Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Проектирование моделей данных. Учебное пособие
.pdf
21
2. Номер кабинета.
3. Назначение кабинета.
4. ФИО сотрудника, который принимает пациента.
5. Должность сотрудника.
6. Дата приема пациента сотрудником.
Пусть заданы следующие ограничения, накладываемые на
предметную область:
1. Среди пациентов нет полных тезок, то есть пациентов с
одинаковыми фамилией, именем и отчеством.
2. В одном кабинете могут принимать несколько врачей, но врач
принимает только в одном кабинете.
3. Среди сотрудников нет полных тезок.
4. Сотрудник может занимать только одну должность.
5. Сотрудник не может одновременно принимать несколько
пациентов.
Метод нормальных форм предполагает, что вся информация о
предметной области первоначально хранится в одном отношении
(рисунок 27).
Рисунок 27 – Одно отношение для «Медицинского центра»
В качестве первичного ключа отношения выберем
PK={ФИО Пациента, ФИО Сотрудника, Дата}
Данные в отношении «Запись на прием» хранятся с
избыточностью. Повторяются номера кабинетов для приема,
должности для сотрудников.
При работе с отношениями, содержащими избыточные данные,
возникают проблемы, которые называются аномалиями модификации.
Поскольку аномалии проявляются при выполнении операций,
изменяющих состояние БД, то различают следующие виды аномалий:
• аномалия вставки;
22
• аномалия удаления;
• аномалия обновления.
В рассматриваемом примере аномалии модификации
проявляются следующим образом:
1. Аномалия вставки.
В отношение нельзя вставить информацию о пациенте, который
только прикрепился к медицинскому центру и ещё не записался на
прием, или о сотруднике, который на данный момент не принимает ни
одного пациента.
Иначе придется присвоить большинству атрибутов NULL-
значения, в том числе и атрибутам, входящим в первичный ключ. А
это противоречит правилу целостности сущностей.
2. Аномалия удаления.
При увольнении сотрудника, если в кабинете не принимали
другие врачи, данные о кабинете теряются.
3. Аномалия обновления.
Если изменится должность сотрудника, то такое изменение
необходимо будет выполнить во всех кортежах, где записана эта
информация.
Причины аномалий – избыточность данных, порожденная тем,
что в отношении хранится разнородная информация. Устранить
аномалии можно, выполнив нормализацию отношения.
4.3.2. Нормализация отношений
Нормализация – это формальный метод анализа отношений на
основе первичных или потенциальных ключей и существующих
зависимостей между атрибутами.
Процесс нормализации заключается в последовательном
переводе отношений из первой нормальной формы (1НФ) в
нормальные формы более высокого порядка по определенным
правилам. Каждой нормальной форме соответствует определенный
набор ограничений, и отношение находится в некоторой НФ, если
удовлетворяет свойственному ей набору ограничений [2].
Выделяют следующую последовательность НФ:
1НФ, 2НФ, 3НФ, БКНФ (НФ Бойса – Кодда), 4НФ, 5НФ,
проекционно-соединительная НФ, ДКНФ (доменно-ключевая НФ).
Каждая НФ сохраняет свойства предшествующих НФ.
Переход к более высокой НФ выполняется путем декомпозиции
исходного отношения на два или более отношения, которые
удовлетворяют требованиям этой НФ.
23
До перехода к этапу разработки схемы базы данных полученные
отношения должны быть проверены на соответствие нормальным
формам не ниже БКНФ (нормальная форма Бойса - Кодда).
Основные определения.
1НФ. Отношение находится в 1НФ, если все значения
отношения являются атомарными (неделимыми), то есть ни один из
его атрибутов нельзя разделить на более простые атрибуты, которые
соответствуют каким-то другим свойствам описываемой сущности.
Определение 1НФ предполагает, что ячейки таблицы должны
содержать одиночные значения и все записи в отдельном столбце
таблицы (атрибуте) должны иметь один и тот же тип, в качестве
значений атрибута таблицы не допускаются группы данных.
Определение более высоких НФ основано на понятии
функциональной зависимости (ФЗ).
Определение ФЗ.
Пусть R отношение, а X, Y – произвольные атрибуты или
множества атрибутов отношения R. Х функционально определяет Y,
что записывается X→Y (или Y функционально зависит от Х), если
одному значению Х соответствует ровно одно значение Y. Обратное
не обязательно.
Х называется детерминантом ФЗ, Y – зависимой частью.
Приведем примеры функциональной зависимости для данной
предметной области:
ФИО Сотрудника → Должность;
{ФИО Пациента, ФИО Сотрудника, Дата} → Стоимость.
ФЗ называется полной, если Y не зависит от любого
собственного подмножества Х (собственное подмножество
представляет собой множество атрибутов, не совпадающее с
множеством всех атрибутов).
Если детерминант представляет собой один атрибут, то ФЗ
автоматически является полной.
Приведем пример полной функциональной зависимости:
{ФИО Пациента, ФИО Сотрудника, Дата} → Стоимость.
Зависимость является полной, так как атрибут Стоимость не
зависит отдельно ни от одной части Детерминанта: ФИО Пациента,
ФИО Сотрудника, Дата.
Определение транзитивной ФЗ.
ФЗ X→Y называется транзитивной, если есть такой атрибут Z,
что существуют следующие ФЗ: X→Z, Z→Y, и отсутствует ФЗ Z→X.
Тогда говорят, что Y транзитивно зависит от Х или Х транзитивно
определяет Y.
24
ФИО Сотрудника Номер Кабинета
Назначение
Х
Z
Y
Обычно транзитивные зависимости изображаются следующим
образом (рисунок 28).
Рисунок 28 – Схема транзитивной зависимости
Пример транзитивной зависимости представлен на рисунке 29.
Рисунок 29 – Пример транзитивной зависимости
Причем в отношении нет зависимости
Назначение → ФИО Сотрудника.
Неключевым атрибутом называется любой атрибут отношения,
не входящий в состав любого потенциального ключа.
Атрибуты называются взаимно независимыми, если ни один из
них не является функционально зависимым от другого.
2НФ. Отношение находится в 2НФ, если оно находится в 1НФ и
каждый неключевой атрибут функционально полно зависит от любого
потенциального ключа (в частности, первичного).
Рассмотрим алгоритм приведения к 2НФ на примере
предметной области «Медицинский центр».
Шаг 1. Выпишем все имеющиеся в отношении ФЗ.
• ФИО Сотрудника → Должность;
• {ФИО Пациента, ФИО Сотрудника, Дата} → Стоимость;
• ФИО Сотрудника → Номер Кабинета → Назначение.
Шаг 2. Если в отношении существует зависимость неключевых
атрибутов от части составного ключа, то проводим декомпозицию
отношения на несколько отношений следующим образом: те атрибуты,
которые зависят от части составного ключа, выносим в отдельное
отношение вместе с этой частью ключа. В новом отношении
первичным ключом (ПК) становится детерминант ФЗ. В исходном
отношении остаются все ключевые атрибуты.
Согласно алгоритму будут получены следующие отношения:
• Сотрудники (ФИО Сотрудника, Должность, Номер кабинета,
Назначение);
25
• Прием (ФИО Пациента, ФИО Сотрудника, Дата, Стоимость).
3НФ. Отношение находится в 3НФ, если оно находится в 2НФ и
если в нём нет транзитивных зависимостей неключевых атрибутов от
любого потенциального ключа (в частности, первичного).
Отношение Прием находится в 3НФ, так как в нем нет
транзитивных зависимостей. Но в отношении Сотрудники есть
транзитивная зависимость, изображенная на рисунке 30.
Алгоритм приведения к 3НФ.
Если в отношении обнаружена транзитивная зависимость, то
проводится декомпозиция отношения следующим образом: те
неключевые атрибуты, которые зависят от других неключевых
атрибутов, выносятся в отдельное отношение. ПК в новом отношении
становится детерминант ФЗ. Детерминант ФЗ также остается в
исходном отношении.
Согласно алгоритму декомпозируем отношение Сотрудники на
два следующих отношения:
• Сотрудники (ФИО Сотрудника, Должность, Номер кабинета);
• Кабинет (Номер кабинета, Назначение).
БКНФ. Отношение находится в БКНФ, если оно находится в
3НФ и если детерминанты всех функциональных зависимостей
являются потенциальными ключами. БКНФ часто называют
усиленной 3НФ.
При приведении отношений к 3НФ неявно предполагалось, что
все отношения содержат один потенциальный ключ, который
принимался в качестве ПК. Дополним отношение Прием атрибутом
Страховой номер. Тогда отношение будет содержать 2 потенциальных
ключа:
PK1 = {ФИО Пациента, ФИО Сотрудника, Дата};
PK2 = {Страховой номер, ФИО Сотрудника, Дата}.
В отношении можно выявить следующие ФЗ:
Страховой номер → ФИО Пациента;
ФИО Пациента → Страховой номер;
{ФИО Пациента, ФИО Сотрудника, Дата} → Стоимость;
{Страховой номер, ФИО Сотрудника, Дата} → Стоимость.
Атрибуты Страховой номер и ФИО Пациента являются частью
составных потенциальных ключей, и, следовательно, отношение
Прием не находится в БКНФ.
Алгоритм приведения к БКНФ.
Атрибуты, которые зависят от детерминантов, не являющихся
потенциальными ключами, выносятся вместе с детерминантами в
отдельное отношение. В новом отношении ключом становится
26
детерминант ФЗ. Детерминант ФЗ также остается в исходном
отношении.
В зависимости от того, какой из потенциальных ключей
назначается первичным ключом, можем получить два различных
варианта:
1-й вариант. В качестве первичного ключа принимаем PK1 =
= {ФИО Пациента, ФИО Сотрудника, Дата}. Тогда декомпозиция
отношений будет следующая:
Пациенты (ФИО Пациента, Страховой номер);
Прием (ФИО Пациента, ФИО Сотрудника, Дата, Стоимость).
2-й вариант. В качестве первичного ключа принимаем PK2 =
= {Страховой номер, ФИО Сотрудника, Дата}. Тогда декомпозиция
отношений будет следующая:
Пациенты (Страховой номер, ФИО Пациента);
Прием (Страховой номер, ФИО Сотрудника, Дата, Стоимость).
Обе декомпозиции являются равноправными с точки зрения
реляционной модели данных.
Схема полученной БД представлена на рисунке 30.
Рисунок 30 – Схема БД, спроектированной методом НФ
4.3.3. Выполнение проверки предварительных отношений
на соответствие нормальным формам
В рамках проектирования ER-методом после формирования
предварительных отношений проводится этап проверки на
соответствие нормальным формам. Обычно на данном этапе
графически изображают функциональные зависимости атрибутов для
каждого отношения в отдельности. Причем ключевые атрибуты
изображаются прямоугольниками, а неключевые – овалами или
прямоугольниками с закругленными углами. Для каждого отношения
указывается нормальная форма, в которой оно находится. Причем для
каждой НФ приводится пояснение. Если атрибут зависит от группы
27
атрибутов, то используется следующее обозначение функциональных
зависимостей (рисунок 31).
Рисунок 31 – Обозначение составного первичного ключа
Выполним проверку отношений на соответствие нормальным
формам до БКНФ для предварительных отношений области
«Медицинский центр»:
1. Пациент (№полиса, Фамилия, Имя, Отчество, Дата рождения,
Пол, Адрес, Телефон, e-mail) (рисунок 32).
Отношение «Пациент» находится в 1НФ, так как все значения
отношения являются атомарными. Отношение находится в 2НФ, так
как оно находится в 1НФ и первичный ключ является простым.
Отношение находится в 3НФ, так как оно находится в 2НФ и в нём нет
транзитивных зависимостей. Отношение находится в БКНФ, так как
оно находится в 3НФ и содержит один потенциальный ключ,
являющийся детерминантом всех ФЗ.
Рисунок 32 – Отношение «Пациент»
28
2. Сотрудник (№паспорта, Фамилия, Имя, Отчество, Дата
рождения, Пол, Адрес, Образование, №ТрудовойКнижки,
IDДолжность, Телефон, e-mail) (рисунок 33).
Отношение «Сотрудник» находится в 1НФ, так как все значения
отношения являются атомарными. Отношение находится в 2НФ, так
как оно находится в 1НФ и оба потенциальных ключа являются
простыми. Отношение находится в 3НФ, так как оно находится в 2НФ
и в нём нет транзитивных зависимостей. Отношение находится в
БКНФ, так как оно находится в 3НФ и детерминанты всех
функциональных зависимостей являются потенциальными ключами.
Рисунок 33 – Отношение «Сотрудник»
3. Должность (IDДолжность, Название, Тип, Описание)
(рисунок 34).
Отношение «Должность» находится в 1НФ, так как все значения
отношения являются атомарными. Отношение находится в 2НФ, так
как оно находится в 1НФ и первичный ключ является простым.
Отношение находится в 3НФ, так как оно находится в 2НФ и в нём нет
транзитивных зависимостей. Отношение находится в БКНФ, так как
29
оно находится в 3НФ и содержит один потенциальный ключ,
являющийся детерминантом всех ФЗ.
Рисунок 34 – Отношение «Должность»
4. Кабинет (№кабинета, Название, Тип) (рисунок 35).
Отношение «Кабинет» находится в 1НФ, так как все значения
отношения являются атомарными. Отношение находится в 2НФ, так
как оно находится в 1НФ и первичный ключ является простым.
Отношение находится в 3НФ, так как оно находится в 2НФ и в нём нет
транзитивных зависимостей. Отношение находится в БКНФ, так как
оно находится в 3НФ и содержит один потенциальный ключ,
являющийся детерминантом всех ФЗ.
Рисунок 35 – Отношение «Кабинет»
5. Услуги (IDУслуги, Название, Описание, IDТип, Цена)
(рисунок 36).
Отношение «Услуги» находится в 1НФ, так как все значения
отношения являются атомарными. Отношение находится в 2НФ, так
как оно находится в 1НФ и первичный ключ является простым.
Отношение находится в 3НФ, так как оно находится в 2НФ и в нём нет
транзитивных зависимостей. Отношение находится в БКНФ, так как
оно находится в 3НФ и содержит один потенциальный ключ,
являющийся детерминантом всех ФЗ.
30
Рисунок 36 – Отношение «Услуги»
6. ТипУслуги (IDТип, Название, Описание) (рисунок 37).
Отношение «ТипУслуги» находится в 1НФ, так как все
значения отношения являются атомарными. Отношение находится в
2НФ, так как оно находится в 1НФ и первичный ключ является
простым. Отношение находится в 3НФ, так как оно находится в 2НФ и
в нём нет транзитивных зависимостей. Отношение находится в БКНФ,
так как оно находится в 3НФ и содержит один потенциальный ключ,
являющийся детерминантом всех ФЗ.
Рисунок 37– Отношение «ТипУслуги»
7. Диагноз (IDДиагноз, Название, Симптомы) (рисунок 38).
Отношение «Диагноз» находится в 1НФ, так как все значения
отношения являются атомарными. Отношение находится в 2НФ, так
как оно находится в 1НФ и первичный ключ является простым.
Отношение находится в 3НФ, так как оно находится в 2НФ и в нём нет
транзитивных зависимостей. Отношение находится в БКНФ, так как
оно находится в 3НФ и содержит один потенциальный ключ,
являющийся детерминантом всех ФЗ.
Рисунок 38 – Отношение «Диагноз»
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]