таблицы ORDERS, что вызовет неожиданные аномалии в отчетах и экранных формах.

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

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

Первичные ключи

Возможность однозначно определить строку в таблице является основополагающей для реляционного проектирования. Делается это путем назначения первичного ключа. Никакие две строки в одной таблице не могут иметь одинаковый первичный ключ. Однако сделать это не так просто, как кажется! В жизни все происходит несколько по-другому. В модели, поскольку она является лишь моделью, мы, может быть, и не сможем уловить отличительные черты каждого экземпляра сущности, однако реляционная теория говорит, что каждая таблица должна иметь первичный ключ. Иногда приходится вводить искусственный идентификатор в форме суррогатного ключа. Это может быть просто числовая последовательность, которая начинается с единицы, обозначающей первую создаваемую строку, и увеличивается на единицу для каждой последующей строки. В некоторых случаях используются абсолютно бессмысленные для большинства людей последовательности чисел и (или) букв (взгляните, к примеру, на порядковые номера банкнот).

Иногда бывает, что предполагаемый первичный ключ таблицы оказывается не достаточно уникальным, когда мы начинаем учитывать реализацию его в реляционной базе данных. Возьмем, к примеру, событие. Дата и время Наступления события будут гарантированно уникальными, если определить их с достаточной степенью точности. Однако в базе данных Oracle время хранится с точностью до секунды, а наличие двух событий в секунду - явление весьма распространенное.

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

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

На этапе анализа каждой сущности, определенной в концептуальной! модели, должен быть присвоен уникальный идентификатор (УИД) - естест-; венно, если концептуальная модель должным образом нормализована. В начале проектирования нужно внимательно изучить эти УИДы и проверить,} действительно ли они уникальны. Ведь в больщинстве случаев в процессе] проектирования мы просто образуем первичные ключи из уникальных идентификаторов, определенных в ходе анализа.

В частности, необходимо проверить все синтетические УИДы (которые часто называют суррогатными ключами) данной сущности Эти ключи легко узнаваемы, потому что соответствуют атрибуту ID (или подобному). Такой атрибут обьршо представляет собой число, которое вне данной компьютерной системы не имеет никакого смысла. Во-первых, мы должны убедиться в том, что аналитик не создал эти суррогатные ключи просто для удобства или не применил какой-то общий метод к УИДам всех сущностей. Кроме того, мы должны проверить, не ли пропущенных или незамеченных УИДов.

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

Перед тем как принять созданный в процессе анализа суррогатный ключ, ответьте на следующие вопросы:

Есть ли или могут ли быть два экземпляра данной сущности с идентичными атрибутами и отношениями (кроме идентификатора)?

Если да, то что, с точки зрения бизнеса, различает их?

Должен ли пользователь в таких случаях записывать или запоминать эти идентификаторы?

Если идентификаторы перепутать, будет ли это иметь значение?

Лучше, конечно, получить ответы на эти вопросы у аналитика. (Впрочем, в качестве упражнения попробуйте ответить на них, привязавшись к деньгам в своем кармане. Полезно знать, сколько у вас с собой денег, но следить за каждой банкнотой или монетой, наверное, бессмысленно.)

Важно понимать различие между суррогатными и сгенерированными ключами. Суррогатные ключи всегда являются сгенерированными (чаше всего при помощи последовательности), однако сгенерированные ключи - не

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

Нсуникалъные (или почти уникальные) ключи

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

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

Рассмотрим пример, приведенный на рис. 6.1. Предположим, что мы можем создать несколько версий исходного кода с одним и тем же именем каталога и файла. Сделать каждую версию уникальной можно было бы путем ввода в ключ столбца INSERTDATETIME ( Вставить дату и время ), поскольку вручную создать две версии одного и того же исходного кода за одну секунду весьма сложно. Но если мы используем генератор кода, который очень быстро создает один за другим два варианта, то возможны проблемы. В таких случаях мы будем получать сообщения об ошибках периода выполнения о нарушении ограничения UNIQUE. Чтобы исправить ситуацию, можно изъять метку даты и времени из ключа и ввести в него простой целочисленный номер версии, как показано на рис. 6.2.

Рис. 6.1. Таблица с первичным ключом, который почти уникален