Scribd Logo
Upload

Welcome to Scribd!

  • 5K views

    List The Functional Dependencies in The Following Table

    Uploaded by

    Mark Kludge
    The document describes a table called INVOICE that contains invoice information like customer details, invoice date, and item details. It lists the functional dependencies and converts the table to third normal form (3NF). The normalized tables are CUSTOMER, PART, INVOICE, and INVOICE_LINE, each with a primary key and foreign keys as needed.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd

    List The Functional Dependencies in The Following Table

    Uploaded by

    Mark Kludge
    5K views3 pages
    The document describes a table called INVOICE that contains invoice information like customer details, invoice date, and item details. It lists the functional dependencies and converts the table to third normal form (3NF). The normalized tables are CUSTOMER, PART, INVOICE, and INVOICE_LINE, each with a primary key and foreign keys as needed.

    Original Title

    List the functional dependencies in the following table

    Copyright

    © Attribution Non-Commercial (BY-NC)

    Available Formats

    DOCX, PDF, TXT or read online from Scribd

    Did you find this document useful?

    Is this content inappropriate?

    The document describes a table called INVOICE that contains invoice information like customer details, invoice date, and item details. It lists the functional dependencies and converts the table to third normal form (3NF). The normalized tables are CUSTOMER, PART, INVOICE, and INVOICE_LINE, each with a primary key and foreign keys as needed.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    5K views3 pages

    List The Functional Dependencies in The Following Table

    Uploaded by

    Mark Kludge
    The document describes a table called INVOICE that contains invoice information like customer details, invoice date, and item details. It lists the functional dependencies and converts the table to third normal form (3NF). The normalized tables are CUSTOMER, PART, INVOICE, and INVOICE_LINE, each with a primary key and foreign keys as needed.

    Copyright:

    Attribution Non-Commercial (BY-NC)
    Download as DOCX, PDF, TXT or read online from Scribd
    Download as docx, pdf, or txt
    You are on page 1of 3
    At a glance
    Powered by AI
    The passage discusses converting relational database tables from first normal form to third normal form by identifying functional dependencies and splitting the tables accordingly.

    The functional dependencies described in the first table are: INVOICE NUMBER -> CUSTOMER_NUMBER, CUSTOMER LAST, CUSTOMER FIRST, etc. and CUSTOMER_NUMBER -> CUSTOMER LAST, CUSTOMER FIRST, etc. PART_NUMBER -> PART DESCRIPTION, PRICE, NUMBER SHIPPED.

    The steps taken are to split the table into four tables - CUSTOMER, PART, INVOICE, and INVOICE_LINE with appropriate primary and foreign keys to ensure each table is in third normal form.

    List the functional dependencies in the following table, subject to the specified conditions.

    Convert this table to an


    equivalent collection of tables that are in third normal form (3NF).

    INVOICE (INVOICE NUMBER , CUSTOMER_NUMBER, LAST, FIRST,

    STREET, CITY, STATE, ZIP_CODE, INVOICE_DATE, (PARTNUMBER,

    PARTDESCRIPTION, UNIT_PRICE, NUMBER_SHIPPED))

    This table concerns invoice information. For a given invoice (identified by the invoice number) there will be a single
    customer. The customer's number, name, and address appear on the invoice as well as the invoice date. Also, there
    may be several different parts appearing on the invoice. For each part that appears, the Part Number, Part
    Description, Unit Price, and Number Shipped will be displayed. The price is from the current master price list.

    The functional dependencies are described below:

    INVOICE NUMBER  CUSTOMER_NUMBER , CUSTOMER LAST , CUSTOMER FIRST, STREET , CITY , STATE
    , ZIP_CODE , INVOICE_DATE

    CUSTOMER_NUMBER CUSTOMER LAST , CUSTOMER FIRST , STREET , CITY , STATE , ZIP_CODE

    PART_NUMBER  PART DESCRIPTION , PRICE , NUMBER SHIPPED

    The tables in 3NF forms are:

    CUSTOMER table
    Primary Key: CUSTOMER_NUMBER
    Table: (CUSTOMER_NUM , LAST_NAME , FIRST_NAME , STREET , CITY , STATE, ZIP_CODE)
    Foreign Key: None
    Normal Form: 3NF

    PART table:
    Primary Key: PART_NUM
    Table: (PART_NUM , PART_DESCRIPTION , PART_PRICE)
    Foreign Key: None
    Normal Form: 3NF

    INVOICE table: (INVOICE_NUMBER , INVOICE_DATE , CUSTOMER_NUMBER)


    Primary key: INVOICE_NUMBER
    Foreign key: CUSTOMER_NUMBER (to table CUSTOMER)
    Normal form: 3NF

    INVOICE_LINE table:
    Primary key: INV_NUM, PROD_NUM , NUMBER_SHIPPED
    Foreign keys: INV_NUM (to table INVOICE) , PROD_NUM (to table PRODUCT)
    Normal Form: 3NF
    2- Using your knowledge of a college environment, determine the functional dependencies that exist in the following
    table. After these have been determined, convert this table to an equivalent collection of tables that are in 3NF.

    STUDENT (STUDENT_NUMBER, STUDENT_NAME, NUMBER_CREDITS, ADVISOR_NUMBER,


    ADVISOR_NAME, DEPT_NUMB, DEPT_NAME,(COURSE_NUMBER, COURSE_DESCRIPTION, COURSE_TERM,
    GRADE))

    The functional dependencies are described below:

    STUDENT_NUMBER--> STUDENT_NAME, NUMBER_CREDITS, ADVISOR_NUMBER, ADVISOR_NAME,


    DEPT_NUMB, DEPT_NAME

    ADVISOR_NUMBER--> ADVISOR_NAME, DEPT_NUMB, DEPT_NAME

    STUDENT_NUMBER, COURSE_NUMBER--> COURSE_DESCRIPTION, COURSE_TERM, GRADE

    The table is now in 1NF, but not in 2NF as Student Name is only dependent on Student Number – only a portion of
    the primary key.

    CONVERT TABLE TO 2NF BY STARTING A TABLE WITH EACH SUBSET AS ITS KEY:

    (STUDENT_NUMBER,
    (COURSE_NUMBER,
    (STUDENT_NUMBER, COURSE_NUMBER

    With the least collection needed, we will put in the remaining attributes:

    (STUDENT_NUMBER, STUDENT_NAME, NUMBER_CREDITS, ADVISOR_NUMBER,


    ADVISOR_NAME, DEPT_NUMB, DEPT_NAME)
    (COURSE_NUMBER, COURSE_DESCRIPTION)
    (STUDENT_NUMBER, COURSE_NUMBER, COURSE_TERM, GRADE)

    Assigning table names:


    STUDENT (STUDENT_NUMBER, STUDENT_NAME, NUMBER_CREDITS,
    ADVISOR_NUMBER, ADVISOR_NAME, DEPTNUMB, DEPTNAME)
    COURSE (COURSE_NUMBER, COURSE_DESCRIPTION)
    GRADE (STUDENT_NUMBER, COURSE_NUMBER, COURSE_TERM, GRADE)

    These tables are all in 2NF; but COURSE and GRADE are also in 3NF. STUDENT, however, is not, as it still
    contains a determinant – Advisor Number – that is not a candidate key. STUDENT still needs to be converted to 3NF.
    Remove the attributes that depend on the determinant Advisor Number and put in a separate table.

    (STUDENT_NUMBER, STUDENT_NAME, NUMBER_CREDITS,


    ADVISOR_NUMBER)
    (ADVISOR_NUMBER, ADVISOR_NAME, DEPTNUMB, DEPTNAME)

    Name these two tables, and put all the tables together:

    STUDENT (STUDENT_NUMBER, STUDENT_NAME, NUMBER_CREDITS,


    ADVISOR_NUMBER)
    ADVISOR (ADVISOR_NUMBER, ADVISOR_NAME, DEPTNUMB, DEPTNAME)
    COURSE (COURSE_NUMBER, COURSE_DESCRIPTION)
    GRADE (STUDENT_NUMBER, COURSE_NUMBER, COURSE_TERM, GRADE)

    You might also like

    pFad - Phonifier reborn

    Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

    Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


    Alternative Proxies:

    Alternative Proxy

    pFad Proxy

    pFad v3 Proxy

    pFad v4 Proxy