Пример проектирования

        Рассмотрим этапы проектирования базы данных, которые должны обеспечить необходимую независимость данных и выполнение эксплуатационных требований (пожеланий пользователей).

        В качестве примера рассмотрим проектирование базы данных по продажам, которая включает информацию о товарах, покупателях, заказах и сотрудниках.
 
        В рамках поставленной задачи определим сущности
                    КЛИЕНТ
                    ТОВАР
                    ТИП ТОВАРА
                    ЗАКАЗАНО
                    ЗАКАЗ
                    ПРОДАВЕЦ
 
        Рассмотрим классический подход, при котором процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая.
        Приведение модели к требуемому уровню нормальной формы является основой построения реляционной БД. В процессе нормализации элементы данных группируются в таблицы,  представляющие объекты и их взаимосвязи.
        Теория нормализации основана на том, что определенный набор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем все остальные наборы таблиц, с помощью которых могут быть представлены те же данные.
        Введение нормализации отношений при разработке информационной модели обеспечивает минимальный объем физической, то есть записанной на каком-либо носителе БД и ее максимальное быстродействие, что впрямую отражается на качестве функционирования информационной системы.
        Нормализация информационной модели выполняется в несколько этапов.
 
Данные, представленные в виде двумерной таблицы, не содержащей повторяющихся групп, являются первой нормальной формой реляционной модели данных. 
 
        Первый этап нормализации заключается в образовании двумерной таблицы, содержащей все необходимые атрибуты информационной модели, и в выделении ключевых атрибутов. Очевидно, что полученная весьма внушительная таблица будет содержать очень разнородную информацию. В этом случае будут наблюдаться аномалии включения, обновления и удаления данных, так как при выполнении этих действий нам придется уделить внимание данным (вводить или заботиться о том, чтобы они не были стерты), которые не имеют к текущим действиям никакого отношения. Например, может наблюдаться такая парадоксальная ситуация: при включении в каталог продаж нового товара нам сразу придется указать купившего ее клиента.
        В нашем примере определим атрибуты:
         код_клиента, компания, фамилия, имя, отчество, должность, телефон, почтовый_индекс, страна, область, город, адрес, дополнительные_сведения;
        номер заказа, дата заказа, количество_заказанного товара, дата_ продажи, количество_проданного товара;
        код_сотрудника; имя_сотрудника;
        группа_товара, код_товара, наименование_товара, цена, примечания
 
        Для устранения повторяющихся групп создадим уникальный индекс, содержащий код_клиента.
        Так как каждый клиент может сделать несколько заказов, в каждый из которых могут быть включены несколько товаров, разобъем нашу таблицу на три, содержащие:
        1. сведения о клиентах;
        2. номер и дата заказа, данные о сотруднике;
        3. код, наименование, количество заказанных и проданных товаров.


 
Отношение задано во второй нормальной форме, если оно является отношением в первой нормальной форме и каждый неключевой атрибут полностью зависит от возможных ключей. 
        Если все возможные ключи отношения содержат по одному атрибуту, то это отношение задано во второй нормальной форме, так как в этом случае все атрибуты, не являющиеся первичными, полностью зависят от возможных ключей.
        Если ключи состоят более чем из одного атрибута, отношение, заданное в первой нормальной форме, может не быть отношением во второй нормальной форме.
        Приведение отношений ко второй нормальной форме заключается в обеспечении полной функциональной зависимости всех атрибутов от ключа за счет разбиения таблицы на несколько, в которых все имеющиеся атрибуты будут иметь полную функциональную зависимость от ключа этой таблицы.
        В нашем примере в таблице ЗАКАЗЫ использован составной ключ. Поля название_товара, цена, группа_товаров однозначно определяются одним из ключевых полей. Для приведения этой таблице ко второй нормальной форме, выделим эти поля в отдельную таблицу ТОВАРЫ.

        В процессе приведения модели ко второй нормальной форме в основном исключаются аномалии дублирования данных.
 
Отношение задано в третьей нормальной форме, если оно задано во второй нормальной форме и каждый атрибут этого отношения, не являющийся первичным, не транзитивно зависит от каждого возможного ключа этого отношения. 
        Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С - три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А.
        Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два.
        Иначе можно сформулировать так: для третьей нормальной формы требуется, чтобы все неключевые столбцы зависели от первичного ключа, но были независимы друг от друга.
        В нашем примере выделим из таблицы ЗАКАЗАНО информацию о продавце.


 
        Многие разработчики не приводят базу данных к четвертой и пятой нормальным формам, считая их сложными или же применимыми лишь в особых случаях. Отказ от приведения к четвертой нормальной форме обычно приводит к неэффективной структуре базы данных, которая все же позволяет решить поставленную задачу.
 
Четвертая нормальная форма: в одной таблице не содержатся независимые элементы данных, если между ними существует отношение «многие-ко-многим»
 
Для пятой нормальной формы требуется, чтобы можно было восстановить исходную таблицу на основе информации таблиц, на которые она была разбита.
 
        На практике довольно редко встречаются случаи, когда таблица в четвертой нормальной форме не соответствует пятой нормальной форме.