ItemInShop(ShopID, address, suburb, postcode, phonenumber, itemid, description, price, quantityinstock)

Transcription

1 ItemInShop(ShopID, address, suburb, postcode, phonenumber, itemid, description, price, quantityinstock) Business rules: An item can be sold in many shops. A shop can have many items. Each shop is identified by a Shop ID and will have further attributes such as address, suburb, postcode and phone number. Each item has a unique identifier and also a description, price and quantity in stock at each shop. Each postcode is for one specific suburb only. What are the Functional dependencies for this business? ShopID->address, suburb, postcode, phonenumber itemid->description, price What is the Primary key of the ItemInShop relation? Only {ShopID,itemID} can determine all other attributes. What normal form is this relation in? 1NF as there exists partial dependencies on the primary key. Description & price only depend on part of the primary key - itemid. Address, suburb & phone number only depend on part of the primary key - ShopID. Since this relation is not in 4NF it should be decomposed.

2 Decomposition the 5 steps. Step 1. List all FDs ShopID->address, suburb, phonenumber itemid->description, price Step 2. List FDs as singletons ShopID->address ShopID->suburb ShopID->phoneNumber itemid->description itemid->price Step 3. Remove redundant FDs. Suburb can be determined two ways so one of these FDs must be removed: ShopID->suburb In selecting the FD to remove we must be careful to preserve dependencies, i.e. ensure the determinant can still determine the attribute value on the right hand side of the arrow. If we remove '' can postcode still determine suburb? No. Then we can't remove it as we would not be preserving dependencies. Postcode must retain its POWER to determine suburb.

3 If we remove 'ShopID->suburb' can ShopID still determine suburb? Yes. Via transitivity: which is the same as: ShopID-> So we can safely remove this FD. The resultant set of FDs is known as our Minimal Basis: ShopID->address ShopID->phoneNumber itemid->description itemid->price Step 4. Create a relation for each FD in our Minimal Basis and give each one a primary key based on the determinant. relation1(shopid, address) relation2(shopid, postcode) relation3(postcode, suburb) relation4(shopid, phonenumber) relation5(itemid, description) relation6(itemid, price) relation7(shopid, itemid, quantityinstock)

4 Now merge any relations that have the exact same primary key: relation1(shopid, address) relation2(shopid, postcode) relation4(shopid, phonenumber) Becomes: Shop(ShopID, address, postcode, phonenumber) relation5(itemid, description) relation6(itemid, price) Becomes: Item(itemID, description, price) Step 5. Create a new relation for the Primary key of the original relation if it does not exist in relations we have created in Step 4. What is the Primary key of our original relation? {ShopID,itemID} Does it exist already? Yes, here: relation7(shopid, itemid, quantityinstock) So skip this step. Final schema: Shop(ShopID, address, postcode*, phonenumber) postcode(postcode, suburb) Item(itemID, description, price) quantity(shopid*, itemid*, quantityinstock) Don t forget to add in foreign keys(*). If an attribute exists as a Primary key in a relation that would appear to be its place of origin(where it was born), then make it foreign in any other relation that uses it.

5 Now the relation is fully decomposed into relations that are in 4NF. Don't believe me? Then test each one against the chart. When you decompose a schema, afterwards, it should pass this test, or you are doing it wrong. So try again. Any questions, me on: adrian.luke@rmit.edu.au