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

Реляционный подход предложен в 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 UD2 U ... Dn Всякий экземпляр отношения R{A1, A2,... , An} есть подмножество D и называется кортежем отношения

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

Код_идентиф Ф_И_О Лектор Учен_звание Учен_степень Читает Код_курса Предмет Название Кол_часов Концептуальная модель

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

Лектор Предмет Читает Реляционные отношения

ФИО Работник ТАБ_№ Квалификация Изготавливает Деталь Код_дет Название_детали Входит ИЗДЕЛИЕ Название_изд Код_изд

РАБОЧИЙ(Таб_№,ФИО,Квалификация) ИЗГОТАВЛИВАЕТ(Таб_№,Код_дет) ДЕТАЛЬ(Код_дет,Название_дет) ВХОДИТ(Код_изд,Код_дет) ИЗДЕЛИЕ(Код_изд,Назв_изд) Таб_№={01,02,03,04} ФИО={возможные фамилии и инициалы} Квалификация={Положительное целое число} Код_изд={И1,И2,И3,И4} Назв_изд={Иа,Ив,Ис,Ид} Код_дет={Д1,Д2,Д3} Назв_дет={Да,Дв,Дс}

РАБОЧИЙ ИЗГОТАВЛИВАЕТ ДЕТАЛЬ ИЗДЕЛИЕ ВХОДИТ Реляционные отношения

Целостность базы данных Поддержание БД в непротиворечивом сотоянии предполагает: 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->B r После сортировки по А имеем

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

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

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

2НФ (Вторая Нормальная Форма) Определение . Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет неключевых атрибутов, зависящих от части сложного ключа. (Неключевой атрибут - это атрибут, не входящий в состав никакого потенциального ключа). Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 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льного номера сотрудника: Н_СОТРФАМ Н_СОТРН_ОТД Н_СОТРТЕЛ

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

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

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

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

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

Одним потенциальным ключом данного отношения является, как и раньше, пара атрибутов {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}.

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

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