Другие нормальные формы

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

Пример нормализации таблицы

Ниже приведен пример нормализации таблицы с вымышленными данными о студентах. 

1. Таблица до нормализации: 

   Student#	Advisor	Adv-Room	Class1	Class2	Class3
   1022	Петров	412	101-07	143-01	159-02
   4123	Иванов	216	201-01	211-02	214-01

2. Первая нормальная форма: устранение повторяющихся групп Таблицы должны иметь только два измерения. Так как один студент изучает несколько курсов, эти курсы следует указать в отдельной таблице. Наличие полей Class1, Class2 и Class3 в приведенных выше записях свидетельствует о неудачном проектировании таблицы.  Электронные таблицы часто включают третье измерение, но в таблицах баз данных оно использоваться не должно. Рассмотреть эту проблему можно также с помощью отношения «один — множество», тогда совет можно сформулировать следующим образом: не включайте в одну таблицу элементы, представляющие обе стороны данного отношения. Вместо этого создайте другую таблицу в первой нормальной форме, устранив повторяющуюся группу (Class#):

   Student#	Advisor	Adv-Room	Class#
   1022	Петров	412	101-07
   1022	Петров	412	143-01
   1022	Петров	412	159-02
   4123	Иванов	216	201-01
   4123	Иванов	216	211-02
   4123	Иванов	216	214-01

3. Вторая нормальная форма: устранение избыточных данных Обратите внимание на то, что в приведенной выше таблице каждое значение Student# сопоставлено с несколькими значениями Class#. Значения Class# функционально не зависят от значений Student# (первичный ключ), а это означает, что данное отношение не нормализовано до второй нормальной формы. Вторую нормальную форму представляют две следующих таблицы.  Таблица Students:

   Student#	Advisor	Adv-Room
   1022	Петров	412
   4123	Иванов	216

4. Таблица Registration:

   Student#	Class#
   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-01

5. Третья нормальная форма: устранение данных, не зависящих от ключа В последнем примере значения Adv-Room (номер кабинета научного руководителя) функционально зависят от атрибута Advisor. Решить эту проблему можно, переместив данный атрибут из таблицы Students в таблицу Faculty (факультет): Таблица Students:

   Student#	Advisor
   1022	Петров
   4123	Иванов

6. Таблица Faculty:

Name	Room	Dept
Петров	412	42
Иванов	216	42

ER-модель

ER-модель (от англ. entity-relationship model, модель «сущность — связь») — модель данных, позволяющая описывать концептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма «сущность-связь» (англ. entity-relationship diagram, ERD, ER-диаграмма).

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

Модель была предложена в 1976 году Питером Ченом^[1][2], им же предложена и самая популярная графическая нотация для модели.

Графические нотации (диаграммы)[править | править вики-текст]

Нотация Чэня[править | править вики-текст]

Простая ER-модель MMORPG с использованием нотации Чэня

Множества сущностей изображаются в виде прямоугольников, множества отношений изображаются в виде ромбов. Если сущность участвует в отношении, они связаны линией. Если отношение не является обязательным, то линия пунктирная. Атрибуты изображаются в виде овалов и связываются линией с одним отношением или с одной сущностью.^[3]

Crow’s Foot[править | править вики-текст]

Пример отношения между сущностями согласно нотации Crow’s Foot

Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest) под названием Inverted Arrow («перевёрнутая стрелка»), однако сейчас чаще называемая Crow’s Foot («воронья лапка») или Fork («вилка»)^[4].

Согласно данной нотации, сущность изображается в виде прямоугольника, содержащего её имя, выражаемое существительным^[5]. Имя сущности должно быть уникальным в рамках одной модели. При этом, имя сущности — это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Связь изображается линией, которая связывает две сущности, участвующие в отношении. Степень конца связи указывается графически, множественность связи изображается в виде «вилки» на конце связи. Модальность связи так же изображается графически — необязательность связи помечается кружком на конце связи. Именование обычно выражается одним глаголом^[5] в изъявительном наклонении настоящего времени: «Имеет», «Принадлежит» и т. д.; или глаголом с поясняющими словами: «Включает в себя», и т. п. Наименование может быть одно для всей связи или два для каждого из концов связи. Во втором случае, название левого конца связи указывается над линией связи, а правого — под линией. Каждое из названий располагаются рядом с сущностью, к которой оно относится.

Атрибуты сущности записываются внутри прямоугольника, изображающего сущность, и выражаются существительным в единственном числе (возможно, с уточняющими словами). Среди атрибутов выделяется ключ сущности — неизбыточный набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности.^[5]