Таблица 2.5 - Первая нормальная форма

КАТЕГОРИИ: Главная Случайная страница Познавательное Новые статьи Контакты Заказать работу Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Пример построения нормализованной базы данных ⇐ Предыдущая14151617181920212223Следующая ⇒ Процесс нормализации таблиц   Среди целей проектирования баз данных наиболее важными представляются следующие: · возможность хранения в базе данных всех необходимых данных; · исключение избыточности данных; · сведение к минимуму числа хранимых в базе данных таблиц; · нормализация таблиц для упрощения решения проблем, связанных с обновлением и удалением данных. Необходимость исключения избыточности не всегда очевидна начинающему проектировщику баз данных. Здесь следует различать дублирование данных и избыточное дублирование данных. Поясним это на примере. В таблице 2.1 содержатся данные о преподавателях университета.   Таблица 2.1 - Пример таблицы Дисциплина Преподаватель Информационное обеспечение систем управления Гришин Базы данных и знаний Гришин Программирование и основы алгоритмизации Градусов Автоматизация проектирования систем и средств управления Градусов   В этой таблице фамилии преподавателей появляются неоднократно, поскольку один преподаватель может читать лекции по нескольким предметам. Однако повторение фамилий в данном случае нельзя считать избыточным. Причина заключается в том, что при удалении повторяющихся фамилий теряется информация о том, кто ведет данный предмет. Небольшое изменение этой таблицы приводит к появлению избыточного дублирования данных.   Таблица 2.2 - Пример избыточного дублирования данных Дисциплина Преподаватель Должность Информационное обеспечение систем управления Гришин Доцент Базы данных и знаний Гришин Доцент Программирование и основы алгоритмизации Градусов Доцент Автоматизация проектирования систем и средств управления Градусов Доцент   Исключение избыточности в данном случае можно исключить путем разбиения таблицы 2.2 на две таблицы: ДИСЦИПЛИНЫ И ПРЕПОДАВАТЕЛИ (таблица 2.1) и ПРЕПОДАВАТЕЛИ И ДОЛЖНОСТИ (таблица 2.3).   Таблица 2.3 - Преподаватели и должности Преподаватель Должность Гришин Доцент Градусов Доцент   Необходимость сведения к минимуму числа таблиц базы данных обусловлена тем, что разбиение одной таблицы на несколько таблиц меньшего размера полезно с точки зрения исключения определенных проблем (например, позволяет исключить избыточность данных). Однако это не совсем удобно для пользователя, поскольку при этом усложняется разработка пользовательских приложений, увеличивается время формирования отчетов. Нормализация. Для большинства таблиц важны проблемы удаления и обновления данных, исключения избыточности данных. Эти проблемы могут решаться с помощью процесса нормализации посредством разбиения определенным образом исходной таблицы на несколько таблиц. В теории проектирования баз данных известны пять нормальных форм. Однако практическое значение имеют первые четыре нормальные формы, которые рассматриваются ниже. Первая нормальная форма (1НФ) – это основа реляционной системы. При этом требуется, чтобы таблица была двумерной и не содержала ячеек, включающих несколько значений. Примером таблицы, которая не приведена к первой нормальной форме, служит таблица 2.4.   Таблица 2.4 - Пример ненормализованной таблицы. Дисциплина Преподаватель Информационное обеспечение систем управления. Базы данных и знаний. Гришин   Программирование и основы алгоритмизации. Автоматизация проектирования систем и средств управления. Градусов     Ячейки столбца «дисциплина» этой таблицы содержат множественные значения. Приведение такой таблицы к 1НФ осуществляется путем разбиения строк таким образом, чтобы в ее ячейках не содержались множественные значения. В результате этого получим таблицу 2.1, являющейся таблицей в первой нормальной форме. биения строк таким образом, чтобы в ее полях не содержались множест   Вторая нормальная форма (2НФ). Рассмотрим таблицу 2.5, которая является таблицей в первой нормальной форме. В таблице содержатся данные о работниках строительной фирмы.

Приведенная таблица 2.5 спроектирована неудачно. Например, в трех записях, соответствующих рабочему с табельным номером 1235, повторяется одно и то же имя и информация о специальности. Эта избыточность данных приводит не только к увеличению объема требуемой памяти компьютера, но может вызвать и нарушение целостности данных в базе данных.

Проблема возникает из-за того, что один и тот же работник может работать в разных бригадах. Предположим, что специальность Петрова была указана неверно, а исправление было внесено только в первую запись. Тогда между записями, содержащими информацию о Петрове, возникает несоответствие, которое называется аномалией обновления.

