3. Особенности проектирования реляционной базы данных (рбд).

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

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

Для решения подобных проблем проводится нормализация отношений.

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

В рамках реляционной модели данных Э.Ф. Коддом (E.F. Codd) был разработан аппарат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме.

Нормализация схемы отношения выполняется путём декомпозиции схемы. Декомпозициейсхемы отношения R называется замена её совокупностью схем отношений А_iтаких, чтоR= U∙Aі (1)

и не требуется, чтобы отношения А_iбыли непересекающимися.

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

Первая нормальная форма (1НФ).

Отношение приведено к 1НФ, если все его атрибуты простые, т.е. неделимы.

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

Введём понятие функциональной зависимости. Пусть X и Y – атрибуты некоторого отношения. Если в любой момент времени каждому значению X соответствует единственное значение Y, что Y функционально зависит от X (X→Y). Атрибут (группа атрибутов) Х называется детерминантом.

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

На рисунке 3 приведен пример таблицы, не приведенный к первой нормальной форме, поскольку в столбце «Контактная информация» содержится массив значений. Рисунок 4 иллюстрирует ту же таблицу в первой нормальной форме, поскольку во всех ее столбцах отсутствует повторение информации.

Код адресата	Фамилия Имя	Контактная информация
1	Иванов Дмитрий	Телефон:111 22 32,Факс:212-333-4321
2	Мелехов Алексей	Телефон:213 12 22, email tom@ aurora.com

3. Таблица не соответствующая 1НФ.

Код адресата	Фамилия Имя	Код типа коммуникации	Тип коммуникации	Контактная информация
1	Иванов Дмитрий	1	Телефон	111 22 32
2	Иванов Дмитрий	2	Факс	212-333-4321
3	Мелехов Алексей	1	Телефон	213 12 22
4	Мелехов Алексей	3	E Mail	email tom@ aurora.com

4. Таблица соответствующая 1НФ.

Вторая нормальная форма (2НФ).

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

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

Рассмотрим понятие транзитивной зависимости. Пусть X, Y, Z – атрибуты некоторого отношения. При этом X→Y и Y→Z, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (X→→Z).

Иначе говоря, на рисунке 4 представлена таблица, которая не соответствует требованиям 2НФ. Таблица во второй нормальной форме должна отвечать требованиям первой нормальной формы, кроме того, каждое не ключевое поле в ней зависит от полного значения первичного ключа. Или часть информации может храниться в другой таблице и на нее можно ссылаться с помощью подстановки. Рассмотрим таблицу, представленную на рисунке 5, первичный ключ составлен из полей « Код адресата», «Код типа коммуникации» и «Контактная информация». Рассмотрим, зависит ли поле «Фамилия Имя» только от части ключа, полей «Код адресата» и «Контактная информация». Очевидно, что нет, поскольку оно зависит только от поля «Код адресата», являющегося частью первичного ключа. Чтобы преобразовать данную таблицу во вторую нормальную форму, необходимо разделить информацию, а данные о заказчиках поместить в таблицу подстановки, установив между двумя таблицами отношение «один-ко-многим». (см. рисунок 5). Теперь эти таблицы приведены ко второй нормальной форме.

Код адресата	Фамилия Имя
1	Иванов Дмитрий
2	Мелехов Алексей

Код адресата	Фамилия Имя	Код типа коммуникации	Тип коммуникации	Контактная информация
1	Иванов Дмитрий	1	Телефон	111 22 32
2	Иванов Дмитрий	2	Факс	212-333-4321
3	Мелехов Алексей	1	Телефон	213 12 22
4	Мелехов Алексей	3	E Mail	email tom@ aurora.com

5. Таблицы приведены к 2НФ

Третья нормальная форма (3НФ).

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

Для того чтобы привести отношение к 3НФ, нужно:

1. построить его проекцию, исключив транзитивно зависящие от ключа атрибуты;

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

Введём понятие многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество, состоящее из нуля (или более) значений атрибута Y (X–”Y).

Различают тривиальные и нетривиальные многозначные зависимости. Тривиальнойназывается такая многозначная зависимость X–”Y, для которой YX или X U Y = R, где R – рассматриваемое отношение. Тривиальная многозначная зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не выполняется, то такая зависимость называетсянетривиальной.

Иначе говоря, представленная на рисунке 5 Таблица 2 отвечает требованиям первой и второй форм, она не приведена к третьей нормальной форме. Третья нормальная форма требует, чтобы все не ключевые столбцы были взаимно независимыми. Хорошим примером зависимого поля является вычисляемое поле. На рисунке 5 Таблица 2 поле «Контактная информация» и поле «Тип Коммуникации». Поскольку значение поля «Контактная информация» определяется по значению поля «Код типа коммуникации», таблица не удовлетворяет 3НФ. Чтобы представить таблицу в третьей нормальной форме, необходимо отделить информацию об адресатах и поместить их в третью таблицу, а также создать отношения «один-ко-многим» между таблицами, содержащими информацию об адресатах и о подробностях контакта. Это отражено на рисунке 6.

Код адресата	Фамилия Имя
1	Иванов Дмитрий
2	Мелехов Алексей

Код типа коммуникаций	Тип коммуникаций
1	Телефон
2	Факс
3	E Mail

Код адресата	Код типа коммуникаций	Контактная информация

6. Исходная таблица представлена в третьей нормальной форме.

Преимущества нормализации.

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

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

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

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

Правила обеспечения целостности данных. При нормализации таблиц необходимо принимать во внимании правила обеспечения целостности данных. Большинство задаваемых правил определяются установленными отношениями. Кроме того, с помощью отношений можно организовать каскадное изменение и удаление данных. Установка каскадного изменения обеспечивает следующее: при изменении значения первичного ключа в таблице «один», изменение распространяется на все таблицы «многие». Например, имеется таблица подстановки, содержащая названия штатов. Значение «NewYork» представлено значением «NY» в поле первичного ключа. Представим ситуацию, когда город Нью-Йорк преобразуется в самостоятельный штат, при этом формируется его собственное сокращение название штата. При изменении значения «NY» на «NYI» (либо на нечто более описательное), значение «NY» во всех дочерних таблицах меняется на «NYI». Если каскадное обновление не установлено, потребуется в таблицу подстановки внести значение «NYI», изменить все записи в дочерней таблице и затем удалить из таблицы подстановки запись «NY». Установка каскадного удаления обеспечивает следующее: при удалении записи из таблицы «один» удаляются также все записи из таблицы «многие». Это может оказаться как преимуществом, так и недостатком. При удалении информации о заказчике в режиме каскадного удаления удаляются все его счета в таблице «многие». Если такой режим не установлен, удаление записей в таблице «один» не разрешается до тех пор, пока в таблице «многие» не будут удалены все связанные записи, чтобы в ней не осталось записей с неопределенным значением внешнего ключа.