Диго С.М. Базы данных проектирование и использование (1084447), страница 21
Текст из файла (страница 21)
Как мы видели, в Design/IDEF набор выразительных средств, предоставляемых для построения ER-модели, невелик.
Основным элементом модели является сущность (Entity). Сущность имеет имя. Для сущностей описываются их атрибуты. Атрибут может играть роль первичного ключа (Primary Key), альтернативного ключа (Alternate Key), дискриминатора (Discriminator) и инверсного входа (Inversion Entry) либо не играть ни одну из них. Как видно, во-первых, эти характеристики атрибутов отражают совершенно разные аспекты как предметной области, так и организации данных; во-вторых, некоторые из этих показателей жестко привязаны к реляционной модели (понятия первичного и альтернативного ключа); в-третьих, выбор большинства характеристик должен являться результатом проектных решений, обычно выполняемых на основе анализа разнообразных факторов; в-четвертых, ряд характеристик, которые можно отобразить в базовой ER-модели, с которой будет идти дальнейшее сравнение, в методологии IDEF1X в явном виде отобразить нельзя.
В Design/IDEF при преобразовании ER-модели в описание целевой базы данных каждому объекту ставится в соответствие таблица реляционной базы данных.
В Design/IDEF нет изобразительных средств для обозначения множественного свойства, составного свойства, нельзя показать, что свойство может присутствовать не у всех экземпляров объектов, нет понятия агрегированного объекта, нет изобразительного средства для отображения альтернативной связи («арк»). Все это нужно отобразить, пользуясь имеющимися в наличии изобразительными средствами.
При построении ER-модели в Design/IDEF предлагается придерживаться следующих рекомендаций.
Если простой объект имеет несколько возможных идентификаторов, то из них следует выбрать тот, который будет использоваться в качестве первичного ключа таблицы, и описать его как Primary Key. Рекомендации по выбору первичного ключа реляционной таблицы изложены в разд. 3.3.
Для остальных возможных идентификаторов надо определить, есть ли необходимость проверять их уникальность в процессе ведения базы данных. Те идентификаторы, для которых это необходимо делать, нужно обозначить как Alternate Key (AK).
Если объект имеет неуникальное имя (например, ФИО для сущности ЛИЧНОСТЬ), то его следует описать как Inversion Entry (IE), поскольку имя часто используется для поиска. В качестве инверсных входов могут быть описаны и другие атрибуты. Для того чтобы определить, для каких атрибутов нужно задавать свойство Inversion Entry, необходимо проанализировать характер запросов к создаваемой таблице: если по данному атрибуту ожидается частый выборочный поиск или требуется сортировка, то этот атрибут следует описать как инверсный вход. Так как альтернативных ключей и инверсных входов может быть несколько, то при описании соответствующего атрибута надо указать порядковый номер АК или IE.
При наличии у объекта множественных свойств нужно каждому из множественных свойств поставить в соответствие отдельную сущность. Название множественного свойства следует определить как ключевой атрибут. Затем надо связать идентифицирующей связью, направленной от основной сущности ко вновь созданной сущности, эти элементы модели (рис. 2.62).
Рис. 2.62. Отображение единичных, множественных и составных
свойств (переход от базовой модели к IDEF1X:
а - простой объект (базовая ER-модель);
б - вариант 1 отображения объекта в IDEF1X; в - вариант 2
Поскольку в Design/IDEF нет возможности отображать составные свойства, то проектировщик должен принять решение, как это составное свойство будет храниться в базе данных. В зависимости от принятого решения нужно либо описать это составное свойство как один атрибут, либо каждый из составляющих его элементов описать как отдельный атрибут. На рис. 2.62, б изображено второе из названных решений. Если использовать первое решение, то вместо атрибутов С7 , C8 следовало бы описать атрибут С6 (рис. 2.62, в).
Отсутствие понятия «условное свойство» приводит к сложностям при моделировании предметной области. Возможны несколько вариантов выхода из сложившейся ситуации.
1. Никак в ER-модели не отражать, что свойство условное, и описывать его как обычный атрибут (такое решение изображено на рис. 2.62,6).
2. В соответствие условному свойству ставится отдельная сущность, которая идентифицирующей связью соединяется с основной сущностью. При этом тот факт, что свойство является условным, передается путем выбора соответствующего типа кардинальности связи (такое решение изображено на рис. 2.62, в).
3. Объект, содержащий условные свойства, отображать как обобщенный. Каждому условному свойству будет соответствовать категория объектов. Этот вариант использован на рис. 2.61, когда условному свойству «Звание_ученое» был поставлен в соответствие видовой объект ИМЕЮЩИЕ_ЗВАНИЕ.
Каждый из вариантов имеет свои недостатки. Выбор варианта будет зависеть от выбранного проектного решения по структуре БД.
Для отображения обобщенного объекта в Design/IDEF имеются специальные изобразительные средства. При изображении обобщенного объекта то свойство, по которому проводится разбиение класса на подклассы, обозначается как дискриминатор. Каждому дискриминатору на схеме соответствует специальный знак. После этого каждому подклассу ставится в соответствие отдельная сущность, в которой перечисляются атрибуты, присущие этому подклассу. Ключ видовых сущностей при описании указывать не нужно. Далее от дискриминатора к видовым сущностям протягивается связь. При этом происходит автоматическая миграция ключа. Подчиненные сущности становятся, таким образом, зависимыми от идентификации сущностями (рис. 2.63).
Рис. 2.63. Изображение обобщенного объекта: а - фрагмент базовой
ER-модели; б - отображение в IDEF1X
В Design/IDEF можно отобразить многоаспектную и многоуровневую классификацию объектов.
Для изображения агрегированных объектов в Design/IDEF не предусмотрено никаких специализированных изобразительных средств. Агрегированные объекты (процессы) в Design/IDEF следует отображать следующим образом (рис.2.64):
1)создать сущность, соответствующую данному объекту;
2)соединить ее идентифицирующими связями с сущностями, участвующими в данном процессе;
3)если для полной идентификации изображаемой сущности мигрировавших ключей оказывается недостаточно, то дополнительные атрибуты при их описании нужно задать как первичный ключ;
4) описать остальные атрибуты.
Рис. 2.64. Отображение агрегированного объекта
в базовой ER-модели (а) и в IDEF1X (б)
На рис. 2.65 изображен агрегированный объект УСПЕВАЕМОСТЬ. Атрибут «Дата» описан как первичный ключ. «Код_студента» и «Код_предмета» мигрируют в сущность УСПЕВАЕМОСТЬ при установлении соответствующих связей.
Рис. 2.65. Агрегированный объект УСПЕВАЕМОСТЬ
Из вышеизложенного следует, что механизм установления идентифицирующей связи используется часто, и не только в случаях, когда в предметной области реально существует такая идентификация (например, когда нумерация участков ведется внутри каждого цеха и в тому подобных ситуациях), но и при обходе ограничений Design/IDEF, когда приходится вводить дополнительные объекты, или при изображении агрегированных объектов в виде обычной сущности в модели Design/IDEF.
Для определения связи в Design/IDEF надо комбинировать возможности, задаваемые в Relationship Type и Relationship Cardinality.
Идентифицирующая (Identifying) и неидентифицирующая (Non-Identifying) связи в общем случае соответствуют отношению 1:М. Если надо указать, что связь 1:1, то можно для Relationship Cardinality этой связи указать Exactly 1 (рис. 2.66).
Рис. 2.66. Отображение связи 1:1 в базовой модели (а) и в IDEF1X(б)
Множественная связь называется в Design/IDEF неспецифической (Non-Specific) (рис. 2.67). Так как алгоритм проектирования БД в Design/IDEF не обеспечивает автоматического преобразования связей М:М, то перед генерацией описания БД необходимо устранить неспецифические связи и преобразовать их в специфические. Для этого нужно ввести дополнительную связующую сущность. Никаких атрибутов для нее определять не надо. Далее следует связать вновь введенную сущность с ранее существовавшими объектами идентифицирующей связью. В результате получится схема, изображенная ни рис. 2.67, в.
Рис. 2.67. Отображение связи М:М в базовой модели (а);
в IDEF1X - неспецифическая связь (б);
преобразование неспецифической связи в специфические (в)
Соответствие базовой модели и модели Design/IDEF при изображении идентифицирующей связи отображено на рис. 2.68, а неидентифицирующей - на рис. 2.69.
Рис. 2.68. Отображение идентифицирующей связи в
базовой модели (а) и в IDEF1X (б)
Рис. 2.69. Отображение связи 1:М (неидентифицирующая связь, обязательный класс членства с обеих сторон) в базовой модели (а)
и в IDEFIX(б)
В базовой модели для характеристики связи используются три независимые характеристики:
1) тип связи (один к одному (1:1), один ко многим (1:М) и многие ко многим (М:М));
2) класс принадлежности (обязательный и необязательный);
3) зависимость по идентификации (зависимая и не зависимая по идентификации сущности).
В Design/IDEF выделяют две группы характеристик: Relationship Туре и Relationship Cardinality. В связи с этим не все сочетания, которые можно передать в базовой модели, удается отобразить в Design/IDEF. На рис. 2.70 представлено соответствие конструкций базовой модели и Design/IDEF1X при изображении типа связей и класса принадлежности. В Design/IDEF при задании неспецифической связи кардинальность связи указать нельзя. Поэтому в Design/IDEF нельзя отобразить ситуации, когда при связи М:М наблюдается необязательный класс принадлежности со стороны одной из сущностей или со стороны обеих сущностей. Кроме того, в Design/IDEF нет возможности отобразить класс принадлежности сущностей, к которым направлена связь.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
