Реляционный подход предложен в 1970 году Д.Коддом

Основные задачи были поставлена следующим образом:

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

Каждая таблица в БД есть с математической точки зрения набор отношений заданнойарности над заранее заданным множеством элементарных данных

Реляционные операции применяются сразу ко всему отношению, а не к отдельной строке

12 требований к реляционной базе даннх

1. Правило информации.Вся информация должна быть представлена на логическом уровне - в виде значений, содержащихся в таблицах.2. Правило гарантированного доступаЛогический доступ к каждому элементу данных должен быть обеспечен путем комбинации имени таблицы, имени столбца, и значения первичного ключа3. Правило динамического каталога.Описание БД на логическом уровне должно быть представимо в том же виде, что и описание собственно данных4. Правило поддержки недействительных значенийВ качестве данных должно обеспечиваться хранение недействительного значения которое будет отличаться от пустой строки символов, 0 и любого другого числа

5. Правило исчерпывающего подъязыка данных.Должен существовать язык, операторы которого можно представить в виде структурированных строк с определенным синтаксисом и который должент поддерживать слудующие элементы:- определение данных;- определение пользовательских представлений;- обработку данных;- условия целостности;- идентификацию прав;- границы транзакций (начало, завершение, отмена)6. Правило обновления пользовательских представленийВсе пользовательские представления, которые теоретически можно обновить должны быть доступны для обновления7. Правило добавления обновления и удаления.Возможность работать с отношением как с одним операндом должна существовать не только для чтения, но и для добавления, обновления и удаления.8. Правило независимости физических данных.Программные средства для работы с данными должны на логическом уровне оставаться неизменными при изменении способов хранения данных и методов доступа к ним.9. Правило независимости логических данных.Программные средства для работы с данными должны на логическом уровне оставаться неизменными при внесении изменений в структуры таблиц с сохранением неизменными хранящихся в таблицах данных10. Правило независимости условий целостностиУсловия целостности, специфические для конкретной базы данных должны определяться на языке реляционной базы даннх (п.5) и храниться в каталоге, а не в прикладных программах.11. Правило независимости распространенияБД не должна зависеть от потребностей конкретного клиента12. Правило едиственности.Никакие языковые средства не должны позволять обходить условия целостности (п.10)

Реляционная база данных есть конечный набор отношений

Отношение - двумерная таблица, имеющая уникальное имя и состоящая из строк и столбцов, где строки соответсвуют записям а столбцы - атрибутам.

Атрибут - поименованный столбец отношения .Порядок следовани яатрибутов не влияет на само отношение.

Схемой отношения R называется конечное множество имен атрибутов {A1, A2,... , An}

Степень отношения определяется количеством атрибутов, которые в нем присутствуют

ПРЕПОДАВАТЕЛЬ{Идентиф_код, Фамилия, Должность}

Для каждого имени атрибута Ai имеентся моножество допустимых значений.Это множество Di является доменом данного атрибута

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

Вся совокупность данных, которые могут встретиться в базе есть подмножетсво D = D1 U D2 U ... Dn

Всякий экземпляр отношения R{A1, A2,... , An} есть подмножество D и называется кортежем отношения

Свойства отношений, как таблиц специального вида:

1. Отношение имеет имя, которое отличает его от других отношений.2. Отношение имеет табличную структуру 3. Каждый атрибут отношения имеет уникальное имя, его значения берутся из одного и того же домена.4. Каждый компонент кортежа является простым элементом домена, не содержащим множество значений.5. Упорядочение атрибутов несущественно.6. Все кортежи отношения должны быть различны7. Порядок следования кортежей не имеет значения

Ключ - атрибут отношения либо группа атрибутов, позволяющие однозначно определять кортеж отношения.

Ключ присутствует в отношении, если выполняются 2 условия:1. Уникальность - в произвольный момент времени никакие 2 кортежа не имеют динаковых занчений ключа.2.Минимальность - ни один из атрибутов не может быть из ключа без нарушения правила уникальности

Ключей в отношении может быть более 1, но их всегда не менее 1.

Один из ключей отношения принимается за первичный ключ.

Внешний ключ - набор атрибутов одного отношения, являющихся ключом для другого отношения.

