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

Основные компоненты диаграммы епуш - это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объек­тов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соот­ветствует таблица, экземпляру сущности - строка в таблице, а атрибуту - колонка таблицы.

Построение модели данных предполагает определение сущностей и ат­рибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объ­ект, событие или концепцию, информация о которых должна сохраняться. Сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить " техничес­ких" наименований и быть достаточно важными для того, чтобы их моде­лировать. Именование сущности в единственном числе облегчает в даль­нейшем чтение модели. Фактически имя сущности дается по " имени се экземпляра. Примером может быть сущность Заказчик( но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказчика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customerс колонками Customer_number, Customer_nameи Customer_adders.

Для внесения сущности в модель необходимо (убедившись предвари­тельно, что вы находитесь на уровне логической модели - переключателем между логической и физической моделью служит раскрывающийся список и правой части панели инструментов) " кликнуть" но кнопке сущности на панели инструментов (ER-win Toolbox) , затем " кликнуть" по тому месту на диаграмме, где необходимо расположить новую сущность. Щелкнув правой кнопкой мыши по сущности и выбрав из всплывающего меню пункт Entity Editor, можно вызвать диалог Entity Editor, в котором определяются имя, описание и комментарии сущности (рис. 2.10).

Каждая сущность должна быть полностью определена с помощью тек­стового описания в закладке Definition. Закладки Note, Note2, Note3, UDP (User Defined Properties - Свойства, определенные пользователем) служат для внесения дополнительных комментариев и определений к сущ­ности. В прежних версиях ER-win закладкам Note2 и Note3 соответствовали окна Query и Sample.

Закладка Definition используется для ввода определения сущности. Эти определения полезны как на логическом уровне, поскольку позволяют по­нять, что это за объект, так и на физическом уровне, поскольку их можно экспортировать как часть схемы и использовать в реальной БД (CREATE COMMENT on entity_name).

Закладка Note позволяет добавлять дополнительные замечания о сущно­сти, которые не были отражены в определении, введенном в закладке Definition. Здесь можно ввести полезное замечание, описывающее какое-либо бизнес-правило или соглашение по организации диаграммы.

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

Рис. 2.10. Диалог Entity Editor

Закладка Note3 позволяет вводить примеры данных для сущности (впроизвольной форме).

В закладке Icon каждой сущности можно поставить в соответствие изо­бражение, которое будет отображаться в режиме просмотра модели на уровне иконок (см. табл. 2.2). В этой закладке можно задать как большую иконку, которая будет отображаться на уровне Icon, так и малую иконку, которая будет отображаться на всех уровнях просмотра модели. Для связы­вания изображения с сущностью необходимо щелкнуть по кнопке , в

появившемся диалоге ER-win Icon Editor щелкнуть по кнопке Import; и вы­брать соответствующий файл формата bmp. После выбора иконки она ото­бражается в закладке Icon диалога Entity Editor (рис. 2.11).

Рис. 2.11. Закладка Icon диалога Entity Editor

Использование свойств, определяемых пользователем (UDP), аналогич­но их использованию в BP-win (см. гл. 2). Дня определения UDP служит диалог User – Defined Property Editor (вызывается из меню Edit\UDPs). В нем необходимо указать вид объекта, для которого заводится ЧОР (диаграмма в целом, сущность, атрибут и т. д.) и тип данных. Для внесения нового свой­ства следует щелкнуть в таблице по кнопке и внести имя, тип данных, значение по умолчанию и определение.

ER-winподдерживает для UDP шести типов данных:

• Date.Дата. Используется формат MM\DD\YY. Для выбора значения даты можноиспользовать контекстный календарь;
• Int. Целое число;
• Real. Действительное число;
• Text. Строка (АЗСП);
• List. Список. При задании списка в диалоге User – Defined Property Editor значения следует разделять запятой, значение по умолчанию выделяется символом " ~" (рис. 2.12);
• Command. Команда - выполняемая строка. На рис. 2.11 свойство Document имеет тип Command.

Рис. 2.12. Диалог User – Defined Property Editor

Значение свойств, определяемых пользователем, задастся в закладке UDP диалога Entity Editor. Если присвоить сущности значение свойства Document “D: \MSOffice97\Office\WINWORD.EXE part3.doc” (рис. 2.13), то из закладки можно редактировать документ part3 (кнопка в строке таб­лицы UDP).

Рис. 2.13. Закладка UDP диалога Entity Editor

Как было указано выше, каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом. Для описания атрибутов следует, “кликнув” правой кнопкой по сущности, выбрать в появившемся меню пункт Attribute Editor. Появляется диалог Attribute Editor (рис. 2.14).

Рис. 2.14. Диалог Attribute Editor

