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

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

Внешние ключи

"Кабелями", которые делают реляционную базу данных "реляционной", являются внешние ключи (foreign key). Это столбец или структура столбцов, которая в вашей модели данных является стороной "многие" в отношении один-ко-многим. При физическом проектировании внешний ключ соответствует столбцу или структуре столбцов первичного ключа таблицы стороны "один" в этом отношении.

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

Рис. 14.1. Простая связь

Такая модель требует, чтобы каждая строка заголовка имела уникальный ORDER_NUMBER и существовала, по меньшей мере, одна детальная строка заказа для каждой заголовочной строки заказа. Другие правила могут применяться к факту существования и к связи. Firebird предоставляет мощные процедуры триггеров для установки, согласования и применения правил к отношениям. Дополнительно он может автоматизировать множество типичных правил управления отношениями, включая ограничение FOREIGN KEY С дополнительными аргументами действий. Основой для такого ограничения являются сгенерированные системой триггеры ссылочной целостности. Поддержка ссылочной целостности в Firebird вкратце обсуждалась ранее в разд. "Ссылочная целостность" и будет детально рассмотрена в главе 17.

Суррогатные ключи

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

CREATE TABLE PERSON {

FIRST_NAME VARCHAR(30) NOT NULL,

LAST NAME VARCHAR(50) NOT NULL,

PHONE_NUMBER VARCHAR(18) NOT NULL,

ADDRESS_1 VARCHAR(50),

. . . );

Проектировщик принимает решение, что комбинация (FIRST_NAME, LAST_NAME, PHONE NUMBER) является хорошим кандидатом для первичного ключа. Люди могут использовать один и тот же телефонный номер, но весьма маловероятно, что два человека с одинаковыми именем и фамилией будут использовать один и тот же номер телефона, верно? Таким образом, проектировщик делает следующее:

ALTER TABLE PERSON

ADD CONSTRAINT PK_PERSON PRIMARY KEY

(LAST_NAME, FIRST_NAME, PHONE_NUMBER) ;

Первая проблема с этим первичным ключом в том, что каждый элемент имеет смысл. Каждый элемент поддерживается человеком и может быть изменен или записан с ошибками. Два ключа ('Smith', 'Mary', '43889474') и ('SMITH', 'Mary', '43889474') Не являются одинаковыми и оба могут быть помещены в эту таблицу. Какая запись будет изменена, если магу выйдет замуж или изменит номер телефона?

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

Реальные накладки могут появиться, если эти столбцы используют многобайтовые наборы символов или не двоичные порядки сортировки. Размеры индексов ограничены 252 байтами. Для ключей обязательно создаются индексы. Такой ключ будет невозможен просто по причине слишком большого размера.

Создание атомарного ключа

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

Решение заключается в добавлении дополнительного столбца в таблицы для использования в качестве искусственного или суррогатного первичного ключа - уникальный, ограниченного размера столбец, желательно генерируемый системой, который заменяет (замещает) функцию теоретического первичного ключа. Firebird предоставляет объекты GENERATOR, которые могут быть использованы для создания требуемых уникальных серий чисел BIGINT для первичного ключа размером 8 байт или меньше.

Общую технику реализации автоинкрементного первичного ключа (при отсутствии ручной работы) см. в разд. "Генераторы" главы 9 ив главе 31.

! ! !

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

. ! .

Итог - суррогатные ключи против естественных ключей

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

Таблица 14.1. Суррогатные (искусственные) ключи в сравнении с естественными

Особенность

За

Против

Атомарность

Суррогатные ключи не воспринимаются как данные и никогда не изменяются

Естественные ключи по своей сути нестабильны, потому что они являются предметом человеческих ошибок и внешних изменений

Удобство

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

Естественные ключи более удобны при использовании в интерактивных инструментах запросов

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

Размер ключа

Суррогатные ключи компактны

Естественные ключи имеют больший размер и часто усложняют составные ключи, которые усложняют запросы и схему

Навигация

Суррогатные ключи обеспечивают чистую, быструю навигацию по коду

Естественные ключи обычно не являются подходящими при навигации в стиле кода по причине порядка сортировки, денормализации и размера

Нормализация

Суррогатные ключи могут быть нормализованы в базе данных

Естественные ключи имеют тенденцию к усложнению, распространению денормализации данных внешних ключей

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

! ! !

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

. ! .

Ключи не являются индексами

Индексы не являются ключами. Ключи- ограничения на уровне таблицы. Сервер базы данных реагирует на объявление ограничений созданием множества объектов базы данных для их поддержки. Для ограничений первичных и уникальных ключей он создает уникальный индекс из столбца (столбцов), указанных в ограничениях. Для внешних ключей он создает неуникальный индекс из указанных столбцов, сохраняет записи для отношения и создает триггеры для выполнения нужных действий.

* Ключи являются ограничениями.

* Индексы требуются для поддержания ограничений.

! ! !

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

. ! .

Ссылочная целостность данных

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