Внешний ключ и ключ определены на одном домене.

Лектор

Читает

Предмет

Ф_И_О

Учен_звание

Код_идентиф

Учен_степень

Код_курса

Кол_часов

Название

Концептуальная модель

ЛЕКТОРКод_идентиф

Ф_И_О

Уч_степень

Уч_звание

ЧИТАЕТ ЛЕКТОРКод_идентиф Код_предмета

Название_предм

К-во_часов

Код_предмета

Код_идентиф={10-значное число}Ф_И_О={возможные фамилии и инициалы}Уч_степень={Кандидат,Доктор,без степени} Уч_звание={Доцент,Профессор,без звания}Код_предмета={символьный}Название_предмета={Информатика,Программирование,Проектирование БД, Численные методы, Матанализ,Структуры и алгоритмы}К-во часов={Положительное целое число}

Реляционная схема БД

Код_идентиф Ф_И_О Уч_степень Уч_звание

2061222147 Баклан И.В. Кандидат Доцент

2093312588 Селин Ю.В Кандидат Без звания

1992698707 Фаловский А.А. Кандидат Без звания

2620123568 Лопатин С.М. Доктор Профессор

Код_предм

Назв_предм К-во_часов

01 Информатика 5402 Программирование 10203 Эконометрия 3604 ООП 5405 Базы данных 102

06 Структуры и алгоритмы 54

Лектор

Предмет Читает

Код_предм Код_идентиф

01 206122214702 206122214703 262012356804 2093312588

05 1992698707

06 1992698707

Реляционные отношения

Работник

ИЗДЕЛИЕ

Изготавливает

ТАБ_№

ФИО

Код_изд

Квалификация

ДетальКод_дет Название_детали

Название_изд

Входит

Таб_№={01,02,03,04}ФИО={возможные фамилии и инициалы}Квалификация={Положительное целое число} Код_изд={И1,И2,И3,И4}Назв_изд={Иа,Ив,Ис,Ид}Код_дет={Д1,Д2,Д3}Назв_дет={Да,Дв,Дс}

РАБОЧИЙ(Таб_№,ФИО,Квалификация) ИЗГОТАВЛИВАЕТ(Таб_№,Код_дет) ДЕТАЛЬ(Код_дет,Название_дет) ВХОДИТ(Код_изд,Код_дет) ИЗДЕЛИЕ(Код_изд,Назв_изд)

Таб_№ ФИО Квалиф01 Иваненко Т.О. 102 Лях К.П. 203 Мальський О.П. 204 Дронь Д.А 3

РАБОЧИЙ

Таб_№ Код_дет01 Д102 Д203 Д3

04 Д3

Код_изд Назв_изд01 Иа02 Ив03 Ис04 Ид

Код_дет Назв_детД1 ДаД2 ДаД3 Дс

ИЗГОТАВЛИВАЕТ ДЕТАЛЬ

ИЗДЕЛИЕ

Код_изд Код_дет01 Д101 Д202 Д303 Д303 Д4

ВХОДИТ

Реляционные отношения

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

Нельзя допускать “висячих ссылок” при удаленииНельзя допускать добавление без наличия хранимого внешнего ключа

4.Целостность относительно корпоративной политики - отражение в БД органичений, накладываемых политикой организации.

Аномалии при обработке данных (проблема нормализации):1. Аномалия добавленияОтношение СТУДЕНТ(№_зачетки,ФИО,Код_гр,ФИО_Старосты,Куратор)может содержать аномалии 2-х типов:1.1. Избыточность данных - необходимость дублировать значения атрибутов ФИО_Старосты,Куратор для каждого студента1.2. Некорректность первичного ключа - создание новой группы, куда еще не включен ни один студент.В этом случае значение №_зачетки будет не определенным =отсутствие первичного ключа.2. Аномалия удаления2.1. Потеря данных о группе при удалении всех ее студентов3. Аномалия модификации3.1. Попытка изменить значение атрибута ФИО_Старосты,Куратор для какой-либо группы может привести к появлению у группы 2-х старост либо 2-х кураторов.

