Лекция 5 Нормализация таблиц БД

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

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

Общие требования нормализации формулируются в виде пяти нормальных форм (НФ), к которым последовательно приводятся таблицы БД. На практике наиболее часто применяются только первые три НФ [10].

Рассмотрим первую нормальную форму (1НФ).

Таблица в 1НФ должна удовлетворять следующим требованиям:

1. В таблице не должно быть повторяющихся записей;

2. Каждое поле таблицы должно быть неделимым (атомарным), т. е. на пересечении строки и столбца должен быть атомарный объект;

3. В таблице должны отсутствовать повторяющиеся группы полей.

Рассмотрим пример нормализации таблицы «Продажи», в которой содержится 21 поле (табл. 3).

Таблица 3

Продажи


Номер

Поле

Тип поля


1

Фамилия

Текст


2

Имя

Текст


3

Отчество

Текст


4

Телефон

Текст


5

Факс

Текст


6

Индекс

Текст


7

Страна

Текст


8

Город

Текст


9

Адрес

Текст


10

Название предприятия

Текст


11

Руководитель предприятия

Текст


12

Web-сайт предприятия

Текст


13

E-mail предприятия

Текст


14

Код товара

Числовой


15

Дата заказа

Дата/время


16

Заказано

Числовой


17

Дата продажи

Дата/время


18

Продано

Числовой


19

Цена

Денежный


20

Категория товара

Числовой


21

Наименование товара

Текстовый


В табл. 3 каждое поле неделимое, и никакое из полей не является уникальным.

Таблица с такой структурой может иметь повторяющиеся группы полей, в которых будут записаны данные об одном и том же покупателе (поля с 1-го по 13-е). Чтобы привести таблицу к 1НФ, она разбивается на две таблицы: «Клиенты» и «Заказы», находящиеся в отношении «один-ко-многим».

Поскольку ни одно из полей исходной таблицы не было уникальным, здесь в качестве первичного ключа таблицы «Клиенты» лучше ввести новое поле – «Код клиента». Это поле будет внешним ключом в таблице «Заказы» (рис. 11).

Рис. 11. Разбиение со связью «один-ко-многим»

В таблице «Заказы» ни одно из полей не является уникальным, поэтому в качестве первичного ключа можно добавить поле «Код заказа» или использовать комбинацию трех полей – «Код клиента», «Код заказа» и «Дата заказа» – в качестве составного ключа (если один клиент делает один заказ в день). Рассмотрим второй вариант – таблицу с составным первичным ключом. Такая таблица должна удовлетворять требованиям 2-й нормальной формы (2НФ).

Таблица находится во 2НФ, если удовлетворены два условия:

1. Таблица удовлетворяет условиям 1НФ;

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

Очевидно, что в таблице «Заказы» второе условие не выполняется, поскольку поля «Категория» и «Наименование товара» зависят только от поля «Код товара». Чтобы привести таблицу к 2НФ, нужно выделить эти поля в отдельную таблицу с наименованием «Товар» (рис. 12).

Рис. 12. Разбиение со связью «один-к-одному»

Рассмотрим далее таблицу «Клиенты». Здесь нет составного ключа, поэтому требования 2НФ выполнены автоматически и требуется рассматривать третью нормальную форму (3НФ).

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

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

В таблице «Клиенты» неключевые поля «Руководитель фирмы», «Web-сайт фирмы» и «E-mail фирмы» определяются неключевым полем «Название фирмы», поэтому необходимо создать новую таблицу с названием «Фирма» (рис. 13).

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

В целом нормализация не только предоставляет преимущества, но и несет некоторые недостатки.

Рис. 13. Устранение зависимости неключевых полей

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

В качестве недостатков могут быть названы следующие:

1. Чем шире предметная область, тем больше получается набор таблиц после нормализации. Для крупного предприятия БД может содержать сотни взаимосвязанных таблиц, что превышает возможности человеческого восприятия. Поэтому функционирование БД может стать труднообъяснимым;

2. При считывании связанных данных необходимо объединять записи в связанных таблицах, что приводит к необходимости выполнения поисковых операций. В сложных БД это может вызывать временные издержки.

Таким образом, нормализация является желательной, но в сложных БД могут появляться другие критерии, мешающие полной нормализации таблиц БД [9].