Normalization Normalization is a formal method involved with a series of test to help database designer to be able to identify the optimal grouping.

Normalization Normalization is a formal method involved with a series of test to help database designer to be able to identify the optimal grouping of attributes for each relation in the relational schema. Normalization can be applied to individual relation so that database can be normalized to a specific form to prevent the possible occurrence of update anomaly.

Data Redundancy and Update Anomalies
The main purpose of database design is to identify the optimal grouping of attributes in order to minimize data redundancy, and NULL value which affect on saving space for data storage. Data redundancy always causes UPDATE ANOMALIES which are classified into 3 types: Insertion anomalies Deletion Anomalies Modification Anomalies

Insertion Anomalies Deletion Anomalies Modification Anomalies

Modification Anomalies
Insertion Anomalies To insert the details of new students into the Class_Info relation, we must include the details of the lecturer and subject in order to avoid null value. Deletion Anomalies If we delete a lecturer from the Class_Info relation, the details of students and subjects are also lost from the database. Modification Anomalies If we want to change the value of one of the attributes of a particular student in the Class_Info relation, we must update all rows which associate to the student. If this modification is not carried out on all the appropriate rows of the Class_Info relation, the database will become inconsistent.

Insertion Anomaly Class_Info
LID Lname Salary Dept Subject Credit SID Sname GPA E5001 Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services NULL S999 Luxana E9999 Thana 17500 CPE NULL NULL CPE GIS 4 Insert new records may cause data redundancy and null value in some fields.

LID Lname Salary Dept Subject Credit SID Sname GPA E5001 Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E5001 Dusit 28700 EE Power Control 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization 3 S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services NULL S999 Luxana E9999 Thana 17500 CPE NULL NULL CPE Prob Stat 4 Insert new records may cause data redundancy and null value in some fields.

LID Lname Salary Dept Subject Credit SID Sname GPA E5001 Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 Power Control E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services NULL S999 Luxana E9999 Thana 17500 CPE NULL NULL CPE Prob Stat 4 Insert new records may cause data redundancy and null value in some fields.

Deletion Anomaly may cause loss other necessary data.
Class_Info LID Lname Salary Dept Subject Credit SID Sname GPA E5001 Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services E6001 Anan 24900 IE Optimization 3 S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 Deletion Anomaly may cause loss other necessary data.

Modification Anomaly Class_Info
LID Lname Salary Dept Subject Credit SID Sname GPA E5001 Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services Dusit 45000 Dusit 45000 Dusit 45000 Dusit 45000 Pattara 21000 Pattara 18500 Panu 2.67 Pattara 18500 Pattara 18500 Pattara 18500 Pattara 25000 Pattara 18500 Panu 2.45 If we want to change the value of one of the attributes of a particular entity in the relation, we must update all rows that relate to this entity. If this modification is not carried out on all the appropriate rows ,the data base will become inconsistent.

To solve update anomalies, a relation must be normalized by using normalization process to remove existing data redundancy. LID Lname Salary Dept Subject Credit SID Sname GPA E5001 Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services

Functional Dependency
One of the main concepts associated with normalization is functional dependency, which describes the relationship between attributes. Functional Dependency describes the relationship between attributes in a relation. For example, if A and B are attributes (or set of attributes) of relation R, B is functionally dependent on A (denoted AB), if each value of A is associated with exactly one value of B. The symbol of Functional Dependency (AB) can be described as followings: B is functionally dependent on A or A determines B or B depends on A

Functional Dependencies
One of the main concepts associated with normalization is functional dependency, which describes the relationship between attributes. (Definition of Functional Dependency) Suppose that B is an attribute and A is another one, we said that B is functionally dependent on A (denoted A  B), if each value of A is associated with exactly one value of B. ( A and B may each consists of one or more attributes.) The symbol of functional dependence (A  B) means B is functionally dependent on A or A functionally defines B or B depends on A

If the functional dependency    holds on schema R, in any legal relation r, for all pairs of tuples t1 and t2 in r such that t1[] = t2[], it is also the case that t1[] = t2[]. Given a relation r, attribute y of r is dependent on attribute x if and only if whenever two tuples of R agree on their x-value, they must necessarily agree on their y-value. For every tuple in the relation r, if the value of attribute  in tuples are the same, DBMS guarantees that the value of the attribute  in those tuples must be the same. That is If    holds on R and if t1[] = t2[] DBMS must guarantee that t1[] = t2[]