Избежать этих проблем можно путем преобразования отношения СТУДЕНТ в 2 меньшихВ общем случае следует найти такой вариант разбиения, который удовлетворял бы следующим требованиям:1. Минимальная избыточность информации2. Ключи отношений должны быть минимальными3. Не должны появляться аномалии включения, удаления,обновления

Пример.ПОСТАВКА(Дата,Назв_поставщика,Товар,Адрес_поставщика,Колич_товара,Цена_ед_товара)

Проблемы:Избыточен Адрес_поставщикаПервичный ключ не минималенПри изменении Адрес_поставщика он не изменяется в др. кортежах = аномалия модификацииЕсли заключен договор на поставку, но товар еще не поставлен его нельзя включить в БД= аномалия включенияЕсли удалить все поставки к/л поставщика будут утеряны все сведения о нем = аномалия удаления

Процедура нормализации отношений

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

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

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

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

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

Согласно ограничениям, налагаемым на данные различают:1. 1НФ - первую нормальную форму 2. 2НФ - вторую нормальную форму 3. 3НФ - третью нормальную форму 4. НФБК - нормальную форму Бойса-Кодда

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

Функциональные зависимости и ключи.

Для отношения R(a1,a2,...aN) атрибут a2 функционально зависит от a1 если каждому значению a1 соответствует единственное значение a2 т.е. для каждого кортежа с одним значением a1 имеется одно значение a2.

Тогда получаем алгоритм выявления функциональных зависимостейВход: Отношение r и зависимость X -> Y.Выход: истина, если r удовлетворяет X -> Y, ложь - в противном случаеТело алгоритма: 1. Отсортировать отношение r по X-столбцам 2. Если каждая совокупность кортежей с равными X-значениями имеет равные Y-значения, то на выходе будет истина, иначе-ложь.

Пример. Проверка наличия зависимости A -> Br

A B C D

A1 B1 C1 D1

A2 B2 C1 D1A1 B1 C2 D2

A3 B1 C2 D3A2 B2 C3 D2

A1 B1 C3 D4

A4 B3 C4 D2

После сортировки по А имеем

A B C D

A1 B1 C1 D1

A1 B1 C2 D2A1 B1 C3 D4

A2 B2 C2 D2A2 B2 C1 D1A3 B1 C2 D3A4 B3 C4 D2

A B C D

A1 B1 C1 D1

A1 B1 C2 D2A1 B1 C3 D4

A2 B2 C2 D2A2 B2 C1 D1A3 B1 C2 D3A4 B3 C4 D2

Проверим наличие функциональной зависмости B->А. После сортировки по кортежу B имеем

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

Например отношение РОЖДЕНИЕИмя Дата рожденияАня 5 марта 1986

Саша 25 января 1987Ольга 1 ноября 1987Федор 14 сентября 1986

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

Имя День_рождения Месяц_рождения Год_рожденияАня 5 Март 1986

Саша 25 Январь 1987Ольга 1 Ноябрь 1987Федор 14 Сентябрь 1986

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

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

Кодпредмета

Названиепредмета

К-вочасов

Код_лекции

ФИО_лектора Должность

ЕНФ02 Информатика 54 001 Селин Ю.Н. ДоцентЕНФ02 Информатика 54 002 Селин А.Н. Ст.преп.ОПДФ08 ОС 102 003 Баклан И.В ПрофессорОПДФ08 ОС 102 001 Селин Ю.Н. ДоцентОПДФ08 ОС 102 002 Селин А.Н Ст.преп.СД03 ООП 54 001 Селин Ю.Н. ДоцентСД03 ООП 54 002 Селин А.Н Ст.преп.

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

Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2НФ.

Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (Н_СОТР, ФАМ, Н_ОТД, ТЕЛ, Н_ПРО, ПРОЕКТ, Н_ЗАДАН) не находится в 2НФ, т.к. есть атрибуты, зависящие от части сложного ключа:

Н_СОТР ФАМ Н_ОТД ТЕЛ Н_ПРО ПРОЕКТ Н_ЗАДАН

1 Иванов 1 11-22-33 1 Космос 11 Иванов 1 11-22-33 2 Климат 12 Петров 1 11-22-33 1 Космос 23 Сидоров 2 33-22-11 1 Космос 33 Сидоров 2 33-22-11 2 Климат 2

Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника является зависимостью от части сложного ключа:

