Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations


Presentation on theme: "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."— Presentation transcript:

1 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. Normalization

2 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 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

3 Insertion Anomalies Deletion Anomalies Modification Anomalies

4 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. Class_Info

5 LID LnameSalaryDept Subject Credit SID SnameGPA E5001Dusit28700EEElectronic 13S4Panita3.35 E5001Dusit28700EEElectronic 13S5Sarun2.96 E5001Dusit28700EEElectronic 13S6Kanok2.75 E5001Dusit28700EEElectronic 13S7Vichu3.15 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Chareon3.08 E6001Anan24900IEProb Stat4S8Kitti2.54 E6001Anan24900IEProb Stat4S9Chareon3.08 E6002Saeree53020IEOptimization3S10Sathit2.67 E6002Saeree53020IEOptimization3S11Vitthaya3.25 E9001Pattara18500CPEData Structure3S1Preeda2.85 E9001Pattara18500CPEData Structure3S2Panu2.45 E9001Pattara18500CPEData Structure3S3Vallapa3.02 E9001Pattara18500CPEWeb Service4S3Vallapa3.02 E9001Pattara18500CPEWeb Services4S1Preeda2.85 E9001Pattara18500CPEWeb Services4S2Panu2.45 NULL S999LuxanaNULL E9999Thana17500CPENULL CPEGIS3NULL Insert new records may cause data redundancy in other fields. Insertion Anomaly Class_Info

6 LID LnameSalaryDept Subject Credit SID SnameGPA E5001Dusit28700EEElectronic 13S4Panita3.35 E5001Dusit28700EEElectronic 13S5Sarun2.96 E5001Dusit28700EEElectronic 13S6Kanok2.75 E5001Dusit28700EEElectronic 13S7Vichu3.15 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Chareon3.08 E6001Anan24900IEProb Stat4S8Kitti2.54 E6001Anan24900IEProb Stat4S9Chareon3.08 E6002Saeree53020IEOptimization3S10Sathit2.67 E6002Saeree53020IEOptimization3S11Vitthaya3.25 E9001Pattara18500CPEData Structure3S1Preeda2.85 E9001Pattara18500CPEData Structure3S2Panu2.45 E9001Pattara18500CPEData Structure3S3Vallapa3.02 E9001Pattara18500CPEWeb Service4S3Vallapa3.02 E9001Pattara18500CPEWeb Services4S1Preeda2.85 E9001Pattara18500CPEWeb Services4S2Panu2.45 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Chareon3.08 E6001Anan24900IEProb Stat4S8Kitti2.54 E6001Anan24900IEProb Stat4S9Chareon3.08 Deletion Anomaly Deletion Anomaly may cause loss other necessary data. Class_Info

7 LID LnameSalaryDept Subject Credit SID SnameGPA E5001Dusit28700EEElectronic 13S4Panita3.35 E5001Dusit28700EEElectronic 13S5Sarun2.96 E5001Dusit28700EEElectronic 13S6Kanok2.75 E5001Dusit28700EEElectronic 13S7Vichu3.15 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Chareon3.08 E6001Anan24900IEProb Stat4S8Kitti2.54 E6001Anan24900IEProb Stat4S9Chareon3.08 E6002Saeree53020IEOptimization3S10Sathit2.67 E6002Saeree53020IEOptimization3S11Vitthaya3.25 E9001Pattara18500CPEData Structure3S1Preeda2.85 E9001Pattara18500CPEData Structure3S2Panu2.45 E9001Pattara18500CPEData Structure3S3Vallapa3.02 E9001Pattara18500CPEWeb Service4S3Vallapa3.02 E9001Pattara18500CPEWeb Services4S1Preeda2.85 E9001Pattara18500CPEWeb Services4S2Panu2.45 Dusit 45000 Dusit 45000 Dusit 45000 Dusit 45000 Modification Anomaly 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. Class_Info Pattara 25000 Panu 2.67 Panu 2.45 Pattara 18500 Pattara 18500 Pattara 18500 Pattara 18500 Pattara 18500 Pattara 21000

