Смекни!
smekni.com

Моделирование в ERwin (стр. 2 из 3)

Все объекты модели ERwin могут редактироваться средствами, принятыми в Windows - группировка, копирование, удаление, перемещение, использование системного буфера. Установка цветов и шрифтов осуществляется в удобных диалогах.
Компоненты модели, представленные текстом (имена сущностей, атрибутов, текстовые элементы) могут редактироваться непосредственно на экране.

Альтернативные ключи

Альтернативный ключ - это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр сущности. Например, для сущности служащий (идентификатор служащего, фамилия. имя, отчество) группа атрибутов "фамилия", "имя", "отчество" может являться альтернативным ключом (в предположении, что на предприятии не работают полные тезки).
Для альтернативного ключа, как и для первичного, ERwin автоматически создает индексы при генерации БД.

Инвертированные индексы

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

Унификация атрибутов

Зависимая сущность может наследовать один и тот же внешний ключ от более чем одной родительской сущности, или от одной и той же родительской сущности через несколько связей. Если не введены различные роли для такого множественного наследования, ERwin считает, что в зависимой сущности атрибуты внешнего ключа появляются только один раз.
Унификация - это объединение двух или более групп атрибутов внешних ключей в один внешний ключ (группу атрибутов), в предположении, что значения одноименных атрибутов в дочерней сущности всегда одинаковы.
Рассмотрим пример: сущность "сотрудник" имеет первичный ключ "код сотрудника" и связан идентифицирующей связью с сущностями "супруга" и "дети". При этом происходит миграция первичного ключа в зависимые сущности. В свою очередь, сущность "супруга" связана неидентифицирующей связью с сущностью "дети". Имеются два пути миграции ключа, однако в сущности "дети" атрибут "код сотрудника" появляется один раз в качестве элемента первичного ключа.
Существуют случаи, когда унификация атрибутов дает неверный с точки зрения предметной области результат. Для отмены унификации для атрибутов вводятся имена ролей.

Связи категоризации

Некоторые сущности определяют целую категорию объектов одного типа. В ERwin в таком случае создается сущность для определения категории и для каждого элемента категории, а затем вводится для них связь категоризации. Родительская сущность категории называется супертипом, а дочерние - подтипом.
Например, сущность "сотрудник" может содержать данные как о штатных работниках, так и о временно нанятых. Первые и вторые имеют различные, частично пересекающиеся наборы атрибутов (минимальное пересечение подтипов составляет первичный ключ). Общая часть этих атрибутов, включая первичный ключ, помещается в сущность-супертип "сотрудник".
Различная часть (например, данные почасовой оплаты для временных работников и данные о зарплате и отпуске для штатных работников) помещается в сущности-подтипы.
В сущности-супертипе вводится атрибут-дискриминатор, позволяющий различать конкретные экземпляры сущности - подтипа.
В зависимости от того, все ли возможные сущности-подтипы включены в модель, категорийная связь является полной или неполной. Продолжая пример, если супертип может содержать данные об уволенных сотрудниках, то эта связь - неполной категоризации, так как для него не существует записи в сущностях - подтипах.
В ERwin полная категория изображается окружностью с двумя подчеркиваниями, а неполная - окружностью с одним подчеркиванием.

Реализация ссылочной целостности с помощью ERwin

Ссылочная целостность - это обеспечение требования, чтобы значения внешнего ключа экземпляра дочерней сущности соответствовали значениям первичного ключа в родительской сущности. Ссылочная целостность может контролироваться при всех операциях, изменяющих данные (INSERT/UPDATE/DELETE). Средства контроля ссылочной целостности в ERwin включают автоматическую генерацию триггеров и использование механизмов декларативной ссылочной целостности (для тех СУБД, которые поддерживают данные механизмы).
Для каждой связи на логическом уровне могут быть заданы требования по обработке операций INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin представляет следующие варианты обработки этих событий:

  • отсутствие проверки;
  • проверка допустимости;
  • запрет операции;
  • каскадное выполнение операции (DELETE/UPDATE);
  • установка пустого (NULL-значения) или заданного значения по умолчанию.

В соответствии с выбранным вариантом ERwin автоматически создает необходимые триггеры на диалекте SQL целевой СУБД. При этом ERwin пользуется библиотекой шаблонов триггеров, которые можно модифицировать.
При генерации структуры базы данных триггеры, обеспечивающие ссылочную целостность могут быть переопределены на трех уровнях:

  1. Могут быть переопределены триггеры, обеспечивающие правила для всей модели.
  2. Могут быть переопределены триггеры, указанные для конкретной связи.
  3. Могут быть переопределены триггеры, указанные для конкретной таблицы.

