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

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

4. Третья нормальная форма (3NF)

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

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

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

Проиллюстрируем процесс приведения ненормализованного отношения к третьей нормальной форме. Для этого рассмотрим пример: отношение, находящееся не в третьей нормальной форме.

Итак, вариант 1 схемы отношения «Сотрудники»:

Сотрудники (№ табельный, Фамилия, Имя, Отчество, Код должности, Оклад);

Primary key (№ табельный);

Кроме того, над данным отношением «Сотрудники» задана следующая система функциональных зависимостей:

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

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

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

Проведя декомпозицию отношения «Сотрудники», получим следующую систему новых самостоятельных отношений:

Итак, вариант 2 схемы отношения «Сотрудники»:

Должности (Код должности, Оклад);

Primary key (Код должности);

Сотрудники (№ табельный, Фамилия, Имя, Отчество, Код должности);

Primary key (Код должности);

Foreign key (Код должности) references Должности (Код должности);

Теперь, как мы видим, в отношении «Должности» неключевой атрибут «Оклад» полностью функционально зависит от простого первичного ключа «Код должности» и только от этого ключа.

Заметим, что в отношении «Сотрудники» все четыре неключевых атрибута «Фамилия», «Имя», «Отчество» и «Код должности» полностью функционально зависят от простого первичного ключа «№ табельный». В этом отношении атрибут «Код должности» – внешний ключ, ссылающийся на первичный ключ отношения «Должности».

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

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

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

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

2.1. Задача нормализации БД

При создании приложений баз данных наиболее важным этапом является конструирование БД (определение структур таблиц, связей между ними и т.д.). Ошибки в структуре данных трудно, а чаще вообще невозможно исправить программным путем. Чем лучше структура данных, тем легче программировать БД. Теория проектирования БД содержит концепцию нормальных форм, предназначенных для оптимизации структуры БД. Нормальные формы — это линейная последовательность правил, применяемых к БД, причем чем выше номер нормальной формы, тем совершеннее структура БД. Нормализация — это многоступенчатый процесс, при котором таблицы БД организуются, разъединяются и данные приводятся в порядок. Концепцию нормализации впервые представил Е.Ф. Кодд (E.F. Codd) в 1970-е годы. Задача нормализации остается той же самой и сегодня: устранить из БД некоторые нежелательные характеристики. В частности, ставится задача устранить некоторые виды избыточности данных и благодаря этому избежать аномалий при изменении данных. Аномалии изменения данных — это сложности при операциях вставки, изменения и удаления данных, возникающие из-за структуры БД. Хотя существует много уровней, обычно достаточно выполнить нормализацию до Третьей нормальной формы (3НФ).

Читайте так же:  Судебный иск о клевете

Рассмотрим пример нормализации БД управления доставкой заказов. Неупорядоченная БД » Продажи» состояла бы из одной таблицы » Продажи» выглядела бы так:

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

2.2. Первая нормальная форма (1НФ)

Первая нормальная форма(1НФ) предопределяет атомарность всех данных, содержащихся в столбцах. Слово «атом» происходит от латинского «atomis», что буквально означает «не подлежащий разделению». 1НФ задает существование в каждой позиции, определяемой строкой и столбцом, только одного значения, а не массива или списка значений. Преимущества этого требования очевидны: если в одном столбце хранятся списки значений, то не существует простого способа манипулировать этими значениями. Конечно, при этом увеличивается количество записей в таблице.

Выполним нормализацию БД » Продажи» до 1НФ:

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

Третья нормальная форма (3НФ) связана с таким понятием как транзитивная зависимость . Рассмотрим следующую таблицу

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

Заметим, что, не смотря на выполнение условий второй нормальной формы, в таблице видна и некоторая избыточность. Действительно, происходит «парное» повторение значения поля (Автор) и поля (Издательство) – автор может иметь несколько книг, и издательство издает далеко не одну книгу.

Рис. 1.9. Транзитивная зависимость

На Рис. 1.9 показаны зависимости столбца (Издательство) . Действительно данный атрибут, очевидно, зависит от первичного ключа. Но по условию атрибут (Автор) однозначно определяет атрибут (Издательство) , который в свою очередь определяется первичным ключом.

Функциональная зависимость атрибута ( A ) от атрибута ( B ) через атрибут ( C ) называется транзитивной зависимостью.

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

