8.2. Свойства отношений

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

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

Кортежи не упорядочены (сверху вниз). Действительно, несмотря на то, что мы изобразили отношение «Сотрудники» в виде таблицы, нельзя сказать, что сотрудник Иванов «предшествует» сотруднику Петрову. Причина та же – тело отношения есть множество, а множество не упорядочено. Это вторая причина, по которой нельзя отождествить отношения и таблицы – строки в таблицах упорядочены. Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.

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

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

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

Каждое отношение можно считать классом эквивалентности таблиц, для которых выполняются следующие условия:

- таблицы имеют одинаковое количество столбцов;

- таблицы содержат столбцы с одинаковыми наименованиями;

- столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов;

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

Все такие таблицы есть различные изображения одного и того же отношения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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