Информатика и выч. техника \ Безопасность систем баз данных

Введение в дисциплину «Безопасность систем баз данных». Теоретические основы построения реляционных баз данных. Верификация баз данных и проведение аудита в СБД. Распределенные базы данных, страница 11

 


Рисунок 2.8 – Диаграмма, изображающая две связи между сущностями СОТРУДНИК и ОТДЕЛ

Связь «руководит» -- это связь 1:1, а «работает в» -- M:1 (или 1:N). На рисунке 2.9 показан пример связи M:N между сущностями СОТРУДНИК и ПРОЕКТ.

 


Рисунок 2.9 – Связь многие-ко-многим

Часто на ER-диаграммах показывается кардинальность связи, или классы принадлежности сущностей к данной связи. Так, у любого отдела обязан быть руководитель, но не каждый сотрудник руководит каким-либо отделом. Это показывается следующим образом (рис. 2.10): СОТРУДНИК имеет обязательный класс принадлежности связи «руководит», а ОТДЕЛ – необязательный.

 


Рисунок 2.10 – Пример изображения кардинальности связи

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

Создание ER-модели начинается с выявления сущностей и связей, после чего определяются их конкретные атрибуты. Очень важно, чтобы атрибуты были определены правильно. Неформальным критерием правильности является следующий критерий: атрибут должен отражать одно из неотъемлемых свойств именно той сущности или связи, к которой он приписан. К примеру, номер студенческого билета не может быть атрибутом сущности ФАКУЛЬТЕТ: он характеризует только студента, а не факультет и не учебную группу. Значение атрибута характеризует конкретный экземпляр сущности или связи. Когда произносится фамилия «Иванов», то ясно, что речь идет о человеке, а не о предприятии; именно поэтому недопустимо для сущности ПРЕДПРИЯТИЕ определять атрибут «фамилия_директора». Директор предприятия – это отдельная сущность, предприятие – тоже отдельная сущность. Связь между этими сущностями показывает, что директора руководят предприятиями.

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

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

Таблица 2.1 – Правила порождения реляционной схемы из модели «сущность-связь»

Тип связи

Пример связи

Правило построения отношений

Отношения

(1,1):(1,1)

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


Продолжение таблицы 2.1

(1,1):(0,1)

(1,1):(0,N)

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

В некоторых случаях требуется указывать дополнительные ограничения целостности, а именно:

  • (1,1):(0,1) – UNIQUE и NOT NULL для внешнего ключа;
  • (1,1):(0,N) – NOT NULL для внешнего ключа;
  • (0,1):(0,1) – UNIQUE для внешнего ключа;

Случай (0,1):(1,N) является нетривиальным. Для точного отражения данного типа связи в БД необходимо использовать дополнительные механизмы обеспечения целостности БД (ограничения общего вида, триггеры), о которых будет говориться в отдельной главе конспекта.

(0,1):(0,1)

(0,1):(0,N)
(0,1):(1,N)


Продолжение таблицы 2.1

M : N

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

Скачать файл