1) Доменная целостность

При задании типа данных определяются правильные значения для отдельно взятого столбца. Это называется доменной целостностью. Домен - это множество допустимых значений столбца. В качестве альтернативного метода определения допустимых значений используется свойство NULL, указывающее для данного столбца тип значений. Традиционные для SQL Server методы обеспечения целостности включают в себя наложение условий на домены столбцов с помощью пользовательских типов данных, правил и значений по умолчанию. Для обеспечения целостности также используются ограничения ANSI (значения по умолчанию и ограничения на проверку). Обратите внимание на то, что типы данных и свойство NULL используются всегда, в то время как другие компоненты системы целостности данных применять необязательно.

2) Ссылочная целостность

Ссылочная целостность состоит в, поддержке определенных отношений между строками данных в разных таблицах. Этот тип целостности обеспечивается главным образом декларативными средствами. Следует отметить, что те же условия на данные налагаются с помощью триггеров и других программных средств, однако при этом требуется ручное выполнение многих операций. В SQL Server 2000 для внешних ключей определено два вида каскадных операций: каскадное удаление (новое средство в SQL Server 2000) и запрет операции. Последнее означает, что если попытаться удалить запись о клиенте, для которого заданы использующиеся счета (то есть, в другой таблице есть записи о его счетах), то сервер не выполнит это действие. Если установлена опция каскадного удаления, то при запросе на удаление клиента сервер также удалит из связанных таблиц все записи о его счетах. В предыдущих версиях SQL Server для выполнения каскадного удаления нужно было .запрограммировать соответствующие действия вручную, с помощью триггеров, хранимых процедур или стандартных операторов T-SQL. Появление в SQL Server 2000 декларативных средств каскадного удаления избавляет' разработчика базы данных от большого объема ручной работы.

3) Объектная целостность

Последний тип целостности, рассматриваемый в этом уроке, - объектная целостность. Она определяет возможность добавления уникального идентификатора для каждой строки таблицы. Объектная целостность обеспечивается с помощью уникальных индексов (рассмотрены в прошлом уроке) и средствами декларативной целостности (первичный ключ или ограничение уникальности), которые рассмотрены ниже.

Null-значения

Основное назначение баз данных состоит в том, чтобы хранить и предоставлять информацию о реальном мире. Для представления этой информации в базе данных используются привычные для программистов типы данных - строковые, численные, логические и т.п. Однако в реальном мире часто встречается ситуация, когда данные неизвестны или не полны. Например, место жительства или дата рождения человека могут быть неизвестны (база данных разыскиваемых преступников). Если вместо неизвестного адреса уместно было бы вводить пустую строку, то что вводить вместо неизвестной даты? Ответ - пустую дату - не вполне удовлетворителен, т.к. простейший запрос "выдать список людей в порядке возрастания дат рождения" даст заведомо неправильных ответ.

Для того чтобы обойти проблему неполных или неизвестных данных, в базах данных могут использоваться типы данных, пополненные так называемым null-значением. Null-значение - это, собственно, не значение, а некий маркер, показывающий, что значение неизвестно.

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

Первый вариант состоит в том, чтобы ограничиться использованием обычных типов данных и не использовать null-значения, а вместо неизвестных данных вводить либо нулевые значения, либо значения специального вида - например, договориться, что строка "АДРЕС НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить вместо неизвестного адреса. В любом случае на пользователя (или на разработчика) ложится ответственность на правильную трактовку таких данных. В частности, может потребоваться написание специального программного кода, который в нужных случаях "вылавливал" бы такие данные. Проблемы, возникающие при этом очевидны - не все данные становятся равноправны, требуется дополнительный программный код, "отслеживающий" эту неравноправность, в результате чего усложняется разработка и сопровождение приложений.

Второй вариант состоит в использовании null-значений вместо неизвестных данных. За кажущейся естественностью такого подхода скрываются менее очевидные и более глубокие проблемы. Наиболее бросающейся в глаза проблемой является необходимость использования трехзначной логики при оперировании с данными, которые могут содержать null-значения. В этом случае при неаккуратном формулировании запросов, даже самые естественные запросы могут давать неправильные ответы. Есть более фундаментальные проблемы, связанные с теоретическим обоснованием корректности введения null-значений, например, непонятно вообще, входят ли null-значения в домены или нет.

Практически все реализации современных реляционных СУБД позволяют использовать null-значения, несмотря на их недостаточную теоретическую обоснованность. Такую ситуацию можно сравнить с ситуацией, сложившейся в начале века с теорией множеств. Почти сразу после создания Кантором теории множеств, в ней были обнаружены внутренние противоречия (антиномии). Были разработаны более строгие теории, позволяющие избежать этих противоречий (конструктивная теория множеств). Однако в реальной работе большинство математиков пользуется классической теорией множеств, т.к. более строгие теории более ограничены и негибки в применении именно в силу своей большей строгости.

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

29. Целостность данных. Первичный ключ, ограничения по связям. Внешний ключ. Бизнес правила.

Целостность (от англ. integrity - нетронутость, неприкосновенность, сохранность, целостность) - понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).