Нормализация отношений в Visual FoxPro
|
« Назад Рассмотрим, не прибегая к точным формулировкам, процесс нормализации таблиц базы данных. Суть его в разбиении первоначальной таблицы на более мелкие. При этом разбиение выполняется без потерь данных: всегда можно восстановить исходную таблицу, объединяя мелкие, полученные в результате ее декомпозиции. Таблица представлена в первой нормальной форме (1НФ) , если в таблице нет групп столбцов с повторяющимися данными и все ее столбцы содержат неделимые данные. Рассмотрим, к примеру, табл. 14.5. Таблица 14.5 Изделия и поставщики
Столбец "Поставщики" содержит данные, которые могут (и должны) быть разделены. Следовательно, эта таблица не удовлетворяет 1НФ. В табл. 14.6 данные столбцов "Сумма" и "Всего" вычисляются по значениям столбцов "Количество", "Цена" и "НДС 20%": Сумма = Цена * Количество Всего = Сумма + НДС 20% = Цена * Количество + НДС 20% Таблица 14.6 Реализация изделий
Кроме того, данные столбца "НДС 20%" вычисляются, как Сумма / 5. Таким образом, столбец "Сумма" повторяет данные столбцов "Количество" и "Цена". Аналогичное мнение справедливо и относительно столбцов "Всего" и "НДС 20%". В реляционной модели такая избыточность не приветствуется. Описанная избыточность данных устраняется после ликвидации трех последних столбцов табл. 14.6. Чтобы привести табл. 14.5 в 1НФ, необходимо разбить ее на две таблицы – табл. 14.7 и 14.8. Таблица 14.7 Изделия
Таблица 14.8 Поставщики изделий
Табл. 14.8 обладает очевидной избыточностью. Так, в ней дважды присутствует название поставщика "Трио" и номер его факса. Кроме того, в ней наблюдаются 3 аномалии: обновления, вставки и удаления. Более того, для нее в общем случае не может быть сформирован первичный ключ. Переход к 2НФ состоит в устранении перечисленных проблем. Обсудим прежде обозначенные проблемы. Понятие первичного ключа выводится из понятий суперключа и кандидатного ключа. Суперключ таблицы – это выражение, операндами которого являются имена столбцов таблицы, уникальным образом определяющее запись таблицы. Так, для табл. 14.7 можно указать по крайней мере 4 суперключа: ID_изделия; Тип; STR(ID_изделия) + Тип; STR(ID_изделия) + Вид + Тип. Кандидатный ключ – это часть суперключа, которая также является суперключом и не может быть сокращена до другого суперключа. Так, для табл. 14.7 можно задать 2 кандидатных ключа: ID_изделия; Тип. Любой кандидатный ключ может быть выбран в качестве первичного ключа. В случае табл. 14.8 ("Поставщики") в общем случае не могут быть указаны суперключ и, следовательно, первичный ключ. Действительно, самое общее выражение STR(ID_изделия) + Наименование_поставщика + Факс не определяет уникальным образом запись таблицы по той причине, что различные поставщики могут иметь одинаковые имена, но при этом не иметь факса. В таком случае относящиеся к разным поставщикам записи, например 5 Сириус – 5 Сириус – не удастся различить при помощи ключа STR(ID_изделия) + Наименование_поставщика + Факс. Очевидно, что в этой таблице нет и иного уникального ключа. Аномалия обновления наблюдается, когда при изменении одного экземпляра данных приходится корректировать несколько записей. Так, если у поставщика, например "Трио", изменился номер факса, то в табл. 14.8 придется корректировать все записи с этим поставщиком. Аналогичная проблема возникает и при изменении имени поставщика. Замена одного поставщика на иного также выглядит неуклюже: приходится корректировать не одно, что логично, а два поля – "Поставщик" и "Факс". Кроме того, такая замена может вдобавок повлечь аномалию удаления. Аномалия вставки проявляется в том, что добавленная запись приведет к потере уникальности заданного первичного ключа (см. приведенный выше пример с поставщиками, имеющими наименование "Сириус"). Аномалия удаления наблюдается, когда удаление записи влечет существенную потерю данных. Так, при удалении из табл. 14.8 записи 2 Аист 5-70-03 полностью теряются сведения о поставщике: в других строках таблицы указанный поставщик не упоминается. Эта потеря существенна, так как нашей целью было лишь указать, что "Аист" не является более поставщиком изделия 2; удаление сведений о поставщике – это явная аномалия. В рассматриваемом примере эти проблемы снимает разбиение табл. 14.8 на две таблицы – табл. 14.9 и 14.10. Таблица 14.9 Поставщики
Таблица 14.10 Поставщики изделий
Таким образом, изначально представленные в табл. 14.5 данные на этом этапе формирования модели предметной области описываются табл. 14.7, 14.9 и 14.10. Среди них табл. 14.7, однако, не отвечает требованиям 3НФ, в которой каждый атрибут таблицы определяется либо ее суперключом, либо ее кандидатным ключом. Действительно, существующая в ней функциональная зависимость "ID изделия – Вид" не позволяет по значению ID изделия определить его вид. В частности, для ID изделия со значениями 1 и 2 в табл. 14.7. указывается один и тот же вид – "Диод". Решение проблемы в том, чтобы ввести таблицу видов изделий (табл. 14.11), а табл. 14.7 записать с учетом определенных в табл. 14.11 видом, т. е. в виде табл. 14.12. Таблица 14.11 Виды изделий
Таблица 14.12 Изделия
В этом случае функциональная зависимость "ID изделия – Вид" перестает существовать; взамен ее появляется зависимость "ID вида изделия – Вид". Аналогичная ситуация, в принципе, может возникнуть и в табл. 14.9, когда в ней окажутся поставщики с одинаковыми наименованиями. Однако это более терпимый случай нарушения 3НФ, с которым в большинстве случаев можно примириться. Пример по причине своей простоты не позволяет проиллюстрировать 4НФ и 5НФ. Суть приведения таблицы к 4НФ – устранение аномалий многозначной зависимости и объединяющей зависимости. Пятая нормальная форма достигается в том случае, когда таблица не может далее разбиваться на более мелкие таблицы без потери данных. Таким образом, разбивая исходные таблицы, мы получаем вариант базы данных, удовлетворяющий нас как по способу представления данных, так и по производительности, возможно, впрочем, не отвечающий строго 3НФ. |