Поддержка
целостности в реляционной модели данных в ее классическом понимании включает
в себя 3 аспекта.
Во-первых,
это поддержка структурной целостности, которая трактуется как то, что
реляционная СУБД должна допускать работу только с однородными структурами данных
типа «реляционное отношение». При этом понятие «реляционного
отношения» должно удовлетворять всем ограничениям, накладываемым на него
в классической теории реляционной БД (отсутствие дубликатов кортежей, соответственно
обязательное наличие первичного ключа, отсутствие понятия упорядоченности кортежей).
В дополнение
к структурной целостности необходимо рассмотреть проблему неопределенных Null
значений. Как уже указывалось раньше, неопределенное значение интерпретируется
в реляционной модели как значение, неизвестное на данный момент времени. Это
значение при появлении дополнительной информации в любой момент времени может
быть заменено на некоторое конкретное значение. При сравнении неопределенных
значений не действуют стандартные правила сравнения: одно неопределенное значение
никогда не считается равным другому неопределенному значению. Для выявления
равенства значения некоторого атрибута неопределенному применяют специальные
стандартные предикаты:
<имя атрибута>IS
NULL и <имя атрибута> IS NOT NULL.
Если в данном
кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то
предикат IS NULL принимает значение TRUE (Истина), а предикат IS NOT NULL —
FALSE (Ложь), в противном случае предикат IS NULL принимает значение FALSE,
а предикат IS NOT NULL принимает значение TRUE.
Ведение Null
значений вызвало необходимость модификации классической двузначной логики и
превращения ее в трехзначную. Все логические операции, производимые с неопределенными
значениями, подчиняются этой логике в соответствии с заданной таблицей истинности.
Таблица
8.1. Таблица истинности для логических операций с неопределенными
значениями ,
А |
В |
Not A |
A&B |
A V В |
||
TRUE |
TRUE |
FA |
TRUE |
TRUE |
||
TRUE |
FALSE |
FALSE |
FALSE |
TRUE |
||
А |
B |
Not A |
A&B |
A V В |
||
TRUE |
Null |
FALSE |
Null |
TRUE |
||
FALSE |
TRUE |
TRUE |
FALSE |
TRUE |
||
FALSE |
FALSE |
TRUE |
FALSE |
FALSE |
||
FALSE |
Null |
TRUE |
FALSE |
Null |
||
Null |
TRUE |
Null |
Null |
TRUE |
||
Null |
FALSE |
Null |
FALSE |
Null |
||
Null |
Null |
Null |
Null |
Null |
||
В стандарте
SQL2 появилась возможность сравнивать не только конкретные значения атрибутов
с неопределенным значением, но и результаты логических выражений сравнивать
с неопределенным значением, для этого введена специальная логическая константа
UNKNOWN. В этом случае операция сравнения выглядит как:
Логическое выражение>
IS {TRUE | FALSE | UNKNOWN}
Во-вторых,
это поддержка языковой целостности, которая состоит в том, что реляционная
СУБД должна обеспечивать языки описания и манипулирования данными не ниже стандарта
SQL. He должны быть доступны иные низкоуровневые средства манипулирования данными,
не соответствующие стандарту.
Именно поэтому
доступ к информации, хранимой в базе данных, и любые изменения этой информации
могут быть выполнены только с использованием операторов языка SQL.
В-третьих,
это поддержка ссылочной целостности (Declarative Referential Integrity,
DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами
кортежей взаимосвязанных отношений:
Ссылочная
целостность обеспечивает поддержку непротиворечивого состояния БД в процессе
модификации данных при выполнении операций добавления или удаления.
Кроме указанных
ограничений целостности, которые в общем виде не определяют семантику БД, вводится
понятие семантической поддержки целостности.
Структурная,
языковая и ссылочная целостность определяют правила работы СУБД с реляционными
структурами данных. Требования поддержки этих трех видов целостности говорят
о том, что каждая СУБД должна уметь это делать, а разработчики должны это учитывать
при построении баз данных с использованием реляционной модели. И эти требования
поддержки целостности достаточно абстрактны, они определяют допустимую форму
представления и обработки информации в реляционных базах данных. Но с другой
стороны, эти аспекты никак
не касаются содержания базы данных. Для определения некоторых ограничений, которые
связаны с содержанием базы данных, требуются другие методы. Именно эти методы
и сведены в поддержку семантической целостности. Давайте рассмотрим конкретный
пример. То, что мы можем построить схему базы данных или ее концептуальную модель
только из совокупности нормализованных таблиц, определяет структурную целостность.
И мы построили нашу схему библиотеки из пяти взаимосвязанных отношений. Но мы
не можем с помощью перечисленных трех методов поддержки целостности обеспечить
ряд правил, которые определены в нашей предметной области и должны в ней соблюдаться.
К таким правилам могут быть отнесены следующие:
Принципы
семантической поддержки целостности как раз и позволяют обеспечить автоматическое
выполнение тех условий, которые перечислены ранее.
Семантическая
поддержка может быть обеспечена двумя путями: декларативным и процедурным путем.
Декларативный путь связан с наличием механизмов в рамках СУБД, обеспечивающих
проверку и выполнение ряда декларативно заданных правил-ограничений, называемых
чаще всего «бизнес-правилами» (Business Rules) или декларативными
ограничениями целостности.
Выделяются
следующие виды декларативных ограничений целостности:
Задание значения по
умолчанию означает, что каждый раз при вводе новой строки в отношение, при
отсутствии данных в указанном столбце этому атрибуту присваивается именно
значение по умолчанию. Например, при вводе новых книг разумно в качестве
значения по умолчанию для года издания задать значение текущего года. Например,
для MS Access 97 это выражение будет иметь вид:
YEAR(NOW())
Здесь NOW() — функция,
возвращающая значение текущей даты, YEAR(data) — функция, возвращающая значение
года указанной в качестве параметра даты.
В качестве условия
на значение для года издания надо задать выражение, которое будет истинным
только тогда, когда год издания будет лежать в пределах от 1960 года до
текущего года. В конкретных СУБД это значение будет формироваться с использованием
специальных встроенных функций СУБД.
Для MS Access 97 это
выражение будет выглядеть следующим образом:
Between 1960 AND YEAR(NOW())
В СУБД MS SQL Server7.0
значение по умолчанию записывается в качестве «бизнес-правила».
В этом случае будет использоваться выражение, в котором явным образом должно
быть указано имя соответствующего столбца, например:
YEAR_PUBL >= 1960
AND YEAR_PUBL <- YEAR(GETDATE())
Здесь GETDATE() —
функция MS SQL Server7.0, возвращающая значение текущей даты, YEAR_PUBL
— имя столбца, соответствующего году издания.
Да, это действительно
легче, тем более что в процессе работы схема базы данных разрастается и
начинает содержать более сотни отношений, и задача нетривиальная — найти
все отношения, в которых ранее установлено это ограничение и исправить его.
Одним из основных
правил при разработке проекта базы данных, как мы уже упоминали раньше,
является минимизация избыточности, а это означает, что если возможно информацию
о чем-то, в том числе и об ограничениях, хранить в одном месте, то это надо
делать обязательно.
HOME_PHON IS NOT NULL
OR WORK_PHON IS NOT NULL
Декларативные
ограничения целостности относятся к ограничениям, которые являются немедленно
проверяемыми. Есть ограничения целостности, которые являются откладываемыми.
Эти ограничения целостности поддерживаются механизмом транзакций и триггеров.
Мы их рассмотрим в следующих Лекциях.