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

Linux, кодинг, митолл и прочая хрень 🙂

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

Для приведения таблиц ко второй нормальной форме (2НФ), приводимые таблицы должны быть уже в 1НФ. Нормализация должна проходить по порядку.

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

На рисунке выше и названия фильмов и имена актеров нарушают правила 2НФ (сами не являются ключами и не зависят от первичного ключа).

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

Чтобы привести бд ко второй нормальной форме, потребовалось 4 таблицы. Режиссёры (directors), представлены в фильмах (movies) через внешний ключ director ID, фильмы в таблице фильмы-актёры (movies-actors) через movie ID, актеры через actor ID

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

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

Чтобы привести базу ко второй нормальной форме, надо:

Чтобы привести эту базу к 2НФ, нужно 3 таблицы минимум

Для каждой таблицы нужен свой первичный ключ

Чтобы соотнести три таблицы, в messages добавлено два внешних ключа, ведущих на первичные ключи в своих таблицах

Подсказки:

Comments are closed.

Об авторе

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

Источник

BestProg

Нормализация. Вторая нормальная форма 2НФ

Перед изучением данной темы рекомендуется ознакомиться со следующими темами:

Содержание

Поиск на других ресурсах:

1. Вторая нормальная форма. Определение

Таблица (отношение) соответствует второй нормальной форме, если:

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

2. Способы приведения таблицы ко второй нормальной форме 2НФ

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

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

3. Пример таблицы во второй нормальной форме. Зависимость неключевого атрибута от составного ключа

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

Рисунок 1. Функциональная зависимость атрибута « Количество выпущенных моделей » от ключа. Таблица во второй нормальной форме 2НФ

Вышеприведенная таблица (рисунок 1) находится во второй нормальной форме по следующим причинам:

4. Примеры приведения таблицы ко второй нормальной форме путем добавления поля-счетчика

Пример 1. Задана таблица учета сотрудников со следующей структурой.

Ключом отношения избраны атрибуты Номер — Должность (рисунок 2).

Рисунок 2. Частичная зависимость неключевого атрибута Оклад от ключа отношения Номер — Должность

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

Чтобы привести таблицу ко второй нормальной форме 2НФ нужно ввести дополнительное ключевое поле как показано на рисунке 3.

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

Пример 2. Пусть задана таблица учета прочтенных занятий в учебном заведении.

В таблице ключом отношения избраны атрибуты « Номер аудитории » — « Номер занятия » — « Дата » — « Преподаватель «. На рисунке 4 показана эта зависимость.

Рисунок 4. Частичная зависимость неключевого атрибута Дисциплина от ключа отношения

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

Рисунок 5. Таблица во второй нормальной форме 2НФ

Источник

Нормализация отношений. Шесть нормальных форм

В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

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

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

Атрибут — свойство некоторой сущности. Часто называется полем таблицы.

Домен атрибута — множество допустимых значений, которые может принимать атрибут.

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

Отношение — конечное множество кортежей (таблица).

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

Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.

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

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

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

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

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

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

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

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

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

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

Например, есть таблица «Автомобили»:

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

Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа(ПК).

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

Например, дана таблица:

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

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

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

Таблица находится во 2НФ, но не в 3НФ.
В отношении атрибут «Модель» является первичным ключом. Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина.
Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон.
Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ.
В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:

Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)

Определение 3НФ не совсем подходит для следующих отношений:
1) отношение имеет два или более потенциальных ключа;
2) два и более потенциальных ключа являются составными;
3) они пересекаются, т.е. имеют хотя бы один общий атрибут.

Для отношений, имеющих один потенциальный ключ (первичный), НФБК является 3НФ.

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

Предположим, рассматривается отношение, представляющее данные о бронировании стоянки на день:

Отношение находится в 3НФ. Требования второй нормальной формы выполняются, так как все атрибуты входят в какой-то из потенциальных ключей, а неключевых атрибутов в отношении нет. Также нет и транзитивных зависимостей, что соответствует требованиям третьей нормальной формы. Тем не менее, существует функциональная зависимость Тариф → Номер стоянки, в которой левая часть (детерминант) не является потенциальным ключом отношения, то есть отношение не находится в нормальной форме Бойса — Кодда.

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

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

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

Отношение находится в 4НФ, если оно находится в НФБК и все нетривиальные многозначные зависимости фактически являются функциональными зависимостями от ее потенциальных ключей.

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

Такая переменная отношения не соответствует 4НФ, так как существует следующая многозначная зависимость:
<Ресторан>→ <Вид пиццы>
<Ресторан>→

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

