Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

Приведем другие существующие ограничения для вычисляемых столбцов.

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

* Вычисляемый столбец не может быть определен как массив или возвращать массив.

* Вы можете определить вычисляемый столбец BLOB, используя оператор SELECT для поиска столбца BLOB в другой таблице, но делать это настоятельно не рекомендуется.

* Вычисляемые столбцы не могут быть индексированы.

* Ограничения, помещенные для вычисляемого столбца, будут проигнорированы.

* Вычисляемые столбцы используются только для вывода и только для чтения. Включение их в операторы INSERT или UPDATE вызовет исключение.

! ! !

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

. ! .

Примеры вычисляемых столбцов

Следующий оператор создает вычисляемый столбец FULL NAME путем конкатенации столбцов LAST_NAMES и FIRST_NAME.

CREATE TABLE PERSON (

PERSON_ID BIGINT NOT NULL,

FIRST_NAME VARCHAR(35) NOT NULL,

LAST_NAMES VARCHAR (80) NOT NULL,

FULL_NAME COMPUTED BY FIRST_NAME ||' ' || LAST_NAMES) ;

/**/

SELECT FULL_NAME FROM PERSON

WHERE LAST_NAMES STARTING WITH 'SMI';

FULL NAME

=============

Arthur Smiley

John Smith

Mary Smits

! ! !

ПРИМЕЧАНИЕ. Обратите внимание на ограничения NOT NULL В двух именах, объединяемых для вычисляемого столбца. Важно обращать внимание на такие детали в случае вычисляемых столбцов, потому что NULL как элемент конкатенации всегда будет давать результат NULL.

. ! .

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

CREATE TABLE SNIFFIT

(SNIFFID INTEGER NOT NULL,

SNIFF COMPUTED BY (CURRENT_USER),

SNIFFDATE COMPUTED BY (CURRENT_TIMESTAMP));

/**/

SELECT FIRST 1 FROM SNIFFIT;

SNIFFID SNIFF SNIFFDATE

===== ===== =====

1 SYSDBA 2004-08-15 08:15:35.0000

Следующий пример создает таблицу с вычисляемым столбцом (NEW_PRICE), который использует ранее созданные определения для OLD_PRICE и PERCENT_CHANGE:

CREATE TABLE PRICE_HISTORY (

PRODUCT_ID D_IDENTITY NOT NULL, /* использует домен */

CHANGE_DATE DATE DEFAULT CURRENT_TIMESTAMP NOT NULL,

UPDATER_ID D_PERSON NOT NULL, /* использует домен */

OLD_PRICE DECIMAL(13,2) NOT NULL,

PERCENT_CHANGE DECIMAL (4, 2)

DEFAULT 0

NOT NULL

CHECK (PERCENT_CHANGE BETWEEN -50.00 AND 50.00);

NEW_PRICE COMPUTED BY

(OLD_PRICE + (OLD PRICE * PERCENT_CHANGE / 100)) );

Ограничения

На языке реляционных баз данных любое условие, налагаемое на формат, диапазон значений, содержание или зависимости структуры данных, называется ограничением (constraint). Firebird предоставляет несколько способов для реализации ограничений, включая как формальные, определенные стандартами ограничение целостности и ссылочное ограничение, так и определенные пользователем ограничения CHECK.

Ограничения видны всем транзакциям, которые выполняют доступ к базе данных, и автоматически применяются на сервере. Они различаются их областью действия. Некоторые, такие как NOT NULL, напрямую применяются к одному столбцу (ограничения столбца), в то время как другие, такие как PRIMARY KEY и некоторые ограничения CHECK, имеют эффект на уровне таблицы (ограничения таблицы). Ограничение FOREIGN KEY имеет область действия таблица-таблица.

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

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

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

Каждое из ограничений целостности подробно обсуждается позже в этой главе.

Ссылочное ограничение

