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

Основными компонентами диаграммы логического уровня модели в ERwin DM являются:

• сущности,

• атрибуты,

• связи (отношения).

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

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

На физическом уровне сущности соответствует таблица, экземпляру сущности - строка в таблице, а атрибу­ту - колонка таблицы:

Логический уровень	Физический уровень
а) Сущность	б) Таблица

Рис. Пример сущности и соответствующей таблицы.

Сущности

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

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

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

Например, у сущности Сотрудник может быть следующий набор атрибутов: Табельный номер, Фамилия, Имя, Отчество, Дата рождения, Количество детей.

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

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

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

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

Атрибуты

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

На диаграмме IDEF1X сущность и атрибуты отображаются следующим образом (рисунок): имя сущности показывается над прямоугольником, изображающим сущность, список атрибутов сущно­сти - внутри прямоугольника. Список разделен горизонтальной чертой, выше которой расположены атрибуты первичного ключа, ниже - неключевые атрибуты.

Рис. Отображение сущности и атрибутов.

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

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

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

Согласно синтаксису IDEF1X имя атрибута должно быть уникально в рамках модели (а не только в рамках сущности!); следовательно, новый атрибут, если его имя совпадает с уже существующим, должен быть переименован.

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

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

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

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

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

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

Связи

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

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

Связь может существовать между:

• двумя разными сущностями

• между сущностью и ей же самой (рекурсивная связь).

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

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

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

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

Рис. Пример именования связей (Relationship Verb Phrases).

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

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

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

Таблица: Описание функций панели инструментов ERwin Toolbox на логическом уровне (нотации IDEF1X, IE).

Элемент управления (IDEF1X)	Элемент управления (IE)	Описание
		Указатель – для выбора объекта (объектов) на диаграмме.
		Создание новой сущности. Для создания сущности нужно щелкнуть левой кнопкой мыши по иконке и один раз по свободному пространству на диаграмме.
		Создание категории. Для установления категориальной связи нужно щелкнуть левой кнопкой мыши по значку категории, затем один раз щелкнуть по сущности – родовому предку, затем - по сущности-потомку.
		Создание идентифицирующей связи.
		Создание связи «многие ко многим».
		Создание неидентифицирующей связи.

Связи идентифицирующие и неидентифицирующие

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

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

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

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

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

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

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

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

В дочерней сущности новые атрибуты помечаются как внешний ключ - (Foreign Key - FK). В дальнейшем, при генерации схемы базы данных, атрибуты первичного ключа получат признак NOT NULL, что означает невозможность внесения записи в таблицу заказов без информации о номере клиента.

Неидентифицирующая связь служит для связывания независи­мых сущностей.

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

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

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

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

Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями.

Для связи "один ко многим" (иденти­фицирующей или неидентифицирующей) достаточно указать имя, характе­ризующее отношение от родительской к дочерней сущности (Parent-to-Child).

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

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

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

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

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

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

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

Роль

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

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

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

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

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

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

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

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

Рис. Пример обязательного использования имен ролей.

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

Валюта:

Продажа_валюты:

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

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

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

Чтобы со­слаться на руководителя сотрудника, следует создать рекурсивную связь (на рис. связь Руководит/Подчиняется) и присвоить имя роли (Руко­водитель).

Схема данных

Таблица Сотрудник

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

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

Связь руководит/подчиняется позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсивной связи называется иерархической рекурсией (hierarchical recursion) и задает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но подчинен­ный имеет только одного руководителя.

Иерархическая связь Руководит/Подчиняется

Другим видом рекурсии является сетевая рекурсия (network recursion), когда руководитель может иметь множество подчиненных и, наоборот, подчиненный может иметь множество руководителей.

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

Руководит.1

Подчиняется.2

Руководит.2

Подчиняется.3

Руководит.3

Подчиняется.1

Руководит.2

Подчиняется.4

……………………………………………..

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

Атрибут Тип отношения может принимать значения "отец-сын", "мать-дочь", "дед-внук", "свекровь-невестка", "тесть-зять" и т. д. По­скольку родственное отношение связывает всегда двух людей, от сущности Родственник к сущности Родственное отношение установлены две иден­тифицирующие связи с именами ролей "Старший" и "Младший". Каждый член семьи может быть в родственных отношениях с любым другим членом семьи.