Для предотвращения аномалии нужно декомпозировать отношение, разместив независимые факты в разных отношениях. В данном примере следует выполнить декомпозицию на <Ресторан, Вид пиццы>и <Ресторан, Район доставки>.

Однако, если к исходной переменной отношения добавить атрибут, функционально зависящий от потенциального ключа, например цену с учётом стоимости доставки ( <Ресторан, Вид пиццы, Район доставки>→ Цена), то полученное отношение будет находиться в 4НФ и его уже нельзя подвергнуть декомпозиции без потерь.

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

Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.
Если «Атрибут_1» зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.

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

Например, некоторая таблица содержит три атрибута «Поставщик», «Товар» и «Покупатель». Покупатель_1 приобретает несколько Товаров у Поставщика_1. Покупатель_1 приобрел новый Товар у Поставщика_2. Тогда в силу изложенного выше требования Поставщик_1 обязан поставлять Покупателю_1 тот же самый новый Товар, а Поставщик_2 должен поставлять Покупателю_1, кроме нового Товара, всю номенклатуру Товаров Поставщика_1. Этого на практике не бывает. Покупатель свободен в своем выборе товаров. Поэтому для устранения отмеченного затруднения все три атрибута разносят по разным отношениям (таблицам). После выделения трех новых отношений (Поставщик, Товар и Покупатель) необходимо помнить, что при извлечении информации (например, о покупателях и товарах) необходимо в запросе соединить все три отношения. Любая комбинация соединения двух отношений из трех неминуемо приведет к извлечению неверной (некорректной) информации. Некоторые СУБД снабжены специальными механизмами, устраняющими извлечение недостоверной информации. Тем не менее, следует придерживаться общей рекомендации: структуру базы данных строить таким образом, чтобы избежать применения 4НФ и 5НФ.

Пятая нормальная форма ориентирована на работу с зависимыми соединениями. Указанные зависимые соединения между тремя атрибутами встречаются очень редко. Зависимые соединения между четырьмя, пятью и более атрибутами указать практически невозможно.

Доменно-ключевая нормальная форма

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

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

Любая переменная отношения, находящаяся в ДКНФ, обязательно находится в 5НФ. Однако не любую переменную отношения можно привести к ДКНФ.

Шестая нормальная форма

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

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

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

Переменная отношения «Работники» не находится в 6НФ и может быть подвергнута декомпозиции на переменные отношения «Должности работников» и «Домашние адреса работников».

Источник

Система управления базами данных SQLite. Изучаем язык запросов SQL и реляционные базы данных на примере библиотекой SQLite3. Курс для начинающих.

Часть 3.7: Вторая нормальная форма (2NF)

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Для демонстрации примеров из этой части я буду пользоваться менеджером баз данных MySQL Workbench, установив его, вы с легкостью сможете повторить все примеры. По традиции повторяем определение второй нормальной формы. Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо (функционально полно) зависит от её потенциального ключа.

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

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

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

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

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

Я неслучайно выделил некоторые столбцы цветами. Обратите внимание на зеленые столбцы: в этих столбцах содержится информация о издательствах: наименование и номер. Номер издательства и его название связаны между собой функционально, то есть между ними есть функциональная зависимость, детерминантом в которой является наименование издательства. Голубые столбцы: автор и день рождения автора, так же связаны между собой.

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

Данное отношение находится во второй нормальной форме

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

Приведу пример приведения ко второй нормальной форме в виде ER-диаграмм.

Преобразование базы данных из первой нормальной формы во вторую

Рисунок 23 стоит немного пояснить. Условимся: базы данных у нас разделяются наименованием таблиц, если в названии таблицы есть 1nf – она относится к базе данных в 1-ой нормальной форме, 2nf – к БД во 2-ой, 3nf – к БД в третьей.

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

Поэтому таблица Books (2nf) связана с таблицей Author (2nf) связью один ко многим (один автор может написать несколько книг). Аналогично таблица Books (2nf) связана с таблицей Publish (2nf) связью один ко многим: одна запись из таблицы издательства может соответствовать нескольким записям из таблицы книг (соответствующая стрелочка на диаграмме это отображает).

Я неслучайно выделил красным на рисунке с диаграммой атрибуты ZIP и City, данные атрибуты имеют транзитивную зависимость (зависят не только от ключа, но и друг от друга), такая зависимость ведет к аномалии (логическим и смысловым ошибкам). Например, оператор, наполняющий базу данных в поле City записал Новосибирск, а в поле индекс написал 644000 (индекс Омска), какому значению я должен верить? Чтобы нам избавиться от транзитивной зависимости, необходимо привести нашу базу данных к третьей нормальной форме.

Источник