Теперь предположим, что Петров длительное время был на больничном и все объекты были завершены. Принято решение удалить все записи таблицы, связанные с завершенными объектами. В этом случае информация о Петрове будет потеряна полностью. Это называется аномалией удаления. Рассмотрим обратный случай. Принят новый работник. Этот работник еще не получил назначения ни на один из объектов. Если пустые значения не допускаются в базе данных, то нельзя ввести информацию о новом работнике. Это называется аномалией ввода.

Чтобы избежать аномалий обновления, удаления и ввода, необходимо применить к таблице метод, называемый разбиением. Разбиение – это процесс разделения таблицы на несколько таблиц в целях избавления от аномалий и поддержания целостности данных.

Прежде, чем перейти к следующим нормальным формам, рассмотрим определение функциональной зависимости.

Функциональные зависимости. Функциональные зависимости (ФЗ) позволяют накладывать дополнительные ограничения на реляционную схему. Основная идея состоит в том, что значение одного атрибута в кортеже однозначно определяет значение другого атрибута. Например, в таблице РАБОТНИК атрибут ТАБЕЛЬНЫЙ НОМЕР однозначно определяют значение атрибутов СПЕЦИАЛЬНОСТЬ и ФИМИЛИЯ. Это можно записать следующим образом:

ТАБЕЛЬНЫЙ НОМЕР -> ФАМИЛИЯ,

ТАБЕЛЬНЫЙ НОМЕР -> СПЕЦИАЛЬНОСТЬ.

Атрибут в левой части ФЗ называется детерминантом, так как его значение определяет значение атрибута в правой части. Ключ таблицы является детерминантом, так как его значение однозначно определяет значение каждого атрибута таблицы.

Вторая нормальная форма. Реляционная таблица находится во второй нормальной форме (2НФ), если никакие неключевые атрибуты не являются функционально зависимыми лишь от части ключа. Следовательно, 2НФ может быть нарушена только в том случае, если ключ составной, то есть ключом является набор из нескольких атрибутов. В таблице РАБОТНИК ключ состоит из атрибутов ТАБЕЛЬНЫЙ НОМЕР и НОМЕР ОБЪЕКТА. При этом фамилия определяется атрибутом ТАБЕЛЬНЫЙ НОМЕР, то есть функционально зависит от части ключа. Эта таблица не удовлетворяет 2НФ. Если таблицу оставить в таком виде, то могут возникнуть следующие проблемы:

· Имя работника повторяется в каждой строке, относящейся к назначению этого работника.

· Если имя работника изменяется, то требуется обновить все строки, содержание информацию о назначениях этого работника.

· Из-за избыточности может возникнуть несоответствие данных, когда в разных строках содержатся разные фамилии для одного и того же работника.

· Если в какой-то момент времени работник не имеет назначений, то может отсутствовать строка, в которой хранится фамилий работника.

Для решения этих проблем таблицу необходимо разбить на две реляционные таблицы, каждая из которых удовлетворяет 2НФ:

НАЗНАЧЕНИЕ (ТАБЕЛЬНЫЙ НОМЕР, НОМЕР ОБЪЕКТА);

РАБОТНИК (ТАБЕЛЬНЫЙ НОМЕР, ФАМИЛИЯ, ТАБЕЛЬНЫЙ НОМЕР МЕНЕДЖЕРА.).

Внешним ключом является ТАБЕЛЬНЫЙ НОМЕР.

2НФ сокращает избыточность данных и несоответствия, но она может усложнить работу некоторых приложений, извлекающих данные.

Полученные таблицы меньшего размера называются проекциями исходной таблицы. Проекция таблицы – это таблица, состоящая из нескольких выбранных атрибутов другой таблицы.

Процесс разбиения на две таблицы во второй нормальной форме состоит из следующих шагов:

1) В исходной таблице выявляются атрибуты, зависящие от части ключа. Создается новая таблица, атрибутами которой будут атрибуты исходной таблицы, входящие в противоречащую правилу ФЗ. Детерминант ФЗ становится ключом новой таблицы.

2) Атрибут, стоящий в правой части ФЗ, исключается из исходной таблицы

3) Если более одной ФЗ нарушают 2НФ, то шаги 1 и 2 повторяются для каждой такой ФЗ.

4) Если один и тот же детерминант входит в несколько ФЗ, то все функционально зависящие от него атрибуты помещаются в качестве неключевых атрибутов в таблицу, ключом которой будет детерминант.

Третья нормальная форма. Реляционная таблица имеет третью нормальную форму (3НФ), если для любой функциональной зависимости X->Y X является ключом. Из определения следует, что любая таблица, удовлетворяющая 3НФ, также удовлетворяет и 2НФ.

