Проектирование баз данных с использованием методологии IDEF1X

Стандарт, описывающий методологию проектирования IDEF1X, был разработан в США в 1993 г. Он уточняет предшествующую версию

IDEF1 и является частью семейства стандартов IDEF (от англ. Integration Definition Methodology), к которому также относятся стандарты на методологию функционального моделирования систем IDEF0, моделирования динамически изменяющихся систем IDEF2 и ряд других.

Методология IDEF1X разрабатывалась для создания информационных моделей, представляющих структуру данных, описывающих предприятие или другую предметную область. Подобные модели также называют концептуальными.

Поддерживающие IDEF1X программные средства, такие как ERwin Data Modeler, позволяют построить независимую от СУБД логическую модель БД и по ней создать физическую модель для реализации в среде конкретной СУБД. При этом появляется возможность уже на ранних этапах проектирования системы (при построении логической модели) согласовать описание предметной области: выделить объекты, их взаимосвязи, атрибуты, описывающие отдельные характеристики. При необходимости для одной согласованной логической модели можно создать физические модели для разных СУБД. Например, ERwin Data Modeler v. 9 в версии Community Edition поддерживает создание физических моделей для СУБД IBM DB2, Microsoft SQL Server, MySQL, Oracle Database, Sybase Adaptive Server Enterprise и ODBC-совместимых (от англ. Open Database Connectivity) СУБД.

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

Разделение на логическую и физическую модель БД имеет ряд преимуществ и с точки зрения документирования разрабатываемого решения. В силу ряда причин, таких как накладываемые СУБД ограничения на длину имен таблиц и столбцов, ограниченная поддержка национальных алфавитов в именах объектов БД, многие разработчики предпочитают использовать для таблиц и столбцов короткие имена, отображаемые латиницей. Например, столбец с идентификатором рабочей станции может называться "Wstld". Такие CASE-средства, как ERwin, позволяют при создании логической модели БД использовать понятные читаемые названия, а в физической модели БД – заменить их на короткие технические обозначения. С точки зрения документирования решений полезной является и возможность добавления комментариев и заметок в процессе работы над моделью.

При создании модели БД описывают сущности, их атрибуты и связи между сущностями [11–13]. Терминология IDEF1X очень близка ктерминологии, используемой в других методиках моделирования БД. Сущность (англ. Entity) является представлением множества реальных или абстрактных объектов (явлений, событий и т.п.), относимых к одному типу: они обладают одинаковым набором характеристик и могут участвовать в однотипных связях с другими сущностями. Конкретный объект из подобного множества будет называться экземпляром. Экземпляры должны отличаться один от другого. Сущности именуются существительным в единственном числе, например "Компьютер". Также стандарт IDEF1X допускает в имени указание уникального в рамках модели БД номера сущности, например "Компьютер/1". Обратите внимание, что в приведенном примере "1" – это номер сущности, а не ее экземпляра.

Атрибут (англ. attribute) соответствует свойству или характеристике, имеющейся у всех или некоторых экземпляров сущности. Множество возможных значений атрибута ограничивается доменом, на котором он определяется.

Связь (англ. relationship) описывает логическое отношение между двумя сущностями или между экземплярами одной сущности. При моделировании БД связь принято именовать глаголом или глагольной фразой.

Рассмотрим пример, иллюстрирующий использование различных типов сущностей и связей, определяемых нотацией IDEF1X. Пусть требуется разработать БД для хранения информации о компьютерной системе предприятия. С помощью программы ERwin Data Modeler начнем создавать логическую модель. Компьютеры имеют уникальные инвентарные номера и имена, причем для одного компьютера может быть использовано несколько дополнительных имен (псевдонимов). Например, компьютер servl.corp.ru может иметь псевдонимы mycorp.net и ftp.mycorp.net. Компьютеры размещены в помещениях организации, на них установлено ПО. Фрагмент логической модели БД представлен на рис. 6.4.

Фрагмент логической модели базы данных в нотации IDEF1X

Рис. 6.4. Фрагмент логической модели базы данных в нотации IDEF1X

Сущности в IDEF1X изображаются с помощью прямоугольника, над которым указывается его название, а в верхней части над чертой перечисляются атрибуты, входящие в первичный ключ. Сущности могут быть независимыми (англ. Identifier-Independent Entity) и зависимыми (англ. Identifier-Dependent Entity). Отличие заключается в том, что для существования экземпляра зависимой сущности необходима его связь с экземпляром сущности, от которой он зависит. Зависимые сущности изображаются прямоугольником со скругленными краями. В примере, приведенном на рис. 6.4, имеются независимая сущность "Компьютер" и зависящая от нее сущность "Псевдоним компьютера". Это означает, что псевдоним не может существовать без указания компьютера, для которого он задан.

