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

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

Преобразование инфологической модели в даталогическую можно осуществить различными способами. Наиболее удобной является табличная даталогическая модель, основанная на реляционных отношениях. Концепция реляционной модели была разработана Е. Коддом, который предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение)[8]. Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение (от англ. relation) (рис.1.).

Рис.1. Состав и структура отношения

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

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

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

·  выбранный состав отношений по возможности должен быть минимальным;

· процедуры обработки и обновления данных не должны вызывать осложнений.

Для решения этих задач Коддом был разработан математический аппарат, называемый нормализацией отношений.

Принципы нормализации до третьей нормальной формы заключаются в следующем[3]:

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

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

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

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

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

2. Если имеется связь степени 1:1 и класс принадлежности одной сущности является обязательным, а другой необязательным, то требуется две таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности. Кроме того, первичный ключ сущности с необязательным классом принадлежности должен быть добавлен в качестве атрибута в таблицу, созданную для сущности с обязательным классом принадлежности.

3. Если имеется связь степени 1:1 и класс принадлежности обеих сущностей является необязательным, то требуется три таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности. Кроме того, связующая таблица должна содержать в себе ключи связываемых таблиц в качестве атрибутов.

4. Если имеется связь степени 1:М и класс принадлежности М-связной сущности является обязательным, то требуется две таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности. Кроме того, первичный ключ 1-связной сущности должен быть добавлен в качестве атрибута в М-связную таблицу.

5. Если имеется связь степени 1:М и класс принадлежности М-связной сущности является обязательным, то требуется три таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности. Кроме того, связующая таблица должна содержать в себе ключи связываемых таблиц в качестве атрибутов.

6. Если имеется связь степени М:N, то требуется три таблицы. Для каждой сущности необходимо создать свою таблицу, первичным ключом которой будет ключ этой сущности. Кроме того, связующая таблица должна содержать в себе ключи связываемых таблиц в качестве атрибутов.

Используя полученное в п.1.1 данной работы формальное описание предметной области и описанные выше принципы нормализации,были выделены дополнительные объекты БД:

1. Атрибут «название отдела» объекта «Оператор» был выделен в отдельную сущность «Отдел»;

2. Атрибут «название направления» объекта «Оператор» был выделен в отдельную сущность «Направление»;

3. Атрибут «название категории» объекта «Товар» был выделен в отдельную сущность «Категория»;

4. Была создана новая сущность «УПД» для расшифровки строк каждой УПД.

В таблице 1 представлены отношения БД, полученные после нормализации.

Таблица 1 - Отношения базы данных отдела выписки товаров