CASE-средства ERWin при нормализации и денормализации БД,

• построить физическую модель,
• изучить алгоритмы перевода БД в первую, вторую и третью нормальную форму

Нормализация

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

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

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

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

Существуют следующие виды нормальных форм:

• Первая нормальная форма

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

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

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

1.1. Поддержка нормализации в ERWin

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

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

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

Создание физической модели

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

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

Таблица 7.1. Сопоставление компонентов логической и физической модели

Логическая модель	Физическая модель
Сущность	Таблица
Атрибут	Столбец
Логический тип (текст, число, дата, blob)	Физический тип (корректный тип, зависящий от выбранной СУБД)
Первичный ключ	Первичный ключ, индекс РК
Внешний ключ	Внешний ключ, индекс FK
Альтернативный ключ	АК-индекс - уникальный, непервичный индекс
Правило бизнес- логики	Триггер или сохраненная процедура
Взаимосвязи	Взаимосвязи, определяемые использованием FK-атрибутов

Денормализация

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

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

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

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

• Таблицы, столбцы, индексы и домены можно создавать только на физическом уровне. В

ERWin существует возможность выделения элементов модели таким образом, чтобы они не появлялись на логическом уровне. Эта возможность напрямую поддерживает денормализацию физической модели, так как позволяет проектировщику включать таблицы, столбцы и индексы в физическую модель, ориентированную на конкретную СУБД.

Разрешение связей «многие-ко-многим». При разрешении этих связей в логической модели ERWin добавляет ассоциированные сущности и позволяет добавить в них атрибуты. При разрешении связей в логической модели автоматически разрешаются связи и в физической модели.

Пример

Нормализуем полученную в предыдущей лабораторной работе БД до третьей нормальной формы. Для приведения БД в первую нормальную форму необходимо выполнить условие, при котором все атрибуты содержат атомарные значения. Рассмотрим атрибуты сущности «Студент». Студент может иметь несколько адресов электронной почты и несколько телефонных номеров, что является нарушением первой нормальной формы. Необходимо создать отдельные сущности «E-mail» и «Телефон» и связать их с сущностью «Студент» (рис. 7.1).

Рис. 7.1. ERD-диаграмма БД студентов в первой нормальной форме

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

Для приведения БД к третьей нормальной форме необходимо обеспечить отсутствие транзитивных зависимостей неключевых атрибутов. Такая зависимость наблюдается у атрибутов «Специальность» и «Специализация» у сущности «Студент»: специализация зависит от специальности и от группы, в которой обучается студент. Создадим новую независимую сущность «Специальность», перенеся в нее атрибут «Специализация» и создав новый атрибут «Группа», являющийся ключевым и определяющий атрибуты «Специальность» и «Специализация». Проведем неидентифици-рующую связь от сущности «Специальность» к сущности «Студент», при этом ключевой атрибут «Группа» мигрирует в сущность «Студент». Получим БД в третьей нормальной форме, так как других транзитивных зависимостей неключевых атрибутов нет (рис. 7.2).

Рис. 7.2 . ERD- диаграмма БД студентов в третьей нормальной форме

Перейдем к построению физической модели. Перед построением физической модели необходимо выбрать тип базы данных в меню при создании физической модели. Выберем в качестве DataBase Microsoft Access 97 или 2000, получив физическую модель, сгенерированную ERWin по умолчанию (рис. 4.4).

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

Таблица 7.2. Свойства колонок таблиц физической модели БД студентов

Колонка	Тип	Размер	Правило валидации
			>10 и <100
Характеристика
Специальность
Специализация
Место работы
Уровень владения
Название
Описание
Дисциплина
Ф.И.О. преподавателя

После установки правил валидации (для этого сначала надо дать имя Validation Name, а затем отредактировать Validation Rule) в диалоговом окне Validation Rule Editor должны получиться следующие правила

Рис. 7.3. Правила валидации

После установки правил валидации в диалоговом окне Column Editor необходимо присвоить соответствующим колонкам таблиц установленные для них правила (рис. 4.4).

Рис. 7.4. Физическая модель БД студентов

Таким образом, проделав все вышеописанные действия, мы получили модель БД, готовую для помещения в СУБД. Для генерации кода создания БД необходимо выбрать иконку Forward Engineer после чего откроется окно установки свойств генерируемой схемы данных. Для предварительного просмотра SQL-скрипта служит кнопка Preview, для генерации схемы - Generate. В процессе генерации ERWin связывается с БД, выполняя SQL-скрипт. Если в процессе генерации возникают какие-либо ошибки, то она прекращается, открывается окно с сообщениями об ошибках.

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