When a functional dependency exists, the attribute or group
B is functionally dependent on A A B When a functional dependency exists, the attribute or group Of attributes on the left-hand side of the arrow is called the determinant. Position is functionally dependent on Staff_No Staff_No Position SL21 System Engineer Staff_No is not functionally dependent on Position Position Staff_No SL21 SG5 System Engineer

( LID, Subject,SID ) Lname, Salary, Dept, Credit, Sname, GPA
Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat 4 E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services ( LID, Subject,SID ) Lname, Salary, Dept, Credit, Sname, GPA LID  Lname, Salary, Dept Subject  Credit SID  Sname, GPA

Utilization of FD to decompose a relation
LID Lname Salary Dept Subject Credit SID Sname GPA E5001 Dusit 28700 EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Charoen 3.08 …… ………….. …………. Lecturer Student Subject LID Lname Salary Dept E5001 Dusit 28700 EE E6001 Anan 24900 IE E6002 Saeree 53020 E9001 Pattara 18500 CPE Subject Credit Electronic 1 3 Optimization Prob Stat 4 Data Structure Web Service SID Sname GPA S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 S7 Vichu 3.15 S8 Kitti 2.54 S9 Chareon 3.08

Boyce-Codd Normal Form
Normalization is a formal method involved with a series of test to help database designer to be able to identify the optimal grouping of attributes for each relation in the relational schema. Unnormalized Form 1st Normal Form 2nd Normal Form 3rd Normal Form Boyce-Codd Normal Form Normalization can be applied to individual relation so that database can be normalized to a specific form to prevent the possible occurrence of update anomaly. The process of normalization is a formal method that identifies relations based on primary key (or candidate keys in the case of BCNF the functional dependencies among their attributes).

Relationships of Normal Forms
Higher Normal forms 1NF: least restrictive; every table in 1NF 2NF: more restrictive than 1NF; every table in 2NF is also in 1NF 3NF/BCNF: BCNF is a revised definition of 3NF; BCNF is more restrictive than BCNF 4NF: Inappropriate usage of an M-way relationship; Relationship independence and MVDs; does not involve FDs 5NF: does not involve FDs; Inappropriate usage of an M-way relationship; more specialized than 4NF DKNF: ideal rather than a practical normal form

Case Study The DreamHome company manages property on behalf of the owners, and as part of this service, the company takes care of the property’s rental. To simplify this example, we assume that a customer rents a given property only once, and cannot rent more than one property at any one time. Unnormalized form (UNF) : A table that contains one or more repeating groups. Customer_Rental Relation Cust_No CName Property_No PAddress Rent RentStart RentFinish Owner_No OName O_addr CR76 John Kay PG4 PG16 6 Lawrence St, 5 Norwar Dr 350 450 1-Jul-94 1-Sep-96 31-Aug-96 1-Sep-98 CO40 CO93 Tina Murphy Tony Shaw CR56 Aline Stewart PG36 2 Manor Rd, 375 1-Sep-92 10-Oct-94 1-Jan-96 10-Jan-94 1-Dec-95 10-Aug-96 A repeating group is an attribute or group of attributes within a table that occurs with multiple values for a single occurrence of the key attribute (s) for that table. The term key refers to the attribute (s) that uniquely identify each row within the unnormalized table.

Case Study The DreamHome company manages property on behalf of the owners, and as part of this service, the company takes care of the property’s rental. To simplify this example, we assume that a customer rents a given property only once, and cannot rent more than one property at any one time. Adjust Unnormalized form to 1st NF by removing of repeating groups in order to form relational data model (data are conceptually structured in the form of table) . Customer_Rental Relation Cust_No CName Property_ No PAddress Rent RentStart RentFinish Owner_No OName O_addr CR76 John Kay PG4 PG16 6 Lawrence St, 5 Norwar Dr 350 450 1-Jul-94 1-Sep-96 31-Aug-96 1-Sep-98 CO40 CO93 Tina Murphy Tony Shaw …… CR56 Aline Stewart PG36 2 Manor Rd, 375 1-Sep-92 10-Oct-94 1-Jan-96 10-Jan-94 1-Dec-95 10-Aug-96 …….. CR76 John Kay ……. CR56 Aline Stewart ……. CR56 Aline Stewart …….

