Книга по БД(Вальке А

4.4. Нормализация

Зачем нужна нормализация?

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

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

----T--------T--------T--------T--------T--------T-----T---------¬ ¦ N ¦Фамилия ¦дата ¦месяц, ¦месячная¦ дата ¦отдел¦должность¦ ¦ ¦ ¦рожден. ¦год ¦зарплата¦ приема ¦ ¦ ¦ +---+--------+--------+--------+--------+--------+-----+---------+ ¦ 1 ¦ Иванов ¦1.1.1955¦12,1994 ¦ 150000 ¦2.2.1986¦ОНТИ ¦инженер ¦ ¦ 2 ¦ Петров ¦3.4.1966¦11.1994 ¦ 280000 ¦4.9.1992¦ВОХР ¦охранник ¦ ¦ 3 ¦ Петров ¦3.4.1966¦12,1994 ¦ 350000 ¦4.9.1992¦ВОХР ¦охранник ¦ ¦ 4 ¦ Сидоров¦7.1.1968¦12,1994 ¦ 350000 ¦1.7.1989¦ВОХР ¦охранник ¦ ¦.. ¦ .... ¦ .... ¦ .... ¦ .... ¦ .... ¦.... ¦ .... ¦ L---+--------+--------+--------+--------+--------+-----+----------

Рис. 4.10. Пример ненормализованеной таблицы.

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

Недостатки такой универсальной таблицы следующие:

- жесткость;

- ненадежность (потенциальная противоречивость);

- повышенный расход ресурсов;

- громоздкость (избыточность).

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

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

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

-----------T--------------------------T-----------------+ ¦ Товар ¦ производитель ¦ Адрес ¦ +----------+--------------------------+-----------------+ ¦ рога ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ копыта ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ джинсы ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ ¦ ...... ¦ .................... ¦ ............... ¦ L----------+--------------------------+------------------

Рис. 4.11. Таблица “Товары”.

Рассмотрим подробно недостатки такой схемы.

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

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

-----------T--------------------------T-----------------¬ ¦ рога ¦ АО Рога и Копыта ¦ Москва, Бутырка ¦ ¦ копыта ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ ...... ¦ .................... ¦ ............... ¦ L----------+--------------------------+------------------

Рис. 4.12. Последствия неполного обновления данных в ненормализованной таблице.

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

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

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

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

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

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

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

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

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

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

Рассмотрим примеры. Как мы уже договорились выше, варианты с отсутствием ключей не представляют практического интереса и рассматриваться не будут. Предположим, мы имеем таблицу “Товары” с описанием товаров и их производителей:

---------T----------------------T-----------------+ ¦ Товар ¦ производитель ¦ Адрес ¦ +--------+----------------------+-----------------+ ¦ рога ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ копыта ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ джинсы ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ ¦ кеды ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ | ... | ... | ... | L--------+----------------------+------------------

Рис. 4.13. Таблица “Товары”.

Один и тот же товар (товар с одним и тем же названием) может производиться несколькими фирмами, но конкретно то или иное изделие может быть идентифицировано по своему названию и по фирме-производителю. В нашем примере кеды производятся двумя разными фирмами и это будут разные товары. С другой стороны, в этой таблице мы храним и адрес фирмы производителя. Адрес фирмы производителя однозначно определяется названием фирмы. Обратное не верно, так как по одному и тому же адресу может располагаться несколько фирм. То есть, единственным ключом является пара атрибутов (Товар, Производитель). В этой таблице существует единственный неключевой атрибут - “Адрес”. Этот атрибут полностью зависит от ключевого атрибута “Производитель”, который является подмножеством ключа. Следовательно, данное отношение не находится во второй нормальной форме.

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

---------T----------T----------------------T-----------------+ ¦ Товар ¦ Бар-код ¦ производитель ¦ Адрес ¦ +--------+----------+----------------------+-----------------+ ¦ рога ¦ 46131313 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ копыта ¦ 46131235 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ 01130004 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ 01130006 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ джинсы ¦ 02010551 ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ ¦ кеды ¦ 02010552 | ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ | ... | ... | ... | ... | L--------+----------+----------------------+------------------

Рис. 4.14. Таблица “Товары”.

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

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

Таблица “Товары” ---------T----------------------+ ¦ Товар ¦ производитель ¦ +--------+----------------------+ ¦ рога ¦ АО Рога и Копыта ¦ ¦ копыта ¦ АО Рога и Копыта ¦ ¦ кеды ¦ АО Рога и Копыта ¦ ¦ джинсы ¦ ТОО Добро пожаловать ¦ ¦ кеды ¦ ТОО Добро пожаловать ¦ | ... | ... | L--------+----------------------+

Таблица “Адреса_производителей” +----------------------T-----------------+ ¦ Производитель ¦ Адрес ¦ +----------------------+-----------------+ ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ +----------------------+-----------------+

Рис. 4.15. Приведение таблицы “Товары” во вторую нормальную форму.

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

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

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

Третья нормальная форма исключает транзитивную зависимость. Отношение находится в третьей нормальной форме, если оно имеет вторую нормальную форму и каждый неключевой атрибут нетранзитивно зависит от от любого ключа в данном отношении [Мартин]. Другими словами, неключевые атрибуты должны зависеть только от ключей. Например, если мы идентифицируем товары по бар-коду, и имеем следующую таблицу, находящуюся во второй нормальной форме и не находящуюся в третьей:

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

---------T----------T ----------------------T-----------------+ ¦ Товар ¦ Бар-код ¦ производитель ¦ Адрес ¦ +--------+----------+----------------------+-----------------+ ¦ рога ¦ 46131313 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ копыта ¦ 46131235 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ 01130004 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ кеды ¦ 01130006 ¦ АО Рога и Копыта ¦ Одесса, п/я 13 ¦ ¦ джинсы ¦ 02010551 ¦ ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ ¦ кеды ¦ 02010552 | ТОО Добро пожаловать ¦ Энск, 5-е авеню ¦ | ... | ... | ... | ... | L--------+----------+----------------------+------------------

Рис. 4.16. Другой вариант таблицы “Товары”.

Данное отношение не находится в третьей нормальной форме, так как адрес фирмы однозначно зависит от ее названия, а название (поле “производитель”) не являются ни ключом, ни частью ключа в данном отношении. Для того, чтобы привести данное отношение в третью нормальную форму, нужно разбить это отношение на два - убрать из данного отношения атрибут “Адрес” и завести новое отношение “Адреса фирм‑производителей”.

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

Нормальная форма Бойса-Кодда

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

В качестве примера отношения, которое находится в третьей нормальной форме, но при этом не находится в нормальной форме Бойса-Кодда, можно привести пример таблицы, определяющей почтовый индекс по названию города и названию улицы. При этом предполагается, что всю улица обслуживается одним почтовым отделением^⁷ задающей номер почтового индекса. При этом, одно почтовое отделение может обслуживать несколько улиц. Ключом в данной таблице будет пара атрибутов (Город, Улица). С другой стороны, в данной таблице имеет место зависимость города от почтового индекса - по индексу всегда можно определить город:

+--------+----------------------+--------+ ¦ Город ¦ Улица ¦ Индекс ¦ +--------+----------------------+--------+ ¦ Москва ¦ Профсоюзная ¦ 116321 ¦ ¦ Москва ¦ Островитянова ¦ 116321 ¦ ¦ Москва ¦ Академическая ¦ 117303 ¦ ¦ Дмитров¦ Профсоюзная ¦ 157400 ¦ ¦ Клин ¦ Профсоюзная ¦ 190005 ¦ ¦ Клин ¦ Абрикосовая ¦ 190006 ¦ | ... | ... | ... | L--------+----------------------+--------+

Рис. 4.17. Таблицы “Почтовые индексы”.

Следовательно, данная таблица не находится в нормальной форме Бойса-Кодда.

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

Четвертая нормальная форма

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

Дадим определение многозначной зависимости, используемой при определении четвертой нормальной формы. В отношении R существует многозначная зависимость между набором атрибутов X и Y (Y многозначно зависит от X), если для любых двух записей r1 и r2, таких что они совпадают на множестве атрибутов X , то есть r1[X]=r2[X], всегда существует запись r3 такая, что

r3 совпадает на множестве атрибутов X с записями r1 и r2, то есть r1[X]=r2[X]=r3[X],
на множестве атрибутов Y запись r3 совпадает с r1, то есть r1[Y]=r3[Y],
на множестве атрибутов, не входящих ни в X, ни в Y , запись r3 совпадает с r2, то есть r2[R-(X+Y)]=r3[R-(X+Y)].

Если попытатьться перефразировать это определение, то можно пояснить его смысл следующим образом: Если существует запись [x, y1, z1] и запись [x, y2, z2], то должна существовать запись [x, y1, z2] и (в силу симметричности определения) запись [x, y2, z1]. Многозначные зависимости проявляются при логическом группировании некоторых атрибутов, и их симметричном вхождении в отношении. Например, рассмотрим таблицу, в которой хранится информация о семинарах, проводимых в некотором Университете. Данная таблица может иметь следующие атрибуты:

+---------------+----------+-----------+--------+--------+ ¦ Преподаватель ¦ Студент ¦ Аудитория | Время ¦ День ¦ +---------------+----------+-----------+--------+--------+ ¦ Бякин ¦ Петров ¦ 711 | 9:00 ¦ Понед ¦ ¦ Бякин ¦ Иванова ¦ 745 | 10:50 ¦ Понед ¦ | ... | ... | ... | ... | ... ¦ L---------------+----------+-----------+--------+--------+

Рис. 4.18. Таблица “Семинары”.

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

7+---------------+----------+-----------+--------+--------+ ¦ Преподаватель ¦ Студент ¦ Аудитория | Время ¦ День ¦ +---------------+----------+-----------+--------+--------+ ¦ Бякин ¦ Петров ¦ 711 | 9:00 ¦ Понед ¦ ¦ Бякин ¦ Иванова ¦ 745 | 10:50 ¦ Понед ¦ ¦ Бякин ¦ Петров ¦ 745 | 10:50 ¦ Понед ¦ ¦ Бякин ¦ Иванова ¦ 711 | 9:50 ¦ Понед ¦ | ... | ... | ... | ... | ... ¦ L---------------+----------+-----------+--------+--------+

Рис. 4.19. Таблица “Семинары” в случае отсутствия 4-й нормальной формы.

В этом случае атрибут “Студент” функционально зависит от атрибута “Преподаватель”.

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

Если отношение не находится в четвертой нормальной форме, то обычно это означает, что при рассмотрении предметной области, при отображении ее в схему базы данных, были пропущены какие-то классы объектов или сущностей, которые стоило бы выделить в отдельные отношения. Например, в нашем примере с семинарами напрашивается введение отношения “Группы”, в котором будут перечислены студенты и для каждого студента будет указан номер группы. А преподаватель теперь будет проводить семинары не для студентов, а для группы.

Методика нормализации

Нормализация схемы базы данных призвана упорядочить схему, сделать ее более надежной и удобной в работе. То есть нормализация не должна рассматриваться как самоцель. Существуют специальные методики разбиения таблиц на две таблицы с целью приведения их к нормальным формам [Мартин, Мейер]. Здесь же мы рассмотрим несколько иной подход, а именно как изначально проектировать “правильную” схему базы данных так, что потребность в нормализации была минимальной.

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

Факт поставки (товар, кто поставил, когда поставил, контракт, условия поставки)
Товар (производитель, название)
Контракт (кто подписал, что предусматривает, срок действия)
Поставщик товара (название, адрес)
Производитель товара (название, адрес)

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

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

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

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

Неточность в нашей схеме проявится тогда, когда мы заключим договор на поставку товара непосредственно с фирмой-производителем данного товара. В этом случае нам потребуется занести информацию о данной фирме сразу в две таблицы - производетелей и поставщикков. Более того, эти две сущности очень похожи, и являются детализацией другой сущности - “Фирма”. Поэтому стоит объединить потсавщиков и производителей в единую таблицу “Фирмы”. В результате получится схема базы данных, которая будет работоспособной:

Общие правила нормализации

Подводя итоги описания методики нормализации, можно выделить следующие правила “хорошего тона”:

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

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

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

Содержание