Рассмотрим таблицу РАБОТНИК (ТАБЕЛЬНЫЙ НОМЕР, СПЕЦИАЛЬНОСТЬ, ПРЕМИЯ). Полагаем, что размер премиальных зависит от специальности. В этом случае имеют место следующие ФЗ:

ТАБЕЛЬНЫЙ НОМЕР -> СПЕЦИАЛЬНОСТЬ,

ТАБЕЛЬНЫЙ НОМЕР -> ПРЕМИЯ,

СПЕЦИАЛЬНОСТЬ -> ПРЕМИЯ.

Первые две ФЗ удовлетворяют критерию 3НФ. В третьей ФЗ атрибут СПЕЦИАЛЬНОСТЬ не является ключом. Следовательно, критерий 3НФ нарушен. В то же время таблица удовлетворяет 2НФ, так как ключ состоит из одного атрибута. Рассмотрим недостатки, присущие таблицам, не удовлетворяющим 3НФ:

· Размер премиальных для вида специальности повторяется в каждой строке, относящейся к работнику этой специальности. Это избыточные данные.

· Если размер премиальных для вида специальности изменяется, то нужно обновить все строки, содержащие эту специальность. Если строка удаляется, то можно потерять информацию о размере премиальных для данной специальности. Следовательно, таблица подвержена аномалиям обновления и удаления.

· Если в какой-то момент времени отсутствуют работники данной специальности, то может не оказаться строки, в которой можно хранить размер премиальных. Это аномалия ввода.

Для приведения таблицы к 3НФ воспользуемся методом разбиения. Разобьем таблицу РАБОТНИК на две таблицы: Т1 (ТАБЕЛЬНЫЙ НОМЕР, СПЕЦИАЛЬНОСТЬ) и Т2 (СПЕЦИАЛЬНОСТЬ, ПРЕМИЯ). Внешним ключом является СПЕЦИАЛЬНОСТЬ. Если хотя бы одна из полученных таблиц нарушает 3НФ, то процесс разбиения продолжается.

ЧЕТВЕРТАЯ НОРМАЛЬНАЯ ФОРМА. Первая нормальная форма запрещает таблицам иметь неатомарные (многозначные) атрибуты. Однако на практике существует множество ситуаций моделирования, требующих многозначных атрибутов. Например, преподаватель университета может вести несколько предметов и работать в нескольких комиссиях (таблица 2.6).

Таблица 2.6 - Таблица с многозначными атрибутами

В таблице 2.6 показан подход к решению проблемы участия преподавателя в комиссиях и ведения предметов. Здесь имеют место пустые значения атрибутов, что нарушает категорную целостность, поскольку все атрибуты вместе составляют ключ таблицы. Кроме того, очевидно, что атрибуты КОМИССИЯ и ПРЕДМЕТ не зависят друг от друга. Устранить это можно следующим образом. Потребуем, чтобы каждое значение атрибута КОМИССИЯ сочеталось с каждым значением атрибута ПРЕДМЕТ как минимум в одной строке (таблица 2.7).

Таблица 2.7 – Таблица с многозначной зависимостью атрибутов

Условие, обеспечивающее независимость атрибутов путем обязательного повторения значений, называется многозначной зависимостью (МЗЗ). МЗЗ является таким же ограничительным условием, как и ФЗ. Недостатком таблицы 2.7 является большое число повторений значений данных. Поэтому важным этапом процесса нормализации является избавление от многозначных зависимостей.

Таблица имеет четвертую нормальную форму (4НФ), если она имеет 3НФ и не содержит многозначных зависимостей. Так как проблема многозначных зависимостей возникает в связи с многозначными атрибутами, то можно решить эту проблему, поместив каждый многозначный атрибут в отдельную таблицу вместе с ключом, от которого атрибут зависит. В нашем примере таблица может быть разбита на две таблицы: КОМИССИЯ (ФАМИЛИЯ, КОМИССИЯ) и ПРЕДМЕТ (ФАМИЛИЯ, ПРЕДМЕТ). Ключом каждой полученной таблицы 4НФ являются оба атрибута таблицы.

Другие нормальные формы. Для избавления от некоторых других аномалий были предложены еще несколько нормальных форм. Но эти нормальные формы имеют в основном теоретический интерес и сомнительную практическую ценность. Поэтому в рамках настоящих методических указаний их рассматривать не будем.

