Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Скачиваний:
59
Добавлен:
16.03.2016
Размер:
558.36 Кб
Скачать

этой формы. Переводя структуру отношений БД в формы более высокого порядка, мы добиваемся удаления из таблиц избыточной неключевой информации.

Процесс нормализации основан на понятии функциональной зависимости атрибутов. Функциональная зависимость атрибута А от атрибута В (обозначается А—>В) существует, если в любой момент времени каждому значению атрибута А соответствует не более одного значения атрибута В.

Обратите внимание, что термин функциональная зависимость соответствует понятию функции в математике.

Полная функциональная зависимость атрибута А от атрибута В существует, если атрибут А зависит от всего атрибута (составного) В и не зависит от его частей.

Если атрибут А зависит от атрибута В, а В зависит от атрибута С, но обратная зависимость отсутствует, то говорят, что атрибут С зависит от А транзитивно.

Отношение находится в первой нормальной форме (1NF), если значения атрибутов атомарны , то есть в каждом столбце находится только одно значение и все неключевые атрибуты функционально зависят от ключа. В СУБД дата — неделимый тип данных, поэтому, хотя дата заказа и состоит из 3 чисел, это — атомарный атрибут.

Отношение находится во второй нормальной форме (2NF), если выполняются ограничения первой нормальной (1NF) формы и каждый неключевой атрибут функционально полно зависит от первичного ключа (первичный ключ может быть составным).

Отношение находится в третьей нормальной форме (3NF), если выполняются ограничения второй нормальной формы (2NF) и если все неключевые атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.

Вот альтернативное определение. Отношение находится в третьей нормальной форме (3NF), если выполняются ограничения второй нормальной формы (2NF) и в нем отсутствуют транзитивные зависимости неключевых атрибутов от первичного ключа.

В большинстве случаев третья нормальная форма служит компромиссом между полной нормализацией и функциональностью в совокупности с легкостью реализации. Как было отмечено выше, существуют нормальные формы, выше третьей (3NF), но на практике они затрудняют разработку структур данных и снижают их функциональность.

Вот пример приведения отношения к третьей нормальной форме.

Пусть небольшому ресторану, требуется сохранять данные о блюдах, которые готовятся в нем. Эти данные включают:

1)название блюда;

2)изготовитель блюда;

3)наименование составных продуктов;

5)вес составных частей блюда.

Нам необходимо нормализовать приведенную ниже таблицу. Заметим, что она даже не

находится в первой нормальной форме (1NF), так как ее атрибут «Изготовитель» не атомарный.

Первая нормальная форма

Для того чтобы таблица была представлена в первой нормальной форме, необходимо, чтобы все значения в столбцах были атомарными, а все строки разными. Следовательно, таблица «Рецепт» приведено к первой нормальной форме. Первичным ключом таблицы являются Код блюда и Код Продукта. Такой выбор не позволяет указывать для одного итого же блюда один и тот же продукт.

11

Рис. 4.4 Первая нормальная форма

Однако в таблице Рецепт содержатся избыточные данные. Данные изготовителе (Фамилия, Имя, Отчество, Город, Улица, Квартира, Квалификация) постоянно повторяются для каждого типа блюда. Избыточность приводит к так называемым аномалиям обновления, которые возникают при вставке, удалении и обновлении данных. В таблице Рецепт могут появиться следующие аномалии.

Тот факт, что некоторый изготовитель имеет имя, фамилию, отчество, адрес, не будет отражен до тех пор пока изготовитель не сделает хотя бы одно блюдо.

Если информация о блюде удаляется из таблицы, то удаляется также информация о ее изготовителе.

Если изменяется информация об изготовителе, то возникает необходимость обновления большого числа строк.

Если изменяется цена продукта, то возникает необходимость обновления большого числа строк.

Вторая нормальная форма

Для того чтобы избежать некоторых аномалий, характерных для первой нормальной формы, необходимо привести нашу таблицу к второй нормальной форме.

Таблица Рецепт соответствует первой нормальной форме, но не соответствует второй нормальной форме, поскольку столбцы Название блюда, Фамилия, Имя, Отчество, Город, Улица, Дом, Квартира, Квалификация зависят только от Кода Блюда, части составного ключа (Код Блюда, Код Продукта).

Для преобразования таблицы из первой нормальной формы во вторую нужно выполнить следующие операции.

Выделить часть (столбец или несколько столбцов) составного ключа, которая целиком определяет некоторые неключевые столбцы таблицы.