8 To solve update anomalies, a relation must be normalized by using normalization process to remove existing data redundancy. LID LnameSalaryDept Subject Credit SID SnameGPA E5001Dusit28700EEElectronic 13S4Panita3.35 E5001Dusit28700EEElectronic 13S5Sarun2.96 E5001Dusit28700EEElectronic 13S6Kanok2.75 E5001Dusit28700EEElectronic 13S7Vichu3.15 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Chareon3.08 E6001Anan24900IEProb Stat4S8Kitti2.54 E6001Anan24900IEProb Stat4S9Chareon3.08 E6002Saeree53020IEOptimization3S10Sathit2.67 E6002Saeree53020IEOptimization3S11Vitthaya3.25 E9001Pattara18500CPEData Structure3S1Preeda2.85 E9001Pattara18500CPEData Structure3S2Panu2.45 E9001Pattara18500CPEData Structure3S3Vallapa3.02 E9001Pattara18500CPEWeb Service4S3Vallapa3.02 E9001Pattara18500CPEWeb Services4S1Preeda2.85 E9001Pattara18500CPEWeb Services4S2Panu2.45

9 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

10 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

11 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 t 1 [  ] = t 2 [  ], it is also the case that t 1 [  ] = t 2 [  ]. 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 t 1 [  ] = t 2 [  ] DBMS must guarantee that t 1 [  ] = t 2 [  ]

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

13 LID LnameSalaryDept Subject Credit SID SnameGPA E5001Dusit28700EEElectronic 13S4Panita3.35 E5001Dusit28700EEElectronic 13S5Sarun2.96 E5001Dusit28700EEElectronic 13S6Kanok2.75 E5001Dusit28700EEElectronic 13S7Vichu3.15 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Chareon3.08 E6001Anan24900IEProb Stat4S8Kitti2.54 E6001Anan24900IEProb Stat4S9Chareon3.08 E6002Saeree53020IEOptimization3S10Sathit2.67 E6002Saeree53020IEOptimization3S11Vitthaya3.25 E9001Pattara18500CPEData Structure3S1Preeda2.85 E9001Pattara18500CPEData Structure3S2Panu2.45 E9001Pattara18500CPEData Structure3S3Vallapa3.02 E9001Pattara18500CPEWeb Service4S3Vallapa3.02 E9001Pattara18500CPEWeb Services4S1Preeda2.85 E9001Pattara18500CPEWeb Services4S2Panu2.45 ( LID, Subject,SID )  Lname, Salary, Dept, Credit, Sname, GPA LID  Lname, Salary, Dept Subject  Credit SID  Sname, GP

14 Utilization of FD to decompose a relation LID LnameSalaryDept Subject Credit SID SnameGPA E5001Dusit28700EEElectronic 13S4Panita3.35 E5001Dusit28700EEElectronic 13S5Sarun2.96 E5001Dusit28700EEElectronic 13S6Kanok2.75 E5001Dusit28700EEElectronic 13S7Vichu3.15 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Charoen3.08 ……………….. ………….………….. LIDLnameSalaryDept E5001Dusit28700EE E6001Anan24900IE E6002Saeree53020IE E9001Pattara18500CPE SubjectCredit Electronic 13 Optimization3 Prob Stat4 Data Structure3 Web Service4 SID SnameGPA S1Preeda2.85 S2Panu2.45 S3Vallapa3.02 S4Panita3.35 S5Sarun2.96 S6Kanok2.75 S7Vichu3.15 S8Kitti2.54 S9Chareon3.08 Lecturer Subject Student

15 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 1 st Normal Form 2 nd Normal Form 3 rd 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).

16 Relationships of Normal Forms Higher Normal forms

17

18 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. 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. Cust_NoCNameProperty_NoPAddressRentRentStartRentFinishOwner_NoOName CR76John KayPG4 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 CR56Aline StewartPG4 PG36 PG16 6 Lawrence St, 2 Manor Rd, 5 Norwar Dr 350 375 450 1-Sep-92 10-Oct-94 1-Jan-96 10-Jan-94 1-Dec-95 10-Aug-96 CO40 CO93 Tina Murphy Tony Shaw Customer_Rental Relation

19 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 1 st NF by removing of repeating groups in order to form relational data model (data are conceptually structured in the form of table). Cust_NoCNameProperty_NoPAddressRentRentStartRentFinishOwner_NoOName CR76John KayPG4 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 CR56Aline StewartPG4 PG36 PG16 6 Lawrence St, 2 Manor Rd, 5 Norwar Dr 350 375 450 1-Sep-92 10-Oct-94 1-Jan-96 10-Jan-94 1-Dec-95 10-Aug-96 CO40 CO93 Tina Murphy Tony Shaw Customer_Rental Relation CR76John Kay CR56 Aline Stewart CR56 Aline Stewart

