Описание ограничений целостности

На этапе логического проектирования необходимо описать все ограничения целостности, обусловленные предметной областью. Типы ограничений целостности и ключевые слова SQL, которые позволяют описывать эти ограничения, приведены в п.6.1.

Если какое-либо ограничение целостности может быть включено в структуру БД (на языке DCL), то его надо реализовать именно так.

СУБД проверяет выполнение ограничений целостности при каждой операции модификации данных, если эта операция может нарушить целостность данных. Если ограничения целостности включены в схему БД, они проверяются автоматически и нельзя внести в базу ошибочные данные. Если же перенести проверку ограничений целостности в программу, то гарантировать их соблюдение нельзя. Программа, во-первых, может содержать ошибки, во-вторых, её можно "обойти", обратившись к БД напрямую с помощью команд языка DML.

Необходимо обратить особое внимание на поля таблиц, для которых домен определён как список возможных значений. Это ограничение целостности можно реализовать в виде: CHECK(<поле> IN (<список значений>)). Но такой подход имеет следующий недостаток: добавление нового значения в список потребует изменения схемы отношения (команда ALTER TABLE). Можно поступить до-другому: вынести этот список значений в отдельное от-ношение. Например, список типов образования (начальное, неполное среднее, среднее, средне-специальное, незаконченное высшее, высшее) для таблицы СОТРУДНИКИ. Таблица ТИПЫ ОБРАЗОВАНИЯ будет состоять из одного поля Название типа, определённого как первичный ключ. Тогда поле Образование таблицы СОТРУДНИКИ станет внешним ключом.

Определение списка значений позволяет гарантировать правильность вводимых данных и правильность поиска. Если не ограничивать значения поля, то оператор может ввести данные произвольным образом, например: 'незаконченное высшее', 'незаконч. высшее', 'н. высш.' и т.д. Человек понимает, что это одно и то же, а для СУБД это разные значения, и учесть все возможные комбинации в условии поиска очень сложно.

Если какое-либо ограничение целостности (ОЦ) нельзя реализовать средствами DCL, то возможны следующие способы его реализации:

1. С помощью процедурных объектов БД. Чаще всего для этой цели используются триггеры (trigger). Триггер – это процедура БД, которая привязана к конкретной таблице и вызывается автоматически при наступлении определённого события (добавления, удаления или модификации данных этой таблицы). Процедура триггера пишется на том языке, который поддерживается выбранной СУБД (например, PL/SQL для Oracle, Visual Basic для MS SQL Server). Триггер пишется программистом и выполняет те действия, которые обусловлены предметной областью. Например, триггер может осуществлять проверку "возраст принимаемого на работу сотрудника не может быть менее 16-и лет" или присваивать полю "Дата заказа" текущую дату при добавлении нового заказа. Если триггер диагностирует нарушение ограничений целостности, он выдаст сообщение об ошибке и команда модификации данных не будет выполнена (произойдёт автоматический откат, rollback).
2. Программно (т.е. через приложение). Для большей гарантии соблюдения ОЦ желательно проектировать программу так, чтобы внесение изменений в данные и проверка ОЦ выполнялись в одном единственном месте.
3. Вручную. Ручная процедура обязательно должна быть описана в документации (в руководстве пользователя).

Аномалии модификации данных

После составления концептуальной (логической) схемы БД необходимо проверить её на отсутствие аномалий модификации данных. Дело в том, что при неправильно спроектированной схеме БД могут возникнуть аномалии выполнения операций модификации данных. Эти аномалии обусловлены ограниченностью структуры РМД (отсутствием агрегатов и проч.).

Рассмотрим эти аномалии на примере отношения со следующими атрибутами (атрибуты, входящие в ключ, выделены подчёркиванием):

ПОСТАВКИ (Номер поставки, Название товара, Цена товара, Количество, Дата поставки, Название поставщика, Адрес поставщика)

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

1. Аномалия обновления: в отношении ПОСТАВКИ она может возникнуть, если у какого-либо поставщика изменился адрес. Изменения должны быть внесены во все кортежи, соответствующие поставкам этого поставщика; в противном случае данные будут противоречивы.
2. Аномалия удаления: при удалении записей обо всех поставках определённого поставщика все данные об этом поставщике будут утеряны.
4. Аномалия добавления: в нашем примере она возникнет, если с поставщиком заключен договор, но поставок от него ещё не было. Сведения о таком поставщике нельзя внести в таблицу ПОСТАВКИ, т.к. для него не определён ключ (номер поставки и название товара) и другие обязательные атрибуты.

Для решения проблемы аномалии модификации данных при проектировании реляционной БД проводится нормализация отношений.