Соловьева Ю.А., Соколова Н.Б. Создание модели данных с помощью AllFusion ERwin Data Modeler

Подождите немного. Документ загружается.

Рисунок 14 – Вкладки меню Properties

2.3 Установление связей

Связи является логическим соотношением между сущностями.

На логическом уровне можно установить идентифицирующую

связь «один ко многим», связь «многие ко многим» и неидентифи-

цирующую связь «один ко многим», пользуясь палитрой инстру-

ментов

. В IDEF1X различают зависимые и независимые

сущности. Тип сущности определяется ее связью с другими сущно-

стями. Идентифицирующая связь устанавливается между незави-

симой (родительский конец связи) и зависимой (дочерний конец

связи) сущностями. Когда рисуется идентифицирующая связь, ER-

win автоматически преобразует дочернюю сущность в зависимую.

Зависимая сущность изображается прямоугольником со скруглен-

ными углами (рисунок 15). Экземпляр

зависимой сущности опре-

деляется только через отношение к родительской сущности.

Рисунок 15 – Вид зависимой сущности

При установлении идентифицирующей связи атрибуты пер-

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

в состав первичного ключа дочерней сущности. Эта операция до-

полнения атрибутов дочерней сущности при создании связи назы-

вается миграцией атрибутов. В дочерней сущности новые атрибуты

помечаются как внешний ключ – (FK).

При установлении неидентифицирующей связи (рисунок 16)

дочерняя сущность остается независимой, а атрибуты первичного

ключа родительской сущности мигрируют в состав неключевых

компонентов дочерней сущности. Неидентифицирующая связь

служит для связывания независимых сущностей.

Рисунок 16 – Пример неидентифицирующей связи

Для создания неидентифицирующей связи необходимо нажать

на значок

на панели инструментов. Затем кликнуть по родитель-

ской сущности, а после – по дочерней. Процесс создания иденти-

фицирующей связи аналогичен созданию связи неидентифици-

рующей. Для просмотра свойств связи кликните по ней дважды

(рисунок 17).

Рисунок 17 – Свойства неидентифицирующей связи