20 First normal form (1NF) : A relation in which the intersection of each row and column contains one and only one value. 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. Custome_NoProperty_NoCNamePAddressRentRentStartRentFinishOwner_NoOName CR76PG4John Kay6 Lawrence St,3501-jul-9431-Aug-96CO40Tina Murphy CR76PG16John Kay5 Norwar Dr4501-Sep-98 CO93Tony Shaw CR56PG4Aline Stew6 Lawrence St,35010-Jun-94 CO40Tina Murphy CR56PG36Aline Stew2 Manor Rd,3751-Dec-95 CO93Tony Shaw CR56PG16Aline Stew5 Norwar Dr45010-Aug-96 CO93Tony Shaw Customer_Rental Relation

21 Set of the Functional Dependency of Customer_Rental relation fd1Customer_No, Property_No  RentStart, RentFinish (Primary key) fd2Customer_No  CName (Partial dependency) fd3Property_No  PAddress, Rent, Owner_No, OName (Partial dependency) fd4Owner_No  OName (Transitive dependency) fd5Customer_No, RentStart  Property_No, PAddress, RentFinish, Rent, Owner, OName (Candidate key) fd6Property_No, RentStart  Customer_No, CName, RentFinish (Candidate key)

22 Customer_NoProperty_NoCNameRentFinishRentPAddressOwner_NoRentStart OName (Primary key) (Partial dependency) (Transitive dependency) (Candidate key) fd1 fd2 fd3 fd5 fd6 fd4

23 A relation that is in the first normal form and every non-primary key attribute is fully functionally dependent on the primary key. Second Normal Form (2NF) : 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_NoProperty_NoCNameRentFinishRentPAddressOwner_NoRentStart (Primary key) (Partial dependency) fd1 fd2 fd3 OName

24 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. Customer (Customer_No, CName) Customer_NoCName CR76John Kay CR56Aline Stewart Customer_NoProperty_NoRentStartRentFinish CR76PG141-Jul-9431-Aug-96 CR766PG161-Sep-961-Sep-98 CR56PG41-Sep-9210-Jun-94 CR56PG3610-Oct-941-Dec-95 CR56PG161-Jan-9610-Aug-96 Customer Relation Rental Relation Property_NoPAddressRentOwner_NoOName PG14 6 Lawrence St, 350CO40Tina Murphy PG165 Norwar Dr450CO93Tony Shaw PG36 2 Manor Rd, 375CO93Tony Shaw Property-Owner Relation Rental (Customer_No, Property_No, RentStart, RentFinish) Property_Owner (Property_No, PAddress, Rent, Owner_No, OName)

25 Transitive dependency Property_ No PAddressRentOwner_NoONameaddress PG14 6 Lawrence St, 350CO40Tina Murphy28 North Rye PG165 Norwar Dr450CO93Tony Shaw550/8 Lake Shore Dr. PG36 2 Manor Rd, 375CO93Tony Shaw550/8 Lake Shore Dr. Property-Owner Relation Customer (Customer_No, CName) Rental (Customer_No, Property_No, RentStart, RentFinish) Property_Owner (Property_No, PAddress, Rent, Owner_No, Oname, address) Transitive dependency Customer_NoCName CR76John Kay CR56Aline Stewart Customer_NoProperty_NoRentStartRentFinish CR76PG141-Jul-9431-Aug-96 CR766PG161-Sep-961-Sep-98 CR56PG41-Sep-9210-Jun-94 CR56PG3610-Oct-941-Dec-95 CR56PG161-Jan-9610-Aug-96 Customer Relation Rental Relation

26 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. Property_NoPAddressRentOwner_No PG14 6 Lawrence St, 350CO40 PG165 Norwar Dr450CO93 PG36 2 Manor Rd, 375CO93 Property-for-Rent Relation Customer (Customer_No, CName) Rental (Customer_No, Property_No, RentStart, RentFinish) Property_Owner (Property_No, PAddress, Rent, Owner_No, OName) Owner_NoONameaddress C040Tina Murphy28 North Rye Co93Tony Shaw 550/8 Lake Shore Dr. Owner Relation

27 Custome_NoProperty_NoCNamePAddressRentRentStartRentFinishOwner_NoOName CR76PG4John Kay6 Lawrence St,3501-jul-9431-Aug-96CO40Tina Murphy CR76PG16John Kay5 Norwar Dr4501-Sep-98 CO93Tony Shaw CR56PG4Aline Stew6 Lawrence St,35010-Jun-94 CO40Tina Murphy CR56PG36Aline Stew2 Manor Rd,3751-Dec-95 CO93Tony Shaw CR56PG16Aline Stew5 Norwar Dr45010-Aug-96 CO93Tony Shaw Customer_Rental Relation Customer (Customer_No, CName) Rental (Customer_No, Property_No, RentStart, RentFinish) Property (Property_No, PAddress, Rent, Owner_No) Owner (Owner_No, Oname, address)

