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

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

street

Abonent

Рис. 1.3. Связь один ко многим между таблицами Street и Abonent

Из рис. 1.3 следует, в столбце StreetCD таблицы Abonent содержится идентификатор улицы, на которой проживает абонент. Столбец StreetCD в таблице Abonent представляет собой внешний ключ, ссылающийся на одноименный столбец таблицы Street. Доменом этого столбца (множеством значений, которые могут в нем храниться) является множество идентификаторов улиц, содержащихся в столбце StreetCD таблицы Street. Мощность отношения - один ко многим , так как на одной и той же улице может проживать (и проживает) множество абонентов, но каждый абонент проживает только на одной определенной улице. Наименование улицы, на которой проживает, например, абонент АКСЕНОВ С.А., можно узнать, определив значение столбца StreetCD в строке таблицы Abonent со значением в столбце Fio, равным АКСЕНОВ С. А. (число 3), и затем отыскав в таблице Street строку с таким же значением в столбце StreetCD (улица ВОЙКОВ ПЕРЕУЛОК). Например, чтобы найти всех абонентов, проживающих на улице ВОЙКОВ ПЕРЕУЛОК, следует запомнить значение столбца StreetCD для этой улицы (число 3), а потом просмотреть таблицу Abonent и найти все строки, в столбце StreetCD которых содержится число 3 (это строки для абонентов с

номерами лицевых счетов 005488, 015527 и 115705).

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

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

1.6. Нормализация отношений

Процесс нормализации был впервые предложен Коддом в 1972 году [1, 2]. Этот процесс основан на понятии функциональной зависимости. По определению функциональная зависимость - это такая связь между атрибутами В и А одного и того же отношения, когда каждому значению А соответствует только одно значение В [2]. Атрибут А называют детерминантом. Детерминанты могут быть составными, т.е. представлять собой не единичные атрибуты, а группы, состоящие из двух и более атрибутов. Нормализация обычно приводит к разделению одной таблицы на две или более таблиц, соответствующих требованиям нормальных форм. Общепринятыми считаются пять нормальных форм. Сначала было предложено только три вида нормальных форм: первая (1 НФ), вторая (2НФ) и третья (3НФ). Затем Бойсом и Коддом в 1974 году было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса-

Кодда (НФБК).

Вслед за НФБК появились определения четвертой (4НФ) и пятой (5НФ) нормальных форм в 1977 и в 1979 годах. Однако на практике эти нормальные формы более высоких порядков используются редко.

Каждая последующая форма удовлетворяет требованиям предыдущей. Если следовать только первому правилу нормализации, то данные будут представлены в 1 НФ. Если данные удовлетворяют третьему правилу нормализации, они будут находиться в 3НФ (а также во 1НФ и 2НФ) и т.д.

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

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

Обратимся к учебной базе данных. Предположим, что данные из таблиц Abonent и Street ранее содержались в одной общей ненормализованной таблице. Вид такой таблицы представлен на рис. 1.4.

Рис. 1.4. Ненормализованная таблица

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

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

Отношение находится во 2НФ, если оно находится в 1 НФ и каждый его атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Другими словами, второе правило нормализации требует, чтобы любой неключевой столбец зависел от всего первичного ключа, а не от его отдельных компонентов. Это правило относится к случаю, когда первичный ключ образован из нескольких столбцов. Первичные ключи всех таблиц из учебной базы данных являются простыми (состоят из одного столбца), поэтому все таблицы находятся не только в 1НФ, но и однозначно во

2НФ.

Третья нормальная форма основана на понятии транзитивной зависимости. Если для атрибутов А, В и С некоторого отношения существуют зависимости С от В и В от А, то говорят, что атрибут С транзитивно зависит от атрибута А через атрибут В.

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

Рассмотрим, например, зависимости между столбцами в таблице PaySumma учебной БД. Например, столбец PaySum в этой таблице не зависит от столбца AccountCD, так как одному абоненту соответствует множество оплаченных сумм. Также столбец PaySum не зависит от столбца PayDate, так как на одну дату может приходиться несколько оплаченных сумм и т.д. Таким образом,