2. Реляционная модель

2.1. Основные понятия реляционной модели

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

Приведем основные понятия реляционных баз данных без математических определений:

Тип данных – совпадает с определением типа данных в языках программирования.

Домен – тип данных с дополнительными ограничениями, например, телефон – число в определенном формате.

Отношение – фактически, это таблица.

Атрибут – название колонки таблицы.

Кортеж – фактически, это строка таблицы.

Первичный ключ – множество атрибутов (или один атрибут), который однозначно идентифицирует кортеж в отношении. Например, номера в табличках примера на Рис. 3.

Внешний ключ – атрибут, который принимает значения первичного ключа в другой таблице. Например, N_Продавца в таблице «Сделки» на Рис. 3.

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

Свойства отношений:

1. Отсутствие кортежей-дубликатов.

2. Отсутствие упорядоченности кортежей (не важно, в каком порядке располагаются записи, их упорядочивание зависит от запроса или представления).

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

4. Атомарность значений атрибутов (не может быть составных атрибутов). Например, Фамилия, Имя, Отчество – это три атрибута, а не один. Данное свойство – действительно жесткое правило, которое может вызывать проблемы. Например, в условиях глобальной корпорации человека могут звать по системе, отличной от «Фамилии, имени и отчества». В ОРБД и ООБД проблема решается созданием класса «Полное имя».

Реляционные СУБД обеспечивают следующие виды целостности:

1. Целостность сущностей: каждый кортеж должен обладать первичным ключом

2. Ссылочная целостность: для каждого кортежа с внешним ключом должен существовать кортеж с соответствующим первичным ключом по связи.

Пример: нет человека без фамилии, нет сделки без покупателя.

Целостность обеспечивается триггерами. Могут работать следующие механизмы:

1. Запретить удаление или изменение кортежей, на которые есть ссылки

2. При удалении установить значение в кортежах, где есть ссылки, на неопределенное

3. Каскадное удаление.

4. Каскадное обновление.

Пример: При удалении продавца установить поле «номер продавца» в таблице «сделка» на номкр «уволенного продавца» (это представляется более верным, так как таблица «Сделки» хранит финансовую информацию, которую удалять нежелательно при каскадном удалении).

2.2. Нормализация

В примерах из домашних заданий до сих пор составление схемы БД было интуитивным. Каждой сущности и сложным видам связи ставились в соответствие таблицы, в которые входили атрибуты соответствующих им сущностей и связей. Вместе с тем, существует формальный механизм «правильного» проектирования схемы БД. Нормализация – формальный метод анализа отношения на основе первичного ключа (или потенциальных ключей) и функциональных зависимостей. Другое определение: нормализация – последовательное приведение схемы БД в удовлетворительное количество отношений и связей. В настоящее время известно шесть нормальных форм: каждая следующая нормальная форма в некотором смысле лучше предыдущей; при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

Пример: таблица СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ

(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Аномалии:

1. аномалия вставки: нельзя вставить новое отделение, в котором нет сотрудников;

2. аномалия удаления: при удалении всех сотрудников одного отделения исчезает информация о самом отделении;

3. аномалия модификации: если несколько сотрудников имеют одинаковое задание, то его изменение придется выполнять в нескольких кортежах.

Определение нормальных форм и пример нормализации БД приведен в Табл. 4.

Как показывает опыт, разработчики БД интуитивным путем создают БД в третьей НФ, если каждой сущности или документу предметной области ставят в соответствие таблицу (если, конечно, бизнес-правила в организации построены логично). При этом нужно следить, чтобы атрибуты находились в нужной таблице. Если есть сомнения, к какой таблице отнести атрибут, то, возможно, это означает, что таблицы на самом деле связаны между собой промежуточной таблицей, которую не включили в схему. Нужно обращать внимание на то, чтобы одна и та же информация не дублировалась в разных таблицах (иначе возможна противоречивость информации). В отношении бизнес-правил также стоит задуматься о последствиях изменения некоторых атрибутов. Так, например, изменение значения отдела у продавца приведет к тому, что все его прошлые сделки, которые он совершил, работая в одном отделе, перейдут к другому отделу. Или изменение фамилии приведет к изменению прошлых официальных документов, в которых человек был под другой фамилией, что может быть не желательно. Такие проблемы требуют изменения структуры БД.

Табл. 4. Нормализация БД

НФ	Описание	Дополнительное определение	Пример	Последствия
1NF	Отсутствие составных атрибутов		ФИО разделить на три части
2NF	1NF + каждый неключевой атрибут полностью зависит от первичного ключа.	В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y. Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.	СОТР_НОМЕР -> СОТР_ЗАРП СОТР_НОМЕР -> ОТД_НОМЕР ОТД_НОМЕР -> СОТР_ЗАРП СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР) СОТР_НОМЕР -> СОТР_ЗАРП СОТР_НОМЕР -> ОТД_НОМЕР ОТД_НОМЕР -> СОТР_ЗАРП СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН) СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН	В результате мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет никакого проекта. При удалении кортежа мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все кортежи, описывающие этого сотрудника, или получим несогласованный результат.
3NF	2NF + каждый неключевой атрибут нетранзитивно зависит от первичного ключа.	Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z --> R.X.	Транзит. СОТР_НОМЕР -> СОТР_ЗАРП СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР) СОТР_НОМЕР -> ОТД_НОМЕР ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП) ОТД_НОМЕР -> СОТР_ЗАРП	В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все кортежи, описывающие сотрудников этого отдела.
BCNF (НФ Бойса-Кодда)	Каждый детерминант является возможным ключом.	Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.	СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН) – СОТР_ИМЯ – детерминант СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ) СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)	для того, чтобы изменить имя сотрудника с данным номером согласованным образом, нам потребуется модифицировать все кортежи, включающие его номер.
4NF	В случае существования многозначной зависимости A -> -> B все остальные атрибуты R функционально зависят от A.	В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.	ПРОЕКТЫ (ПРО_НОМЕР,ПРО_СОТР, ПРО_ЗАДАН) ПРО_НОМЕР -> -> ПРО_СОТР ПРО_НОМЕР -> -> ПРО_ЗАДАН ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР) ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)	некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено.
PJ/NF (Проекция-Соединение)	любая зависимость соединения в R следует из существования некоторого возможного ключа в R.	Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.	СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР) СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР) СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР) ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)	Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ существует зависимость соединения: * (СО, СП, ОП) На примерах легко показать, что при вставках и удалениях кортежей могут возникнуть проблемы. Их можно устранить путем декомпозиции исходного отношения в три новых отношения:

Подробнее о реляционной модели см. [3].