2 ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ НА ОСНОВЕ ER-МОДЕЛЕЙ

2.1 Понятие ER-модели

ER-модель, или ER-диаграмма (Entity – Relation; в русском переводе - модель “объект - отношение” или “сущность - связь”) предназначена для формализованного описания предметной области на этапе инфологического проектирования БД. Модель представляет собой графическое описание предметной области с использованием стандартизированного набора обозначений. На основе ER-модели по определенным правилам строится даталогическая модель для реализации в конкретной СУБД (для реляционных БД – набор таблиц и связей между ними). БД, построенная на основе ER-модели, обычно (но не всегда) находится в 4НФ. Тем не менее, необходимо проверять построенную БД на соблюдение правил нормализации.

Основные достоинства ER-моделей:

−наглядность;

−удобство для проектирования БД с большим количеством объектов (сущностей) и атрибутов;

−широкое применение в CASE-системах - системах автоматизированного проектирования БД (ERWin, Design/IDEF, Prokit*WORKBENCH и т.д.).

Основные элементы, входящие в состав ER-моделей:

−объекты (сущности);

−атрибуты (свойства) объектов;

−связи между объектами.

Правила построения ER-моделей и наборы обозначений, используемые в различных CASE-системах и приводимые в различных литературных источниках, имеют незначительные отличия. В данном пособии используется система обозначений, близкая к применяемой в CASE-системе Prokit*WORKBENCH [8], как наиболее наглядная (хотя наиболее распространенной в настоящее время, по-видимому, является система ERWin, рассматриваемая в разделе 3).

2.2 ER-модель объекта

Как уже отмечалось выше, под объектом (сущностью) понимается некоторый объект предметной области, имеющий свойства (атрибуты). Иногда используются понятия экземпляра объекта (экземпляр – конкретный объект, например, сотрудник, предприятие, изделие и т.д.) и класса объектов (класс включает все однотипные объекты, например, всех сотрудников предприятия, все предприятия отрасли или региона, все выпускаемые предприятием изделия и т.д.). Обычно под термином “объект” понимается экземпляр объекта.

Основные элементы ER-модели объекта рассмотрим на следующем примере. Пусть проектируется БД вуза. На рисунке 2.1 приведена ER-модель объекта “преподаватель”.

20

ПРЕПОДАВАТЕЛЬ

Табельный номер

ФИО Год рождения Образование

Адрес

Специальность

Кафедра

Должность Ученая степень Иностранный язык

Научный труд

Преподаваемый курс

Рисунок 2.1 – Пример ER-модели сущности

Здесь ПРЕПОДАВАТЕЛЬ – имя класса объектов. Атрибут Табельный номер – атрибут-идентификатор, т.е. атрибут, позволяющий однозначно отличить любой объект (в данном примере - конкретного преподавателя) от других объектов того же класса. Упрощенно говоря, атрибут, указанный в качестве идентификатора, будет ключевым атрибутом в БД. ФИО, Год рождения и т.д. – атрибуты, не являющиеся идентификаторами.

Имеются различные виды атрибутов объектов. Для них в ER-моделях используются разные обозначения, и они по-разному влияют на структуру создаваемой БД. На рисунке 2.1 показаны основные виды атрибутов:

− единичные и множественные атрибуты. Если объект может обладать только одним (точнее, не более чем одним) значением атрибута, то атрибут является единичным. Если объект может иметь одновременно несколько значений атрибута, то атрибут – множественный. Единичные атрибуты обозначаются одинарной стрелкой, множественные – двойной. В данном примере единичны-

ми являются атрибуты ФИО, Год рождения, Образование, Адрес, Специальность, Кафедра, Должность, Ученая степень: у любого преподавателя эти ат-

рибуты, по-видимому, могут иметь только одно значение (например, ФИО -

21

Иванов Петр Иванович, Год рождения – 1950, Образование – высшее, и т.д.).

Атрибуты Иностранный язык, Научный труд и Преподаваемый курс - множе-

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