First normal form (1NF) : A relation in which the intersection of each row and column contains one and only one value. Customer_Rental Relation Custome_No Property_No CName PAddress Rent RentStart RentFinish Owner_No OName CR76 PG4 John Kay 6 Lawrence St, 350 1-jul-94 31-Aug-96 CO40 Tina Murphy PG16 5 Norwar Dr 450 1-Sep-98 CO93 Tony Shaw CR56 Aline Stew 10-Jun-94 PG36 2 Manor Rd, 375 1-Dec-95 10-Aug-96 For the relational data model, it is important to recognize that it is only first normal form(1NF) that is critical in creating appropriate relations. All the subsequent normal forms are optional. However, to avoid the update anomalies, it is recommended that we proceed to at least 3NF.

Set of the Functional Dependency of Customer_Rental relation
fd1 Customer_No, Property_No  RentStart, RentFinish (Primary key) fd2 Customer_No  CName (Partial dependency) fd3 Property_No  PAddress, Rent, Owner_No, OName (Partial dependency) fd4 Owner_No  Oname, O_add (Transitive dependency) fd5 Customer_No, RentStart  Property_No, PAddress, RentFinish, Rent, Owner, OName (Candidate key) fd6 Property_No, RentStart  Customer_No, CName, RentFinish (Candidate key)

fd1 fd2 fd3 fd4 fd5 fd6 OName (Primary key) (Partial dependency)
Customer_No Property_No CName PAddress RentStart RentFinish Rent Owner_No OName fd1 (Primary key) fd2 (Partial dependency) (Partial dependency) fd3 fd4 (Transitive dependency) fd5 (Candidate key) fd6 (Candidate key)

Second Normal Form (2NF) :
A relation that is in the first normal form and every non-primary key attribute is fully functionally dependent on the primary key. Full functional : Indicates that if A and B are attributes of a relation, B is fully functionally dependent dependency on A if B is functionally dependent on A, but not on any proper subset of A. ถ้า B เป็น Non-Key attribute ซึ่งมีฟังก์ชั่นการขึ้นต่อกันอยู่กับส่วนใดส่วนหนึ่งของคีย์หลัก เราจะเรียกว่า B partial dependence on A. Partial dependency ต้องถูกขจัดออกโดยการแยก ออกไปตั้งเป็นตารางใหม่ เพื่อให้ Non-Key attribute ตัวนี้ fully dependent on คีย์หลัก Customer_No Property_No CName PAddress RentStart RentFinish Rent Owner_No OName O_Addr fd1 (Primary key) fd2 (Partial dependency) fd3 (Partial dependency)

Rental (Customer_No, Property_No, RentStart, RentFinish)
Customer (Customer_No, CName) Rental (Customer_No, Property_No, RentStart, RentFinish) Property_Owner (Property_No, PAddress, Rent, Owner_No, Oname, O_addr) Rental Relation Customer Relation Customer_No Property_No RentStart RentFinish CR76 PG14 1-Jul-94 31-Aug-96 CR766 PG16 1-Sep-96 1-Sep-98 CR56 PG4 1-Sep-92 10-Jun-94 PG36 10-Oct-94 1-Dec-95 1-Jan-96 10-Aug-96 Customer_No CName CR76 John Kay CR56 Aline Stewart Property-Owner Relation Property_No PAddress Rent Owner_No OName O_addr PG14 6 Lawrence St, 350 CO40 Tina Murphy 28 North Rye PG16 5 Norwar Dr 450 CO93 Tony Shaw 550/8 Lake Shore Dr. PG36 2 Manor Rd, 375 2NF applies to relations with composite keys, that is, relations with a primary key that composed of two or more attributes. A relation with a single attribute primary key is automatically in at least 2NF.

Transitive dependency
Customer (Customer_No, CName) Rental (Customer_No, Property_No, RentStart, RentFinish) Property_Owner (Property_No, PAddress, Rent, Owner_No, Oname, O_addr) Transitive dependency Property-Owner Relation Property_No PAddress Rent Owner_No OName O_addr PG14 6 Lawrence St, 350 CO40 Tina Murphy 28 North Rye PG16 5 Norwar Dr 450 CO93 Tony Shaw 550/8 Lake Shore Dr. PG36 2 Manor Rd, 375 Customer Relation Rental Relation Customer_No CName CR76 John Kay CR56 Aline Stewart Customer_No Property_No RentStart RentFinish CR76 PG14 1-Jul-94 31-Aug-96 CR766 PG16 1-Sep-96 1-Sep-98 CR56 PG4 1-Sep-92 10-Jun-94 PG36 10-Oct-94 1-Dec-95 1-Jan-96 10-Aug-96

