Идентифицирующая связь erwin. Построение моделей в ERwin. Задание правил декларативной ссылочной целостности

Лабораторная работа №4. Определение связей между сущностями в ERwin

Как отмечалось в упражнении 3, для построения логической модели дан - ных, прежде всего, необходимо определить набор сущностей и задать связи меж- ду ними. На упражнении 3 была создана диаграмма, содержащая четыре сущно - сти (рисунок 4.1). Методику определения связи между ними мы рассмотрим на текущем упражнении.

https://pandia.ru/text/78/177/images/image002_182.gif" width="123" height="128 src=">ется генерируемая по умолчанию глагольная фраза - «R/1» (рисунок 4.2).

Рисунок 4.2 - Неидентифицирующая связь

Шаг 3. Перейдите на уровень атрибутов и обратите внимание на то, что у сущно- сти «Учебное место» добавился атрибут первичного ключа от сущности «Класс» и помечен буквами «FK». Говорят, что атрибут «мигрировал», a FK (foreign key) означает, что атрибут является частью внешнего ключа (рисунок 4.3). Для иден - тифицирующей связи внешний ключ всегда входит в первичный ключ дочерней

сущности, для неидентифицирующей не входит.

Рисунок 4.3 - Миграция атрибутов

Шаг 4. Назначьте связи глагольную фразу. Для этого выделите связь, щелкнув по ней указателем мыши, затем нажмите правую кнопку мыши и в контекстном ме - ню выберите пункт «Relationship Properties… » (свойства отношений).

Общий вид окна редактора связей показан на рисунке 4.4.

DIV_ADBLOCK223">

1 «Zero, One or More» (ноль, один или более) - каждый экземпляр родитель - ской сущности связан с нулем, одним или более экземпляров дочерней сущности. Говоря «связан с нулем экземпляров», мы имеем в виду, что ро - дительский экземпляр может быть не связан ни с одним экземпляром до- черней сущности.

2 «One or More (P)» (один или более) - каждый экземпляр родительской сущ-

ности связан с одним или более экземпляром дочерней сущности.

3 «Zero or One (Z)» (ноль или один) - каждый экземпляр родительской сущно - сти связан с нулем экземпляров или с одним экземпляром дочерней сущно - сти.

4 «Exactly» (точно) - каждый экземпляр родительской сущности связан с за - данным количеством экземпляров дочерней сущности. Рядом находится по - ле, где необходимо ввести это количество.

Тип связи выбирается в области «Relationship Type». Связь может быть иденти - фицирующая (Identifying) и неидентифицирующая (Non-Identifying). Кроме того, для неидентифицирующей связи задается обязательность (Nulls), которая показы - вает, может ли атрибут внешнего ключа принимать значение NULL в таблице БД. Это свойство используется потом при генерации физической схемы базы данных . В нашем примере, так как при анализе предметной области мы выяснили, что учебное место не может существовать отдельно от класса, установите этот пе - реключатель в позицию «No Nulls». Тем самым накладывается условие, что у су- ществующего экземпляра рабочего места всегда должна быть ссылка на класс, в который оно входит.

Закладка «Definition» (определение).

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

Закладка «Rolename» (Имя роли)

Имя роли (rolename) - это дополнительная характеристика, которая может при-

сваиваться мигрирующему атрибуту первичного ключа (рисунок 4.5).

https://pandia.ru/text/78/177/images/image006_79.gif" width="358" height="221 src=">

Рисунок 4.6 – Контекстное меню диаграммы для отображения мигрирующих атрибутов сущностей

Закладка «RI Actions» (Установки ссылочной целостности)

Закладка предназначена для задания параметров ссылочной целостности проек-

тируемой базы данных (рисунок 4.7).

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

Существуют следующие виды действий или правил, определяемых в логической модели:

1 RESTRICT - запрет удаления, вставки или изменения экземпляра сущности

2 CASCADE - при удалении экземпляра родительской сущности удаление всех экземпляров дочерней сущности, ссылающихся на удаляемый роди- тельский экземпляр.

3 SET NULL - при удалении экземпляра родительской сущности атрибутам внешнего ключа всех экземпляров дочерней сущности, присваивается зна - чение NULL.

4 SET DEFAULT - то же самое, что и в предыдущем случае, только вместо значения NULL присваивается значение по умолчанию.

5 NONE - никаких действий не предпринимается.

Рисунок 4.7 – Закладка «RI Actions» (Установки ссылочной целостности)

Эти правила задаются на вставку, удаление и изменение экземпляра как родитель - ской, так и дочерней сущности. Таким образом, каждая связь должна обладать на - бором из шести правил, которые вводятся в поля, объединенные общим заголов - ком «RI Actions». При добавлении связи в диаграмму ERwin по умолчанию уста - навливает для нее набор правил, которые можно редактировать в диалоге «Model Properties» (Свойства модели) на вкладке «RI Defaults»(рисунок 4.8), вызываю-

щемся путем выбора из главного меню команды «Model» Server» и, далее, подко-

манды «Model Properties» (рисунок 4.9).

https://pandia.ru/text/78/177/images/image009_57.gif" width="227" height="289 src=">

Рисунок 4.9 – Порядок вызова диалогового окна «Model Properties»

Правила, присваиваемые связи по умолчанию, можно изменить, выбрав нужное значение из выпадающего списка (см. рисунок 4.8). При нажатии на кнопку «Re - bind» (переназначить) новые установки умолчаний переносятся в текущую мо-

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

Каждый тип связи имеет, в зависимости от вида действия, свой набор допустимых правил, приведенный в таблице 4.2.

Таблица 4.2 - Набор допустимых правил для различных типов связей

