ERwin. Опыт использования.. Учебное пособие по дисциплинам информационные системы в экономике, проектирование информационных систем
 Скачать 3.87 Mb.
|
|
Restrict. Не разрешает удалять, обновлять или редактировать экзем- пляр в родительской или дочерней сущности (таблице), если существует один или более связанных с ним экземпляров в дочерней или родительской сущности (таблице). Cascade. Если экземпляр в родительской сущности (таблице) удаля- ется, вставляется или обновляется, то каждый связанный экземпляр в до- черней сущности (таблице) также удаляется, вставляется или обновляется. Set null. Если экземпляр в родительской сущности (таблице) удаля- ется, вставляется или обновляется, то атрибут (колонка) внешнего ключа каждого связанного экземпляра дочерней сущности (таблице) устанавли- вается в Null. Set default. Если экземпляр в родительской сущности (таблице) уда- ляется, вставляется или обновляется, то атрибут (колонка) внешнего ключа каждому связанному экземпляру дочерней сущности (таблице) назначается определенное значение по умолчанию. No Action. Если экземпляр в родительской сущности (таблице) уда- ляется, вставляется или обновляется, то во всех связанных экземплярах дочерней сущности никакие действия не производятся. None. Не требуются действия по поддержанию ссылочной целостно- сти. Для отображения на диаграмме установленных правил ссылочной це- лостности следует в меню Format выбрать пункт Relationship Display, затем Referential Integrity. В таблице 13 приведены примеры правил ссылочной целостности при удалении строки родительской таблицы. Таблица 13. Примеры правил ссылочной целостности при удалении строки родительской таблицы. № Название Пример 1 Parent Delete RESTRICT - удаление с ограничением На рис. 53 между сущностями Команда и Игрок суще- ствует идентифицирующая связь. Экземпляр сущности Игрок не может существовать без Команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL). Правило запрещает удаление команды, пока в ней чис- лится хотя бы один игрок (для удаления команды сна- чала нужно удалить всех игроков). 58 При попытке выполнить удаление строки из родитель- ской таблицы Команда, в которой есть хотя бы один игрок, сервер реляционной СУБД возвратит ошибку. 2 Parent Delete CASCADE - удаление каскадом На рис. 53 между сущностями Команда и Игрок суще- ствует идентифицирующая связь. Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде играет. Номер команды не может принимать значение NULL). Согласно правилу вместе с командой удаляются сразу все ее игроки. Примечание. Сущности Игрок и Гол, в свою очередь, тоже связаны идентифицирующей связью и в случае удаления каскадом команды будут удалены все игроки этой команды и все голы, которые они забили. Выпол- нение команды на удаление одной строки фактически может привести к удалению тысяч строк в базе данных, поэтому использовать правило удаления каскадом следует с осторожностью. 3 Parent Delete SET NULL - удаление с установкой в Null На рис. 46 установлена необязательная неидентифици- рующая связь между сущностями Отдел и Сотрудник. Экземпляр сущности Сотрудник может существовать без ссылки на отдел (атрибут внешнего ключа Где ра- ботает. Номер отдела может принимать значение NULL). Согласно правилу при удалении отдела атрибут внеш- него ключа сущности Сотрудник - Где работает. Но- мер отдела примет значение NULL. Это означает, что при удалении отдела сотрудник остается работать в ор- ганизации, не будучи приписан к какому-либо отделу, и информация о нем сохраняется. 4 Parent Delete SET DEFAULT - удаление с уста- новкой значений по умолчанию На рис. 53 существует идентифицирующая связь между сущностями Команда и Игрок. Согласно правилу атрибут внешнего ключа получит значение по умолчанию. Т.е. при удалении команды атрибут первичного ключа в сущности Игрок (В какой команде играет. Номер ко- манды)получит значение по умолчанию. Например, при удалении команды ее игроки могут быть переведе- ны в другую команду. 5 Parent Delete NONE - простое удаление На рис. 53 существует идентифицирующая связь между сущностями Команда и Игрок. Согласно правилу при удалении значение атрибута внешнего ключа не меняется. Запись об игроке "повисает в воздухе", т. е. ссылается на несуществующую уже команду. 59 Ситуация, когда при удалении значение атрибута внешнего ключа не меняется (режим Parent Delete NONE) характерна для «плоских» таб- лиц. Например, если информация об игроках и командах хранится в dbf- файлах, можно удалить запись о команде, при этом файл игроков «ничего не будет знать» о том, что соответствующей команды не существует. По- этому в настольных или файл-серверных системах функциональность, обеспечивающая правила ссылочной целостности, реализуется в клиент- ском приложении. Правила удаления управляют тем, что будет происходить в базе дан- ных при удалении строки. Аналогично правила вставки и обновления управляют тем, что будет происходить с базой данных, если строки изме- няются или добавляются. Например, можно установить правило, которое разрешает вносить новую команду только в том случае, когда в нее зачис- лен хотя бы один игрок. Желаемое поведение может быть достигнуто сле- дующими действиями: Задать мощность связи между сущностями Команда и Игрок , рав- ную 1 или более (тип Р). Предполагается, что установлена идентифицирующая связь. Присвоить действие RI-триггера Parent Insert-CASCADE для того, чтобы при создании новой строки в таблице Команда автоматически созда- валась хотя бы одна строка в дочерней таблице Игрок. (рис. 54) Присвоить связи действие RI-триггера Parent Delete-CASCADE для того, чтобы при удалении строки из таблицы Команда соответствующая строка или строки из таблицы Игрок тоже удалялись (рис. 54) Связь "многие ко многим" Связь "многие ко многим" может быть создана только на уровне логи- ческой модели. На рис. 55 показан пример связи "многие ко многим". Врач может принимать много пациентов, пациент может лечиться у не- скольких врачей. Такая связь обозначается сплошной линией с двумя точ- ками на концах Рис. 55. Пример связи «многие ко многим». Для внесения связи следует установить курсор на кнопке на панели инструментов ERwin, щелкнуть по одной, затем по другой сущности. Связь "многие ко многим" должна именоваться двумя фразами - в обе стороны (в примере "лечит/лечится у"). Это облегчает чтение диаграммы. Связь на рис. 55 следует читать так: Врач <лечит> Пациента, Пациент <лечится у> Врача. 60 На физическом уровне связь "многие ко многим" должна быть преоб- разована. По умолчанию при переходе к физическому уровню ERwin DM автоматически не преобразует связь "многие ко многим", и на физическом уровне диаграмма выглядит так же, как и на логическом (рис. 55). Однако при генерации схемы такая связь игнорируется. Для преобразования связи "многие ко многим" необходимо щелкнуть по связи правой кнопкой мыши и выбрать пункт меню Create Association Table или выбрать связь и щелкнуть по инструменту на панели транс- формаций ERwin Transform Toolbar (см. табл. 5). (Подробнее операции преобразования будут рассмотрены разделе «Трансформации».) Появляет- ся Мастер трансформаций - Many-To-Many Transform Wizard, состоящий из 4 шагов-диалогов. Для перехода к следующему шагу надо щелкнуть по кнопке Next (Далее). На втором и третьем шаге следует задать имя вновь создаваемой таблицы и имя преобразования. Преобразование связи вклю- чает создание новой таблицы и двух новых связей "один ко многим" от старых к новой таблице (рис.56). При этом имя новой таблице присваива- ется как Имя1_Имя2. Рис. 56. Пример автотрансформации связи «многие ко многим». Описанного выше решения проблемы связи «многие ко многим» не всегда оказывается достаточно. В примере таблица Врач_Пациент имеет смысл визита к врачу, поэтому ее следует переименовать согласно бизнес- логике в Посещение. Один и тот же пациент может много раз посещать врача, поэтому для того, чтобы идентифицировать визит, необходимо в со- став первичного ключа таблицы Посещение добавить дополнительную ко- лонку, например дату-время посещения (ДатаВремяПосещения, рис. 57). Следует заметить, что после переименования таблицы на физическом уровне на логическом уровне представление модели не изменится, диа- грамма будет выглядеть так, как на рис. 56. Рис. 57. Пример дополнения физического уровня модели после трансформации связи «многие ко многим». 61 Типы зависимых сущностей Как было указано выше, связи определяют, является ли сущность не- зависимой или зависимой. Различают несколько типов зависимых сущно- стей. Характеристическая - зависимая дочерняя сущность (рис.58), кото- рая связана только с одной родительской и по смыслу хранит информацию о характеристиках родительской сущности. Рис. 58. Пример характеристической сущности «Хобби». Ассоциативная - сущность, связанная с несколькими родительскими сущностями. Такая сущность содержит информацию о связях сущностей. Примером ассоциативной сущности является Посещение на рис. 57. Именующая - частный случай ассоциативной сущности, не имеющей собственных атрибутов (только атрибуты родительских сущностей, мигри- ровавших в качестве внешнего ключа). Примером именующей сущности является Врач_Пациент на рис. 56. Категориальная - дочерняя сущность в иерархии наследования (см. ниже). Иерархия категорий (иерархия наследования). Представление об иерархиях категорий, их типах и отображении в нотациях IDEF1X, IE было дано в разделе «Особенности методологий IDEF1X и IE». Рассмотрим возможные стадии построения иерархии наследования. А) Определение сущностей с общими (но определению) атрибутами. Предположим, в процессе проектирования созданы сущности Посто- янный сотрудник и Совместитель (рис. 59). Можно заметить, что часть атрибутов у этих сущностей (Фамилия, Имя, Отчество, Дата рожде- ния, Должность) имеет одинаковый смысл. Рис. 59. Сущности с общими по смыслу атрибутами. В случае обнаружения совпадающих по смыслу атрибутов следует со- здать новую сущность (Сотрудник) - родовой предок и перенести в нее общие атрибуты. 62 Б) Создание неполной структуры категорий. Создается категориаль- ная связь от новой сущности - родового предка к старым сущностям- потомкам. Новая сущность дополняется атрибутом-дискриминатором ка- тегории (Тип) (рис. 60). Рис. 60. Пример неполной иерархии категорий. Рис. 61. Диалог Subtype Properties. Для создания категориальной связи следует: левой кнопкой мышки щелкнуть по кнопке (см. табл. 11); щелкнуть сначала по родовому предку, а затем по потомку; 63 для установления второй связи в иерархии категории сначала щелк- нуть по символу категории, затем по второму (третьему и т.д.) потомку. Для редактирования категорий нужно щелкнуть правой кнопкой мы- ши по символу категории и выбрать в контекстном меню пункт Subtype Properties. В диалоге Subtype Properties (рис. 61) можно указать атрибут- дискриминатор категории Тип (список Discriminator) и тип категории - In- complete – неполная (раздел Type: опции Complete/Incomplete - полная/неполная). В) Создание полной структуры категорий. Прово- дится дополнительный поиск сущностей, имеющих общие по смыслу атрибуты с родовым предком. В примере это сущность Консультант (рис. 62). Общие атрибуты переносятся в родового предка, и категория преобразуется в полную. Признак полной категории устанавливается в диалоге Subtype Relation- ship (в разделе Type следует выбрать опцию Complete). Сущность Консультант не имеет атрибута Должность, поэтому в родовом предке значение этого атрибута в случае консультанта будет NULL. В зависимости от бизнес-правил атрибут Должность может быть перенесен обратно из родового предка в сущно- сти-потомки Постоянный сотрудник и Совместитель или может быть принято решение о том, что для консультанта также требуется указывать должность (рис. 63). Рис. 63. Пример полной иерархии категорий. Г) Пример комбинации полной и неполной категорий показан на рис.64. Согласно представленному на рисунке фрагменту модели сотруд- ник может быть совместителем или постоянным сотрудником (неполная категория, т.к. не отображены сотрудники-консультанты), а постоянный сотрудник является любо мужчиной либо женщиной (полная категория). Рис. 62. Дополни- тельная сущность. 64 Рис. 64. Пример смешанной иерархии категорий. Ключи Выделяют следующие виды ключей: потенциальные, первичные, сложные, альтернативные, инверсные, внешние, суррогатные, которые бу- дут рассмотрены ниже. Каждый экземпляр сущности должен быть уникален. Первичный ключ (primary key) - это атрибут или группа атрибутов, уникально идентифицирующая каждый экземпляр сущности. Атрибуты первичного ключа на диаграмме располагаются выше горизонтальной ли- нии (рис. 65). При внесении нового атрибута в диалоге Attributes для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key в нижней части закладки General (рис. 38). На диаграмме неключевой атрибут можно перевести в состав первичного ключа, вос- пользовавшись режимом переноса атрибутов. Выбор первичного ключа может оказаться непростой задачей, реше- ние которой в состоянии повлиять на эффективность будущей информаци- онной системы. В одной сущности могут оказаться несколько атрибутов или наборов атрибутов, претендующих на роль первичного ключа. Такие претенденты называются потенциальными ключами (candidate key). Ключи могут быть сложными (составными), т. е. содержащими не- сколько атрибутов. 65 Рис. 65. Ключи сущности «Сотрудник». Рассмотрим потенциальные ключи сущности Сотрудник (рис. 65): 1. Табельный номер. 2. Номер паспорта. 3. Фамилия + Имя + Отчество. Выберем из них первичный ключ. Первичный ключ должен удовлетворять следующим требованиям: уникальность, компактность, простота, не содержать нулевых (отсутству- ющих) значений; значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности. Рассмотрим эти тре- бования подробнее. Уникальность. Два экземпляра не должны иметь одинаковых значе- ний возможного ключа. Потенциальный ключ № 3 (Фамилия + Имя + Отчество) является плохим кандидатом, поскольку в организации могут работать полные тезки, поэтому добавим атрибут дату рождения: Фами- лия + Имя + Отчество + Дата рождения. Компактность. Сложный потенциальный ключ не должен содержать ни одного атрибута, удаление которого приводило бы к утрате уникально- сти. Для обеспечения уникальности ключа № 3 дополним его атрибутами Дата рождения и Цвет волос. Если бизнес-правила говорят, что сочета- ния атрибутов Фамилия + Имя + Отчество + Дата рождения достаточ- но для однозначной идентификации сотрудника, то Цвет волос оказывает- ся лишним, т.е. ключ Фамилия + Имя + Отчество + Дата рождения + Цвет волос не является компактным. При выборе первичного ключа предпочтение должно отдаваться бо- лее простымключам, т. е. ключам, содержащим меньшее количество атри- бутов. В рассматриваемом примере потенциальные ключи № 1 и № 2 предпочтительней ключа № 3. Атрибуты ключа не должны содержать нулевых значений. Если до- пускается, что сотрудник может не иметь паспорта или вместо паспорта иметь какое-либо другое удостоверение личности, то потенциальный ключ 66 № 2 не подойдет на роль первичного ключа. Если для обеспечения уни- кальности необходимо дополнить потенциальный ключ дополнительными атрибутами, то они не должны содержать нулевых значений. Дополняя ключ № 3 атрибутом Дата рождения, нужно убедиться в том, что даты рождения известны для всех сотрудников. Значение атрибутов ключа не должно меняться в течение всего вре- мени существования экземпляра сущности. Сотрудница организации мо- жет выйти замуж и сменить как фамилию, так и паспорт. Поэтому ключи № 2 и 3 не подходят на роль первичного ключа. Иногда создают искусственный (суррогатный) ключ, например, Номер сотрудника, Номер клиента, Номер товара и т.д. Каждая сущность должна иметь, по крайней мере, один потенциаль- ный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Некоторые сущности могут иметь бо- лее одного возможного ключа. Тогда один из них становится первичным, а остальные - альтернативными ключами. Альтернативный ключ (Alternate Key) - это потенциальный ключ, не ставший первичным. ERwin DM позволяет выделить атрибуты альтерна- тивных ключей, и по умолчанию в дальнейшем при генерации схемы базы данных по этим атрибутам будет генерироваться уникальный индекс. Инверсный вход (Inversion Entry) - это атрибут или группа атрибу- тов, которые не определяют экземпляр сущности уникальным образом, но часто используются в запросах к базе данных для обеспечения доступа к нескольким экземплярам сущности, объединенным каким-либо одним признаком. В этом случае для повышения производительности информа- ционной системы используются неуникальные индексы. ERwin DM позво- ляет на уровне логической модели назначить атрибуты, которые будут участвовать в неуникальных индексах, а затем сгенерировать неуникаль- ный индекс для каждого Inversion Entry. В ERwin DM создать альтернативные ключи и инверсионные входы можно в диалоге Key Groups (рис. 66). Для запуска диалога следует в меню Model выбрать пункт Key Groups или щелкнуть правой кнопкой мышки по сущности и в появившемся контекстном меню выбрать пункт Key Groups. В верхней части диалога находится список сущностей, в средней части - список ключей, в нижней - список атрибутов, доступных для включения в состав ключа (слева), и список выбранных ключевых атрибутов (справа). Каждый вновь созданный ключ должен иметь хотя бы один атрибут. Каж- дому ключу соответствует индекс, имя которого также присваивается ав- томатически. Имена ключа и индекса можно изменить вручную. На диаграмме атрибуты альтернативных ключей обозначаются как (AKn.m), где n - порядковый номер ключа, m - порядковый номер атрибута в ключе. Когда альтернативный ключ содержит несколько атрибутов, (AKn.m) ставится после каждого. |