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);