действия	Тип связи (Relationship Type)
Идентифици-	Неидентифици- рующая (Non- Identifying, Nulls	Неидентифици- рующая (Non- Identifying, No	ная связь
(удаление дочернего объекта)			CASCADE, NONE SET NULL,	CASCADE, NONE SET DEFAULT
(вставка дочернего объекта)			CASCADE, NONE SET NULL,	CASCADE, NONE SET DEFAULT
(изменение дочернего объекта)			CASCADE, NONE SET NULL, SET DE - FAULT	CASCADE, N6NE SET
(удаление родитель - ского объ- екта)			CASCADE, NONE SET	CASCADE, NONE SET
(вставка родитель - ского объ- екта)			CASCADE, NONE SET NULL,	CASCADE. NONE SET DEFAULT
(изменение родитель - ского объ - екта)			CASCADE, NONE SET	CASCADE, NONE SET

Установки для связи «Класс - Учебное место», присвоенные по умолчанию, за - прещают вставку и изменение экземпляра дочерней сущности, а также удаление и изменение родительской сущности. Это означает, что не допускается удаление

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

Закладка «UDP» (Параметры устанавливаемые пользователем)

Закладка - UDP, как и у предыдущих объектов диаграммы, позволяет присвоить связи свой набор пользовательских свойств.

Итак, мы создали неидентифицнрующую связь между сущностями «Класс» и

«Учебное место» с условием «No Nulls». Очевидно, связь того же типа должна существовать между сущностями «Тип оборудования» и «Единица оборудова- ния», так как единица оборудования обязательно должна иметь тип. Внесите эту связь в диаграмму, выполнив те же действия, что и в предыдущем случае. Вызо - вите редактор связей и измените глагольную фразу на «описывает», остальные установки связи оставьте неизменными. Обратите внимание, что атрибут «код ти- па оборудования» мигрировал в состав неключевых атрибутов сущности «Учеб- ное место» (рисунок 4.10).

Рисунок 4.10 – Атрибут «код типа оборудования» мигрировал в состав неключевых атрибутов сущности «Учебное место»

Рассмотрим теперь связь между сущностями «Учебное место» и «Единица обору- дования». Как мы выяснили при обследовании предметной области, единицы оборудования образуют некий фонд комплектующих, часть из которых установ - лена в учебные места. Другая часть комплектующих может находиться на складе, быть неисправной и дожидаться списания и т. п., то есть существовать отдельно от учебного места. Таким образом, сущности «Учебное место» и «Единица обо- рудования» не зависят друг от друга, и должны быть ассоциированы неиден - тифицирующей связью.

Шаг 5. Выберите неидентифицирующую связь в палитре инструментов и внесите ее в диаграмму, выбрав «Учебное место» в качестве родительской сущности, а

«Единицу оборудования» - дочерней. В редакторе связи измените глагольную фразу «Parent-to-Child» на «состоит из». Неидентифицирующая связь имеет две разновидности - допускающая значения NULL (Nulls Allowed) и не допускающая (No Nulls). По умолчанию выбирается разновидность «Nulls Allowed», оставьте это без изменений. Такая установка означает, что у экземпляра сущности «Едини - ца оборудования» поля внешнего ключа могут иметь нулевое значение, то есть

отсутствовать указание на экземпляр «Учебного места». Таким образом, единица оборудования может существовать «сама по себе».

После установки связей диаграмма на уровне сущностей будет иметь вид, пока-

DIV_ADBLOCK229">

В зависимости от типа, связи изображаются на диаграмме по-разному. Графиче- ское изображение зависит и от принятой методологии построения диаграммы. Например, в нотации IDEF1X, используемой в этом примере, принято изображе-

https://pandia.ru/text/78/177/images/image013_25.gif" width="315" height="165 src=">

Рисунок 4.13 – Выбор команд для отображения установок ссылочной целостности

Обозначение ссылочной целостности на схеме представляет собой две алфавит- ные группы, разделенные символом двоеточия «:». Первый символ обозначает действие, к которому относится правило целостности: D - удаление (delete), I - вставка (insert), U - изменение (update).

Вторая группа обозначает правило: R - RESTRICT, С - CASCADE, SN - SET NULL, SD - SET DEFAULT. Таким образом, запрет удаления обозначается D:R, а установка NULL при изменении - U:SN. Обозначения проставляются у родитель- ского или дочернего конца связи, в зависимости от того, к какой сущности они относятся. С включенными установками ссылочной целостности диаграмма вы-

глядит так, как показано на рисунке 4.14.

Рисунок 4.14 - ER-диаграмма с включенными установками ссылочной целостности

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

Шаг 7. На вкладке «Уровень сущностей» сохраните модель, например, под име-

нем Lab_4_Petrov. er1.

Шаг 8. Выполните индивидуальное задание по определению связей между сущ-

ностями в ERwin для указанной предметной области (см. таблица 3.4).

1. Результаты выполнения шагов 1 – 7 программы занятия.

2. Результаты выполнения индивидуального задания.

Контрольные вопросы

1. Как различают зависимые и независимые сущности на диаграмме ERwin?

2. Какая связь между сущностями называется неидентифицирующей?

3. Что такое физическая и логическая модель данных?

4. Какая связь между сущностями называется идентифицирующей?

5. Поясните смысл утверждения о том, что некоторый атрибут «мигрировал»?

6. Что обозначает символика «FK» на диаграмме ERwin?

7. Какими возможностями обладает редактора связей?

8. Каково изображение связей в нотации IDEF1X?

9. Как производится обозначение ссылочной целостности на диаграмме

10.Какие связи между сущностями были использованы при выполнении инди-

видуального задания?

Описание интерфейса 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.Э. Уровень сущностей модели данных

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, с помощью которого указывается стиль окна и выбранные колонки таблиц.

Лабораторна рОбота №3. Моделирование баз данных средствами Erwin

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

Основные сведения

Система ERwin поддерживает прямое и обратное моделирование баз данных. При прямом моделировании схема базы данных описывается в прямом виде с использованием диаграммы сущность-связь. Сущности на диаграмме представляются прямоугольниками. Каждый прямоугольник может иметь различные визуальные атрибуты. Каждой сущности должно быть присвоено уникальное имя. Имена сущностей необходимо задавать в единственном числе. Это определяется тем, что система всегда оперирует отдельными экземплярами сущности. При этом отдельные экземпляры сущности рассматриваются как объекты, а сущности – как класс объектов. Если сущности были описаны при моделировании в BPwin, то их можно просто импортировать в ERwin. Пример диаграммы с созданными сущностями приведен на рисунке.

Рисунок 4 - Пример диаграммы с созданными сущностями

Построение моделей в ERwin

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

ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Термин "логический уровень" в ERwin соответствует концептуальной модели.

Этапы построения информационной модели.

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

Erwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

Создание сущности.

Для внесения сущности в модель необходимо щелкнуть по кнопке сущности на панели инструментов (Erwin Toolbox) , затем - по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности.

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name ). Закладки Note, Note2, Note3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности.

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

Закладка UDP диалога Entity Editor служит для определения свойств, определяемых пользователем (User - Defined Properties). При нажатии на кнопку этой закладки вызывается диалог User - Defined Property Editor (также вызывается из меню Edit/UDPs). В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т.д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке и внести имя, тип данных, значение по умолчанию и определение.

Создание атрибутов.

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

Рисунок 5 - Создание нового домена	Рисунок 6 - Указание свойств нового домена

Рисунок 7 - Значение по умолчанию для нового домена

Рисунок 8 - Использование домена для указания типа данных атрибуту.

Для описания атрибутов следует, щелкнув правой кнопкой по сущности, выбрать в появившемся меню пункт Attribute Editor. Появится диалог Attribute Editor.

Если щелкнуть по кнопке New, то в появившемся диалоге New Attribute можно указать имя атрибута, имя соответствующей ему в физической модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.

Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key.
Закладки Definition, Note и UDP несут те же функции, что и при определении сущности, но на уровне атрибутов.

Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. Это можно сделать при помощи списка выбора Icon в закладке General.

Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение.

Согласно синтаксису IDEF1X, имя атрибута должно быть уникальным в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута ERwin переименовывает его. Например, если атрибут Комментарий уже существует в модели, другой атрибут (в другой сущности) будет назван Комментарий/2, затем Комментарий/3 и т.д.
При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку в палитре инструментов.

Для создания новой связи следует выбрать идентифицирующую или неидентифицирующую связь в палитре инструментов (ERwin Toolbox), щелкнуть сначала по родительской, а затем по дочерней сущности.
В палитре инструментов кнопка соответствует идентифицирующей связи, кнопка связи многие-ко-многим и кнопка соответствует неидентифицирующей связи. Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor.

В закладке General появившегося диалога можно задать мощность, имя и тип связи.

Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Различают четыре типа мощности:

· общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом;

· символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);

· символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);

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

По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Cardinality.

Тип связи (идентифицирующая/неидентифицирующая).

В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю связь в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами.

Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешние ключи - (FK).

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

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

Для неидентифицирующей связи можно указать обязательность (Nulls в закладке General диалога Relationship Editor). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующей отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие-ко-многим следует указывать имена как Parent-to-Child, так и Child-to-Parent. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Verb Phrase.

Имя роли или функциональное имя (Rolename) - это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. Задать имя роли можно в закладке Rolename/RI Actions диалога Relationship Editor.

Создание ключей.

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

Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующие экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии. При внесении нового атрибута в диалоге Attribute Editor для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key в нижней части закладки General. На диаграмме ключевой атрибут можно внести в состав первичного ключа, воспользовавшись режимом переноса атрибутов (кнопка в палитре инструментов).

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

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

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

Альтернативный ключ (Alternative Key) - это потенциальный ключ, не ставший первичным.

Каждому ключу соответствует индекс, имя которого также присваивается автоматически. Имена ключа и индекса при желании можно изменить вручную.