28 Customer_NoCName CR76John Kay CR56Aline Stewart Customer_NoProperty_NoRentStartRentFinish CR76PG141-Jul-9431-Aug-96 CR766PG161-Sep-961-Sep-98 CR56PG41-Sep-9210-Jun-94 CR56PG3610-Oct-941-Dec-95 CR56PG161-Jan-9610-Aug-96 Customer Rental Property_NoPAddressRentOwner_No PG14 6 Lawrence St, 350CO40 PG165 Norwar Dr450CO93 PG36 2 Manor Rd, 375CO93 Property-Owner Owner_NoONameaddress CO40Tina Murphy28 North Rye CO93Tony Shaw 550/8 Lake Shore Owner Customer_Rental CustomerRental Property_Owner Property_for_RentOwner 1NF 2NF 3NF

29 From 3NF to Boyce-Codd Normal Form (BCNF) 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. 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. 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

30 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.

31 Fd1 Client_No, Interview_Date  Interview_Time, Staff_No, Room_No (Primary key) Fd2 Staff_No, Interview_Date, Interview_Time  Client_No (Candidate key) Fd3 Room_No, Interview_Date, Interview_Time  Staff_No, Client_No (Candidate key) Fd4 Staff_No, Interview_Date  Room_No Client_Interview (Client_No, Inverview_Date, Interview_Time, Staff_No, Room_No) The Client_Interview relation has the following functional dependencies : Client_NoInterview_DateInterview_TimeStaff_NoRoom_No CR7613-May-9810:30SG5G101 CR5613-May-9812:00SG5G101 CR7413-May-9812:00SG37G102 CR561-Jul-9810:30SG5G102 Client_Interview Relation

32 Client_NoInterview_DateInterview_TimeStaff_No CR7613-May-9810:30SG5 CR5613-May-9812:00SG5 CR7413-May-9812:00SG37 CR561-Jul-9810:30SG5 Interview Relation Staff_NoInterview_DateRoom_No SG513-May-98G101 SG3713-May-98G102 SG51-Jul-98G102 Staff_Room Relation Interview (Client_No, Interview-Date, Interview_Time, Staff_No) Staff_Room (Staff_No, Interview-Date, Room_No)

33 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_NoPAddressIDateITimeCommentsStaff_NoSNameCar_Reg PG46 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 PG165 Norwar Dr22-Apr-96 24-Oct-97 13:00 14:00 Replace room carpet Good condition SG14 SG37 David Ford Ann Beech M533 HDR N721 HFR Property_Inspection Relation Property_Inspection (Property_No, PAddress, IDate, ITime, Comments, Staff_No, SName, OName)

34 1NF : Property_Inspection Relation Property_NoIDateITimePAddressCommentsStaff_NoSNameCar_Reg PG418-Oct-9610:006 Lawrence St,Need to replace crockerySG37Ann BeechM231 JGR PG422-Apr-9709:006 Lawrence St,In good orderSG14David FordM533 HDR PG41-Oct-9812:006 Lawrence St,Damp rot in bathroomSG14David FordN721 HFR PG1622-Apr-9613:005 Norwar DrReplace room carpetSG14David FordM533 HDR PG1624-Oct-9714:005 Norwar DrGood conditionSG37Ann BeechN721 HFR Property_Inspection (Property_No, IDate, ITime, PAddress, Comments, Staff_No, SName, OName) Property_NoIDateITimePAddressCommentsStaff_NoSNameCar_Reg (Partial dependency) (Primary key) (Transitive dependency) (Candidate key) FD1 FD2 FD3 FD4 FD5 FD6

35 Property_NoIDateITimePAddressCommentsStaff_NoSNameCar_Reg (Partial dependency) (Primary key) FD1 FD2 Property Relation Property_NoPAddress PG46 Lawrence St, PG165 Norwar Dr Property_Inspection Relation Property_NoIDateITimeCommentsStaff_NoSNameCar_Reg PG418-Oct-9610:00Need to replace crockerySG37Ann BeechM231 JGR PG422-Apr-9709:00In good orderSG14David FordM533 HDR PG41-Oct-9812:00Damp rot in bathroomSG14David FordN721 HFR PG1622-Apr-9613:00Replace room carpetSG14David FordM533 HDR PG1624-Oct-9714:00Good conditionSG37Ann BeechN721 HFR Remove Partial dependency (decompose the relation) to obtain 2NF

