10

Лекция 5 Тема «Нормализация»

(4 Часа)

1.Цель нормализации

2. Избыточность данных и аномалии обновления

- Аномалии вставки

- Аномалии удаления

- Аномалии модификации

3. Функциональные зависимости

- Характеристики функциональных зависимостей

- Выявление первичного ключа отношения с использованием функциональных зависимостей

- Правила вывода для функциональных зависимостей

- Минимальное множество функциональных зависимостей

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

Цель нормализации

Нормализация. Метод создания набора отношений с заданными свойствами на основе требований к данным, установленных в некоторой организации.

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

Избыточность данных и аномалии обновления

Основная цель проектирования реляционной базы данных заключается в группировании атрибутов в отношениях таким образом, чтобы минимизировать избыточность данных и тем самым сократить объем памяти, необходимый для физического хранения отношений, представленных в виде таблиц. Проблемы, связанные с избыточностью данных, можно проиллюстрировать, сравнив отношения «Служащие» и «Отдел» табл. 5.2 и 5.3 с отношением «Служащий_Отдел» табл. 5.1. Пусть отношение «Служащий_Отдел» является альтернативной формой представления отношений «Служащий» и «Отдел». Упомянутые отношения описываются следующим образом:

Служащий_ Отдел (Табельный_N, Фамилия, Должность, Оклад, Комната_N, Отдел)

Служащий (Табельный_N, Фамилия, Должность, Оклад, Комната_N)

Отдел (Комната_N, Отдел)

Таблица 5.1 «Служащий_ Отдел»

Табельный_N	Фамилия	Должность	Оклад	Отдел_N	Отдел
100	Сидоров	Техник	2000	О22(5)	Сборка
102	Шевченко	Инженер	5400	О24(3)	Проек. S
107	Том	Инженер	5000	О24(3)	Проек. S
103	Коваль	Бухгалтер	3000	О21(7)	Бухгалтерия
108	Ампер	Инженер	5100	О24(3)	Проек. S
104	Бондарь	Техник	3200	О22(5)	Сборка

Таблицы5.2 «Служащий»

Табельный_N	Фамилия	Должность	Оклад	Отдел_N
100	Сидоров	Техник	2000	О22(5)
102	Шевченко	Инженер	5400	О24(3)
107	Том	Инженер	5000	О24(3)
103	Коваль	Бухгалтер	3000	О21(7)
108	Ампер	Инженер	5100	О24(3)
104	Бондарь	Техник	3200	О22(5)

Таблица 5.3 « Отдел»

Отдел_N	Отдел
О21	Бухгалтерия
О22	Сборка
О24	Проек. S

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

Аномалии вставки

Существуют два основных типа аномалий вставки, которые иллюстрируются с помощью отношения «Служащий_ Отдел» (см, табл. 5.1).

• При вставке сведений о новых сотрудниках в отношение «Служащий_ Отдел». необходимо указать и сведения об отделе, в котором эти сотрудники работают. Например, при вставке сведений о новом сотруднике необходимо ввести информацию отдела - «О21», а так же необходимо ввести сведения и о самом отделе«О21», которые должны соответствовать сведениям об этом же отделе в других строках отношения «Служащий_ Отдел». Отношения, показанные в табл. 5.2 и 5.3, не подвержены влиянию этой потенциальной несовместимости данных, поскольку для каждого сотрудника в отношение «Служащие» потребуется ввести только соответствующий номер отдела. А сведения об отделе с номером «О21», уже существуют в отношении «Отдел» или заносятся в базу данных однократно, в виде единственной строки в это отношение, если бы этой информации не было бы.

• Для вставки сведений о новом отделе компании, которое еще не имеет собственных сотрудников, требуется присвоить значение NULL всем атрибутам описания персонала отношения «Служащий_ Отдел», включая и табельный номер сотрудника «Табельный_N». Но поскольку атрибут «Табельный_N» является первичным ключом отношения «Служащий_ Отдел», то попытка ввести значение NULL в атрибут «Табельный_N». вызовет нарушение целостности сущностей и потому будет отклонена. Следовательно, в отношение «Служащий_ Отдел» невозможно ввести строку о новом отделе компании, содержащую значение NULL в атрибуте «Табельный_N».. Структура отношений, представленных в табл. 5.2 и 5.3, позволяет избежать возникновения этой проблемы, поскольку сведения об отделах компании вводятся в отношение «Отдел» независимо от ввода сведений о сотрудниках. Сведения о сотрудниках, которые будут работать в новом отделении компании, могут быть введены в отношение «Служащие» позже.

