5.4.4.Переход к реляционной модели данных

Правила преобразования ER-модели в реляционную модель.

Каждой сущности ставится в соответствие отношение реляционной модели данных. Например, сущность может быть названа «Книжный каталог», а соответствующее ей отношение желательно назвать, например, BOOKS (без пробелов и латинскими буквами) (Рис.5.4).

Каждый атрибут сущности становится атрибутом соответствующего отношения. Для каждого атрибута задаётся конкретный допустимый в СУБД тип данных и обязательность или необязательность данного атрибута (то есть допустимость или недопустимость NULL значений для него).

КНИЖНЫЙ КАТАЛОГ				BOOKS
Номер				Num int
Наименование				Name varchar(60)
Автор			Avtor varchar(30)
год			God int

Рис.5.4. Соответствие сущности «КНИЖНЫЙ КАТАЛОГ» отношению «BOOKS».

• Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

• В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).

• Для моделирования необязательного типа связи на физическом уровне у атрибутов, соответствующих внешнему ключу, устанавливается свойство допустимости неопределённых значений (признак NULL). При обязательном типе связи атрибуты получают свойство отсутствия неопределённых значений (признак NOT NULL).

• Для каждого подтипа создаются свои отдельные отношения. [165]

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

На рис. 5.5 показан смысл этих понятий на примере отношения СЛУЖАЩИЕ, содержащего информацию о служащих некоторого предприятия.

Рис.5.5. Соотношение основных понятий реляционного подхода

Тип данных.

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

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

Домен.

Понятие домена более специфично для баз данных, хотя и имеются аналогии с подтипами в некоторых языках программирования (более того, в своем «Третьем манифесте» Кристофер Дейт и Хью Дарвен вообще ликвидируют различие между доменом и типом данных).³⁹ В общем виде домен определяется путем задания некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу этого типа данных (ограничения домена). Элемент данных является элементом домена в том и только в том случае, если вычисление этого логического выражения даёт результат истина (истина и ложь или true и false). С каждым доменом связывается имя, уникальное среди имен всех доменов соответствующей базы данных.

Наиболее правильной интуитивной трактовкой понятия домена является его восприятие как допустимого потенциального, ограниченного подмножества значений данного типа [166].

Например, домен ИМЕНА в примере определён на базовом типе символьных строк, но в число его значений могут входить только те строки, которые могут представлять имена (в частности, для возможности представления русских имен такие строки не могут начинаться с мягкого или твердого знака и не могут быть длиннее, например, 30 символов). Если некоторый атрибут отношения определяется на некотором домене (как, например, на рисунке атрибут СЛУ_ИМЯ определяется на домене ИМЕНА), то в дальнейшем ограничение домена играет роль ограничения целостности, накладываемого на значения этого атрибута.

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов НОМЕРА ПРОПУСКОВ и НОМЕРА ОТДЕЛОВ относятся к типу целых чисел, но не являются сравнимыми (допускать их сравнение было бы бессмысленно).

Заголовок отношения, кортеж, тело отношения, значение отношения, переменная отношения.

Понятие отношения является наиболее фундаментальным в реляционном подходе к организации баз данных, поскольку n–арное отношение является единственной родовой структурой данных, хранящихся в реляционной базе данных. Это отражено и в общем названии подхода – термин реляционный (relational) происходит от relation (отношение). Однако сам термин отношение является исключительно неточным, поскольку, говоря про любые сохраняемые данные, мы должны иметь в виду тип этих данных, значения этого типа и переменные, в которых сохраняются значения. Соответственно, для уточнения термина отношение выделяются понятия заголовка отношения, значения отношения и переменной отношения. Кроме того, требуется вспомогательное понятие кортежа.

Итак, заголовком (или схемой) отношения r (Hr) называется конечное множество упорядоченных пар вида <A, T>, где A называется именем атрибута, а T обозначает имя некоторого базового типа или ранее определённого домена. По определению требуется, чтобы все имена атрибутов в заголовке отношения были различны. В примере на рисунке 5.5 заголовком отношения СЛУЖАЩИЕ является множество пар {<слу_номер, номера_пропусков>, <слу_имя, имена>, <слу_зарп, размеры_выплат>, <слу_отд_номер, номера_отделов>}.

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

