Батин Н.В. Проектирование баз данных

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

ГОРОД

ID Код города

1,1

ID Название

1,1

Численность населения

1,1

Аэропорт

0,N

АЭРОПОРТ

ID Код аэропорта

1,1

Площадь

1,1

Длина ВВП

1,1

Город

1,1

Рисунок 3.4 – СОМ-модель связи между объектами

Здесь семантический объект ГОРОД, наряду с простыми атрибутами (Код

города, Название и Численность населения), содержит также семантический

объектный атрибут Аэропорт. Этот атрибут фактически представляет собой

ссылку на другой объект и указывает, что объект ГОРОД связан с объектом

АЭРОПОРТ. Аналогично, объект АЭРОПОРТ содержит семантический объ-

ектный атрибут Город, указывающий на связь с этим объектом. Следует обра-

тить внимание, что семантические объектные атрибуты всегда указываются па-

рами.

Характеристики связи (тип и класс принадлежности) описываются карди-

нальными числами семантических объектных атрибутов. Так, атрибут Аэро-

порт объекта ГОРОД имеет кардинальные числа 0,N. Это значит, что городу

может не соответствовать ни одного аэропорта или соответствовать любое ко-

личество аэропортов (один, два и более). Атрибут Город объекта АЭРОПОРТ

имеет кардинальные числа 1,1. Это значит, что аэропорту соответствует в точ-

ности один город (ни больше, ни меньше). Таким образом, связь между города-

ми и аэропортами – 1:М (одному городу может соответствовать много аэропор-

тов, а одному аэропорту – один город), необязательная для города, обязатель-

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

Рассмотрим теперь СОМ-модель, описывающей связь между объектами и

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

проектировании БД о цехах предприятия и о материалах, расходуемых цехами

(см. п.2.3.7). СОМ-модель для этого примера приведена на рисунке 3.5.

ЦЕХ

ID Номер цеха

1,1

ID Название цеха

1,1

ФИО начальника

1,1

Использование

1,N

МАТЕРИАЛ

ID Шифр материала

1,1

Цена

1,1

Единица измерения

1,1

Использование

0,N

ИСПОЛЬЗОВАНИЕ

Цех

1,1

Материал

1,1

Расход

1,1

Периодичность

1,N

Рисунок 3.5 – СОМ-модель связи между объектами

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

Здесь ИСПОЛЬЗОВАНИЕ – семантический объект, описывающий связь

между двумя другими объектами – ЦЕХ и МАТЕРИАЛ. Даталогическая модель

для данной задачи приведена на рисунке 2.34.

3.4 Типы семантических объектов

В зависимости от назначения семантических объектов и от атрибутов, вхо-

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

этих типов следующие:

− простые объекты (simple objects) – объекты, содержащие только единич-

ные атрибуты;

− композитные объекты (composite objects) – объекты, содержащие хотя

бы один множественный атрибут, но при этом не содержащие семантических

объектных атрибутов (т.е. связей с другими объектами). Пример композитного

объекта – объект ПРЕПОДАВАТЕЛЬ (см. подраздел 3.2);

− составные объекты (compound objects) – объекты, содержащие хотя бы

один семантический объектный атрибут. Примеры таких объектов – ГОРОД,

АЭРОПОРТ, ЦЕХ, МАТЕРИАЛ (см. подраздел 3.3);

− ассоциативные объекты (association objects) – объекты, используемые

для описания связей между двумя (или несколькими) объектами и содержащие

семантические объектные атрибуты, соответствующие этим объектам. Пример

ассоциативного объекта – ИСПОЛЬЗОВАНИЕ (см. подраздел 3.3).

Более сложные типы семантических объектов и примеры их применения

подробно рассматриваются в [2].

4 СИСТЕМА АВТОМАТИЗИРОВАННОГО ПРОЕКТИРОВАНИЯ

БАЗ ДАННЫХ ERwin

4.1 Назначение системы ERWin. Основные этапы

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

Пакет программ ERWin (AllFusion ERWin Data Modeler) предназначен для

автоматизированного проектирования баз данных.

Процесс проектирования БД в ERWin включает следующие основные эта-

пы:

− построение модели данных, т.е. описание данных в соответствии с опре-