−безусловные (обязательные) и условные (необязательные) атрибу-

ты. Если атрибут имеет некоторое значение для всех объектов, то он является безусловным, в противном случае – условным. Безусловные атрибуты обозначаются сплошной линией, условные – пунктирной. В данном примере услов-

ными являются атрибуты Ученая степень, Иностранный язык и Научный труд,

так как не все преподаватели имеют ученую степень, знают иностранные языки

иявляются авторами научных трудов. Остальные атрибуты - безусловные, так как, очевидно, любой преподаватель имеет ФИО, год рождения, преподаваемые курсы (хотя бы один) и т.д. Различие между безусловными и условными атрибутами в некоторых случаях влияет на дальнейшее проектирование БД;

−статические и динамические атрибуты. Атрибуты, значения которых,

как правило, не изменяются со временем, являются статическими, в противном случае – динамическими. Статические атрибуты обозначаются буквой S, динамические – буквой D. В данном примере атрибуты ФИО, Год рождения, Образование и Специальность – статические (вряд ли может измениться, например, год рождения), остальные – динамические. Различие между статическими и динамическими атрибутами обычно не влияет на проектирование структуры БД, поэтому во многих случаях обозначения S и D в ER-моделях не указывают. Тем не менее, желательно определять, является атрибут статическим или динамическим, так как это может учитываться при организации работы со спроектированной БД: например, для статических атрибутов внесение изменений может быть запрещено, или может быть предусмотрен запрос подтверждения при попытке изменения значений таких атрибутов.

На основе построенной ER-модели (т.е. инфологической модели) даталогическая модель (набор таблиц) строится следующим образом:

−все единичные атрибуты сводятся в одну таблицу. Ключом в такой таблице является атрибут-идентификатор;

−каждый множественный атрибут вместе с атрибутом-идентификатором выделяется в отдельную таблицу. Ключ в таких таблицах составной и состоит из обоих атрибутов (идентификатора и множественного атрибута).

Для примера, показанного на рисунке 2.1, даталогическая модель будет состоять из четырех таблиц, показанных на рисунке 2.2 (имена таблиц выбраны произвольно).

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

2.2 – 2.5.

22

Рисунок 2.5 – Даталогическая модель связи 1:1 с обязательным классом принадлежности для обоих объектов (первый вариант)

Рисунок 2.6 – Даталогическая модель связи 1:1 с обязательным классом принадлежности для обоих объектов (второй вариант)

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

В данном примере связь между автомобилями и водителями – 1:1 (одному водителю соответствует в точности один автомобиль, и наоборот). Класс принадлежности обязателен как для водителей (нет водителей, за которыми не закреплен автомобиль), так и для автомобилей (нет автомобилей, за которыми не закреплен водитель). ER-модель для данного примера приведена на рисунке 2.7, а возможные варианты даталогической модели – на рисунках 2.8 и 2.9.

Рисунок 2.7 – ER-модель для примера 2.3.1

Таблица ВОДИТЕЛИ

Рисунок 2.8 – Даталогическая модель для примера 2.3.1 (первый вариант)

26

Даталогическая модель для рассматриваемого случая может строиться двумя способами:

−если в одном из классов (или в обоих классах) количество объектов, не связанных с объектами другого класса, невелико, то даталогическую модель следует строить аналогично показанному в пункте 2.3.1. При этом, если в классе ОБЪЕКТ 1 имеется немного объектов, не связанных с объектами класса ОБЪЕКТЫ 2, то следует использовать даталогическую модель, аналогичную показанной на рисунке 2.5 (т.е. включить Идентификатор 2 в таблицу ОБЪЕКТЫ 1), в противном случае – использовать модель, аналогичную показанной на рисунке 2.6;

−если в обоих классах имеется много объектов, не связанных с объектами другого класса, то целесообразно построить три таблицы: по одной – для каждого из классов объектов, и третья – с атрибутами-идентификаторами объектов.

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

сдругом. Даталогическая модель для данного случая показана на рисунке 2.15.

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

