При проектировании БД необходимо стремиться к уменьшению избыточности хранимой в ней информации. Это обусловлено следующими причинами:
1. Требование редактируемости БД. Если одна и та же информация хранится в разных местах, то при необходимости ее обновления/удаления придется просмотреть все записи в базе, что в ряде случаев неприемлемо.
2. Требование компактности БД. Дублирование информации приводит к разрастанию БД, что не только расходует место в памяти машины, но и замедляет работу СУБД с такой базой. Использование специальных методов нормализацииБД, которые будут рассмотрены ниже, приводит к резкому сокращению размеров БД. Например, размер справочника телефонов Тулы в исходном виде составляет 10 Мбайт, а после нормализации- менее 3 Мбайт (обратите внимание, что речь идет не о сжатии информации, а только о ее более рациональной организации).
В качестве примера неправильно спроектированной БД рассмотрим базу, в которой нужно хранить данные о покупателях продукции предприятия. Первая структура БД, которая приходит в голову, имеет вид, показанный на Рис. 23.2.
PRODUCT
C
FIRMA
C
Рис. 27.2 Первоначальная структура БД
Здесь в поле PRODUCT хранится наименование изделия, а в поле FIRMA - наименование покупателя. Вид БД представлен на Рис. 23.3.
PRODUCT
FIRMA
Привод
ОАО "Электроприбор"
Задвижка
ООО "Арматура"
Задвижка
ОАО "Электроприбор"
Привод
ООО "Арматура"
Рис. 27.3. Заполненная БД
Приведенная здесь структура БД является в корне неверной! Предположим, что в связи с модификацией изделие "Привод" теперь называется "Привод 2.0", а ОАО "Электроприбор" было переименовано в ОАО "Электропривод". Для внесения всего одного фактического изменения придется просмотреть все кортежи в БД (а она может оказаться огромной). Так же обстоит дело с поиском и фильтрацией: если необходимо узнать, какие клиенты покупают приводы, придется выполнять последовательный поиск во всей БД. Индексирование здесь не сильно поможет: в индексированной базе записи с одинаковыми значениями ключевого поля располагаются одна за одной и для прохода по ним все равно придется использовать медленный цикл с перебором всех записей, начиная с некоторой.
Рассмотрим теперь основные способы нормализацииБД, т.е. устранения избыточности информации. Будем называть нормализованной такую БД, в которой избыточность информации устранена. В принципе все способы нормализациипроходят следующие этапы:
1. Создается универсальная БД, хранящая все атрибуты всех описываемых объектов и не являющаяся нормализованной.
2. Универсальная БД анализируется на предмет необходимости дробления выбранных атрибутов.
3. Выполняется декомпозиция: универсальная БД разбивается на ряд отношений, в каждом из которых дублирование данных исключено.
4. Для сформированных на предыдущем этапе отношений устанавливаются уникальные ключи, обеспечивающие однозначную идентификацию каждой записи в каждом отношении.
5. Между отношениями формируются связи, объединяющие их в законченную БД.
Рассмотрим пример декомпозиции. Пусть нам нужно создать телефонный справочник простейшего вида, содержащий только фамилии абонентов и их телефоны. Универсальная БД (этап 1) будет иметь вид, показанный на Рис. 23.4.
NAME
PHONE
Иванов А.Б.
Иванов В.Г.
Петров Д.Е.
Сидоров М.В.
Рис. 27.4. Структура телефонного справочника
Избыточность универсальной БД в данном случае заключается в том, что фамилии в базе повторяются (число однофамильцев огромно). Это приводит к бессмысленному разрастанию базы. С другой стороны, очевидно, что чаще всего совпадают только фамилии, а инициалы остаются различными. Поэтому (этап 2) сначала нужно выполнить дробление атрибутовпутем выделения инициалов в отдельные поля (рис.4). Смысл дробления - в увеличении схожести записей.
NAME
I1
I2
PHONE
Иванов
А
Б
Иванов
В
Г
Петров
Д
Е
Сидоров
М
В
Рис. 27.5. Дробление атрибутов
Теперь можно перейти к этапу 3 - декомпозиции нашей универсальной БД. В любом случае декомпозиция выполняется по следующему простому правилу: атрибут, содержащий повторяющуюся информацию, выделяется в отдельное отношение.
В данном случае атрибут NAME следует выделить в отдельную таблицу (обозначим ее Т1, а таблицу с телефонами - Т0) – Рис. 23.6.
Таблица Т1 уже является нормализованной: в ней все записи уникальны. Но как же установить соответствие между фамилией абонента и его номером? Сейчас эта связь потеряна. Очевидно, в таблице Т0 отсутствует какой-то важный атрибут.
