Диго С.М. Базы данных проектирование и использование (1084447), страница 33
Текст из файла (страница 33)
Работоспособность программы может нарушиться не только при изменении структуры БД, но и при перемещении тех или иных файлов, используемых ею, в другую директорию. Это также необходимо учитывать при проектировании ИС.
Задание ограничений целостности и их проверка - важная часть проектирования и функционирования банков данных. Ограничения целостности, присущие той или иной предметной области, должны быть выявлены при обследовании и зафиксированы в инфологической модели. Вопрос о необходимости проверки ограничений целостности при функционировании БнД должен решаться на основе анализа эффективности проекта, так как в некоторых случаях для ее реализации требуются значительные затраты ресурсов.
Ограничения целостности в банках данных могут задаваться либо при описании баз данных (декларативный способ задания), либо в программах обработки данных (процедурный способ задания). Первый подход более предпочтителен, и не только потому, что при декларативном способе задания используется более высокий уровень языковых средств, но и потому, что один раз заданные ограничения будут контролироваться при выполнении всех операций над данными.
Разные СУБД обладают различным набором средств для обеспечения целостности данных. При проектировании БнД необходимо изучить, какие возможности по контролю целостности предоставляет используемая СУБД. Если СУБД автоматически не поддерживает то или иное нужное ограничение, то обеспечение его соблюдения становится заботой пользователя (проектировщика).
В СУБД семейства xBASE основная масса ограничений целостности должна была быть определена на ЯМД, так как в ЯОД практически отсутствовали средства определения ограничений целостности данных. Часть ограничений целостности можно было задавать при создании экранных форм.
В современных СУБД многие ограничения можно описать на ЯОД. Они хранятся в схеме данных и при работе с БД поддерживаются автоматически.
Для контроля целостности БД применяется также механизм триггеров. Триггер - это действие, которое активизируется при наступлении указанного события (вставки, удаления, обновления записи). Триггеры специфицируются в схеме базы данных.
Более широким понятием по отношению к триггеру является понятие хранимая процедура. Хранимые процедуры описывают фрагменты логики приложения, хранятся и исполняются на сервере, что позволяет улучшать характеристики производительности.
4.2. ER-модели и ограничения целостности
Некоторые ограничения целостности видны из описания предметной области в виде ER-модели.
1. Ограничение на уникальность - уникальные идентификаторы объектов являются ключами таблиц, соответствующих этим объектам. Если идентификаторов несколько, то для СУБД, поддерживающих концепцию ключа, нужно определить первичный ключ (Primary Key) и вероятные ключи (Alternate Key, Unique).
2. Между уникальным идентификатором объекта и полями, соответствующими единичным свойствам объекта, существует функциональная зависимость.
3. Если объекты связаны между собой, то соответствующие таблицы БД могут иметь ограничение целостности по связи.
Тип связи между объектами (1:1, 1:М, М:М) определяет, что будет первичным, а что - внешним ключом в этих связях. Если отношение между объектами 1:М, то очевидно, что первичным будет ключ основной таблицы (объект, который стоит со стороны единичной связи), внешним - соответствующее ему поле в таблице, отображающей объект, стоящий на стороне множественной связи.
В случае, если связь 1:1, объекты относительно связи являются равноправными, и для определения, какой из файлов БД будет играть ведущую роль, необходимо рассматривать дополнительные характеристики. Например, если класс членства с одной стороны связи необязательный, а с другой - обязательный, то идентификатор объекта, имеющего необязательный класс членства, помещается в таблицу, соответствующую объекту с обязательным классом членства, и именно он будет внешним ключом.
При наличии связи М:М в базу данных вводится дополнительная связующая таблица. Между ней и таблицами, соответствующими исходным объектам, существуют ограничения целостности по связи. Внешними ключами будут идентификаторы связанных объектов, помещенные в связующей таблице.
4. Если при наличии связи типа 1:М класс членства в связи - необязательный для объектов, стоящих со стороны множественной связи, то могут быть «пустые» значения внешнего ключа. В противном случае они должны иметь ограничение целостности «NON NULL».
5. Класс членства объектов в связи оказывает влияние не только на выбор варианта построения логической структуры, но и на задание ограничений целостности. Причем ограничение целостности будет определяться как классом членства, так и выбранным вариантом отображения этой связи в БД. Так, если объекты связаны отношением 1:М, класс принадлежности n-связной сущности является необязательным и для отображения связи создается третье отношение, которое содержит ключи каждой из связанных сущностей, то между связующим файлом и основными файлами будет ограничение целостности по связи, а значения каждого из полей связующего файла не должны быть пустыми. Если же дополнительная таблица не создается, то значение поля связи, включенного в таблицу, соответствующую объекту, стоящему со стороны множественной связи, либо должно совпадать с одним из значений ключевого поля связанного объекта, либо может быть пустым. Если класс членства обязательный, то поле связи не может иметь пустого значения.
6. При наличии связи 1:1 следует проверять количество элементов в связи.
7. Для статических свойств объектов можно предусматривать запрет на обновление.
8. Если свойство - условное, то соответствующий атрибут может иметь пустые значения.
4.3. Задание ограничений целостности в ERWin
При построении ER-модели в ERWin можно задавать ограничения целостности.
4.3.1. Обязательный атрибут
Для атрибута можно задавать свойство «Required» (обязательный). Для тех атрибутов, которые выбраны в качестве первичного ключа, это свойство является неактивным, поскольку свойство обязательности и так (по определению ключа) присуще элементам ключа. Свойство «Required» следует задать для атрибутов «Фамилия», «Имя», «Отчество» объекта СОТРУДНИК, «Наименование предмета полное» объекта ПРЕДМЕТ и некоторых других атрибутов. Задание этого свойства будет означать, что при вводе данных в БД недопустимо пустое значение соответствующего поля.
4.3.2. Ограничения целостности связи
При описании связи можно задать ограничения целостности связи. Для этого следует воспользоваться вкладкой RI Actions (рис. 4.3) в окне редактора связей (Relationship Editor). В этой секции для каждой связи можно задать действия, которые будут выполняться при удалении (Delete), вставке (Insert) и обновлении (Update) как порожденной (Child), так и родительской (Parent) сущности.
Рис. 4.З. Описание целостности связи в ERWin
Для каждой корректирующей операции можно выбрать действие, которое представлено в ниспадающих списках. Каждый список имеет четыре возможных значения: NONE (никакой), RESTRICT (ограничивать),
CASCADE (каскад), SET DEFAULT (значение по умолчанию).
На рис. 4.3 показаны значения RI Actions, задаваемые по умолчанию. В рассматриваемом примере для операции Parent Delete следует выбрать действие CASCADE. Если «Код_сотрудника» может изменяться, то для операции Parent Update также следует выбрать действие CASCADE.
Так как связь «многие ко многим» в реляционной модели не поддерживается, то на уровне логической модели нет смысла (и, как следствие, нет возможности) задавать действия при корректировке сущностей, связанных таким типом связи. При необходимости можно перейти к уровню физической модели и скорректировать ограничения связи для связей, появляющихся в физической модели взамен связи «многие ко многим».
Естественно, что выбор режима действий при выполнении корректирующих операций будет зависеть от типа связи между сущностями. В табл. 4.1 приведены возможные режимы для каждого вида связи. Значения по умолчанию выделены полужирным курсивом с подчеркиванием.
Таблица 4.1
| Действие | Идентифицирующая связь | Неидентифици-рующая связь (Nulls Allowed) | Неидентифици- рующая связь (No Nulls) | Категориальная связь |
| Child Delete | NONE, RESTRICT, CASCADE | NONE, RESTRICT, CASCADE, SET DEFAULT, SET Null | NONE, RESTRICT, CASCADE, SET DEFAULT | NONE, RESTRICT, CASCADE |
| Child Insert | NONE, RESTRICT, CASCADE | NONE, RESTRICT, CASCADE, SET DEFAULT, SET Null | NONE, RESTRICT, CASCADE, SET DEFAULT | NONE, RESTRICT, CASCADE |
| Child Update | NONE, RESTRICT, CASCADE | NONE, RESTRICT, CASCADE, SET DEFAULT, SET Null | NONE, RESTRICT, CASCADE, SET DEFAULT | NONE, RESTRICT, CASCADE |
| Parent Delete | NONE, RESTRICT, CASCADE, | NONE, RESTRICT, CASCADE, SET DEFAULT, SET Null | NONE, RESTRICT CASCADE, SET DEFAULT | NONE, RESTRICT, CASCADE |
Продолжение таблицы 4.1
| Parent Insert | NONE, RESTRICT, CASCADE | NONE, RESTRICT, CASCADE, SET DEFAULT, SET Null | NONE, RESTRICT, CASCADE, SET DEFAULT | NONE, RESTRICT, CASCADE |
| Parent Update | NONE, RESTRICT, CASCADE | NONE, RESTRICT, CASCADE, SET DEFAULT, SET Null | NONE, RESTRICT, CASCADE, SET DEFAULT | NONE, RESTRICT, CASCADE |
Значения ограничений означают следующее:
-
NONE - действие не оказывает влияния на связанные записи;
-
RESTRICT - действие запрещено (при определенных условиях);
-
CASCADE - действие вызывает изменения в связанных записях;
-
SET DEFAULT - устанавливается значение по умолчанию для поля связи;
-
SET Null - устанавливается по умолчанию значение Null для поля связи.
Обычно удаление зависимой записи (Child Delete) при любом типе связи не требует дополнительных проверок на допустимость корректировки и не приводит к каким-либо изменениям в связанных записях. Поэтому режимом по умолчанию для всех типов связи является NONE. Дополнительная проверка может потребоваться, если в предметной области невозможно существование главного объекта без связанных с ним подчиненных объектов. Например, не может быть ОТДЕЛА без СОТРУДНИКОВ. В этом случае либо не должна быть допущена попытка удаления последнего сотрудника из отдела, либо при этом должен быть удален отдел.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
