Проблема обеспечения целостности данных является одной из самых важных в реляционных базах данных. Тем не менее, несмотря на многолетние изучения в данной области, все еще не существует четкого определения этого понятия. Вообще под целостностью данных понимается представление данных в базе данных в правильном виде, который определяется ограничениями целостности, представляющими собой логические выражения, результат вычисления которых должен быть истинным [1].
Ограничения целостности являются ограничениями, накладываемыми на значения некоторого атрибута. Например, значение атрибута «возраст» не может быть отрицательным число или атрибут «пол» может принимать только два значения: «мужской» или «женский». На словах все это выглядит довольно просто, но в базе данных все устроено совсем не так.
Как было сказано выше, ограничение целостности является логическим выражением, параметры которого не определены, что делает ограничение целостности предикатом. Суть подобного предиката следующая — если некоторый кортеж относится к определенной переменной отношения, то для него должно выполняться заданное условие. Соответственно, проверить, выполняется ли указанное ограничение целостности можно только при подстановке вместо формального параметра предиката переменной отношения. Но когда именно и при каких условиях будет совершаться данная подстановка? Прежде, чем ответить на этот вопрос, необходимо разобраться с крайне важным правилом, касающемся ограничений целостности и называемым также золотым правилом.
Золото правило ограничений целостности гласит, что никакая операция обновления при ее выполнении не должна привести к тому, чтобы предикат этой базы данных получил ложное значение [1]. Это значит, что производить проверку ограничений целостности необходимо при выполнении любой операции обновления, которыми являются, например, вставка нового кортежа или изменение атрибута некоторого уже имеющегося в переменной отношения кортежа. Итак, с условием проверки ограничения целостности разобраться удалось, но когда же все-таки ее проводить?
Пусть есть некоторая переменная отношения со следующими атрибутами: «идентификационный номер», «имя» и «средний балл». Для этой переменной отношения имеется ограничение целостности, которое указывает, что значение атрибута «средний балл» должно находится в интервале от двух до пяти. В эту переменную отношения решают вставить новый кортеж, причем, со значением атрибута «средний балл» равным шести. Представим, что сначала выполняется вставка, а уже затем — проверка ограничения. В данном случае проверка окажется неудачной, так как значение предиката примет ложное значение, после чего произойдет отмена операции вставки. Но из-за подобной реализации были выполнены две ненужные операции: операция вставки и ее отмены. Правильным же является проведение проверки на ограничение целостности первой. Тогда бы в данном примере после проверки просто был бы получен отказ на выполнение операции. Значит, проверка ограничения целостности должна производиться перед выполнением любой операции обновления.
Отдельно необходимо рассмотреть вопрос с проверкой ограничений целостности в транзакциях. Как известно, транзакция является логической единицей работы, для выполнения которой необходимо выполнить несколько операций. Ранее считалось, что проверку ограничения целостности необходимо проводить по завершению транзакции, откатив изменения при неудачном варианте. Сейчас же считается, что для транзакций стандартные правила не меняются и проверка ограничения целостности также должна производиться перед выполнением любой операции обновления. Плюсом первого способа является меньшее число проверок, а минусом — необходимость откатывать все изменения при неудачной проверки по завершению транзакции. Минусом же второго способа, соответственно, является необходимость проверки каждой операции, но его плюсы перекрывают этот минус с лихвой: более высокая надежность (по завершению транзакции целостность может быть не нарушена, но она может быть нарушена во время ее выполнения) и возможность более быстрого отката изменений. Именно поэтому второй способ и является предпочтительнее первого, так как только он позволяет полностью выполнить все указанные ограничения целостности.
Нельзя не сказать про то, что ограничения целостности имеют свою четкую схему классификации ограничений, которая подразделяет их на четыре основные категории [1], а именно на:
1) Ограничения базы данных — это те ограничения, которые указывают, какие значения разрешено принимать некоторой базе данных. Подобные ограничения распространяются либо на несколько переменных отношения (не менее двух), либо на всю базу данных в целом. Обособленно среди ограничений базы данных выделяются ограничения перехода. Ограничения переходы указывают возможные переходы от одного значения переменной отношения к другому. Так, например, человек со статусом «школьник» может изменить его на статус «студент», но обратный переход от статуса «студент» к статусу «школьник» невозможен.
2) Ограничения переменной отношения — это те ограничения, которые указывают, какие значения разрешено принимать некоторой переменной отношения. Подобные ограничения распространяются только на одну переменную отношения. Считается, что ограничения переменной отношения являются частным случаем ограничений базы данных и что выделять их в отдельную категорию не нужно. Это мнение имеет право на существование, ведь, например, среди ограничений переменной отношения, как и среди ограничений базы данных, обособленно выделяются ограничения перехода.
3) Ограничения атрибута — это те ограничения, которые указывают, какие значения разрешено принимать некоторому атрибуту. Про эти ограничения уже шла речь выше. Ограничения атрибута является стандартными ограничениями, например, атрибут «возраст» не может быть отрицательным числом. Эти ограничения являются довольно простыми, и большинство ограничений относится именно к этой категории ограничений целостности.
4) Ограничения типа — это те ограничения, которые указывают, из каких значений состоит некоторый тип. То есть ограничение типа — это ни что иное, как задание множества значений некоторого типа. Например, если задать тип «пол» со значениями «женский» и «мужской», то ограничением типа будет являться то, что все значения типа «пол» могут либо равняться значению «женский», либо — значению «мужской».
Одними из самых важных ограничений в базах данных являются ограничения по ключам. Так первичный ключ должен быть уникальным в рамках каждого кортежа, а для внешних ключей должна также выполняться ссылочная целостность, суть которой заключается в том, что не может существовать такого значения внешнего ключа, которое не имеет первичный ключ. То есть, если, к примеру, первичный ключ имеет три значения («1», «2» и «3»), то значение внешнего ключа не может, например, равняться «4». Другими словами, можно сказать, что в базе данных должно поддерживаться условие, что если одно значение ссылается на другое, то это значение обязательно должно существовать без каких-либо дополнительных оговорок.
В заключение хотелось бы еще раз отметить, что пробела целостности данных в базах данных является очень важной, ведь только при выполнении всех ограничений целостности (проверка выполнения которых производится перед проведением любой операции обновления) база данных будет содержать в наибольшей степени правильные значения.
Литература:
- Дейт, К.Дж. Введение в системы баз данных, 8-е издание: Пер. с англ. / К.Дж. Дейт. — М.: Издательский дом «Вильямс», 2008. — 1328 с.: ил. — Парал. тит. англ.