1. Что называется процессом нормализации?
2. Что называется функциональной зависимостью?
3. Что называется полной функциональной зависимостью,?
4. Первая нормальная форма.
5. Вторая нормальная форма.
6. Третья нормальная форма.
7. Нормальная форма Бойсса - Кодда.
8. Что называется процессом денормализации?
9. В чем смысл денормализации?
10. Какова цель создания физической модели?
11. Назовите функции
ERWin по поддержке денормализации.
12. Как осуществляется разрешение связей «многие-ко-многим»?

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

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

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

Рис.1. Имена ролей внешних ключей

В примере, приведенном на рис. 1, в сущности Сотрудник внешний ключ Номер отдела имеет имя роли "Где работает", которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Entities и затем включить опцию Rolename/Attribute. Полное имя показывается как функциональное имя и базовое имя, разделенные точкой (рис. 1).

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

Рис.2. Случай обязательности имен ролей

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

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

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

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

Рис.3. Миграция имен ролей

На рис.3 существует идентифицирующая связь между сущностями Команда и Игрок. Что будет, если удалить команду? Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL), следовательно нужно либо запретить удаление команды, пока в ней числится хотя бы один игрок, либо удалять вместе с командой и всех ее игроков. Такие правила удаления (Parent Delete) называются Parent Restrict (ограничение) и Parent Cascade (каскад). Сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и, если на удаление игрока наложено правило каскадного удаления всех записей о его голах, то при удалении команды будут удалены все игроки команды и все голы, забитые этими игроками.

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

Связь многие-ко-многим должна именоваться (Verb Phrase) двумя фразами - в обе стороны. Это облегчает чтение диаграммы.

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

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

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

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

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

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

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

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

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

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

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

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

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

Домены.

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

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

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

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

· щелкнуть по кнопке New. Появляется диалог New Domain;

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

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

· щелкнуть по кнопке OK;

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

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

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

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

Функции других закладок диалога Domain Dictionary Editor:

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

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

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

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

Задание на выполнение.

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

Лабораторная работа № 7.
Основы работы в Erwin. Подготовка физической модели данных для генерации БД

1. Цель работы: освоение принципов подготовки физической модели данных для генерации системного каталога БД.

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 пользуется библиотекой шаблонов триггеров, которые можно модифицировать.
При генерации структуры базы данных триггеры, обеспечивающие ссылочную целостность могут быть переопределены на трех уровнях:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 6. Выбор параметров генерации базы данных

7. Расширенные функции ERwin

Обратное проектирование (Reverse engineering)

Обратное проектирование, то есть восстановление информационной модели по существующей базе данных, используется при выборе оптимальной платформы (rightsizing) для существующей настольной (desktop) базы данных или базы данных на mainframe, а также при расширении (или модификации) существующей структуры, которая была построена без необходимой сопроводительной документации. После завершения процесса восстановления модели ERwin автоматически "раскладывает" таблицы на диаграмме. Теперь можно выполнять модификации уже с использованием логической схемы - добавлять сущности, атрибуты, комментарии, связи и т.д. По завершении изменений одна команда - синхронизировать модель с базой данных - актуализирует все проведенные изменения.
Построение модели может быть выполнено как на основании данных каталога базы данных, так и на основании пакета операторов SQL, с помощью которого была создана база данных.

Синхронизация с базой данных

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

Рис. 7. Выбор синхронизируемых таблиц

ERwin "знает" о таких особенностях хранения данных в отдельных СУБД, как сегменты (в Sybase) и табличное пространство (в Oracle). Информация о физическом размещении может быть включена в модель и использована при прямом и обратном проектировании.

Интерфейсы к СУБД

ERwin поддерживает прямой интерфейс с основными СУБД: DB2 версии 2 и 3, Informix версий 5.1, 6.0, 7.1, Ingres, NetWare SQL, ORACLE версий 6 и 7, Progress, Rdb версий 4 и 6, SQL/400 версий 2 и 3, SQLBase версий 5 и 6, SQL Server версий 4 и 6, Sybase версии 4.2, Sybase System 10 и 11, Watcom SQL. Отметим, что поддерживаются как самые современные, так и предыдущие версии основных СУБД (рис.8).

Рис. 8. Выбор СУБД для создания модели

ERwin поддерживает также настольные (desktop) СУБД: Microsoft Access, FoxPro, Clipper, dBASE III, dBASE IV и Paradox.
Проектирование на физическом уровне выполняется в терминах той базы данных, которую предполагается использовать в системе. Важно, что ERwin "известны" соответствия между возможностями СУБД различных производителей, вследствие чего возможно преобразование физической схемы, спроектированной для одной СУБД, в другую.
Для создания физической структуры БД может быть запрошена генерация DDL-скрипта (data definition language). При этом используется диалект SQL для выбранного типа и версии сервера. Хотя сгенерированный код не нуждается в модификации, имеется возможность его сохранить в файл или распечатать.