Создать и снабдить именем новую таблицу для каждого определяющего столбца и тех неключевых столбцов исходной таблицы, которые полностью зависят от значений этого столбца.

Переместить найденные столбцы из исходной таблицы во вновь созданную. определяющий столбец (или множества столбцов) становится первичным ключом новой

12

таблицы.

• Удалить в исходной таблицы те столбцы, которые были перемещены в новую, за исключением столбцов играющих роль внешних ключей.

Трансформируем таблицу Рецепт во вторую нормальную форму. Для этого переместим столбцы Название блюда, Фамилия, Имя, Отчество, Город, Улица, Дом, Квартира, Квалификация в новую таблицу Изготовитель. Столбец Код Блюда становится первичным ключом таблицы Блюдо.

БЛЮДО

Название блюда (РК)

Фамилия

изготовителя Имя изготовителя Отчество изготовителя Город проживания изготовителя Улица проживания изготовителя Дом проживания изготовителя

Квартира проживания изготовителя Квалификация изготовителя

РЕЦЕПТ

Название Блюда (РК, FK)

Название

Продукта

(РК, FK)

Вес

продукта

ПРОДУКТ

Название

Продукта

(РК)

Цена

продукта

Рис. 4.5. Вторая нормальная форма

Как можно заметить, теперь удаление строки из таблицы Рецепт не приведет к уничтожению информации об изготовителе.

Таблица во второй нормальной форме, по прежнему содержит аномалии.

Данные об изготовителе нельзя внести в таблицу до тех пор , пока не внесена информация о блюде.

Удаление строки из таблицы Блюдо влечет уничтожение информации о изготовителе.

Если адрес изготовителя меняется, то возникает необходимость в обновлении многих

строк.

Третья нормальная форма

Реляционная таблица находится в третьей нормальной форме, если выполняются ограничения второй нормальной формы и в ней отсутствуют транзитивные зависимости неключевых атрибутов от ключа.

Таблица Рецепт уже соответствует третьей нормальной форме. Неключевой атрибут «Вес продукта» полностью зависит от первичного ключа(Код Блюда, Код Продукта). Однако таблица Блюдо представлена во второй нормальной форме, поскольку в ней существуют транзитивные зависимости. Например, атрибут «Квалификация» зависит от атрибутов Фамилия, Имя, Отчество.

13

Для того чтобы привести таблицу Блюдо к третьей нормальной форме необходимо сделать следующее.

Выявить определяющие атрибуты (группы атрибутов), не входящие в состав первичного ключа, и те неключевые атрибуты, которые полностью зависят от значений определяющих атрибутов.

Для каждого определяющего атрибута (группы атрибутов) создать новую таблицу и присвоить ей имя. Включить в таблицу все атрибуты полностью зависящие от определяющего.

Для того чтобы преобразовать таблицу Блюдо в третью нормальную форму, создадим таблицу Изготовитель и переместим в нее атрибуты Фамилия, Имя, Отчество, Город, Улица, Дом, квартира, Квалификация. Добавим в таблицу в качестве первичного ключа атрибут «Код Изготовителя». В таблице Блюдо также добавим атрибут «Код Изготовителя» в качестве внешнего ключа.

Таким образом, приведение таблицы Блюдо к третьей нормальной форме приводит к созданию двух таблиц Блюдо и Изготовитель. Для того чтобы база данных получилась законченной добавим к полученным трем таблицам четвертую таблицу Продукт.

БЛЮДО

РЕЦЕПТ

 

ПРОДУКТ

 

 

 

 

 

 

 

Название блюда

Название

 

Название

(РК)

Блюда (РК,

 

Продукта

 

 

FK)

 

(РК)

Фамилия (FK)

Название

 

 

Имя

 

 

 

Цена

Продукта

 

Отчество

 

