Лекции ПрБД, 2 курс 3 семестр (для ИВТ и т.п.) / Проектирование БД_уч пособие v02

−первая нормальная форма (1НФ);

−вторая нормальная форма (2 НФ);

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

−нормальная форма Бойса-Кодда (БКНФ);

−четвертая нормальная форма (4 НФ);

−пятая нормальная форма, или нормальная форма проекциисоединения (5 НФ).

Набольшую практическую значимость имеют первые три нормальные формы. Аномалии более высоких форм не оказывают существенного влияние на результаты обработки отношений и встречаются редко [24].

Основные свойства нормальных форм:

−каждая следующая нормальная форма в некотором смысле лучше предыдущей;

−при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

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

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

Пусть R – переменная отношения, A, B – произвольные подмножества множества всех атрибутов R. A→B, то есть B функционально зависит от A тогда и только тогда, когда для любого допустимого значения R каждое значение A связано только с одним значением B.

Это означает, что во всех кортежах с одинаковым значением атрибута A атрибут B будет иметь одно и то же значение. Отметим, что A и B могут быть составными – состоять из двух и более атрибутов. Говорится: «A функционально определяет B» или «B функционально зависит от A».

101

Левая часть выражения называется детерминантом (детерминантой) функциональной зависимости (ФЗ), правая – зависимой частью ФЗ.

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

В нашем примере нельзя, например, использовать атрибут ФИО, состоящий из фамилии, имени и отчества. Понятие атомарности является условным: будем считать значение атомарным, если оно не используется по частям.

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

Рассмотрим следующий пример схемы отношения: СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР,

СОТР_ЗАДАН)

Первичный ключ: СОТР_НОМЕР, ПРО_НОМЕР Функциональные зависимости:

СОТР_НОМЕР → СОТР_ЗАРП СОТР_НОМЕР → ОТД_НОМЕР ОТД_НОМЕР → СОТР_ЗАРП

СОТР_НОМЕР, ПРО_НОМЕР → СОТР_ЗАДАН Как видно, хотя первичным ключом является составной атрибут

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

102

Отношение находится во второй нормальной форме (2НФ)

2НФ

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

Можно произвести следующую декомпозицию отношения СО- ТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:

СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)

Первичный ключ: СОТР_НОМЕР Функциональные зависимости: СОТР_НОМЕР → СОТР_ЗАРП СОТР_НОМЕР → ОТД_НОМЕР ОТД_НОМЕР → СОТР_ЗАРП

СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Первичный ключ: СОТР_НОМЕР, ПРО_НОМЕР Функциональные зависимости:

СОТР_НОМЕР, ПРО_НОМЕР → CОТР_ЗАДАН

Каждое из этих двух отношений находится в 2НФ, и в них устранены отмеченные аномалии.

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

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

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

103

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

Отношение R находится в третьей нормальной форме

3НФ

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

Можно произвести декомпозицию отношения СОТРУДНИКИОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:

СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР) Первичный ключ: СОТР_НОМЕР Функциональные зависимости:

СОТР_НОМЕР → ОТД_НОМЕР ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП) Первичный ключ: ОТД_НОМЕР Функциональные зависимости: ОТД_НОМЕР → СОТР_ЗАРП

Каждое из этих двух отношений находится в 3НФ и свободно от отмеченных аномалий.

Нормальная форма Бойса-Кодда

Рассмотрим следующий пример схемы отношения: СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ,

ПРО_НОМЕР, СОТР_ЗАДАН) Возможные ключи: СОТР_НОМЕР, ПРО_НОМЕР СОТР_ИМЯ, ПРО_НОМЕР Функциональные зависимости: СОТР_НОМЕР → CОТР_ИМЯ СОТР_НОМЕР → ПРО_НОМЕР

104

СОТР_ИМЯ → CОТР_НОМЕР СОТР_ИМЯ → ПРО_НОМЕР

СОТР_НОМЕР, ПРО_НОМЕР → CОТР_ЗАДАН

СОТР_ИМЯ, ПРО_НОМЕР → CОТР_ЗАДАН

В этом примере мы предполагаем, что личность сотрудника полностью определяется как его номером, так и именем.

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

СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ) Возможные ключи:

СОТР_НОМЕР СОТР_ИМЯ

Функциональные зависимости: СОТР_НОМЕР → CОТР_ИМЯ СОТР_ИМЯ → СОТР_НОМЕР

СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)

Возможный ключ: СОТР_НОМЕР, ПРО_НОМЕР Функциональные зависимости:

СОТР_НОМЕР, ПРО_НОМЕР → CОТР_ЗАДАН

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

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

