Метод моделирования "сущность-связь"

Нормализация модели "сущность-связь"

Имеются 3 подуровня логического уровня модели данных, отличающихся по глубине представления информации о данных:

• диаграмма "сущность-связь" (Entity Relationship Diagram, ERD);
• модель данных, основанная на ключах (Key Based model, KB);
• полная атрибутивная модель (Fully Attributed model, FA).

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

Модель данных, основанная на ключах, – более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.

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

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

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

Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных. Известно 6 нормальных форм:

• первая нормальная форма (1NF) ;
• вторая нормальная форма (2NF) ;
• третья нормальная форма (3NF) ;
• нормальная форма Бойса-Кодда (усиленная 3NF);
• четвертая нормальная форма (4NF) ;
• пятая нормальная форма (5NF).

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

Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин "зависимость"). Приведем формальное определение для функциональной зависимости.

Функциональная зависимость (FD). Атрибут B сущности E функционально зависит от атрибута A сущности E тогда и только тогда, когда каждое значение A в E связало с ним точно одно значение B в E, т. е. A однозначно определяет B.

Полная функциональная зависимость. Атрибут B сущности E полностью функционально зависит от ряда атрибутов A сущности E тогда и только тогда, когда B функционально зависит от A и не зависит ни от какого подмножества атрибутов A.

Рис. 6.15. Ненормализованная сущность "Сотрудник"

На рис. 6.15 в сущности "Сотрудник" значения атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибуты Фамилия, Имя и Отчество зависят от атрибута Табельный номер.

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

Рассмотрим нормальные формы.

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

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

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

Для приведения сущности к первой нормальной форме следует:

• разделить сложные атрибуты на атомарные;
• создать новую сущность;
• перенести в нее все "повторяющиеся" атрибуты;
• выбрать возможный ключ для нового PK (или создать новый PK);
• установить идентифицирующую связь от прежней сущности к новой, PK прежней сущности станет внешним ключом (FK) для новой сущности.

На рис. 6.16 показана сущность "Сотрудник", приведенная к первой нормальной форме.

Рис. 6.16. Сущность "Сотрудник", приведенная к первой нормальной форме

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

Рис. 6.17. Сущность "Проект"

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

Для приведения сущности ко второй нормальной форме следует:

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

Рис. 6.18. Сущность "Проект", приведенная ко второй нормальной форме

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

• обновления (UPDATE). Происходит дублирование данных о сотруднике, если он руководит несколькими проектами. Если данные о сотруднике изменяются, необходимо менять несколько записей (по числу ведомых проектов);
• вставки (INSERT). Невозможно ввести данные о сотруднике, если он в данный момент не руководит проектами;
• удаления (DELETE). Если сотрудник временно прекращает руководство проектами, данные о нем теряются.

На рис. 6.18 показана сущность "Проект", приведенная ко второй нормальной форме.

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

На рис. 6.16 сущность "Сотрудник" находится во второй нормальной форме (имеется только один атрибут первичного ключа, поэтому не может быть зависимости неключевых атрибутов от части ключа), но неключевой атрибут Оклад зависит от другого неключевого атрибута – Должности.

Для приведения сущности к третьей нормальной форме следует:

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

увеличить изображение
Рис. 6.19. Сущность "Сотрудник", приведенная к третьей нормальной форме

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

Третья нормальная форма также позволяет избежать ряда аномалий.

• Обновление (UPDATE). Происходит дублирование данных об окладе, если должность занимают несколько сотрудников. Если оклад, соответствующий должности, меняется, необходимо менять несколько записей (по числу сотрудников на одной должности).
• Вставка (INSERT). Невозможно ввести данные об окладе, соответствующем должности, если в данный момент нет сотрудника, занимающего эту должность.
• Удаление (DELETE). В случае удаления из таблицы сотрудника, занимающего уникальную должность, данные об окладе теряются.

Четвертая нормальная форма (4NF) требует отсутствия многозначных зависимостей между атрибутами.

В примере на рис. 6.20 (слева) преподаватель читает лекции по нескольким предметам и курирует несколько групп студентов. Одна группа студентов может изучать несколько предметов, одному предмету могут обучаться несколько групп студентов. Имеется многозначная зависимость между атрибутами Предмет и Группа. При этом возможна аномалия: если у преподавателя появляется новая группа, приходится добавлять несколько записей, по числу читаемых предметов.

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

Рис. 6.20. Иллюстрация четвертой нормальной формы

Резюме

Метод моделирования "сущность-связь" был предложен С. Ченом в 1976 году. Ряд исследователей разработали несколько графических нотаций для представления элементов модели. Проектировщик ХД может выбрать графическую нотацию по своему вкусу.

Применение метода моделирования "сущность-связь" помогает проектировщикам создать логическую модель предметной области, не зависимую от программно-аппаратной реализации. Этот метод используется как при моделировании предметных областей OLTP-систем, так и при моделировании предметных областей BI-систем. Знание этого метода помогает проектировщику ХД быстрее установить логические связи между моделями БД OLTP-систем масштаба организации и моделями ХД BI-систем.

Независимо от выбранной нотации, действия проектировщика ХД при ER-моделировании сводятся к следующему алгоритму.

Для каждой сущности предметной области базы данных необходимо:

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

Для каждой связи между сущностями необходимо:

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