Рис. 52. Пример реализации сетевой рекурсии.

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

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

Атрибут внешнего ключа Номер команды сущности Игрок имеет имя роли В какой команде играет. На следующем уровне, в сущности Гол, отображается только имя роли соответствующего атрибута внешнего ключа (В какой команде играет).

Рис. Пример миграции имен ролей.

Правила ссылочной целостности (RI - referential integrity) – правила определяющие, что произойдет в случае, если будут произведены изменения в родительской или дочерней сущности: добавление (INSERT), обновление (UPDATE), удаление (DELETE). Правила ссылочной целостности позволяют избежать «висячих» данных и позволяют придерживаться бизнес правил.

Связь "многие ко многим"

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

Рис. Пример связи «многие ко многим».

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

Для разрешения связи "многие ко многим" необходимо создать новую сущность.

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

Для преобразования связи "многие ко многим" необходимо выполнить специальное преобразование в ERwin (Мастер трансформаций - Many-To-Many Transform Wizard, состоящий из 4 шагов-диалогов).

На втором и третьем шаге следует задать имя вновь создаваемой таблицы и имя преобразования. Преобразование связи включает создание новой таблицы и двух новых связей "один ко многим" от старых к новой таблице (рисунок). При этом имя новой таблице присваивается как Имя1_Имя2.

Рис. Пример автотрансформации связи «многие ко многим».

Описанного выше решения проблемы связи «многие ко многим» не всегда оказывается достаточно.

В примере таблица Врач_Пациент имеет смысл ви­зита к врачу, поэтому ее следует переименовать согласно бизнес-логике в Посещение.

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

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

Рис. Пример дополнения физического уровня модели после трансформации связи «многие ко многим».

Типы зависимых сущностей

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

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

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

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

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

Категориальная - дочерняя сущность в иерархии наследования (см. ниже).

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

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

В IDEF1X выделяют два типа иерархии категории (наследования): полная и неполная.

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

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

Рассмотрим возможные стадии построения иерархии наследования.

А) Определение сущностей с общими (по определению) атрибутами.

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

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

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

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

Рис. Пример неполной иерархии категорий.

Полученная схема базы данных:

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

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

Сущность Консультант не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае кон­сультанта будет NULL.

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

Рис. Пример полной иерархии категорий.

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

Рис. Пример смешанной иерархии категорий.

Ключи

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

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

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

При внесении нового атрибута в диалоге Attributes для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key. На диаграмме неключевой атрибут можно перевести в состав первичного ключа, воспользовавшись режимом пе­реноса атрибутов.

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

Ключи могут быть сложными (составными), т. е. содержа­щими несколько атрибутов.

Рис. Ключи сущности «Сотрудник».

Рассмотрим потенциальные ключи сущности Сотрудник:

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

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

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

Выберем из них первичный ключ.

Первичный ключ должен удовле­творять следующим требованиям:

• уникальность,

• компактность,

• простота,

• не содержать нулевых (отсутствующих) значений;

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

Рассмотрим эти требования подробнее.

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

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

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

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

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

Иногда создают искусственный (суррогатный) ключ, например, Номер сотрудника, Номер клиента, Номер товара и т.д.

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

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

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

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

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

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

На рисунке атрибуты Фамилия, Имя, Отчество и Дата рождения входят в альтернативный ключ № 1 (АК1), Номер паспорта составляет альтернативный ключ № 2 (АК2).

Инверсион­ные входы обозначаются как (IEn.m), где n - порядковый номер входа, m -порядковый номер атрибута. Инверсионный вход IE1 (атрибут Должность) позволяет выбрать всех сотрудников, занимающих одинаковую должность, IE2 (атрибут Номер офиса) - всех сотрудников, работающих в одном офисе, IE3 (атрибуты Город и Улица) - всех сотрудников, живущих на одной ули­це.

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

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

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

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

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

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

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

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

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

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

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

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

Домены

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

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

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

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

По умолчанию ERwin DM имеет четыре предопределенных домена: String, Number, Blob¹, Datetime.

Нормализация и денормализация

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

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

Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам (6 нормальных форм) – формализованным требованиям к организации данных.

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

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

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

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

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

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

ERwin DM позволяет сохранить на логическом уровне нормализованную структуру, при этом построить на физическом уровне структуру (возможно, денормализованную), которая обеспечит лучшую производительность.

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

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

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

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

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

