Проектирование модели в ERWin. Построение моделей в ERwin Создание отчетов в Erwin
Создание современных информационных систем представляет собой сложнейшую задачу, решение которой требует применения специальных методик и инструментов. Неудивительно, что в последнее время среди системных аналитиков и разработчиков значительно вырос интерес к CASE (Computer-Aided Software/System Engineering) - технологиям и инструментальным CASE-средствам, позволяющим максимально систематизировать и автоматизировать все этапы разработки программного обеспечения.
Предлагаемая читателю книга представляет собой практическое руководство по созданию информационных систем с помощью эффективных инструментов анализа, проектирования и кодогенерации фирмы PLATINUM technology - BPwin и ERwin. Она содержит также описание методов структурного анализа и проектирование моделей данных в объеме, необходимом для практической работы. Применение методов иллюстрируется примерами.
Книга написана на основе личного опыта автора, полученного при разработке информационных систем, чтении лекций и проведении практических занятий по CASE-технологиям и CASE-средствам в Учебном центре компании "Интерфейс Ltd." Она адресована специалистам в области информационных технологий: системным аналитикам, руководителям проектов, разработчикам - и может быть также полезна для студентов и аспирантов, изучающих основы системного анализа и проектирования информационных систем.
Книга:
Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) (рис. 2.20). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например:
Каждый КЛИЕНТ <размещает> ЗАКАЗы;
Каждый ЗАКАЗ <выполняется> СОТРУДНИКом.
Рис. 2.20. Имя связи - Relationship Verb Phrases
Связь показывает, какие именно заказы разместил клиент и какой именно сотрудник выполняет заказ. По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Verb Phrase.
На логическом уровне можно установить идентифицирующую связь один-ко-многим, связь многие-ко-многим и неидентифицирующую связь один-ко-многим (соответственно это кнопки слева направо в палитре инструментов).
В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами (сущность Заказ на рис. 2.21). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, т. е. в структуре на рис. 2.21 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, который его размещает. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK).
Рис. 2.21. Идентифицирующая связь между независимой и зависимой таблицей
В дальнейшем, при генерации схемы БД, атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента.
При установлении неидентифицирующей связи (рис. 2.22) дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности. Неидентифицирующая связь служит для связывания независимых сущностей.
Рис. 2.22. Неидентифицирующая связь
Экземпляр сущности Сотрудник может существовать безотносительно к какому-либо экземпляру сущности Отдел, т. е. сотрудник может работать в организации, не числясь в каком-либо отделе.
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи (см. рис. 2.21), неидентифицирующая - пунктирной (рис. 2.22).
Для создания новой связи следует:
установить курсор на нужной кнопке в палитре инструментов (идентифицирующая или неидентифицирующая связь) и нажать левую кнопку мыши (рис. 2.2);
щелкнуть сначала по родительской, а затем по дочерней сущности.
Форму линии связи можно изменить. Для этого нужно захватывать мышью нужную линию связи и переносить ее с места на место, пока линия не начнет выглядеть лучше.
В палитре инструментов кнопка
Соответствует идентифицирующей связи, кнопка
Связи многие-ко-многим и кнопка
Соответствуют неидентифицирующей связи.
Для редактирования свойств связи следует "кликнуть" правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor.
В закладке General появившегося диалога можно задать мощность, имя и тип связи (рис. 2.23).
Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа мощности (рис. 2.24):
общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом;
символом Р помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.
Рис. 2.23. Диалог Relationship Editor
По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Cardinality.
Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child так и Child-to-Parent.
Рис. 2.24. Обозначения мощности
Тип связи (идентифицирующая/неидентифицирующая). Для неидентифицирующей связи можно указать обязательность (Nulls). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности (см. рис. 2.22).
Рис. 2.25. Закладка Rolename/RI Actions диалога Relationship Editor
В закладке Definition можно дать более полное определение связи для того, чтобы в дальнейшем иметь возможность на него ссылаться.
В закладке Rolename/RI Actions можно задать имя роли и правила ссылочной целостности.
Имя роли (функциональное имя) - это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности.
Рис. 2.26. Имена ролей внешних ключей
В примере, приведенном на рис. 2.26, в сущности Сотрудник внешний ключ Номер отдела имеет функциональное имя "Где работает", которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Entities и затем включить опцию Rolename/Attribute (рис. 2.25). Полное имя показывается как функциональное имя и базовое имя, разделенные точкой (см. рис. 2.26).
Обязательным является применение имен ролей в том случае, когда два или более атрибутов одной сущности определены по одной и той же области, т. е. они имеют одинаковую область значений, но разный смысл. На рис. 2.27 сущность Продажа валюты содержит информацию об акте обмена валюты, в котором участвуют две валюты - проданная и купленная. Информация о валютах содержится в сущности Валюта. Следовательно, сущности Продажа валюты и Валюта должны быть связаны дважды и первичный ключ - Номер валюты должен дважды мигрировать в сущность Валюта в качестве внешнего ключа. Необходимо различать эти атрибуты, которые содержат информацию о номере проданной и купленной валюты (имеют разный смысл), но ссылаются на одну и ту же сущность Валюта (имеют общую область значений). В примере на рис. 2.27 атрибуты получили имена ролей Проданная и Купленная.
Рис. 2.27. Случай обязательности имен ролей
Другим примером обязательности присвоения имен ролей являются рекурсивные связи (иногда их называют "рыболовный крючок" - fish hook), когда одна и та же сущность является и родительской и дочерней одновременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рис. 2.26 сущность Сотрудник содержит атрибут первичного ключа Табельный номер. Информация о руководителе сотрудника содержится в той же сущности, поскольку руководитель работает в той же организации. Чтобы сослаться на руководителя сотрудника следует создать рекурсивную связь (на рис. 2.26 связь руководит/подчиняется) и присвоить имя роли ("Руководитель"). Заметим, что рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии - у дерева подчиненности должен быть корень - сотрудник, который никому не подчиняется в рамках данной организации.
Связь руководит/подчиняется на рис. 2.26 позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчиненный имеет только одного руководителя (рис. 2.28).
Иерархическая рекурсия Сетевая рекурсия
Рис. 2.28. Подчиненность экземпляров сущности в иерархической и сетевой рекурсии
Другим видом рекурсии является сетевая рекурсия (network recursion), когда руководитель может иметь множество подчиненных и, наоборот, подчиненный может иметь множество руководителей. Сетевая рекурсия задает паутину отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в связи многие-ко-многим. Для разрешения связи многие-ко-многим необходимо создать новую сущность (подробно связь многие-ко-многим будет рассмотрена ниже).
Рис. 2.29. Пример реализации сетевой рекурсии
На рис. 2.29 рассмотрен пример реализации сетевой рекурсии. Структура моделирует родственные отношения между членами семьи любой сложности. Атрибут Тип отношения может принимать значения "отец-сын", "мать-дочь", "дед-внук", "свекровь-невестка", "тесть-зять" и т. д. Поскольку родственное отношение связывает всегда двух людей, от сущности Родственник к. сущности Родственное отношение установлены две идентифицирующие связи с именами ролей "Старший" и "Младший". Каждый член семьи может быть в родственных отношениях с любым другим членом семьи, более того, одну и ту же пару родственников могут связывать разные типы родственных отношений.
Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более - только имя роли. На рис. 2.30 изображена структура данных, которая содержит сущность Команда, сущность Игрок, в которой хранится информация об игроках каждой команды, и сущность Гол, содержащая информацию и голах, которые забивает каждый игрок. Атрибут внешнего ключа Номер команды сущности Игрок имеет имя роли "В какой команде играет".
Рис. 2.30. Миграция имен ролей
На следующем уровне, в сущности Гол, отображается только имя роли соответствующего атрибута внешнего ключа (В какой команде играет).
Правила ссылочной целостности (referential integrity, RI) - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. При генерации схемы БД на основе опций логической модели, задаваемых в закладке Rolename/RI Actions, будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность. Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT, UPDATE или DELETE). На рис. 2.30 существует идентифицирующая связь между сущностями Команда и Игрок. Что будет, если удалить команду? Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL), следовательно, нужно либо запретить удаление команды, пока в ней числится хотя бы один игрок (для удаления команды сначала нужно удалить всех игроков), либо сразу удалять вместе с командой всех ее игроков. Такие правила удаления называются "ограничение" и "каскад" (Parent RESTRICT и Parent CASCADE, см. рис. 2.25). Заметим, что сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и в случае удаления каскадом команды будут удалены все игроки команды и все голы, которые они забивали. Выполнение команды на удаление одной строки реально может привести к удалению тысячи строк в БД, поэтому использовать правило удаления каскадом следует с осторожностью. В том случае, если установлено правило ограничения удаления, при попытке выполнить удаление команды, в которой есть хотя бы один игрок, сервер реляционной СУБД возвратит ошибку.
На рис. 2.26 установлена необязательная неидентифицирующая связь между сущностями Отдел и Сотрудник. Экземпляр сущности Сотрудник может существовать без ссылки на отдел (атрибут внешнего ключа Где работает. Номер отдела может принимать значение NULL). В этом случае возможно установление правила установки в нуль - SET NULL. При удалении отдела атрибут внешнего ключа сущности Сотрудник - Где работает. Номер отдела примет значение NULL. Это означает, что при удалении отдела сотрудник остается работать в организации не будучи приписан к какому-либо отделу и информация о нем сохраняется.
Возможна установка еще двух правил удаления (если таковые поддерживаются СУБД):
SET DEFAULT - при удалении атрибуту внешнего ключа присваивается значение по умолчанию. Например, при удалении команды игроки могут быть переведены в другую команду.
NONE - при удалении значение атрибута внешнего ключа не меняется. Запись об игроке "повисает в воздухе", т. е. ссылается на несуществующую уже команду. Такая ситуация характерна для "плоских" таблиц. Например, если информация об игроках и командах хранится в dbf-файлах, можно удалить запись о команде, при этом файл игроков "ничего не будет знать" о том, что соответствующей команды не существует. Поэтому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиентском приложении.
Правила удаления управляют тем, что будет происходить в БД при удалении строки. Аналогично правила вставки и обновления управляют тем, что будет происходить с БД, если строки изменяются или добавляются. Например, можно установить правило, которое разрешает вносить новую команду только в том случае, когда в нее зачислен хотя бы один игрок. Желаемое поведение может быть достигнуто следующими действиями:
Задать мощность связи между сущностями Команда и Игрок, равную "One or more" - 1 или более (тип Р). Предполагается, что установлена идентифицирующая связь.
Присвоить действие RI-триггера "Parent Insert-CASCADE" для того, чтобы при создании новой строки в таблице Команда автоматически создавалась хотя бы одна строка в дочерней таблице Игрок.
Присвоить связи действие RI-триггера "Parent Delete-CASCADE" для того, чтобы при удалении строки из таблицы Команда соответствующая строка или строки из таблицы Игрок тоже удалялись.
ERwin автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграмму. Режимы RI, присваиваемые ERwin по умолчанию (приведены в табл. 2.4), могут быть изменены в редакторе Referential Integrity Default, который вызывается, если щелкнуть по кнопке RI Defaults диалога Target Server (меню Server/Target Server).
Таблица 2.4. Значения RI, присваиваемые в ERwin no умолчанию, а также возможные оежимы для каждого типа связи
| Идентифицирующая связь | Неидентифицирующая связь (Nulls Allowed) | Неидентифицирующая связь (No Nulls) | Категориальная связь | |
| Child Delete Возможные режимы | RESTRICT, CASCADE, NONE | RESTRICT, CASCADE, NONE, SET NULL, SET DEFAULT | RESTRICT, CASCADE, | |
| NONE | ||||
| Child Delete Режимы по умолчанию | NONE | NONE | NONE | NONE |
| Child Insert Возможные режимы | RESTRICT, CASCADE, | RESTRICT, CASCADE, NONE, SET DEFAULT | RESTRICT, CASCADE, | |
| NONE | NONE | |||
| Child Insert Режимы по умолчанию | RESTRICT | SET NULL | RESTRICT | RESTRICT |
| Child Update Возможные режимы | RESTRICT, CASCADE, NONE | RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT | RESTRICT, CASCADE, NONE, SET DEFAULT | RESTRICT, CASCADE, NONE |
| Child Update Режимы по умолчанию | RESTRICT | SET NULL | RESTRICT | RESTRICT |
| Parent Delete Возможные режимы | RESTRICT, CASCADE, NONE | RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT | RESTRICT, CASCADE, NONE, SET DEFAULT | RESTRICT, CASCADE, |
| NONE | ||||
| Parent Delete Режимы по умолчанию | RESTRICT | SET NULL | RESTRICT | CASCADE |
| Parent Insert Возможные режимы | RESTRICT, CASCADE, NONE | RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT | RESTRICT, CASCADE, NONE, SET DEFAULT | RESTRICT, CASCADE, NONE |
| Parent Insert Режимы по умолчанию | NONE | NONE | NONE | NONE |
| Parent Update Возможные режимы | RESTRICT, CASCADE, NONE | RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT | RESTRICT, CASCADE, NONE, SET DEFAULT | RESTRICT, CASCADE, NONE |
| Parent Update Режимы по умолчанию | RESTRICT | SET NULL | RESTRICT | CASCADE |
Связь многие-ко-многим возможна только на уровне логической модели данных. На рис. 2.31 вверху показан пример связи многие-ко-многим. Врач может принимать много пациентов, пациент может лечиться у нескольких врачей. Такая связь обозначается сплошной линией с двумя точками на концах.
6. Моделирование в ERwin
Место ERwin в информационном моделировании
Процесс построения информационной модели состоит из следующих шагов:
- определение сущностей;
- определение зависимостей между сущностями;
- задание первичных и альтернативных ключей;
- определение атрибутов сущностей;
- приведение модели к требуемому уровню нормальной формы;
- переход к физическому описанию модели: назначение соответствий имя сущности - имя таблицы, атрибут сущности - атрибут таблицы; задание триггеров, процедур и ограничений;
- генерация базы данных.
ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).
Отображение логического и физического уровня модели данных в ERwin
В ERwin существуют два уровня представления и моделирования - логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.
Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin.
ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне.
Компоненты диаграммы ERwin и основные виды представлений диаграммы
Диаграмма ERwin строится из трех основных блоков - сущностей, атрибутов и связей. Если рассматривать диаграмму как графическое представление правил предметной области, то сущности являются существительными, а связи - глаголами.
Выбор между логическим и физическим уровнем отображения осуществляется через линейку инструментов или меню. Внутри каждого из этих уровней есть следующие режимы отображения:
- Режим "сущности" - внутри прямоугольников отображается имя сущности (для логической модели) или имя таблицы (для физического представления модели); служит для удобства обзора большой диаграммы или размещения прямоугольников сущностей на диаграмме.
- Режим "определение сущности" служит для презентации диаграммы другим людям.
- Режим "атрибуты". При переходе от предметной области к модели требуется вводить информацию о том, что составляет сущность. Эта информация вводится путем задания атрибутов (на физическом уровне - колонок таблиц). В этом режиме прямоугольник-сущность делится линией на две части - в верхней части отображаются атрибуты (колонки), составляющие первичный ключ, а в нижней - остальные атрибуты. Этот режим является основным при проектировании на логическом и физическом уровнях.
- Режим "первичные ключи" - внутри прямоугольников - сущностей показываются только атрибуты/колонки, составляющие первичный ключ.
- Режим "пиктограммы". Для презентационных целей каждой таблице может быть поставлена в соответствие пиктограмма (bitmap).
- Режим "показ глагольной фразы". На дугах связей показываются глагольные фразы, связывающие сущности (для логического уровня) или имена внешних ключей (для физического уровня).
Диаграмма может занимать более чем один экран и более чем один лист при печати. Для обзора модели предусмотрены, кроме прокруток экрана, режимы уменьшения/увеличения изображения, отображение всей модели, отображение выделенной части модели.
Инструменты для создания модели в ERwin
Основные инструменты создания модели доступны как из меню, так и через окно инструментов. С их помощью создаются независимые и зависимые сущности, идентифицирующие и неидентифицирующие связи, полные и неполные категории, неспецифические связи и текстовые элементы.
Нажатием мыши над сущностью производится вход в один из многочисленных редакторов ERwin:
- редакторы, связанные с сущностью в целом (определение сущности, дополнительная информация, триггеры, индексы, характеристики таблицы, хранимые процедуры, связанные с таблицей);
- редакторы атрибутов (определение атрибутов, колонки таблицы в физическом представлении модели, репозитарий средства 4GL, например, расширенные атрибуты в PowerBuilder).
Идентификация сущностей. Сущности в ERwin
На диаграмме сущность изображается прямоугольником. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения.
Горизонтальная линия прямоугольника разделяет атрибуты сущности на два набора - атрибуты, составляющие первичный ключ в верхней части и прочие (не входящие в первичных ключ) в нижней части.
Сущность представляет собой множество реальных или абстрактных объектов, например, люди, места, события, факты, которые имеют общие характеристики. Сущность - это логическое понятие. Сущности соответствует таблица в реальной СУБД. В ERwin сущность визуально представляет три основных вида информации:
- атрибуты, составляющие первичный ключ;
- неключевые атрибуты;
- тип сущности (независимая/зависимая).
Первичный ключ - это атрибут или набор атрибутов, уникально идентифицирующий экземпляр сущности. Если несколько наборов атрибутов могут уникально идентифицировать сущность, то выбор одного из них осуществляется разработчиком на основании анализа предметной области.
Для каждого первичного ключа ERwin создает при генерации структуры БД уникальный индекс.
Экземпляры независимой сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями; зависимая сущность, наоборот, не может быть уникально идентифицирована без определения ее связей с другими сущностями. Зависимая сущность отображается в ERwin прямоугольником с закругленными углами.
Связи (relationships) в ERwin
Связь - это функциональная зависимость между двумя сущностями (в частности, возможна связь сущности с самой собой). Например, важно знать фамилию сотрудника, и не менее важно знать, в каком отделе он работает. Таким образом, между сущностями "отдел" и "сотрудник" существует связь "состоит из" (отдел состоит из сотрудников). Связь - это понятие логического уровня, которому соответствует внешний ключ на физическом уровне. В ERwin связи представлены пятью основными элементами информации:
- тип связи (идентифицирующая, неидентифицирующая, полная/неполная категория, неспецифическая связь);
- родительская сущность;
- дочерняя (зависимая) сущность;
- мощность связи (cardinality);
- допустимость пустых (null) значений.
Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей связи всегда является зависимой.
Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе, чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности, при этом входят в состав неключевых атрибутов дочерней сущности.
Для определения связей ERwin выбирается тип связи, затем мышью указывается родительская и дочерняя сущность. Идентифицирующая связь изображается сплошной линией; неидентифицирующая - пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.
При определении связи происходит миграция атрибутов первичного ключа родительской сущности в соответствующую область атрибутов дочерней сущности. Поэтому такие атрибуты не вводятся вручную.
Атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами. ERwin позволяет ввести для них роли, т.е. новые имена, под которыми мигрирующие атрибуты будут представлены в дочерней сущности. В случае неоднократной миграции атрибута такое переименование необходимо. Например, сущность "посредническая сделка" имеет атрибут "код предприятия-продавца" и "код предприятия-покупателя". В данном случае первичный ключ сущности "предприятие" ("код предприятия") имеет две роли в дочерней сущности.
На физическом уровне имя роли - это имя колонки внешнего ключа в дочерней таблице.
Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n.
ERwin в соответствии с методологией IDEF1X предоставляет 4 варианта для n, которые изображаются дополнительным символом у дочерней сущности: ноль, один или больше (по умолчанию); ноль или один; ровно N, где N - конкретное число.
Допустимость пустых (NULL) значений в неидентифицирующих связей ERwin изображает пустым ромбиком на дуге связи со стороны родительской сущности.
Обозначения мощности соответственно ноль, один или больше, один или больше, ноль или один в нотации IE приведены на рис. 1.
Рис.1. Обозначения мощности связи в нотации IE
Имя связи на логическом уровне представляет собой "глагол", связывающий сущности. Физическое имя связи (которое может отличаться от логического) для ERwin означает имя ограничения (constraint) или индекса.
Графическое редактирование модели
Все объекты модели ERwin могут редактироваться средствами, принятыми в Windows - группировка, копирование, удаление, перемещение, использование системного буфера. Установка цветов и шрифтов осуществляется в удобных диалогах.
Компоненты модели, представленные текстом (имена сущностей, атрибутов, текстовые элементы) могут редактироваться непосредственно на экране.
Альтернативные ключи
Альтернативный ключ - это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр сущности. Например, для сущности служащий (идентификатор служащего, фамилия. имя, отчество) группа атрибутов "фамилия", "имя", "отчество" может являться альтернативным ключом (в предположении, что на предприятии не работают полные тезки).
Для альтернативного ключа, как и для первичного, ERwin автоматически создает индексы при генерации БД.
Инвертированные индексы
Атрибуты, составляющие альтернативный ключ, однозначно (уникально) идентифицируют экземпляры сущности. В ERwin можно также составлять группы атрибутов, которые не идентифицируют уникально экземпляры сущности, но часто используются для доступа к данным. Для каждой такой группы атрибутов ERwin создает неуникальные индексы.
Одни и те же атрибуты сущности могут входить в несколько различных групп ключей.
Унификация атрибутов
Зависимая сущность может наследовать один и тот же внешний ключ от более чем одной родительской сущности, или от одной и той же родительской сущности через несколько связей. Если не введены различные роли для такого множественного наследования, ERwin считает, что в зависимой сущности атрибуты внешнего ключа появляются только один раз.
Унификация - это объединение двух или более групп атрибутов внешних ключей в один внешний ключ (группу атрибутов), в предположении, что значения одноименных атрибутов в дочерней сущности всегда одинаковы.
Рассмотрим пример: сущность "сотрудник" имеет первичный ключ "код сотрудника" и связан идентифицирующей связью с сущностями "супруга" и "дети". При этом происходит миграция первичного ключа в зависимые сущности. В свою очередь, сущность "супруга" связана неидентифицирующей связью с сущностью "дети". Имеются два пути миграции ключа, однако в сущности "дети" атрибут "код сотрудника" появляется один раз в качестве элемента первичного ключа.
Существуют случаи, когда унификация атрибутов дает неверный с точки зрения предметной области результат. Для отмены унификации для атрибутов вводятся имена ролей.
Некоторые сущности определяют целую категорию объектов одного типа. В ERwin в таком случае создается сущность для определения категории и для каждого элемента категории, а затем вводится для них связь категоризации. Родительская сущность категории называется супертипом, а дочерние - подтипом.
Например, сущность "сотрудник" может содержать данные как о штатных работниках, так и о временно нанятых. Первые и вторые имеют различные, частично пересекающиеся наборы атрибутов (минимальное пересечение подтипов составляет первичный ключ). Общая часть этих атрибутов, включая первичный ключ, помещается в сущность-супертип "сотрудник".
Различная часть (например, данные почасовой оплаты для временных работников и данные о зарплате и отпуске для штатных работников) помещается в сущности-подтипы.
В сущности-супертипе вводится атрибут-дискриминатор, позволяющий различать конкретные экземпляры сущности - подтипа.
В зависимости от того, все ли возможные сущности-подтипы включены в модель, категорийная связь является полной или неполной. Продолжая пример, если супертип может содержать данные об уволенных сотрудниках, то эта связь - неполной категоризации, так как для него не существует записи в сущностях - подтипах.
В ERwin полная категория изображается окружностью с двумя подчеркиваниями, а неполная - окружностью с одним подчеркиванием.
Реализация ссылочной целостности с помощью ERwin
Ссылочная целостность - это обеспечение требования, чтобы значения внешнего ключа экземпляра дочерней сущности соответствовали значениям первичного ключа в родительской сущности. Ссылочная целостность может контролироваться при всех операциях, изменяющих данные (INSERT/UPDATE/DELETE). Средства контроля ссылочной целостности в ERwin включают автоматическую генерацию триггеров и использование механизмов декларативной ссылочной целостности (для тех СУБД, которые поддерживают данные механизмы).
Для каждой связи на логическом уровне могут быть заданы требования по обработке операций INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin представляет следующие варианты обработки этих событий:
- отсутствие проверки;
- проверка допустимости;
- запрет операции;
- каскадное выполнение операции (DELETE/UPDATE);
- установка пустого (NULL-значения) или заданного значения по умолчанию.
В соответствии с выбранным вариантом ERwin автоматически создает необходимые триггеры на диалекте SQL целевой СУБД. При этом ERwin пользуется библиотекой шаблонов триггеров, которые можно модифицировать.
При генерации структуры базы данных триггеры, обеспечивающие ссылочную целостность могут быть переопределены на трех уровнях:
- Могут быть переопределены триггеры, обеспечивающие правила для всей модели.
- Могут быть переопределены триггеры, указанные для конкретной связи.
- Могут быть переопределены триггеры, указанные для конкретной таблицы.
Тип переопределения указывается разработчиком при генерации схемы базы данных (рис. 6- соответственно RI Type Override, Relationship Override, Entity Override).
Хранение информации в модели ERwin
Обычно модели ERwin сохраняются на диск в виде файла. Имеется возможность хранить модель в целевой СУБД. Для этого с помощью самого ERwin в целевой СУБД создается метабаза ERwin. В этой базе данных сохраняется информация модели. В частном случае базой данных могут быть и dBase-файлы, с которыми ERwin работает через ODBC.
Пример разработки модели в ERwin
Рассмотрим цикл разработки на примере, приведенном в статье Кодда .
Коротко напомним содержательную сторону задачи. Ведется учет служащих. Для каждого служащего хранится информация о детях и о списке занимавшихся этим служащим должностей. Для должностей хранится информация по установленным должностным окладам.
Сначала создадим логический уровень модели. Для этого зададим режим отображения сущностей (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).
Рис. 6. Выбор параметров генерации базы данных
7. Расширенные функции ERwin
Обратное проектирование (Reverse engineering)
Обратное проектирование, то есть восстановление информационной модели по существующей базе данных, используется при выборе оптимальной платформы (rightsizing) для существующей настольной (desktop) базы данных или базы данных на mainframe, а также при расширении (или модификации) существующей структуры, которая была построена без необходимой сопроводительной документации. После завершения процесса восстановления модели ERwin автоматически "раскладывает" таблицы на диаграмме. Теперь можно выполнять модификации уже с использованием логической схемы - добавлять сущности, атрибуты, комментарии, связи и т.д. По завершении изменений одна команда - синхронизировать модель с базой данных - актуализирует все проведенные изменения.
Построение модели может быть выполнено как на основании данных каталога базы данных, так и на основании пакета операторов SQL, с помощью которого была создана база данных.
Синхронизация с базой данных
В процессе разработки информационной системы может возникнуть ситуация, когда структура базы данных и информационная модель не соответствуют друг другу. ERwin предоставляет возможность привести их в соответствие.
Для этого предусмотрена функция синхронизации с базой данных. После подключения к СУБД предлагается список несоответствий между существующей структурой данных и моделью. Например, если в базе данных создана новая таблица, то ERwin предложит провести включение ее в модель. Если в модель добавлена новая таблица, ERwin предложит создать ее в реальной базе данных. Аналогично, при добавлении колонок в базе данных или в модели ERwin предлагает провести соответствующие операции по синхронизации. Процедура выбора синхронизируемых таблиц показана на рис.7.
Рис. 7. Выбор синхронизируемых таблиц
ERwin "знает" о таких особенностях хранения данных в отдельных СУБД, как сегменты (в Sybase) и табличное пространство (в Oracle). Информация о физическом размещении может быть включена в модель и использована при прямом и обратном проектировании.
Интерфейсы к СУБД
ERwin поддерживает прямой интерфейс с основными СУБД: DB2 версии 2 и 3, Informix версий 5.1, 6.0, 7.1, Ingres, NetWare SQL, ORACLE версий 6 и 7, Progress, Rdb версий 4 и 6, SQL/400 версий 2 и 3, SQLBase версий 5 и 6, SQL Server версий 4 и 6, Sybase версии 4.2, Sybase System 10 и 11, Watcom SQL. Отметим, что поддерживаются как самые современные, так и предыдущие версии основных СУБД (рис.8).
Рис. 8. Выбор СУБД для создания модели
ERwin поддерживает также настольные (desktop) СУБД: Microsoft Access, FoxPro, Clipper, dBASE III, dBASE IV и Paradox.
Проектирование на физическом уровне выполняется в терминах той базы данных, которую предполагается использовать в системе. Важно, что ERwin "известны" соответствия между возможностями СУБД различных производителей, вследствие чего возможно преобразование физической схемы, спроектированной для одной СУБД, в другую.
Для создания физической структуры БД может быть запрошена генерация DDL-скрипта (data definition language). При этом используется диалект SQL для выбранного типа и версии сервера. Хотя сгенерированный код не нуждается в модификации, имеется возможность его сохранить в файл или распечатать.
Поддержка средств 4GL
ERwin выпускается в нескольких различных редакциях, ориентированных на наиболее распространенные средства разработки 4GL. В числе поддерживаемых средств - PowerBuidler фирмы Powersoft, SQL Windows фирмы Gupta, Visual Basic фирмы Microsoft, Oracle*CASE фирмы Oracle.
Средства двунаправленного взаимодействия ERwin с базой данных обеспечивают управление информацией, ориентированной как на серверную, так и на клиентскую часть. Например, для PowerBuilder можно просматривать/редактировать расширенные атрибуты в редакторах ERwin.
Ориентация ERwin на средства 4GL позволяет задать для будущих приложений большинство параметров, непосредственно связанных с базой данных, уже на стадии проектирования информационной модели.
Покажем принципы организации такого взаимодействия на примере PowerBuilder.
PowerBuilder создает в базе данных несколько внутренних таблиц для хранения своего репозитария (расширенных атрибутов для datawindow). Использование расширенных атрибутов гарантирует сохранение стиля отображения одних и тех же колонок базы данных для всех приложений, создаваемых рабочей группой. В расширенных атрибутах задаются такие параметры, как формат отображения, стиль редактирования, выражение проверки на корректность, начальное значение, выравнивание, ширина и высота элемента отображения, метка для формы редактирования, заголовок для табличного отображения.
Для расширенных атрибутов допустимы те же операции синхронизации, что и для всей модели, то есть описания могут быть загружены в базу данных и, наоборот, созданные из среды PowerBuilder описания расширенных атрибутов могут быть загружены из базы данных в ERwin для модификации.
Пример определения расширенных атрибутов показан на рис.9.
Рис. 9. Задание расширенных атрибутов PowerBuilder
Функция ERwin по генерации DataWindow позволяет сгенерировать прототипы окон данных будущего приложения уже на стадии создания информационной модели. Для создания Data Windows предлагается Wizard, с помощью которого указывается стиль окна и выбранные колонки таблиц.
Нам понадобится понятие аномалии - несоответствия между ограничениями целостности концептуальной и логической (а также физической) схем данных. Цель нормализации - это как раз устранение аномалий, проявляющихся при включении, обновлении и удалении данных.
Четыре первые нормальные формы (точнее первая, вторая, третья и Бойса-Кодда) объединяются в одну группу потому, что их определения основаны на классическом понятии функции, заданной на схеме отношения, и на теореме Хиса.
Еще две нормальные формы (четвертая и пятая) используют модифицированные функциональные зависимости . Последняя нормальная форма - домен- ключ - знаменует возвращение к истокам - логическому подходу к реляционной теории.
Будет рекомендован практический способ получения схемы базы в первых четырех нормальных формах, почти всегда дающий окончательный вариант схемы. Правильность этого построения необходимо будет проверять формальными методами, то есть нужны и эвристические приемы и теория нормализации.
Обговорим сначала принятый способ изложения материала по нормализации. Мы, естественно, будем исходить из теории нормализации, развитой в рамках реляционной модели данных. Однако опыт показал, что при таком изложении начинающие с трудом усваивают важнейшее понятие аномалии, определяемое как некоторая характеристика "неправильности" отображения концептуальной модели бизнеса в модель базы данных . Поэтому
мы воспользуемся уже известным вам отображением реляционной модели в модель " сущность-связь " и в ER-модели будем изучать нормализацию. Это позволит привлечь семантику, необходимую для работы с аномалиями.
Давайте еще раз вспомним о связях между отношениями, о соединении отношений и о внешних ключах.
5.1 Связи и внешние ключи
В предыдущих главах изучались понятия соединения сущностей и связей между ними. Будем четко различать их. Понятие связи по своей природе не алгебраическое, так как связи активны. В реализациях связи задают структуру базы, работают при манипуляциях данными и при изменениях схемы. Соединение - понятие алгебраическое. Смысл данных, полученных при выполнении соединения, полностью на совести разработчика. Смысл связи жестко задается моделируемым бизнесом.
Семантика связей достаточно развита. Кроме мощности концов, используются такие свойства как обязательность, свойство идентифицируемости. В реляционной модели выразить их напрямую нельзя (нет таких слов). Поэтому первые нормальные формы будем рассматривать в рамках модели "сущность-связь".
Связи между отношениями/сущностями и в реляционной модели и в ER-диаграммах образуются ссылочным ограничением целостности, которое называется "внешний ключ" ("Foreign Key" - сокращенно FK).
Чтобы не создавать ложного представления о бедности реляционной модели как невозможности реализации чего-то, вспомним, что в ней связь п: т представляется через две связи 1: n, что сложные связи можно моделировать различными способами. Даже агрегаты можно как-то представить, вводя сущности, описывающие их состав. Такие модели могут эффективно реализоваться в программе, но, скорее всего, они будут неудобными для человека. Возможности моделирования структур данных в рамках реляционной модели достаточно широки но, конечно, не безграничны.
Обговорим общий подход к анализу структур, которые будут разбираться в дальнейшем на примере двух связанных сущностей "Сотрудник" и "Отдел", проиллюстрированном на рисунке 5.1 . Слева вариант с идентифицирующей связью, справа с неидентифицирующей.
Рис.
5.1.
Пример связей "один-ко-многим"
Хочу еще раз напомнить о том, что примеры мы договорились рассматривать такими, как они описаны в тексте, а не так, как бывает или может быть в жизни. Это ограничение необходимо, чтобы информация воспринималась всеми и всегда одинаково.
В обоих вариантах схемы каждый сотрудник причисляется к одному из отделов. Имеем связь ("ко-многим" на стороне отношения "Сотрудник"). В отношении "Сотрудник" нельзя выбрать номер отдела deptno, несуществующий в списке отделов (сущность "Отдел"). В одном отделе может быть ни одного, один, два и более сотрудников.
Мы отметили по поводу похожего примера (раздел 2.2.7), что образуется парадоксальная ситуация. Директор причислен к какому-то отделу, а начальник этого отдела и подчинен директору и одновременно будет его же начальником. Но может быть отделы - это центры затрат, и зарплату директора решили относить на расходы одного из отделов. В наших учебных примерах не стоит заниматься такими деталями, если, конечно, не оговорено противное. Вы должны с самого начала привыкать в числе прочего думать о стороне бизнеса, но при решении учебных задач не следует расширять задания до анализа возможных вариантов.
В чем же разница между схемами на рисунке 5.1 ? Идентифицирующая связь заставляет думать о сотруднике в первую очередь как о работнике отдела. Неидентифицирующая связь означает, что принадлежность к отделу отмечается как нечто второстепенное.
5.2 Типы связи. Идентифицирующие и неидентифицирующие, обязательные и необязательные связи
Типы связи идентифицирующая и неидентифицирующая (см. рисунок 5.1) относится не к теории реляционных баз данных, а к стандарту моделирования IDEF1X, на котором основан ERwin (он же AllFusion Data Modeller).
Если внешний ключ создает зависимую (слабую) сущность, то он передается в группу атрибутов, образующих первичный ключ этой сущности. В этом случае образуется идентифицирующая связь. Она всегда обязательная.
Неидентифицирующая связь используется для соединения двух сильных сущностей. Она передает ключ в область неключевых атрибутов.
Для неидентифицирующей связи можно указать обязательность (всей связи, а не ее конца). Если связь обязательна (в ERwin это задание признака No Nulls), то атрибуты внешнего ключа получат признак NOT NULL, означающий недопустимость неопределенных значений. Для необязательной связи (признак Nulls Allowed) внешний ключ может принимать значение NULL .
После того, как в "Язык SQL" мы познакомимся с языком SQL, используя прямой инжиниринг, можно будет генерировать скрипт SQL создающий фрагмент схемы базы. Но и сейчас, если вы уже хотя бы немного знакомы с SQL, то, пройдя путь Tools > Forward Engineer/Schema Generation, а затем нажав кнопку Preview, просмотрите сгенерированный текст.
Зачем при рассмотрении нормализации мы собираемся использовать более сложную модель "сущность-связь", а не ограничиваемся классическим подходом в рамках реляционной модели? Ведь добавление понятий сильной и слабой сущностей, идентифицирующей связи, обязательной и необязательной неидентифицирующей связей существенно усложняет семантику модели данных.
Введение перечисленных пяти понятий более высокого уровня дает язык, лучше отражающий особенности задачи и потому более понятный разработчику. Это позволит быстро и без формальных преобразований получить исходную схему реляционной базы почти в законченном виде (позже мы эту мысль выразим точнее: "в третьей нормальной форме или нормальной форме Бойса-Кодда").
Описание интерфейса ERwin. Интерфейс CASE - средства ERwin состоит их трех основных частей. Первая - это главное меню и панели инструментов.
Кнопки на панелях инструментов повторяют некоторые основные команды в главном меню. Сохранить, открыть, создать новый файл, панель с кнопками увеличения или уменьшения масштаба отображение модели, переключатель между физической и логической моделью, переключатель между хранимыми отображениями, панель для редактирования стиля, размера и цвета шрифтов, панель с инструментами для построения геометрических фигур и несколько вспомогательных панелей инструментов (рис. 5.3).
Рис. 5.3.
Вторая - это Model Explorer. Она содержит три закладки: Model, Subject Areas и Domains. Чаще всего в Model Explorer применяется закладка Domains или Model (которая содержит все объекты и модели). В Domains отображаются соответственно домены, в Subject Areas - отображаемые области (рис. 5.4).
Рис. 5.4.
И третья - непосредственно область, отведенная для создания модели объектов, в которой создаются и редактируются все объекты модели. Снизу появляются закладки с именами запомненных хранимых отображений (Stored Displays) (рис. 5.5).
Рис. 5.5.
ERwin имеет два уровня представления данных модели: логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, например «Заказчик», «Цех» или «Фамилия сотрудника». Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели на логические и физические позволяет решить много важных задач.
ERwin имеет несколько уровней отображения диаграммы: уровень сущностей, уровень атрибутов, уровень определений, уровень первичных ключей и уровень иконок. Переключиться между первыми тремя уровнями можно с использованием кнопок панели инструментов. Переключиться на другие уровни отображения можно при помощи контекстного меню, которое появляется, если «кликнуть» по любому месту диаграммы, не занятому объектами модели. В контекстном меню следует выбрать пункт Display Level и затем необходимый уровень отображения. ERwin позволяет связать с сущностью большую и малую иконки. При переключении на уровень иконок показывается большая иконка. Для отображения малой иконки следует выбрать в контекстном меню пункт Entity Display/Entity Icon. Маленькая иконка будет показана слева от имени сущности на всех уровнях отображения модели.
Установка цвета и шрифта. Установить шрифт и цвет объектов в ERwin можно несколькими способами. Во-первых, для установки цвета и шрифта объекта служит Font and Color Toolbar, которая располагается под основной панелью. Для редактирования шрифта и цвета конкретного объекта следует, щелкнув правой кнопкой мыши по сущности или связи и выбрав из всплывающего меню пункт Object Font & Color..., вызвать диалог Font/Color Editor, в котором определяются имя, описание и комментарии сущности. В диалоге Font/Color Editor можно выбрать шрифт и установить его размер, стиль и цвет, установить цвет заливки (свойство Fill Color, только для сущностей) и цвет линий (свойство Outline Color, только для сущностей).
При создании реальных моделей данных количество сущностей и атрибутов может исчисляться сотнями. Для более удобной работы с большими моделями в ERwin предусмотрены подмножества модели (Subject Areas), в которые можно включить тематически общие сущности. В подмножество модели может входить произвольный набор сущностей, связей и текстовых комментариев. Для создания, удаления или редактирования подмножеств модели нужно вызвать диалог Subject Areas (меню Model/Subject Areas...), в котором указывается имя подмножества и входящие в нее сущности. Все изменения, сделанные в любой Subject Area, автоматически отображаются на общей модели. Одна и та же сущность может входить в несколько Subject Area.
Хранимое отображение (Stored Display) - представление подмножества модели, отображающее специфический аспект структуры данных. Одна Subject Area может включать в себя несколько хранимых отображений. В хранимое отображение входят те же самые сущности и связи, что и в Subject Area, но они могут по-разному располагаться на экране, иметь разные уровни, различный масштаб и цвет объектов или фона.
Для создания хранимого отображения служит диалог Stored Displays (меню Format/Stored Display Settings...). Для переключения между хранимыми отображениями служат закладки в нижней части диаграммы.
Основные компоненты диаграммы ERwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.
Создание логической модели данных предметной области «Мебель под заказ». Создаваемая логическая модель повторяет структуру проектируемой ИС. Для того чтобы создать сущность в области для создания моделей объектов, необходимо (убедившись предварительно, что вы находитесь на уровне логической модели: переключателем между логической и физической моделью служит раскрывающийся список в правой части панели инструментов) «кликнуть» по кнопке сущности на панели инструментов (ERwin Toolbox) Q , затем «кликнуть» по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Properties..., можно вызвать диалог Entities, в котором определяются имя, описание и комментарии сущности (например, имя сущности - поставщик, описание - данные о поставщике). Каждая сущность определяется с помощью текстового описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев к сущности. Следующим шагом является создание атрибутов сущности. Как было указано выше, каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом. Для создания атрибутов следует, «кликнув» правой кнопкой по сущности, выбрать в появившемся меню пункт Attributes.... Появляется диалог Attributes. Если щелкнуть по кнопке New..., то в появившемся диалоге New Attribute указываем имя атрибута, имя соответствующей ему в физической модели колонки и домен (например, имя атрибута - наименование поставщика). Домен атрибута будет использоваться при определении типа колонки на уровне физической модели. Для атрибутов первичного ключа в закладке General диалога Attributes необходимо сделать пометку в окне выбора Primary Key.
Для отображения иконки атрибута следует выбрать в контекстном меню пункт Entity Display и в каскадном меню включить опцию Attribute Icon. Малая иконка будет показана слева от имени атрибута на уровне атрибутов отображения модели. Имя сущности показывается над прямоугольником, изображающим сущность, список атрибутов сущности - внутри прямоугольника. Список разделен горизонтальной чертой, выше которой расположены атрибуты первичного ключа, ниже - неключевые атрибуты. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов. Например, создание в сущности Поставщик атрибута Телефоны поставщика противоречит требованиям нормализации, поскольку атрибут должен быть атомарным, т. е. не содержать множественных значений. Согласно синтаксису IDEF1X имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). Каждый экземпляр сущности должен быть уникален и отличаться от других атрибутов. Следующим шагом создания модели является установление связей между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases рис. 5.6). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например:
Каждый ЗАКАЗЧИК ЗАКАЗы;
Каждый ЗАКАЗ ДИЗАЙН.
Рис. 5.В. Имя связи - Relationship Verb Phrases
Для создания новой связи следует:
- установить курсор на нужной кнопке в палитре инструментов (идентифицирующая или неидентифицирующая связь) и нажать левую кнопку мыши;
- щелкнуть сначала по родительской, а затем по дочерней сущности. При установлении связей между сущностями атрибуты первичного ключа родительской сущности мигрируют в качестве внешних ключей в дочернюю сущность. По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Relationship Display и в контекстном меню включить опцию Verb Phrase.
Логическая модель данных предметной области «Мебель под заказ» приведена на рис. 5.7.
Рис. 5.7.
Полная атрибутивная модель представляет данные в третьей нормальной форме и включает все сущности атрибуты и связи и представлена на рис. 5.8.
На уровне сущностей модель представлена на рис. 5.9.
На рис. 5.10 представлена модель данных на уровне определений.
Рис. 5.8.
Рис. 5.Э. Уровень сущностей модели данных
Лабораторная работа № 5
Цель работы:
Задание:
Последовательность выполнения работы
Знакомство с пользовательским интерфейсом
· Загрузите программу Erwin.
· В появившемся диалоговом окне установите переключатель Crеаte а New Model. На экране появится диалог Create Model – Select Template, гденеобходимо выбрать уровень моделирования.
Erwin имеет два уровня моделирования: логический и физический. На логическом уровне данные представляются так, как они выглядят в реальном мире. Объектами логического уровня являются сущности и атрибуты.
На физическом уровне модель зависит от конкретной реализации базы данных, выбираемой пользователем. При переходе модели на физический уровень производится трансформация сущностей в таблицы, а атрибутов в поля, поэтому все имена и описания физической модели должны соответствовать принятым для выбранной СУБД соглашениям.
· Установите переключательLogical/Physical для создания модели с логическим и физическим уровнями.
· В полях DataBase и Version указывается тип и версия сервера, для которого создается модель. Выберите в списке Access, 2000. Нажмите кнопку ОК .
· На экране появится основное окно программы.
В верхней части окна находится титульная строка, в которой указано название программы, наименование модели, наименование подмножества (Subject Area) и хранимого отображения (Stored Display). Основную часть пространства программы занимает рабочая область, в которой создается ER-диаграмма.
Для переключения между логическим и физическим уровнями на панели инструментов имеется список (рис 1.1).
Помимо этого списка, на панели инструментов имеются кнопки (см. табл. 1.1).
Таблица 1.1.
Кнопки, расположенные на панели инструментов программы Erwin
| Кнопка | Назначение |
 | Создание, открытие, сохранение и печать модели |
