1626434812-e667f6b6e7e69d3a0798830a58e9075b (844135), страница 22
Текст из файла (страница 22)
Если рассматривать диаграмму как графическое представление правил предметной области, то сущности являются существительными, а связи — глаголами. Например, между сущностями ОТДЕЛ и СОТРУДНИК существует связь "состоит из" (ОТДЕЛ состоит из СОТРУДНИКов). В Ейччп связи представлены пятью основными элементами информации: тип связи; ° родительская и дочерняя (зависимая) сущности; ° мощность связи; допустимость пустых (ппП) значений; ° требования по обеспечению ссылочной целостности.
Глава 5. Семантическое моделирование в базах данных ЕКъчп поддерживает следующие основные типы связей: идентифицирующая, неидентифицирующая, полная категория, неполная категория, многие-комногим. Связь называется идентифицирующей, если экземпляр дочернеи сущности идентифицируется через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности.
Дочерняя сущность при идентифицирующей связи всегда является зависимой. Связь называется неидвнтифииирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав неключевых атрибутов дочерней сущности. Идентифицирующая связь изображается сплошной линией; неидентифицирующая — пунктирной линией.
Линии заканчиваются точкой со стороны дочерней сущности. При определении связи происходит миграция атрибутов первичного ключа родительской сущности в соответствующую область атрибутов дочерней сущности. Поэтому такие атрибуты не вводятся вручную. На рис. 5.6,3. приведен пример неидентифицируюшей связи.
Первичный ключ сущности ОТДЕЛ "номер отдела" мигрировал в область неключевых атрибутов (поскольку связь нсидентифицирующая) сущности СОТРУДНИК. На диаграмме атрибуты, наследованные от родительской сущности, помечаются символами РК, заключенными в скобки. СОТРУДНИК ОТДЕЛ состоит из Рис, 5,6.3. Пример иеидеитифииирующей связи Зависимая сущность может наследовать один и тот же атрибут от более чем одной родительской сущности или от одной и той же родительской сущности через несколько связей.
Базы данных. Интеллектуальная обработка информации Поскольку атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами, Ейлчп считает, что в зависимой сущности атрибуты внешнего ключа появляются толью один раз. Чтобы избежать этого ограничения, ЕКъчп позволяет ввести для них роли, т.е. новые имена, под которыми мигрирующие атрибуты будут представлены в дочерней сущности.
В случае неоднократной миграции атрибута такое переименование необходимо. Напримср, при создании модели сделки по обмену валюты сущность СДЕЛКА (рис. 5,6.4) должна иметь два различных атрибута для кодов проданной и купленной валюты. В данном случае первичный ключ сущности ВАЛЮТА ("код валюты") имеет две роли в дочерней сущности. ВАЛЮТА продается покупается Рис. 5.6.4. Пример исяользовоиия ролей Ситуация, когда экземпляру одной сущности соответствует один или несколько экземпляров второй сущности, а экземпляру второй сущности соответствует один или несколько экземпляров первой сущности, отражается в логической модели связью многие-ко-многим между данными сущностями.
На диаграмме связь изображается сплошной линией с точками на концах. Например, для заключения сделки в некоторой фирме клиент обращается к любому из свободных сотрудников этой фирмы. В то же время сотрудник фирмы может обслуживать нескольких клиентов. Поэтому тип связи между сущностями КЛИЕНТ и СОТРУДНИК должен быть многие-ко-многим (рис. 5.б.5).
Рис. 5.б.5. Пример связи лтогие-ко-.ьиюгиы Заметим, что связь типа многие-ко-многим возможна толью па логическом уровне. Преобразование связи данного типа на физическом уровне будет рассмотрено в следующем пункте. Однако добавим, что связей многие-ко-многим рекомендуется избегать. В рассмотренном примере этого можно добиться, если ввести дополнительную сущность СДЕЛКА. булава 5. Семантическое моделирование в базах данных бслукивеет о заключает кликнт Рис. 5.б.6.
Прииер устранения сети мпогие-ко-многим Некоторые сущности определяют целую категорию объектов одного типа. В ЕЮип в таком случае создается сущность для определения категории и для каждого элемента категории, а затем вводится для них связь категоризации. Родительская сущность категории называется сунертипом, а дочерние — нодтином. Общая часть атрибутов сущностей-подтипов, включая первичный ключ, помещается в сущность-супертип. Различная часть (например, данные о почасовой оплате для временных работников или данные о зарплате и отпуске для штатных работников) помещается в сущности-подтипы. В сущности-супертипе вводится атрибут-дискриминатор, позволяющий различать конкретные экземпляры сущности-подтипа. В зависимости от того, все ли возможные сущности-подтипы включены в модель, категорийная связь является полной или ленолной.
В ЕКжш полная категория изображается окружностью с двумя подчеркиваниями, а неполная— окружностью с одним подчеркиванием. На рис. 5.6.7. категорийная связь между сущностью СОТРУДНИК и сущностями ПОСТОЯННЫЙ СОТРУДНИК и СОВМЕСТИТЕЛЬ является неполной, если предположить, что существует еще один тип сотрудников — консультант. сотРудник ', ~ тип ПОСТОЯННЫЙ СОТРУДНИК совместитель Рис. 5.6.7. Ири.иер непсиной категории Базы данных.
Интеллектуальнан обработка информации Включение в модель сущности КОНСУЛЬТАНТ приводит к тому, что категорийная связь становится полной (рис 5.6.8). Рис. 5.б.8. Пример виной категории Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Мощность связи определяется только для идентифицируюших и неидентифицируюших связей и записывается как 1:и. ЕКит, в соответствии с методологией 10ЕН Х, предоставляет 4 варианта для и, которые изображаются дополнительным символом у дочерней сущности (рис.
5.6.9) О, 1 или больше (по умолчанию) 1 или больше Оили1 ровно 1ч (3). 3 Рис. 5.б.9. Обозначение кратности связи Допустимость пустых (МЛЛ ) значений в неидентифицирующих связях ЕКъчп изображает пустым ромбиком на дуге связи со стороны родительской сущности (рис.
5.6.3). Глава 5. Семантическое моделирование в базах данных В целях контроля ссылочной целостности (под ссьиочной цвлосогаоапью в ЕКччп понимается обеспечение требования, чтобы значения внешнего ключа экземпляра дочерней сущности соответствовали значениям первичного ключа в родительской сущности) для каждой связи могут быть заданы требования по обработке операций ПЧЗЕЙТФРРАТЕ/РЕ1 ЕТЕ для родительской и дочерней сущности.
ЕЮнп предоставляет следующие варианты обработки этих событий: отсутствие проверки; ° проверка допустимости; ° запрет операции; каскадное выполнение операции (РЕЬЕТЕЛЗРРАТЕ); ° установка пустого (МЯЛ.-значения) или заданного значения по умолчанию. 5.6.4. Создание физической модели и генерация схемы Бд Для создания физической модели данных, разработчику необходимо выбрать конкретную СУБД и переключиться на физический уровень отображения диаграммы. На уровне физической модели сущности соответствует таблица в реальной СУБД, атрибуту — колонка таблицы, связи — внешний ключ 1если для связи задавалось имя роли, то оно соотвстствует имени колонки внешнего ключа в дочерней таблице), первичным и альтернативным ключам — уникальные индексы, а инверсным входам — неуникальные.
Ейлип автоматически присваивает имена элементов логической модели элементам физической схемы, исходя из приведенных выше соотношений. Т.о. разработчику нет необходимости проделывать это вручную. Однако если модель разрабатывалась на русском языке, то имена таблиц, колонок и индексов необходимо задать на английском языке.
При этом сами имена сущностей, атрибутов, связей и ролей могут оставаться без изменения. Для каждой колонки разработчик должен указать тип данных, возможность пустых значений, значения по умолчанию и т.п. в зависимости от используемой СУБД. Например, логической модели, представленной на рис.
5.6 З„будет соответствовать физическая модсль, изображенная на рис, 5.6.10. При переходе на уровень физической модели происходит автоматическая развязка связей "многие-ко-многим". Так, для логической модели приведенной на рис. 5.6.5, будет создана следующая физическая модель (рис 5.6.11). Последним шагом на этапе создания физической модели данных является написание триггеров и хранимых процедур. Этот шаг является необязательным, т.к.