Правила получения реляционных отношений.

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

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

Правило 3: Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей является необязательным, то необходимо построение трех отношений: по одному для каждой сущности, ключи которых служат в качестве первичных ключей соответствующих отношений, и одно для связи. Среди своих атрибутов отношение, выделенное для связи, будет иметь ключи сущностей.

Правило 4: Если степень бинарной связи 1: М и класс принадлежности М-связанной сущности является обязательным, то достаточным является использование двух отношений, по одному на каждую сущность. При условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связанной сущности должен быть добавлен как атрибут в отношение, отведенной для М-связанной сущности.

Правило 5: Если степень бинарной связи 1: М и класс принадлежности М-связанной сущности является необязательным, то достаточным является использование трех отношений, по одному на каждую сущность, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одного отношения для связи. Отношение для связи должно иметь среди своих атрибутов ключ каждой сущности.

Правило 6: Если степень бинарной связи равна М : М, то необходимо три отношения: по одному на каждую сущность с первичными ключами от соответствующих сущностей, и одно отношение для связи. Отношение для связи должно иметь среди своих атрибутов ключ каждой сущности.

Процесс проектирования БД.

Цели создания БД:

• Возможность хранения всех необходимых данных.

• Исключение избыточности.

• Сведение числа хранимых в БД отношений к минимуму. Решение проблем избыточности, корректировки и обновления данных решается, как правило, разбиением отношения на несколько независимых. Это приводит к общему увеличению числа отношений и соответственно файлов. Это приводит к сложностям пользования и ведения БД.

• Нормализация отношений для упрощения процедур обновления и удаления данных.

Исключение избыточности данных.

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

Пример. На рис.5.6 в поле Исполнитель на первый взляд наблюдается избыточность – повторение Исп-1.

Тема

Шифр_темы	Исполнитель
111	Исп-1
112	Исп-2
113	Исп-1
114	Исп-1

Рис.5.6. Отношение Тема в исходном виде.

Если сгруппировать данные по исполнителям (рис.5.7) и убрать «лишних» Исп-1, то

Шифр_темы	Исполнитель
112	Исп-2
111	Исп-1
113	---
114	---

Рис.5.7. Приведенное отношение Тема.

Если удалить запись 111, то не будет известен исполнитель тем 113 и 114. Таким образом, это пример не избыточности данных, а необходимого неизбыточного дублирования.

Если отношение Тема расширить атрибутом Телефон,

Шифр_темы

Исполнитель

Телефон

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

Тема (Шифр_Темы, Исполнитель)

Тел._Исполнителя (Исполнитель, Телефон)

Аномалии вставки, удаления и обновления.

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

Обновление. Если имеет место большая избыточность данных, то к одному и тому же объекту может относиться несколько кортежей. В этом случае изменения должны вноситься во все записи, относящиеся к этому объекту.

Удаление. Аномалия сводится к тому, что при необходимости удаления некоторых значение атрибутов в случае определённой избыточности данных, удаляется вся запись.

Функциональная зависимость.

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

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

АВ

На практике это сводится к тому, что функциональная зависимость В от А означает, что если в любой момент времени известно значение А, то можно одновременно найти значение атрибута В.

Отсутствие функциональной зависимости

АВ.

Например, в отношении

СТУДЕНТ (НЗК, ФИО, Ном_Гр), где НЗК – номер зачётной книжки, Ном_Гр – номер группы,

НЗК  ФИО

НЗК  Ном_Гр

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

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

Пусть R (A1, A2,…, AN) – схема отношения, X и Y – подмножества (A1, A2,…, AN). Говорят, что Х функционально определяет Y (X  Y), если в любом отношении R, являющемся текущим значением R, не могут содержаться два кортежа, компоненты которых совпадают по всем атрибутам, принадлежащим множеству Х, но не совпадают по одному или более атрибутам, принадлежащим множеству Y.

Определение. Если АВ есть функциональная зависимость и В не зависит функционально от любого подмножества А, то говорят, что А представляет собой детерминант В или В функционально полно зависит от А.

Например, в отношении:

УСПЕВАЕМОСТЬ (НЗК, ФИО, ДИСЦ., ОЦЕНКА, ДАТА),

НЗК+ДИСЦ+ДАТА полностью определяет атрибут ОЦЕНКА.

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

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