Дадим теперь следующее определение.

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

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

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

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

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

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

Часть 3.8: Третья нормальная форма (3NF)

Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Мы уже рассмотрели первую и вторую нормальную форму, давайте теперь разберемся с тем, как привести отношение ко третьей нормальной форме и избавиться от транзитивной зависимости.

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

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

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

Читайте так же:  Доверенность он имени несовершеннолетние

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

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

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

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

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

Рис. 16. Пример состояния схемы отношения

Пусть для этого отношения задана следующая структура зависимостей (рис. 17):

Рис. 17. Список ФЗ, заданных на отношении, приведенном на рис. 16

В представленном на рис. 16 отношении с заданным множеством зависимостей ФЗ (рис. 17) первичный ключ состоит из атрибутов Дисциплина, Вид_работы .

Определение 3НФ

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

Более точно правило принадлежности отношения к 3НФ можно сформулировать следующим образом.

Выделим из множества имен атрибутов А R отношения R три подмножества X, Y, Z, не являющихся атрибутами ключа, так что X ≠ Y и Y ≠ Z.

Если X Y, Y Z и Y X, то Z транзитивно зависит от X, т.е. X Z и Z X

Заметим, что запрещается только ФЗ Y X, так как в этом случае они бы функционально определяли друг друга (что фактически соответствовало бы их эквивалентности). Наличие или отсутствие ФЗ Z Y в данном случае игнорируется: она может как существовать, так и не существовать.

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

Рассмотрим переход к третьей нормальной форме (рис. 18 — 21) от отношения, состояние которого представлено на рис. 16:

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

Последний пост про нормальные формы, перевод книги PHP 6 and MySQL 5 for Dynamic Web Sites. Предыдущие три вынесены ссылками в конце поста.

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

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

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

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

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

Читайте так же:  Сан-стефанский договор 1878

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

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

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

2. Создайте соответствующие таблицы. Если есть проблемный столбец в шаге 1, создавайте раздельные таблицы для него. Как города и штаты, в примере с клиентами.

3. Создайте или выделите первичные ключи. Каждая таблица должна иметь первичный ключ. Для примера с клиентами это будут city ID и state ID.

4. Создайте необходимые внешние ключи, которые образуют любое из отношений. В нашем примере нужно добавить state ID в таблицу городов и city ID в таблицу клиентов. Это свяжет каждого клиента с городом и штатом, где они живут.

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

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

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

Нарушения правил нормализации

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

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

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

Похожие статьи:

  • Исковое заявление о праве на досрочную пенсию Исковое заявление о назначении пенсии Разногласия по пенсионному вопросу можно решить в судебном порядке для чего нужно составить исковое заявление о назначении пенсии. Пенсионное законодательство весьма запутано. Поскольку в разные периоды развития страны закон […]
  • Quizgroup минимальные требования Партнерка для ютуба — QuizGroup Партнерка для ютуба QuizGroup Если Вы задаете себе вопросы: «что такое партнерка для ютуба?», «как подключить партнерку на youtube?», «партнерка youtube сколько платят?», «какую партнерку на youtube выбрать?» и «какая лучшая партнерка […]
  • Пособия с временной пропиской Выплаты и пособия на ребенка по временной регистрации После рождения малыша появляется основание для оформления пособий в соцзащите. Но не все семьи проживают по месту регистрации. Возникает вопрос: можно ли оформить пособия ребенку без прописки. Общефедеральные […]
  • Договор купли-продажи квартиры с ребенком старше 14 лет Особенности договора купли-продажи квартиры с участием несовершеннолетних детей: образец документа Как правило продажа квартиры осуществляется через договор купли-продажи, заключаемый сторонами, одна из которых выступает продавцом, другая покупателем. Основная […]
  • Договор на часть ставки Договор оказания услуг заключен в соответствии с требованиями Федерального закона от 18.07.2011 N 223-ФЗ "О закупках товаров, работ, услуг отдельными видами юридических лиц". С 01.01.2019 произойдет увеличение ставки НДС с 18% до 20%. Как изменение ставки соотносится […]
  • Подать документы на налоговый вычет за квартиру Вопрос 961083 - Срок подачи документов на налоговый вычет Здравствуйте. У меня вопрос следующего характера: если я купила квартиру в 2015 году, в собственность оформила в середине 2017, а документы на налоговый вычет подаю в конце 2017 или в начале 2018 года. За какой […]