| Вызов диалога Report Browser для генерации отчетов | |
| Изменение уровня просмотра модели: уровень сущностей, уровень атрибутов, уровень определений | |
 | Изменение масштаба просмотра модели |
| Генерация схемы БД, выравнивание схемы с моделью и выбор сервера (доступны только на уровне физической модели) | |
| Переключение между областями модели Subject Area |
Для непосредственной работы с элементами модели в программе имеется палитра инструментов (Erwin Toolbox), представляющая собой «плавающее окошко» (рис. 1.2). При необходимости палитру инструментов можно убирать с экрана и вызывать нажатием комбинации клавиш «CTRL-T».
Рис. 1.2. Палитра инструментов на логическом уровне
Внесение в модель сущностей
На данном этапе необходимо внести в модель следующие сущности, выявленные в результате анализа предметной области (поставка товара в соответствии с договорами): покупатель, договор, накладная, товар, склад.
· Выберите на панели инструментов (ERwin Toolbox) кнопку Сущность ,щелкнув по ней указателем мыши. Затем щелкните мышкой по тому месту на диаграмме, где необходимо расположить новую сущность. На поле диаграммы появится прямоугольник, изображающий новую сущность, с автоматически сгенерированным именем «Е/1».
· Введите с клавиатуры имя сущности «Покупатель » и нажмите Enter .
· Точно таким же образом вставьте в диаграмму еще четыре сущности: договор, накладная, товар, склад.
· Щелкнув правой кнопкой мыши по сущности и выбрав из контекстного меню пункт Entity Properties , можно вызвать редактор сущностей Entities (рис. 1.6), который позволяет изменять свойства выбранной сущности. Редактор сущностей также можно вызвать через главное меню: Model | Entities.
 |
