Термин целостность данных относится к правильности и полноте информации содержащейся в базе данных. При изменении содержимого базы данных с помощью инструкций insert, delete или update может произойти нарущение целостности содержащихся в ней данных. Например:

в базу могут быть внесены неправильные данные, скажем, заказ, в котором указан несуществующий товар;

в результате изменения имеющихся данных им могут быть присвоены некорректные значения, пример - назначение служащего в несуществующий офис;

при внесении изменений в базу данных они могут быть утеряны из-за системной ошибки или сбоя в электропитании;

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

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

Условия целостности данных

Для сохранения непротиворечивости и правильности хранимой информации в реляционных СУБД устанавливается одно или несколько условий целостности данных. Эти условия определяют, какие значения могут быть записаны в базу данных в результате добавления или обновления данных. Как правило, в реляционной базе дащвых можно использовать следующие условия целостности данных:

Обязательное наличие данных. Некоторые столбцы в базе данных должны содержать значения в каждой строке; строки в таких столбцах не могут содержать значения null или не содержать никакого значения. Например, в учебной базе данных для каждого заказа должен существовать соответствующий клиент, сделавший этот заказ. Поэтому столбец cusT в таблице orders является обязательным. Можно указать СУБД, что запись значения null в такие столбцы недопустима.

Условие на значение. У каждого столбца в базе данных есть свой домен, т.е. набор значений, которые допускается хранить в данном сюлбце. В учебной базе данных заказы нумеруются, начиная с числа 10000L поэтому доменом столбца order num являются положительные целые числа, большие 100000 Аналогично, идентификаторы служащих в столбце empl num должны находиться в диапазоне от 101 до 999 Можно указать СУБД, что запись значений, не входящих в определенный диапазон, в такие столбцы недопустима.

Целостность таблицы. Первичный ключ таблицы должен в каждой строке иметь уникальное значение, отличное от значений во всех остальных строках. Например, каждая строка таблицы products имеет уникальную комбинацию значений в столбцах mfr id и product id, которая однозначно идентифицирует товар, представляемый данной строкой Повторяющиеся значения в этих столбцах недопустимы, поскольку тогда база данных не сможет отличить один товар от другого. Можно указать СУБД, чтобы она обеспечивала целостность таблиц.

Ссылочная целостность. В реляционной базе данных каждая строка таблицы-потоМ-ка с помощью внешнего ключа связана со строкой таблицы-предка, содержащей

первичный ключ, значение которого равно значению внешнего ключа. В учебной базе данных значение столбца rep office таблицы salesreps связывает служащего с офисом, в котором он работает. Столбец rep office должен содержать значение из столбца office таблицы offices; в противном случае служащий будет закреплен за несуществующим офисом. Можно указать СУБД, чтобы она обеспечивала ограничение на значения внешнего ключа.

Деловые правила. Обновление информации в базе данных может быть ограничено деловыми правилами, которым подчиняются сделки, представляемые подобными обновлениями. Например, компания, использующая учебную базу данных, может установить деловое правило, запрещающее принимать заказы на товар в количествах, превьпцающих количество товара на складе. Можно указать СУБД, что следует проверять каждую новую строку, добавляемую в таблицу orders, и убеждаться, что значение в столбце qty не нарушает установленное деловое гфавило.

Непротиворечивость. Многие реальные деловые операции вызывают в базе данных несколько изменений одновременно. Например, операция прием заказа может включать в себя добавление строки в таблицу orders, увеличение значения столбца sales в таблице salesreps для служащего, принявшего заказ, и увеличение значения столбца sales в таблице offices для офиса, за которым закреплен этот служащий. Одна инструкция insert и две инструкции update - все они должны быть выполнены для того, чтобы база данных осталась в правильном, непротиворечивом состоящий. Можно указать СУБД, что следует обеспечивать непротиворечивость изменяемых данных.

В стандарте ANSI/ISO определены наиболее простые условия целостности данных. Например, условие обязательности данных поддерживается стандартом ANSI/ISO и одинаковым образом реализовано почти во всех коммерческих СУБД. Более сложные условия, в частности деловые правила, не упоминаются в стандарте, и среди методов их реализации в различных СУБД наблюдается большое разнообразие. В настоящей главе рассматриваются средства SQL, поддерживающие первые пять условий целостности данных. Механизм обработки транзакций в SQL, который обеспечивает вьшолнение условия негфотиворечивости данных, будет рассмотрен в главе 12.

Обязательное наличие данных

Это, наиболее простое, условие целостности данных требует, чтобы некоторые столбцы не содержали значений null. Стандарт ANSI/ISO и большинство коммерческих СУБД поддерживают выполнение подобного условия, позволяя пользователю при создании таблицы объявить, что некоторые столбцы не могут содержать значений null. Само условие задается как часть инструкции create table в виде ограничения not null.

Если на столбец наложено ограничение not null, то для выполнения этого условия СУБД обеспечивает следующее:

ни в одной инструкции insert, добавляющей в таблицу строку или строки, нельзя указьшать значение null для этого столбца; попытка добавить строку, содержащую (явно или неявно) значение null для такого столбца, вызовет ошибку;

ни в одной инструкции update, обновляющей столбец, нельзя присваивать столбцу значение null; попытка обновить такой столбец, присвоив ему значение null, вызовет ошибку

Недостатком условия обязательного наличия данных является то, что его необходимо задавать при создании таблицы. Как правило, для таблицы, созданной ранее это условие отменить нельзя. Но это не очень большой недостаток, поскольку обычно уже при создании таблицы бывает ясно, какой столбец может содержать значения null, а какой - нет.

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

Условия на значения

в стандарте SQL1 частично поддерживаются ограничения на значения данных, которые можно заносить в столбец таблицы. При создании таблицы за каждым столбцом закрепляется определенный тип данных, и СУБД следит за тем, чтобы в столбец вводились данные только этого типа. Например, для столбца empl num таблицы salesreps определен тип данных integer, и СУБД вьщаст ошибку, если инструкция insert или update попытается ввести в столбец строку символов или десятичное число.

Однако в стандарте SQL1 и многих коммерческих СУБД не существует ограничений на запись в столбец конкретных значений. СУБД без колебаний добавит в таблицу salesreps строку с идентификатором служащего 12345, хотя в учебной базе данных вдентификаторы служащих должны состоять только из трех цифр. Аналогично, дата 25 декабря без возражений будет принята в качестве даты приема на работу, хотя на Рождество в компании был выходной день.

В некоторых коммерческих СУБД имеются дополнительные средства для проверки допустимости значений данных. Например, в СУБД DB2 за каждой таблицей может бьпъ закреплена соответствующая процедура проверки данных - программа, написанная пользователем и проверяющая, являются ли значения данных допустимыми. Эта процедура в DB2 вызьшается всякий раз, когда инструкция SQL пытается изменить строку таблицы или добавшъ в таблицу новую строку. В процедуру проверки передаются предлагаемые значения столбцов этой строки, а сама процедура проверяет данные и посредством возвращаемого значения сообщает, являются ли они приемлемыми. Процедура проверки представляет собой обычную программу (написанную, например, на ассемблере для S/370 или на РЕД), поэтому она может выполнять любые проверки значений данных, включая проверку на принадлежность диапазону или на внутреннюю непротиворечивость записи в таблице. В то же время процедура проверки не имеет доступа к базе данных, поэтому ее нельзя использовать для проверки уникальности значений или отношений внешний ключ - первичный ключ .

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