вторая нормальная форма определение

Вторая нормальная форма (2NF) базы данных

Всем привет! Сегодня мы с Вами подробно рассмотрим вторую нормальную форму (2NF) базы данных, в частности Вы узнаете, какие требования предъявляются к таблицам, чтобы база данных находилась во второй нормальной форме, и для наглядности мы как всегда рассмотрим несколько примеров.

Перед тем как переходить к процессу приведения таблиц базы данных до второй нормальной формы, необходимо чтобы эти таблицы уже находились в первой нормальной форме, подробно процесс приведения таблиц базы данных до первой нормальной формы, а также все требования, предъявляемые к первой нормальной форме, мы рассматривали в предыдущей статье – первая нормальная форма (1NF).

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

Требования второй нормальной формы (2NF)

Чтобы база данных находилась во второй нормальной форме (2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:

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

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

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

Главное правило второй нормальной формы (2NF) звучит следующим образом

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

Пример приведения таблицы ко второй нормальной форме

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

Таблица сотрудников в первой нормальной форме.

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

Теперь мы можем начать процесс нормализации этой таблицы до второй нормальной формы.

Что для этого нам нужно сделать? Нам нужно внедрить первичный ключ.

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

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

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

Таблица сотрудников во второй нормальной форме с простым первичным ключом.

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

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

Пример приведения таблицы ко второй нормальной форме (первичный ключ составной)

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

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

Для хранения таких данных мы создали следующую таблицу.

Таблица проектов организации в первой нормальной форме.

Как видим, она в первой нормальной форме, значит, мы можем пытаться приводить ее ко второй нормальной форме.

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

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

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

Таблица проектов организации. Внедрен составной первичный ключ.

Так как первичный ключ составной, нам необходимо проверить еще и второе требование, которое гласит, что «Все неключевые столбцы таблицы должны зависеть от полного ключа».

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

Чтобы это проверить, мы можем задать себе несколько вопросов.

Можем ли мы определить «Должность», зная только название проекта? Нет. Для этого нам необходимо знать и участника. Значит, пока все хорошо, по этой части ключа мы не можем четко определить значение неключевого столбца. Идем дальше и проверяем другую часть ключа.

Можем ли мы определить «Должность» зная только участника? Да, можем. Значит наш первичный ключ плохой, и требование второй нормальной формы не выполняется.

Что делать в этом случае?

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

Декомпозиция – это процесс разбиения одного отношения (таблицы) на несколько.

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

Связь проектов и участников этих проектов.

Заметка! Если Вас интересует язык SQL, то рекомендую почитать книгу «SQL код» – это самоучитель по языку SQL для начинающих программистов. В ней очень подробно рассмотрены основные конструкции языка.

Мы создали 3 таблицы:

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

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Источник

2NF – вторая нормальная форма

Вы будете перенаправлены на Автор24

Довольно часто первичный ключ отношения может включать несколько атрибутов (тогда он называется составным).

К примеру, отношение ДЕТИ, которое показано на рисунке 1.

Полная функциональная зависимость

Рассмотрим понятие полная функциональная зависимость.

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

Рассмотрим отношение ПОСТАВКИ (НОМЕР_ПОСТАВЩИКА, ТОВАР, СТОИМОСТЬ).

Поставщиком могут поставляться различные товары, а одинаковый товар может поставляться разными поставщиками. Тогда ключом отношения будет НОМЕР_ПОСТАВЩИКА + ТОВАР. Предположим, что всеми поставщиками поставляется товар по одинаковой цене. Тогда будут существовать следующие функциональные зависимости:

При неполной функциональной зависимости атрибута СТОИМОСТЬ от ключа возможно появление следующей аномалии: если изменится стоимость товара, необходимо полностью просмотреть отношения для изменения всех записей о его поставщиках. Такая аномалия появляется вследствие того, что два семантических факта объединены в одной структуре данных.

Рассмотрим разложение, которое дает отношения во второй нормальной форме:

Готовые работы на аналогичную тему

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

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

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

Следовательно, вторая нормальная форма может быть нарушена лишь в том случае, если ключ является составным, т.е. ключ состоит из нескольких атрибутов.

Рассмотрим таблицу «Назначение 1», представленную на рисунке 1. В таблице ключ состоит из набора атрибутов № здания и № работника. Атрибут Фамилия определяет атрибут № работника, а значит состоит в функциональной зависимости от части ключа. То есть для того, чтобы определить фамилию работника достаточно узнать № работника. Следовательно, таблица не удовлетворяет второй нормальной форме.

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

Для решения этих проблем необходимо выполнить разбиение таблицы на 2 реляционные таблицы, которые будут удовлетворять второй нормальной форме (рисунок 3).

Полученные реляционные таблицы «Работник» и «Назначение» находятся во второй нормальной форме и не содержат перечисленных выше проблем. Следовательно, 2NF уменьшает избыточность данных и исключает возможность аномалий.

Этапы разбиения на 2 таблицы в 2NF:

Источник

Вторая нормальная форма в примерах

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

Что же такое вторая нормальная форма или 2NF? Так чтоб трехлетний ребенок понял…
Для начала разберемся в целях, которые преследует нормализация. Под катом немного терминов из дискретки.

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

Например если у отношения ’Семья’ есть атрибут ’Дети’, мы можем легко сравнить две строки ’Вася’ и ’Аня’ и определить их лексикографический порядок. Но сравнивать строки ’Вася’ и ’Аня, Саша’ и определять их порядок бессмысленно, а попытка решить эту проблему без декомпозиции, приведет либо к введению правил на сравнение скаляров и списков, либо к усложнению языка формул. Логики предикатов первого порядка тут недостаточно. Поэтому 1NF требует, чтобы все значения были простыми значениями из домена.

То есть первая НФ имеет дело, со структурой значений записей.

Вторая (и третья) НФ имеет дело уже с ключами и зависимостями в схеме. Перечислим ее цели с пояснениями.

Например, у нас есть схема

, где первичным ключом является ’Идентификатор’, а альтернативным ключом — ’Название СД-диска’. Эта схема находится во 2NF, поскольку неключевой атрибут ’Название группы’ зависит только от ключа и не зависит от подмножества атрибутов этого ключа (которых собственно нет, см. ниже).

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

Вообще ставить вопрос о несоответствии 2NF можно только в случае если в схеме есть составные ключи. Схемы с простыми ключами как в примере всегда имеют 2NF. Указанная схема есть как раз пример такого случая, так как в ней оба ключа (а это ’Идентификатор’ и ’Название СД-диска’) простые, и подмножества атрибутов этих ключей пусты.

Несоответствие 2NF рассмотрим на схеме

Одна и та же песня может входить в несколько дисков, также теоретически возможны одноименные альбомы с одноименными песнями у разных групп, например трибьюты. Поэтому ключом будет . При этом атрибуты ’Автор слов’ и ’Композитор’ зависят от множества атрибутов . Это и есть нарушение 2NF.

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

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

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

Чтобы избежать подобных аномалий и убрать избыточность, нам нужно разбить схему, то есть провести декомпозицию, на две схемы:

Обе схемы имеют 2NF, R1 — поскольку у нее нет неключевых атрибутов, а R2 — поскольку ’Автор’ и ’Композитор’ зависят от ключа и не зависят (функционально) от любого из атрибутов ‘Название группы’ или ’Название песни’.

Проиллюстрируем на другом примере. У нас есть детали на складах. Все это представлено в таблице вида

Ключом в данной схеме есть пара , но ’Адрес_склада’ функционально зависит только от атрибута ’Склад’, то есть от подмножества атрибутов ключа. Поэтому требования 2NF несоблюдены. Чем плохо? Во-первых, адрес склада будет дублироваться для всех деталей на складе (избыточность) и если адрес изменится, нужно будет изменить все эти записи, чтобы сохранить целостность (могут возникнуть аномалии удаления). Во-вторых, если на складе еще нет деталей, то у нас нет возможности хранить адрес склада, так как схема такую ситуацию не предусматривает. Поэтому добаление нового склада невозможно (аномалия вставки), а вывоз деталей со склада означает, что мы потеряем информацию о его адресе (аномалия удаления).

Вот собственно и все.
Надеюсь было понятно, я же пошел разбираться с 3NF!

Источник

Нормализация отношений. Первая и вторая нормальные формы

Предисловие

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

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

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

Используемые термины

Атрибут — свойство некоторой сущности. Часто называется полем таблицы.
Домен атрибута — множество допустимых значений, которые может принимать атрибут.
Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица).
Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение: -> .

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

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

Будем называть исходное отношение основным, а значение неатомарного атрибута — подчинённым.

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

Следует пояснить сказанное на примере. Рассмотрим отношение, имеющее атрибуты «Код сотрудника», «ФИО», «Должность», «Проекты». Очевидно, что один сотрудник может работать над несколькими проектами. Предположим, что проект описывается идентификатором, названием и датой сдачи.

Легко заметить, что не все атрибуты этого отношения атомарны (неделимы). В частности, атрибут «Проекты» можно разделить на три более простых атрибута: «Код проекта», «Название», «Дата сдачи», а значение этого атрибута для сотрудника Иван Иванович Иванов содержит несколько кортежей — информацию о трёх проектах.

Примечание: с некоторой точки зрения атрибут «ФИО» можно также считать неатомарным и в таком случае его также следует разделить на более простые, как «Фамилия», «Имя», «Отчество».

Результат будет выглядеть так:

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

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

Пусть исходное отношение содержит информацию о поставке некоторых товаров и их поставщиках.

Заранее известно, что в этом отношении содержатся следующие функциональные зависимости:
< <Код поставщика, Код товара>-> < Количество>,
<Код поставщика>-> <Город>,
<Код поставщика>-> <Статус>,
<Город>-> <Статус>>

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

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

Источник