Наличие тех или иных зависимостей в схеме отношения определяет степень её нормализации.

Степень нормализации определяется её номером: первая нормальная форма – 1НФ, вторая – 2НФ, третья – 3НФ, четвертая – 4НФ. Существует еще одна дополнительная нормальная форма Бойса-Кодда (НФБК).

Определение 1НФ: Отношение находится в 1НФ, если каждый его атрибут имеет и всегда будет иметь атомарное (неделимое) строение.

Например. Значение атомарного атрибута год рождения – «1970» не может быть разделено по смыслу на «19» и «70». В этом случае реляционное отношение представлено в виде множества неповторяющихся кортежей.

Эта форма является достаточной для работы языков запросов СУБД.

Определение 2НФ: Отношение задано во 2НФ, если оно является отношением в 1НФ и каждый атрибут, не являющийся первичным атрибутом в этом отношении, полностью зависит от любого возможного ключа этого отношения.

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

Если все возможные ключи отношения содержат по одному атрибуту, то это отношение задано во 2НФ, т.к. в этом случае все атрибуты, не являющиеся первичными, полностью зависят от возможных ключей.

Если ключи составные, отношение, заданное в 1НФ, может не быть отношением во 2НФ.

Например, в отношении:

ПОСТАВКА (НОМЕР_ИЗДЕЛИЯ, НОМЕР_ПОСТАВЩИКА, ИМЯ_ПОСТАВЩИКА, СВЕДЕНИЯ_О_ПОСТАВЩИКЕ, ЦЕНА)

атрибут ЦЕНА полностью зависит от составного ключа

НОМЕР_ИЗДЕЛИЯ, НОМЕР_ПОСТАВЩИКАЦЕНА

Атрибуты ИМЯ_ПОСТАВЩИКА и СВЕДЕНИЯ_О_ПОСТАВЩИКЕ полностью зависят от одного возможного ключа

НОМЕР_ПОСТАВЩИКАИМЯ_ПОСТАВЩИКА,

НОМЕР_ПОСТАВЩИКАСВЕДЕНИЯ_О_ПОСТАВЩИКЕ.

Для того, чтобы отношение ПОСТАВКА было задано во 2НФ, его необходимо разбить на два отношения:

ПОСТАВКА (НОМЕР_ИЗДЕЛИЯ, НОМЕР_ПОСТАВЩИКА, ЦЕНА);

ПОСТАВЩИК (НОМЕР_ПОСТАВЩИКА, ИМЯ_ПОСТАВЩИКА, СВЕДЕНИЯ_О_ПОСТАВЩИКЕ).

Определение 3НФ: Отношение задано в 3НФ, если оно задано во 2НФ и каждый атрибут из отношения, не являющийся первичным, нетранзитивно зависит от каждого возможного ключа.

Пусть А, В, С – атрибуты реляционного отношения. Если С зависит от В, а В – от А, то С зависит от А. Если при этом обратное соответствие неоднозначно (т. е., А не зависит от В или В не зависит от С), то говорят, что С транзитивно зависит от А, т. е.:

AB, BC, то AC

А

В

С

Преобразование в 3НФ состоит в разбиении исходного отношения на два:

(A, B) и (B, C).

А В

В С

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

Ниже определяются нормальные формы более высоких порядков, а именно, нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ).

При приведении к отношениям в 3НФ неявно предполагается, что все отношения содержат один потенциальный ключ. Это не всегда верно. Отношения могут содержащего несколько потенциальных ключей.

Определение НФБК: Отношение находится в нормальной форме Бойса-Кодда (НФБК) тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами [135].

Пример отношения, содержащего два ключа. Необходимо хранить данные о поставках деталей некоторыми поставщиками. Каждый поставщик имеет свой уникальный номер и уникальное наименование. Данные о поставках можно хранить в следующем отношении (Таблица 5.20):

Таблица 5.20. Отношение «Поставки»

Номер поставщика PNUM	Наименование поставщика PNAME	Номер детали DNUM	Поставляемое количество VOLUME
1	Фирма 1	1	100
1	Фирма 1	2	200
1	Фирма 1	3	300
2	Фирма 2	1	150
2	Фирма 2	2	250
3	Фирма 3	1	1000

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

