double arrow

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Заказ;

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

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

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

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

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

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


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



Сейчас читают про: