2.4 Реляционная модель данных

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

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

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

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

<ИМЯ ТАБЛИЦЫ> (<СПИСОК АТРИБУТОВ>),

где список атрибутов – это множество неповторяющихся имен атрибутов, в котором ключевые атрибуты будут выделены подчеркиванием.

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

Пустые значения. Значение атрибута может быть пустым (иметь значение NULL). Значение NULL приписывается атрибуту в кортеже, если атрибут неприменим или его значение неизвестно.

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

2.4.1 Поддержка целостности данных

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

Целостность данных – это точность и непротиворечивость значений данных в базе данных.

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

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

• категорная целостность;

• целостность на уровне ссылок;

• функциональные зависимости.

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

Правило категорной целостности. Никакой ключевой атрибут строки не может быть пустым.

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

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

ЗАГОЛОВКИ (НОМЕР_ПРОТОКОЛА, ДАТА, ТИП_ОБЪЕКТА, ИСПЫТАТЕЛЬ),

РЕЗУЛЬТАТЫ (НОМЕР_ПРОТОКОЛА, ПАРАМЕТР_1,…, ПАРАМЕТР_N).

Внешним ключом для связи между этими таблицами служит атрибут НОМЕР_ПРОТОКОЛА.

Если в рассмотренном выше примере из таблицы ЗАГОЛОВКИ удалить некоторую запись, не удалив при этом связанные с ней записи из дочерней таблицы РЕЗУЛЬТАТЫ, то эти записи как бы повиснут в воздухе.

Условиями ссылочной целостности данных называют набор правил для поддержания связей между записями в связанных таблицах. Эти правила делают невозможным случайное удаление или изменение связанных данных.

Условия целостности данных выполняются в следующих случаях:

• связанное поле главной таблицы является ключевым полем;

• связанные поля (внешние ключи) имеют один тип данных;

• обе таблицы принадлежат одной базе данных.

При определении условия целостности данных действуют следующие ограничения.

Для изменения записей:

• при изменении значений внешнего ключа в родительской таблице автоматически осуществляется каскадное изменение всех соответствующих значений в дочерней таблице;

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

При удалении записей:

• при удалении записей в родительской таблице автоматически осуществляется каскадное удаление всех записей из дочерней таблицы, связанных с удаляемой записью;

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

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