C170 VHT1.docx C170 VHT1 A1A. TABLE IN FIRST NORMAL FORM Using the sales order form, I

C170 VHT1.docx  C170 VHT1  A1A. TABLE IN FIRST NORMAL FORM  Using the sales order form, I created a dataset from the given information.  I decided to use a composite primary key since both keys could uniquely identify the data for the table.  I ensured there were no repeating groups by splitting the address requirements into their own attributes.  A1B.  TABLE IN SECOND NORMAL FORM  Since I used a composite (multivalued) primary key in the first normal form, I knew I should look for dependencies on the keys.  To resolve the dependencies, I split the attributes into three separate tables.  Doing this resolved the dependency issues and created separate tables for Donut Order, Quantity, and Donut.  A1C. NORMALIZED TABLE IN THIRD NORMAL FORM  To ensure normalization to the third normal form, there should be no transitive dependencies so these needed to be removed.  This was solved by creating a Customer table using the Customer ID as a primary key, and using it as a foreign key in the Donut Order table.  B1 €“ B4 ER DIAGRAM  The entities in the diagram are taken from the tables created in A1C.  The Customer and Donut tables are each entities that have a single primary key and related attributes that describe them.  DonutOrder and Quantity tables are associative and represent the interactive relationship of Customer and Donut.  The Quantity table has a multivalued Primary Key (DOrderID and DonutID) that also act as a Foreign Key.  Customer and DonutOrder tables have a 1:N (one to many) cardinality