Presentation is loading. Please wait.

Presentation is loading. Please wait.

Relation StudentAdvisor ( St_id, St_fname, St_lname, St_major, Semester, Adv_fname, Adv_lname, Adv_email, Adv_dept, Adv_id) Primary Key: St_id, Semester.

Similar presentations


Presentation on theme: "Relation StudentAdvisor ( St_id, St_fname, St_lname, St_major, Semester, Adv_fname, Adv_lname, Adv_email, Adv_dept, Adv_id) Primary Key: St_id, Semester."— Presentation transcript:

1 Relation StudentAdvisor ( St_id, St_fname, St_lname, St_major, Semester, Adv_fname, Adv_lname, Adv_email, Adv_dept, Adv_id) Primary Key: St_id, Semester Find Functional Dependencies: St_id --> St_fname, St_lname Adv_id -> Adv_fname, Adv_lname, Adv_email, Adv_dept Adv_email -> Adv_ID St_id, Semester -> St_Major, AdvID, Adv_fname, Adv_lname, Adv_email, Adv_dept, St_fname, St_lname StMajor -> AdvDept Students are allowed to change their major, So same student can have different majors in different semesters.

2 2NF: checking and normalizing To check if in 2NF: if the primary key is simple (i.e. consists of a single attribute) – then YES, it is in 2NF If the primary key is composite (consists of more than 1 attribute) does any attribute depend on just a part of the primary key (or, stated differently, is there any functional dependency with a part of the key on the left side)? If the answer is no, then YES, it’s in 2NF. Otherwise, it is not in 2NF Find all functional dependencies on attribute, which is a part of the key, but not the whole key St_id --> St_fname, St_lname To Normalize into 2NF Create a separate table for the attributes that depend on just a part of the key. Remove these attributes from the original relation. Add their determinant to the new table. Determinant becomes PK of new table. Add a FK (ref integrity ) constraint from the original table to the new one. Original Relation : StudentAdvisor ( St_id, St_fname, St_lname, St_major, Semester, Adv_fname, Adv_lname, Adv_email, Adv_dept, Adv_id) New Design in 2 NF : STUDENT(St_id, St_fname, St_lname ) STUDENTADVISor( St_id, St_major, Semester, Adv_fname, Adv_lname, Adv_email, Adv_dept, Adv_id)

3 3NF: checking and normalizing To check if in 3NF: Does any attribute depend on a non-key attribute (or, stated differently, is there any functional dependency with a non-key on the left side)? If no, then there are not transitive dependencies and YES, it’s in 3NF. Otherwise, there is a transitive dependency and it is therefore not in 3NF Find all functional dependencies on a non-key attribute Adv_id -> Adv_fname, Adv_lname, Adv_email, Adv_dept StMajor -> AdvDept Adv_email -> Adv_ID To normalize into 3NF Create a separate table for the attributes that depend on a non-key attribute. Remove these attributes from the original relation. Put them with their determinant into a separate table. Determinant becomes PK of new table, also the original table has an FK to the new Table. New Design in 3NF STUDENT (St_id, St_fname, St_lname ) StudentAdvisor ( St_id, St_major, Semester, Adv_id) Advisor(Adv_id, Adv_fname, Adv_lname, Adv_email, Adv_dept) Major (StMajor, Adv_dept)


Download ppt "Relation StudentAdvisor ( St_id, St_fname, St_lname, St_major, Semester, Adv_fname, Adv_lname, Adv_email, Adv_dept, Adv_id) Primary Key: St_id, Semester."

Similar presentations


Ads by Google