Н_СОТР ФАМ Н_СОТР Н_ОТД Н_СОТР ТЕЛ

Зависимость наименования проекта от номера проекта является зависимостью от части сложного ключа: Н_ПРО ПРОЕКТ

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

Отношение СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ декомпозируем на три отношения - СОТРУДНИКИ_ОТДЕЛЫ, ПРОЕКТЫ, ЗАДАНИЯ.

Отношение СОТРУДНИКИ_ОТДЕЛЫ (Н_СОТР, ФАМ, Н_ОТД, ТЕЛ):

Н_СОТР ФАМ Н_ОТД ТЕЛ1 Иванов 1 11-22-332 Петров 1 11-22-333 Сидоров 2 33-22-11

Функциональные зависимости: Зависимость атрибутов, характеризующих сотрудника от табельного номера сотрудника: Н_СОТР ФАМ Н_СОТР Н_ОТД Н_СОТР ТЕЛ Зависимость номера телефона от номера отдела: Н_ОТД ТЕЛ

Отношение ПРОЕКТЫ (Н_ПРО, ПРОЕКТ):

Н_ПРО ПРОЕКТ1 Космос2 Климат

Функциональные зависимости: Н_ПРО ПРОЕКТ

Н_СОТР Н_ПРО Н_ЗАДАН1 1 11 2 12 1 23 1 33 2 2

Функциональные зависимости: {Н_СОТР, Н_ПРО} Н_ЗАДАН

Отношение ЗАДАНИЯ (Н_СОТР, Н_ПРО, Н_ЗАДАН):

Анализ декомпозированных отношений

Отношения, полученные в результате декомпозиции, находятся в 2НФ. Действительно, отношения СОТРУДНИКИ_ОТДЕЛЫ и ПРОЕКТЫ имеют простые ключи, следовательно автоматически находятся в 2НФ, отношение ЗАДАНИЯ имеет сложный ключ, но единственный неключевой атрибут Н_ЗАДАН функционально зависит от всего ключа {Н_СОТР, Н_ПРО}. Часть аномалий обновления устранена. Так, данные о сотрудниках и проектах теперь хранятся в различных отношениях, поэтому при появлении сотрудников, не участвующих ни в одном проекте просто добавляются кортежи в отношение СОТРУДНИКИ_ОТДЕЛЫ. Точно также, при появлении проекта, над которым не работает ни один сотрудник, просто вставляется кортеж в отношение ПРОЕКТЫ. Фамилии сотрудников и наименования проектов теперь хранятся без избыточности. Если сотрудник сменит фамилию или проект сменит наименование, то такое обновление будет произведено в одном месте.

Если по проекту временно прекращены работы, но требуется, чтобы сам проект сохранился, то для этого проекта удаляются соответствующие кортежи в отношении ЗАДАНИЯ, а данные о самом проекте и данные о сотрудниках, участвовавших в проекте, остаются в отношениях ПРОЕКТЫ и ОТРУДНИКИ_ОТДЕЛЫ. Тем не менее, часть аномалий разрешить не удалось.

Оставшиеся аномалии вставки (INSERT)В отношение СОТРУДНИКИ_ОТДЕЛЫ нельзя вставить кортеж (4, Пушников, 1, 33-22-11), т.к. при этом получится, что два сотрудника из 1-го отдела (Иванов и Пушников) имеют разные номера телефонов, а это противоречит модели предметной области. В этой ситуации можно предложить два решения, в зависимости от того, что реально произошло в предметной области. Другой номер телефона может быть введен по двум причинам - по ошибке человека, вводящего данные о новом сотруднике, или потому что номер в отделе действительно изменился.

Если нужно оставить старый номер (новый номер введен ошибочно), то кортеж с данными о новом сотруднике будет вставлен, но номер телефона будет у него будет тот, который уже есть в отделе (в данном случае, 11-22-33). Если же номер в отделе действительно изменился, то кортеж будет вставлен с новым номером, и одновременно будут изменены номера телефонов у всех сотрудников этого же отдела.Причина аномалии - избыточность данных, порожденная тем, что в одном отношении хранится разнородная информация (о сотрудниках и об отделах). Вывод - увеличивается сложность разработки базы данных. База данных, основанная на такой модели, будет работать правильно только при наличии дополнительного программного кода

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

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