деленной методологией (т.е. по определенному стандарту, в соответствии с оп-

ределенными правилами);

− генерация БД (на основе построенной модели) в формате выбран-

ной СУБД.

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

логии: IDEF1X и IE. В данном пособии рассматривается применение методоло-

гии IDEF1X, основанной на использовании ER-моделей.

Модель данных в ERWin может строиться на двух уровнях: логическом

(Logical) и физическом (Physical). Построение логической модели соответст-

вует этапу инфологического проектирования (см. подраздел 1.1). Построение

физической модели соответствует этапам даталогического и физического про-

ектирования.

Логическая модель данных не связана с конкретной СУБД. На этапе по-

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

− указание объектов (сущностей) предметной области;

− описание связей между объектами.

− указание ключевых атрибутов (первичных и альтернативных ключей);

− описание неключевых атрибутов объектов.

Физическая модель данных строится по правилам конкретной СУБД.

Система ERWin позволяет строить модели данных по правилам фактически

всех СУБД, распространенных в настоящее время.

Как правило, сначала строится логическая модель, затем – физическая. На

основе физической модели ERwin может сгенерировать ЬД в формате выбран-

ной СУБД или соответствующий код на языке SQL.

Процесс проектирования БД, начиная с построения ее модели и кончая ге-

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

нием (Forward Engineering).

Важной дополнительной возможностью системы ERWin является возмож-

ность обратного проектирования (Reverse Engineering) – автоматическое по-

строение логической или физической модели на основе существующей БД или

кода на языке SQL. В построенную модель данных могут вноситься изменения

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

ERWin в процессе прямого проектирования. По модели данных затем генери-

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

которой была построена модель данных, так и в формате другой СУБД. Таким

образом, обратное проектирование позволяет решать следующие основные за-

дачи:

− внесение изменений в структуру существующей БД;

− перенос структуры БД из одной СУБД в другую.

4.2 Основные элементы интерфейса ERWin

Для переключения между логической и физической моделью данных слу-

жит список выбора в левой части панели инструментов ERWin. Если выполня-

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

еще не существует, то она будет создана автоматически.

Палитра инструментов ERWin выглядит по-разному в зависимости от

уровня модели данных. На логическом уровне палитра инструментов содержит

следующие кнопки:

− кнопка указателя – для выбора объектов модели;

− кнопка добавления сущности – для добавления сущностей в модель.

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

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

му пространству на модели. Для редактирования сущностей (или других объек-

тов модели) необходимо выбрать кнопку указателя;

− кнопка категории. Категория, или категориальная связь - специальный

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

гориальной связи нужно щелкнуть левой кнопкой мыши по кнопке категории,

затем один раз щелкнуть по сущности-родителю, затем – по сущности-потомку;

− кнопка добавления текстового блока. С ее помощью можно внести тек-

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

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

буты могут быть перемещены способом drag&drop;

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

идентифицирующей (эти виды связей рассматриваются ниже).

На физическом уровне палитра инструментов не содержит кнопки катего-

рии и кнопки связи “многие ко многим”.

Как указано выше, для создания моделей данных в ERwin можно исполь-

зовать две методологии: IDEF1X или IE (Information Engineering). Для выбора

методологии используется закладка Methodology диалогового окна

Preferences (меню Options).

ERwin имеет несколько уровней отображения модели: уровень сущно-

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

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

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

ни отображения можно при помощи контекстного меню, которое появляется,

если щелкнуть по любому месту диаграммы, не занятому объектами модели. В

контекстном меню следует выбрать пункт Display Level и затем необходимый

уровень отображения. ERwin позволяет связать с сущностью большую или ма-

лую пиктограмму. При переключении на уровень пиктограмм по умолчанию

используются большие пиктограммы. Для переключения на малые пиктограм-

мы следует выбрать в контекстном меню пункт Display Options/Entities и в

каскадном меню включить опцию Entity Icon.

4.3 Создание логической модели данных

4.3.1 Уровни логической модели

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

представления информации о данных:

− диаграмма сущность-связь (Entity Relationship Diagram) - представляет

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

между ними;

− модель данных, основанная на ключах (Key Based model) - более под-

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

вичных ключей;

− полная атрибутивная модель (Fully Attributed model) - наиболее деталь-

