Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
В отличие от файловых систем управления данными Firebird совсем не поддерживает данные таблиц в табличном формате. Строки одной таблицы могут не находиться рядом с другими строками той же таблицы. В действительности строки одной таблицы могут размещаться в разных файлах и на разных дисках. Сервер использует разнообразные типы инвентарных страниц для хранения информации о физическом расположении строк, принадлежащих каждой таблице.
Обобщенно, столбец является совокупностью атрибутов, определяющих элемент данных, который может быть сохранен в одной указанной ячейке в структуре строки таблицы слева направо. При этом столбцы фактически
выведет набор, где порядок столбцов будет соответствовать указанному в запросе. Запрос может указывать столбцы из разных таблиц: соединений, подзапросов, объединений. Он может определять столбцы, вовсе отсутствующие в базе данных, сделав их вычисляемыми или даже просто задавая их как именованные константы.
Некоторые люди используют термин "поле" вместо столбца, например: "У меня есть таблица TABLEI, содержащая три поля". Часто книги по реляционным базам данных не одобряют использование "поле" как замена для "столбец", предпочитая использовать "поле" в смысле "значение в столбце" или "ссылка на столбец".
В этой книге "поле" используется только как термин для обобщения концепции столбца, аргумента и локальной переменной и для ссылок на выходные элементы, создаваемые во время выполнения. "Столбец" используется для ссылок на физические столбцы, определенные для таблиц.
Основной частью процесса проектирования базы данных является выделение в логической модели базы данных для каждой таблицы одного уникального столбца или структуры из нескольких столбцов, которая отличает каждую строку от любой другой строки в таблице. Такой уникальный столбец или комбинация столбцов является логическим первичным ключом (primary key). Когда вы создаете вашу физическую модель, вы используете ограничение PRIMARY KEY, чтобы сообщить СУБД, какой столбец или столбцы формируют такую уникальную идентификационную структуру. На таблицу вы можете определить только одно ограничение PRIMARY KEY. Синтаксис рассматривается в разд. "Ограничения" главы 16.
В процессе вашего моделирования может случиться так, что по разным причинам вам будет нужно более одного уникального столбца или структуры столбцов в таблице. Для поддержания требуемой уникальности таких столбцов или структур Firebird предоставляет ключ-ограничение UNIQUE. Это является альтернативой первичному ключу и при необходимости иногда может быть использовано вместо первичного ключа.
"Кабелями", которые делают реляционную базу данных "реляционной", являются внешние ключи (foreign key). Это столбец или структура столбцов, которая в вашей модели данных является стороной "многие" в отношении один-ко-многим. При физическом проектировании внешний ключ соответствует столбцу или структуре столбцов первичного ключа таблицы стороны "один" в этом отношении.
В следующей простой модели для примера детальные строки заказа связаны с заголовком заказа через ключ ORDER_NUMBER.
Рис. 14.1. Простая связь
Такая
Столбец, который в вашем анализе был определен как первичный ключ, или элемент первичного ключа почти всегда хранит элемент данных, имеющий некоторое значение. Возьмем, к примеру, таблицу, хранящую данные о человеке:
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 байт или меньше.