Правила проектирования БД

Проблемы реляционного подхода

Главный ключ системы

Для выполнения операций над данными необходимо иметь для каждой записи (строки) таблицы уникальный идентификатор, значение которого однозначно определяет только эту запись. Этот идентификатор называют Главный ключ (primary key). Он может состоять из одного или нескольких полей. Например, в TELEF (телефонный справочник, см. пример)- роль ключа выполняет одно поле- Номер телефона, а в SEBEST- 3 поля: Фирма, Прод., Сх.

Главный ключ должен обладать двумя свойствами:

1. Однозначной идентификацией записи.

2. Отсутствием избыточности- никакое поле нельзя удалить из ключа, не нарушая при этом однозначности (первого свойства).

В примере ZAKAZ - главным ключом является номер завода (поскольку бессмысленно иметь иначе).

Главным ключом в таблице KADR «просится» быть Ф.И.О…. (посмотрим далее).

Таким образом, указание главного ключа - это и есть единственный способ отличить один экземпляр объекта от другого.

Вернемся к Ф.И.О.- это не надежный ключ. Более надежным является в пределах предприятия - табельный номер; в пределах страны - номер и серия паспорта или просто один номер (как в США- social secuirity number).

Слово «главный» предполагает и наличие неглавного или простого (вторичного) ключа. Этот термин возникает в операции, подразумевающей просмотр по какому-либо полю. Например, по полю «Катег» в примере с телефонным справочником. Т.е. при этом «Катег»- это простой ключ и его значение может быть неуникальным.

Один из выводов по ключам: главный ключ - только один, а простых ключей может быть множество.

Простые ключи используются при так называемом индексировании (об этом далее).

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

Пользуясь рассмотренными понятиями можно спроектировать совокупность таблиц, которая и образует БД. Например, в БД для задачи Заказ может содержаться три таблицы.

- Заказ;

- Словарь заказчиков;

- Словарь продукции.

При оценке приведённых примеров становится ясно, что разработчик располагает некоторой свободой (можно сделать разными способами). Однако главный критерий проектирования - компромисс между двумя противоречащими друг другу требованиями:

- количество таблиц должно быть по возможности минимальным;

- таблицы должны быть нормализованы с учетом некоторых правил (рассмотрим далее).

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

Задача нормализации

Ранее мы встретились с чисто механическим переходом от иерархической структуры к реляционной и назвали этот процесс нормализацией.

Но такая нормализация не дает оптимальной двумерной структуры. Могут возникнуть неприятности, приводящие к потерям данных.

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

Выход - в удалении поля «Банк_рек» и включении его, с добавлением кода заказчика в качестве ключа в таблицу- словарь SLZAK. Получится, что одно поле в словаре будет обслуживать много полей в основной таблице. Кроме этого словарь можно использовать и с другими таблицами, в которых есть поле «Код_зак».

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

Если применить этот принцип снова к тому же примеру - обнаружим еще поле «Цена»- его значение является функцией поля «Код_прод», поэтому следует поступить аналогично «Реквизитам» - сделать словарем.

Последнее поле «Стоимость» также является лишним, поскольку его значение- вычислимо и равно произведению цены на объем, поэтому его не нужно хранить в БД.

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

Выводы:

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

1. Правильно выбрать главный ключ (убедиться, что не могут существовать двух записей с одинаковым значением главного ключа).

2. Если главный ключ не просматривается - подумать, правильно ли подобран состав полей.

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

Дата добавления: 2014-01-06