Scribd
Upload
10 views7 pages

Assignemnt 5

The document discusses database normalization, specifically focusing on converting a table into 1NF and 3NF. It highlights issues such as insert, delete, and modification anomalies that arise from the current structure. Additionally, it outlines the necessary relations to achieve 3NF and categorizes items into two types based on shipping requirements.

Uploaded by

Om Dhinoja
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
10 views7 pages

Assignemnt 5

The document discusses database normalization, specifically focusing on converting a table into 1NF and 3NF. It highlights issues such as insert, delete, and modification anomalies that arise from the current structure. Additionally, it outlines the necessary relations to achieve 3NF and categorizes items into two types based on shipping requirements.

Uploaded by

Om Dhinoja
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

Om Dhinoja dhinoja.o@northeastern.

edu
002832284 DMDD
Assignment - 5

4-34.

a. Table in 1NF:

Part No. Description Vendor Name Address Unit Cost


1234 Logic Chip Fast Chips Cupertino 10.00
1234 Logic Chip Smart Chips Phoenix 8.00
5678 Memory Chip Fast Chips Cupertino 3.00
5678 Memory Chip Quality Chips Austin 2.00
5678 Memory Chip Smart Chips Phoenix 5.00

b. Functional dependencies

Part no - Description
Vendor Name - Address
Part No, Vendor Name - Unit Cost
Candidate Key – Unit Cost

c.

Insert Anomaly: An insert anomaly will occur when you add a new vendor to the database. It will require
both the part number and the vendor's address, which might not always be practical. This issue arises
because it may be necessary to store incomplete vendor data, but the database structure forces the inclusion
of part information. As a result, vendor details are not stored independently, making it difficult to add new
vendors without complete data.

Delete Anomaly: If you need to remove the vendor "Fast Chips" from the table, you may also end up
deleting the record for "smart Chips" and "Quality Chips" since both vendors share the same part number
"5678" This leads to unintended data loss, which is not good for a well-structured database.
Modification Anomaly: If you need to update the address of the vendor "Fast Chips" from Cupertino to
New York, you will have to modify it in every record where "Fast Chips" appears in the table. This can be a
time-consuming task, especially if there are multiple entries for the same vendor in the database.
Om Dhinoja [email protected]
002832284 DMDD
d.

e. The relation is in the form of 1NF

f. To convert the relation in 3NF form, we need 3 relations as follows:


1. Part No, Description
2. Vendor Name, Address
3. Part No., Vendor Name, Unit Cost

g.

4 - 35.
Om Dhinoja [email protected]
002832284 DMDD
a.

b.
SEATING:
Seating_ID → (Nbr_of_Guests, Start_TimeDate, End_TimeDate)
RTABLE:
RTable_Nbr → (RTable_Nbr_of_Seats, RTable_Rating)
EMPLOYEE:
Employee_ID → ( Emp_Lname, Emp_Fname)
MANAGER:
Employee_ID → (Monthly_Salary)
WAITER:
Employee_ID → (Hourly_Wage, manager_employee_id)
ASSIGNMENT:
Seating_ID, Employee_ID → (Start_TimeDate, End_TimeDate, Tips_Earned)
USES:
Seating_ID, RTable_Nbr
Om Dhinoja [email protected]
002832284 DMDD
c. Employee id is the enterprise key

4 – 37

a.
Om Dhinoja [email protected]
002832284 DMDD

b. The relation is 1NF


c.
Om Dhinoja [email protected]
002832284 DMDD
d.

e.
Om Dhinoja [email protected]
002832284 DMDD
4 - 38. It is assumed that items can be categorized into two types: Type A and Type B. Type A refers to
regular items meant for shipping, while Type B represents fragile items that require careful handling during
shipment.

You might also like