Нормализация баз данных

Нормальная форма

Нормальная форма — требование, предъявляемое к отношениям в теории реляционных баз данных для устранения из базы избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных.

Нормализация баз данных

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

Происхождение и назначение нормальных форм

Понятие нормальной формы было введено Эдгаром Коддом при создании реляционной модели БД. Основное назначение нормальных форм — приведение структуры базы данных к виду, обеспечивающему минимальную избыточность. Устранение избыточности производится за счёт декомпозиции отношений (таблиц) таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). Таким образом, нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации.

Типы нормальных форм

Нормализация может применяться к таблице, которая представляет собой правильное отношение.

Первая нормальная форма (1NF)

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

Замечание: в реляционной модели отношение всегда находится в 1 (или более высокой) нормальной форме в том смысле, что иные отношения не рассматриваются в реляционной модели. То есть само определение понятия отношение заведомо подразумевает наличие 1NF.

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

Сотрудник Номер телефона
Иванов И. И. 283–56–82
390–57–34
Петров П. Ю. 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) только для облегчения будущей программной реализации, а именно:

  • для облегчения хранения отношений в виде двумерных массивов («A relation whose domains are all simple can be represented in storage by a two-dimensional column-homogeneous array»);
  • для облегчения передачи данных в гетерогенных системах («The simplicity of the array representation which becomes feasible when all relations are cast in normal form is not only an advantage for storage purposes but also for communication of bulk data between systems which use widely different representations of the data.»)

