Базы данных

Схемы S


Схема S1 находится в 3NF, а функциональные зависимости схемы S2 являются нарушениями 3NF. Поэтому необходимо провести декомпозицию схемы S2, чтобы устранить эти нарушения. Многочисленные нарушения ликвидируются поочередно. В первую очередь, можно устранить первое нарушение путем декомпозиции схемы S2 на следующие две схемы:

S3: (purchaseOrderld, supplierld, dateOrdered)

(S2 с удаленной правой частью функциональной зависимости)

S4: (supplierld, supplierName, street, city, state, zipcode)

(все участвующие в функциональной зависимости атрибуты).

Теперь схема S3 находится в 3NF, так как в ней отсутствуют зависимости между неключевыми атрибутами. Зависимости, связанные с ZIP-кодом, перемещены теперь в схему S4.

В схеме S4 две зависимости нарушают требования 3NF. Устранение любой из них приведет также и к удалению второй, так как они взаимозависимы. На этом этапе следует принять решение о выборе одного из двух вариантов. Удаление зависимости city и state от zipcode приводит к следующим схемам.

S5: (supplierld, supplierName, street, zipcode)

S6: (zipcode, city, state)

Удаление зависимости zipcode от адреса, города и штата приводит к следующим схемам.

S7: (supplierld, supplierName, street, city, state)

S8: (street, city, state, zipcode)

Очевидно, что лучше выбрать декомпозицию на S5 и S6 по сравнению с S7 и S8. Во-первых, схемы S7 и S8 содержат больше повторяющихся атрибутов. Во-вторых, три атрибута street, city и state образуют внешний ключ схемы S7. Так как внешние ключи используются для поиска сущности в схеме S8 по сущности из схемы S7, то состоящий из нескольких атрибутов внешний ключ будет приводить к существенному снижению эффективности и усложнению обслуживания.

Исходная схема Purchaselnfo была преобразована в четыре новые 3NF-cxeMbi: S1, S3, S5 и S6. Однако нельзя считать процесс нормализации завершенным, поскольку схемы имеют неподходящие имена. Анализ информационного содержимого  (и некоторые знания о том, как обычно называются подобные объекты) приводят к представленному на 5.8 набору завершенных реляционных схем. Заказ на покупку PurchaseOrder содержит ID заказа, ID поставщика и дату заказа. Это общая информация для всех пунктов определенного заказа на покупку. Схема PurchaseOrderDetail содержит заказываемые пункты и их количества. Две последние схемы на 5.8 содержат информацию о поставщике.

PurchaseOrder: (PurchaseOrderld, supplierld, dateOrdered) PurchaseOrderDetail: (PurchaseOrderld, movield, title, quantity) Supplier: (supplierld, supplierName, street, zipcode)

Zipcode: (zipcode, city, state)

Puc. 5.8. 3NF-cxeMbi, полученные в результате нормализации Purcahselnfo

Комментарии закрыты