На диаграмме атрибуты альтернативных ключей обозначаются как (Akn.m.), где n - порядковый номер ключа, m - порядковый номер атрибута в ключе. Когда альтернативный ключ содержит несколько атрибутов, (Akn.m.) ставится после каждого.

Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени.

Зависимая сущность может иметь один и тот же ключ из нескольких родительских сущностей. Сущность может также получить один и тот же внешний ключ несколько раз от одного и того же родителя через несколько разных связей. Когда ERwin обнаруживает одно из этих событий, он распознает, что два атрибута одинаковы, и помещает атрибуты внешнего ключа в зависимой сущности только один раз. Это комбинирование или объединение идентичных атрибутов называется унификацией.

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

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

После указания всем атрибутам формата данных необходимо созданную логическую модель преобразовать в физическую. Для этого необходимо в Tools выбрать Derive New Model , где в качестве Target Databases выберите ODBC/Generic (для использования в СУБД MySQL) см. Рисунок 9. Наша модель (см Рисунок 4) будет преобразована к виду см.Рисунок 11.

Рисунок 9 - Преобразование логической модели в физическую

Рисунок 10 - Физическая модель с указанием формата данных.

Рисунок 11 - Генерация кода SQL

Задание

1. Выполните построение диаграммы с заданными сущностями (прямое моделирование) для заданной предметной области.

2. Задайте атрибуты для каждой определенной сущности. При задании атрибутов используйте домены.

3. Введите связи между сущностями. Присвойте связям уникальные имена.

4. Используя СУБД MYSQL, решите прямую генерацию базы данных для проектируемой информационной.

5. Отчет должен содержать концептуальную модель и физическую базу данных в СУБД MYSQL.

Контрольные вопросы

1. В чем состоит различие логического и физического уровней представления моделей данных с помощью ERwin?

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

3. Какие основные компоненты содержат модели данных, представленные по методологии IDEF1X?

Перечень типов данных, поддерживаемых СУБД необходимо уточнить у производителя

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2016-04-27

ERwin имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например "Постоянный клиент", "Отдел" или "Фамилия сотрудника". Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами (подробнее о сущностях и атрибутах будет рассказано ниже). Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов (см. гл. 1). Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.

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

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.

Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС. Заметим, однако, что формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать. Процессы прямого и обратного проектирования будут рассмотрены ниже.

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

Рис. 2.1. Переключение между логической и физической моделью

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

Интерфейс выполнен в стиле Windows-приложений, достаточно прост и интуитивно понятен. В дальнейшем будет описан интерфейс версии Erwin 3.5.2. Рассмотрим кратко основные функции ERwin по отображению модели, а также панель и палитру инструментов. Более подробно элементы интерфейса будут рассмотрены в последующих главах. Элементы панели инструментов описаны в табл. 2.1.

Таблица 2.1. Основная панель инструментов

	Назначение кнопок
	Создание, открытие, сохранение и печать модели
	Вызов диалога Report Browser для генерации отчетов
	Изменение уровня просмотра модели: уровень сущностей, уровень атрибутов и уровень определений
	Изменение масштаба просмотра модели
	Генерация схемы БД, выравнивание схемы с моделью и выбор сервера (доступны только на уровне физической модели)
	Вызов дополнительной панели инструментов для работы с репозиторием Model Mart. (Работа с Model Mart рассмотрена в гл. 4)
	Переключение между областями модели - Subject Area

Палитра инструментов выглядит различно на разных уровнях отображения модели. На логическом уровне (рис. 2.2) палитра инструментов имеет:

1. Слева направо, верхний ряд:

кнопку указателя (режим мыши)

В этом режиме можно установить фокус на каком-либо объекте модели;

кнопку внесения сущности

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

Специальный тип связи между сущностями, которая будет рассмотрена ниже. Для установления категориальной связи нужно щелкнуть левой кнопкой мыши по кнопке категории, затем один раз щелкнуть по сущности - родовому предку, затем - по сущности-потомку;

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

2. Слева направо, нижний ряд:

кнопку перенесения атрибутов внутри сущностей и между ними. Атрибуты могут быть перемещены способом

кнопки создания связей: идентифицирующую, "многие-ко-многим" и неидентифицирующую.

Рис. 2.2. Палитра инструментов на логическом уровне

На физическом уровне (рис. 2.3) палитра инструментов имеет:

вместо кнопки связи "многие-ко-многим" (третья справа кнопка в нижнем ряду) кнопку связей представлений.

Для создания моделей данных в ERwin можно использовать две нотации: IDEF1X и IE (Information Engineering). Методология IDEF1X была разработана для армии США и широко используется в государственных учреждениях США,

финансовых и промышленных корпорациях. Методология IE, разработанная Мартином (Martin), Финкельштейном (Finkelstein) и другими авторами, используется преимущественно в промышленности. Переключение между нотациями

можно сделать в закладке Methodology диалога Preferences (меню Option/Preferences) (рис. 2.4). В дальнейшем будет использоваться нотация IDEF1X.

Рис. 2.3. Палитра инструментов на физическом уровне

Рис. 2.4. Переключение между нотациями

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

ERwin позволяет связать с сущностью большую и малую иконки. При переключении на уровень иконок показывается большая иконка. Для отображения малой иконки следует выбрать в контекстном меню пункт Display Options/Entities и в каскадном меню включить опцию Entity Icon.

Малая иконка будет показана слева от имени сущности на всех.уровнях отображения модели. В табл. 2 2 показаны уровни отображения модели.

Таблица 2.2. Уровни отображения модели

Установка цвета и шрифта. Установить шрифт и цвет объектов в ERwin можно несколькими способами. Во-первых, для установки цвета и шрифта объекта служит панель инструментов Font and Color Toolbar, которая располагается под основной панелью. Значение каждого элемента приведено в табл. 2.3.

Таблица 2.3. Панель инструментов Font and Color Toolbar

	Выбор наименования шрифта
	Выбор размера шрифта
	Выбор стиля шрифта

	Выбор цвета заливки
	Выбор цвета линий

Для редактирования шрифта и цвета конкретного объекта следует, щелкнув правой кнопкой мыши по сущности или связи и выбрав из всплывающего меню пункт Object Font/Color, вызвать диалог Font/Color Editor,

в котором определяются имя, описание и комментарии сущности. Диалог Font/Color Editor имеет три закладки, в которых можно выбрать шрифт и установить его размер, стиль и цвет (закладка Text), установить цвет заливки (закладка Fill, только для сущностей) и цвет линий (закладка Entity Outline, только для сущностей).

Имеется возможность изменить шрифт и цвет для всех объектов модели или для какой-либо отдельной категории объектов. Для этого служит диалог All Default Font/Color Editor (пункт меню Option/Default Font/Color). Каждая закладка на диалоге (рис. 2.5) позволяет редактировать шрифт и цвет для определенной категории объектов:

All Fonts - все объекты модели;

Entity Name - имена сущностей и таблиц;

Entity Definition - определение сущностей и таблиц (показываются на уровне определений, см. табл. 2.2);

Relationship - связи, включая имя и обозначение мощности;

Text Block Text - текстовые блоки;

Page Number - номер страницы при печати диаграммы;

Owned Entity Attributes - атрибуты и колонки, за исключением атрибутов и колонок внешних ключей;

Foreign Key - атрибуты и колонки внешних ключей;

Background Color - цвет фона диаграммы;

Entity Line - линии, которыми прорисовываются сущности и таблицы;

Entity Fill - заливка сущностей и таблиц;

Subtype Fill - заливка символов, обозначающих категории.

Рис. 2.5. Диалог АН Default Font/Color Editor