Аномалии удаления

При удалении из отношения «Служащий_ Отдел» строки с информацией о последнем сотруднике некоторого отдела компании сведения об этом отделе будут полностью удалены из базы данных.

Например, после удаления из отношения «Служащий_ Отдел» строки для сотрудника Коваль с табельным номером ' 103' из базы данных неявно будут удалены все сведения об отделе с номером 'О21'. Однако структура отношений, показанных в табл. 5.2 и 5.3, позволяет избежать возникновения этой проблемы, поскольку строки со сведениями об отделениях компании хранятся отдельно от строк со сведениями о сотрудниках. Связывает эти два отношения только общий атрибут «Отдел_N». При удалении из отношения «Служащие» строки с номером сотрудника ' 103' сведения об отделении 'О21' в отношении «Отдел» останутся нетронутыми.

Аномалии модификации

При попытке изменения значения одного из атрибутов для некоторого отдела компании в отношении «Служащий_ Отдел» (Например название отделения 'Проек. S') необходимо обновить соответствующие значения в строках для всех сотрудников этого отделения. Если такой модификации будут подвергнуты не все требуемые строки отношения «Служащий_ Отдел», база данных будет содержать противоречивые сведения.

Все приведенные выше примеры иллюстрируют то, что представленные в табл. 5.2 и 5.3 отношения «Служащий» и «Отдел» обладают более приемлемыми свойствами, чем отношение «Служащий_ Отдел», представленное в табл. 5.1. Это доказывает, что отношение «Служащий_ Отдел» подвержено аномалиям обновления, но этих аномалий можно избежать путем декомпозиции первоначального отношения на отношения «Служащие» и «Отдел». С декомпозицией крупного отношения на более мелкие связаны два важных свойства.

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

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

Функциональные зависимости

Функциональная зависимость (functional dependency) описывает связь между атрибутами и является одним из основных понятий нормализации

Характеристики функциональных зависимостей

При описании функциональных зависимостей подразумевается, что реляционная схема имеет атрибуты (А, В, С, . . ., Z) и что вся база данных может быть представлена в виде одного универсального отношения R = (А, В, С, ..., Z). Из этого предположения следует, что каждый атрибут в базе данных имеет уникальное имя.

Функциональная зависимость. Описывает связь между атрибутами отношения. Например если в отношении R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А (что обозначается как А {B}), то каждое значение атрибута А связано только с одним значением атрибута В. (Причем атрибуты А и В могут состоять из одного или нескольких атрибутов.)

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

Рис 5.1 Диаграмма функциональной зависимости

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

Пример 5.1. Выявление функциональной зависимости

Рассмотрим атрибуты «Табельный_N» и «Должность» отношения «Служащий», представленного в табл. 5.2. Зная значение атрибута Табельный_N (например, '100'), можно определить должность, занимаемую этим сотрудником (' Техник '). Иначе говоря, атрибут «Должность» функционально зависит от атрибута «Табельный_N» ,

Табельный_N 100 -------------- Техник

Рис 5.4

как показано на Рис 5.4

Однако обратное утверждение неверно, поскольку атрибут «Табельный_N» функционально не зависит от атрибута «Должность».

100 < — Техник

104 <—/

Другими словами, каждый сотрудник может занимать только одну должность, однако не исключено, что несколько сотрудников могут иметь одинаковую должность.

Связь между атрибутами «Табельный_N» и «Должность» относится к типу "один к одному" (1:1), поскольку с каждым табельным номером сотрудника связана только одна должность. А связь между атрибутами «Должность» и «Табельный_N» имеет тип "один ко многим" (1:*), так как существуют сразу несколько сотрудников (которые различаются по табельным номерам), занимающих одинаковую должность. В данном примере атрибут «Табельный_N» является детерминантом функциональной зависимости «Табельный_N» —> «Должность». Для проведения нормализации необходимо прежде всего выявить функциональные зависимости между атрибутами отношения, которые участвуют в связи "один к одному"

