 |
Проверка модели с помощью правил нормализации
|
|
|
|
На этом этапе необходимо проверить созданный для представления пользователя «начальник склада» приложения «Сборочное предприятие» набор отношений на соответствие всем требованиям процедуры нормализации отношений и включает следующие действия:
n приведение к 1НФ, позволяющее удалить из отношений повторяющиеся группы атрибутов:
n приведение ко 2НФ, позволяющее устранить частичную зависимость атрибутов от первичного ключа;
n приведение к 3НФ, позволяющее удалить транзитивную зависимость атрибутов от первичного ключа;
n приведение к нормальной форме Бойса-Кодда, позволяющее удалить из функциональных зависимостей оставшиеся аномалии
Чтобы убедиться, что каждое из отношений находятся, как минимум, в НФБК, проанализируем функциональные зависимости между этими отношениями.
IZDEL (K_IZDEL, IZDEL, KHAR, ZENA_ED)
Pr. key K_IZDEL
K_IZDELà IZDEL, KHAR, ZENA_ED;
KOMP (K_KOMP, KOMP, KHAR, ZENA_ED)
Pr. key K_KOMP
K_KOMPà KOMP, KHAR, ZENA_ED;
POKUP (K_POKUP, POKUP, GOROD, ADR);
Pr. key K_POKUP
K_POKUPà POKUP, GOROD, ADR;
PSTV (K_PSTV, PSTV, GOROD, ADR)
Pr. key K_PSTV
K_PSTVà PSTV, GOROD, ADR;
POST (N_POST, K_KOMP, K_PSTV, KOLVO, DATA_POST)
Pr. key N_POST
N_POSTà K_KOMP, K_PSTV, KOLVO, N_SKLAD, DATA_POST;
OTGR (N_OTGR, K_IZDEL, K_POKUP, KOLVO, DATA_OTGR)
Pr. key N_OTGR
N_OTGR à K_IZDEL, K_POKUP, N_SKLAD, KOLVO, DATA_OTGR;
SKLAD (N_SKLAD, FIO K_KOMP, K_DET, KOLVO, DATA_OPER);
N_SKLAD, K_KOMP, DATA_OPERà FIO, KOLVO;
Видим, что все эти отношения не содержат повторяющихся групп атрибутов и не имеют атрибутов, частично или транзитивно зависящих от первичных ключей этих отношений. Единственное, отношение SKLAD не находится в НФБК, но как мы видим оно не будет подвержено аномалиям обновления.
Спецификация требований представления пользователя «Менеджер по поставкам и по реализации».
Требования к данным
|
|
|
1. Предприятие заключает договора на продажу готовых изделий с другими организациями.
2. Каждая такая организация является покупателем, информация о котором содержит сведения об уникальном номере, названии, городе и адресе.
3. В обязанности менеджера входит составление договора на продажу. В этот документ входят план продажи на год, распределение плана по всем месяцам и дате начала действия договора. Каждый такой документ имеет уникальный номер.
4. Сведения об изделиях содержат информацию о его уникальном номере, названии, характеристики и цене за единицу продукции.
5. Предприятие не все составляющие двигателя изготавливает само. Часть сырья и деталей оно закупает у других предприятий.
6. Эти предприятия являются поставщиками. В информацию и них входит уникальный номер, название, город и адрес.
7. В обязанности менеджера по поставкам входит заключение договора с поставщиками на поставку сырья и компонентов.
8. Каждый такой договор имеет уникальный номер, план поставки на год, распределение по всем месяцам и дате начала действия договора.
9. Каждая поставляемая деталь характеризуется кодом, названием, характеристикой и ценой за единицу продукции.
Построение локальной концептуальной модели данных для представления пользователя «менеджер по поставкам и по продаже».
Определение типов сущностей
Договор DOGOVOR
Заказ ZAKAZ
Изделие IZDEL
Материалы KOMP
Покупатель POKUP
Поставщик PSTV
Определение типов связей
Тип сущности Тип связи Тип сущности
ZAKAZ заключается с POKUP
DOGOVOR заключается с PSTV
IZDEL отпускаются по ZAKAZ
KOMP поставляются по DOGOVOR
Теперь определим кардинальности и уровень участия этих типов сущностей в вышеперечисленных связях.
Связь ZAKAZàPOKUP.
Каждый договор на продажу изделий заключается с покупателем. Связь типа 1:1. Сущность ZAKAZ участвует в связи полностью.
|
|
|
Связь IZDELàZAKAZ. Кардинальность связи 1:M. Поскольку одно и о же изделие может продаваться по разным договорам. Степень участия IZDEL в данной связи частичная.
Связь DOGOVORàPSTV. Кардинальность этой связи 1:1, так как каждый договор заключается только с одним поставщиком. Сущность DOGOVOR участвует в этой связи полностью.
Связь KOMPàDOGOVOR.
Кардинальность связи KOMPàDOGOVOR 1:M, так как одна и та же деталь может поставляться по нескольким договорам.
Определение атрибутов и связывание их с типами сущностей.
Тип сущности Атрибут
IZDEL K_IZDEL (код изделия)
IZDEL (наименование)
KHAR (характеристика)
ZENA_ED (цена за ед.)
POKUP K_POKUP (код покуп.)
POKUP (название)
GOROD (город)
ADR (адрес)
ZAKAZ N_ZAK (№ документа)
PLAN_GOD (план на год)
YAN, FEV, MART…
DATA_ZAK (дата начала договора)
PSTV K_PSTV
PSTV
GOROD
ADR
KOMP K_KOMP
KOMP
GOROD
ADR
DOGOVOR N_DOG (№ договора)
PLAN_GOD (план на год)
YAN, FEV, MART…
DATA_DOG (дата начала действия)
Определение атрибутов, являющихся потенциальными и первичными ключами.
Тип сущности Первичный ключ Потенц. ключ
PSTV K_PSTV GOROD, ADR
KOMP K_KOMP KOMP
DOGOVOR N_DOG
ZAKAZ N_ZAK
POKUP K_POKUP GOROD,ADR
IZDEL K_IZDEL IZDEL
Построение локальной логической модели данных для представления пользователя «менеджер по продаже и по поставкам».
На этом этапе обычно удаляются из концептуальной модели данных структуры, реализация которых в СУБД реляционного типа была бы затруднительна. Но, как видно, в нашем случае таких структур нет, т.е. нет связей типа M:N, сложных и рекурсивных связей. Поэтому сразу перейдем к следующему этапу.
Определение набора отношений. Напомню, что на данном этапе создаются отношения, представляющие сущности и связи локальной логической модели данных представления пользователя «менеджер по продаже и по поставкам». Связи между сущностями моделируются с помощью механизма первичных ключей и внешних ключей.
POKUP (K_POKUP, POKUP, GOROD, ADR)
Primary key K_POKUP
PSTV (K_PSTV, PSTV, GOROD, ADR)
Primary key K_PSTV
IZDEL (K_IZDEL, IZDEL, KHAR, ZENA_ED)
Primary key K_IZDEL
KOMP (K_KOMP, KOMP, KHAR, ZENA_ED)
|
|
|
Primary key K_KOMP
DOGOVOR (N_DOG, K_PSTV, K_KOMP, RLAN_GOD, YAN, FEV,…, DATA_DOG)
Primary key N_DOG
ZAKAZ (N_ZAK, K_POKUP, K_IZDEL, PLAN_GOD, YAN, FEV, …, DATA_DOG)
Primary key N_ZAK
Проверка модели с помощью правил нормализации
IZDEL (K_IZDEL, IZDEL, KHAR, ZENA_ED)
Pr. Key K_IZDEL
K_IZDELàIZDEL, KHAR, ZENA_ED
POKUP (K_POKUP, POKUP, GOROD, ADR)
Pr.key K_POKUP
K_POKUPàPOKUP, GOROD, ADR;
KOMP (K_KOMP, KOMP, KHAR, ZENA_ED)
Pr.key K_KOMP
K_KOMPà KOMP, KHAR, ZENA_ED;
PSTV (K_PSTV, PSTV, GOROD, ADR)
Pr. Key K_PSTV
K_PSTVà PSTV, GOROD, ADR;
DOGOVOR (N_DOG, K_KOMP, K_PSTV, PLAN_GOD, YAN, FEV,…, DATA_DOG)
Pr. key N_DOG
N_DOGà K_KOMP, K_PSTV, PLAN_GOD, YAN,…, DATA_DOG;
ZAKAZ (N_ZAK, K_IZDEL, K_POKUP, PLAN_GOD, YAN, FEV,…, DATA_DOG)
Pr. key N_ZAK
N_ZAK à K_IZDEL, K_POKUP, PLAN_GOD, YAN,…, DATA_DOG;
Таким образом, мы видим, что все три отношения не содержат ни повторяющихся групп, ни атрибутов, частично или транзитивно зависящих от первичных ключей этих отношений. Более того, каждая из сущностей имеет только один детерминант, который является первичным ключом в соответствующем отношении. В результате можно сделать вывод, что эти отношения находятся в НФБК.
|
|
|