Поддержка средств 4GL

ERwin выпускается в нескольких различных редакциях, ориентированных на наиболее распространенные средства разработки 4GL. В числе поддерживаемых средств - PowerBuidler фирмы Powersoft, SQL Windows фирмы Gupta, Visual Basic фирмы Microsoft, Oracle*CASE фирмы Oracle.
Средства двунаправленного взаимодействия ERwin с базой данных обеспечивают управление информацией, ориентированной как на серверную, так и на клиентскую часть. Например, для PowerBuilder можно просматривать/редактировать расширенные атрибуты в редакторах ERwin.
Ориентация ERwin на средства 4GL позволяет задать для будущих приложений большинство параметров, непосредственно связанных с базой данных, уже на стадии проектирования информационной модели.
Покажем принципы организации такого взаимодействия на примере PowerBuilder.
PowerBuilder создает в базе данных несколько внутренних таблиц для хранения своего репозитария (расширенных атрибутов для datawindow). Использование расширенных атрибутов гарантирует сохранение стиля отображения одних и тех же колонок базы данных для всех приложений, создаваемых рабочей группой. В расширенных атрибутах задаются такие параметры, как формат отображения, стиль редактирования, выражение проверки на корректность, начальное значение, выравнивание, ширина и высота элемента отображения, метка для формы редактирования, заголовок для табличного отображения.
Для расширенных атрибутов допустимы те же операции синхронизации, что и для всей модели, то есть описания могут быть загружены в базу данных и, наоборот, созданные из среды PowerBuilder описания расширенных атрибутов могут быть загружены из базы данных в ERwin для модификации.
Пример определения расширенных атрибутов показан на рис.9.

Рис. 9. Задание расширенных атрибутов PowerBuilder

Функция ERwin по генерации DataWindow позволяет сгенерировать прототипы окон данных будущего приложения уже на стадии создания информационной модели. Для создания Data Windows предлагается Wizard, с помощью которого указывается стиль окна и выбранные колонки таблиц.

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

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

Четыре первые нормальные формы (точнее первая, вторая, третья и Бойса-Кодда) объединяются в одну группу потому, что их определения основаны на классическом понятии функции, заданной на схеме отношения, и на теореме Хиса.

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

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

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

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

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

5.1 Связи и внешние ключи

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

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

Связи между отношениями/сущностями и в реляционной модели и в ER-диаграммах образуются ссылочным ограничением целостности, которое называется "внешний ключ" ("Foreign Key" - сокращенно FK).

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

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

Рис. 5.1. Пример связей "один-ко-многим"

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

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

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

В чем же разница между схемами на рисунке 5.1 ? Идентифицирующая связь заставляет думать о сотруднике в первую очередь как о работнике отдела. Неидентифицирующая связь означает, что принадлежность к отделу отмечается как нечто второстепенное.

5.2 Типы связи. Идентифицирующие и неидентифицирующие, обязательные и необязательные связи

Типы связи идентифицирующая и неидентифицирующая (см. рисунок 5.1) относится не к теории реляционных баз данных, а к стандарту моделирования IDEF1X, на котором основан ERwin (он же AllFusion Data Modeller).

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

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

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

После того, как в "Язык SQL" мы познакомимся с языком SQL, используя прямой инжиниринг, можно будет генерировать скрипт SQL создающий фрагмент схемы базы. Но и сейчас, если вы уже хотя бы немного знакомы с SQL, то, пройдя путь Tools > Forward Engineer/Schema Generation, а затем нажав кнопку Preview, просмотрите сгенерированный текст.

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

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

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

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

Рис. 31. Связи между сущностями

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

Каждый Клиент <Вносит/Снимает > средства со счета .

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

В ERwin связи представлены пятью основными элементами информации:

тип связи (идентифицирующая, неидентифицирующая, полная/неполная категория, неспецифическая связь);

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

дочерняя (зависимая) сущность;

мощность связи (cardinality);

допустимость пустых (null) значений.

В IDEF1X различают зависимые и независимые сущности . Тип сущности определяется ее связью с другими сущностями.

Связь называется идентифицирующей , если экземпляр дочерней (зависимой) сущности идентифицируется через ее отношение с родительской (независимой) сущностью. Когда рисуется идентифицирующая связь ERwinавтоматически преобразует дочернюю сущность в зависимую, а атрибуты, составляющие первичный ключ родительской сущности, автоматически переносятся в первичный ключ дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ – (FK ) . Зависимая сущность изображается прямоугольником со скругленными углами (рис. 32). В дальнейшем, при генерации схемы БД, атрибуты первичного ключа получат признак NOT NULL , что означает невозможность внесения записи в таблицу заказов без информации о номере клиента. Идентифицирующая связь показывается на модели сплошной линией с жирной точкой на дочернем конце связи.