• Автоматизация. ERwin DM упрощает совершенствование логической и физической моделей. Вместо трудоемкого «ручного» изменения модели можно использовать встроенные Мастеры для автоматизации процессов преобразования (трансформации) объектов модели.

• Трассировка. Для каждого объекта модели, создаваемого при трансформации, в ERwin DM ведется историческая информация. Историю трансформированных объектов можно проследить.

• Сохранение свойств объекта. Свойства трансформированных объектов сохраняются.

Для запуска процесса трансформации следует выбрать объекты, участвующие в трансформации и щелкнуть по соответствующей кнопке на панели трансформаций ERwin Transform Toolbar (табл.).

Таблица. Описание функций панели трансформаций (ERwin Transform Toolbar).

Элемент управления	Описание	Соответствующий пункт меню
	Преобразовать связь «многие ко многим»: создать третью сущность (таблицу) и две новые идентифицирующие связи «один ко многим» от исходных к новой сущности (таблице).	Edit/Many To Many Transform
	Заменить связь «иерархия наследования» между предком и потомком идентифицирующими связями.	Edit/Supertype-Subtype Identity Transform
	Свернуть связь «иерархия наследования»: мигрировать первичный ключ и неключевые атрибуты в иерархии наследования от потомков к предку.	Edit/ Supertype-Subtype Rollup Transform
	Развернуть связь «иерархия наследования»: мигрировать первичный ключ и неключевые атрибуты в иерархии наследования от предка к потомкам.	Edit/ Supertype-Subtype Rolldown Transform
	Разбить вертикально исходную таблицу на несколько таблиц.	Edit/ Vertical Partition Transform
	Разбить горизонтально исходную таблицу на несколько таблиц.	Edit/Horizontal Partition Transform
	Заменить две связанные таблицы на одну денормализованную таблицу (денормализация развертывания).	Edit/ Roll-Down Denormalization Transform
	Заменить две связанные таблицы на одну денормализованную таблицу (денормализация свертывания).	Edit/Roll-Up Denormalization Transform
	Скопировать колонку их одной таблицы в другую и затем связать две колонки (денормализация колонки).	Edit/ Linked Column Copy Transform
	Отобразить исходные объекты трансформации. Выполняется для всех трансформаций активной модели. Чтобы отобразить исходные объекты для одной трансформации, следует щелкнуть по имени трансформации правой кнопкой мышки в Навигаторе модели Model Explorer и в появившемся контекстном меню выбрать команду Show Source Objects.	Edit/ Show Transform Source Objects
	Отобразить целевые объекты трансформации (результат трансформации). Выполняется для всех трансформаций активной модели. Чтобы отобразить целевые объекты для одной трансформации, следует щелкнуть по имени трансформации правой кнопкой мышки в Навигаторе модели Model Explorer и в появившемся контекстном меню выбрать команду Show Target Objects.	Edit/ Show Transform Target Objects
	Отменить (Reverse) результаты всех трансформации в активной модели. В результате имена трансформаций исчезают из списка трансформаций в Навигаторе модели Model Explorer, и модель «откатывается» к состоянию до выполнения трансформаций. Связи трансформации разрываются, исходные объекты модели сохраняются, а целевые объекты, созданные при трансформации, удаляются.	Edit/ Reverse All Transforms
	Принять результаты всех трансформаций активной модели. В результате имена трансформаций исчезают из списка трансформаций в Навигаторе модели Model Explorer, и все преобразования, сделанные во время трансформаций, становятся необратимыми. Связи трансформации разрываются, целевые объекты модели, созданные при трансформации, сохраняются, а исходные объекты удаляются.	Edit/ Resolve All Transforms

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

Таблица. Состояние объектов до и после трансформации.

Исходные объекты	Используемая трансформация	Результат трансформации
	Многие ко многим
	Идентификация связи «иерархия наследования»
	Свертывание связи «иерархия наследования»
	Развертывание связи «иерархия наследования»
	Вертикальное разбиение таблицы
	Горизонтальное разбиение таблицы
	Денормализация развертывания
	Денормализация свертывания	ИЛИ
	Скопировать/связать столбец

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

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

ERwin DM предлагает два способа "отмены" трансформации. Связи трансформации можно разорвать, либо трансформацию можно отменить.

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