Сформулируйте приемлемые допущения относительно ключей и пресекайте все нарущсния ограничений установкой значения соответствующего афибута в NULL.

♦а) Каждый класс, упомянутый в Ships, должен быть упомянут и в Classes.

b) Каждое сражение, упомянутое в Outcomes, должно быть упомянуто и U Battles.

c) Каждый корабль, упомянутый в Outcomes, должен быть упомянут и в Ships.

6.3 Ограничения на значения атрибутов

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

1. Офаничение на атрибут в определении схемы отношения, в которое он входит.

2. Ограничение на область, которая объявляется областью значений данного атрибута.

в разделе 6.3.1 будет введен простой тип ограничений на значение атрибута, согласно которому атрибут ие имеет значения NULL. В разделе 6.3.2 рассматрнвакл-ся главная форма огра1Н1чений типа (1) - основанные на атрибуте ограничения CHECK. Раздел 6.3.3 посвяшен второму типу ограничений - ограничениям на области, а раздел 6.4 - более общим вндам ограничений. Последние применяются как для ограничения изменений целых кортежей и даже целых отношений или множества отношений, так н аля ограничения значения единственного атрибута.

6.3.1 Ограничения,

запрещающие значение NULL

Простым ограничением, связанным с атрибутом, является NOT NULL. Оно запрещает кортежн. п которых данный атрибут имеет значение NULL, и задается ключевыми словами NOT NULL, стоящими за описанием атрибута в определении CREATE TABLE.

При.чср 6.5. Требование, чтобы атрибут presC# отноиюния Stud о не имел зна че1И1я NULL, можно выразить заменой строки (4) рис. 6.3 на строку

4) presC# INT REFERENCES Movi6Exec(cert#) NOT NULL

Это изменение имеет несколько следствий:

о Значение компонента presC# кортежа невозможно заменить значением NULL.

Невозможно ввести кортеж в отношение Studio, определив только имя

и адрес, так как при этом он имеет значение NULL в компоненте presC*.

Невозможно применить правило установки в NULL в случаях, подобных тому, что отражен II строке (5) рис. 6 3, т.е. фиксировать нарушения внешнего ключа установкой значения presC#. D

6.3 Ограничения на значений атрибутов 277

6.3-2 Основанные на атрибуте ограничения CHECK

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

Проверка основанного на атрибуте ограничения CHECK проводится всегда, когда любой кортеж получает новое значение данного атрибута. Новое значение может быть введено при изменении кортежа или являться частью введенного кортежа. Если новое значение нарушает ограничение, изменение не выполняется. В примере 6.7 будет показано, что основанное на атрибуте ограничение CHECK не всегда проверяется, когда изменение БД не затрагивает значение атрибута, к которому ограничение относится, и это может привести к его нарушению. Рассмотрим простой пример этого ограничения.

Пример 6.6. Допустим, требуется, чтобы номер сертификата состоял по меньшей мере из шести цифр. Для этого строку (4) описания схемы отношения

Studio(nanie. address. presC#)

из рис. 6.3 можно заменить строкой

4) presC# INT REFERENCES MovieExec(cert#) CHECK (presC# >= 100000)

Или, например, атрибут gender отношения

MovieStar(nanie, address, gender, birthdate)

описанного на рис. 5.13, имеет тип данных CHAR(1), т.е. единственный символ. В действительности же здесь могуг появиться только буквы F или М. Поэтому сфоку (4) рнс. 5.13 можно заменить строкой

4) gender CHAR{1) CHECK (gender N (F. M)).

В этом условии используется явное отношение с двумя значениями. Условие означает, <гго значение любого компонента gender должно входить в это отношение. □

В проверяемом условии можно упоминать другие етрибуты данного отношения и даже другие отношения, но при этом нужно формулировать подзапрос. Условием может быть все, что следует за словом WHERE,в SQL-предложеиии. Однако проверка ограничения связана только с рассматриваемым атрибутом, а не с каждым отношением или атрибутом, упомянутым в офаничении. Поэтому условие может стать ложным, если змeняeтcя элемент не проверяемого, а какого-то другого атрибута.

Пример 6.7. Попробуем выразить офаничение ссылочной целостности с помощью основанного на атрибуте ограничения CHECK, требующего наличия значения, на которое делается ссьшка. Далее показана ошибочная попытка выразить требование, согласно которому значение presC# в кортеже отношения

Studio(nanne, address, presC#)

Когда нужно проверять выполнение ограничения

в нормальных условиях система SQL не допускает изменений БД. вызывающих нарушения ограничения. Но иногда приходится выполнить несколько изменений, одно из которых вызывает нарушение, а другие устраняют возникшие противоречия. В примере 6.3 presC# -это внешний ключ отношения Studio, ссылающийся на cert# в отношении MovieExec. Если нужно добавить новую студию и ее президента, то попьггка сначала добавить студию нарушает ограничение по внешнему ключу.

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

В SQL2 проблема решается добавлением к ограничению аювй DEFERRED. s Тогда данное ограничение проверяется до тех пор, пока не завершится тран-I закиия (базовый модуль операции на БД; см. раздел 7.2). В единственной ? транзакции можно ввести н студню, и президента, избежав таким образом J нарушения ограничения.

6.3.3 Ограничения области

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

должно появиться в компоненте сеп* кортежа отношения

MovieExecfnanie, address, cert#, netWorth)

Допустим, что строка {А) рис. 6.3 заменена строкой

4) presC# INT CHECK

(preset IN (SELECT certS FROM MovieExec))

Это вполне корректное, основанное на атрибуте ограьшченне CHECK, но результаты его негативны.

Невозможно ввесгн в отношение Studio новый кортеж, имеющий значение компонента presC#, не являющееся номером сертификата администратора фильма.

Значение компонента presC# кортежа из Studio невозможно заментъ новым значением, не являющимся номером сертификата администратора фильма.

Если из отношения MovieExec удалить, например, кортеж для президента студии, такое изменение останется невидимым для данного ограничения. Значит, удаление разрешено, даже если нарушается ограничение CHECK на атрибут presC#.

В разделе 6.4.2 будут введены более жесткие ограничения, позволяющие корректно выразить рассмотренное в этом примере условие. О