ERwin. Опыт использования.. Учебное пособие по дисциплинам информационные системы в экономике, проектирование информационных систем
 Скачать 3.87 Mb.
|
|
Definition диалога Attributes позволяет записывать опреде- ления отдельных атрибутов. Определения атрибутов можно также автома- тически сгенерировать как часть схемы (CREATE COMMENT on enti- ty_name.attribute name). Закладка Note позволяет добавлять замечания об одном или несколь- ких атрибутах сущности, которые не вошли в определения. В закладке History отображается история создания и изменения атрибутов. Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойства должны быть внесены в диа- лог User Defined Property как свойства атрибутов. 47 Закладка Key Group (рис. 40) позволяет включить атрибут в состав первичного, альтернативного или инверсного ключа. Рис. 40. Закладка Key Group диалога Attributes. На диаграмме IDEF1X сущность и атрибуты отображаются следую- щим образом (рис. 41): имя сущности показывается над прямоугольником, изображающим сущность, список атрибутов сущности - внутри прямо- угольника. Список разделен горизонтальной чертой, выше которой распо- ложены атрибуты первичного ключа, ниже - неключевые атрибуты. Рис. 41. Отображение сущности и атрибутов. Очень важно дать атрибуту правильное имя. Атрибуты должны име- новаться в единственном числе и иметь четкое смысловое значение. Со- блюдение этого правила позволяет частично решить проблему нормализа- ции данных уже на этапе определения атрибутов. Например, создание в сущности Сотрудник атрибута Телефоны Сотрудника противоречит тре- бованиям нормализации, т.к. атрибут должен быть атомарным, т.е. не со- держать множественных значений. Согласно синтаксису IDEF1X имя ат- рибута должно быть уникально в рамках модели (а не только в рамках сущности!); следовательно, новый атрибут, если его имя совпадает с уже существующим, должен быть переименован. На практике такое переиме- 48 нование не всегда удобно, поэтому по умолчанию эта опция выключена, однако в случае необходимости ее можно включить. Для настройки правил уникальности имен модели (не только имен ат- рибутов) используют закладку Duplicate Names диалога Model Naming Op- tions (меню Tools/Names/Model Naming Options) (рис. 42) Можно задать следующие режимы именования: Рис. 42. Диалог Model Naming Options. Allow duplicate name – позволить использование одинаковых имен (опция по умолчанию). Automatically Rename duplicate names – автоматически переимено- вывать атрибут (сущность) при попытке внесения уже существующего имени атрибута, при этом к имени атрибута добавляется число. Например, если атрибут Имя уже существует в модели, то при добавлении новых ат- рибутов Имя в ту же или в другую сущность они будут автоматически пе- реименованы: Имя_2, затем Имя_3 и т.д. Ask – запрашивать возможные действия каждый раз при внесении од- ноименных атрибутов (сущности). ERwin DM будет показывать на экране диалог Unique Name каждый раз, когда вводится неуникальное имя сущно- сти или атрибута. В диалоге Unique Name можно ввести другое имя или разрешить дублирование (рис. 43). Новое имя уже не проверяется на уни- кальность. Disallow duplicate names – запретить внесение одинаковых имен. При попытке использовать уже существующее имя ERwin DM сам производит переименование, чтобы обеспечить уникальность имен в модели. 49 Рис. 43. Диалог Unique Name. Кроме общепринятых правил именования атрибутов часто требуется следовать правилам, разработанным внутри организации - корпоративным стандартам. Настроить правила именования можно с помощью диалогов Model Naming Option и Edit Naming Standards (меню Tools/Names). Каждый атрибут должен быть определен в закладке Definition, при этом следует избегать циклических определений, например когда термин 1 определяется через термин 2, термин 2 - через термин 3, а термин 3, в свою очередь, - через термин 1. Иногда определение атрибута легче дать через описание области значений. Например, Оценка школьника - это число, принимающее значения 2,3,4 или 5. Часто приходится создавать производные атрибуты, т. е. атрибуты, значение которых можно вычислить из других атрибутов. Примером мо- жет служить Возраст сотрудника, который может быть вычислен из ат- рибута Дата рождения сотрудника. Такой атрибут может привести к конфликтам: если вовремя не обновить значение атрибута Возраст со- трудника, он может противоречить значению атрибута Дата рождения сотрудника. Производные атрибуты - ошибка нормализации, однако их вводят для повышения производительности системы - если необходимо узнать возраст сотрудника, можно обратиться к соответствующему атри- буту, а не проводить вычисления (которые на практике могут быть значи- тельно более сложными, чем в приведенном примере с датой рождения). ERwin DM позволяет перемещать атрибуты внутри сущности и между сущностями. Для этого необходимо щелкнуть левой кнопкой мышки по атрибуту. Указатель приобретает вид кисти руки , после чего можно, удерживая левую кнопку мышки, переместить атрибут. Связи Связь является логическим отношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (Relationship Verb Phrases) (рис. 44). Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например: Каждый КЛИЕНТ <размещает> ЗАКАЗы; Каждый ЗАКАЗ <выполняется> СОТРУДНИКом. 50 Рис. 44. Пример именования связей (Relationship Verb Phrases). Связь показывает, какие именно заказы разместил клиент и какой именно сотрудник выполняет заказ. По умолчанию имя связи на диаграм- ме не показывается. Для отображения имени связи следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любо- му месту диаграммы, не занятому объектами модели, выбрать пункт Rela- tionship Display и затем включить опцию Verb Phrase. На логическом уровне можно установить идентифицирующую связь "один ко многим", связь "многие ко многим" и неидентифицирующую связь "один ко многим" (см. табл. 11). Связи идентифицирующие и неидентифицирующие В IDEF1X и в IE различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифициру- ющая связь устанавливается между независимой (родительский конец свя- зи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin DM автоматически преобразует дочер- нюю сущность в зависимую. Зависимая сущность изображается прямо- угольником со скругленными углами (сущность Заказ на рис. 45). Экзем- пляр зависимой сущности определяется только через отношение к роди- тельской сущности, т. е. в структуре на рис. 45 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, кото- рый его размещает. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав пер- вичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ - (For- eign Key - FK) (рис. 45). В дальнейшем, при генерации схемы базы данных, атрибуты первичного ключа получат признак NOT NULL, что означает не- возможность внесения записи в таблицу заказов без информации о номере клиента. Рис. 45. Идентифицирующая связь. 51 При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущно- сти мигрируют в состав неключевых компонентов дочерней сущности. Не- идентифицирующая связь служит для связывания независимых сущностей. На рис. 46 экземпляр сущности Сотрудник может существовать безотно- сительно к какому-либо экземпляру сущности Отдел, т. е. сотрудник мо- жет работать в организации, не числясь в каком-либо отделе. Рис. 46. Неидентифицирующая связь. Идентифицирующая связь показывается на диаграмме сплошной ли- нией с жирной точкой на дочернем конце связи (рис. 45), неидентифици- рующая - пунктирной (рис. 46). Рис. 47. Диалог Relationships. 52 Для создания новой связи следует: щелкнуть левой кнопкой мышки по кнопке рисования связи впанели инструментов ERwin (табл. 11); щелкнуть сначала по родительской, а затем по дочерней сущности. Размещение фрагментов линии связи можно изменить: левой кнопкой мышки захватить нужный фрагмент линии связи и перенести его в другую позицию. Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по линии связи и выбрать в контекстном меню пункт Relationship Properties. В появившемся диалоге Relationships в закладке General можно задать имя связи (раздел Verb Phrase), мощность (раздел Cardinality), тип связи (раздел Relationship Type) (рис. 47). Имя связи (Verb Phrase) - фраза, характеризующая отношение меж- ду родительской и дочерней сущностями. Для связи "один ко многим" (идентифицирующей или неидентифицирующей) достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child) (рис. 45, 46). Для связи "многие ко многим" следует ука- зывать имя как Parent-to-Child, так и Child-to-Parent. Мощность связи (Cardinality) служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают 4 типа мощности, которые были рассмотрены в разделе «Осо- бенности методологий IDEF1X и IE» По умолчанию символ, обозначаю- щий мощность связи, не показывается на диаграмме. Для его отображения следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами моде- ли, выбрать пункт Relationship Display и затем включить опцию Cardinality. Тип связи (Relationship Type). Можно изменить тип связи: идентифи- цирующая или неидентифицирующая. Для неидентифицирующей связи в разделе Nulls можно выбрать переключатель обязательности связи: No Nulls – обязательная неидентифицирующая связь. При генерации схемы базы данных атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. Nulls Allowed – необязательная неидентифицирующая связи. Внеш- ний ключ может принимать значение NULL. Необязательная неидентифи- цирующая связь помечается прозрачным ромбом со стороны родительской сущности (см. рис 46). В закладке Definition диалога Relationships можно дать более полное определение связи. В закладке RI Actions определяют правила ссылочной целостности (referential integrity), о которых будет рассказано позднее. За- кладка UDP служит для задания значений свойств, определяемых пользо- вателем. Предварительно эти свойства должны быть внесены в диалог User 53 Defined Property (меню Model/UDP Dictionary) как свойства связи (Rela- tionship). В закладке Rolename (рис.48) можно задать имя роли. Рис. 48. Закладка Rolenameдиалога Relationships. Имя роли (функциональное имя) - показывает, какую роль играет мигрировавший атрибут в дочерней сущности. В примере, приведенном на рис. 49, в сущности Сотрудник внешний ключ Номер отдела имеет функциональное имя "Где работает", которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов пока- зывается только имя роли. Для отображения полного имени атрибута (имя роли + имя мигрировавшего атрибута) в контекстном меню, которое появ- ляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, следует выбрать пункт Entity Display и за- тем включить опцию Rolename/Attribute. Полное имя показывается как имя роли, имя мигрировавшего атрибута, разделенные точкой (рис. 49). Рис. 49. Пример имен ролей внешних ключей. 54 Обязательным является применение имен ролей в том случае, когда два или более атрибута одной и той же сущности имеют одинаковую об- ласть значений, но разный смысл. На рис. 50 сущность Продажа валюты содержит информацию об акте обмена валюты, в котором участвуют две валюты - проданная и купленная. Информация о валютах содержится в сущности Валюта. Следовательно, сущности Продажа валюты и Валю- та должны быть связаны дважды, и первичный ключ Номер валюты должен дважды мигрировать в сущность Продажа валюты в качестве внешнего ключа. Требуется различать два атрибута, мигрировавших из сущности Валюта: один содержит номер проданной валюты, а другой со- держит номер купленной валюты,- они имеют общую область значений и ссылаются на одну и ту же сущность Валюта. В примере на рис. 50 атри- бутам присвоены разные имена ролей: Проданная и Купленная. Рис. 50. Пример обязательного использования имен ролей. Другим примером обязательности присвоения имен ролей являются рекурсивные связи, когда одна и та же сущность является и родительской и дочерней одновременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рис. 49 сущность Сотрудник содержит атрибут первичного ключа Та- бельный номер. Информация о руководителе сотрудника содержится в той же сущности, поскольку руководитель работает в той же организации. Чтобы сослаться на руководителя сотрудника, следует создать рекурсив- ную связь (на рис. 49 связь Руководит/Подчиняется) и присвоить имя роли (Руководитель). Заметим, что рекурсивная связь может быть только неидентифицирующей. В противном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии - у дерева подчиненности должен быть корень - сотрудник, который никому не под- чиняется. Связь руководит/подчиняется на рис. 49 позволяет хранить древовидную иерархию подчиненности сотрудников. Такой вид рекурсив- ной связи называется иерархической рекурсией (hierarchical recursion) и за- дает связь, когда руководитель (экземпляр родительской сущности) может иметь множество подчиненных (экземпляров дочерней сущности), но под- чиненный имеет только одного руководителя (рис. 51 слева). 55 Рис. 51. Подчиненность экземпляров сущности в рекурсии. Другим видом рекурсии является сетевая рекурсия (network recursion) (рис. 51 справа), когда руководитель может иметь множество подчиненных и, наоборот, подчиненный может иметь множество руководителей. Сетевая рекурсия задает паутину отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в связи "многие ко многим". Для разрешения связи "многие ко многим" необходимо создать новую сущность (подробно связь "многие ко многим" будет рассмотрена ниже). На рис. 52 рассмотрен пример реализации сетевой рекурсии. Струк- тура моделирует родственные отношения между членами семьи любой сложности. Атрибут Тип отношения может принимать значения "отец- сын", "мать-дочь", "дед-внук", "свекровь-невестка", "тесть-зять" и т. д. По- скольку родственное отношение связывает всегда двух людей, от сущно- сти Родственник к сущности Родственное отношение установлены две идентифицирующие связи с именами ролей "Старший" и "Младший". Каждый член семьи может быть в родственных отношениях с любым дру- гим членом семьи, более того, одну и ту же пару родственников могут свя- зывать разные типы родственных отношений. Рис. 52. Пример реализации сетевой рекурсии. Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более - только имя роли. На рис. 53 изображена структура данных, которая содержит сущ- ность Команда, сущность Игрок, в которой хранится информация об игро- ках каждой команды, и сущность Гол, содержащая информацию о голах, которые забивает каждый игрок. Атрибут внешнего ключа Номер коман- ды сущности Игрок имеет имя роли В какой команде играет. На следую- 56 щем уровне, в сущности Гол, отображается только имя роли соответству- ющего атрибута внешнего ключа (В какой команде играет). Рис. 53. Пример миграции имен ролей. Правила ссылочной целостности (RI - referential integrity) – прави- ла определяющие, что произойдет в случае, если будут произведены изме- нения в родительской или дочерней сущности: добавление (INSERT), об- новление (UPDATE), удаление (DELETE). Правила ссылочной целостно- сти позволяют избежать «висячих» данных и позволяют придерживаться бизнес правил. ERwin DM автоматически присваивает каждой связи значение ссы- лочной целостности, устанавливаемой по умолчанию, прежде чем доба- вить ее в диаграмму. В закладке RI Actions диалога Model Properties (меню Model/Model Properties) можно изменить правила ссылочной целостности по умолчанию. На основе этих правил при генерации схемы базы данных будут сгенерированы: правила декларативной ссылочной целостности для каждой связи, триггеры, обеспечивающие ссылочную целостность. Переопределить правила ссылочной целостности для конкретной свя- зи можно в закладке RI Actions диалога Relationships (рис. 54). Рис. 54. Закладка RI Actionsдиалога Relationships. 57 Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд вставки, замены или удаления. По умолчанию ERwin DM генерирует триггеры, дублирующие декларативную ссылочную целостность. Для связей в модели ERwin DM можно определить следующие типы действий триггеров ссылочной целостности (в зависимости от выбранной СУБД и ее версии этот список может быть короче): |