Вторая нормальная форма (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 и любая многозначная зависимость соединения в ней является тривиальной.

Пятая нормальная форма в большей степени является теоретическим исследованием, и практически не применяется при реальном проектировании баз данных.

Это связано со сложностью определения самого наличия зависимостей «проекции — соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.

Ссылки

Раздел: Теоретические основы баз данных • СУБД

Вторая нормальная форма

Последнее обновление: 02.07.2017

Во второй нормальной форме каждый столбец в таблице, который не является ключом, должен зависеть от ключа.

Ключевой момент второй нормальной формы — полная функциональная зависимость. Она предполагает, что атрибут В полностью функционально зависим от атрибута А, если атрибут В функционально зависит от полного значения атрибута А, а не от какого-либо подмножества значений из атрибута А. То есть, если атрибут А составляют несколько значений, скажем, А1 и А2, то атрибут В полностью функционально зависит от А, если он зависит и от А1 и от А2 (А1, А2 → В).

Если атрибут В зависит только от какого-либо подмножества из атрибута А, например, только от А1, то имеет место частичная функциональная зависимость.

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

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

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

Возьмем сформированную в прошлой теме таблицу StudentCourses после применения первой нормальной формы:

StudentId Name CourseId Course Date TeacherId Teacher Position
1 Том 1 Математика 11/06/2017 1 Смит Профессор
1 Том 2 JavaScript 14/06/2017 2 Адамс Ассистент
2 Сэм 3 Алгоритмы 12/06/2017 2 Адамс Ассистент
3 Боб 1 Математика 13/06/2017 1 Смит Профессор

На данный момент эта таблица имеет составной первичный ключ StudentId+CourseId. Какие функциональные зависимости от ключевых атрибутов здесь можно выделить:

StudentId, CourseId → Date

StudentId → Name

CourseId → Course, TeacherId, Teacher, Position

От обоих частей составного ключа StudentId+CourseId зависит только арибут Date — дата, в которую студент с идентификатором StudentId поступил на курс с идентифкатором CourseId.

Атрибут Name зависит только от части составного ключа — от атрибута StudentId, так как зная идентификатор студента, можно сказать, какое у него имя. В данном случае имеет факт частичной зависимости.

Атрибуты Course, TeacherId, Teacher, Position зависит от другой части ключа — от атрибута CourseId. Зная значение CourseId, можно сказать, как называется курс, какой у курса преподаватель, какую должность он занимает. Опять же здесь частичная зависимость.

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

В нашем случае из одной таблицы получатся три. Таблица Students:

StudentId Name
1 Том
2 Сэм
3 Боб

Таблица Courses:

CourseId Course TeacherId Teacher Position
1 Математика 1 Смит Профессор
2 JavaScript 2 Адамс Ассистент
3 Алгоритмы 2 Адамс Ассистент

И таблица StudentCourses:

StudentId CourseId Date
1 1 11/06/2017
1 2 14/06/2017
2 3 12/06/2017
3 1 13/06/2017

Итогом стало образование связи многие ко многим (много студентов — много курсов) между таблицами Students и Courses через таблицу StudentCourses .

Таким образом, база данных перешла во вторую нормальную форму.

НазадСодержаниеВперед

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

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

База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме (вернее сказать, сознательного приведения их к пятой нормальной форме) в реальных базах данных я лично не встречал.

Главная цель нормализации базы данных — устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе.

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

Первая нормальная форма

Первая нормальная форма:

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

Вторая нормальная форма

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

Третья нормальная форма

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

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

Нормальная форма Бойса-Кодда

Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу.

Четвертая нормальная форма

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

Пятая нормальная форма

Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается.

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

Краткие итоги.

Зачем нужна нормализация.

Главное, чего мы добьемся, проведя нормализацию базы данных — это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства.

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

Метод нормальных форм

Проектирование БД является одним из этапов жизненного цикла информационной системы. Основной задачей, решаемой в процессе проектирования БД, является задача нормализации ее отношений. Рассматриваемый ниже метод нормальных форм является классическим методом проектирования реляционных БД. Этот метод основан на фундаментальном в теории реляционных баз данных понятии зависимости между атрибутами отношений.

Рассмотрим основные виды зависимостей между атрибутами отношений: функциональные, транзитивные и многозначные.

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

Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В.

Математически функциональная зависимость В от А обозначается записью А → В. Это означает, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. Отметим, что А и В могут быть составными — состоять из двух и более атрибутов.

В отношении на примере Преподаватель можно выделить функциональные зависимости между атрибутами ФИО→Каф, ФИО→Должн, Должн→ Oклад и другие. Наличие функциональной зависимости в отношении определяется природой вещей, информация о которых представлена кортежами отношения. В отношении ключ является составным и состоит из атрибутов ФИО, Предмет, Группа.

Функциональная взаимозависимость. Если существует функциональная зависимость вида А→В и В→А, то между А и В имеется взаимно однозначное соответствие, или функциональная взаимозависимость. Наличие функциональной взаимозависимости между атрибутами А и В обозначим как %%А \leftrightarrow В%% или %%В \leftrightarrow А%%.

Пример. Пусть имеется некоторое отношение, включающее два атрибута, функционально зависящие друг от друга. Это серия и номер паспорта () и фамилия, имя и отчество владельца (ФИО). Наличие функциональной зависимости поля ФИО от означает не только тот факт, что значение поля однозначно определяет значение поля ФИО, но и то, что одному и тому же значению поля соответствует только единственное значение поля ФИО.

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

Если отношение находится в 1НФ (первой нормальной форме), то все неключевые атрибуты функционально зависят от ключа с различной степенью зависимости.

Частичной зависимостью (частичной функциональной зависимостью) называется зависимость неключевого атрибута от части составного ключа. В рассматриваемом отношении атрибут Должн находится в функциональной зависимости от атрибута ФИО, являющегося частью ключа. Тем самым атрибут Должн находится в частичной зависимости от ключа отношения.

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

Атрибут зависит от атрибута транзитивно (существует транзитивная зависимость), если для атрибутов , , выполняются условия %%А\rightarrowВ%% и %%В\rightarrow С%%, но обратная зависимость отсутствует. В отношении Преподаватель транзитивной зависимостью связаны атрибуты: %%ФИО\rightarrowДолжн\rightarrowОклад%%

Между атрибутами может иметь место многозначная зависимость. В отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами из R.

Многозначные зависимости могут быть «один ко многим» (1:М), «многие к одному» (М:1) или «многие ко многим» (М:М), обозначаемые соответственно: %%А\rightarrowВ, А\leftarrowВ%% и %%А \leftrightarrow В%%.

Например, пусть преподаватель ведет несколько предметов, а каждый предмет может вестись несколькими преподавателями, тогда имеет место зависимость ФИО→Предмет. Так, из таблицы Сотрудник видно, что преподаватель Иванов И.М. ведет занятия по двум предметам, а дисциплина СУБД — читается двумя преподавателями: Ивановым И.М.

и Петровым М.И.

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

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

В случае двух атрибутов отсутствие зависимости атрибута А от атрибута В можно обозначить так: %%A\sim\rightarrow B%%. Случай, когда %%A\sim\rightarrow B%% и %%B\sim\rightarrow A%%, можно обозначить %%A\sim=B%%.

Нормализация базы данных и ее формы

Материал этой статьи напрямую не относиться к изучению языка SQL, так как имеет отношение к проектированию баз данных (БД), но для общего понимания взаимосвязи хранимой в системе информации она будет полезна.

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

Нормализация баз данных заключается в приведении структуры хранения данных к нормальным формам (NF). Всего таких форм существует 8, но часто достаточным является соблюдение первых трех. Рассмотрим их более подробно на примере учебной базы данных. Примеры будут строится по принципу «что было бы, если было иначе, чем сейчас».

Первая нормальная форма

Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.

Рассмотрим таблицы сотрудников и телефонных линий.

Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:

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

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

Помимо атомарности к первой нормальной форме относятся следующие правила:

  • Строки таблиц не должны зависеть друг от друга, т.е. первая запись не должна влиять на вторую и наоборот, вторая на третью и т.д.

    Размещение записей в таблице не имеет никакого значения.

  • Аналогичная ситуация со столбцами записей. Их порядок не должен влиять на понимание информации.
  • Каждая строка должна быть уникальна, поэтому для нее определяется первичный ключ, состоящий из одного либо нескольких полей (составной ключ). Первичный ключ не может повторяться в пределах таблицы и служит идентификатором записи.

Вторая нормальная форма

Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.

Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.

На представленной диаграмме столбцы описания и приоритета зависят от столбца «Линия», входящего в составной ключ. Это значит, что для каждой линии, подключенной разным сотрудникам, потребуется повторно указывать описание и приоритетность. Подобная структура приводит к избыточности данных.

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

Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.

Третья нормальная форма

3NF схожа по логике с 2NF, но с некоторым отличием. Если 2 форма ликвидирует зависимости неключевых полей от части ключа, то третья нормальная форма исключает зависимость неключевых полей от других неключевых полей.

На приведенном примере таблицы сотрудников видно, что столбец «Супервайзер» имеет зависимость от столбца «Группа», а это значит, что при изменении значения поля группы, потребуется изменить значение поля супервайзера.

Все риски, которые были рассмотрены для 2NF, так же относятся к 3NF и устраняются переносом зависимых полей в отдельную таблицу.

Денормализация базы данных

Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.

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

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы мы могли развивать его дальше.

У Вас недостаточно прав для комментирования.

Добавить комментарий

Закрыть меню