Рис. 1.6. Редактор сущности
В верхней части окна редактора находится список всех сущностей, имеющихся на диаграмме. С его помощью можно выбрать сущность, свойства которой необходимо посмотреть или изменить. По умолчанию, выбранной является выделенная на диаграмме сущность, по которой щелкнули мышью. Далее имеется поле Name, в котором высвечивается имя сущности. Имя можно редактировать.
Ниже в окне редактора находится ряд закладок:
Definition (определение) – на этой странице вводится определение сущности.
Note, Note2, Note3 (примечание) – используются для ввода произвольного текста, связанного с сущностью, например, образцы данных и запросы.
UDP – определяемые пользователем свойства.
Icon (иконка) – для наглядности каждой сущности может быть присвоена иконка, которая выводится рядом с ее названием.
· Для каждой сущности введите определение Definition.
Ключевые группы
· Вызовите редактор ключевых групп Key Groups, щелкнув правой кнопкой мыши по сущности Покупатель и выбрав из контекстного меню пункт Key Groups . Редактор ключевых групп также можно вызвать через главное меню: Model | Key Groups.
Редактор ключевых групп содержит элементы управления:
Entity – поле с выпадающим списком, в котором следует выбрать сущность для редактирования.
Окно с перечнем ключевых групп. Каждая группа представлена отдельной строкой, включающей в себя имя (Key Group), тип (Type) и определение (Definition).
Кроме того, диалоговое окно редактора ключевых групп содержит следующие закладки:
ü Members (члены). Задаются члены ключевых групп и их порядок следования в группе.
ü General (общие установки). Переключатели, позволяющие задавать тип ключевой группы. Для первичного и внешнего ключа эти группы недоступны.
ü Definition (определение). Произвольная текстовая информация, относящаяся к выбранной ключевой группе.
ü Note (примечание). Примечание к выбранной группе.
ü UDP (пользовательские свойства).
· Нажмите кнопку New .
· В окне New Key Group в поле Key Group введите имя ключевой группы – ИНН . В поле Index выводится генерируемое программой Erwin имя индекса. Оставьте его без изменений.
· Переключатель Key Group Type задает тип создаваемого ключа. Это может быть альтернативный ключ (Alternate Key) или инверсный вход (Inversion Entry). Выберите Alternate Key и нажмите ОК . Вновь введенный альтернативный ключ появится в перечне ключей.
 |
