ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Базы данных
Добавлен: 28.11.2018
Просмотров: 5441
Скачиваний: 10
56
Таблица
3.3. «
Назначение
1»
№
работника
№
здания
Дата
начала
Фамилия
1235 312
10.10
Петров
1412 312
01.10
Смирнов
1235 515
17.10
Петров
1412 460
08.12
Смирнов
1412 435
15.10
Смирнов
Для
того
чтобы
решить
эти
проблемы
,
таблицу
необхо
-
димо
разбить
на
две
реляционные
таблицы
,
каждая
из
ко
-
торых
удовлетворяет
2
НФ
.
Таблица
3.4. «
Работник
»
№
работ
-
ника
Фамилия
1235
Петров
1412
Смирнов
Таблица
3.5. «
Назначение
»
№
работника
№
здания
Дата
начала
1235 312
10.10
1412 312
01.10
1235 515
17.10
1412 460
08.12
1412 435
15.10
Эти
две
реляционные
таблицы
находятся
во
2
НФ
и
ис
-
ключают
перечисленные
выше
проблемы
.
Таким
образом
,
2
НФ
сокращает
избыточность
данных
и
возможность
ано
-
малий
.
Процесс
разбиения
на
две
2
НФ
-
таблицы
состоит
из
не
-
скольких
простых
шагов
:
1.
Создается
новая
таблица
,
атрибутами
которой
будут
атрибуты
исходной
таблицы
,
входящие
в
противоречащую
правилу
ФЗ
.
Детерминант
ФЗ
становится
ключом
новой
таб
-
лицы
.
57
2.
Атрибут
,
стоящий
в
правой
части
ФЗ
,
исключается
из
исходной
таблицы
.
3.
Если
более
одной
ФЗ
нарушают
2
НФ
,
то
шаги
1
и
2
повторяются
для
каждой
такой
ФЗ
.
4.
Если
один
и
тот
же
детерминант
входит
в
несколько
ФЗ
,
то
все
функционально
зависящие
от
него
атрибуты
по
-
мещаются
в
качестве
неключевых
атрибутов
в
таблицу
,
ключом
которой
будет
детерминант
.
3.4.
Третья
нормальная
форма
Реляционная
таблица
удовлетворяет
третьей
нормаль
-
ной
форме
3
НФ
,
если
она
находится
в
2
НФ
и
в
ней
нет
транзитивных
зависимостей
.
Транзитивная
зависимость
возникает
,
если
неключевой
атрибут
функционально
зависит
от
одного
или
более
неключевых
атрибутов
.
В
данном
примере
мы
привели
таблицу
3.6,
содержащую
цепочку
транзитивных
зависимостей
,
к
паре
таблиц
3.7
и
3.8,
находящихся
в
3
НФ
.
Для
таблицы
3.6.
действительны
следующие
ограничения
предметной
области
:
1)
каждый
работник
имеет
только
одного
менеджера
;
2)
один
менджер
может
руководить
несколькими
рабочими
.
Таблица
3.6
№
работника
Фамилия
работника
№
менедже
-
ра
Фамилия
менеджера
1235
Иванов
1311
Сергеев
1412
Петров
1311
Сергеев
1311
Сидоров
1312
Попов
Таблица
3.7
№
работника
Фамилия
№
менеджера
1235
Иванов
1311
1412
Петров
1311
1311
Сидоров
1312
Таблица
3.8
№
менеджера
Фамилия
менеджера
1311
Сергеев
1312
Попов
58
3.5.
Нормальная
форма
Бойса
-
Кодда
(
НФБК
)
Реляционная
таблица
находится
в
нормальной
форме
Бойса
-
Кодда
(
НФБК
),
если
для
любой
ФЗ
: X
⎯>
Y, X (
то
есть
детерминанта
)
является
возможным
ключом
отношения
.
Из
определения
следует
,
что
любая
таблица
,
удовлетво
-
ряющая
НФБК
,
также
удовлетворяет
и
2
НФ
,
однако
обрат
-
ное
неверно
.
Рассмотрим
таблицу
3.9 «
Оплата
за
работу
».
№
Работника
является
ключом
,
следовательно
,
в
таблице
имеются
функ
-
циональные
зависимости
:
ФЗ
:
№
Работника
⎯>
Разряд
;
ФЗ
:
№
Работника
⎯>
Оплата
.
Однако
также
имеется
функциональная
зависимость
ФЗ
:
Разряд
⎯>
Оплата
.
Атрибут
«
разряд
»
является
детерминантой
,
так
как
он
одно
-
значно
определяет
атрибут
«
оплата
»,
но
«
разряд
»
не
может
быть
ключом
отношения
,
поэтому
в
таком
виде
отношение
«
Оп
-
лата
за
работу
»
не
удовлетворяет
НБКФ
.
Но
таблица
3.9
удовлетворяет
2
НФ
(
так
как
неключевые
атрибуты
«
разряд
»
и
«
оплата
»).
Таким
образом
,
таблица
может
быть
в
2
НФ
,
но
не
в
НФБК
.
Таблица
3.9. «
Работник
»
№
работника
Разряд
Премиальные
1235 1
150
1412 2
120
1311 1
150
Чем
плохи
таблицы
,
не
удовлетворяющие
НФБК
?
Вы
-
званные
ими
проблемы
схожи
с
перечисленными
для
таб
-
лиц
,
нарушающих
2
НФ
:
1.
Размер
премиальных
для
типа
специальности
повторя
-
ется
в
каждой
строке
,
относящейся
к
работнику
этой
специ
-
альности
.
Это
избыточные
данные
,
занимающие
лишнее
ме
-
сто
.
2.
Если
размер
премиальных
для
типа
специальности
изменяется
,
то
требуется
обновить
каждую
строку
.
Если
строка
удаляется
,
то
мы
можем
потерять
информацию
о
размере
премиальных
для
данной
специальности
.
Таким
об
-
59
разом
,
таблица
подвержена
аномалиям
обновления
и
уда
-
ления
.
3.
Если
в
какой
-
то
момент
времени
отсутствуют
работни
-
ки
данной
специальности
,
то
может
не
оказаться
строки
,
в
которой
можно
хранить
размер
премиальных
.
Это
аномалия
ввода
.
Для
того
чтобы
решить
эти
проблемы
,
таблицу
необходи
-
мо
разбить
на
несколько
таблиц
для
устранения
аномалий
и
поддержания
целостности
данных
.
Создадим
новую
таблицу
3.10 «
Работник
1»,
удалив
из
таблицы
3.9
все
атрибуты
,
стоящие
в
правой
части
ФЗ
,
на
-
рушающие
критерий
НФБК
.
В
нашем
примере
это
Преми
-
альные
.
Создадим
новую
таблицу
3.11 «
Работник
2»,
со
-
стоящую
из
атрибутов
,
как
из
левой
,
так
и
из
правой
части
ФЗ
,
нарушающей
критерий
НФБК
.
В
нашем
примере
это
Специальность
и
Премиальные
.
Детерминант
ФЗ
Специ
-
альность
будет
ключом
.
Таблица
3.10. «
Работник
1»
№
работника
Специальность
1235
Электрик
1412
Штукатур
1311
Электрик
Таблица
3.11. «
Работник
2»
Специальность
Премиальные
Электрик
150
Штукатур
120
Электрик
150
Мы
разбили
таблицу
3.9 «
Работник
»
на
таблицы
3.10
и
3.11,
каждая
из
которых
удовлетворяет
НФБК
.
60
3.6.
Нормализация
−
за
и
против
Нормализация
таблиц
БД
призвана
устранить
из
них
избы
-
точную
информацию
.
Как
видно
из
приведенных
выше
приме
-
ров
,
таблицы
нормализованной
БД
содержат
только
один
эле
-
мент
избыточных
данных
-
это
поля
связи
,
присутствующие
од
-
новременно
у
родительской
и
дочерних
таблиц
.
Поскольку
из
-
быточные
данные
в
таблицах
не
хранятся
,
экономится
дисковое
пространство
.
ТОВАРЫ
ПОКУПАТЕЛИ
Товар
Ед_изм
Цен_за_ед_изм
Покупатель
Город
Адрес
НАКЛАДНЫЕ
Номер_накладной
Дата
Покупатель (FK)
ОТПУСК-ТОВАРОВ-СО-СКЛАДА
Товар (FK)
Номер_накладной (FK)
Отпущено_ед
Рис
.3.20.
Нормализованная
база
данных
Однако
у
нормализованной
БД
есть
и
недостатки
,
прежде
всего
практического
характера
.
Чем
шире
число
сущностей
,
ох
-
ватываемых
предметной
областью
,
тем
из
большего
числа
таб
-
лиц
будет
состоять
нормализованная
БД
.
Базы
данных
в
соста
-
ве
больших
систем
,
управляющих
жизнедеятельностью
крупных