Definition of Third Normal Form:
Transitive dependency : A condition where A, B, and C are attributes of a relation such that if A  B and B  C, then C is transitively dependent on A via B (provided that A is not functionally dependent on B or C). Definition of Third Normal Form: A relation that is in first and second normal form, and in which no non-primary key attribute is transitively dependent on the primary key. Customer (Customer_No, CName) Rental (Customer_No, Property_No, RentStart, RentFinish) Property_Owner (Property_No, PAddress, Rent, Owner_No, Oname, O_addr) Property-for-Rent Relation Owner Relation Property_No PAddress Rent Owner_No PG14 6 Lawrence St, 350 CO40 PG16 5 Norwar Dr 450 CO93 PG36 2 Manor Rd, 375 Owner_No OName O_addr C040 Tina Murphy 28 North Rye Co93 Tony Shaw 550/8 Lake Shore Dr.

Customer (Customer_No, CName)
Customer_Rental Relation Custome_No Property_No CName PAddress Rent RentStart RentFinish Owner_No OName CR76 PG4 John Kay 6 Lawrence St, 350 1-jul-94 31-Aug-96 CO40 Tina Murphy PG16 5 Norwar Dr 450 1-Sep-98 CO93 Tony Shaw CR56 Aline Stew 10-Jun-94 PG36 2 Manor Rd, 375 1-Dec-95 10-Aug-96 Customer (Customer_No, CName) Rental (Customer_No, Property_No, RentStart, RentFinish) Property (Property_No, PAddress, Rent, Owner_No) Owner (Owner_No, Oname, O_addr)

Customer_Rental 1NF Property_Owner 2NF Customer Rental
Property_for_Rent Owner 3NF Customer Rental Customer_No Property_No RentStart RentFinish CR76 PG14 1-Jul-94 31-Aug-96 CR766 PG16 1-Sep-96 1-Sep-98 CR56 PG4 1-Sep-92 10-Jun-94 PG36 10-Oct-94 1-Dec-95 1-Jan-96 10-Aug-96 Customer_No CName CR76 John Kay CR56 Aline Stewart Property_for_Rent Owner Property_No PAddress Rent Owner_No PG14 6 Lawrence St, 350 CO40 PG16 5 Norwar Dr 450 CO93 PG36 2 Manor Rd, 375 Owner_No OName address CO40 Tina Murphy 28 North Rye CO93 Tony Shaw 550/8 Lake Shore

From 3NF to Boyce-Codd Normal Form (BCNF)
BCNF is based on functional dependencies that take into account all candidate keys in a relation. For a relation with only one candidate key, 3NF and BCNF are equivalent. The difference between 3NF and BCNF is that for a functional dependency AB, 3NF allows this dependency in a relation if B is a primary-key attribute and A is not a candidate key. Whereas, BCNF insists that for this dependency to remain in a relation, A must be a candidate key. Therefore, BCNF is a stronger form of 3NF, such every relation in BCNF is also in 3NF. Boyce-Codd : A relation is in BCNF if and only if every determinant is normal form (BCNF) a candidate key. Violation of BCNF is quite rare, since it may only happen under specific conditions. The potential to violate BCNF may occur in relation that contains two (or more) composite candidate keys and which overlap, that is share at least one attribute in common

Case Study In this example, Client_Interview relation is presented. It contains details of the arrangements for interviews of clients by members of staff of the DreamHome company. The members of staff involved in interviewing clients are allocated to a specific room on the day of interview. However, a room may be allocated to several members of staff as required throughout a working day. A client is only interviewed once on a given date, but may be requested to attend further interviews at later dates. This relation has three candidate keys: (Client_No, Interview_Date), (Staff_No, Interview_Date, Interview_Time), and (Room_No, Interview_Date, Interview_Time). Therefore the Client_Interview relation has three composite candidate keys, which overlap by sharing the common attribute Interview_Date. We select Client_No, Interview_Date) to act as the primary key for this relation.