Перейдите на закладку Members . Новый ключ пока не содержит никаких атрибутов, поэтому правый список Key Group Members (члены ключевой группы) пуст. Выберите в левом списке атрибут ИНН и переместите его в правый список при помощи кнопки со стрелкой (см. рис. 1.8).
Рис. 1.8. Редактор ключевых групп
· Таким же образом создайте ключевые группы для инверсных входов, приведенных в табл. 1.3.
Лабораторная работа № 6
Задание правил декларативной ссылочной целостности
· Находясь на логическом уровне модели данных, выделите связь «заключает» между сущностями Покупатель и Договор, щелкнув по ней указателем мыши. Затем нажмите правую кнопку мыши и в контекстном меню выберите пункт Relationship Properties (редактор связей).
· В окне редактора связей Relationship перейдите на вкладку RI Actions . Ознакомьтесь с правилами ссылочной целостности для связи «Покупатель – Договор», присвоенными по умолчанию. Данные установки запрещают вставку и изменение экземпляра дочерней сущности, а также удаление и изменение родительской сущности. Это означает, что не допускается удаление или изменение покупателя, если в базе данных имеются заключенные с ним договоры, а также ввод договора без указания покупателя или со ссылкой на несуществующего покупателя. Тем самым мы выполнили условие, по которому договор может существовать только для конкретного покупателя.
· Проанализируйте установленные правила ссылочной целостности для всех остальных связей.
Правила, присваиваемые связи по умолчанию, можно изменить, выбрав нужное значение из выпадающего списка.
Нормализация данных
Из модели видно, что в сущности Покупатель присутствует множественный атрибут ТЕЛ. Покупатель может иметь несколько телефонных номеров, что является нарушением первой нормальной формы, согласно которой все значения атрибутов должны быть атомарными. Поэтому необходимо выделить атрибут ТЕЛ в отдельную сущность.
· Создайте сущность Телефон, содержащую следующие атрибуты: КОД_ТЕЛ (первичный ключ, тип – number) и ТЕЛ (тип – string).
· Свяжите сущности Покупатель и Телефон идентифицирующей связью. Установите мощность связи – One or More (P) и введите имя связи – имеет.
Выбор сервера
· Выполните команду Database | Choose Database .
· В диалоговом окне Erwin/ERX – Target Server необходимо задать тип сервера – Access и его версию – 2000 . Кроме того, здесь указывается используемый по умолчанию тип данных и условие NULL для вновь созданных колонок. Некоторые опции данного диалогового окна зависят от выбранного типа сервера.
· После выбора сервера нажмите кнопку ОК .
Денормализация данных
На модели имеются две связи типа «многие-ко-многим»: Товар – Договор и Товар – Накладная, которые должны быть разрешены на физическом уровне. Результат разрешения данных связей представлен в табл. 2.1.
Таблица 2.1.
Результат разрешения связей «многие-ко-многим»
Разрешение связей «многие-ко-многим» осуществляется автоматически при переходе на физический уровень, либо с помощью специального мастера Many Relationship Transform Wizard .
· Для вызова данного мастера выделите связь «Товар – Договор», щелкнув по ней указателем мыши. Затем нажмите правую кнопку мыши и в контекстном меню выберите пункт Create Association Table (создать ассоциативную таблицу). На экране появится первый диалог мастера, содержащий текст о его назначении.
· Введите в поле Table Name (имя таблицы) – Поставка_План . В поле Table Comment (комментарии к таблице) введите текст: Сведения о поставках товара по договору.
· На модели появилась новая таблица Поставка_План, связанная идентифицирующей связью с таблицами Товар и Договор.
· Новую таблицу необходимо дополнить тремя колонками (см. табл. 2.1). Для этого выделите таблицу Поставка_План , щелкнув по ней указателем мыши. Затем нажмите правую кнопку мыши и в контекстном меню выберите пункт Columns (редактор колонок). Работа с данным редактором аналогична работе с редактором атрибутов.
· Самостоятельно введите три новых колонки в соответствии с табл. 2.1.
· Рассмотренным выше способом (с использованием мастера) преобразуйте связь «Товар – Накладная» и дополните полученную ассоциативную таблицу Отгрузка двумя колонками согласно табл. 2.1.
Задание правил валидации
Задание списка допустимых значений
В соответствии с рассматриваемой предметной областью для поля СТАВКА_НДС таблицы Товар зададим список допустимых значений: 0, 10 и 18 %.
Columns.
· В окне редактора в поле Column – СТАВКА_НДС .
· Перейдите на закладку выбранной СУБД – Access .
· Valid .
· В диалоге Validation Rules щелкните по кнопке New .
· В диалоге New Validation Rule вполе Logical введите имя правила – Проверка ставки НДС . Нажмите кнопку ОК .
· Перейдите на закладку General . В группе Type установите опцию Valid Value List .
· В поле Valid Value в первой строке введите 0. Во вторую и третью строки введите значения: 10 и 18.
· Проверьте, чтобы в верхней части окна редактора Validation Rules появилась строчка: Проверка ставки НДС (Validation Name) IN (0, 10, 18) (Validation Rule).
· Нажмите ОК. В окне редактора Columns на закладке Access в поле Valid появилось наименование созданного правила – «Проверка ставки НДС».
Задание значений, присваиваемых по умолчанию
Создадим правило, согласно которому в поле ДАТА_ДОГ таблицы Договор будет по умолчанию подставляться значение текущей даты.
· Вызовите контекстное меню таблицы Договор и выберите пункт Columns.
· В окне редактора в поле Column выберите колонку, для которой будет задаваться правило– ДАТА_ДОГ .
· На закладке Access щелкните по кнопке, расположенной справа от раскрывающегося списка Default .
· В диалоговом окне Default/Initial Values щелкните по кнопке New .
· В диалоге New Default Value вполе Logical введите имя правила – Текущая дата . Нажмите кнопку ОК .
· На закладке Access в поле Server Value – Access Default введите Date() (функцию, получающую значение текущей даты).
· Нажмите ОК. В окне редактора Columns на закладке Access в поле Default появилось наименование созданного правила – «Текущая дата».
· Установите это же правило для поля ДАТА_ОТГР таблицы Накладная. Для этого в окне редактора колонок Column выделите поле ДАТА_ОТГР и на закладке Access в поле Default из раскрывающегося списка выберитеправилоТекущая дата.
Задание правил проверки вводимых значений
Создадим правило проверки вводимых значений для поля ЦЕНА таблицы Товар, согласно которому данное поле не может иметь значения, меньшие 0.
· Вызовите контекстное меню таблицы Товар и выберите пункт Columns.
· В окне редактора в поле Column выберите колонку, для которой будет задаваться правило– ЦЕНА .
· На закладке Access щелкните по кнопке, расположенной справа от раскрывающегося списка Valid .
· В диалоге Validation Rules щелкните по кнопке New .
· В диалоге New Validation Rule вполе Logical введите имя правила – Проверка цены . Нажмите кнопку ОК .
· Перейдите на закладку General . В группе Type установите опцию Min/Max .
· В поле Min введите 1. Кроме нижней границы диапазона значений здесь также можно задать и верхнюю границу (Max ).
· В верхней части окна редактора Validation Rules в списке правил валидации добавилось вновь созданное: Проверка цены >=1.
· Нажмите кнопку ОК .
Лабораторная работа № 7
Расчет размера базы данных
Цель работы:
Освоить методику расчета размера базы данных, реализованную в Erwin.
Лабораторная работа № 8
Создание отчетов в Erwin
Цель работы:
· изучение видов отчетов;
· освоение процедуры создания отчетов
Лабораторная работа № 5
Основы работы в Erwin. Построение логической модели данных
Цель работы:
· овладение навыками работы в Erwin;
· построение логической модели заданной предметной области.
Задание:
Построить логическую информационную модель поставки товаров в соответствии с договорами средствами Erwin.