Требования к реляционным базам данных

1) каждая таблица должна иметь уникальное имя;

2) столбцы одной таблицы должны иметь уникальные имена, поэтому порядок следования столбцов в таблице не имеет значения;

3) каждая строка таблицы должна быть уникальной, т.е. в одной таблице не может быть двух одинаковых строк;

4) в каждой ячейке таблицы может быть только одно значение;

5) в идеале каждое данное должно храниться в базе в единственном экземпляре, т.е. не должно быть избыточности и дублирования данных. На практике избыточность данных должна быть сведена к разумному минимуму;

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

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

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

Из всех возможных ключей необходимо выбрать один (желательно, наиболее компактный и неинформативный) и сделать его первичным ключом.

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

Для каждой таблицы обязательно наличие первичного ключа.

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

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

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

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

Пятое требование. Для уменьшения избыточности данных необходимо выявить столбцы, в которых одно и то же значение повторяется (может повторяться) несколько раз. Если такой столбец найден, сначала следует принять решение: стоит ли избавляться от избыточности в этом столбце (привести пример со столбцом «Год рождения». Если такое решение принято, то этот столбец следует сделать отдельной сущностью, т.е.:

- создать отдельную таблицу;

- перенести этот столбец и другие столбцы, которые (функционально или транзитивно) зависят от данного столбца, в новую таблицу;

- обеспечить наличие в новой таблице целочисленного столбца «ID» (т.е. если еще не было – добавить) в качестве первичного ключа;

-в исходную таблицу добавить столбец, в котором будут храниться значения «ID» из новой таблицы (такой столбец называется внешним ключом, желательно, чтобы его название заканчивалось на «_ID»).

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

Если столбец является внешним ключом, то это означает, что две таблицы связаны, и СУБД будет самостоятельно следить за целостностью информации во внешнем ключе. Это обеспечивает выполнение шестого требования в части ссылочной целостности.

Примечание. Подобным же образом можно обосновать необходимость использования трех таблиц для реализации связи «многие-ко-многим» в реляционной модели данных.

Шестое требование. Термин «целостность данных» относится к правильности и полноте информации, содержащейся в базе данных. При изменении содержимого базы данных (добавление, обновление, удаление) может произойти нарушение целостности содержащихся в ней данных. Например:

- для номера телефона не указано имя контакта;

- при добавлении нового имени контакту ему присвоен уже имеющийся у другого имени контакта идентификационный номер;

- для контакта указана несуществующая мелодия.

Одной из важнейших задач реляционной СУБД является поддержка целостности данных на максимально возможном уровне.

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

Обязательность данных. Некоторые столбцы в базе данных должны обязательно содержать значения в каждой строке, т.е. это столбцы, обязательные для заполнения.

Целостность таблицы. В каждой таблице должен быть первичный ключ. Первичный ключ обязателен для заполнения.

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

Если в СУБД установлены вышеперечисленные условия целостности данных, то СУБД сама следит за их выполнением.