Между независимой сущностью и подчиненной ей зависимой устанавливается идентифицирующая связь (англ. Identifying Relationship) типа "один-ко-многим". Связь изображается непрерывной линией с черным кружком на стороне подчиненной сущности. При создании модели БД в ERwin сущности сначала создаются как независимые, а после установки идентифицирующей связи дочерняя сущность автоматически преобразуется в зависимую. При этом в ее первичный ключ автоматически добавляются атрибуты первичного ключа родительской сущности, которые также сформируют внешний ключ: на рис. 6.4 это атрибут "Номер компьютера", который входит в состав первичного ключа сущности "Псевдоним компьютера". Внешний ключ отмечается на диаграмме символами "(FK)".

Операция автоматического добавления (при создании связи) ключевых атрибутов родительской сущности в дочернюю сущность в качестве внешнего ключа называется миграцией ключей (англ. key migration).

Рассмотрим вторую связь типа "один-ко-многим" представленную на диаграмме (рис. 6.4). Это связь между двумя независимыми сущностями "Помещение" и "Компьютер". В терминологии IDEF1X такая связь будет являться неидентифицирующей (англ. Non-identifying Relationship). Она изображается на диаграмме пунктирной линией с черным кружком со стороны дочерней сущности. В данном случае мы считаем, что для компьютера может быть определено не более одного помещения и могут существовать компьютеры, для которых помещение не задано. С точки зрения проектирования реляционной БД это означает, что в таблице "Компьютер" для внешнего ключа "Номер помещения" допустимо значение NULL. На диаграмме это изображается пустым ромбом со стороны родительской сущности (рис. 6.4). Такая связь называется опциональной, или необязательной (англ. optional non-identifying relationship) [11]. Если ромба нет, это означает обязательное участие подчиненной сущности в данной связи, что реализуется ограничением NOT NULL для соответствующего внешнего ключа (подробнее об ограничениях, определяемых при создании таблиц реляционной БД, см. гл. 7). В IDEF1X такая связь называется обязательной неидентифицирующей связью (англ. mandatory non-identifying relationship).

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

Третий тип связи, определяемый методологией IDEF1X, – связь "многие-ко-многим". При проектировании реляционной БД подобная связь допустима только в логической модели. В приведенном на рис. 6.4 примере это связь между сущностями "Компьютер" и "Программное обеспечение". Связь "многие-ко-многим" изображается сплошной линией с двумя черными кружками на концах. В соответствии с IDEF1X, такую связь рекомендуется именовать двумя глагольными фразами, разделенными косой чертой, что облегчает чтение диаграммы. Пусть связь "многие-ко-многим" установлена между сущностями "Сотрудник" и "Проект". Ее можно назвать "участвует/задействован". При чтении диаграммы получим "Сотрудник участвует в Проекте" и "в Проекте задействован Сотрудник". В примере, представленном на рис. 6.4, связь "многие-ко-многим" можно назвать "присутствует/установлено".

Реляционная модель в явном виде не поддерживает связи типа "многие-ко-многим". При проектировании БД в среде ERwin, при переходе от логической модели БД к физической, связь "многие-ко-многим" автоматически преобразуется: создается зависимая сущность, для которой определяются две связи "один-ко-многим". На рис. 6.5 изображен фрагмент физической модели БД, построенной для логической модели, представленной на рис. 6.4. Еще раз хочется обратить внимание, что ERwin позволяет давать различные имена соответствующим объектам физической и логической модели. Поэтому сущностям "Компьютер" и "Программное обеспечение" в физической модели на рис. 6.5 соответствуют таблицы "Computer" и "Software"; переименованы были и столбцы таблиц. Автоматически созданная таблица "Computer_Software", имя которой было сгенерировано на основе имен родительских таблиц, получила составной первичный ключ, включающий первичные ключи исходных таблиц. Таким образом, миграция ключей в данном случае произошла на уровне физической модели.

Преобразование связи

Рис. 6.5. Преобразование связи "многие-ко-многим" в физической модели

Прежде чем продолжить описание типов связей, определенных нотацией IDEF1X, рассмотрим уровни представления модели БД, предлагаемые ERwin Data Modeler. Надо отметить, что данное разделение уровней не определяется в IDEF1X, но в целом характерно для CASE-средств проектирования БД, поддерживающих эту методологию.