Если щелкнуть но кнопке New, то в появившемся диалоге New Attribute (рис. 2.15) можно указать имя атрибута, имя соответствующей ему в физи­ческой модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.

Рис. 2.15. Диалог New Attribute

Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо сделать пометку в окне выбора Primary Key.

Закладка Definition позволяет записывать определения отдельных атри­бутов. Определения атрибутов можно также сгенерировать как часть схемы (CREATE COMMENT on entity_name). Закладка Note позволяет добавлять замечания об одном или нескольких атрибутах сущности, которые не вошли в определения. Закладка UDP служит для задания значений свойств, определяемых пользователем. Предварительно эти свойств должны быть внесены в диалог User – Defined Property Editor как свойства атрибутов.

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

Для большей наглядности диаграммы каждый атрибут можно связать с иконкой. При помощи списка выбора Icon в закладке General можно свя­зать иконку с атрибутом.

Рис 2.16. Диалог ER-win Icon Editor

Каждому домену соответствует стандартная иконка, однако можно им­портировать и дополнительные изображения. Кнопка справа от списка выбора Icon вызывает диалог ER-win Icon Editor (рис. 2.16), щелкнув покнопке Import можно добавить в список необходимую иконку.

Рис. 2.17. Отображение сущности на уровне атрибутов с включенной опцией Attribute Icon

Для отображения иконки атрибута следует выбрать в контекстном ме­нюпункт Display Options\Entities и в каскадном меню включить опцию Attribute Icon.

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

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

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

(в другой сущности) будет назван Комментарий/2, затем Комментарий/3 и т. д.

Рис. 2.18. Диалог Unique Name Option

На практике такое переименование не всегда удобно, поэтому существу­ет возможность отменить эту опцию. В диалоге Unique Name Option (меню Option\Unique Name)

(рис. 2.18) можно задать следующие режимы имено­вания атрибутов:

• Allow - позволить внесение одинаковых имен;
• Rename - переименовывать атрибуты (по умолчанию);
• Ask - запрашивать возможные действия каждый раз при внесении одно­именных атрибутов. ER-win будет показывать на экране окно - диалог Edit Unique Name каждый раз, когда вводится неуникальное имя сущности или атрибута. В диалоге Edit Unique Name можно ввести другое имя или разрешить дублирование. При этом новое имя не проверяется на уни­кальность;
• Disallow - запретить внесение одинаковых имен. Если двойное имя об­наружено, то ER-win выдает на экран окно с сообщением, что ввод не­уникальных имен запрещается.

Каждый атрибут должен быть определен (закладка Definition), при этом следует избегать циклических определений, например когда термин 1 опре­деляется через термин 2, термин 2 - через термин 3, а термин 3 в свою оче­редь - через термин 1 (рис. 2.19).

Рис. 2.19. Циклическое определение атрибутов

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

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

При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag& drop, выбрав кнопку в палитре инструментов.

Связи

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

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

Рис. 2.20. Имя связи - Relationship Verb Phrases

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

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

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

В IDEF1X различают зависимые и независимые сущности. Тип сущно­сти определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифи­цирующая связь, ER-win автоматически преобразует дочернюю сущность в зависимую. Зависимая сущность изображается прямоугольником со скруг­ленными углами (сущность Заказ на рис. 2.21). Экземпляр зависимой сущ­ности определяется только через отношение к родительской сущности, т. е. в структуре на рис. 2.21 информация о заказе не может быть внесена и не имеет смысла без информации о клиенте, который его размещает. При ус­тановлении идентифицирующей связи атрибуты первичного ключа роди­тельской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущно­сти при создании связи называется миграцией атрибутов. В дочерней сущ­ности новые атрибуты помечаются как внешний ключ - (FK).

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

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

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

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

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

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

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

• установить курсор на нужной кнопке в палитре инструментов (идентифицирующая или неидентифицирующая связь) и нажать левую кнопку мыши (рис. 2.2);
• щелкнуть сначала по родительской, а затем по дочерней сущности. Форму линии связи можно изменить. Для этого нужно захватывать мы­тью нужную линию связи и переносить ее с места на место, пока линия не начнет выглядеть лучше.

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

Для редактирования свойств связи следует " кликнуть" правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor.

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

(рис. 2.23).

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

Различают четыре типа мощности (рис. 2.24):

• общий случай, когда одному экземпляру родительской сущности соот­ветствуют 0, 1 или много экземпляров дочерней сущности не помечает­ся каким-либо символом;
• символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
• символом 2 помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или I экземпляр дочерней сущности (исклю­чены множественные значения);
• цифрой помечается случай точного соответствия, когда одному экземп­ляру родительской сущности соответствует заранее заданное число эк­земпляров дочерней сущности.