PNUMPNAME – наименование поставщика зависит от номера поставщика.

PNAMEPNUM – номер поставщика зависит от наименования поставщика.

(PNUM, DNUM)VOLUME – поставляемое количество зависит от первого ключа отношения.

(PNUM, DNUM)PNAME – наименование поставщика зависит от первого ключа отношения.

(PNAME, DNUM)VOLUME – поставляемое количество зависит от второго ключа отношения.

(PNAME, DNUM)PNUM – номер поставщика зависит от второго ключа отношения.

Данное отношение не содержит неключевых атрибутов, зависящих от части сложного ключа. Действительно, от части сложного ключа зависят атрибуты PNAME и PNUM, но они сами являются ключевыми. Таким образом, отношение находится в 2НФ.

Кроме того, отношение находится в 3НФ и не содержит зависимых друг от друга неключевых атрибутов, т.к. неключевой атрибут всего один – VOLUME. Аномалия данного отношения устраняется путем декомпозиции его на два следующих отношения (Таблицы 5.21 и 5.22):

Таблица 5.21. Отношение "Поставщики"

ПОСТАВЩИКИ
Номер поставщика PNUM	Наименование поставщика PNAME
1	Фирма 1
2	Фирма 2
3	Фирма 3

Таблица 5.22. Отношение "Поставки-2"

ПОСТАВКИ-2
Номер поставщика PNUM	Номер детали DNUM	Поставляемое количество VOLUME
1	1	100
1	2	200
1	3	300
2	1	150
2	2	250
3	1	1000

Нормализация отношений вплоть до нормальной формы Бойса-Кодда основывается на понятии функциональной зависимости и предположении, что декомпозиция отношений происходит без потерь информации [135].

Дальнейшая нормализация в 4НФ основывается на понятии многозначной зависимости атрибутов в отношении. Понятие многозначной зависимости является обобщением понятия функциональной зависимости (подробнее в [135]).

Определение. Пусть R – отношение, и X, Y, Z – некоторые из его атрибутов (или непересекающиеся множества атрибутов).

Тогда атрибуты [множества атрибутов Y и Z многозначно зависят от X (обозначается ХY|Z)] тогда и только тогда, когда из того, что в отношении R содержатся кортежи r₁=(x,y,z₁) и r₂=(x,y₁,z), следует, что в отношении R содержится также и кортеж r₃=(x,y,z).

Определение. Многозначная зависимость (ХY|Z) называется нетривиальной многозначной зависимостью, если не существует функциональных зависимостей ХY и ХZ .

Определение 4НФ: Отношение R находится в четвертой нормальной форме тогда и только тогда, когда отношение находится в НФБК и е содержит нетривиальных многозначных зависимостей.

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

Таблица 5.23. Отношение СЛУЖАЩИЙ

СЛУЖАЩИЙ	ИН_ЯЗЫК	ДОЛЖНОСТЬ	ГОД
Иванов	Английский	инженер	1996
Иванов	Немецкий	инженер	1996
Иванов	Немецкий	Ст.инженер	1998
Иванов	Английский	Ст.инженер	1998
Сидоров	Французский	Вед.инженер	1998
Сидоров	Французский	Руководитель	1999
Сидоров	Испанский	Вед.инженер	1999
Сидоров	Испанский	Руководитель	1999

Аналогично, в отношении СЛУЖАЩИЙ (Таблица 5.23) также возникает нетривиальная многозначная зависимость СЛУЖАЩИЙИН_ЯЗЫК и СЛУЖАЩИЙДОЛЖНОСТЬ.

Для устранения этой зависимости необходимо выполнить разбиение отношения на два отношения: ЯЗЫК и ДОЛЖНОСТЬ (Таблицы 5.24 и 5.25):

Таблица 5.24. Отношение ЯЗЫК

СЛУЖАЩИЙ	ИН_ЯЗЫК
Сидоров	Французский
Сидоров	Испанский
Иванов	Английский
Иванов	Немецкий

Таблица 5.25. Отношение ДОЛЖНОСТЬ.

СЛУЖАЩИЙ	ДОЛЖНОСТЬ	ГОД
Сидоров	Вед.инженер	1998
Сидоров	Руководитель	1999
Иванов	Инженер	1996
Иванов	Ст.инженер	1998