В соответствии с идеологией нисходящего проектирования разработчики ERwin ввели несколько промежуточных уровней моделирования [14]. Для логической модели определяются следующие формы представления.

Диаграмма "сущность – связь" (англ. Entity-Relationship Diagram, ERD) включает основные сущности, выявленные в предметной области, и связи между ними. Атрибуты не указываются. Диаграммы не перегружены деталями и могут использоваться для обсуждения структуры проектируемой базы в целом. Пример подобной диаграммы представлен на рис. 6.6.

Диаграмма "сущность – связь&quot

Рис. 6.6. Диаграмма "сущность – связь"

Представления модели БД, основанной на ключах

Рис. 6.7. Представления модели БД, основанной на ключах

Модель базы данных, основанная на ключах (англ. key-based), является более подробной, включает все сущности, их ключи, а также связи. В интерфейсе ERwin Data Modeler при работе с моделью можно переключиться на представление, использующее только первичные ключи (англ. primary key display level, рис. 6.7, а) или первичные и внешние ключи (англ. keys display level, рис. 6.7, б).

Нижний уровень для логической модели – полная атрибутивная модель (англ. fully-attributed, FA), включающая все сущности, их атрибуты и связи. Структура проектируемой БД должна быть приведена в соответствие третьей нормальной форме. В качестве примера может выступать модель, изображенная на рис. 6.4, при условии, что все необходимые объекты предметной области, их связи и характеристики представлены на диаграмме.

Для физической модели определены два уровня:

  • 1) трансформационная модель (англ. Transformation Model, ТМ) описывает преобразование логической реляционной модели в структуры, поддерживаемые СУБД, выбранной для реализации. Эти структуры оптимизированы, исходя из возможностей СУБД, объемов данных, ожидаемых запросов к данным, и могут быть денормализованы (не соответствовать требованиям третьей нормальной формы);
  • 2) модель СУБД (англ. DBMS Model) создается на основе трансформационной модели и содержит отображение структур системного каталога сервера БД, описывающих разрабатываемую БД.

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

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

Рассматриваемая нотация при необходимости позволяет указать мощность связи (англ. cardinality) – количество экземпляров подчиненной сущности, которые могут быть связаны с экземпляром родительской сущности. Мощность может задаваться для связи типа "один-ко-многим", как идентифицирующей, так и неидентифицирующей. Могут быть определены следующие варианты:

  • • по умолчанию одному экземпляру родительской сущности может соответствовать 0, 1 или несколько экземпляров дочерней сущности; этот вариант на диаграмме специально не отмечается;
  • • Р (от англ. positive – положительный) указывает, что экземпляру родительской сущности соответствует 1 или более экземпляров дочерней сущности, символ ставится рядом с черной точкой в изображении связи;
  • • Z (от англ. zero – ноль) указывает, что экземпляру родительской сущности соответствует 0 или 1 экземпляр дочерней сущности;
  • • число рядом с черной точкой указывает количество экземпляров подчиненной сущности; также можно задать диапазон или в скобках рядом с точкой указать комментарий, поясняющий возможные значения. Последние два варианта указания мощности средой ERwin Data Modeler v. 9 не поддерживаются.

Примеры указания мощности связи приведены в табл. 6.1.

Задать мощность связи в ERwin можно в окне свойств (пункт "Properties" контекстного меню, открывающегося при щелчке правой клавишей мыши на изображении связи). Нужно отметить, что при настройках по умолчанию ERwin не отображает на диаграмме название и мощность связи. Если нужно включить отображение мотцности связи на диаграмме, надо щелчком правой клавиши мыши на свободном месте поля диаграммы вызвать контекстное меню, в нем выбрать пункт "Properties" и на вкладке "Relationship" отметить опцию "Display Relationship Cardinality". Если нужно отобразить на диаграмме название связи, на той же вкладке надо отметить опцию "Display Logical Relationship Name".

Таблица 6.1

Правила изображения мощности связи

Описание

Пример

0, 1 или много

1 или много

0 или 1

Точно N. где N – неотрицательное целое

От N до Л/, где N и М – неотрицательные целые

В соответствии с комментарием в скобках