Оставшиеся аномалии удаления (DELETE)При удалении некоторых данных по-прежнему может произойти потеря другой информации. Например, если удалить сотрудника Сидорова, то будет потеряна информация о том, что в отделе номер 2 находится телефон 33-22-11. Причина аномалии - хранение в одном отношении разнородной информации (и о сотрудниках, и об отделах).

Вывод - логическая модель данных не адекватна модели предметной области. База данных, основанная на такой модели, будет работать неправильно.

Заметим, что при переходе ко второй нормальной форме отношения стали почти адекватными предметной области.Остались также трудности в разработке базы данных, связанные с необходимостью написания кода, поддерживающего целостность базы данных.Эти трудности теперь связаны только с одним отношением СОТРУДНИКИ_ОТДЕЛЫ.

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

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

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

Отношение СОТРУДНИКИ_ОТДЕЛЫ не находится в 3НФ, т.к. имеется функциональная зависимость неключевых атрибутов (зависимость номера телефона от номера отдела): Н_ОТД ТЕЛ

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

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

Н_СОТР ФАМ Н_ОТД1 Иванов 12 Петров 13 Сидоров 2

Функциональные зависимости: Зависимость атрибутов, характеризующих сотрудника от табе1льного номера сотрудника:Н_СОТР ФАМН_СОТР Н_ОТДН_СОТР ТЕЛ

Отношение ОТДЕЛЫ (Н_ОТД, ТЕЛ):

Н_ОТД ТЕЛ1 11-22-332 33-22-11

Функциональные зависимости: Зависимость номера телефона от номера отдела: Н_ОТД ТЕЛ

Обратим внимание на то, что атрибут Н_ОТД, не являвшийся ключевым в отношении СОТРУДНИКИ_ОТДЕЛЫ, становится потенциальным ключом в отношении ОТДЕЛЫ. Именно за счет этого устраняется избыточность, связанная с многократным хранением одних и тех же номеров телефонов.

Вывод. Таким образом, все обнаруженные аномалии обновления устранены.Реляционная модель, состоящая из четырех отношений СОТРУДНИКИ, ОТДЕЛЫ, ПРОЕКТЫ, ЗАДАНИЯ, находящихся в третьей нормальной форме, является адекватной описанной модели предметной области, и требует наличия только тех поддержки ссылочной целостность.

Алгоритм нормализации (приведение к 3НФ)

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

Шаг 2 (Приведение к 2НФ). Если в некоторых отношениях обнаружена зависимость атрибутов от части сложного ключа, то проводим декомпозицию этих отношений на несколько отношений следующим образом: те атрибуты, которые зависят от части сложного ключа выносятся в отдельное отношение вместе с этой частью ключа. В исходном отношении остаются все ключевые атрибуты: Исходное отношение: . R (K1, K2, A1,... AN, B1, ... BM)Ключ: { K1, K2 }- сложный. Функциональные зависимости: { K1, K2 } { A1,... AN, B1, ... BM } - зависимость всех атрибутов от ключа отношения. { K1 } { A1,... AN}- зависимость некоторых атрибутов от части сложного ключа. Декомпозированные отношения: R1 (K1, K2, B1, ... BM)- остаток от исходного отношения. Ключ { K1, K2 }

R1 (K1, A1,... AN} атрибуты, вынесенные из исходного отношения вместе с частью сложного ключа. Ключ . { K1 }

Шаг 3 (Приведение к 3НФ). Если в некоторых отношениях обнаружена зависимость некоторых неключевых атрибутов от других неключевых атрибутов, то проводим декомпозицию этих отношений следующим образом: те неключевые атрибуты, которые зависят других неключевых атрибутов выносятся в отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости: Исходное отношение: . R (K, A1,... AN, B1, ... BM)Ключ: K . Функциональные зависимости: K { A1,... AN, B1, ... BM }- зависимость всех атрибутов от ключа отношения. {A1,... AN } {B1, ... BM }- зависимость некоторых неключевых атрибутов других неключевых атрибутов.

