Шаг 1: приведение к 1НФ

На первом шаге задается одно или несколько отношений, отображающих понятия ПО. По модели ПО (а не по внешнему виду полученных отношений!) выписываются обнаруженные ФЗ. Все отношения автоматически находятся в 1НФ.

Шаг 2: приведение к 2НФ

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

Исходное отношение R (K1, K2, A1, An, B1, Bm)

ФЗ: {К1, К2} – { A1, An, B1, Bm} – зависимость всех атрибутов от ключа отношения.

{К1}-{ A1, An} – зависимость некоторых атрибутов от части составного ключа.

Декомпозированные отношения:

R1 (K1, K2, B1, Bm) – остаток от исходного отношения.

R2 (K1, A1, An) – атрибуты, вынесенные из исходного отношения вместе с часть составного ключа.

Шаг 3: приведение к 3НФ

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

Исходное отношение R (K, A1,... An, B1, Bm)

ФЗ: {К} – { A1, An, B1, Bm}- зависимость всех атрибутов от ключа отношения.

{ A1, An} – {B1, Bm} – зависимость некоторых атрибутов от других неключевых атрибутов.

Декомпозированные отношения:

R1 (K, А1, Аm) – остаток от исходного отношения

R2 (A1, An, B1, Bm) – атрибуты, вынесенные из исходного отношения вместе с детерминантом ФЗ.

PS1. На практике, при создании логической модели данных, как правило, не следуют этому алгоритму. Опытные разработчики обычно строят отношения сразу в 3НФ. Но этот механизм важен, так как модель ПО никогда не бывает правильна разработана с первого шага. Поэтому надо после каждого изменения проверять остались ли отношения в 3НФ.