Иногда при работе Erwin3.X под операционной системой Windows NT в модели "расплываются" надписи - названия сущностей, атрибутов и комментариев. Эта ошибка связана с некорректной настройкой регистров Windows.

Имеется два способа борьбы с расплывающимися надписями при работе с Erwin3.X под NT:

1. При работе использовать заранее подготовленный шаблон. Для этого следует создать новый проект (НЕ ВКЛЮЧАЯ В НЕГО НОВЫЕ СУЩНОСТИ), установить шрифты, работающие корректно при прямом внесении сущностей (подбираются экспериментально),

Option/default font/color/All Fonts/All Objects и сохранить модель как шаблон - File/SaveAs/Files of Type/ERwin Template. При Reverse Engineering в качестве шаблона необходимо выбрать не стандартный шаблон, а вновь созданный.

2. Редактирование регистров NT. В разделе

HKEY_LOCAL_MACHINE

следует установить 204-ю таблицу - DEFAULT 0X000000cc (204).

В разделе

HKEY_LOCAL_MACHINE

следует для всех стандартных шрифтов установить ссылку на 204-ю таблицу, например:

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

модели нужно вызвать диалог Subject Area Editor (меню Edit/Subject Area), в котором указывается имя подмножества и входящие в нее сущности (рис. 2 6) Все изменения, сделанные в любой Subject Area, автоматически отображаются на общей модели. Одна и та же сущность может входить в несколько Subject Area.

Рис. 2.6. Диалог Subject Area Editor

По умолчанию исходная модель получает имя Main Subject Area. При создании нового подмножества следует в диалоге Subject Area Editor указать ее имя и список входящих в него объектов. Для включения сущности в

Subject Area нужно выбрать ее в левом списке диалога и щелкнуть по кнопке . Сущность можно переместить в Subject Area вместе со всеми связанными с ней сущностями. Для этого следует воспользоваться кнопкой ,

причем можно задать уровень взаимосвязи (рис. 2.7) как для сущностей-потомков (Descedants), так и для сущностей-предков (Ancestors).

Рис. 2.7. Диалог задания уровня перемещения сущностей

Например, если в модели сущность Клиент связана с сущностью Заказ, а та в свою очередь с сущностью Предмет заказа, то при перемещении сущности Клиент со связанными сущностями уровня 2 (потомки) будут перемещены все три сущности.

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

список выбора на панели инструментов (см. табл. 2.1). Subject Area можно создавать как в логической, так и в физической модели данных.

В хранимое отображение входят те же самые сущности и связи, что и в Subject Area, но они могут по-разному располагаться на экране, иметь разные уровни (см: табл. 2.2), различный масштаб и цвет объектов или фона.

Для создания хранимого отображения служит диалог Stored Display Editor (меню Edit/Stored Display).

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

При создании Subject Area в нее могут не входить либо родительская, либо дочерняя сущность. По умолчанию связи с сущностями, которые не вошли в Subject Area ("висящие связи"), не показываются. Для отображения таких связей следует включить опцию Show Dangling Relationship в закладке General диалога Stored Display Editor (рис. 2.8).

Хранимое отображение позволяет отобразить линии связей не только ортогональными, но и диагональными. Для представления связей диагональными линиями следует в закладке General выбрать опцию Diagonal (по умолчанию установлена опция Orthogonal).

Рис. 2.8. Диалог Stored Display Editor

Для переключения между хранимыми отображениями служат закладки в нижней части диаграммы (рис. 2.9).

Рис. 2.9. Переключение между хранимыми отображениями

Различают три уровня логической модели, отличающихся по глубине представления информации о данных:

диаграмма

сущность-связь (Entity Relationship Diagram, ERD);

модель данных, основанная на ключах (

Key Based model, KB);

атрибутивная модель (Fully Attributed model, FA).

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

детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют основным требованиям, предъявляемым к ИС. Диаграмма сущность-связь может включать связи многие-ко-многим и не включать описание ключей. Как правило, ERD используется для презентаций и обсуждения структуры данных с экспертами предметной области.

Модель данных, основанная на ключах, - более подробное представление данных. Она включает описание всех сущностей и первичных ключей и предназначена для представления структуры данных и ключей, которые соответствуют предметной области.

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

Основные компоненты диаграммы Erwin - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален

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

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

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

Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущность Заказчик (но не Заказчики !)с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика.

На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address.

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

"кликнуть" по кнопке сущности на панели инструментов (ERwin Toolbox) , затем "кликнуть" по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности (рис. 2.10).

Каждая сущность должна быть полностью определена с помощью текстового описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущности. В прежних версиях ERwin закладкам Note2 и Note3 соответствовали окна Query и Sample.

Закладка Definition используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют понять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name).

Закладка Note позволяет добавлять дополнительные замечания о сущности, которые не были отражены в определении, введенном в закладке Definition. Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-правило или соглашение по организации диаграммы.

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

Рис. 2.10. Диалог Entity Editor

Закладка Note 3 позволяет вводить примеры данных для сущности (в произвольной форме).

В закладке Icon каждой сущности можно поставить в соответствие изображение, которое будет отображаться в режиме просмотра модели на уровне иконок (см. табл. 2.2). В этой закладке можно задать как большую иконку,

которая будет отображаться на уровне Icon, так и малую иконку, которая будет отображаться на всех уровнях просмотра модели. Для связывания изображения с сущностью необходимо щелкнуть по кнопке

В появившемся диалоге ERwin Icon Editor щелкнуть по кнопке Import и выбрать соответствующий файл формата bmp. После выбора иконки она отображается в закладке Icon диалога Entity Editor (рис. 2.11).

Рис. 2.11. Закладка Icon диалога Entity Editor

Использование свойств, определяемых пользователем (UDP), аналогично их использованию в BPwin (см. гл. 1.4). Для определения UDP служит диалог User-Defined Property Editor (вызывается из меню Edit/UDPs).

В нем необходимо указать вид объекта, для которого заводится UDP (диаграмма в целом, сущность, атрибут и т. д.) и тип данных. Для внесения нового свойства следует щелкнуть в таблице по кнопке “+”, и внести имя, тип данных, значение по умолчанию и определение.

ERwin поддерживает для UDP шести типов данных:

Date. Дата. Используется формат MM/DD/YY. Для выбора значения даты можно использовать контекстный календарь;

Int. Целое число;

Real. Действительное число;

Text. Строка (ASCII);

List. Список. При задании списка в диалоге User-Defined Property Editor значения следует разделять запятой, значение по умолчанию выделяется символом "~" (рис. 2.12);

Command. Команда - выполняемая строка. На рис. 2.11 свойство Document имеет тип Command.

Рис. 2.12. Диалог User-Defined Property Editor

Значение свойств, определяемых пользователем, задается в закладке UDP диалога Entity Editor. Если присвоить сущности значение свойства Document "D:\MSOffice97\Office\WINWORD.EXE part3.doc" (рис. 2.13), то из закладки можно редактировать документ part3 (кнопка “…” в строке таблицы UDP).

Рис. 2.13. Закладка UDP диалога Entity Editor

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

называется первичным ключом. Для описания атрибутов следует, "кликнув" правой кнопкой по сущности, выбрать в появившемся меню пункт Attribute Editor. Появляется диалог Attribute Editor (рис. 2.14).

Рис. 2.14. Диалог Attribute Editor

Если щелкнуть по кнопке New, то в появившемся диалоге New Attribute (рис. 2.15) можно указать имя атрибута, имя соответствующей ему в физической модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.

Рис. 2.15. Диалог New Attribute

Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key.

Закладка Definition позволяет записывать определения отдельных атрибутов. Определения атрибутов можно также сгенерировать как часть схемы (CREATE COMMENT on entity_name.attribute_name). Закладка

