Юрий Сергеевич Избачков, Владимир Николаевич Петров Информационные системы: учебник
| Вид материала | Учебник |
- Горелик Александр Владимирович, д т. н., проф. Панков Юрий Николаевич, к т. н учебно-методический, 549.99kb.
- Программа дисциплины "Математические модели и методы теории решений" для направления, 146.63kb.
- Владимир Николаевич Лавриненко Философия Философия: учебник, 6688.53kb.
- Артеменко Юрий Николаевич исследование и разработка информационно-измерительной системы, 450.64kb.
- «Охотник и рыболов Поволжья и Урала» №9 (202), сентябрь 2009, 85.58kb.
- Рыкунов Юрий Николаевич, канд пед наук, доцент, зав кафедрой гимнастики факультета, 1058.29kb.
- Уткин В. Б. У 84 Информационные системы в экономике: Учебник для студ высш учеб, заведений, 3846.67kb.
- Владимир Николаевич Горбатенко, заместитель директора по воспитательной части программа, 49.57kb.
- Автор Карпухин Владимир Борисович учебно-методический комплекс, 473.72kb.
- Направление 230400 «Информационные системы и технологии», 20.25kb.
Нормализация данных
Нормализация представляет собой процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществлять непротиворечивое и корректное редактирование данных.
Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, то есть исключена избыточность информации. Таким образом, нормализацию можно также определить как процесс, направленный на снижение избыточности информации в реляционной базе данных.
Цели нормализации
Избыточность информации устраняется не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных и упрощения управления ими.
Использование ненормализованных таблиц может привести к нарушению целостности данных (непротиворечивости информации) в базе данных. Обычно различают следующие проблемы, возникающие при наличии ненормализованных таблиц:
• избыточность данных;
• аномалии обновления;
• аномалии удаления;
• аномалии ввода.
Чтобы проиллюстрировать проблемы, возникающие при работе с ненормализованными базами данных, рассмотрим в качестве примера таблицу СОТРУДНИКИ, содержащую информацию о сотрудниках некой организации. Структура этой таблицы приведена на рис. 4.2.
Рис. 4.2. Структура ненормализованной таблицы СОТРУДНИКИ.
Избыточность данных
Избыточность данных проявляется в том, что в нескольких записях таблицы базы данных повторяется одна и та же информация. Например, один человек может работать на двух (или даже более) должностях. Но в таблице, приведенной на рис. 4.2, каждой должности соответствует запись, и в этой записи содержится информация о личных данных сотрудника, данную должность занимающего. Таким образом, если сотрудник работает на нескольких должностях, то его личные данные будут дублироваться несколько раз, что приведет к неоправданному увеличению занимаемого объема внешней памяти.
Аномалии обновления
Аномалии обновления тесно связаны с избыточностью данных. Предположим, что у сотрудника, работающего на нескольких должностях, изменился адрес. Чтобы информация, содержащаяся в таблице, была корректной, необходимо будет внести изменения в несколько записей. Если же исправление будет внесено не во все записи, то возникнет несоответствие информации, которое и называется аномалией обновления.
Аномалии удаления
Аномалии удаления возникают при удалении записей из ненормализованной таблицы. Пусть, например, в организации проводится сокращение штатов, и некоторые должности аннулируются. При этом следует удалить соответствующие записи в рассматриваемой таблице. Однако удаление приведет к потере информации о сотруднике, занимавшем эту должность. Такая потеря информации и называется аномалией удаления. (Для нашего случая можно привести и другой пример – удаление записи при увольнении сотрудника приведет к потере информации о должности, которую он занимал.)
Аномалии ввода
Аномалии ввода возникают при добавлении в таблицу новых записей и обычно имеют место, когда для некоторых полей таблицы заданы ограничения NOT NULL. В таблице, рассматриваемой в качестве примера, имеется поле Рейтинг, в котором содержится информация об уровне квалификации сотрудника, устанавливаемом по результатам его работы. При приеме на работу нового сотрудника установить уровень его квалификации невозможно, так он еще не выполнял никаких работ в организации. Если для этого поля задать ограничение NOT NULL, то в таблицу нельзя будет ввести информацию о новом сотруднике. Это и называется аномалией ввода.
Очевидно, что аномалии обновления, удаления и ввода крайне нежелательны. Чтобы свести к минимуму возможность появления такого рода аномалий, выполняется нормализация.
Нормальные формы
Теория нормализации основана на концепции нормальных форм. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если оно удовлетворяет свойственному данной форме набору ограничений.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
• первая нормальная форма (1 Normal Form, 1NF);
• вторая нормальная форма (2NF);
• третья нормальная форма (3NF);
• нормальная форма Бойса—Кодда (BCNF);
• четвертая нормальная форма (4NF);
• пятая нормальная форма, или нормальная форма проекции-соединения (5NF, или PJ/NF).
Основные свойства нормальных форм:
• каждая следующая нормальная форма в некотором смысле лучше предыдущей;
• при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.
В основе процесса проектирования лежит метод нормализации – декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Функционально зависимым считается такой атрибут, значение которого однозначно определяется значением другого атрибута. Функционально зависимые атрибуты обозначаются следующим образом: X —> Y. Эта запись означает, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута Y. Атрибут, указываемый в левой части, называетсядетерминантом.
Примечание.
Первичный ключ таблицы является детерминантом, так как его значение однозначно определяет значение любого атрибута таблицы.
Первая нормальная форма
Ограничение первой нормальной формы – значения всех атрибутов отношения должны быть атомарными. Данное требование является базовым требованием классической реляционной модели данных, поэтому любая реляционная таблица (в том числе и таблица, структура которой изображена на рис. 4.2), по определению, уже находится в первой нормальной форме.
Вторая нормальная форма
Отношение находится во второй нормальной форме в том и только в том случае, если это отношение находится в первой нормальной форме и каждый неключевой атрибут полностью зависит от первичного ключа.
Примечание.
Неключевым называется любой атрибут отношения, не входящий в состав первичного ключа.
Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги.
1. Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (причем эти части могут содержать несколько атрибутов).
2. Создать новую таблицу для каждой такой части ключа и группы зависящих от нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа станет при этом первичным ключом новой таблицы.
3. Удалить из исходной таблицы поля, перемещенные в другие таблицы, кроме тех из них, которые станут внешними ключами.
В нашем примере для приведения таблицы СОТРУДНИКИ ко второй нормальной форме ее следует разделить на две таблицы. Первичный ключ исходной таблицы состоит из двух атрибутов – Код сотрудника и Должность. Все же личные данные о сотрудниках зависят только от атрибута Код сотрудника. Атрибуты, соответствующие этим данным, мы и выделим в качестве одной из таблиц, которую назовем ФИЗИЧЕСКИЕ ЛИЦА. Информацию же о должностях и их оплате вынесем в другую таблицу, которой присвоим имя СОТРУДНИКИ. Схема приведения таблицы ко второй нормальной форме приведена на рис. 4.3.
Рис. 4.3. Приведение таблицы ко второй нормальной форме.
Полученные две таблицы связаны между собой по полю Код физического лица, которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом для таблицы СОТРУДНИКИ. Данное поле отсутствовало в исходной таблице и было добавлено при проведении нормализации.
Третья нормальная форма
Рассмотрим таблицу СОТРУДНИКИ, полученную после приведения исходной таблицы ко второй нормальной форме. Для этой таблицы существует функциональная связь между полями Код сотрудника и Зарплата. Однако эта функциональная связь является транзитивной.
Примечание.
Функциональная зависимость атрибутов X и Y отношения R называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости X → Z и Z → Y, но отсутствует функциональная зависимость Z → X.
Транзитивность зависимости полей Код сотрудника и Зарплата означает, что заработная плата на самом деле является характеристикой не сотрудника, а должности, которую он занимает. В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату должности, до тех пор, пока не появится хотя бы один сотрудник, эту должность занимающий (так как первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника, занимающего данную должность, мы лишимся информации о заработной плате, соответствующей этой должности. Кроме того, чтобы согласованным образом изменить заработную плату, соответствующую должности, необходимо предварительно найти все записи, описывающие сотрудников, занимающих данную должность. Таким образом, в таблице СОТРУДИКИ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации – приведения базы данных к третьей нормальной форме.
Отношение R находится в третьей нормальной форме в том и только том случае, если оно находится во второй нормальной форме и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги.
1. Определить все поля (или группы полей), от которых зависят другие поля.
2. Создать новую таблицу для каждого такого поля (или группы полей) и группы зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей), от которого зависят все остальные перемещенные поля, станет при этом первичным ключом новой таблицы.
3. Удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешними ключами.
Приведем рассматриваемую в качестве примера базу данных к третьей нормальной форме. Для этого разделим таблицу СОТРУДНИКИ на две – СОТРУДНИКИ и ДОЛЖНОСТИ (рис. 4.4).
Рис. 4.4. Приведение базы данных к третьей нормальной форме.
Примечание.
Обратите внимание, что мы опять добавили новый атрибут Код должности, который является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отношения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет получить таблицы с простыми первичными ключами, что облегчает выполнение операции связывания таблиц. Такие первичные ключи, как правило, являются искусственными.
На практике третья нормальная форма схем отношений в большинстве случаев достаточна, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Поэтому мы не будем рассматривать другие нормальные формы, тем более что в работе они используются сравнительно редко.
В заключение приведем схему базы данных, рассматриваемой в качестве примера и приведенной к третьей нормальной форме (рис. 4.5).
Рис. 4.5. Структура базы данных, приведенной к третьей нормальной форме.