Для того, чтобы продолжить нормализацию данных, приведем данные ко второй нормальной форме (2нф).
Вторая нормальная форма (2НФ) требует [4, 5], чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. Те поля, которые зависят только от части первичного ключа, должны быть выделены в составе отдельных таблиц.
Продолжим рассмотрение описанного выше примера. Для приведения к 2НФ выделим поля, которые входят в первичный ключ. Дата и НомернНакладной по отдельности не могут уникально определять запись, поскольку они будут одинаковы для всех записей, относящихся к одной и той же накладной. Поэтому введем в первичный ключ поле Товар. При этом исходим из имеющегося правила, что по одной накладной может быть отпущено одно наименование конкретного товара, то есть не может иметь место ситуация, когда отпуск одного и того же товара оформляется в накладной двумя строками что влечет за собой две одинаковые записи в таблице ОтпускТоваровСоСклада.
Покажем на рис. 123 структуру таблицы ОтпускТоваровСоСклада после выделения полей в составе первичного ключа (эти поля отчеркнуты от прочих полей линией и располагаются в верхней части структуры таблицы).
|
|
| |
|
|
ОтпускТоваровСоСклада |
|
|
|
|
|
|
|
Дата |
|
|
|
Покупатель |
|
|
|
НомерНакладной |
|
|
|
Товар |
|
|
|
Город |
|
|
|
Адрес |
|
|
|
ЕдиницаИзмерения |
|
|
|
ЦенаЗаЕдиницуИзмерения |
|
|
|
ОтпущеноЕдиниц |
|
|
|
ОбщаяСтоимость |
|
|
|
|
|
|
Рис. 123. Таблица с избыточным первичным ключом | ||
|
| ||
Проведя смысловой анализ зависимостей между полями таблицы, нетрудно увидеть, что созданный нами первичный ключ является избыточным: поле НомерНакладной однозначно определяет дату и покупателя. Для данной накладной не может быть никакой иной даты и никакого иного покупателя.
|
|
| |
|
|
ОтпускТоваровСоСклада |
|
|
|
|
|
|
|
НомерНакладной |
|
|
|
Товар |
|
|
|
Дата |
|
|
|
Покупатель |
|
|
|
Город |
|
|
|
Адрес |
|
|
|
ЕдиницаИзмерения |
|
|
|
ЦенаЗаЕдиницуИзмерения |
|
|
|
ОтпущеноЕдиниц |
|
|
|
ОбщаяСтоимость |
|
|
|
|
|
|
Рис. 124. Таблица с неизбыточным первичным ключом, не приведенная к 2НФ | ||
Поле Товар, будучи взято в комбинации с номером накладной, напротив, однозначно идентифицирует запись, поскольку для каждой записи ясно, о каком, собственно, товаре из множества товаров, отпущенных по данной накладной, идет речь. После уточнения состава полей в первичном ключе получим таблицу со структурой, показанной на рис. 124.
Первое требование 2НФ выполнено. Чего не скажешь о втором требовании, гласящем, что значения всех полей записи должны однозначно зависеть от совокупного значения первичного ключа и не должна иметь место ситуация, когда некоторые поля зависят от части первичного ключа. Действительно, при дальнейшем анализе можно увидеть, что поля ЕдиницаИзмерения, ЦенаЗа ЕдиницуИзмерения зависят только от значения поля Товар. В самом деле, стоимость единицы измерения товара и название самой единицы измерения не зависят от конкретной накладной и будут одинаковыми для всех накладных, в которые входит данный товар. Поэтому выделяем данные поля в отдельную таблицу Товары и определяем связь: поскольку один товар может присутствовать во многих накладных, таблицы Товары и ОтпускТоваровСоСклада находятся в связи один-ко-многим (рис. 125).
|
|
|
| |
|
|
Товары |
| |
|
|
|
| |
|
|
Товар |
| |
|
|
ЕдиницаИзмерения |
| |
|
|
ЦенаЗаЕдиницуИзмерения |
| |
|
|
|
| |
|
|
ОтпускТоваровСоСклада |
| |
|
|
|
| |
|
|
НомерНакладной |
| |
|
|
Товар |
| |
|
|
Дата |
| |
|
|
Покупатель |
| |
|
|
Город |
| |
|
|
Адрес |
| |
|
|
ОтпущеноЕдиниц |
| |
|
|
ОбщаяСтоимость |
| |
|
|
|
| |
|
Рис. 125. Выделение таблицы Товар | |||
После анализа структуры таблицы ОтпускТоваровСоСклада можно заметить, что значение поля Покупатель никоим образом не зависит от пары значений НомерНакладной и Товар, а зависит только от значения поля НомерНакладной. Поэтому данное поле и, зависящие от его значения поля Город, Адрес, выделяются в отдельную таблицу Покупатели (рис. 126).
|
|
|
|
| |||
|
|
Товары |
|
Покупатели |
| ||
|
|
|
|
|
| ||
|
|
Товар |
|
Покупатель |
| ||
|
|
ЕдиницаИзмерения |
|
Город |
| ||
|
|
ЦенаЗаЕдиницуИзмерения |
|
Адрес |
| ||
|
|
|
| ||||
|
|
|
| ||||
|
|
ОтпускТоваровСоСклада |
| ||||
|
|
|
| ||||
|
|
НомерНакладной |
| ||||
|
|
Товар |
| ||||
|
|
Дата |
| ||||
|
|
ОтпущеноЕдиниц |
| ||||
|
|
ОбщаяСтоимость |
| ||||
|
|
|
| ||||
|
Рис. 126. Выделение таблицы Покупатели | ||||||
|
| ||||||
Анализируя далее структуру таблицы ОтпускТоваровСоСклада, можно заметить, что одно из оставшихся полей – Дата зависит только от значения поля НомерНакладной. Поэтому выделяем дату и номер накладной в отдельную таблицу Накладные (рис. 127).
Установим связи между таблицами. Один покупатель может встречаться во многих накладных. Поэтому между таблицами Покупатели и Накладные имеется связь один-ко-многим по полю Покупатель. Одной накладной может соответствовать несколько товаров. Поэтому между таблицами Накладные и ОтпускТоваровСоСклада имеется связь один-ко-многим по полю НомерНакладной (рис. 128).
|
|
|
|
|
|
| ||
|
|
Товары |
|
Покупатели |
Накладные | |||
|
|
|
|
|
|
| ||
|
|
Товар |
|
Покупатель |
|
НомерНакладной | ||
|
|
ЕдиницаИзмерения |
|
Город |
|
Дата | ||
|
|
ЦенаЗаЕдиницуИзмерения |
|
Адрес |
|
| ||
|
|
|
| |||||
|
|
|
| |||||
|
|
ОтпускТоваровСоСклада |
| |||||
|
|
|
| |||||
|
|
Товар |
| |||||
|
|
ОтпущеноЕдиниц |
| |||||
|
|
ОбщаяСтоимость |
| |||||
|
|
|
| |||||
|
Рис. 127. Выделение таблицы Накладные | |||||||
|
| |||||||
|
|
|
|
|
| ||||
|
|
Товары |
|
Покупатели |
| ||||
|
|
|
|
|
| ||||
|
|
Товар |
|
Покупатель |
| ||||
|
|
ЕдиницаИзмерения |
|
Город |
| ||||
|
|
ЦенаЗаЕдиницуИзмерения |
|
Адрес |
| ||||
|
|
|
| ||||||
|
|
|
| ||||||
|
|
Накладные |
| ||||||
|
|
|
| ||||||
|
|
НомерНакладной |
| ||||||
|
|
Дата |
| ||||||
|
|
Покупатель |
| ||||||
|
|
|
| ||||||
|
|
|
| ||||||
|
|
ОтпускТоваровСоСклада |
| ||||||
|
|
|
| ||||||
|
|
Товар |
| ||||||
|
|
НомерНакладной |
| ||||||
|
|
ОтпущеноЕдиниц |
| ||||||
|
|
ОбщаяСтоимость |
| ||||||
|
|
|
| ||||||
|
Рис. 128. Связи между таблицами | ||||||||
|
| ||||||||
Для того чтобы уяснить, до конца нормализованы таблицы в составе разрабатываемой нами БД или нет, проанализируем ее структуру с позиций третьей нормальной формы (ЗНФ).
Третья нормальная форма (ЗНФ) требует [4, 5], чтобы в таблице не имелось транзитивных зависимостей между не ключевыми полями, то есть, чтобы значение любого поля таблицы, не входящего в первичный ключ, не зависело от значения другого поля, не входящего в первичный ключ.
|
|
|
|
|
| ||||
|
|
Товары |
|
Покупатели |
| ||||
|
|
|
|
|
| ||||
|
|
Товар |
|
Покупатель |
| ||||
|
|
ЕдиницаИзмерения |
|
Город |
| ||||
|
|
ЦенаЗаЕдиницуИзмерения |
|
Адрес |
| ||||
|
|
|
| ||||||
|
|
|
| ||||||
|
|
Накладные |
| ||||||
|
|
|
| ||||||
|
|
НомерНакладной |
| ||||||
|
|
Дата |
| ||||||
|
|
Покупатель |
| ||||||
|
|
|
| ||||||
|
|
|
| ||||||
|
|
ОтпускТоваровСоСклада |
| ||||||
|
|
|
| ||||||
|
|
Товар |
| ||||||
|
|
НомерНакладной |
| ||||||
|
|
ОтпущеноЕдиниц |
| ||||||
|
|
|
| ||||||
|
Рис. 129. Нормализованная база данных | ||||||||
|
| ||||||||
Продолжим рассмотрение примера. Можно увидеть, что в таблице ОтпускТоваровСоСклада имеется зависимость значения поля ОбщаяСтоимость от значения поля Количество. Значение поля ОбщаяСтоимость может вычисляться как значение поля Количество, умноженное на значение поля ЦенаЗаЕдиницуИзмерения из таблицы Товары (из записи с таким же значением поля Товар). Поэтому поле ОбщаяСтоимость из таблицы ОтпускТоваровСоСклада удаляем. В результате получаем нормализованную базу данных, структура которой приведена на рис. 129.
Нормализация таблиц БД призвана устранить из них избыточную информацию. Как видно из приведенных выше примеров, таблицы нормализованной БД содержат только один элемент избыточных данных – это поля связи, присутствующие одновременно у родительской и дочерних таблиц. Поскольку избыточные данные в таблицах не хранятся, экономится дисковое пространство.
У нормализованной БД есть и недостатки, прежде всего практического характера.
Чем шире число сущностей, охватываемых предметной областью, тем из большего числа таблиц будет состоять нормализованная БД. Базы данных в составе больших систем, управляющих жизнедеятельностью крупных организаций и предприятий, могут содержать сотни связанных между собою таблиц. Поскольку порог человеческого восприятия не позволяет одновременно воспринимать большое число объектов с учетом их взаимосвязей, можно утверждать, что с увеличением числа нормализованных таблиц уменьшается целостное восприятие базы данных как системы взаимосвязанных данных. Поэтому при разработке и эксплуатации крупных систем нередки ситуации, когда каждый сотрудник представляет себе процессы, протекающие только в части системы. Известны случаи эволюционного создания таких систем, принципы функционирования которых впоследствии признавались вышедшими за границы понимания.
Другим недостатком нормализованной БД является необходимость считывать из таблиц связанные данные при выполнении запросов к нескольким таблицам БД. Так, например, пусть для рассмотренной выше БД, содержащей сведения о расходе товара со склада, требуется выдать отчет, в котором для каждой накладной указан покупатель и его реквизиты (город и адрес). Для этого необходимо каждую запись в таблице Накладные объединить по названию покупателя (поле связи) с соответствующей записью из таблицы Покупатели. Операции такого объединения подразумевают поиск и позиционирование в таблице Покупатели и могут выполняться достаточно медленно, особенно когда одна из таблиц имеет большой объем, данные в базе данных и на диске фрагментированы, и т.д. Замечено, что ненормализованные (скажем так: "не вполне нормализованные") данные отыскиваются быстрее, если они хранятся в одной таблице, по сравнению со случаем поиска данных в одной или более связанных таблиц. Подобное ускорение тем заметнее, чем больше число записей в связанных таблицах. На скорость поиска в подчиненной таблице могут оказывать негативное влияние такие факторы, как слишком большое число вложенных полей в индексе; индекс, структура которого не совсем корректно определена, и другие факторы.
Для более эффективной работы с данными, используя возможности конкретного сервера БД, приходится производить процесс, обратный нормализации, – денормализацию.
Для процесса денормализации не существует стандартного алгоритма, поэтому в каждом конкретном случае приходится искать свое решение. Денормализация обычно проводится на физическом уровне модели.
Заметим, что в ERwin имеются возможности по поддержке процесса денормализации.
Приведенные выше соображения не следует воспринимать как призыв вовсе не нормализовывать данные. Эти соображения лишь призваны показать, что при работе с данными большого объема приходится искать компромисс между требованиями нормализации (то есть "логичности" данных и экономии места на носителях информации) и необходимостью улучшения быстродействия системы.
24. С помощью СУБД Access создайте новую базу данных OtpuskTovarov.
24.1. Будем считать, что после проведения операции нормализации должны быть созданы четыре таблицы: ОтпускТоваровСоСклада, Товары, Накладные, Покупатели (рис. 129).
24.2. С помощью мастера создания таблиц создайте четыре указанных ранее таблицы (рис. 130).
Рис. 130. Таблицы в СУБД Access
24.3. В режиме конструктора скорректируйте названия полей и характеристики полей в соответствии с табл. 12.
Таблица 12
Данные для создания базы данных
|
Имя поля |
Тип данных |
Размер поля |
Формат поля |
|
НомерНакладной |
Текстовый |
30 |
– |
|
ДатаОтпуска |
Дата/время |
|
Краткий формат даты |
|
Покупатель |
Текстовый |
50 |
– |
|
Товар |
Текстовый |
255 |
– |
|
ОтпущеноЕдиниц |
Числовой |
|
Целое |
|
Город |
Текстовый |
20 |
– |
|
Адрес |
Текстовый |
255 |
– |
|
ЕдиницаИзмерения |
Текстовый |
10 |
– |
|
ЦенаЗаЕдиницуИзмерения |
Денежный |
|
Денежный |
24.4. Определите ключевые поля в соответствии с рис. 129.
24.5. С помощью команды Схема Данных создайте схему данных базы данных и установите связи между таблицами (рис. 131).
24.7. Закройте СУБД Access.
25. Запустите ERwin.
Рис. 131. Схема связи между таблицами
26. Создайте новую модель с именем OtpuskTovarov.er1.
27. Повторите пункты 14-19 и проведите обратное проектирование для базы данных OtpuskTovarov. Результаты сохраните в файле OtpuskTovarov.er1.
28. Результаты орбратного преобразования базы данных OtpuskTovarov, созданной в СУБД Access, в модели ERwin представлены на рис. 132 и рис. 133.
Рис. 132. БД OtpuskTovarov на уровне логической модели
Рис. 133. БД OtpuskTovarov на уровне физической модели