Нормализация отношений.ppt
- Количество слайдов: 25
Нормализация отношений
Нормализация данных Нормализация - процесс реорганизации данных путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществлять непротиворечивое и корректное редактирование данных. Нормализацию можно также определить как процесс, направленный на уменьшение избыточности информации в реляционной базе данных.
Цели нормализации Избыточность информации устраняется не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных и упрощения управления ими.
Проблемы, возникающие при использовании ненормализованных таблиц избыточность данных; аномалии обновления; аномалии удаления; аномалии ввода.
Код сотрудника Структура ненормализованной Фамилия таблицы СОТРУДНИКИ Имя Отчество Дата рождения Адрес Телефон Должность Разряд Зарплата Рейтинг Дата приема
Избыточность данных - в нескольких записях таблицы базы данных повторяется одна и та же информация. Пример: Один человек может работать на двух (или более) должностях. Каждой должности соответствует запись, и в этой записи содержится информация о личных данных сотрудника, эту должность занимающего. Таким образом, если сотрудник работает на нескольких должностях, то его личные данные будут дублироваться несколько раз, что приведет к неоправданному увеличению занимаемого объема внешней памяти.
Аномалии обновления тесно связаны с избыточностью данных, появляются при обновлении значений атрибутов в ненормализованной таблице. Пример: Если у сотрудника, работающего на нескольких должностях, изменился адрес необходимо будет внести изменения в несколько записей. Если же исправление будет внесено не во все записи, то возникнет несоответствие информации, которое и называется аномалией обновления.
Аномалии удаления возникают при удалении записей из ненормализованной таблицы. Пример: Удаление записи при увольнении сотрудника приведет к потере информации о должности, которую он занимал. При этом следует удалить соответствующие записи в рассматриваемой таблице. Однако удаление приведет к потере информации о сотруднике, занимавшем эту должность. Такая потеря информации и называется аномалией удаления.
Аномалии ввода возникают при добавлении в таблицу новых записей, когда для некоторых полей таблицы заданы ограничения NOT NULL. Пример: В ненормализованной таблице имеется поле «Рейтинг» , в котором содержится информация об уровне квалификации сотрудника, устанавливаемом по результатам его работы. При приеме на работу нового сотрудника установить уровень его квалификации невозможно, так он еще не выполнял никаких работ в организации. Если для этого поля задать ограничение NOT NULL, то в таблицу нельзя будет ввести информацию о новом сотруднике. Это и называется аномалией ввода.
Выводы Причина аномалий — хранение в одном отношении разнородной информации. Вывод — логическая модель данных неадекватна модели предметной области. База данных, основанная на такой модели, будет работать неправильно.
Нормальные формы Теория нормализации основана на концепции нормальных форм. Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если оно удовлетворяет свойственному данной форме набору ограничений.
Нормальные формы В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм: • первая нормальная форма (1 NF); • вторая нормальная форма (2 NF); • третья нормальная форма (ЗNF); • нормальная форма Бойса—Кодда (BCNF); • четвертая нормальная форма (4 NF); • пятая нормальная форма (5 NF).
Основные свойства нормальных форм: каждая следующая нормальная форма в некотором смысле лучше предыдущей; при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются. В основе процесса проектирования лежит метод нормализации — декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Первая нормальная форма Отношение является в 1 НФ, если оно удовлетворяет свойствам отношений: В отношении нет одинаковых кортежей Кортежи не упорядочены Атрибуты не упорядочены и различаются по наименованию Все значения атрибуты атомарны.
Функциональные зависимости Функционально зависимым считается такой атрибут, значение которого однозначно определяется значением другого атрибута. Функционально зависимые атрибуты обозначаются следующим образом: X -->Y. Эта запись означает, что если два кортежа в таблице имеют одно и то же значение атрибута X, то они имеют одно и то же значение атрибута У. Атрибут, указываемый в левой части, называется детерминантом. Первичный ключ таблицы является детерминантом, так как его значение однозначно определяет значение любого атрибута таблицы.
Вторая нормальная форма Отношение находится во второй нормальной форме в том и только в том случае, когда это отношение находится в первой нормальной форме и каждый не ключевой атрибут полностью зависит от первичного ключа. Неключевым называется любой атрибут отношения, не входящий в состав первичного ключа.
Вторая нормальная форма Чтобы перейти от первой нормальной формы ко второй, нужно выполнить следующие шаги: 1. Определить, на какие части можно разбить первичный ключ, так чтобы некоторые из неключевых полей зависели от одной из этих частей (причем эти части могут содержать несколько атрибутов). 2. Создать новую таблицу для каждой такой части ключа и группы зависящих от нее полей и переместить их в эту таблицу. Часть бывшего первичного ключа станет при этом первичным ключом новой таблицы. 3. Удалить из исходной таблицы поля, перемещенные в другие таблицы, кроме тех их них, которые станут внешними ключами.
Приведение таблицы ко второй нормальной форме Код физического лица Код сотрудника Фамилия Имя Отчество Дата рождения Адрес Телефон Код сотрудника Должность Код физического лица Разряд Зарплата Должность Разряд Зарплата
Вторая нормальная форма Первичный ключ исходной таблицы состоит из двух атрибутов - «Код сотрудника» и «Должность» . • Все личные данные о сотрудниках зависят только от атрибута «Код сотрудника» . • Полученные две таблицы связаны между собой по полю «Код физического лица» , которое является первичным ключом для таблицы ФИЗИЧЕСКИЕ ЛИЦА и внешним ключом для таблицы СОТРУДНИКИ.
Третья нормальная форма Отношение R находится в третьей нормальной форме в том и только в том случае, если оно находится во второй нормальной форме, и каждый неключевой атрибут нетранзитивно зависит от первичного ключа. Функциональная зависимость атрибутов Х и Y отношения R называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости Х->Z и Z->У, но отсутствует функциональная зависимость Z ->Х.
Третья нормальная форма Чтобы перейти от второй нормальной формы к третьей, нужно выполнить следующие шаги: 1. Определить все поля (или группы полей), от которых зависят другие поля. 2. Создать новую таблицу для каждого такого поля (или группы полей) и группы зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей), от которого зависят все остальные перемещенные поля, станет при этом первичным ключом новой таблицы. 3. Удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешними ключами.
Приведение таблицы к третьей нормальной форме Код сотрудника Код должности Код сотрудника Код физического лица Должность Разряд Зарплата Рейтинг Дата приема Дата увольнения Код физического лица Рейтинг Дата приема Дата увольнения Код должности Должность Разряд Зарплата
Третья нормальная форма Атрибут "Код должности» является первичным ключом для отношения ДОЛЖНОСТИ и внешним ключом для отношения СОТРУДНИКИ. Добавление новых атрибутов при нормализации позволяет получить таблицы с простыми первичными ключами, что облегчает выполнение операции связывания таблиц. Такие первичные ключи, как правило,
Структура базы данных, приведенной к третьей нормальной форме Код должности Код физического лица Код сотрудника Должность Фамилия Код должности Разряд Имя Код физического лица Зарплата Отчество Дата рождения Адрес Телефон Рейтинг Дата приема Дата увольнения
На практике третья нормальная форма схем отношений в большинстве случаев достаточна, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается.