База данных для работников гостиницы. В БД должны храниться сведения о проживающих клиентах. Номера отличаются числом мест и стоимостью проживания в сутки. Цена проживания зависит от числа мест. Количество номеров в гостинице известно. Номера располагаются на разных этажах гостиницы.

О каждом проживающем должна храниться следующая информация: код клиента; номер паспорта; фамилия; имя; отчество; город, из которого он прибыл; выделенный гостиничный номер; дата прибытия и дата убытия.

Определим таблицу ГОСТИНИЦА в первой нормальной форме:

ГОСТИНИЦА (номер, число_мест, цена, ЭТАЖ, код_клиента, фАмилия, имя, отчество, ПАСПОРТ, город, дата_прибытия, дата_убытия).

Здесь подчеркнуты ключевые атрибуты. Строку таблицы можно однозначно идентифицировать по коду клиента и дате прибытия клиента в гостиницу. Данная таблица не находится во второй нормальной форме, поскольку имеют место функциональные зависимости неключевых атрибутов от части ключа:

КОД_КЛИЕНТА -> ФАМИЛИЯ,

КОД_КЛИЕНТА -> ИМЯ,

КОД_КЛИЕНТА -> ОТЧЕСТВО,

КОД_КЛИЕНТА -> ПАСПОРТ,

КОД_КЛИЕНТА -> ГОРОД,

Для приведения исходной таблицы ко второй нормальной форме разобьем ее на две таблицы:

КЛИЕНТ (код_клиента, фАмилия, имя, отчество, ПАСПОРТ, город),

проЖИВАЕТ (номер, число_мест, цена, ЭТАЖ, код_клиента, дата_прибытия, дата_убытия).

Таблица ПРОЖИВАЕТ получена из таблицы ГОСТИНИЦА после удаления из нее повторяющихся в таблице КЛИЕНТ неключевых атрибутов. Полученные таблицы КЛИЕНТ и ПРОЖИВАЕТ находятся во второй нормальной форме, поскольку в них нет функциональных зависимостей, в которых какой-либо неключевой атрибут зависит от части ключа. Но в таблице ПРОЖИВАЕТ имеют место функциональные зависимости:

НОМЕР - > ЧИСЛО_МЕСТ,

НОМЕР - > ЦЕНА,

НОМЕР - > ЭТАЖ,

где неключевые атрибуты функционально определяются неключевым атрибутом. Следовательно, указанная таблица не находится в третьей нормальной форме. Для получения третьей нормальной формы создадим таблицу

НОМЕР (НОМЕР, ЧИСЛО_МЕСТ, ЦЕНА, ЭТАЖ).

После удаления из таблицы ПРОЖИВАЕТ повторяющихся в таблице НОМЕР неключевых атрибутов получим таблицу

проЖИВАЕТ (номер, код_клиента, дата_прибытия, дата_убытия).

Таблица ПРОЖИВАЕТ теперь является таблицей в третьей нормальной форме, поскольку в ней не осталось функциональных зависимостей неключевых атрибутов от неключевого атрибута.

Анализ таблицы НОМЕР показывает, что в ней имеет место зависимость неключевого атрибута от другого неключевого атрибута

ЧИСЛО_МЕСТ -> ЦЕНА.

После создания таблицы ТИП_НОМЕРА (ЧИСЛО_МЕСТ, ЦЕНА) и удаление атрибута ЦЕНА из таблицы НОМЕР получим базу данных ГОСТИНИЦА, состоящую из четырех таблиц:

КЛИЕНТ (код_клиента, фАмилия, имя, отчество, ПАСПОРТ, город),

проЖИВАЕТ (номер, код_клиента, дата_прибытия, дата_убытия),

НОМЕР (НОМЕР, ЧИСЛО_МЕСТ, ЭТАЖ),

ТИП_НОМЕРА (ЧИСЛО_МЕСТ, ЦЕНА).

В полученных таблицах отсутствуют множественные зависимости, поэтому можно утверждать, что таблицы находятся в четвертой нормальной форме. На этом процесс нормализации может быть завершен.

Наконец, определим в полученных таблицах внешние ключи, которые служат для установления связей между данными, находящимися в разных таблицах.

Атрибут НОМЕР служит внешним ключом для связи между таблицами НОМЕР и ПРОЖИВАЕТ. Атрибут ЧИСЛО_МЕСТ служит внешним ключом для связи между таблицами НОМЕР и ТИП_НОМЕРА. Атрибут КОД_КЛИЕНТА обеспечивает связь между таблицами КЛИЕНТ и ПРОЖИВАЕТ.

Дата добавления: 2014-11-20; Просмотров: 1474; Нарушение авторских прав?; Мы поможем в написании вашей работы!