Рис. 32. Пример идентифицирующей связи один-ко-мнoгим

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

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

Рис. 33. Пример неидентифицирующей связи один-ко-мнoгим

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

команда включает много игроков;

самолет перевозит много пассажиров;

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

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

Рис. 34. Пример связи многие-ко-мнoгим

Связь многие-ко-мно гим может не учитывать определенные ограни­чения системы, поэтому при переходе к физическому уровню ERwin автоматически преобразует связь многие-ко-многим , добавляя новую сущность и устанавливая две новые связи один-ко-многим от старых сущностей к новой сущности. При этом имя новой сущности автоматически присваивается как Имя1_И мя2, например, Товар_Заказ .

13. Создайте связи.

13.1. При помощи панели инструментов Стандартная перейдите в режим (уровень) отображения сущностей (рис. 35).

Рис. 35. Вид модели в режиме отображения сущностей

13.2. Включите режим отображения связей на дугах связей между сущностями, включив для этого режим Verb Phrases (Показ глагольной фразы ) в меню Format/Relation ship Display .

13.3. Для установления связей используются кнопки связей на панели Инструменты (рис. 5).

13.4. Установите связь М:М между сущностями Товар и Заказ Many - to - many relationship на панели Инструменты Товар Заказ Выбор (Select ).

13.5. Установите связь 1:М между сущностями Клиент и Заказ (рис. 35). Порядок задания связи следующий: щелкните мышью по кнопке Non - identifying reletionship на панели Инструменты , а затем сделайте щелчок мышью сначала по родительской сущности Клиент , а затем по дочерней сущности Заказ . Для отключения режима задания связей щелкните мышью по кнопке Выбор (Select ).

После выполнения пунктов 13.3 и 13.4 на модели появятся линии связи между сущностями с дежурными именами связей R/1 и R/2 (рис. 36).

Рис. 36. Вид модели с установленными связями сущностей

14. Задайте имена связям.

14.1. Проверьте выполнение пункта 13.2.

14.2. Для задания имен связям между сущностями Товар и Заказ R/1 (рис. 36).

14.3. В появившемся окне Reletionship (рис. 37) выберите вкладку General .

Рассмотрим назначение вкладок в окне задания связей Reletionship (рис. 37).

Рис. 37. Окно Reletionship

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

Мощность связи (Cardinality )–обозначает отношение числа экземпляров родительской сущности к числу экземпляров дочерней. ERwin , в соответствии с методологией IDEF1X , позволяет задать четыре типа мощности:

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

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

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

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

По умолчанию символ, обозначающий мощность связи, не показывается на модели. Для отображения имени следует меню Format/ Relationship Display включить режим Cardinality . Мощность отображается дополнительным символом у дочерней сущности (рис. 38).

			0, 1 или много
			1 или много
			точно N (5)

Рис. 38. Обозначение мощности связи на моделях

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

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

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

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

В закладке Rolename можно задать имя роли.

В закладке RI Actions правила ссылочной целостности.

Имя роли (Rolename ) – это функциональное имя синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту модели, не занятому объектами модели, выбрать пункт Entities Display и затем включить режим Rolename/Attribute . Полное имя показывается как функциональное имя и базовое имя, разделенные точкой.

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

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

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

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

Рис. 39. Окно Triggers

Если атрибут мигрирует в качестве внешнего ключа более, чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более – только имя роли.

Правила ссылочной целостности (Referential Integrity (RI )) – логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. При генерации схемы БД на основе опций логической модели, задаваемых в закладке RI Actions , будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность. Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления (INSERT , UPDATE или DELETE ).

Рис. 40. Задание имен связей между сущностями Товар иЗаказ

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

Erwinавтоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в модель. Режимы RI , присваиваемые Erwin по умолчанию, могут быть изменены в окне Triggers , которое вызывается с помощью меню Database/RI Triggers/Table Triggers… (рис. 39).

14.4. В окне Reletionship (рис. 37) в разделе Parent - to - Child введите Входит , а в разделе Child - to - Parent – Включает (рис. 40).

14.5. Аналогично для задания имени связи между сущностями Клиент и Заказ сделайте двойной щелчок мышью по связи R/2 (рис. 36) и в появившемся окне Reletionship (рис. 37) в разделе Parent - to - Child введите Делает (рис. 41).

Рис. 41. Задание имен связей между сущностями Клиент иЗаказ

14.5. В результате выполнения пунктов 14.1-14.5 модель примет вид, показанный на рис. 42.

Замечание : В нашей модели, представленной на рис 41, символы мощности связи у дочерних сущностей отсутствуют, так как выбран тип мощности Zero , One or More .

Рис. 42. Вид модели с указанием связей между сущностями