create table можно установить один из двух режимов, обеспечиваюших целостность данных:

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

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

Расширенные возможности задания ограничений (SQL2)

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

Ограничения столбца указьшаются при создании таблицы (в инсфукции create table) как часть определения столбца. Концептуально они офаничивают его допустимые значения.

Домены - это особая форма офаничений столбца. С их помощью можно создавать нечто наподобие новьк типов данных, используемых в конкретной базе данных. По своей сути домен - это один из предопределенных типов данных, на который наложены некоторые дополнительные ограничения, задаваемые в определении домена. Столбцы наследуют эти офаничения. Сами домены создаются вне определений таблиц и столбцов с помощью инсфукции create domain.

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

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

Каждый из четырех типов офаничений имеет собственное концептуальное назначение и является отдельной частью синтаксиса SQL2. Однако различия между некоторыми из них довольно условны. Любое офаничение столбца может быть задано как офаничение таблицы. Подобным же образом офаничение таблицы может быть задано как утверждение. На практике обычно лучше определять каждое офаничение на том уровне, которому оно наиболее естественно соответствует в ситуации

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

Утверждения

Примеры первых трех типов офаничений приводились в начале этой главы. Офаничения четвертого типа, утверждения, задаются с помощью инструкции create assertion, появившейся в SQL2. Вот пример утверждения, которое может быть полезно в нашей учебной базе данных:

Гарантировать, что плановый объем продаж офиса не превысит сумму плановых объемов продаж его служащих:

CREATE ASSERTION quota valid CHECK ((OFFICES.QUOTA <= SUM(SALESREPS.QOOTA)) AND (SALESREPS.REP OFFICE = OFFICES.OFFICE))

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

Вот еще один пример утверждения:

Гарантировать, что общий объем заказов клиента не превысит его лимит кредита.

CREATE ASSERTION credit orders CHECK (CUSTOMER.CREDIT LIMIT >=

SELECT SUM(ORDERS.AMOUNT) FROM ORDERS WHERE ORDERS.CUST = CUSTOMER.CUST NUM)

Как показывают эти примеры, утверждение в SQL2 определяется заключенным в скобки условием, следующим за ключевым словом check. При каждой попытке изменения содержимого базы данных с помощью инсфукции insert, delete или update проверяется выполнение этого условия Если оно выполняется, модификация допускается. В противном случае СУБД не выполняет предложенные изменения, а вместо этого возвращает код ошибки и указывает, какое именно утверждение было нарушено.

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

Типы ограничений столбцов и таблиц в SQL2

По функциональному назначению все офаничения, предусмафиваемые стандартом SQL2, можно разделить на несколько типов:

Офаничение not null может действовать только на уровне столбца. Оно запрещает присваивать ячейкам столбца значение null.

Офаничение primary key может действовать на уровне столбца или таблицы. Если первичный ключ состоит из одного столбца, данное ограничение удобнее определить для этого столбца. Если же ключ содержит несколько столбцов, ограничение должно быть определено для всей таблицы.

Ограничение unique может действовать на уровне столбца или таблицы. Если уникальными должны быть значения одного столбца, данное офаничение лучше всего определить для этого столбца. Если же уникальной должна быть комбинация значений нескольких столбцов, тогда следует определить ограничение на уровне таблицы.

Офаничение foreign key может действовать на уровне столбца или таблицы. Если внешний ключ состоит из одного столбца, данное офаничение удобнее задать для этого столбца. Если же ключ состоит из нескольких столбцов, лучше определить офаничение на уровне таблицы. Когда таблица связана через внешние ключи с большим количеством других таблиц, удобнее собрать все ограничения внешних ключей в одном месте, определив их на уровне таблицы, а не разбрасывать их определения по отдельным столбцам.

Офаничение check может действовать на уровне столбца или таблицы. Кроме того, это единственный вид офаничения, которое может быть частью определения домена или утверждения. Офаничение этого типа задается как условие отбора, подобное тем, что используются в предложении where в запросах к базе данных. Данные удовлетворяют офаничению в том случае, если выполняется указанное в нем условие.

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

Отложенная проверка ограничений

в своей простейшей форме офаничения, определенные в базе данных, проверяются при каждой попытке изменения ее содержимого - т.е. при выполнении каждой инструкции insert, delete или update. Для СУБД, совместимых со стандартом SQL2 только на уровне Intermediate или Entry, это единственный способ проверки Офаничений. А вот уровнем Full стандарта SQL2 определяется дополнительная возможность отложенной проверки офаничений.

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