Рисунок 2.15 – Даталогическая модель связи 1:1 с необязательным классом принадлежности для обоих объектов

Примечание – В таблице СВЯЗАННЫЕ ОБЪЕКТЫ в качестве ключевого может использоваться любой из атрибутов (как Идентификатор 1, так и Идентификатор 2).

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

снеобходимого языка).

Вданном примере связь между переводчиками и заказами – 1:1 (одному переводчику соответствует один выполняемый им заказ, и каждый заказ выдается одному переводчику). Класс принадлежности необязателен как для переводчиков (так как переводчики не всегда имеют заказы), так и для заказов (так как заказ может в течение некоторого времени ожидать переводчика). ER-

29

модель для данного примера приведена на рисунке 2.16. На рисунке 2.17 приведена даталогическая модель для случая, когда известно, что обычно имеется достаточно много свободных переводчиков, а заказы обычно распределены. На рисунке 2.18 приведена даталогическая модель для случая, когда известно, что количество свободных переводчиков и нераспределенных заказов одновременно может быть достаточно большим.

ПЕРЕВОДЧИК ЗАКАЗ

Рисунок 2.17 – Даталогическая модель для примера 2.3.3 (первый способ)

Таблица ПЕРЕВОДЧИКИ

Рисунок 2.18 – Даталогическая модель для примера 2.3.3 (второй способ)

Примечание – В таблице ПЕРЕВОДЫ в качестве ключевого может использоваться любой из атрибутов (как Табельный номер, так и Регистрационный номер).

30

2.3.4 Связь 1:M, обязательный класс принадлежности для многосвязного объекта

Общий вид ER-модели для такого случая показан на рисунке 2.19.

Рисунок 2.19 – ER-модель связи 1:M с обязательным классом принадлежности для многосвязного объекта

Рисунок 2.19 означает, что любой объект класса ОБЪЕКТ 1 может быть связан с несколькими объектами класса ОБЪЕКТ 2, а объект класса ОБЪЕКТ 2

– только с одним объектом класса ОБЪЕКТ 1. Здесь ОБЪЕКТ 1 называется од-

носвязным, а ОБЪЕКТ 2 – многосвязным.

Даталогическая модель для рассматриваемого случая строится следующим образом: составляются две таблицы, одна из которых содержит все атрибуты ОБЪЕКТА 1, другая – все атрибуты ОБЪЕКТА 2. При этом в таблицу с атрибутами многосвязного объекта включается атрибут-идентификатор односвязного объекта. Даталогическая модель для данного случая показана на рисунке 2.20.

Примечание. Класс принадлежности односвязного объекта в данном случае безразличен. Другими словами, даталогическая модель строится одинаково, независимо от того, обязателен или необязателен класс принадлежности для односвязного объекта.

Рисунок 2.20 – Даталогическая модель связи 1:M с обязательным классом принадлежности для многосвязного объекта

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

В данном примере связь между городами и аэропортами – 1:M (одному городу может соответствовать несколько аэропортов, но каждому аэропорту – в точности один город). Таким образом, город – односвязный объект, аэропорт – многосвязный. Класс принадлежности обязателен для аэропортов (каждый на-

31

ходится в некотором городе), но не обязателен для городов (в городе может не быть ни одного аэропорта). ER-модель для данного примера приведена на рисунке 2.21, а даталогическая модель – на рисунке 2.22.

Рисунок 2.22 – Даталогическая модель для примера 2.3.4

2.3.5 Связь 1:M, необязательный класс принадлежности для многосвязного объекта

Общий вид ER-модели для такого случая показан на рисунке 2.23.

Рисунок 2.23 – ER-модель связи 1:M с необязательным классом принадлежности для многосвязного объекта

Даталогическая модель для рассматриваемого случая может строиться двумя способами:

−если количество многосвязных объектов, не связанных с односвязными объектами, невелико, то даталогическую модель следует строить аналогично показанному в пункте 2.3.4;