ное представление структуры данных: представляет данные в третьей нормаль-

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

4.3.2 Сущности и атрибуты

Основные компоненты модели данных в ERwin – это сущности (объекты),

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

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

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

деленное свойство объекта. С точки зрения БД (физическая модель) сущности

соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту –

колонка таблицы.

Построение модели данных предполагает определение сущностей и атри-

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

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

смысловым значением. Примером может быть сущность Заказчик с атрибутами

Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической

модели ей может соответствовать таблица Customer с колонками Cus-

tomer_number, Customer_name и Customer_address.

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

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

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

новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из

всплывающего меню пункт Entity Editor…, можно вызвать диалог Entity Editor,

в котором определяются имя, описание и комментарии сущности.

Каждая сущность должна быть полностью описана с помощью текстового

описания в закладке Definition. Закладки Note, Note 2, Note 3, UDP (User De-

fined Properties) служат для внесения дополнительных комментариев и описа-

ний сущности: Закладка Icon позволяет каждой сущности поставить в соответ-

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

уровне пиктограмм.

Примечание – Закладка User Defined Properties и диалоговое окно User-Defined

Property Editor (меню Edit/UDPs…) служат для достаточно сложных операций с сущностя-

ми, не рассматриваемых в данном пособии.

Атрибут или группа атрибутов, которые идентифицируют сущность, назы-

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

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

является диалог Attribute Editor. Если щелкнуть по кнопке New…, то в поя-

вившемся диалоге New Attribute можно указать имя атрибута, имя соответст-

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

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

атрибутов первичного ключа в закладке General диалога Attribute Editor необ-

ходимо сделать отметку в окне Primary Key.

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

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

сущность. Кнопка Migrate… диалога Attribute Editor вызывает диалог Migrate

Attribute Property, в котором можно задать свойства, сохраняемые при мигра-

ции.

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

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

Для отображения пиктограммы атрибута следует выбрать в контекстном

меню пункт Display Options/Entities и включить опцию Attribute Icon.

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

в единственном числе. Согласно синтаксису IDEF1X имя атрибута должно

быть уникально в рамках модели (а не только в рамках сущности).

4.3.3 Связи

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

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

Рисунок 4.1 – Имя связи

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

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

кнопкой мыши по любому месту диаграммы, не занятому объектами модели,

выбрать пункт Display Options/Relationship и затем включить опцию Verb

Phrase.

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

связь “один ко многим”, связь “многие ко многим” и неидентифицирующую

связь “один ко многим” (этим видам связи соответствуют кнопки слева направо

в палитре инструментов). Ниже эти виды связей рассматриваются подробно.

В методологии IDEF1X, применяемой в ERWin для построения моделей

данных, различают зависимые и независимые сущности. Тип сущности опре-

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

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

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

(см. рисунок 4.2), ERwin автоматически преобразует дочернюю сущность в за-

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

ми углами.

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

и зависимой сущностью

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

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

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

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

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

дочерней сущности новые атрибуты помечаются как внешний ключ – (FK, For-

eign Key).

В дальнейшем, при генерации схемы БД, атрибуты первичного ключа по-

лучат признак NOT NULL, что означает невозможность внесения записи в таб-

лицу заказов без информации о номере клиента.

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

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

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

фицирующая связь (рисунок 4.3) служит для связывания независимых сущно-

стей.

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

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

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

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

− установить курсор на нужной кнопке в палитре инструментов (иденти-

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

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

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

ши по связи и выбрать на контекстном меню пункт Relationship Editor. В за-

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

зи.

4.3.3.1 Мощность связи (Cardinality) служит для обозначения отношения

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

личают четыре типа мощности:

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

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

ким-либо символом;

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

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

(исключено нулевое значение);

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

ской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключе-

ны множественные значения);

− цифрой обозначается случай точного соответствия, когда одному экзем-

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

ров дочерней сущности.

По умолчанию символ, обозначающий мощность связи, не отображается

на диаграмме. Для отображения такого символа следует в контекстном меню,

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

занятому объектами модели), выбрать пункт Display Options/Relationship и

затем включить опцию Cardinality.

4.3.3.2 Имя связи (Verb Phrase) – фраза, характеризующая отношение

между родительской и дочерней сущностями. Для связи “один ко многим”