В открывшемся окне будут активны:

 Relationship – указывает на выбранную связь (так же это

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

 Name – указывает имя связи;

 Кнопка

– альтернативный путь создания связи;

 Кнопка

– отвечает за удаление связи;

 Вкладка General включает в себя все основные свойства

связи, такие как идентификация и мощности отношений;

 Вкладка Definition позволяет дать более полное опреде-

ление связи для того, чтобы в дальнейшем иметь воз-

можность на него ссылаться;

 Вкладка Rolename позволяет задать имя роли и просмот-

реть мигрирующие компоненты;

 Во вкладке RI Actions имеется возможность настройки

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

 Вкладка UDP отображает свойства, заданные пользова-

телем.

Свяжем наши сущности в модели кадрового учета двумя

идентифицирующими связями. Свяжем сущности СОТРУДНИК и

НАЗНАЧЕНИЕ НА ДОЛЖНОСТЬ, ДОЛЖНОСТЬ и НАЗНАЧЕ-

НИЕ НА ДОЛЖНОСТЬ по атрибутам ID сотрудника и ID должно-

сти. СОТРУДНИК и ДОЛЖНОСТЬ будут выступать как

две неза-

висимых (родительских) сущности, а сущность НАЗНАЧЕНИЕ НА

ДОЛЖНОСТЬ будет зависимой (дочерней) сущностью (рисунок

18).

Рисунок 18 – Внешний вид идентифицирующих связей

2.3.1 Задание 2

Для иллюстрации неидентифицирующей связи свяжите сущ-

ность ПРОДАЖА ТОВАРА с сущностью СОТРУДНИК по полю ID

сотрудника. Для этого используем неидентифицирующую связь,

так как обе сущности являются сильными. Сравните полученный

результат с представленным на рисунке 19.

Рисунок 19 – Пример неидентифицирующей связи между

сущностями

В получившейся модели данных торгового центра у нас име-

ются 10 сущностей, 2 из которых будут зависимыми. Для обозначе-

ния зависимости сущностей, необходимо установить идентифици-

рующие связи. Дочерняя сущность ПОСТАВКА будет связана

идентифицирующей связью с родительской сущностью КАТАЛОГ.

Зависимая сущность НАЗНАЧЕНИЯ НА ДОЛЖНОСТЬ будет свя-

зана

двумя идентифицирующими связями с родительскими сущно-

стями СОТРУДНИК и ДОЛЖНОСТЬ. Неидентифицирующей свя-

зью необходимо связать следующие сущности: СОТРУДНИК и

ПРОДАЖА ТОВАРА; ТОВАР и Продажа Товара; ПОСТАВЩИК и

ПОСТАВКА; ПРОИЗВОДИТЕЛЬ и КАТАЛОГ; ГРУППА и КАТА-

ЛОГ; ПОСТАВКА и ТОВАР. После установления связей сравните

получившуюся модель базы данных торгового центра с представ-

ленной

ниже (рисунок 20).

Рисунок 20 – Пример модели базы данных торгового центра

3 Создание физического уровня модели данных

ERwin имеет два уровня представления модели – логический и

физический. Логический уровень – это абстрактный взгляд на дан-

ные, на нем данные представляются так, как они выглядят в реаль-

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

мире, например, «Поставщик», «Должность» или «Страна». Логи-

ческий уровень модели данных может быть

построен на основе

другой модели, например, на основе модели процессов. Логический

уровень модели данных является универсальным и никак не связан

с конкретной СУБД.

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

конкретной СУБД, фактически являясь отображением системного

каталога. В физическом уровне модели содержится информация о

всех объектах базы данных. Физический уровень модели зависит от

конкретной реализации СУБД. Следовательно, одному и тому же

логическому уровню модели могут соответствовать несколько раз-

ных физических уровней различных моделей. На физическом уров-

не модели важно описать всю информацию о конкретных физиче-

ских объектах

базы данных – таблицах, индексах, процедурах и т.д.

Разделение модели данных на логический и физический уровни по-

зволяет решить несколько важных задач, таких как документирова-

ние модели и масштабирование.

Документирование модели – позволяет упростить понимание

модели данных неспециалистами за счет задания на логическом

уровне семантического имени сущности, описывающего объект в

реальном

мире. При этом, данной сущности на физическом уровне

можно задать символьное обозначение объекта.

Масштабирование – позволяет каждому объекту логического

уровня задать объект физического уровня, например, каждой сущ-

ности задать таблицу. Модель, имеющая только логический уро-

вень, может быть синхронизирована с несколькими моделями,

имеющими только физический уровень. Это позволяет эффективно

разрабатывать гетерогенные ИС

Рисунок 21 – Окно прямого проектирования

ERwin позволяет перенести созданную модель данных непо-

средственно в СУБД, путем создания в выбранном файле таблиц и

отношений между ними. Для начала переноса необходимо создать

пустой файл под будущую базу данных. Например, для СУБД Mi-

crosoft Access создаем файл Access.mdb. Далее в AllFusion ERwin

Data Modeler r7 открываем модель данных, переходим на физиче-

ский уровень отображения модели, и при помощи команды Schema

Generation (Tools -> Forward Engineer -> Schema Generation) вызы-

ваем окно прямого проектирования (рисунок 21).

В данном окне настраиваются опции, которые будут учиты-

ваться при переносе в СУБД. Выпадающий список Option Set по

зволяет выбрать пакет настроек, который был создан ранее, или на-

строить опции в данный момент и сохранить для будущего исполь-

зования. Кнопка

отвечает за возможность фильтрации пере-

даваемого кода. Кнопка

позволяет просмотреть код, кото-

рый будет передан в СУБД. Кнопка

позволяет распечать и

сохранить на жестком диске (в формате .tif) передаваемый код. При

нажатии кнопки

появляется окно соединения с сервером ба-

зы данных (рисунок 22).

Рисунок 22 – Настройка соединения с СУБД

В поле Database указывается файл, в который будут переданы

данные. После нажатия кнопки

начнется передача файлов в

базу данных. Весь процесс будет отображаться в окне Generate Da-

tabase Schema (рисунок 23).

Рисунок 23 – Логирование процесса переноса

При возникновении ошибки процесс приостановится, и пре-

доставит выбор отменить или продолжить процесс передачи дан-

ных (рисунок 24). В основном окне будет указан номер ошибки,

причина, строка кода, в котором произошла ошибка. Если ошибки

некритичны, можно отменить остановку при их возникновении, уб-

рав галочку в пункте Stop if Failure.

Рисунок 24 – Окно выдачи ошибки процесса

3.1 Задание 3

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

получившуюся модель базы данных в СУБД Access. После успеш-

ного завершения процесса переноса все сущности будут преобразо-

ваны в таблицы в СУБД Microsoft Access (рисунок 25) с сохранени-

ем связей между сущностями (рисунок 26). Сравните результаты.

Рисунок 25 – Перечень таблиц в СУБД Microsoft Access

Рисунок 26 – Схема данных

4 Преобразование модели данных

Создание физического уровня данных для уже имеющейся ба-

зы данных осуществляется при помощи опции Reverse Engineer –

обратное проектирование (Tools ->Reverse Engineer) (рисунок 27).

Рисунок 27 – Окно создания физического уровня модели данных

Данный процесс похож на процесс создания новой модели, с

той разницей, что изменения производятся с уже имеющейся моде-

лью данных. В блоке New Model Type выбирает тип создаваемой

модели: Физический или Логический/Физический. Данные типы

отличаются тем, что при Логическом/Физическом типе имеется

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

уровнями представления моде-

ли.

В блоке Target Database выбирается СУБД, с которой связыва-

ется физический уровень представления модели данных. После на-

жатия кнопки

появится окно установки параметров обрат-

ного проектирования (рисунок 28).