Note позволяет добавлять замечания об одном или нескольких атрибутах сущности, которые не вошли в определения. Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойства должны быть внесены в диалог User-Defined Property Editor как свойства атрибутов.

При установлении связей между сущностями атрибуты первичного ключа родительской сущности мигрируют в качестве внешних ключей в дочернюю сущность. Кнопка Migrate диалога Attribute Editor вызывает диалог Migrate Attribute Property, в котором можно задать свойства, сохраняемые при миграции.

Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. При помощи списка выбора Icon в закладке General можно связать иконку с атрибутом.

Рис. 2.16. Диалог Erwin Icon Editor

Каждому домену соответствует стандартная иконка, однако можно импортировать и дополнительные изображения. Кнопка “…” справа от списка выбора Icon вызывает диалог ERwin Icon Editor (рис. 2.16), щелкнув по кнопке Import можно добавить в список необходимую иконку.

Рис. 2.17. Отображение сущности на уровне атрибутов с включенной опцией Attribute Icon

Для отображения иконки атрибута следует выбрать в контекстном меню пункт Display Options/Entities и в каскадном меню включить опцию Attribute Icon. Малая иконка будет показана слева от имени атрибута

на уровне атрибутов отображения модели. Как видно из рис. 2.17, имя сущности показывается над прямоугольником, изображающим сущность, список атрибутов сущности - внутри прямоугольника. Список разделен горизонтальной чертой, выше которой расположены атрибуты первичного ключа, ниже - неключевые атрибуты.

Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Соблюдение этого правила позволяет частично решить проблему нормализации

данных уже на этапе определения атрибутов. Например, создание в сущности Сотрудник атрибута Телефоны сотрудника противоречит требованиям нормализации, поскольку атрибут должен быть атомарным, т. е. не содержать

множественных значений. Согласно синтаксису IDEF1X имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!). По умолчанию при попытке внесения уже существующего имени атрибута Erwin переименовывает его. Например, если атрибут Комментарий уже существует в модели, другой атрибут (в другой сущности) будет назван Комментарий/ 2, затем Комментарш/3 и т. д.

Рис. 2.18. Диалог Unique Name Option

На практике такое переименование не всегда удобно, поэтому существует возможность отменить эту опцию. В диалоге Unique Name Option (меню Option/Unique Name) (рис. 2.18) можно задать следующие режимы именования атрибутов:

Allow - позволить внесение одинаковых имен;

Rename - переименовывать атрибуты (по умолчанию);

Ask - запрашивать возможные действия каждый раз при внесении одноименных атрибутов. ERwin будет показывать на экране окно-диалог Edit Unique Name каждый раз, когда вводится неуникальное имя сущности или атрибута. В диалоге Edit Unique Name можно ввести другое имя или разрешить дублирование. При этом новое имя не проверяется на уникальность;

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

Каждый атрибут должен быть определен (закладка Definition), при этом следует избегать циклических определений, например когда термин 1 определяется через термин 2, термин 2 - через термин 3, а термин 3 в свою очередь - через термин 1 (рис. 2.19).

Рис. 2.19. Циклическое определение атрибутов

Иногда определение атрибута легче дать через описание области значений. Например, оценка школьника - это число, принимающее значения 2, 3, 4 и 5.

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

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

Дата рождения сотрудника. Производные атрибуты - ошибка нормализации, однако их вводят для повышения производительности системы -если необходимо узнать возраст сотрудника, можно обратиться к соответствующему атрибуту, а не проводить вычисления (которые на практике могут быть значительно более сложными, чем в приведенном примере) по дате рождения.

При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку в палитре инструментов.

Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) (рис. 2.20). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например:

Каждый КЛИЕНТ <размещает> ЗАКАЗы;

Каждый ЗАКАЗ <выполняется> СОТРУДНИКом.

Рис. 2.20. Имя связи - Relationship Verb Phrases

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

которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Verb Phrase.

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

и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником

со скругленными углами (сущность Заказ на рис. 2.21). Экземпляр зависимой сущности определяется только через отношение к родительской сущности, т. е. в структуре на рис. 2.21 информация о заказе не может быть внесена

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

ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (FK).

Рис. 2.21. Идентифицирующая связь между независимой и зависимой таблицей

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

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

Рис. 2.22. Неидентифицирующая связь

Экземпляр сущности Сотрудник может существовать безотносительно к какому-либо экземпляру сущности Отдел, т. е. сотрудник может работать в организации, не числясь в каком-либо отделе.

Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи (см. рис. 2.21), неидентифицирующая - пунктирной (рис. 2.22).

Для создания новой связи следует:

установить курсор на нужной кнопке в палитре инструментов (идентифицирующая или неидентифицирующая связь) и нажать левую кнопку мыши (рис.

щелкнуть сначала по родительской, а затем по дочерней сущности.

Форму линии связи можно изменить. Для этого нужно захватывать мышью нужную линию связи и переносить ее с места на место, пока линия не начнет выглядеть лучше.

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

Для редактирования свойств связи следует "кликнуть" правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor.

В закладке General появившегося диалога можно задать мощность, имя и тип связи (рис. 2.23).

Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.

Различают четыре типа мощности (рис. 2.24):

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

0, 1 или много экземпляров дочерней сущности не помечается каким-либо символом;

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

1 или много экземпляров дочерней сущности (исключено нулевое значение);

символом

Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);

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

Рис. 2.23. Диалог Relationship Editor

По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Cardinality.

Рис. 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,
Child Delete Режимы по умолчанию
Child Insert Возможные режимы	RESTRICT, CASCADE,		RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE,
Child Insert Режимы по умолчанию
Child Update Возможные режимы	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE, NONE
Child Update Режимы по умолчанию
Parent Delete Возможные режимы	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE,
Parent Delete Режимы по умолчанию
Parent Insert Возможные режимы	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE, NONE
Parent Insert Режимы по умолчанию
Parent Update Возможные режимы	RESTRICT, CASCADE, NONE	RESTRICT, CASCADE, NONE, SET NULL,SET DEFAULT	RESTRICT, CASCADE, NONE, SET DEFAULT	RESTRICT, CASCADE, NONE
Parent Update Режимы по умолчанию

Связь многие-ко-многим возможна только на уровне логической модели данных. На рис. 2.31 вверху показан пример связи многие-ко-многим. Врач может принимать много пациентов, пациент может лечиться у нескольких врачей. Такая связь обозначается сплошной линией с двумя точками на концах.

Рис. 2.31. Связь многие-ко-многим

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

Связь многие-ко-многим должна именоваться двумя фразами - в обе стороны (в примере "принимает/лечится"). Это облегчает чтение диаграммы. Связь на рис. 2.31 следует читать Вран <принимает> Пациент" а, Пациент <лечится> у Врач" а.

При переходе к физическому уровню ERwin автоматически преобразует связь многие-ко-многим, добавляя новую таблицу и устанавливая две новые связи один-ко-многим от старых к новой таблице (рис. 2.32, сверху). При "этом имя новой таблице присваивается автоматически как “Имя1 Имя2".

Рис. 2.32. Иллюстрация автоматического разрешения связи многие-ко-многим на уровне физической модели

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

Рис. 2.33. Дополнение модели при разрешении связи многие-ко-многим на уровне физической модели

Следует заметить, что после внесения дополнительной колонки на физическом уровне на логическом уровне представление модели не изменится, диаграмма будет выглядеть так, как на рис. 2.31.

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

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

Рис. 2.34. Пример характеристической сущности "Хобби "

Ассоциативная - сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. Примером ассоциативной сущности является Visit на рис. 2.33.

Именующая - частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигрировавших в качестве внешнего ключа). Примером именующей сущности является Doctor_Patient на рис. 2.32.

