Логическая структура данных планирования

4.2 Логическая структура данных планирования

После создания всех сущностей и атрибутов, необходимых для описания всего документооборота начинается разработка логической модели базы данных. Внесение сущностей и их атрибутов в логическую модель осуществляется путем импорта данных из BPwin в Erwin. Сущности и их атрибуты, определенные в BPwin переместятся в логическую модель в ERwin. Импортированные сущности не имеют первичного ключа и не связаны друг с другом. Назначение атрибутов первичным ключом и связывание сущностей осуществляется только средствами Erwin, т. е. сущности и атрибуты, созданные в BPwin и затем импортированные в Erwin, рассматривают как заготовку для создания полноценной модели данных, а не как готовую модель (см. рис. 4.1).

Рис. 4.1. Модель данных после импорта сущностей и атрибутов

После описания сущностей и атрибутов производится связка сущностей. На логическом уровне можно установить идентифицирующую связь один ко многим, связь многие ко многим и неидентифицирующую связь один ко многим.

При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности (миграция атрибутов). В дочерней сущности они помечаются как внешний ключ - (FK). При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов родительской сущности.

В результате выполнения этих действий получаем ненормализованную логическую модель данных (см. рис. 4.2).

Далее необходимо нормализовать модель данных. В результате проведения нормализации создадим структуру данных, при которой информация о каждом факте хранится только в одном месте. Процесс нормализации сводится к последовательному приведению структур данных к нормальным формам.

Процесс нормализации логической модели данных продемонстрируем на примере приведения сущностей «TWORKORDER», «TPLAN» к нормальным формам.

Первая нормальная форма требует, чтобы все атрибуты были атомарными. Для этого атрибут "FC_ADRESS" был разбит на атрибуты "FC_COUNTRY", "FC_REGION", "FC_TOWN", "FC_STREET", "FC_OFIS" и добавлен атрибут “FP_TYPE” для определения типа документа. (см. рис. 4.3)

Рис. 4.3. Модель данных после нормализации первой формы

Вторая нормальная форма требует, чтобы каждый неключевой атрибут зависел от всего первичного ключа, не должно быть зависимости от части ключа. Для приведения ко второй нормальной форме создадим новую сущность «TPLAN», в которую перенесем атрибуты “FC_FAM”, “FC_NAME”, “FN_KOLV”, “FC_OTKLON”, «FN_SALARY», зависящие от части ключа (“FN_TAB_NUM”). В новой сущности создаем новый первичный ключ «FK_PLANID» и устанавливаем идентифицирующую связь от новой сущности к старой, аналогично выделяем сущность «TADRESS» (см. рис. 4.4).

Рис. 4.4. Модель данных после нормализации второй формы