Определяя в ERwin связь типа "один-ко-многим", которая в большинстве случаев поддерживается на уровне СУБД с помощью внешнего ключа, можно уточнить, что должно происходить при изменениях в данных, таких как удаление экземпляра родительской сущности, для которой определены связанные дочерние. Подобные изменения могут привести к нарушению ссылочной целостности, и такие случаи должны специальным образом обрабатываться. Правило, определяющее поведение СУБД в каждом конкретном случае, называется правилом ссылочной целостности (англ. referential integrity, RI). Эти правила можно определить при проектировании в среде ERwin, а на уровне СУБД они будут реализованы или с помощью опций при создании внешних ключей, или с помощью триггеров. Триггер – это последовательность действий, описываемая на языке SQL и автоматически выполняемая при наступлении заданного события (подробнее о триггерах см. гл. 9). Триггер ссылочной целостности (RI-триггер) [13] – особый вид триггера, используемый для поддержания ссылочной целостности между двумя таблицами, которые связаны между собой. Если строка в одной таблице вставляется, изменяется или удаляется, то RI-триггер определяет, что нужно делать с теми строками в других таблицах, у которых значение внешнего ключа совпадает со значением первичного ключа вставленной (измененной, удаленной) строки. На рис. 6.8 показано окно ERwin, где определяются правила ссылочной целостности для выбранной связи.

Правила могут задаваться для шести случаев: удаление, добавление, изменение экземпляра дочерней сущности (англ. child delete rule, child insert rule, child update rule соответственно) или родительской сущности (англ. parent delete rule, parent insert rule, parent update rule). Могут быть определены следующие действия:

Определение правил ссылочной целостности

Рис. 6.8. Определение правил ссылочной целостности

  • • None – никаких действий по поддержанию ссылочной целостности не требуется;
  • • No action – никаких действий не предпринимается;
  • • Cascade – действие "каскадируется", например, при удалении экземпляра родительской сущности все связанные экземпляры дочерней сущности будут удалены;
  • • Restrict – действие запрещается, если оно может привести к нарушению ссылочной целостности; например, попытка удаления экземпляра родительской сущности будет отклонена, если у нее есть связанные экземпляры дочерней сущности;
  • • Set Null – после удаления объекта ссылки внешнего ключа внешнему ключу будет установлено значение Null (не определено);
  • • Set Default – в аналогичной предыдущему случаю ситуации внешний ключ получит значение по умолчанию, если оно для него определено.

Например, зададим для связи между сущностями "Помещение" и "Компьютер" (рис. 6.7, 6.8) в Parent Delete Rule действие Set Null. Тогда в случае удаления описания помещения во всех описаниях компьютеров, располагавшихся в этом помещении, соответствующий внешний ключ получит значение Null (т.е. "не определено").

Рассмотрим теперь некоторые частные случаи определения связей между сущностями. Начнем с n-арных связей. Связь между двумя сущностями называется бинарной. Если участников связи п (п> 2), связь будет п-арной. Строго говоря, нотация IDEF1X определяет правила изображения только бинарных связей, а для представления я-арных вводится дополнительная сущность. На рис. 6.9 представлен пример описания подобной связи между сущностями "Компания", "Продукт" и "Заказчик". Сущность "Контракт" описывает заказ товара у поставщика указанным клиентом в заданную дату.

Представленная на рис. 6.9 сущность "Контракт" является ассоциативной (англ. associative) [12] – она связана с несколькими родительскими сущностями и содержит дополнительную информацию о связи этих сущностей. Если дополнительных атрибутов нет, а есть только внешние ключи, такая сущность будет называться именующей [12] (англ. designative, может встречаться перевод "указательная" и другие близкие варианты).

Пример n-арной связи

Рис. 6.9. Пример n-арной связи

Другой интересный частный случай – это рекурсивная связь, где и в качестве родительской, и в качестве дочерней выступает одна и та же сущность. Подобные связи часто используются при описании иерархий однотипных объектов, имеющихся в предметной области. Например, для описания служебной иерархии в организации можно использовать структуру данных, представленную на рис. 6.10.

Среди атрибутов сущности "Сотрудник" (рис. 6.10, а) присутствует атрибут "ID начальника", являющийся внешним ключом, ссылающимся на первичный ключ этой же сущности. Таким образом, появляется возможность указать, кому подчинен сотрудник, а за счет того, что связь определена как неидентифицирующая и необязательная, в БД можно будет хранить информацию и о сотрудниках, которые на данный момент никому не подчинены.

При задании рекурсивной связи в среде ERwin нужно в свойствах связи уточнить имя атрибута внешнего ключа, которое будет ему назначено после выполнения миграции ключа (рис. 6.11). Это имя называется "имя роли" (англ. role name), оно показывает, какую роль атрибут, являющийся

