1. Первая
нормальная форма. Нарушения первой нормальной формы.
Теория нормальных форм представляет
собой попытку формализовать процесс проектирования реляционной базы данных.
Однако, как мы увидим в дальнейшем, существуют более содержательные формы
проектирования, приводящие к аналогичным результатам.
Нормальная форма это некоторое
требование, которому должна удовлетворять таблица. Каждая нормальная форма
номера N, где N
больше единицы, предполагает выполнение требований нормальной формы с
номером N-1. На Рис. 1.7 схематически представлены
уровни нормализации.
Идея нормализации (приведения таблицы к
нормальной форме) в сущности, заключает в себе очень простую идею. А
именно, таблица должна быть удобной для
выполнения трех основных операций: вставки строк, удаления строк, обновления
строк. Анализируя таблицы с этой точки зрения и используя декомпозицию,
мы легко придем к таким же результатам,
что и при использовании нормальных форм.
Разумеется, декомпозицию следует
проводить, не нарушая зависимостей, существующих в таблице.
Требования первой нормальной формы
(принято обозначать 1НФ) можно сформулировать следующим образом.
Первая
нормальная форма
На пересечении строки и
столбца таблицы должны находиться простые атомарные элементы.
Другими словами таблица
должна содержать элементы, с простой внутренней структурой. Попробуем понять,
что означает данное требование. Рассмотрим
следующую таблицу <fio, zarplata, doljnost>. Здесь fio – фамилия, имя и
отчество работника, zarplata – зарплата работника, doljnost – должность, которую
занимает работник. Каждый из столбцов
данной таблицы заслуживает того, чтобы о нем поговорили отдельно.
Остановимся на столбце fio. В обыденной
жизни фамилия, имя и отчество часто воспринимается нами как единый
идентификатор, обозначающий человека. В действительности, как вы
понимаете, мы имеем дело с тремя
отдельными характеристиками человека. А что же, - спросите вы, - помешает нам
записывать эти характеристики в одном столбце таблицы? В общем, то, ничего, но
вот определенные проблемы в программировании возникнут. Причем проблемы совсем
не простые, как может показаться на первый взгляд. Действительно, данные придется вводить
оператору и быть может не одному. Ошибившись, оператор может перепутать последовательность
ввода характеристик. Как в этом случае программно можно будет отличать эти характеристики друг от друга. Почти безнадежная задача. Не будете же вы
писать, в самом деле, для этого лексический анализатор. Да скажете вы, но можно поступить следующим
образом: разделить ввод этих характеристик, но помещать их при этом в одну
строку. Это действительно выход, но согласитесь с тем, что нагрузка на программирование все же возрастет. Если же каждую характеристику мы разместим в
отдельном столбце, то выше указанных
проблем не возникнет. И так, мы приходим к следующей таблице: <fam, imja, otch,
zarplata, doljnost>.
На поверку и поле zarplata оказывается не простым элементом. Действительно, зарплата это факт выдачи
денег. Этот факт характеризуется несколькими параметрами: суммой, датой выдачи,
периодом, за который деньги выдаются. Последняя характеристика также может не
быть атомарной, так как период часто
приходится задавать двумя датами. Таким образом, и этот столбец совсем не прост
и имеет сложную структуру.
Наконец задание должности совсем не
ограничивается только ее названием. Важно, когда работник вступил в эту должность. Кроме этого,
заметим, что в течение работы в данной организации работник может многократно
менять должности. Другими словами такая характеристика, как и зарплата, имеет
историю.
В результате наших рассуждений мы
приходим к следующей таблице: <fam, imja, otch, z_sum,
z_date, z1_date, z2_date, doljn,
d_date>.
Вот описание столбцов новой таблицы: fam – фамилия, imja – имя, otch – отчество, z_sum – сумма зарплаты, z_date – дата выдачи зарплаты, z1_date – начало периода, за который выдается зарплата, z2_date – конец периода, за который выдается заплата, doljn – название должности, d_date – дата вступление
в должность. Я еще пощадил читателя,
так как и фамилия, это такая характеристика, которая также может иметь историю,
что правда в большинстве информационных систем игнорируется.
Получившаяся в результате наших
рассуждений таблица конечно не удобна
для программирования. Действительно, поскольку зарплату работник получает
неоднократно, то строки с одинаковыми значениями полей fam, imja, otch, doljn,
d_dolj
будут повторяться. То же можно сказать,
хотя и в меньшей степени, относительно
такой характеристика, как должность, поскольку некоторые работники время от времени
должность меняют. Но это уже другая история, связанная с другими нормальными
формами и об этом речь пойдет далее.
Разобранный пример далеко не уникален.
Типичной характеристикой, с которой часто начинающие проектанты попадают впросак, является адрес. Попытка представить
адрес в виде одного столбца, в конце концов, приводит серьезным программистским
трудностям.
Мне бы хотелось обратить внимание
читателя на один важный момент. Возникнет или не возникнет проблема при попытке
представить ту или иную характеристику в виде одного столбца целиком и
полностью связана с постановкой задачи. Если постановка задачи такова, что в
ней адрес всегда представляется единым целым (что, честно говоря,
маловероятно), то, конечно, есть смысл потратить на эту характеристику только
один столбец. Есть правда еще одна
причина, по которой сложную характеристику можно рассматривать как единое целое
– если в вашем распоряжении имеется развитый аппарат управления этой
характеристикой и ее отдельными частями.
Примерами таких характеристик являются такие типы данных как дата, время,
дата-время, промежуток и т.п. Как
правило, во всех современных СУБД имеется набор функций, для работы с такими
типами столбцов, по этой причине мы, не задумываясь, используем столбцы типа date, datetime и т.п.