Нормализация баз данных
В реляционных БД определенная часть информации выражается множеством зависимостей между атрибутами сущностей (между полями таблиц). Однако некоторые зависимости могут быть нежелательны из-за побочных эффектов (аномалий), которые они вызывают при модификации базы данных. Для их устранения прибегают к процедуре, называемой декомпозицией (разложением, разбиением) исходных таблиц, что составляет суть процесса нормализации. Другими словами, нормализация – это пошаговый обратимый процесс замены данной совокупности таблиц другой, в которой таблицы имеют более простую структуру.
Обратимость означает возможность восстановления структуры исходной совокупности таблиц. Для этого необходима декомпозиция, гарантирующая отсутствие потерь и сохранение зависимостей.
|
|
|
| код_п | статус | город |
| п3 | Париж | |
| п5 | Лондон |
| код_п | статус | ||
| п3 | |||
|
| код_п | город | ||
| п3 | Париж | ||
| Лондон |
а)
| код_п | статус |
| п3 | |
| п5 |
| статус | город |
| Париж | |
| Лондон |
б)
Ознакомившись с приведенными декомпозициями, можно заметить две особенности:
1. В случае (а) информация не утрачивается, поскольку таблицы SST и SC все еще содержат данные о том, что поставщик п3 имеет статус 30 и находится в Париже, а поставщик п5 имеет статус 30 и находится в Лондоне. Иначе говоря, первая декомпозиция действительно является декомпозицией без потерь.
2. В случае (б), наоборот, некоторая информация утрачивается, поскольку оба поставщика имеют статус 30, но при этом нельзя сказать, какой из них в каком городе находится. Иначе говоря, вторая декомпозиция не является декомпозицией без потерь (полной декомпозицией).
Первая нормальная форма (1НФ)
Таблица находится в первой нормальной форме, если все ее поля имеют атомарные (единственные) значение, т.е. значение поля не должно быть множеством или группой.
Пример: Рейс (номер_рейса, пункт_назначения, Расписание)
Расписание (день, время_вылета)
Пусть имеются следующие данные о рейсах:
Р101 Владивосток пон. 9:40
вт. 9:30
пятн. 10:30
Р800 Москва пон. 7:30
чет. 7:30
пятн. 7:30
Преобразовать эти данные в 1НФ можно 2 способами:
1) В составной таблице Рейс заменить таблицу Расписание соответствующими атрибутами:
Рейс (номер_рейса, пункт_назначения, день, время_вылета)
| номер | пункт_назначения | день | время_вылета |
| Р101 | Владивосток | пон. | 9:40 |
| Р101 | Владивосток | вт. | 9:30 |
| Р101 | Владивосток | пятн. | 10:30 |
| Р800 | Москва | пон | 7:30 |
| Р800 | Москва | чет. | 7:30 |
| Р800 | Москва | пятн. | 7:30 |
Недостатки этого способа:
а) избыточность; б) необходимость определения нового ключа.
2) Таблица с множественными значениями указывает на то, что существует, по крайней мере, один объект (сущность), который должен описываться отдельной таблицей. Нужно выделить из имеющейся таблицы этот объект, определить его структуру (поля), и провести декомпозицию таблицы так, чтобы каждая из полученных таблиц находилась в 1НФ:
Рейс (номер_рейса, пункт_назначения)
Расписание (день, время_вылета, номер_рейса) – будем считать, что 2 разных самолета не могут вылететь одновременно!)
Рейс <--->> Расписание
В таблице Расписание можно избавиться от составного ключа день, время_вылета, добавив уникальное поле, например, код_расписания, и выбрав его в качестве первичного ключа:
Расписание (код_расписания,день, время_вылета, номер_рейса),
однако делать этого до полной нормализации не рекомендуется.
Вторая нормальная форма (2НФ)
Таблица находится во второй нормальной форме, если она находится в первой нормальной форме и каждое ее неключевое поле полностью зависит от ключа.
Пример:
Пусть имеется таблица Поставка, содержащая данные о поставщиках (идентифицируемых номером), поставляемых ими товарах и их ценах.
Поставка (номер_поставщика, товар, цена)
Предположим, что поставщик может поставлять различные товары, а один и тот же товар могут поставлять разные поставщики. Таким образом, первичный ключ сущности Поставка (выделенный подчеркиванием) будет состоять из атрибутов номер_поставщика и товар. Известно, что цена любого товара зафиксирована (т.е. все поставщики поставляют товар по одной и той же цене). В таблице присутствуют следующие зависимости.
номер_поставщика, товар ® цена
товар ® цена
Можно отметить неполную функциональную зависимость атрибута цена от ключа.
Это приводит к следующим аномалиям:
Аномалия включения. Если у поставщика появляется новый товар, информация о товаре и его цене не сможет храниться в базе данных до тех пор, пока поставщик не начнет поставлять его
Аномалия удаления. Если поставки некоторого товара прекращаются, из базы данных придется удалить сведения о товаре и его цене, даже если он имеется в наличии у поставщиков.
Аномалия обновления. При изменении цены товара необходим полный просмотр таблицы с целью найти все поставки товара, чтобы изменение цены было отражено для всех поставщиков. Таким образом, изменение значения атрибута одного объекта влечет необходимость изменений в нескольких записях таблицы: в противном случае база данных окажется несогласованной.
Разложение таблицы Поставка на две таблицы устранит неполную функциональную зависимость:
Поставка (номер_поставщика, товар)
Цена_товара (товар, цена)
Цену товара конкретной поставки можно определить путем соединения двух таблиц по полю товар. Изменение цены товара вызовет модификацию лишь одной ячейки второй таблицы.