ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Базы данных
Добавлен: 28.11.2018
Просмотров: 7745
Скачиваний: 53
86
Номер
ФИО Клиента Телефон
Дата
Товары
569
Петров И. С.
778899
14.05.2017 Стул – 15 шт.
Стол – 5 шт.
570
Иванов С. П.
445566
16.05.2017 Стул – 15 шт.
Стол – 3 шт.
571
Иванов С. П.
445566
19.05.2017 Стул – 11 шт.
Несмотря на то что визуально данная таблица достаточно удобно пред-
ставляет информацию, с точки зрения реляционной модели данных подобная
организация недопустима. Прежде всего, нарушено правило атомарности зна-
чений, ведь поле «Товары» содержит не только набор значений товаров, но и их
количество, указанное в этом же поле. Теоретически такую таблицу можно ор-
ганизовать в любой реляционной СУБД, просто создав текстовый атрибут «То-
вары» и занося в него подобные строки в ручном режиме. Однако в дальней-
шем очень сложно будет производить простейшие операции запросов,
например на вычисление общего количества проданных стульев за период и
т. п. Очевидно, что с точки зрения реляционной модели данная таблица должна
быть преобразована за счет разделения атрибута «Товары», а также путем до-
бавления новых строк для каждого товара в одном заказе. Полученная таблица
приведена ниже (табл. 4.5).
Таблица 4.5 – Заказы товаров в 1НФ
Номер
(ПК)
ФИО
Клиента
Телефон
Дата
заказа
Товар
(ПК)
Кол-во,
шт.
568
Иванов С. П.
445566
14.05.2017
Стул
10
568
Иванов С. П.
445566
14.05.2017
Стол
3
569
Петров И. С.
778899
14.05.2017
Стул
15
569
Петров И. С.
778899
14.05.2017
Стол
5
570
Иванов С. П.
445566
16.05.2017
Стул
15
570
Иванов С. П.
445566
16.05.2017
Стол
3
571
Иванов С. П.
445566
19.05.2017
Стул
11
Данная таблица очевидно аномально избыточна, ведь значения полей
«ФИО Клиента», «Телефон» и «Дата заказа» будут дублироваться для всех
строк одного заказа, однако соответствует требованиям реляционной модели, а
87
потому находится в 1НФ. Обратим внимание, что в новой таблице первичный
ключ является составным и включает 2 атрибута: «Номер» и «Товар». Очевид-
но, что простой ПК «Номер», ранее обозначавший номер каждого заказа, те-
перь не может быть использован, т. к. в новой структуре для него нарушается
правило уникальности. Один и тот же «старый» ПК теперь был бы у всех запи-
сей, в которых товаров перечислено было бы больше одного. Эта проблема бы-
ла решена путём добавления в состав ключа атрибута «Товар».
Важно отметить, что для каждой таблицы, подлежащей нормализации, на
данном этапе обязательно необходимо определить набор атрибутов, которые
будут составлять первичный ключ. Все атрибуты, не вошедшие в состав ПК,
будут называться неключевыми.
Вторая нормальная форма (2НФ)
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Таблица находится во второй нормальной форме (2НФ), ес-
ли она находится в 1НФ и её неключевые атрибуты полностью за-
висят от всего первичного ключа. Другими словами, в таблице не
должно быть неключевых атрибутов, которые зависят от части
первичного ключа.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Рассмотренная выше таблица 4.5 не находится в 2НФ, поскольку в ней
имеются атрибуты, которые зависят от части первичного ключа. Поля «ФИО
Клиента», «Телефон» и «Дата заказа» зависят от поля «Номер», которое являет-
ся только частью ПК, и не связаны с тем, сколько и каких товаров заказал кли-
ент. Поле «Кол-во» зависит от всех частей ПК одновременно, поскольку коли-
чество даже одного и того же товара в разных заказах может оказаться разным.
Для перевода таблицы из 1НФ в 2НФ необходимо воспользоваться сле-
дующим алгоритмом:
1. Определить все частичные зависимости, т. е. все части первичного
ключа и все неключевые атрибуты, которые от них зависят.
2. Для каждой части первичного ключа и набора неключевых атрибутов,
которые от них зависят, необходимо создать новую таблицу и скопи-
ровать эти данные в неё. В новой таблице бывшая часть первичного
ключа станет первичным ключом.
88
3. Из исходной таблицы необходимо удалить все скопированные неклю-
чевые атрибуты, при этом не удаляя части первичного ключа, которые
станут ещё и внешними ключами, связанными с новыми таблицами.
В нашем примере мы уже выделили зависимость некоторых неключевых
атрибутов от поля «Номер» и согласно алгоритму должны создать новую таб-
лицу для всей этой группы атрибутов вместе с частью первичного ключа.
В исходной таблице данную группу неключевых атрибутов необходимо
удалить, оставив только поле «Номер». Данный атрибут теперь также будет яв-
ляться и внешним ключом.
В результате приведения к 2НФ будет получено две таблицы, связанные
по атрибуту «Номер» (рис. 4.4).
Рис. 4.4 – Таблицы «Заказы» и «Заказы товаров» в 2НФ
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Любая реляционная таблица, у которой первичный ключ со-
стоит из одного атрибута или является простым, по умолчанию
Номер (ПК) ФИО Клиента Телефон
Дата
568
Иванов С. П.
445566
14.05.2017
569
Петров И. С.
778899
14.05.2017
«Заказы»
570
Иванов С. П.
445566
16.05.2017
571
Иванов С. П.
445566
19.05.2017
Номер (ПК, ВК) Товар (ПК) Кол-во, шт.
568
Стул
10
568
Стол
3
«Заказы товаров»
569
Стул
15
569
Стол
5
570
Стул
15
570
Стол
3
571
Стул
11
89
находится в 2НФ, поскольку первичный ключ такой таблицы не-
возможно разделить на части.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Третья нормальная форма (3НФ)
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
Таблица находится в третьей нормальной форме (3НФ), ес-
ли она находится в 2НФ и её неключевые атрибуты зависят толь-
ко от первичного ключа. Другими словами, в таблице не должно
быть неключевых атрибутов, которые зависят от других неклю-
чевых атрибутов.
· · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · · ·
После приведения к 2НФ в таблице «Заказы» на рисунке 4.4 по-прежнему
видно аномальное дублирование. Следовательно, данная таблица находится в
2НФ, но не в 3НФ. Действительно, здесь имеется функциональная зависимость
между атрибутами «ФИО Клиента» и «Телефон», которая рассматривалась в
пп. 4.2.1.
Для того чтобы перевести таблицу из 2НФ в 3НФ, необходимо восполь-
зоваться следующим алгоритмом:
1. Определить зависимости группы одних неключевых атрибутов от
других неключевых атрибутов.
2. Для каждого такого неключевого атрибута и набора неключевых ат-
рибутов, которые от него зависят, необходимо создать новую таблицу
и скопировать эти данные в неё. В новой таблице бывший неключевой
атрибут, от которого зависят остальные, станет первичным ключом.
3. Из исходной таблицы необходимо удалить все скопированные неклю-
чевые атрибуты, при этом не удаляя того, от которого все зависят,
ведь он станет ещё и внешним ключом, связанным с новой таблицей.
В нашем примере мы уже выделили зависимость неключевого атрибута
«Телефон клиента» от поля «ФИО Клиента» и согласно алгоритму должны со-
здать новую таблицу для всей этой группы атрибутов.
В исходной таблице данную группу неключевых атрибутов необходимо
удалить, оставив только поле «ФИО Клиента». Данный атрибут теперь также
будет являться и внешним ключом.
В результате приведения к 3НФ будут получены таблицы, изображенные
на рисунке 4.5.
90
Рис. 4.5 – Таблицы «Заказы», «Заказы товаров» и «Клиенты» в 3НФ
Полученная схема БД считается нормализованной и готовой к следую-
щим этапам проектирования. Нормализация позволила устранить избыточность
данных, что в свою очередь приведёт к снижению объема хранимых данных и
устранит различные аномалии.
Пример нормализации данных
В качестве примера нормализации данных рассмотрим информацию об
успеваемости студентов, содержащуюся в таблице 4.6. Данную таблицу необ-
ходимо привести к третьей нормальной форме. В таблице «Успеваемость» хра-
нится информация о студентах, сдавших экзамен, предмете, номере группы
студента, ФИО преподавателя, принимавшего экзамен, а также дата сдачи эк-
замена и итоговая оценка по предмету.
На первом этапе необходимо определить соответствие таблицы первой
нормальной форме. В данном случае таблица уже находится в 1НФ, поскольку
все значения полей простые или атомарные, а все записи уникальные. Прежде
чем проводить дальнейшую нормализацию, для любой таблицы необходимо
выбрать атрибут или набор атрибутов, которые будут выступать в качестве
Номер (ПК) ФИО Клиента (ВК)
Дата
568
Иванов С. П.
14.05.2017
569
Петров И. С.
14.05.2017
«Заказы»
570
Иванов С. П.
16.05.2017
571
Иванов С. П.
19.05.2017
Номер (ПК, ВК) Товар (ПК) Кол-во, шт.
568
Стул
10
568
Стол
3
«Заказы товаров»
569
Стул
15
569
Стол
5
570
Стул
15
570
Стол
3
571
Стул
11
ФИО Клиента (ПК) Телефон
Иванов С. П.
445566
Петров И. С.
778899
«Клиенты»