Моделирование БД. Нарушение целостности

С точки зрения логики, любое преобразование БД должно переводить одно состояние БД в другое (декомпозиция). Любое преобразование должно сохранять это отношение (декомпозицию). (То есть таблица®таблица).

В реляционных БД в реальности модификация понимается как модификация таблиц. Декларативные реляционные языки содержат команды, выполняющие именно такие преобразования (SQL).

Таблицы состоят из записей. Можно понимать преобразование таблиц как реализацию некоторых алгоритмов обработки записей. Такой подход характерен для процедурно-реляционных языков (xBase, dBase, FoxPro). Эти языки ближе к реализации, здесь таблица есть файл, то есть последовательность реализации.

В любом случае реализация преобразований допускает некорректное состояние. Разумеется, что проблема неспецифична для СУБД. Но именно здесь она приобретает наибольшую остроту – СУБД изначально ориентированы на хранение данных; их корректность имеет наивысший приоритет.

Переход базы в некорректное, с точки зрения логики, состояние называется нарушением её целостности (база содержит неправильные данные). Такие нарушения могут происходить по нескольким причинам: нарушение уровня поля - неточное описание доменов – области допустимых, с точки зрения логики, значений полей.

Пример. Описать в терминах БД понятие «прямоугольник».

RÌD² – множество всех точек.

x, y

x³x₁ & x£x₂

y³y₁ & y£y₂

Соответственно таблица с заданными полями x, y – вещественных чисел. Такое определение допускает появление в базе некорректных точек (не входящих в прямоугольник). Проблема решается указанием не только типа, но и условия назначения поля. Вторая проблема: нарушение уровня записи. Может оказаться, что домен каждого из полей описан точно, но значение записи в целом некорректно.

Пример. Описать круг в терминах БД

RÌD²

Даже если описать точно домены каждого из полей, остаётся возможность попадания в БД некорректных записей. Точно описать соответствующее отношение как предикат. В терминах СУБД такие предикаты уровней поля и уровней записи называются правилами допустимости.

Классификация допустимости преобразований «уровня отношений» (уровня БД) практически не существует, что, очевидно, вызвано тем, что в реляционных БД отношения имеют, в физическом смысле, мнимый характер. Есть отношения допустимости преобразований как сохраняющих отношения ключей – ссылочная целостность (referential integrity). Преобразования не сохраняют ссылочною целостность, если оставляют сирот, то есть записи дочерних таблиц, содержащих ссылку на несуществующее значение ключа материнской таблицы. Среди преобразований, сохраняющих ссылочную целостность, выделяются каскадные (cascades) – модификация родительских таблиц продолжается на дочерние записи. Например, каскадное удаление – удаление родительской записи влечёт удаление всех дочерних – каскадное изменение ключа. Нулевое изменение (nulls) – изменение родительской записи с изменением внешнего ключа дочерних на значение null. Например, нулевое удаление – удаление родительской записи влечёт установку внешнего ключа дочерней со значением «ноль». Ограниченное (restricted) изменение родительской записи возможно лишь в случае, когда дочерние записи не существуют. В противном случае оно запрещено. Например, ограниченное удаление – удаляются только родительские записи, у которых нет дочерних.

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