Ссылочное ограничение реализовано как FOREIGN KEY. Ограничение внешнего ключа существует только в контексте другой таблицы и уникального ключа этой таблицы, заданного явно или неявно в предложении REFERENCES при объявлении ограничения.

Таблицы, связанные в отношении внешнего ключа, называются связанными ограничением ссылочной целостности. Следовательно, любой столбец или группа столбцов, ограниченная в ограничениях PRIMARY KEY или UNIQUE, также потенциально являются субъектами ссылочных ограничений.

Ссылочная целостность подробно обсуждается в главе 17.

Именованные ограничения

При объявлении ограничения на уровне таблицы или на уровне столбца вы можете именовать ограничение, используя предложение CONSTRAINT. Если вы опустите предложение CONSTRAINT, Firebird сгенерирует уникальное системное имя ограничения. Ограничения хранятся в системной таблице RDB$RELATION_CONSTRAINTS.

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

Имена для PRIMARY KEY и FOREIGN KEY

Именование ограничения имеет особый смысл для ограничений PRIMARY KEY и FOREIGN KEY, особенно в Firebird 1.5 и выше. Существует возможность перекрыть "родные" для Firebird ограничения по именованию ключей.

Во всех версиях указанное имя будет перекрывать имя по умолчанию iNTEG nn и будет применено к ограничению. Однако:

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

* в версии 1.0.x будет использовано имя индекса по умолчанию (RDB$PRIMARYnn или RDB$FOREIGNnn).

! ! !

ПРИМЕЧАНИЕ. Существующие имена ограничений останутся без изменений при переводе базы данных с сервера версии 1.0.x на сервер версии 1.5.

. ! .

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

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

Ограничение NOT NULL

Firebird не поддерживает атрибут указания допустимости пустого значения, как это делают некоторые нестандартные СУБД. В соответствии со стандартами все столбцы в Firebird могут содержать пустое значение, если не будет явно указано ограничение NOT NULL. Необязательное ограничение NOT NULL является ограничением на уровне столбца, которое может быть применено, чтобы заставить пользователя вводить значение. NULL не является значением, так что любая попытка ввести NULL В столбец или установить его в значение NULL приведет к исключению.

Поскольку роль ограничения NOT NULL заключается в формировании ключей, вы должны знать относительно него некоторые ограничения.

* Оно должно применяться к определению любого столбца, который будет включен в ограничение PRIMARY KEY или UNIQUE.

* В Firebird 1,0.x оно должно применяться к определению любого столбца, который будет включен в ограничение UNIQUE или в уникальный индекс.

* Оно не может быть удалено из домена или столбца операторами ALTER DOMAIN или ALTER TABLE, ALTER COLUMN или перекрыто на уровне столбца. Не используйте домен NOT NULL для определения столбца, который может иметь значение NULL.

Для большего понимания NULL см. разд. "Обсуждение NULL" главы 21.

Ограничение PRIMARY KEY

PRIMARY KEY является ограничением целостности на уровне столбца - набор поддерживаемых правил, - которое формально отмечает столбец или группу столбцов как уникальный идентификатор для каждой строки в таблице.

Если вы пришли в Firebird из СУБД, которые поддерживают концепцию "первичного индекса" для определения ключа (обычно основанные на файлах системы, такие как Paradox, Access и MySQL), то Firebird и мир стандартов SQL вам понятны. Первичный ключ является не индексом, а ограничением. Одним из правил для такого ограничения является то, что ограничение должно иметь определенный уникальный индекс из одного или более связанных с ним непустых элементов.

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

! ! !

ВНИМАНИЕ! Не надо импортировать существующий "первичный индекс" из наследуемой системы, основанной на файлах, или создавать такой индекс в ожидании объявления ограничения первичного ключа. Firebird не может накладывать ограничение первичного ключа поверх существующего индекса - по крайней мере в существующих версиях, включая 1.5, - а оптимизатор запросов не будет правильно работать при дублировании индексов.