Рассмотрим пример следующей схемы отношения: ПРОЕКТЫ (ПРО_НОМЕР,ПРО_СОТР, ПРО_ЗАДАН)

105

Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.

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

В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:

ПРО_НОМЕР →→ ПРО_СОТР ПРО_НОМЕР →→ ПРО_ЗАДАН

Отношение R находится в четвертой нормальной форме 4НФ (4NF) в том и только в том случае, если в случае существования многозначной зависимости A →→> B все

остальные атрибуты R функционально зависят от A.

В нашем примере можно произвести декомпозицию отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫЗАДАНИЯ:

ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР) ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)

Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий.

Пятая нормальная форма

Во всех рассмотренных до этого момента нормализациях производилась декомпозиция одного отношения в два. Иногда это сделать не удает-

106

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

Рассмотрим, например, отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР,

ОТД_НОМЕР, ПРО_НОМЕР)

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

Поэтому отношение находится в 4NF. Однако в нем могут существовать аномалии, которые можно устранить путем декомпозиции в три отношения.

Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.

Введем следующие имена составных атрибутов: СО = {СОТР_НОМЕР, ОТД_НОМЕР} СП = {СОТР_НОМЕР, ПРО_НОМЕР} ОП = {ОТД_НОМЕР, ПРО_НОМЕР}

Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ- ПРОЕКТЫ существует зависимость соединения:

* (СО, СП, ОП)

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

СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР) СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР) ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)

Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется. Зависимость соединения яв-

107

ляется обобщением как многозначной зависимости, так и функциональной зависимости.

Вопросы для самопроверки

1)С каким проблемами можно столкнуться при проектировании БД?

2)Перечислите существующие виды аномалий.

3)Что такое нормализация?

4)Сколько нормальных форм существует?

5)Что такое функциональная зависимость?

6)Дайте определение первой нормальной формы.

7)Дайте определение второй нормальной формы.

8)Дайте определение третьей нормальной формы.

9)Кратко охарактеризуйте нормальные формы высшего порядка.

8 Проектирование реляционных БД

с использованием семантических моделей: ER-диаграммы

Моделирование структуры БД при помощи алгоритма нормализации имеет серьезные ограничения [14]:

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

2)Невозможно сразу определить полный список атрибутов. Пользователи имеют привычку называть разными именами одни и те же вещи или наоборот, называть одними именами разные вещи.

3)Несмотря на то, что процесс проектирования начинается с выделения некоторых существенных для приложения объектов предметной области («сущностей») и выявления связей между этими сущностями, реляционная модель данных не предлагает какого-либо механизма для разделения сущностей и связей.

108

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

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

Семантическое моделирование чаще всего используется на начальной стадии проектирования БД. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования. Основным достоинством данного подхода является отсутствие потребности в дополнительных программных средствах, поддерживающих семантическое моделирование. Требуется только знание основ выбранной семантической модели и правил преобразования концептуальной схемы в реляционную схему.

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

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

109

В качестве одной из наиболее популярных семантических моделей данных выступает модель «Сущность – Связь» (часто используют краткий термин ER-модель от Entity-Relationship). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов.

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. Оригинальная работа Питера Чена (Peter Chen) «The Entity Relationship Model – Toward A Unified View of Data» («Модель сущность-связь – Унифицированное представление данных») обычно цитируется как основополагающая. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина (иногда называемая «Вороньими лапками» (Crow’s Foot)), нотация IDEF1X, нотация Баркера и др.). По сути, все варианты диаграмм сущность-связь исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями. Простота ER-модели делает ее доминирующим инструментом моделирования и проектирования баз данных [17].

Модели ER обычно представлены в диаграмме взаимосвязей объектов (ERD, Entity Relationship Diagram), которая использует графические представления для моделирования компонентов базы данных. Модель ER основана на следующих компонентах:

−Сущность – представлена в ERD прямоугольником. Имя сущности – существительное, написано в центре прямоугольника. Имя сущности обычно пишется заглавными буквами в именительном падеже и в единственном числе: СТУДЕНТ, а не СТУДЕНТЫ, и ПРЕПОДАВАТЕЛЬ,

ане ПРЕПОДАВАТЕЛИ. Обычно при применении ERD к реляционной модели сущность сопоставляется с таблицей. Каждая строка в реляционной таблице называется экземпляром сущности в модели ER.

−Атрибуты. Каждая сущность состоит из набора атрибутов, которые описывают конкретные свойства сущности. Например, сущность ПРЕПОДАВАТЕЛИ будет иметь такие атрибуты, как фамилия, имя, звание и пр.

−Связь – описывает отношение между данными. Большинство связей описывают ассоциации между двумя объектами. В реляционной модели используются три типа связи: один-ко-многим (1:M), много-ко-

110