Рекурсивная связь, описывающая служебную иерархию в организации

Рис. 6.10. Рекурсивная связь, описывающая служебную иерархию в организации:

а – опция Display Rolenames выключена; б – опция Display Rolenames включена

внешним ключом, играет в дочерней сущности. В нашем примере базовое имя атрибута – "ID сотрудника", имя роли – "ID начальника". В ERwin в окне Diagram Editor на вкладке Entity можно включить опцию Display Rolenames, и диаграмма будет выглядеть, как представлено на рис. 6.10, б: внешний ключ называется "ID начальника.ID сотрудника".

При определении рекурсивной связи также рекомендуется проверить мощность связи (вкладка "General" окна свойств связи, рис. 6.11), так как автоматически она задается не всегда верно.

Как уже отмечалось выше, рассмотренный вариант задания рекурсивной связи удобен при описании иерархий, когда у каждого логически подчиненного экземпляра сущности есть не более одного логически исходного. В нашем примере у каждого сотрудника может быть только один непосредственный начальник, а у начальника может быть несколько подчиненных. Такую связь также называют иерархической рекурсией {англ. hierarchical recursion) [12]. Однако на практике может встречаться и сетевая рекурсия {англ. network recursion), когда между родительскими и дочерними объектами присутствует связь типа "многие-ко-многим". Например, производственная компания может как закупать товары у многих поставщиков, так и поставлять товары многим заказчикам. В подобном случае при проектировании БД нужно использовать дополнительную зависимую сущность и две идентифицирующие связи "один-ко-многим". На рис. 6.12 для этих целей вводится сущность "Поставка", описывающая связь заказчика с поставщиком.

Уточнение имени внешнего ключа

Рис. 6.11. Уточнение имени внешнего ключа

Пример задания сетевой рекурсии

Рис. 6.12. Пример задания сетевой рекурсии

Следующая возможность нотации IDEF1X, на которую хотелось бы обратить внимание, – это определение категорий. В ряде случаев одна сущность является подтипом или категорией другой. Например, компьютер может быть сервером, рабочей станцией или ноутбуком. Рассматриваемое отношение между сущностями, по сути, является иерархическим, но, в отличие от иерархической рекурсии, тут строится иерархия сущностей, а не экземпляров. Дочерняя сущность в этой иерархии называется категориальной. В приведенном примере категориальные сущности – "Сервер", "Рабочая станция", "Ноутбук".

Подобным образом может строиться иерархия категорий или иерархия наследования, представляющая собой особый тип объединения сущностей, которые разделяют общие характеристики [12]. Для каждой категории

Иерархия категорий

Рис. 6.13. Иерархия категорий:

а – неполное множество категорий; б – полное множество категорий; в – отображение в физической модели

можно указать дискриминатор (англ. discriminator) – атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой. Например, это может быть атрибут "Тип компьютера", относящийся к сущности "Компьютер".

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

Рассмотрим два примера. На рис. 6.13, а представлен фрагмент диаграммы с неполным множеством категорий: для родительской сущности "компьютер" определены категории "сервер" и "рабочая станция". На то, что множество категорий неполно, указывает одна черта в значке категории. В качестве дискриминатора выбран атрибут "Тип компьютера".

На рис. 6.13, б добавлена категориальная сущность "Ноутбук" и указано, что множество категорий теперь является полным (значок категории с двойной чертой). Кроме того, в дочерние сущности добавлены атрибуты, показывающие, зачем вводятся категории. Так, атрибуты "номер компьютера", "имя компьютера" и "тип компьютера" есть у всех компьютеров, а "вес" и "диагональ экрана" определяются только для категории "Ноутбук".

На рис. 6.13, в показано, как иерархия категорий преобразуется средой ERwin Data Modeler при переходе от логической модели БД к физической: для связи таблиц будут использоваться внешние ключи.

Таблица 6.2

Классификация зависимых сущностей

Название

типа

Описание

Пример

Характеристика (англ. characteristic)

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

Ассоциативная (англ. associative) и именующая (англ. dcsignative) сущности

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

Категория ИЛИ ПОДТИП (англ. subtype)

Категориальная сущность является подтипом родительской сущности.

В табл. 6.2 представлена классификация зависимых сущностей, которые могут встретиться на диаграммах в нотации IDEF1X [14]. Ее рассмотрением завершим краткий обзор данной нотации, для более подробного ознакомления с которой рекомендуется обратиться к самому стандарту [11].

 
< Пред   СОДЕРЖАНИЕ     След >