Нормализация полученных таблиц

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

● 1НФ - первая нормальная форма

● 2НФ - вторая нормальная форма

● 3НФ - третья нормальная форма

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

● 4НФ - четвертая нормальная форма

● 5НФ - пятая нормальная форма

 

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

 

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

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

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

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

 

Но что если наши поставщики находятся в разных городах? Тогда, посылая машину за товарами в определенный город, нужно быть уверенным, что она заберет товары у всех поставщиков, находящихся в этом городе. Т.е. нам могут понадобиться сведения о поставщикам, находящихся в определенном городе. В этом случае, значения в поле Адрес уже не являются атомарными (т.к. используется часть адреса), и для приведения таблицы к 1НФ нам надо выделить еще одно поле - Город:

 

 

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

 

Для запросов магазина все остальные таблицы приведены к 1НФ.

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

 

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

 

В нашей базе данных две таблицы имеют составной ключ - Журнал покупок и Журнал поставок. Значение поля Количество зависит, как от Поставки (Покупки), так и от Товара. Значит, наши таблицы находятся во 2НФ.

 

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

 

 

Посмотрим теперь на таблицу Журнал поставок: поле Количество зависит от Наименования товара и от Даты поставки, но не зависит от того, кто поставил товар (поле Поставщика). Т.е. таблица не находится во 2НФ. Если бы на этапе концептуального моделирования нашей базы данных, не были выделены объекты Поставка и Покупка, это бы пришлось это делать сейчас. Но поскольку это уже сделано, все таблицы находятся во 2НФ.

 

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

 

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

 

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

 

 

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

 

 

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

 

Подведем итог. Схема нашей базы данных после нормализации несколько изменилась и выглядит теперь так:

 

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

Физическая реализация БД

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

Перечень задач:

1. Перенос реляционной модели в среду конкретной СУБД

a. Выбор СУБД для реализации (краткое обоснование выбора СУБД)

b. Проектирование таблиц в среде целевой СУБД

c. Реализация бизнес-правил предметной области с среде целевой СУБД

2. Проектирование физического представления БД

3. Организация мониторнга и настройка функционирования приложения.