36 Property Relation (Property_No, PAddress) Property_NoPAddress PG46 Lawrence St, PG165 Norwar Dr Property_Inspection Relation Property_NoIDateITimeCommentsStaff_NoSNameCar_Reg FD1 FD3 FD4 FD5 FD6 (Primary key) (Transitive dependency) (Candidate key)

37 Property Relation Property_NoPAddress PG46 Lawrence St, PG165 Norwar Dr Property_Inspection Relation Property_NoIDateITimeCommentsStaff_NoCar_Reg PG418-Oct-9610:00Need to replace crockerySG37M231 JGR PG422-Apr-9709:00In good orderSG14M533 HDR PG41-Oct-9812:00Damp rot in bathroomSG14N721 HFR PG1622-Apr-9713:00Replace room carpetSG14M533 HDR PG1624-Oct-9714:00Good conditionSG37N721 HFR Remove Transitive dependency (decompose the relation) to obtain 3NF Staff Relation Staff_NoSName SG37Ann Beech SG14David Ford

38 Property Relation Property_NoPAddress PG46 Lawrence St, PG165 Norwar Dr Property_Inspection Relation Property_NoIDateITimeCommentsStaff_NoCar_Reg Remove remaining anomalies from functional dependencies to obtain BCNF Staff Relation Staff_NoSName SG37Ann Beech SG14David Ford Staff_Car (Staff_No, IDate, Car_Reg) Inspection (Property_No, IDate, ITime, Comments, Staff_No)

39 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. Lecturer_NameSubjectResearch YuenData StructureNatural Language Processing YuenData StructureProtocal Analyzer YuenDiscrete MathNatural Language Processing YuenDiscrete MathProtocal Analyzer YuenData BaseNatural Language Processing YuenData BaseProtocal Analyzer ChalerrmsakData StructureProtocal Analyzer ChalerrmsakData StructureCompiler Utilities ChalerrmsakData StructureNatural Language Processing ตารางต่อไปนี้เป็น BCNF แต่ยังเกิดปัญหา update anomalies Lect_Sub_Research Relation

40 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 Lecturer_NameSubjectResearch YuenData StructureNatural Language Processing YuenData StructureProtocal Analyzer YuenDiscrete MathNatural Language Processing YuenDiscrete MathProtocal Analyzer YuenData BaseNatural Language Processing YuenData BaseProtocal Analyzer ChalerrmsakData StructureProtocal Analyzer ChalerrmsakData StructureCompiler Utilities ChalerrmsakData StructureNatural Language Processing Lec_Sub_Research Relation Lecturer_NameSubject YuenData Structure YuenDiscrete Math YuenData Base ChalerrmsakData Structure Lec_Sub Relation Lecturer_NameResearch YuenNatural Language Processing YuenProtocal Analyzer ChalerrmsakProtocal Analyzer ChalerrmsakCompiler Utilities ChalerrmsakNatural Language Processing Lec_Research Relation

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

42 LID LnameSalaryDept Subject Credit SID SnameGPA E5001Dusit28700EEElectronic 13S4Panita3.35 E5001Dusit28700EEElectronic 13S5Sarun2.96 E5001Dusit28700EEElectronic 13S6Kanok2.75 E5001Dusit28700EEElectronic 14S7Vichu3.15 E6001Anan24900IEOptimization3S8Kitti2.54 E6001Anan24900IEOptimization3S9Chareon3.08 E6001Anan24900IEProb Stat4S8Kitti2.54 E6001Anan24900IEProb Stat4S9Chareon3.08 E6002Saeree53020IEOptimization3S10Sathit2.67 E6002Saeree53020IEOptimization3S11Vitthaya3.25 E9001Pattara18500CPEData Structure3S1Preeda2.85 E9001Pattara18500CPEData Structure3S2Panu2.45 E9001Pattara18500CPEData Structure3S3Vallapa3.02 E9001Pattara18500CPEWeb Service4S3Vallapa3.02 E9001Pattara18500CPEWeb Services4S1Preeda2.85 E9001Pattara18500CPEWeb Services4S2Panu2.45 NULL S999LuxanaNULL E9999Thana17500CPENULL CPEGIS3NULL


Download ppt "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."

Similar presentations


Ads by Google