Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Содержание
Нормализация баз данных .............................................................................. 2
Происхождение и назначение нормальных форм ........................................ 2
Типы нормальных форм .................................................................................. 2
3.1. Первая нормальная форма (1NF) .......................................................... 4
3.2. Вторая нормальная форма (2NF) ........................................................... 5
3.3. Третья нормальная форма (3NF) ........................................................... 6
3.4. Нормальная форма Бойса—Кодда (NFBC) ..........................................7
3.5. Четвёртая нормальная форма (4NF) ..................................................... 8
3.6. Пятая нормальная форма (5NF) ............................................................ 8
Заключение………………………………………….................................................. 8
Список литературы ……………………………………............................................ 9
Нормальная форма — требование, предъявляемое к отношениям в теории реляционных баз данных для устранения из базы избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных.
Нормализация баз данных
Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация позволяет обезопасить базу данных от логических и структурных проблем, называемых аномалиями данных. К примеру, когда существует несколько одинаковых записей в таблице, существует риск нарушения целостности данных при обновлении таблицы. Таблица, прошедшая нормализацию, менее подвержена таким проблемам, т.к. ее структура предполагает определение связей между данными, что исключает необходимость в существовании записей с повторяющейся информацией.
Происхождение и назначение нормальных форм
Понятие нормальной формы было введено Эдгаром Коддом при создании реляционной модели БД. Основное назначение нормальных форм — приведение структуры базы данных к виду, обеспечивающему минимальную избыточность. Устранение избыточности производится за счёт декомпозиции отношений (таблиц) таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). Таким образом, нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.
Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой.
Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе.
Типы нормальных форм
Нормализация может применяться к таблице, которая представляет собой правильное отношение.
В теории баз данных обычно выделяется следующая последовательность нормальных форм:
Основные свойства нормальных форм:
В основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих требованиям следующей нормальной формы.
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном в теории реляционных баз данных понятии функциональной зависимости. Для дальнейшего изложения нам потребуются несколько определений.
Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y: R.X (r) R.Y.
Определение 2. Полная функциональная зависимость
Функциональная зависимость R.X (r) R.Y называется полной, если атрибут Y не зависит функционально от любого точного подмножества X.
Определение 3. Транзитивная функциональная зависимость
Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует функциональная зависимость R.Z --> R.X. (При отсутствии последнего требования мы имели бы "неинтересные" транзитивные зависимости в любом отношении, обладающем несколькими ключами.)
Определение 4. Неключевой атрибут
Неключевым атрибутом называется любой атрибут отношения, не входящий в состав первичного ключа (в частности, первичного).
Определение 5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.
Первая нормальная форма (1NF)
Таблица находится в первой нормальной форме, если каждый её атрибут атомарен. Под выражением «атрибут атомарен» понимается, что атрибут может содержать только одно значение. Таким образом, не существует 1NF таблицы, в полях которых могут храниться списки значений. Для приведения таблицы к 1NF обычно требуется разбить таблицу на несколько отдельных таблиц.
Замечание: в реляционной модели отношение всегда находится в 1 (или более высокой) нормальной форме в том смысле, что иные отношения не рассматриваются в реляционной модели. То есть само определение понятия отношение заведомо подразумевает наличие 1NF.
Пример приведения таблицы к первой нормальной форме
Исходная, ненормализованная, таблица:
|
Сотрудник |
Номер телефона |
|
Иванов И. И. |
283–56–82 |
|
Петров П. Ю. |
708–62–34 |
Таблица, приведённая к 1NF:
|
Сотрудник |
Номер телефона |
|
Иванов И. И. |
283–56–82 |
|
Иванов И. И. |
390–57–34 |
|
Петров П. Ю. |
708–62–34 |
Атомарность атрибутов
Вопрос об атомарности атрибутов решается на основе семантики данных, то есть их смыслового значения. Атрибут атомарен, если его значение теряет смысл при любом разбиении на части или переупорядочивании. И наоборот, если какой-либо способ разбиения на части не лишает атрибут смысла, то атрибут неатомарен. Одно и то же значение может быть атомарным или неатомарным в зависимости от смысла этого значения. Например, значение «4286» является
Хорошим способом принятия решения о необходимости разбиения атрибута на части является вопрос: «будут ли части атрибута использоваться по отдельности?». Если да, то атрибут следует разделить (но так, чтобы сохранились осмысленные части атрибута). Далее необходимо снова задаться тем же вопросом для новой структуры и так до тех пор, пока не останется атрибутов, допускающих разбиение.
Примеры неатомарного атрибута, часто встречающиеся на практике: составные поля в виде строки идентификаторов, разделённых, скажем, запятыми: 100,32,168,1045
Замечание: исходное назначение первой НФ, которую предложил Кодд в статье “A Relational Model of Data for Large Shared Data Banks”, вообще не было связано с борьбой с аномалиями или избыточностью. Кодд предложил использовать «простые домены» (simple domains) только для облегчения будущей программной реализации, а именно:
Вторая нормальная форма (2NF)
Вторая нормальная форма (в этом определении предполагается, что единственным ключом отношения является первичный ключ)
Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав первичного ключа, функционально полно зависит от первичного ключа. Функционально полная зависимость означает, что атрибут функционально зависит от всего первичного составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов(частей). Или другими словами: в 2НФ нет неключевых атрибутов, зависящих от части составного ключа (+ выполняются условия 1НФ).
Пример приведения таблицы ко второй нормальной форме
Пусть Начальник и Должность вместе образуют первичный ключ в такой таблице:
|
Начальник |
Должность |
Зарплата |
Наличие компьютера |
|
Гришин |
Кладовщик |
20000 |
Нет |
|
Васильев |
Программист |
40000 |
Есть |
|
Васильев |
Кладовщик |
25000 |
Нет |
Зарплату сотруднику каждый начальник устанавливает сам, но её границы зависят от должности. Наличие же компьютера у сотрудника зависит только от должности, то есть зависимость от первичного ключа не полная.
В результате приведения к 2NF получим две таблицы:
|
Начальник |
Должность |
Зарплата |
|
Гришин |
Кладовщик |
20000 |
|
Васильев |
Программист |
40000 |
|
Васильев |
Кладовщик |
25000 |
Здесь первичный ключ, как и в исходной таблице, составной, но единственный не входящий в него атрибут Зарплата зависит теперь от всего ключа, то есть полно.
|
Должность |
Наличие компьютера |
|
Кладовщик |
Нет |
|
Программист |
Есть |
Третья нормальная форма (3NF)
Третья нормальная форма. (Снова определение дается в предположении существования единственного ключа.)
Таблица находится в третьей нормальной форме, если она находится во второй нормальной форме, и при этом любой её неключевой атрибут функционально зависит только от первичного ключа. Или что тоже самое – «нет зависимостей неключевых атрибутов от других неключевых атрибутов + 2НФ».
При решении практических задач в большинстве случаев третья нормальная форма является достаточной. Процесс проектирования реляционной базы данных, как правило, заканчивается приведением к 3NF.
Пример приведения таблицы к третьей нормальной форме
|
Фамилия |
Отдел |
Телефон |
|
Гришин |
1 |
11–22–33 |
|
Васильев |
1 |
11–22–33 |
|
Петров |
2 |
44–55–66 |
В результате приведения к 3NF получим две таблицы:
|
Фамилия |
Отдел |
|
Гришин |
1 |
|
Васильев |
1 |
|
Петров |
2 |
|
Отдел |
Телефон |
|
1 |
11–22–33 |
|
2 |
44–55–66 |
Нормальная форма Бойса—Кодда (NFBC)
Между третьей и четвертой формами существует еще одна разновидность — нормальная форма Бойса—Кодда (НФБК). Все зависимые от первичного ключа атрибуты должны быть потенциальными ключами отношения. Если это условие не выполняется для них создаётся отдельное отношение. Чтобы сущность соответствовала НФБК, она должна находиться в третьей нормальной форме. Любая сущность с единственным возможным ключом, соответствующая требованиям третьей нормальной формы, автоматически находится в НФБК.
Пример приведения таблицы к нормальной форме Бойса—Кодда
|
Номер клиента |
Дата собеседования |
Время собеседования |
Номер комнаты |
Номер сотрудника |
|
С345 |
13.10.03 |
13.00 |
103 |
А138 |
|
С355 |
13.10.03 |
13.05 |
103 |
А136 |
|
С368 |
13.09.03 |
13.00 |
102 |
А154 |
|
С366 |
13.09.03 |
13.30 |
105 |
А207 |
В результате приведения к форме Бойса—Кодда получим две таблицы:
|
Номер клиента |
Дата собеседования |
Время собеседования |
Номер Сотрудника |
|
С345 |
13.10.03 |
13.00 |
А138 |
|
С355 |
13.10.03 |
13.05 |
А136 |
|
С368 |
13.09.03 |
13.00 |
А154 |
|
С366 |
13.09.03 |
13.30 |
А207 |
|
Дата собеседования |
Номер сотрудника |
Номер комнаты |
|
13.10.03 |
А138 |
103 |
|
13.10.03 |
А136 |
103 |
|
13.09.03 |
А154 |
102 |
|
13.09.03 |
А207 |
105 |
Пример ситуации 3NF, но не BCNF: отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Однако на практике как правило 3NF эквивалентна BCNF.
Четвёртая нормальная форма (4NF)
Таблица находится в 4NF, если она находится в BCNF и не содержит нетривиальных многозначных зависимостей. Многозначная зависимость не является функциональной, она существует в том случае, когда из факта, что в таблице содержится некоторая строка X, следует, что в таблице обязательно существует некоторая определённая строка Y.
То есть, таблица находится в 4NF, если все ее многозначные зависимости являются функциональными.
Пятая нормальная форма (5NF)
Таблица находится в 5NF, если она находится в 4NF и любая многозначная зависимость соединения в ней является тривиальной.
Пятая нормальная форма в большей степени является теоретическим исследованием, и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции — соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.
Заключение. Зачем нужна нормализация
Главное, чего мы добьемся, проведя нормализацию базы данных - это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства.
Но не все так бело и пушисто. Зачастую, чтобы извлечь информацию из нормализованной базы данных, приходится конструировать очень сложные запросы, которые к тому же, бывает, работают довольно медленно - из-за, главным образом, большого количества соединений таблиц. Поэтому, чтобы увеличить скорость выборки данных и упростить программирование запросов, нередко приходится идти на выборочную денормализацию базы.
Список литературы:
PAGE \* MERGEFORMAT1