Иерархия наследования (или иерархия категорий) представляет собой особый тип объединения сущностей, которые разделяют общие характеристики. Например, в организации работают служащие, занятые полный рабочий день (постоянные служащие) и совместители. Из их общих свойств можно сформировать обобщенную сущность (родовой предок) Сотрудник (рис. 2.35), чтобы представить информацию, общую для всех типов служащих. Специфическая для каждого типа информация может быть* расположена в категориальных сущностях (потомках) Постоянный сотрудник и Совместитель.

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

Для каждой категории можно указать дискриминатор - атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой (атрибут Тип на рис. 2 35).

Рис. 2.35. Иерархия наследования. Неполная категория

Иерархии категорий делятся на два типа - полные и неполные. В полной категории одному экземпляру родового предка (сущность Служащий, рис. 2.36) обязательно соответствует экземпляр в каком-либо потомке, т. е. в примере служащий обязательно является либо совместителем, либо консультантом, либо постоянным сотрудником.

Если категория еще не выстроена полностью и в родовом предке могут существовать экземпляры, которые не имеют соответствующих экземпляров в потомках, то такая категория будет неполной. На рис. 2.35 показана неполная категория - сотрудник может быть не только постоянным или совместителем, но и консультантом, однако сущность Консультант еще не внесена в иерархию наследования.

Рис. 2.36. Иерархия наследования. Полная категория

Полная категория помечается символом , неполная - . Возможна комбинация полной и неполной категорий. На рис. 2.37 помимо постоянных сотрудников и совместителей могут быть и консультанты, что не отражено в иерархии (неполная категория), но каждый постоянный сотрудник либо мужчина, либо женщина (полная категория).

Рис. 2.37. Иерархия наследования. Комбинация полной и неполной категорий

Для редактирования категорий нужно щелкнуть правой кнопкой мыши по символу категории и выбрать в контекстном меню пункт Subtype Relationship Editor. В диалоге Subtype Relationship (рис. 2.38) можно указать атрибут - дискриминатор категории (список Discriminator Attribute Choice) и тип категории - полная/неполная (радиокнопки Complete/Incomplete).

Рис. 2.38. Диалог Subtype Relationship

Рассмотрим возможные стадии построения иерархии наследования. Определение сущностей с общими (по определению) атрибутами. Предположим, в процессе проектирования созданы сущности Постоянный сотрудник и Совместитель (рис. 2.39). Можно заметить, что часть атрибутов у этих сущностей (Фамилия, Имя, Отчество, Дата рождения, Должность) имеет одинаковый смысл.

Рис. 2.39. Сущности с общими по смыслу атрибутами

Перенос общих атрибутов в сущность - родовой предок. В случае обнаружения совпадающих по смыслу атрибутов следует создать новую сущность (Сотрудник) - родовой предок и перенести в нее общие атрибуты (Фамилия, Имя, Отчество, Дата рождения. Должность).

Создание неполной структуры категорий. Создается категориальная связь от новой сущности - родового предка к старым сущностям - потомкам. Новая сущность дополняется атрибутом-дискриминатором категории (Тип) (см. рис. 2.35).

Создание полной структуры категорий. Проводится дополнительный поиск сущностей, имеющих общие по смыслу атрибуты с родовым предком. В примере это сущность Консультант (рис. 2.40).

Рис. 2.40. Дополнительная сущность с общими по смыслу атрибутами

Общие атрибуты переносятся в родового предка и категория преобразуется в полную (признак полной категории устанавливается в диалоге Subtype Relationship). Сущность Консультант не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущности - потомки Постоянный сотрудник и Совместитель.

Комбинации полной и неполной структур категорий. При необходимости создание иерархии категорий можно продолжить. Для каждого потомка может найтись сущность с общими атрибутами, тогда сущность - потомок становится родовым предком для новых потомков, и т. д. (см. рис. 2.37).

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

Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии (см., например, рис. 2.33). При внесении нового атрибута в диалоге Attribute Editor для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key в нижней части закладки General. На диаграмме неключевой атрибут можно внести в состав первичного ключа, воспользовавшись режимом переноса атрибутов (кнопка в палитре инструментов).

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

Ключи могут быть сложными, т. е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения - это список атрибутов выше горизонтальной линии:"

Рассмотрим кандидатов на первичный ключ сущности Сотрудник (рис. 2.41).

Здесь можно выделить следующие потенциальные ключи:

1. Табельный номер,

2. Номер паспорта;

3. Фамилия + Имя + Отчество.

Рис. 2.41. Определение первичного ключа для сущности "Сотрудник"

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

Уникальность. Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ № 3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки.

Компактность. Сложный возможный ключ не должен содержать ни одного атрибута, удаление которого не приводило бы к утрате уникальности. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения и Цвет волос. Если бизнес-правила говорят, что сочетания атрибутов Фамилия + Имя + Отчество + Дата рождения достаточно для однозначной идентификации сотрудника, то Цвет волос оказывается лишним, т. е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным.

При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т. е. ключам, содержащим меньшее количество атрибутов. В примере ключи № 1 и 2 предпочтительней ключа № 3.

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

Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Сотрудница организации может выйти замуж и сменить как фамилию, так и паспорт. Поэтому ключи № 2 и 3 не подходят на роль первичного ключа.

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

При работе ИС часто бывает необходимо обеспечить доступ к нескольким экземплярам сущности, объединенным каким-либо одним признаком. Для повышения производительности в этом случае используются неуникальные индексы. ERwin позволяет на уровне логической модели назначить атрибуты, которые будут участвовать в неуникальных индексах. Атрибуты, участвующие в неуникальных индексах, называются Inversion Entries (инверсионные входы). Inversion Entry - это атрибут или группа атрибутов, которые не определяют экземпляр сущности уникальным образом, но часто используются для обращения к экземплярам сущности. ERwin генерирует неуникальный индекс для каждого Inversion Entry.

Создать альтернативные ключи и инверсионные входы можно в закладке Key Group диалога Attribute Editor (рис. 2.42). Если щелкнуть по кнопке!!!, расположенной в правой верхней части закладки, вызывается диалог Key Group Editor (рис. 2.43). В верхней части диалога находится список ключей, в нижней - список атрибутов, доступных для включения в состав ключа (слева), и список ключевых атрибутов. Каждый вновь созданный ключ должен иметь хотя бы один атрибут. Для включения атрибута в состав ключа следует выделить его в левом списке и щелкнуть по кнопке!!!

Рис. 2.43. Диалог Key Group Editor

Для создания нового ключа следует щелкнуть по кнопке New. Появляется диалог New Key Group (рис. 2.44). Имя нового ключа присваивается автоматически ("Alternate Key N" для альтернативного ключа и "Inversion Entry N" для инверсионного входа, где N - порядковый номер ключа).

Рис. 2.44. Диалог New Key Group

Каждому ключу соответствует индекс, имя которого также присваивается автоматически ("XAKNENTITY" для альтернативного ключа и " XIENENTITY" для инверсионного входа, где N - порядковый номер ключа, ENTITY - имя сущности). Имена ключа и индекса при желании можно изменить вручную.

Рис. 2.45. Сущность "Сотрудник" с отображением ключей