(идентифицирующей или неидентифицирующей) достаточно указать имя, ха-

рактеризующее отношение от родительской к дочерней сущности (Parent-to-

Child). Для связи “многие ко многим” следует указывать имена как Parent-to-

Child, так и Child-to-Parent. См. также описание связи “многие ко многим”

ниже.

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

идентифицирующей связи можно указать обязательность (Nulls). В случае обя-

зательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа

получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в

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

(Nulls Allowed) внешний ключ может принимать значение NULL. Необязатель-

ная неидентифицирующая связь помечается прозрачным ромбом со стороны

родительской сущности.

В закладке Definition можно дать более полное определение связи для то-

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

В закладке Rolename/RI Actions можно задать имя роли и правила ссы-

лочной целостности.

4.3.3.4 Имя роли (функциональное имя) – это синоним атрибута внешне-

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

сти. По умолчанию в списке атрибутов показывается только имя роли. Для ото-

бражения полного имени атрибута (как имени роли, так и базового имени) сле-

дует в контекстном меню выбрать пункт Display Options/Entities и затем

включить опцию Rolename/Attribute. Полное имя показывается как имя роли и

базовое имя, разделенные точкой.

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

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

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

Другим примером обязательности присвоения имен ролей являются ре-

курсивные связи, когда одна и та же сущность является и родительской и до-

черней одновременно. При задании рекурсивной связи атрибут должен мигри-

ровать в качестве внешнего ключа в состав неключевых атрибутов той же сущ-

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

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

быть только неидентифицирующей.

Вид рекурсивной связи, называющийся иерархической рекурсией, задает

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

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

только один экземпляр родительской сущности.

Другим видом рекурсии является сетевая рекурсия, когда экземпляр ро-

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

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

ров родительской сущности. Это случай, когда сущность находится сама с со-

бой в связи “многие ко многим”. Если атрибут мигрирует в качестве внешнего

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

имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более –

только имя роли.

4.3.3.5 Правила ссылочной целостности (referential integrity (RI)) – ло-

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

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

БД на основе опций логической модели, задаваемых в закладке Rolename/RI

Actions, будут сгенерированы правила декларативной ссылочной целостности,

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

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

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

ния (INSERT, UPDATE или DELETE).

Правила удаления управляют тем, что будет происходить в БД при удале-

нии строки. Аналогично правила вставки и обновления управляют тем, что бу-

дет происходить с БД, если строки изменяются или добавляются.

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

лостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграм-

му. Режимы RI, присваиваемые Erwin по умолчанию, могут быть изменены в

редакторе Referential Integrity Default, который вызывается, если щелкнуть по

кнопке RI Defaults… диалога Target Server (меню Server/Target Server…).

4.3.3.6 Связь “многие ко многим” (рисунок 4.4) возможна только на

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

с двумя точками на концах.

Рисунок 4.4 - Связь “многие ко многим”

Для внесения связи “многие ко многим” следует установить курсор на

кнопке с изображением сплошной линии с двумя точками на концах в палитре

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

Связь “многие ко многим” должна именоваться двумя фразами – в обе сто-

роны. Это облегчает чтение диаграммы.

При переходе к физическому уровню ERwin автоматически преобразует

связь “многие ко многим”, добавляя новую таблицу и устанавливая две новые

связи “один ко многим” от таблиц, указанных в логической модели (т.е. связан-

ных связью “многие ко многим”), к новой таблице.

4.3.4 Типы сущностей и иерархия наследования

Как было указано выше, связи определяют, является ли сущность незави-

симой или зависимой. В ERWin различают несколько типов зависимых сущно-

стей:

− характеристическая - зависимая дочерняя сущность, которая связана

только с одной родительской и по смыслу хранит информацию о характеристи-

ках родительской сущности;

− ассоциативная - сущность, связанная с несколькими родительскими

сущностями. Такая сущность содержит информацию о связях сущностей;

− именующая - частный случай ассоциативной сущности, не имеющей

собственных атрибутов (только атрибуты родительских сущностей, мигриро-

вавших в качестве внешнего ключа);

− категориальная - дочерняя сущность в иерархии наследования.

Иерархия наследования (или иерархия категорий) представляет собой

особый тип объединения сущностей, имеющих общие характеристики.