Тип переопределения указывается разработчиком при генерации схемы базы данных (рис. 6- соответственно RI Type Override, Relationship Override, Entity Override).

Хранение информации в модели ERwin

Обычно модели ERwin сохраняются на диск в виде файла. Имеется возможность хранить модель в целевой СУБД. Для этого с помощью самого ERwin в целевой СУБД создается метабаза ERwin. В этой базе данных сохраняется информация модели. В частном случае базой данных могут быть и dBase-файлы, с которыми ERwin работает через ODBC.

Пример разработки модели в ERwin

Рассмотрим цикл разработки на примере, приведенном в статье Кодда [1].
Коротко напомним содержательную сторону задачи. Ведется учет служащих. Для каждого служащего хранится информация о детях и о списке занимавшихся этим служащим должностей. Для должностей хранится информация по установленным должностным окладам.
Сначала создадим логический уровень модели. Для этого зададим режим отображения сущностей (Display/Entity Level). Создадим при помощи линейки инструментов сущности "служащий", "дети", "история работы", "история зарплаты". Будем именовать сущности на русском языке.
Выбрав каждую сущность, зададим для нее подробное описание на русском языке в редакторе "Entity Definition". Это описание появится в отчетах ERwin и может быть отображено на диаграмме.
Укажем связи между сущностями. Например, "служащий" связан идентифицирующей связью "является родителем" с сущностью "дети". Описание связи вводится в редакторе "Editor/Relationship".
Результат работы отображен на диаграмме ERwin (рис. 2).

Рис. 2. Диаграмма уровня сущности

Теперь перейдем в режим задания атрибутов (Display/Atribute Level). В редакторе "Entity/Attribute" зададим на русском языке имена ключевых и неключевых атрибутов. Заметим, что для дочерней сущности "дети" ключевой атрибут "номер служащего" не указывается вручную. ERwin обеспечивает его миграцию из родительской сущности. То же происходит с другими дочерними сущностями.
Для атрибута "имя" сущности "служащий" укажем, что он является альтернативным ключом (будем считать, что у всех служащих уникальные имена/фамилии). Для этого после имени атрибута поместим указатель AK1 в скобках.
Результат работы отображен на диаграмме ERwin (рис. 3) в нотации IDEF1X.

Рис. 3. Диаграмма уровня атрибутов в нотации IDEF1X

Вид той же диаграммы в нотации IE (Information Engineering) показан на рис.4.

Рис. 4. Диаграмма уровня атрибутов в нотации IE

Так как имена атрибутов и сущностей задавались нами на русском языке, для перехода к физическому уровню модели следует поставить им в соответствие идентификаторы таблиц, колонок и ограничений, удовлетворяющие правилам целевой СУБД (обычно это означает использование латинских букв, цифр и некоторых специальных символов).
В редакторе "Database Schema" указываем для каждой сущности соответствующее имя таблицы. Затем в редакторе "Attribute Definition" задаем имена колонок таблиц, соответствующие атрибутам сущностей. ERwin и здесь обеспечивает миграцию имен колонок в подчиненные таблицы.
На этом этапе можно воспользоваться и редактором "Extended Attributes" для определения расширенных атрибутов PowerBuilder (формата отображения, маски редактирования, правила контроля, выравнивания, заголовков и комментариев).
В редакторе "Relationship Definitions" указывается физическое имя связи, которое соответствует имени ограничения (constraint), создаваемого ERwin в базе данных.
Теперь все готово к созданию БД и нужно выбрать целевую СУБД (если этого не было сделано раньше). Выберем, например, Sybase System 10.
В редакторе SYBASE Database Schema задаем типы данных для колонок таблиц.
Диалог, в котором происходит выбор типа данных, приведен на рис.5.

Рис. 5. Определение физической модели

Теперь можно перейти к созданию базы данных. Для этого выполняется команда "Sybase schema generation". ERwin построит пакет SQL-предложений генерации базы данных. На рис.6 показан диалог выбора параметров генерации пакета для генерации БД. На рисунке видно, что может быть задан фильтр (генерация не всех таблиц), пакет SQL-предложений можно просмотреть (preview), распечатать, сохранить в файл (report), выполнить генерацию (generate).