На диаграмме атрибуты альтернативных ключей обозначаются как (AKn.m), где n - порядковый номер ключа, m - порядковый номер атрибута в ключе. Когда альтернативный ключ содержит несколько атрибутов, (AKn.m) ставится после каждого. На рис. 2.45 атрибуты Фамилия, Имя, Отчество и Дата рождения входят в альтернативный ключ № 1 (АК1), Номер паспорта составляет альтернативный ключ № 2 (АК2). Инверсионные входы обозначаются как (IEn.m), где n - порядковый номер входа, m -порядковый номер атрибута. Инверсионный вход IE1 (атрибут Должность) позволяет выбрать всех сотрудников, занимающих одинаковую должность, IE2 (атрибуты Город и Улица) - всех сотрудников, живущих на одной улице, IE3 (атрибут Номер комнаты) - всех сотрудников, работающих в одной комнате, a IE4 (атрибут Дата рождения) - всех сотрудников, родившихся в один день. Если один атрибут входит в состав нескольких ключей, ключи перечисляются в скобках через запятую (атрибут Дата рождения входит в состав АК1 и IE4). По умолчанию номера альтернативных ключей и инверсионных входов рядом с именем атрибута на диаграмме не показываются. Для отображения номера следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Entities и затем включить опцию Alternate Key Designator (AK).

Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связь образует ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени (см. рис. 2.45). Атрибут внешнего ключа Где работает. Номер отдела ("Где работает" - имя роли) является атрибутом первичного ключа (РК) в сущности Отдел.

Зависимая сущность может иметь один и тот же внешний ключ из нескольких родительских сущностей. Сущность может также получить один и тот же внешний ключ несколько раз от одного и того же родителя через несколько разных связей. Когда ERwin обнаруживает одно из этих событий, он распознает, что два атрибута одинаковы, и помещает атрибут внешнего ключа в зависимой сущности только один раз. Хотя в закладке Key Group диалога Attribute Editor этот атрибут будет входить в два внешних ключа, на диаграмме он показывается только один раз. Это комбинирование или объединение идентичных атрибутов называется унификацией.

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

Рис. 2.46. Унификация атрибута

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

Есть и другие случаи, когда унификация нежелательна. Например, когда два атрибута имеют одинаковые имена, но на самом деле они отличаются по смыслу и необходимо, чтобы это отличие отражалось в диаграмме. В этом случае необходимо использовать имена ролей атрибутов внешнего ключа (см. рис. 2.27).

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

