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

Всегда выполняйте резервное копирование перед любыми действиями, изменяющими метаданные.

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

Временные таблицы

Firebird не поддерживает временные таблицы, которые управляются системой. Здесь они меньше нужны, чем в других СУБД. Например, у Firebird есть возможность получать виртуальные таблицы напрямую через хранимую процедуру, написанную с использованием специального синтаксиса. Более подробно об этом см. разд. "Хранимые процедуры выбора" в главах 29 и 30.

Постоянные "временные" таблицы

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

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

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

! ! !

СОВЕТ. Временные таблицы, скорее всего, появятся в следующем релизе Firebird.

. ! .

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

ГЛАВА 17. Ссылочная целостность данных.

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

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

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

* Скорость запросов: индексы, автоматически созданные для ограничений ссылочной целостности, увеличат скорость операций соединения (join)[47].

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

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

Терминология

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

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

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

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

! ! !

ПРИМЕЧАНИЕ. Необязательное отношение существует, когда отношение возможно в формальной структуре, но не является необходимым. То есть родитель- ский экземпляр может существовать без каких-либо ссылок на него со стороны дочернего элемента, но, если оба существуют, оба подчиняются ограничениям. В противоположность этому существуют обязательные отношения. Обязательные отношения обсуждаются позже в этой главе.

. ! .

Стандартная модель объект-отношение описывает простое отношение один-ко- многим, между двумя сущностями, как показано на рис. 17.1.

Рис. 17.1. Модель объект-отношение

Если мы реализуем такую модель между двумя таблицами PARENT и CHILD, то строки в таблице CHILD зависят от существования связанной строки из PARENT. Ограничение FOREIGN KEY в Firebird осуществляет это отношение следующими способами:

* требуется, чтобы значение столбца внешнего ключа в таблице CHILD (CHILD.PARENT ID) могло быть связано с соответствующим значением уникального ключа (в нашем случае, первичного ключа) в таблице PARENT (PARENT, ID);

* по умолчанию запрещено удаление строки PARENT или изменение значения уникального ключа, если существуют зависимые строки в CHILD;

* должно быть реализовано отношение, которое предполагалось во время создания ссылки или когда оно в последний раз изменялось[48];

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

Реализация ограничения

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

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

CREATE TABLE PARENT (

ID BIGINT NOT NULL,

DATA VARCHAR(20),

CONSTRAINT PK_PARENT PRIMARY KEY(ID));

COMMIT;

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

CREATE TABLE CHILD (

ID BIGINT NOT NULL,

CHILD_DATA VARCHAR(20),

PARENT_ID BIGINT,

CONSTRAINT PK_CHILD PRIMARY KEY(ID));

COMMIT;

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

Синтаксис определения ссылочной целостности следующий:

FOREIGN KEY (столбец [, столбец ...])

REFERENCES (родительская-таблица [, столбец ...])

[USING [ASC | DESC] INDEX имя-индекса] /* добавлено в версии 1.5 */

[ON DELETE {NO ACTION | CASCADE | SET NULL | SET DEFAULT}]

[ON UPDATE {NO ACTION | CASCADE | SET NULL | SET DEFAULT}]

Определим наш внешний ключ:

ALTER TABLE CHILD

ADD CONSTRAINT FK_CHILD_PARENT

FOREIGN KEY(PARENT_ID)

REFERENCES PARENT(ID);

/* также допустимо REFERENCES PARENT, поскольку ID является первичным ключом таблицы PARENT */

Firebird сохраняет ограничение FK_CHILD_PARENT и создает обычный индекс для столбца (столбцов), перечисленных в качестве аргументов FOREIGN KEY. В Firebird этот индекс будет также назван FK_CHILD_PARENT, если вы не использовали необязательное предложение USING для задания другого имени индекса. В Firebird 1.0.x индекс будет иметь имя INTEG_NN (где NN - некоторое число).