Scribd Logo
Upload

Welcome to Scribd!

  • Account Normal Is at Ion

    Uploaded by

    Jay Fernz
    3 views2 pages
    The document describes normalizing a database to eliminate redundant data and solve issues with updates and deletes. It involves separating customer information, product information, and account information into three separate tables - Product, Customer, and Account. This eliminates repeating the customer data in each account and solves problems if a customer's information like their number needs to be changed or if they close their accounts. The resulting tables meet both 2NF and 3NF standards.

    Original Description:

    Original Title

    Account Normal is at Ion

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    Report this Document
    The document describes normalizing a database to eliminate redundant data and solve issues with updates and deletes. It involves separating customer information, product information, and account information into three separate tables - Product, Customer, and Account. This eliminates repeating the customer data in each account and solves problems if a customer's information like their number needs to be changed or if they close their accounts. The resulting tables meet both 2NF and 3NF standards.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    3 views2 pages

    Account Normal Is at Ion

    Uploaded by

    Jay Fernz
    The document describes normalizing a database to eliminate redundant data and solve issues with updates and deletes. It involves separating customer information, product information, and account information into three separate tables - Product, Customer, and Account. This eliminates repeating the customer data in each account and solves problems if a customer's information like their number needs to be changed or if they close their accounts. The resulting tables meet both 2NF and 3NF standards.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as PDF, TXT or read online from Scribd
    Flag for inappropriate content
    of 2

    CI2611 Data Server Technology Course work Account Example

    Scenario Customers open accounts and choose a given product type. Customers can have more than one account supposing they choose different products. No customer can have more than one account of the same product type. Un-normalised Relation Product (ProductNo, ProductDescription, * CustomerNo, CustomerName, Balance) Step 1 (1NF) Step 2 (2NF & 3NF)

    Product

    Account

    Customer

    Eliminate the redundant data for 2NF. Customer information is redundantly repeated in each account. Remove the customer information to a separate relation. This solves the update problem if you decide to change the Customer No for a given customer. Also the delete problem which causes the customer to disappear if she closes her accounts! Product (ProductNo, ProductDescription)

    Product

    Customer (CustomerNo, CustomerName)

    Account

    Account (ProductNo, CustomerNo, Balance) We dont have attributes not depending upon the key, in this case, so putting this in 2NF has also given us 3NF.
    *

    Account is a repeating group and needs to be removed to put the relation into 1NF. Product (ProductNo, ProductDescription) Account (ProductNo, CustomerNo, CustomerName, Balance)

    Representing a relation with the name of the relation followed by the attributes in brackets is a common convention. Normally, the primary key is underlined. ( See Connolly & Begg, 5th ed, p.101 ).

    You might also like