−если количество многосвязных объектов, не связанных с односвязными объектами, достаточно велико, то целесообразно построить три таблицы: по одной – для каждого из классов объектов, и третья – с атрибутами-

32

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

Рисунок 2.24 – Даталогическая модель связи 1:M с необязательным классом принадлежности для многосвязного объекта

Примечание – В таблице СВЯЗАННЫЕ ОБЪЕКТЫ в качестве ключевого может использоваться только идентификатор многосвязного объекта.

Пример 2.3.5 Проектируется база данных, в которой должна храниться информация о расположенных в некотором регионе городах и газохранилищах. В городе может находиться как одно, так и несколько газохранилищ (или ни одного). Газохранилища могут находиться как в городах, так и вне городов.

В данном примере связь между городами и газохранилищами – 1:M (одному городу может соответствовать несколько газохранилищ, но каждому газохранилищу – не более одного города). Таким образом, город – односвязный объект, газохранилище – многосвязный. Класс принадлежности необязателен ни для газохранилищ (газохранилище может находиться не в городе), ни для городов (в городе может не быть ни одного газохранилища). ER-модель для данного примера приведена на рисунке 2.25. На рисунке 2.26 приведена даталогическая модель для случая, когда значительное большинство газохранилищ находится в городах, на рисунке 2.27 – для случая, когда имеется много газохранилищ вне городов.

Рисунок 2.25 – ER-модель для примера 2.3.5

33

Рисунок 2.26 – Даталогическая модель для примера 2.3.5 (первый способ)

Таблица ГОРОДА

Рисунок 2.27 – Даталогическая модель для примера 2.3.5 (второй способ)

2.3.6 Связь M:M

Общий вид ER-модели для такого случая показан на рисунке 2.28.

Рисунок 2.28 – ER-модель связи M:M

Примечание – Класс принадлежности объектов в данном случае безразличен.

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

34

Рисунок 2.29 – Даталогическая модель связи M:M

Примечание – В таблице СВЯЗАННЫЕ ОБЪЕКТЫ ключ составной, включающий оба атрибута-идентификатора.

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

В данном примере связь между цехами и материалами – M:M (каждый материал может использоваться в нескольких цехах, и в каждом цехе может использоваться несколько материалов). Класс принадлежности для цеха обязателен (в каждом цехе используется хотя бы один вид материалов), для материалов

– необязателен (в БД могут храниться данные о материалах, не используемых на предприятии в данный момент). ER-модель для данного примера приведена на рисунке 2.30, а даталогическая модель – на рисунке 2.31.

Рисунок 2.31 – Даталогическая модель для примера 2.3.6

35

2.3.7 Связь M:M с атрибутами

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

Атрибут С1

Атрибут С2

Рисунок 2.32 – ER-модель связи M:M с атрибутами

Примечание – В литературе по проектированию БД связь, имеющая атрибуты, часто рассматривается как специальный объект, называемый “агрегированным объектом” [1].

Даталогическая модель для рассматриваемого случая содержит три таблицы: по одной – для каждого из классов объектов, и третья – с атрибутамиидентификаторами объектов и атрибутами связи. Даталогическая модель для данного случая показана на рисунке 2.33.

Рисунок 2.33 – Даталогическая модель связи M:M с атрибутами

Пример 2.3.7 Проектируется база данных производственного предприятия (см. пример 2.3.6). Требуется хранить данные о цехах предприятия и о используемых материалах, в том числе о величине расхода каждого материала в каждом цеху и о периодичности пополнения запаса каждого материала в каждом цеху.

В данном примере связь между цехами и материалами – M:M. При этом величины расхода материалов и периодичности пополнения их запасов являют-

36

ся атрибутами связи между цехами и материалами. ER-модель для данного примера приведена на рисунке 2.34, а даталогическая модель – на рисунке 2.35.

Расход

Периодичность

Рисунок 2.34 – ER-модель для примера 2.3.7

Рисунок 2.35 – Даталогическая модель для примера 2.3.7

37