Fd1 Client_No, Interview_Date  Interview_Time, Staff_No, Room_No
Client_Interview (Client_No, Inverview_Date, Interview_Time, Staff_No, Room_No) The Client_Interview relation has the following functional dependencies : Fd Client_No, Interview_Date  Interview_Time, Staff_No, Room_No (Primary key) Fd Staff_No, Interview_Date, Interview_Time  Client_No (Candidate key) Fd Room_No, Interview_Date, Interview_Time  Staff_No, Client_No (Candidate key) Fd Staff_No, Interview_Date  Room_No Client_No Interview_Date Interview_Time Staff_No Room_No CR76 13-May-98 10:30 SG5 G101 CR56 12:00 CR74 SG37 G102 1-Jul-98 Client_Interview Relation

Interview (Client_No, Interview-Date, Interview_Time, Staff_No)
Staff_Room (Staff_No, Interview-Date, Room_No) Interview Relation Client_No Interview_Date Interview_Time Staff_No CR76 13-May-98 10:30 SG5 CR56 12:00 CR74 SG37 1-Jul-98 Staff_Room Relation Staff_No Interview_Date Room_No SG5 13-May-98 G101 SG37 G102 1-Jul-98

Review of Normalization (1NF to BCNF)
The DreamHome company manages property on behalf of the owners, and as part of this service the company undertakes regular inspections of the property by members of staff. When staff are required to undertake these inspections, they are allocated a company car for use on the day of the inspections. However, a car may be allocated to several members of staff, as required throughout the working day. A member of staff may inspect several properties on a given date, but a property is only inspected once on a given date. Property_Inspection Relation Property_No PAddress IDate ITime Comments Staff_No SName Car_Reg PG4 6 Lawrence St, 18-Oct-96 22-Apr-97 1-Oct-98 10:00 09:00 12:00 Need to replace crockery In good order Damp rot in bathroom SG37 SG14 Ann Beech David Ford M231 JGR M533 HDR N721 HFR PG16 5 Norwar Dr 22-Apr-96 24-Oct-97 13:00 14:00 Replace room carpet Good condition Property_Inspection (Property_No, PAddress, IDate, ITime, Comments, Staff_No, SName, OName)

1NF : Property_Inspection Relation
Property_No IDate ITime PAddress Comments Staff_No SName Car_Reg PG4 18-Oct-96 10:00 6 Lawrence St, Need to replace crockery SG37 Ann Beech M231 JGR 22-Apr-97 09:00 In good order SG14 David Ford M533 HDR 1-Oct-98 12:00 Damp rot in bathroom N721 HFR PG16 22-Apr-96 13:00 5 Norwar Dr Replace room carpet 24-Oct-97 14:00 Good condition Property_Inspection (Property_No, IDate, ITime, PAddress, Comments, Staff_No, SName, OName) Property_No IDate ITime PAddress Comments Staff_No SName Car_Reg FD1 (Primary key) (Partial dependency) FD2 FD3 (Transitive dependency) FD4 FD5 (Candidate key) FD6 (Candidate key)

(IDate, ITime, Staff_No)
1NF : Property_Inspection Relation Property_No IDate ITime PAddress Comments Staff_No SName Car_Reg PG4 18-Oct-96 10:00 6 Lawrence St, Need to replace crockery SG37 Ann Beech M231 JGR 22-Apr-97 09:00 In good order SG14 David Ford M533 HDR 1-Oct-98 12:00 Damp rot in bathroom N721 HFR PG16 22-Apr-96 13:00 5 Norwar Dr Replace room carpet 24-Oct-97 14:00 Good condition The potential to violate BCNF may occur in relation that contains two (or more) composite candidate keys and which overlap, that is share at least one attribute in common (Property_No, Idate) (IDate, ITime, Car_Reg) (IDate, ITime, Staff_No)

Remove Partial dependency (decompose the relation) to obtain 2NF
Property_No IDate ITime PAddress Comments Staff_No SName Car_Reg FD1 (Primary key) (Partial dependency) FD2 Remove Partial dependency (decompose the relation) to obtain 2NF Property Relation Property_No PAddress PG4 6 Lawrence St, PG16 5 Norwar Dr Property_Inspection Relation Property_No IDate ITime Comments Staff_No SName Car_Reg PG4 18-Oct-96 10:00 Need to replace crockery SG37 Ann Beech M231 JGR 22-Apr-97 09:00 In good order SG14 David Ford M533 HDR 1-Oct-98 12:00 Damp rot in bathroom N721 HFR PG16 22-Apr-96 13:00 Replace room carpet 24-Oct-97 14:00 Good condition