Декомпозированные отношения: R1 (K, A1,... AN) - остаток от исходного отношения. Ключ K.R2 (A1,... AN, B1, ... BM) - атрибуты, вынесенные из исходного отношения вместе с детерминантом функциональной зависимости. Ключ { A1,... AN }.

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

НФБК (Нормальная Форма Бойса-Кодда)При приведении отношений при помощи алгоритма нормализации к отношениям в 3НФ неявно предполагалось, что все отношения содержат один потенциальный ключ. Это не всегда верно. Рассмотрим следующий пример отношения, содержащего два ключа. Пример 1. Пусть требуется хранить данные о поставках деталей некоторыми поставщиками. Предположим, что наименования поставщиков являются уникальными. Кроме того, каждый поставщик имеет свой уникальный номер. Данные о поставках можно хранить в следующем отношении:

Отношение "Поставки" :

НомерпоставщикаPNUM

НаименованиепоставщикаPNAME

НомердеталиDNUM

Поставляемоеколичество VOLUME

1 Фирма 1 1 1001 Фирма 1 2 2001 Фирма 1 3 3002 Фирма 2 1 1502 Фирма 2 2 2503 Фирма 3 1 1000

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

PNAME PNUM - номер поставщика зависит от наименования поставщика. {PNUM, DNUM} VOLUME - поставляемое количество зависит от первого ключа отношения. {PNUM, DNUM} PNAME - наименование поставщика зависит от первого ключа отношения. {PNAME, DNUM} VOLUME - поставляемое количество зависит от второго ключа отношения. {PNAME, DNUM} PNUM - номер поставщика зависит от второго ключа отношения. Данное отношение не содержит не ключевых атрибутов, зависящих от части сложного ключа (см. определение 2НФ). Действительно, от части сложного ключа зависят атрибуты PNAME и PNUM, но они сами являются ключевыми. Таким образом, отношение находится в 2НФ. Кроме того, отношение не содержит зависимых друг от друга не ключевых атрибутов, т.к. не ключевой атрибут всего один - VOLUME - отношение "Поставки" находится в 3НФ.

Т.е. алгоритм нормализации до ЗНФ неприменим к данному отношению. Очевидно, однако, что аномалия данного отношения устраняется путем декомпозиции его на два следующих отношения: Отношение "Поставщики" Номер поставщикаPNUM

Наименованиепоставщика PNAME

1 Фирма 12 Фирма 23 Фирма 3

Отношение "Поставки-2"Номер поставщикаPNUM

Номер деталиDNUM

Поставляемоеколичество VOLUME

1 1 1001 2 2001 3 3002 1 1502 2 2503 1 1000

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

Хотя отношение "Поставщики" имеет два потенциальных ключа, но, т.к. других атрибутов в нем нет, упростить его дальше нельзя.Вопрос: как быть с случае независимости потенциальных ключей? Пример. Предположим, что нам по-прежнему необходимо учитывать поставки, но каждый акт поставки должен иметь некоторый уникальный номер (назовем его «номер договора поставки"). Отношение может иметь следующий вид: Отношение "Поставки-с-номером" НомерпоставщикаPNUM

НомердеталиDNUM

ПоставляемоеколичествоVOLUME

Номер договорапоставки NN

1 1 100 11 2 200 21 3 300 32 1 150 42 2 250 53 1 1000 6

Одним потенциальным ключом данного отношения является, как и раньше, пара атрибутов {PNUM, DNUM}. Другим ключом, в силу уникальности сквозного номера, является атрибут NN.Зависимость атрибутов от первого ключа отношения: {PNUM, DNUM} VOLUME, {PNUM, DNUM} NN, Зависимость атрибутов от второго ключа отношения: NN PNUM, NN DNUM, NN VOLUME, Зависимости, являющиеся следствием зависимостей от ключей отношения: {PNUM, DNUM} {VOLUME, NN}, NN {PNUM, DNUM}, NN {PNUM, VOLUME}, NN {DNUM, VOLUME}, NN {PNUM, DNUM, VOLUME}.

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

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

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