(РК, FK

 

продукта

 

 

 

Вес

продукта

ИЗГОТОВИТЕЛЬ

Фамилия

Имя

Отчество

(РК)

Город

Улица

Дом

Квартира

Квалификация

Рис. 4.6. Третья нормальная форма

При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Так, для идентификации студента можно использовать либо

14

уникальный номер зачетной книжки, либо набор из фамилии, имени, отчества, номера группы и может быть дополнительных атрибутов, так как не исключено появление в группе двух студентов (а чаще студенток) с одинаковыми фамилиями, именами и отчествами. Плохо также использовать в качестве ключа не номер блюда, а его название, например, " Закуска из плавленых сырков "Дружба" с ветчиной и соленым огурцом" или "Заяц в сметане с картофельными крокетами и салатом из красной капусты".

Ниже представлены таблицы, полученные после минимизации длины первичных ключей.

БЛЮДО

Код Блюда (РК)

Название блюда Код Изготовителя

(FK)

РЕЦЕПТ

Код Блюда

(РК, FK)

Код (РК, FK

Вес

продукта

ПРОДУКТ

Код

Продукта

(РК)

Название

Продукта

Цена

Продукта

ИЗГОТОВИТЕЛЬ

Код Изготовителя (РК)

Фамилия

Имя

Отчество

Город

Улица

Дом

Квартира

Квалификация

Рис. 4.7. Третья нормальная форма с короткими ключами

Преимущества представления реляционных таблиц в третьей нормальной форме заключается в ликвидации избыточности данных, позволяющей экономить память, в снижении числа аномалий обновлений.

Усовершенствование нашей базы данных после преобразования ее в третью нормальную форму таковы.

Информация об изготовителе может быть внесена, даже если изготовитель не сделал ни одного блюда.

Информация о блюдах может быть удалена без уничтожения информации об изготовителе.

Изменение адреса изготовителя потребует изменения лишь одной строки.

15

Нормализация отношений — не пустая трата времени. Пусть в приведенном примере требуется изменить цену картофеля с 5р на 8р. В ненормализованном отношении пришлось бы искать и редактировать все строки, содержащие это наименование, а в нормализованной БД изменяется только одна строка одного отношения.

4.5.3 Манипулирование реляционными данными

В манипуляционной составляющей модели данных определяются два базовых механизма манипулирования реляционными данными:

реляционная алгебра, основанная на теории множеств

реляционное исчисление, базируется на математической логике.

Рассматриваются два вида реляционного исчисления — исчисление доменов и исчисление предикатов.

Все эти механизмы обладают одним важным свойством: они замкнуты относительно понятия отношения.

Язык манипулирования реляционными БД называется реляционно-полным, если любой запрос, выражаемый с помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления, может быть выражен с помощью одного оператора этого языка.

Известно, что механизмы реляционной алгебры и реляционного исчисления эквивалентны, т.е. для любого допустимого выражения реляционной алгебры можно построить эквивалентную (т.е. производящую такой же результат) формулу реляционного исчисления и наоборот.

Почему же в реляционной модели данных присутствуют два механизма на основе которых могут быть построены запросы?

Известно, что любое выражения реляционной алгебры имеют аналог в виде одной формулы реляционного исчисления и наоборот.

Для формулы реляционного исчисления однозначная интерпретация, вообще говоря, отсутствует. Формула только устанавливает условия, которым должны удовлетворять кортежи результирующего отношения. Поэтому языки реляционного исчисления являются более непроцедурными или декларативными.

Реляционная алгебра. Основная идея реляционной алгебры состоит в том, что коль скоро отношения являются множествами, то средства манипулирования отношениями могут базироваться на традиционных операциях над множествами, дополненных некоторыми специальными операциями, специфичными для баз данных.

Чаще всего выделяют следующие операции реляционной алгебры:

1)объединение отношений;

2)пересечение отношений;

3)разность отношений; •

4)произведение отношений;

5)деление отношений;

6)ограничение отношения;

7)проекция отношения;

8)соединение отношений.

Не вдаваясь в детали, операции реляционной алгебры могут быть описаны следующим образом

1)Операция объединения двух отношений позволяет создать отношение, включающее все строки отношений-операндов. Отношения-операнды должны иметь одинаковый набор атрибутов.

2)Результат операции пересечения отношений - отношение, содержащее строки, которые входят одновременно в оба отношения-операнда. Отношения-операнды должны иметь одинаковый набор атрибутов

3)Разность отношений используется для выделения строк, которые входят в первое отношение-операнд и не входят во второе. Операнды должны иметь одинаковый набор атрибутов.

16

4)При выполнении операции произведения двух отношений каждая строка первого отношения-операнда сцепляется (конкатенируется) с каждой строкой второго отношенияоперанда. Сцепленные строки образуют отношение-результат. Число строк в отношении-ре- зультате равно произведению числа строк в отношениях-операндах. Множества атрибутов отношений-операндов не должны пересекаться.

5)Операция деления "обратна" операции умножения. Описать ее в нематематических терминах довольно сложно.