Property Relation (Property_No, PAddress)
PG4 6 Lawrence St, PG16 5 Norwar Dr Property_Inspection Relation Property_No IDate ITime Comments Staff_No SName Car_Reg FD1 (Primary key) FD3 (Transitive dependency) FD4 FD5 (Candidate key) FD6 (Candidate key)

Remove Transitive dependency (decompose the relation) to obtain 3NF
Property Relation Property_No PAddress PG4 6 Lawrence St, PG16 5 Norwar Dr Remove Transitive dependency (decompose the relation) to obtain 3NF Staff Relation Staff_No SName SG37 Ann Beech SG14 David Ford Property_Inspection Relation Property_No IDate ITime Comments Staff_No Car_Reg PG4 18-Oct-96 10:00 Need to replace crockery SG37 M231 JGR 22-Apr-97 09:00 In good order SG14 M533 HDR 1-Oct-98 12:00 Damp rot in bathroom N721 HFR PG16 13:00 Replace room carpet 24-Oct-97 14:00 Good condition

Remove remaining anomalies from functional dependencies to obtain BCNF
Property Relation Staff Relation Property_No PAddress PG4 6 Lawrence St, PG16 5 Norwar Dr Staff_No SName SG37 Ann Beech SG14 David Ford Remove remaining anomalies from functional dependencies to obtain BCNF Property_Inspection Relation Property_No IDate ITime Comments Staff_No Car_Reg (Primary key) (Candidate key) Staff_Car (Staff_No, IDate, Car_Reg) Inspection (Property_No, IDate, ITime, Comments, Staff_No)

From BCNF to Fourth Normal Form (4NF)
Although BCNF removes any anomalies due to functional dependencies, further research led to the identification of another type of dependency called multi-valued dependency (MVD), which can cause similar design problems for relations in terms of data redundancy. Even though the following table is in BCNF, but update anomalies still exists. Lect_Sub_Research Relation Lecturer_Name Subject Research Yuen Data Structure Natural Language Processing Protocal Analyzer Discrete Math Data Base Chalerrmsak Compiler Utilities

Lecturer > Subject Lecturer > Research
Multi-valued : Represents a dependency between attributes (for example, A, dependency B, and C) in a relation, such that for each value of A there is a (MVD) set of values for B, and a set of values for C. However, the set of values for B and C are independent of each other. A > B A > C Lecturer > Subject Lecturer > Research Lec_Sub_Research Relation Lec_Sub Relation Lecturer_Name Subject Yuen Data Structure Discrete Math Data Base Chalerrmsak Lecturer_Name Subject Research Yuen Data Structure Natural Language Processing Protocal Analyzer Discrete Math Data Base Chalerrmsak Compiler Utilities Lec_Research Relation Lecturer_Name Research Yuen Natural Language Processing Protocal Analyzer Chalerrmsak Compiler Utilities

Unnormalized form (UNF)
Remove repeating groups First normal form (1NF) Remove partial dependencies Second normal form (2NF) Remove transitive dependencies Third normal form (3NF) Remove remaining anomalies From functional dependencies Boyce-Codd form (BCNF) Remove multi-valued dependencies Fourth normal form (4NF)

LID Subject SID Lname Salary Dept Credit Sname GPA E5001 Dusit 28700
EE Electronic 1 3 S4 Panita 3.35 S5 Sarun 2.96 S6 Kanok 2.75 4 S7 Vichu 3.15 E6001 Anan 24900 IE Optimization S8 Kitti 2.54 S9 Chareon 3.08 Prob Stat E6002 Saeree 53020 S10 Sathit 2.67 S11 Vitthaya 3.25 E9001 Pattara 18500 CPE Data Structure S1 Preeda 2.85 S2 Panu 2.45 S3 Vallapa 3.02 Web Service Web Services NULL S999 Luxana E9999 Thana 17500

Normalization Normalization is a formal method involved with a series of test to help database designer to be able to identify the optimal grouping.

Similar presentations

Presentation on theme: "Normalization Normalization is a formal method involved with a series of test to help database designer to be able to identify the optimal grouping."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Normalization Normalization is a formal method involved with a series of test to help database designer to be able to identify the optimal grouping.

Similar presentations

Presentation on theme: "Normalization Normalization is a formal method involved with a series of test to help database designer to be able to identify the optimal grouping."— Presentation transcript:

Similar presentations

About project

Feedback