90. Нормализованные отношения. Первичные и вторичные ключи отношений. Моделирование связей в реляционной модели данных. Внешние ключи.

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

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

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

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

Первая нормальная форма.

Определение. Отношение R находится в 1НФ тогда и только тогда, когда все входящие в него значения (домены) содержат только атомарные значения.

Это значит, что любое нормализованное отношение находится в 1 НФ.

Вторая нормальная форма.

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

STUD (Ns, Flo, Ngr,Addr, Tel, Np, Ball)

Отношение STUD находится в 1НФ. Но атрибуты Flo, Ngr, Addr, Tel нe находятся в полной функциональной зависимости от ключа отношения, так как они функционально зависят от части ключа - Ns. Это приводит к следующей нежелательной ситуации. Во-первых, имеет место дублирование информации. Во-вторых, информация о студенте появится только тогда, когда он получит оценку хотя бы по одному предмету.

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

Чтобы отношение STUD привести ко 2НФ, необходимо:

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

В нашем случае отношение STUD преобразуется последовательно в отношение S_P и в отношение S. Отношения S, S_P находятся во 2НФ.

Третья нормальная форма.

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

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

S(Ns, Flo, Ngr, Addr, Tel),   Spec_S(Ngr, Spec).

Отношение в ЗНФ называют отношением в нормальной форме Бойса-Кодда (НФБК), если в нем отсутствуют зависимости ключей от неключевых атрибутов.

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

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

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

Четвертая нормальная форма.

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

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

Рассмотрим отношение R(Pred,Prep,Uch), где Pred - предмет, Prep - преподаватель, Uch - учебник. Семантика данных следующая:

* данному предмету может соответствовать любое количество преподавателей и любое количество учебников; * преподаватели и учебники не зависят друг от друга.

В отношении R атрибут Pred многозначно определяет атрибут Prep; атрибут Uch многозначно зависит от Pred, причем эти завивисимости не являются функциональными.

Проекции Rl (Pred, Prep) и R2 (Pred, Uch) не содержат таких зависимостей, поэтому отношения R1, R2 представляют собой улучшение по сравнению с первоначальным отношением R.

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

Ключи отношений.

На пальцах. Пусть есть две таблицы — Отделы и Сотрудники. Предполагается, что сотрудник работает в одном и только в одном отделе. У отделов есть колонка КодОтдела, уникально определяющий отдел. Так что первичный ключ для таблицы Отделы будет состоять из одной колонки: PK(КодОтдела). Аналогично, в таблице сотрудников есть КодСотрудника. Так что первичный ключ для таблицы Сотрудники будет PK(КодСотрудника)

Теперь связь. В таблице Сотрудники есть колонка КодОтдела, определяющая, в каком отделе работает сотрудник. Ограничение внешнего ключа (FOREIGN KEY CONSTRAINT) позволяет гарантировать (СУБД следит), что код указанный в колонке КодОтдела таблицы Сотрудники всегдя является одним из значений первичного ключа таблицы Отделы. Т.е. что нельзя записать в КодОтдела Иванова значение 123456, если нет отдела 123456. Можно сказать, что таблица Сотрудники своей колонкой КодОтдела ссылается на таблицу Отделов, а внешний ключ гарантирует валидность этой связи.

Перви́чный ключ (англ. primary key) — в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).

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

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

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

Внешний ключ (вторичный ключ) -атрибут реляционной таблицы являющийся ссылкой назначения главного ключа другой таблицы.

Реляционная модель данных включает следующие компоненты:

• Структурный аспект (составляющая) — данные в базе данных представляют собой набор отношений.

• Аспект (составляющая) целостности — отношения (таблицы) отвечают определенным условиям целостности. РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.

• Аспект (составляющая) обработки (манипулирования) — РМД поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

Кроме того, в состав реляционной модели данных включают теорию нормализации.

Термин «реляционный» означает, что теория основана на математическом понятии отношение (relation). В качестве неформального синонима термину «отношение» часто встречается слово таблица. Необходимо помнить, что «таблица» есть понятие нестрогое и неформальное и часто означает не «отношение» как абстрактное понятие, а визуальное представление отношения на бумаге или экране. Некорректное и нестрогое использование термина «таблица» вместо термина «отношение» нередко приводит к недопониманию. Наиболее частая ошибка состоит в рассуждениях о том, что РМД имеет дело с «плоскими», или «двумерными» таблицами, тогда как таковыми могут быть только визуальные представления таблиц. Отношения же являются абстракциями, и не могут быть ни «плоскими», ни «неплоскими».

Для лучшего понимания РМД следует отметить три важных обстоятельства:

• модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами;

• для реляционных баз данных верен информационный принцип: всё информационное наполнение базы данных представлено одним и только одним способом, а именно — явным заданием значений атрибутов в кортежах отношений; в частности, нет никаких указателей (адресов), связывающих одно значение с другим;

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

Наиболее известными альтернативами реляционной модели являются иерархическая модель, и сетевая модель. Некоторые системы, использующие эти старые архитектуры, используются до сих пор. Кроме того, можно упомянуть об объектно-ориентированной модели, на которой строятся так называемые объектно-ориентированные СУБД, хотя однозначного и общепринятого определения такой модели нет.