6)Операция ограничения (селекции) - это выбор из отношения подмножества кортежей, удовлетворяющих заданному условию.

7)Операция проекции позволяет выбрать из отношения-операнда определенные столбцы (атрибуты отношения), исключая повторения.

8)Операция соединения — одна из наиболее важных операций в реляционной алгебре. Различают операции соединения по условию и операцию естественного соединения. В первом случае происходит конкатенация строк отношений, которое проверяется на соответствие заданному условию. Если строка удовлетворяет условию, то она включается в отношение-результат. Во втором случае в отношение результат включаются строки, удовлетворяющие условию равенства общих атрибутов.

В настоящее время созданы языки манипулирования данными, которые позволяют реализовывать все операции реляционной алгебры.

SQL (Structured Query Language) – структуризованный язык запросов QBE (Quere-By-Example – запросы по образцу.

Оба языка являются к языкам очень высокого уровня.

С помощью единственного запроса таких языков можно соединить несколько таблиц во временную таблицу и вырезать из нее требуемые строки и столбцы.

4.5.4. Ограничения целостности

Под Целостностью (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) понимается правильность данных в любой момент времени.

Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений.

Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).

Выделяют три группы правил целостности:

Целостность по сущностям.

Целостность по ссылкам.

Целостность, определяемая пользователем.

Первое требование называется требованием целостности сущностей. Объекту или сущности реального мира в реляционных БД соответствуют кортежи отношений. Конкретно требование состоит в том, что любой кортеж любого отношения отличим от любого другого кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным ключом. Как мы видели в предыдущем разделе, это требование автоматически удовлетворяется, если в системе не нарушаются базовые свойства отношений.

Т.к. потенциальные ключи фактически служат идентификаторами объектов предметной области (т.е. предназначены для различения объектов), то значения этих идентификаторов не могут содержать неизвестные значения. Действительно, если бы идентификаторы могли содержать null-значения, то мы не могли бы дать ответ "да" или "нет" на вопрос, совпадают или нет два идентификатора.

Это определяет следующее правило целостности сущностей:

Правило целостности сущностей. Атрибуты, входящие в состав некоторого потенциального ключа не могут принимать null-значений.

Второе требование называется требованием целостности по ссылкам.

17

Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа.

Правило целостности внешних ключей. Внешние ключи не должны быть несогласованными, т.е. для каждого значения внешнего ключа должно существовать соответствующее значение первичного ключа в родительском отношении.

В нашем примере (база данных для хранения рецептов блюд) значение атрибута Код Изготовителя в любом кортеже отношения БЛЮДО должно соответствовать значению атрибута Код Изготовителя в каком-либо кортеже отношения ИЗГОТОВИТЕЛЬ.

Таким образом, если Код Изготовителя указан, то Изготовитель должен существовать.

БЛЮДО

Код Блюда (РК)

Название блюда Код Изготовителя

(FK)

РЕЦЕПТ

Код Блюда (РК, FK)