Выявление функциональной зависимости, которая

остается действительной при всех условиях

Рассмотрим значения, хранящиеся в атрибутах «Табельный_N» и «Фамилия» отношения «Служащие» (см. табл. 5.2). На основе изучения этой таблицы можно сделать вывод, что по конкретному значению «Табельный_N», например «100», можно определить «Фамилие» сотрудника компании, в данном случае Сидоров. Кроме того, создается впечатление, что, зная конкретное значение атрибута «Фамилия», например Сидоров, мы можем определить табельный номер этого сотрудника компании, в данном случае «100». Можно ли на основании этого сделать вывод, что атрибут «Табельный_N» является функционально зависимым от атрибута «Фамилия» и/или атрибут «Фамилия» функционально зависит от атрибута «Табельный_N»? Если значения, приведенные в отношении «Служащие» (см. табл. 13.1), представляют собой множество всех возможных значений атрибутов «Табельный_N» и «Фамилия», то имеют место следующие функциональные зависимости:

«Табельный_N»  «Фамилия»

«Фамилия» «Табельный_N»

Есть необходимость выявить функциональные зависимости, которые остаются справедливыми при всех возможных значениях атрибутов отношения, поскольку лишь такие зависимости представляют ограничения целостности тех типов, которые необходимо выявить в процессе проектирования. Подобные ограничения определяют требования, предъявляемые к значениям, которые могут быть представлены в отношении на законных основаниях. Но поскольку нельзя исключить вероятность того, что атрибут «Фамилия» может содержать повторяющиеся значения при наличии в компании сотрудников с одинаковыми именами, это означает, что при определенных обстоятельствах невозможно будет определить табельный номер сотрудника компании «Табельный_N» по его фамилии. Таким образом, между атрибутами «Табельный_N» и «Фамилия» имеется связь "один к одному" (1:1), поскольку каждому табельному номеру соответствует только одно фамилие. С другой стороны, между атрибутами «Фамилия» и «Табельный_N» имеется связь "один ко многим" (1:*), поскольку одинаковое имя могут иметь несколько сотрудников компании. Итак, если рассматриваются все возможные значения атрибутов «Табельный_N» и «Фамилия» отношения «Служащие», то остается справедливой только следующая функциональная зависимость:

«Табельный_N»  «Фамилия»

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

Тривиальные функциональные зависимости

Примеры тривиальных зависимостей для отношения «Служащие» приведены ниже

«Табельный_N», «Фамилия»  «Фамилия»

«Табельный_N», «Фамилия»  «Табельный_N»

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

• определяют связь "один к одному" между атрибутами, приведенными в левой и правой частях выражения зависимости;

• остаются справедливыми при любых условиях;

• являются нетривиальными.

Выявление множества функциональных зависимостей для

отношения «Служащие_ Отдел»

Прежде всего необходимо изучить семантику атрибутов отношения «Служащие_ Отдел» (см. табл. 5.1. Например, предположим, что зарплата сотрудника компании зависит от того, какую должность он занимает и в каком отделении работает. Исходя из такой трактовки атрибутов отношения, можно определить следующие функциональные зависимости:

«Табельный_N»  «Фамилия», «Должность», «Оклад», «Отдел_N», «Отдел»

«Отдел_N»,  «Отдел»

«Отдел»  «Отдел_N»,

«Отдел_N», «Должность»  «Оклад»

«Отдел», «Должность»  «Оклад»

Итак, определено пять функциональных зависимостей в отношении «Служащие_ Отдел», детерминантами которых являются «Табельный_N», «Отдел_N», «Отдел», («Отдел_N», «Должность») и («Отдел», «Должность»). Применительно к каждой из этих функциональных зависимостей можно гарантировать, что все атрибуты, приведенные в правой части выражения, являются функционально зависимыми от детерминанта, который находится в левой части.