первая нормальная форма (1

вторая нормальная форма (2

третья нормальная форма (3

нормальная форма Бойса

Кодда (усиленная 3NF);

четвертая нормальная форма (4

пятая нормальная форма (5

На практике обычно ограничиваются приведением данных к третьей нормальной форме (полная атрибутивная модель, FA, см. 2.2.1). В данном подразделе будут достаточно кратко рассмотрены первые три нормальные формы и, в качестве иллюстрации, четвертая нормальная форма.

Для углубленного изучения нормализации следует рекомендовать книгу К. Дж. Дейта "Введение в системы баз данных" (Киев;М.:Диалектика, 1998).

Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин "зависимость"). Приведем формальное определение для функциональной зависимости.

Функциональная зависимость (FD). Атрибут В сущности Е функционально зависит от атрибута А сущности Е тогда и только тогда, когда каждое значение А в Е связало с ним точно одно значение В в Е, т. е. А однозначно определяет В.

Полная функциональная зависимость. Атрибут В сущности Е полностью функционально зависит от ряда атрибутов А сущности Е тогда и только тогда, когда В функционально зависит от А и не зависит ни от какого подряда А.

Рис. 2.47. Ненормализованная сущность "Сотрудник"

На рис. 2.47 в сущности Сотрудник значение атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибуты Фамилия, Имя и Отчество зависят от атрибута Табельный номер. Функциональные зависимости определяются бизнес-правилами предметной области. Так, если оклад сотрудника определяется только должностью, то атрибут Оклад зависит от атрибута Должность; если оклад зависит еще, например, от стажа, то такой зависимости нет. В нижеследующих примерах будем считать для определенности, что такая зависимость есть.

Рассмотрим нормальные формы.

Первая нормальная форма (1 NF). Сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, т. е. несколько значений для каждого экземпляра. На рис, 2 47 атрибуты Телефон и Хобби являются нарушением первой нормальной формы. Что будет, если у сотрудника несколько рабочих телефонов? Запись значения колонки через разделитель, например "124-56-78, 124-56-79, 124-56-90" или "Аквалангист, мотоциклист, шахматист", приводит к ряду проблем. Размера поля может не хватить для хранения данных (нельзя увеличивать список телефонов до бесконечности), по такой колонке невозможно построить индекс и т. д. и т. п. Сущность, приведенная на рис. 2.48, не является решением проблемы. Что будет, если у сотрудника появится четвертый телефон или третье хобби? Эту информацию будет негде хранить.

Рис. 2.48. Еще один пример ненормализованной сущности

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

Для приведения сущности к первой нормальной форме следует:

разделить сложные атрибуты на атомарные,

создать новую сущность,

перенести в нее все "повторяющиеся" атрибуты,

выбрать возможный ключ для нового РК (или создать новый РК).

установить идентифицирующую связь от прежней сущности к новой, РК прежней сущности станет внешним ключом (

FK) для новой сущности.

На рис. 2.49 показана сущность Сотрудник, приведенная к первой нормальной форме.

Рис. 2.49. Сущность "Сотрудник", приведенная к первой нормальной форме

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

Рис. 2.50. Сущность "Проект"

Предположим, сущность Проект содержит информацию о проекте, которым руководит сотрудник, причем информация содержится как непосредственно о проекте, так и о руководителе проекта (рис. 2.50). Атрибуты Фамилия, Имя, Отчество и Должность зависят только от атрибута Табельный номер руководителя, но вовсе не от Наименования проекта. Другими словами, имеется зависимость только от части ключа.

выделить атрибуты, которые зависят только от части первичного ключа, создать новую сущность;

поместить атрибуты, зависящие от части ключа, в их собственную (новую) сущность;

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

Рис. 2.51. Сущность "Проект", приведенная ко второй нормальной форме

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

Обновление (UPDATE). Имеет место дублирование данных о сотруднике, если он руководит несколькими проектами. Если данные о сотруднике изменяются, необходимо менять несколько записей (по числу ведомых проектов).

Вставка (INSERT). Невозможно ввести данные о сотруднике, если он в данный момент не руководит проектами.

Удаление (DELETE). Если сотрудник временно прекращает руководство проектами, данные о нем теряются.

На рис. 2.51 показана сущность Проект, приведенная ко второй нормальной форме.

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

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

Для приведения сущности ко второй нормальной форме следует:

создать новую сущность и перенести в нее атрибуты с одной и той же зависимостью от неключевого атрибута;

использовать атрибут(ы), определяющий эту зависимость, в качестве первичного ключа новой сущности;

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

Рис. 2.52. Сущность "Сотрудник", приведенная к третьей нормальной форме

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

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

Вставка (INSERT). Невозможно ввести данные об окладе, соответствующем должности, если в данный момент нет сотрудника, занимающего эту должность.

Удаление (DELETE). В случае удаления из таблицы сотрудника, занимающего уникальную должность, данные об окладе теряются.

Четвертая нормальная форма (4 NF) требует отсутствия многозначных зависимостей между атрибутами.

В примере на рис. 2.53 (слева) преподаватель читает лекции по нескольким предметам и курирует несколько групп студентов. Одна группа студентов может изучать несколько предметов, одному предмету могут обучаться несколько групп студентов. Имеется многозначная зависимость между атрибутами Предмет и Группа. При этом возможна аномалия: если у преподавателя появляется новая группа, приходится добавлять несколько записей, по числу читаемых предметов.

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

Рис. 2.53. Иллюстрация четвертой нормальной формы

Поддержка нормализации в ERwin. ERwin не содержит полного алгоритма нормализации и не может проводить нормализацию автоматически, однако его возможности облегчают создание нормализованной модели данных. Запрет на присвоение неуникальных имен атрибутов в рамках модели (при соответствующей установке опции Unique Name) облегчает соблюдение правила "один факт - в одном месте". Имена ролей атрибутов внешних ключей и унификация атрибутов также облегчают построение нормализованной модели.

Денормализация. В результате нормализации все взаимосвязи данных становятся правильно определены, исключаются аномалии при оперировании с данными, модель данных становится легче поддерживать. Однако часто нормализация данных не ведет к повышению производительности ИС в целом. Рассмотрим примеры на рис. 2.47 и 2.52. Для получения полной информации о сотруднике из ненормализованной структуры данных достаточно обратиться к одной таблице (см. рис. 2.47). После приведения структуры данных к третьей нормальной форме (рис. 2.52) информация о сотруднике содержится уже в четырех таблицах. Хотя общее количество строк в этих таблицах может быть меньше, чем в исходной (до нормализации), теперь для получения полной информации о сотруднике серверу БД необходимо обращаться одновременно к четырем таблицам (объединение таблиц, join). Время выполнения запроса с объединением может во много. раз превосходить время выполнения запроса к одной таблице, другими словами, в приведенном примере общая производительность ИС в результате нормализации скорее всего упадет. В целях повышения производительности при переходе на физический уровень приходится сознательно отходить от нормальных форм для того, чтобы использовать возможности конкретного сервера или ИС в целом.

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

Примером денормализации могут служить производные атрибуты, которые являются нарушением первой нормальной формы (см. 2.2.2). Другой пример денормализации приведен на рис. 2.54.

Рис. 2.54. Пример денормализации

Слева данные находятся в третьей нормальной форме, но для получения из БД информации о сотруднике, включая его оклад, приходится обращаться к таблицам Должность и Сотрудник. Если в таблицу Сотрудник добавить колонку Оклад (рис. 2.54, справа), то тогда при выборке информации о сотруднике достаточно обратиться только к таблице Сотрудник (исключается объединение). При этом нарушается третья нормальная форма и возникают аномалии, в том числе аномалии при обновлении (если оклад соответствующих должности меняется, необходимо менять несколько записей по числу сотрудников на одной должности). Для решения проблемы можно делать выборку только из таблицы Сотрудник, а обновлять значение оклада только в таблице Должность. Но при этом возникает противоречие между старым значением оклада, хранящимся в таблице Сотрудник, и новыми данными, хранящимися в таблице Должность. Чтобы избежать противоречия, можно создать утилиту (процедуру сервера), которая будет запускаться во время минимальной загрузки сервера, например ночью, и выравнивать значения колонок. Если при выборке должности всегда необходимо самое свежее значение, то такое решение неприемлемо. Если задача позволяет подождать до начала следующего дня после редактирования справочника Должность, то такое решение вполне допустимо.

Заметим, что приведенный пример следует воспринимать исключительно как иллюстрацию, а не как руководство к действию.

Еще один пример денормализации данных будет рассмотрен в подразделе 2.2.8, посвященном проектированию хранилищ данных.

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

ERwin имеет следующую функциональность для поддержки денормализации:

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

Таблицы, колонки, домены и индексы можно создавать только на уровне физической модели (опция Physical Only, см. 2.3). Например, на уровне только физической модели может быть создана колонка Оклад таблицы Сотрудник, см. рис. 2.54.

При автоматическом разрешении связи многие-ко-многим (см. 2.2.3) в физической модели создается новая таблица и структура данных может быть дополнена только на уровне физической модели.

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

В ERwin домен может быть определен только один раз и использоваться как в логической, так и в физической модели.

Домены позволяют облегчить работу с данными как разработчикам на этапе проектирования, так и администраторам БД на этапе эксплуатации системы. На логическом уровне домены можно описать без конкретных физических свойств. На физическом уровне они автоматически получают специфические свойства, которые можно изменить вручную. Так, домен "Возраст" может иметь на логическом уровне тип Number, на физическом уровне колонкам домена будет присвоен тип INTEGER.

Для создания домена в логической модели служит диалог Domain Dictionary Editor, (рис. 2.55). Его можно вызвать из меню Edit/Domain Dictionary по кнопке, расположенной в верхней левой части закладки General диалога Attribute Editor (см. рис. 2.14). Для создания нового домена в диалоге Domain Dictionary Editor следует:

Рис. 2.55. Диалог Domain Dictionary Editor

щелкнуть по кнопке

New. Появляется диалог New Domain (рис. 2.56);

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

Domain Parent. Новый домен можно создать на основе уже созданного пользователем домена либо на основе изначально существующего. По умолчанию ERwin имеет четыре предопределенных домена (String, Number, Blob, Datetime). Новый домен наследует все свойства родительского домена. Эти свойства в дальнейшем можно переопределить;

набрать имя домена в поле

Logical Name. Можно также указать имя домена на физическом уровне в поле Physical Name. Если физическое имя не указано, по умолчанию оно принимает значение логического имени;

щелкнуть по кнопке ОК.

В диалоге Domain Dictionary Editor можно связать домен и иконкой, с которой он будет отображаться в списке доменов (Domain Icon), и иконкой, с которой атрибут, определенный на домене, будет отображаться в модели (Icon Inherited by Attribite).

Рис. 2.56. Диалог New Domain

Каждый домен может быть описан в закладке Definition, снабжен комментарием в закладке Note или свойством, определенным пользователем в закладке UDP.

Рис. 2.57. Создание нового атрибута с помощью диалога Independent Attribute Browser

ERwin имеет специальный инструмент, который значительно облегчает создание новых атрибутов в модели, используя описание доменов, -Independent Attribute Browser. Этот диалог вызывается (и скрывается) по горячему ключу CTRL+B. С его помощью можно выбрать в списке домен и по методу drag&drop перенести его в какую-либо сущность. В ней будет создан новый атрибут с именем, которое следует задать в окне Name Inherited by Attribite диалога Domain Dictionary Editor. Если значение поля не задано, по умолчанию принимается имя домена. На рис. 2.57 для домена "Возраст" значение этого поля было "Атрибут Возраст". В дальнейшем в случае необходимости имя атрибута.можно изменить.

Рис. 2.58. Диалог Domain Dictionary Editor на физическом уровне

На физическом уровне диалог Domain Dictionary Editor позволяет редактировать физические свойства домена. На рис. 2.58 показана закладка ORACLE. Имя этой закладки зависит от выбранного сервера БД. На ней можно задать конкретный тип данных, соответствующих домену, правила присвоения NULL-значений, правила валидации (правила проверки допустимых значений) и задания значения по умолчанию. Правила валидации и значения по умолчанию должны быть предварительно описаны и именованы так, как это описано в 2.3.4 (на рис. 2.58 для домена "Возраст" заданы соответственно правило валидации "Проверка_возраста" и значение по умолчанию "Возраст по умолчанию"). Для вызова диалогов редактирования правил валидации и значений по умолчанию служат кнопки “…” справа от соответствующего списка выбора (Valid и Default).

Рассмотрим функции других закладок диалога Domain Dictionary Editor:

General (рис. 2.59). Задание родительского домена (Domain Parent) и имени, присваиваемого колонке при ее создании с помощью Independent Column Browser. С помощью опции Physical Only домен можно определить только на уровне физической модели.

Comment. Внесение комментария к атрибуту.

UDP. Свойства, определяемые пользователем.

Visual Basic - PowerBuilder. Задание специальных свойств домена для кодогенерации клиентского приложения.

Рис. 2.59. Закладка General диалога Domain Dictionary Editor

Домены могут быть использованы при генерации схемы БД для создания типов, определяемых пользователем для тех СУБД, которые поддерживают такие конструкции (DB2, Rdb, Inteibase, SQL Anywhere, SQL Server и SYBASE). Типы, определяемые пользователем, представляют собой синонимы существующих в БД типов, создаваемых для удобства работы с данными.

При выборе соответствующего сервера на закладке General появляется флажок:

Distinct Types - для DB2/CS и DB2/UDB;

Domains - для Rdb и Inteibase;

User Datatypes - для SQL Anywhere, SQL Server и SYBASE.

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