Код Продукта(РК, FK

Вес продукта

ИЗГОТОВИТЕЛЬ

Код Изготовителя (РК)

Фамилия

Имя

Отчество

Город

Улица

Дом

Квартира

Квалификация

Рис. 4.8. Схема базы данных «Рецепты блюд»

ПРОДУКТ

Код

Продукта

(РК)

Название

Продукта

Цена

Продукта

Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД.

Для соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении кортежей с одним и тем же значением первичного ключа. С целостностью по ссылкам дела обстоят несколько более сложно.

Понятно, что при обновлении ссылающегося отношения (вставке новых кортежей или модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем, чтобы не появлялись некорректные значения внешнего ключа. Но как быть при удалении кортежа из отношения, на которое ведет ссылка?

18

Здесь существуют три подхода, каждый из которых поддерживает целостность по ссылкам. Первый подход заключается в том, что запрещается производить удаление кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения их внешнего ключа).

При втором подходе при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение внешнего ключа автоматически становится неопределенным.

Наконец, третий подход (каскадное удаление) состоит в том, что при удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.

В развитых реляционных СУБД обычно можно выбрать способ поддержания целостности по ссылкам для каждой отдельной ситуации определения внешнего ключа.

Замечания к правилам целостности сущностей и внешних ключей

На самом деле приведенные правила целостности сущностей и внешних ключей прямо следуют из определений понятий "потенциальный ключ" и "внешний ключ".

Действительно, в определении потенциального ключа требуется, чтобы потенциальный ключ обладал свойством уникальности. Это фактически означает, что мы должны уметь различать значения потенциальных ключей, т.е. при сравнении двух значений потенциального ключа мы всегда должны получать значения либо ИСТИНА, либо ЛОЖЬ. Но любое сравнение, в которое входит null-значение, принимает значение U - НЕИЗВЕСТНО, откуда следует, что атрибуты потенциального ключа не могут содержать null-значений.

Для внешних ключей правило целостности фактически входит в определение (п. 2 определения 2).

Таким образом, с точки зрения реляционной теории, явная формулировка правил целостности является излишней - они автоматически вытекают из определений понятий ключа и внешнего ключа.

Тем не менее, явная формулировка правил целостности имеет определенный практический смысл. В большинстве серьезных СУБД за выполнением этих ограничений следит сама СУБД, если, конечно, пользователь явно объявил потенциальные и внешние ключи. Но, во-первых, для некоторых систем можно допустить, чтобы эти ограничения не выполнялись, а во-вторых, некоторые системы просто не поддерживают понятия целостности, например, некоторые "настольные" СУБД типа FoxPro 2.5. В этих случаях за целостностью данных должен следить сам пользователь, или программист, разрабатывающий приложение для пользователя.

Явная формулировка правил целостности помогает четко понять, какие опасности несет в себе пренебрежение этими правилами.

Операции, могущие нарушить ссылочную целостность

Ссылочная целостность может нарушиться в результате операций, изменяющих состояние базы данных. Таких операций три - вставка, обновление и удаление кортежей в отношениях. Т.к. в определении ссылочной целостности участвуют два отношения - родительское и дочернее, а в каждом из них возможны три операции - вставка, обновление, удаление, то нужно рассмотреть шесть различных вариантов.

Для родительского отношения

19

Вставка кортежа в родительском отношении. При вставке кортежа в родительское отношение возникает новое значение потенциального ключа. Т.к. допустимо существование кортежей в родительском отношении, на которые нет ссылок из дочернего отношения, то вставка кортежей в родительское отношение не нарушает ссылочной целостности.

Обновление кортежа в родительском отношении. При обновлении кортежа в родительском отношении может измениться значение потенциального ключа. Если есть кортежи в дочернем отношении, ссылающиеся на обновляемый кортеж, то значения их внешних ключей станут некорректными. Обновление кортежа в родительском отношении может привести к нарушению ссылочной целостности,

если это обновление затрагивает значение потенциального ключа.

Удаление кортежа в родительском отношении. При удалении кортежа в родительском отношении удаляется значение потенциального ключа. Если есть кортежи в дочернем отношении, ссылающиеся на удаляемый кортеж, то значения их внешних ключей станут некорректными. Удаление кортежей в родительском отношении может привести к нарушению ссылочной целостности.

Для дочернего отношения

Вставка кортежа в дочернее отношение. Нельзя вставить кортеж в дочернее отношение, если вставляемое значение внешнего ключа некорректно. Вставка кортежа в дочернее отношение привести к нарушению ссылочной целостности.

Обновление кортежа в дочернем отношении. При обновлении кортежа в дочернем отношении можно попытаться некорректно изменить значение внешнего ключа. Обновление кортежа в дочернем отношении может привести к нарушению ссылочной целостности.

Удаление кортежа в дочернем отношении. При удалении кортежа в дочернем отношении ссылочная целостность не нарушается.

Таким образом, ссылочная целостность в принципе может быть нарушена при выполнении одной из четырех операций:

Обновление кортежа в родительском отношении.

Удаление кортежа в родительском отношении.

Вставка кортежа в дочернее отношение.

Обновление кортежа в дочернем отношении.

Стратегии поддержания ссылочной целостности

Существуют две основные стратегии поддержания ссылочной целостности:

RESTRICT (ОГРАНИЧИТЬ)- не разрешать выполнение операции, приводящей к нарушению ссылочной целостности. Это самая простая стратегия, требующая только проверки, имеются ли кортежи в дочернем отношении, связанные с некоторым кортежем в родительском отношении.

CASCADE (КАСКАДИРОВАТЬ)- разрешить выполнение требуемой операции, но внести при этом необходимые поправки в других отношениях так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительском отношении и каскадно выполняется в дочернем отношении. В реализации этой стратегии имеется одна тонкость,

20

Соседние файлы в папке Информационные системы