П. Г. Демидова А. В. Зафиевский А. А. Короткин А. Н. Лататуев Базы данных Учебное пособие

5.3. Концептуальные и физические ER­модели 
Разработанный выше пример ER-диаграммы является приме-
ром концептуальной диаграммы. Это означает, что диаграмма 
не учитывает особенности конкретной СУБД. По данной кон-
цептуальной диаграмме можно построить физическую диаграм-
му
, которая уже будут учитываться такие особенности СУБД, как 
допустимые типы и наименования полей и таблиц, ограничения 
целостности и т. п.
Правила преобразования ER-диаграммы в физическую 
модель следующие. 
1. Каждой сущности ставится в соответствие отношение ре-
ляционной модели данных (таблица). При этом имена сущности и 
отношения могут быть различными, потому что на имена сущ-
ностей обычно не накладываются синтаксические ограничения, 
кроме уникальности. Имена отношений (таблиц) могут быть 

---

121 
ограничены требованиями конкретной СУБД, чаще всего эти 
имена являются идентификаторами в некотором базовом языке, 
они ограничены по длине и не должны содержать пробелов и 
некоторых специальных символов. 
2. Каждый атрибут сущности становится атрибутом соответ-
ствующего отношения. Для каждого атрибута задается конкрет-
ный допустимый в СУБД тип данных и обязательность или 
необязательность данного атрибута (т. е. допустимость или 
недопустимость null-значений). 
3. Первичный ключ сущности становится первичным ключом 
(PRIMARY KEY) соответствующего отношения. Атрибуты 
первичного ключа автоматически получают свойство обязатель-
ности (NOT null). 
4. В каждое отношение, соответствующее подчиненной сущ-
ности, включается набор атрибутов главной сущности, являю-
щийся первичным ключом главной сущности. В отношении, 
соответствующем подчиненной сущности, этот набор атрибутов 
становится внешним ключом (FOREING KEY).
5. При моделировании необязательного типа связи (модаль-
ность «может») у атрибутов, соответствующих внешнему ключу, 
устанавливается свойство допустимости null-значений. При обя-
зательном типе связи атрибуты получают свойство отсутствия 
неопределенных значений (NOT null). 
Физический вариант диаграммы, приведенной на рис. 5.10, 
может выглядеть, например, следующим образом. 
На данной диаграмме каждая сущность представляет собой 
таблицу базы данных, каждый атрибут становится колонкой соот-
ветствующей таблицы. Обращаем внимание на то, что во многих 
таблицах, например, «CUST_DETAIL» и «PROD_IN_SKLAD», 
соответствующих сущностям «Запись списка накладной» и 
«Товар на складе», появились новые атрибуты, которых не было 
в концептуальной модели, – это ключевые атрибуты главных таб-
лиц, в соответствии с правилом 4 мигрировавших в подчиненные 
таблицы для того, чтобы обеспечить связь между таблицами 
посредством внешних ключей.
Легко заметить, что полученные таблицы сразу находятся 
в 3НФ. 

---

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