Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Чтобы первичный ключ был атомарным, нужно быть вне человеческих решений. Если люди составляют его или классифицируют его, он не является атомарным. Если он является субъектом любого правила за исключением требований NOT NULL и уникальности, он не является атомарным. В приведенном ранее примере даже водительские права или номер социального обеспечения не соответствуют требованиям атомарности для первичного ключа, потому что они являются субъектами внешних систем.

Можно использовать несколько вариантов синтаксиса для назначения ограничения PRIMARY KEY столбцу или группе столбцов. Все столбцы, являющиеся элементами первичного ключа, должны быть предварительно определены с атрибутом NOT NULL. Так как нельзя добавить ограничение NOT NULL в столбец после его создания, необходимо позаботиться об этом ограничении до использования других ограничений.

Ограничение PRIMARY KEY может применяться в любой из следующих фаз создания метаданных:

* в определении столбца в операторах CREATE TABLE или ALTER TABLE как часть определения столбца;

* в определении таблицы в операторах CREATE TABLE или ALTER TABLE как отдельно определенное ограничение таблицы.

В следующей последовательности создается и подтверждается (commit) домен, не допускающий пустое значение, затем определяется столбец первичного ключа, основанный на этом домене, и одновременно применяется ограничение PRIMARY KEY к этому столбцу:

CREATE DOMAIN D_IDENTITY AS BIGINT NOT NULL;

COMMIT;

CREATE TABLE PERSON (

PERSON_ID D_IDENTITY PRIMARY KEY,

Firebird создает ограничение таблицы с именем INTEG_M и индекс с именем RDB$PRIMARYnn. (пл в каждом случае - число, полученное от генератора. Эти два числа не связаны друг с другом.) Вы не можете повлиять на то, какими будут эти имена, и не можете поменять их.

Результат будет похожим, если вы используете тот же подход при добавлении столбца, используя оператор ALTER TABLE и создавая первичный ключ в одном предложении:

ALTER TABLE BOOK

ADD BOOK_ID D_IDENTITY PRIMARY KEY;

Другой способ определения первичного ключа в определении таблицы - добавить объявление ограничения в конце определений столбцов. Объявления ограничений помещаются последними, потому что они зависят от существования столбцов, к которым они обращаются. Этот метод дает вам возможность именования ограничений. Следующее объявление именует ограничение первичного ключа как PK_ATABLE:

CREATE TABLE ATABLE (

ID BIGINT NOT NULL,

ANOTHER_COLUMN VARCHAR (20),

CONSTRAINT PK_ATABLE PRIMARY KEY(ID) );

Теперь вместо использования сгенерированного системой имени RDB$PRIMARYnnn Firebird использует PK_ATABLE В качестве имени этого ограничения. В Firebird 1.5 и выше он также применяет определенное пользователем имя ограничения для поддерживающего уникального индекса. В этом примере индекс получит имя PK_ATABLE, когда в других версиях его имя будет RDB$PRIMARYnnn.

Firebird 1.5 также позволяет использовать определенные пользователем имена для ограничения и поддерживающего его индекса.

До Firebird 1.5 не было возможности использовать убывающий индекс для поддержки первичного ключа. Начиная с версии 1.5, можно поддерживать первичный ключ убывающим индексом. Чтобы это сделать, в Firebird 1.5 добавляется расширение синтаксиса в форме предложения USING, позволяющего создавать индекс ASC[ENDING] (по возрастанию) или DESC [ENDING] (по убыванию) и присваивать ему имя, отличное от имени ограничения.

AS с и DESC определяют направление поиска. Подробнее эта концепция обсуждается в главе 18.

Следующий оператор создаст ограничение первичного ключа с именем PK ATEST и поддерживающий его убывающий индекс с именем IDX_PK_ATEST:

CREATE TABLE ATEST (

ID BIGINT NOT NULL,

DATA VARCHAR(10));

COMMIT;

ALTER TABLE ATEST

ADD CONSTRAINT PK_ATEST PRIMARY KEY(ID)

USING DESC INDEX IDX_PK_ATEST;

COMMIT;

Альтернативный синтаксис также будет работать:

CREATE TABLE ATEST (

ID BIGINT NOT NULL,

DATA VARCHAR(10),

CONSTRAINT PK_ATEST PRIMARY KEY(ID)

USING DESC INDEX IDX PK ATEST;

! ! !

ВНИМАНИЕ! Если вы создаете индекс DESCENDING для ограничения первичного или уникального ключа, вы должны указать USING DESC INDEX для всех ссылающихся на него внешних ключей.

. ! .

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

Обычно в первом скрипте мы объявляем таблицы и подтверждаем их создание:

CREATE TABLE ATABLE (

ID BIGINT NOT NULL,

ANOTHER_COLUMN VARCHAR (20),

< другие столбцы > ) ;

CREATE TABLE ANOTHERTABLE (

. . .

COMMIT;

ALTER TABLE ATABLE

ADD CONSTRAINT PK_ATABLE

PRIMARY KEY(ID);

ALTER TABLE ANOTHERTABLE...

и т.д.

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

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

! ! !

СОВЕТ. Ограничения CHECK применяются после выполнения триггеров "before". Используйте триггер, если вы хотите выполнить проверку и присвоить данным допустимые значения.

. ! .

В определении таблицы это ограничение на уровне таблицы. В отличие от ограничений CHECK, применимых к определению домена, его элемент VALUE является ссылкой на столбец. Например, для домена предложение CHECK может быть следующим:

CHECK(VALUE > 10)

В определении таблицы то же самое условие для столбца с именем ACOLUMN будет представлено как:

CHECK (ACOLUMN > 10)

Ограничение CHECK будет активным для операций INSERT и UPDATE. Хотя это ограничение на уровне таблицы, его область действия может выходить за пределы уровня столбца на уровень строки и, хотя это не рекомендуется, на уровень таблицы и даже за пределы таблицы. Ограничение CHECK гарантирует целостность данных, только если значения, включенные в проверку, находятся в той же самой строке, что и проверяемое значение.

! ! !

ВНИМАНИЕ! Вы не должны использовать выражения, которые сравнивают значение со значениями из других строк этой же таблицы или других таблиц, потому что любая строка, отличная от текущей, может находиться в процессе изменения или удаления в другой транзакции. В особенности не полагайтесь на ограничение CHECK для проверки ссылочных отношений!