На этапе логического проектирования необходимо описать все ограничения целостности, обусловленные предметной областью. Типы ограничений целостности и ключевые слова SQL, которые позволяют описывать эти ограничения, приведены в п.6.1.
Если какое-либо ограничение целостности может быть включено в структуру БД (на языке DCL), то его надо реализовать именно так. |
СУБД проверяет выполнение ограничений целостности при каждой операции модификации данных, если эта операция может нарушить целостность данных. Если ограничения целостности включены в схему БД, они проверяются автоматически и нельзя внести в базу ошибочные данные. Если же перенести проверку ограничений целостности в программу, то гарантировать их соблюдение нельзя. Программа, во-первых, может содержать ошибки, во-вторых, её можно "обойти", обратившись к БД напрямую с помощью команд языка DML.
Необходимо обратить особое внимание на поля таблиц, для которых домен определён как список возможных значений. Это ограничение целостности можно реализовать в виде: CHECK(<поле> IN (<список значений>)). Но такой подход имеет следующий недостаток: добавление нового значения в список потребует изменения схемы отношения (команда ALTER TABLE). Можно поступить до-другому: вынести этот список значений в отдельное от-ношение. Например, список типов образования (начальное, неполное среднее, среднее, средне-специальное, незаконченное высшее, высшее) для таблицы СОТРУДНИКИ. Таблица ТИПЫ ОБРАЗОВАНИЯ будет состоять из одного поля Название типа, определённого как первичный ключ. Тогда поле Образование таблицы СОТРУДНИКИ станет внешним ключом.
|
|
Определение списка значений позволяет гарантировать правильность вводимых данных и правильность поиска. Если не ограничивать значения поля, то оператор может ввести данные произвольным образом, например: 'незаконченное высшее', 'незаконч. высшее', 'н. высш.' и т.д. Человек понимает, что это одно и то же, а для СУБД это разные значения, и учесть все возможные комбинации в условии поиска очень сложно.
Если какое-либо ограничение целостности (ОЦ) нельзя реализовать средствами DCL, то возможны следующие способы его реализации:
- С помощью процедурных объектов БД. Чаще всего для этой цели используются триггеры (trigger). Триггер – это процедура БД, которая привязана к конкретной таблице и вызывается автоматически при наступлении определённого события (добавления, удаления или модификации данных этой таблицы). Процедура триггера пишется на том языке, который поддерживается выбранной СУБД (например, PL/SQL для Oracle, Visual Basic для MS SQL Server). Триггер пишется программистом и выполняет те действия, которые обусловлены предметной областью. Например, триггер может осуществлять проверку "возраст принимаемого на работу сотрудника не может быть менее 16-и лет" или присваивать полю "Дата заказа" текущую дату при добавлении нового заказа. Если триггер диагностирует нарушение ограничений целостности, он выдаст сообщение об ошибке и команда модификации данных не будет выполнена (произойдёт автоматический откат, rollback).
- Программно (т.е. через приложение). Для большей гарантии соблюдения ОЦ желательно проектировать программу так, чтобы внесение изменений в данные и проверка ОЦ выполнялись в одном единственном месте.
- Вручную. Ручная процедура обязательно должна быть описана в документации (в руководстве пользователя).
|
|