Рис 2.23. Диалог Relationship Editor

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

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

Рис. 2.24. Обозначения мощности

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

Рис. 2.25. Закладка Roiename\RI Actions диалога Relationship Editor

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

В закладке Roiename\RI Actionsможно задать имя роли иправила ссы­лочной целостности.

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

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

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

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

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

Другим примером обязательностиприсвоения имен ролей являются ре­курсивные связи (иногда их называют " рыболовный крючок" – fish hook), тогда одна и та же сущность является и родительской и дочерней одновременно. При задании рекурсивной связи атрибут должен мигрировать в ка­честве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. На рис. 2.26 сущность Сотрудник содержит атрибут первичного ключа Табельный номер. Инфор­мация о руководителе сотрудника содержится в той же сущности, посколь­ку руководитель работает в той же организации. Чтобы сослаться на руко­водителя сотрудника следует создать рекурсивную связь (на рис. 2.26 связь руководит/подчиняется) и присвоить имя роли (" Руководитель"). Заметим, что рекурсивная связь может быть только неидентифицирующей. В про­тивном случае внешний ключ должен был бы войти в состав первичного ключа и получить при генерации схемы признак NOT NULL. Это сделало бы невозможным построение иерархии - у дерева подчиненности должен быть корень - сотрудник, который никому не подчиняется в рамках данной организации.

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

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

Другим видом рекурсии является сетевая рекурсия (network recursion),

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

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

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

Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более - только имя роли. На рис. 2.30 изображена структура данных, которая содержит сущность Команда, сущность Игрок, в которой хранится информация об игроках ка­ждой команды, и сущность Гол, содержащая информацию и голах, которые забивает каждый игрок. Атрибут внешнего ключа Номер команды сущность Игрок имеет имя роли " В какой команде играет".

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

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

Правила ссылочной целостности (referential integrity (RI)) - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. При генераций схемы БД на основе опций логической модели, задаваемых в закладке Rolename\RI Actions, будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи, и триггеры, обеспечивающие ссылочную целостность. Триггеры представляют собой программы, выполняемые всякий раз при выполнении команд встав­ки, замены или удаления (INSERT, UPDATE или DELETE). На рис. 2.30 существует идентифицирующая связь между сущностями Команда и Игрок. Что будет, если удалить команду? Экземпляр сущности Игрок не может существовать без команды (атрибут первичного ключа В какой команде иг­рает. Номер команды не может принимать значение NULL), следователь­но, нужно либо запретить удаление команды, пока в ней числится хотя бы один игрок (для удаления команды сначала нужно удалить всех игроков), либо сразу удалять вместе с командой всех ее игроков. Такие правила уда­ления называются " ограничение" и " каскад" (Parent RESTRICT и Parent CASCADE, см. рис. 2.25). Заметим, что сущности Игрок и Гол, в свою оче­редь, тоже связаны идентифицирующей связью и в случае удаления каска­дом команды будут удалены все игроки команды и вес голы, которые они забивали. Выполнение команды на удаление одной строки реально может привести к удалению тысячи строк в БД, поэтому использовать правило удаления каскадом следует с осторожностью. В том случае, если установле­но правило ограничения удаления, при попытке выполнить удаление ко­манды, в которой есть хотя бы один игрок, сервер реляционной СУБД воз­вратит ошибку.

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

Возможна установка еще двух правил удаления (если таковые поддерживаются СУБД):

SET DEFAULT - при удалении атрибуту внешнего ключа присваивается значение по умолчанию. Например, при удалении команды игроки могут быть переведены в другую команду.

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

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

• Задать мощность связимежду сущностями Командаи Игрок, равную “One or more” - I или более (тип Р). Предполагается, что установлена идентифицирующая связь.
• Присвоить действие RI-триггера " Parent Insert-CASCADE" для того, чтобы при создании новой строки в таблице Команда автоматический создавалась хотя бы одна строка в дочерней таблице Игрок.
• Присвоить связи действие RI-триггера " Parent Delete-CASCADE" для того, чтобы при удалении строки из таблицы Команда соответствующая строка или строки из таблицы Игрок тоже удалялись.

ER-win автоматически присваивает каждой связи значение ссылочной целостности, устанавливаемой по умолчанию, прежде чем добавить ее в диаграмму. Режимы RI, присваиваемые ER-win по умолчанию (приведены в табл. 2.4), могут быть изменены в редакторе Referential Integrity Default, который вызывается, если щелкнуть по кнопке RI Defaults диалога Target Server (меню Server\Target Server).

Таблица 2.4. Значения RI, присваиваемые в ER-win по умолчанию,