DBMS - Normalization
210 likes1,115,824 views
Normalization is a technique for designing relational database tables to minimize duplication of data and ensure data integrity. It involves organizing data into tables and establishing relationships between tables based on their attributes. There are several normal forms like 1NF, 2NF and 3NF that provide rules for table design to reduce anomalies and inconsistencies. Functional dependencies define relationships between attributes in a table, and normalization aims to remove non-key attributes that are functionally dependent on other attributes.
![Normalization
According to Chris Date in "What First Normal Form
Really Means“, a Relation is said as Un-Normalized
Relation if it does not follow the following set of rules:
□ There's no top-to-bottom ordering to the rows.
□ There's no left-to-right ordering to the columns.
□ There are no duplicate rows.
□ Every row-and-column intersection contains exactly
one value from the applicable domain (and nothing
else).
□ All columns are regular [i.e. rows have no hidden
components such as row IDs, object IDs, or hidden
timestamps].
Jitendra Tomar 3](https://image.slidesharecdn.com/dbms7-120403002040-phpapp02/85/DBMS-Normalization-3-320.jpg)
![Normalization
First Normal Form
□ A Relation is said to be First Normal Form if it meets a
certain minimum set of given criteria.
□ There's no top-to-bottom ordering of the rows.
□ There's no left-to-right ordering of the columns.
□ There are no duplicate rows.
□ Every row-and-column intersection contains exactly one
value from the applicable domain (and nothing else).
□ All columns are regular [i.e. rows have no hidden
components such as row IDs, object IDs, or timestamps].
□ These criteria are basically concerned with ensuring that
the table is a faithful representation of a Relation and
that it is free of Repeating Groups.
Jitendra Tomar 5](https://image.slidesharecdn.com/dbms7-120403002040-phpapp02/85/DBMS-Normalization-5-320.jpg)
DBMS - Normalization
- 1. Normalization □ It is a technique for designing relational database tables to minimize duplication of information. □ Normalization is a practice to safeguard the database against logical and structural anomalies. □ Normalization is also termed as canonical synthesis by the experts. □ It is used to keep data consistent and check that no loss of data as well as data integrity is there. □ Its complexity may lead to higher degree of join operations which sometimes lead to the degraded throughput times. □ The normal forms like 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, DKNF & 6NF are in practice. Jitendra Tomar 1
- 2. Normalization Normal Forms □ The Normal Forms (NF) of relational database provide with the theoretical procedures that determine a relation’s vulnerability towards the inconsistencies . □ If we Normalize the relation, it will always meets the requirements of its HNF (Highest Normal Form) and of all normal forms lower than its HNF. Also by definition, a relation fails to meet the requirements of any Normal Form higher than its HNF. □ The Normal Forms are applicable to individual relations. The entire database is said to be in Normal Form n if all of its relations are in Normal Form n. □ E.F. Codd gave the concepts of first three Normal Forms based on the concept of FDs where as the HNFs are based on degree of relationship between attributes of a relation. Jitendra Tomar 2
- 3. Normalization According to Chris Date in "What First Normal Form Really Means“, a Relation is said as Un-Normalized Relation if it does not follow the following set of rules: □ There's no top-to-bottom ordering to the rows. □ There's no left-to-right ordering to the columns. □ There are no duplicate rows. □ Every row-and-column intersection contains exactly one value from the applicable domain (and nothing else). □ All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or hidden timestamps]. Jitendra Tomar 3
- 4. Normalization Un-Normalized Relation □ The below given Relation is Un-Normalized Relation because of non-atomicity of the cell under Contact_No attribute. Customer Cust_ID Name Contact_No 123 Navin Kumar 01202536145 01245847698 456 Vikas Malhotra 01243265984 789 Ashish Sharma 01125698745 Jitendra Tomar 4
- 5. Normalization First Normal Form □ A Relation is said to be First Normal Form if it meets a certain minimum set of given criteria. □ There's no top-to-bottom ordering of the rows. □ There's no left-to-right ordering of the columns. □ There are no duplicate rows. □ Every row-and-column intersection contains exactly one value from the applicable domain (and nothing else). □ All columns are regular [i.e. rows have no hidden components such as row IDs, object IDs, or timestamps]. □ These criteria are basically concerned with ensuring that the table is a faithful representation of a Relation and that it is free of Repeating Groups. Jitendra Tomar 5
- 6. Normalization First Normal Form □ The Novice Structure of a Customer Table. Customer Cust_ID Name Contact_No 123 Navin Kumar 01202536145 456 Vikas Malhotra 01245847698 789 Ashish Sharma 01125698745 □ The basic problem of Atomicity will arise if the structure of a Relation is kept as above. □ To have multiple contact numbers for a customer will give rise to the problem of atomicity and the user will have repeated groups. Jitendra Tomar 6
- 7. Normalization First Normal Form □ Solution 1 □ The simplest way is to allow two values in each cell which will be the problematic aspect. □ This introduce the repeated groups of Domain & Values. Customer Cust_ID Name Contact_No 123 Navin Kumar 01202536145 01245847698 456 Vikas Malhotra 01243265984 789 Ashish Sharma 01125698745 Jitendra Tomar 7
- 8. Normalization First Normal Form □ Solution 2 Customer Cust_ID Name Contact_No1 Contact_No2 123 Navin Kumar 01202536145 456 Vikas Malhotra 01245847698 01243265984 789 Ashish Sharma 01125698745 □ The another way is to define multiple columns which makes use of Null Columns. □ This introduce the Repeated Groups across Columns. □ Contact_No1, Contact_No2 and so on share the identical domain and same meaning. Jitendra Tomar 8
- 9. Normalization First Normal Form □ The splitting is artificial and causes logical problem like: □ Difficulty in querying the table such as "Which customers have telephone number X?" □ By mistake a customer is given identical values for Contact_No1 & Contact_No2. Creates Redundancy. □ Restriction on the number of Contact numbers per customer. It leaves DB with unrecorded information and means that DB design is imposing constraints on the business process, rather than (as should ideally be the case) vise-versa. Jitendra Tomar 9
- 10. Normalization First Normal Form □ Solution (A design that complies with 1NF) □ Make two table, one for the customer details and other for the Contact details of the customer. □ Repeating groups of Contact details are absent in this design. Contact Customer Cust_ID Contact_No Cust_ID Name 123 01202536145 123 Navin Kumar 456 01245847698 456 Vikas Malhotra 456 01243265984 789 Ashish Sharma 789 01125698745 Jitendra Tomar 10
- 11. Normalization Jitendra Tomar 11
- 12. Normalization Functional Dependency (FD) □ It is a property of the information represented by the relation. □ It defines the most common encountered type of relatedness property between data items of a database. □ Usually, relatedness between attributes of single relational table are considered. □ FD concerns the dependence of the values of one attribute or set of attributes on those of another attribute or set of attributes, giving rise to constraint between two attributes or two sets of attributes. Jitendra Tomar 12
- 13. Normalization Functional Dependency □ In FDD, functional dependency is represented by rectangles representing attributes and a heavy arrow showing the dependency. □ E.g. FD: YX (Functional Dependency Diagram when X is functionally dependent on Y.) Y X □ The arrow notation ‘’ is read as ‘functionally determines.’ Jitendra Tomar 13
- 14. Normalization Functional Dependency □ In general terms, it can be stated that a set of attributes (subset) X in a relation model table T is said to be functionally dependent on a set of attributes (subset) Y in the table T if a given set of values for each attribute in Y determines a unique (only one) value for the set of attributes in X. □ The attributes in subset Y are sometimes knows as the determinant of FD: Y X. The left hand side of the FD is sometimes called determinant whereas that of the right hand side is called the dependent. The determinant and dependent are both sets of attributes. Jitendra Tomar 14
- 15. Normalization Functional Dependency □ Example □ Let us consider a functional dependency that there is one person working on a machine each day, which is given as: FD: {Person_Id, Date_Used} {Machine_no} Person_Id Machine_No Date_Used Jitendra Tomar 15
- 16. Normalization Functional Dependency □ Let us consider a functional dependency of relation Assign which is given as Emp_No Project Yrs Spent on Project 106519 P1 5 Emp_No 112233 P3 2 Yrs Spent 106519 P2 4 Project 111222 P1 4 □ Here , if the values of Emp_No and Project are known, a unique value of Yrs_Spent could also be known. FD: {Emp_No, Project} {Yrs Spend on Project} Jitendra Tomar 16
- 17. Normalization Full Functional Dependency □ The set of attributes X will be fully functionally dependent on the set of attributes Y if the following conditions are satisfied: □ X is functionally dependent on Y and □ X is not functionally dependent on any subset of Y □ Example: {Proj_Id} has a functional dependency on {Employee ID, Skill}, but not a full functional dependency, because is also dependent on {Employee ID}. Jitendra Tomar 17
- 18. Normalization Jitendra Tomar 18
- 19. Normalization Second Normal Form □ A relation R is said to be in second normal form (2NF) if □ it is in 1NF and □ every non-prime key attributes of R is fully functionally dependent on Primary Key i.e. no partial dependency is allowed in the relation R. □ In other words, no attributes of the relation should be functionally dependent on only one part of the concatenated primary key. □ Thus, 2NF can be violated only when a key is a composite key, consisting or more than one attribute. □ 2NF is an intermediate step towards higher normal forms, it eliminates the problems of 1NF. Jitendra Tomar 19
- 20. Normalization Second Normal Form Example 1 □ Consider the below given relation PATIENT_DOCTOR. The relation is in 1NF. Patient DOB Doctor Contact Date Consult Name Name No Time Duration Ravi 10.02.1963 Abhishek 1122334 10.01.08 10:20 15 Sanjay 05.08.1983 Prakash 2255886 10.01.08 11:00 10 Ravi 10.02.1963 Manish 5566448 10.01.08 12:30 20 □ It can be observed from the relational table that a doctor cannot have two simultaneous appointments and thus DOCTOR_NAME and DATE_TIME is a compound key. Jitendra Tomar 20
- 21. Normalization Second Normal Form □ Similarly, a patient cannot have same time from two different doctors. Therefore, PATIENT_NAME and DATE_TIME attributes are also a candidate key. □ The Relation could be depicted as: PATIENT_DOCTOR (PATIENT_NAME, DOB, DOCTOR_NAME, DATE_TIME, CONTACT_NO, CONSULT_DURATION) □ In this relation composite key (DOCTOR_NAME, DATE_TIME) is taken as a primary key. □ But there is a partial dependency as CONTACT_NO is Functionally Dependent upon DOCTOR_NAME, and hence the relation is not in 2NF. Jitendra Tomar 21
- 22. Normalization Second Normal Form □ Therefore, to bring the relation in 2NF, the information about doctors and their contact numbers have to be separated from information about patients and their appointments with doctors. Thus, the relation is decomposed into two table namely PATIENT_DOCTOR and DOCTOR. □ The relation in 2NF can be depicted as: PATIENT_DOCTOR (PATIENT_NAME, DOB, DOCTOR_NAME, DATE_TIME, CONTACT_NO, CONSULT_DURATION) DOCTOR (DOCTOR_NAME, CONTACT_NO) Jitendra Tomar 22
- 23. Normalization Second Normal Form Contact_No Doctor_Name Patient_Name DOB Date_Time Cons Duration Doctor_Name Patient_Name DOB Date_Time Cons Duration Doctor_Name Contact_No Jitendra Tomar 23
- 24. Normalization Second Normal Form Problems in above example: □ Deleting a record from relation PATIENT_DOCTOR may lose patient’s details □ Any changes in the details of the patient may involve changing multiple occurrences because this information is still stored redundantly. Jitendra Tomar 24
- 25. Normalization Jitendra Tomar 25
- 26. Normalization Third Normal Form □ A relation R is said to be in Third Normal Form (3NF) if □ it is in 2NF, □ The non-prime attributes are □ Mutually independent & □ Functionally dependent on the primary (or relation) key. □ No attributes of the relation should be transitively functionally dependent on the primary key or no non prime attribute is functionally dependent on another non-prime attribute. □ This means that a relation in 3NF consists of the primary key and a set of independent non prime attributes. Jitendra Tomar 26
- 27. Normalization Third Normal Form □ The following Relation in 1NF was depicted as: PATIENT_DOCTOR (PATIENT_NAME, DOB, DOCTOR_NAME, DATE_TIME, CONTACT_NO, CONSULT_DURATION) □ The relation in 2NF can be depicted as: PATIENT_DOCTOR (PATIENT_NAME, DOB, DOCTOR_NAME, DATE_TIME, CONTACT_NO, CONSULT_DURATION) DOCTOR (DOCTOR_NAME, CONTACT_NO) Jitendra Tomar 27
- 28. Normalization Third Normal Form □ Therefore, to bring the relation in 2NF, the information about doctors and their contact numbers have to be separated from information about patients and their appointments with doctors. Thus, the relation is decomposed into two table namely PATIENT_DOCTOR and DOCTOR. □ The relation in 2NF can be depicted as: PATIENT_DOCTOR (PATIENT_NAME, DOB, DOCTOR_NAME, DATE_TIME, CONTACT_NO, CONSULT_DURATION) DOCTOR (DOCTOR_NAME, CONTACT_NO) Jitendra Tomar 28
- 29. Normalization The FFD in 1NF and 2NF was given as below: Contact_No Doctor_Name Patient_Name DOB Date_Time Cons Duration Doctor_Name Patient_Name DOB Date_Time Cons Duration Doctor_Name Contact_No Jitendra Tomar 29
- 30. Normalization Third Normal Form □ But the Relation still have the problem as the attribute DOB is not Functionally Dependent on the composite primary key i.e. {Doctor_Name, Date_Time} □ Infact the attribute DOB is FD on Patient_Name which is the non-key attribute. □ Thus Patient_Name and DOB are not mutually independent. □ Since in 3NF, the non-key attributes should be mutually independent and no transitive dependency should occur, hence the relation violates the requisite for 3NF. □ The relation has to be decomposed to remove the parts that are not directly dependent on primary key. Jitendra Tomar 30
- 31. Normalization The FFD in 1NF and 2NF was given as below: Doctor_Name Patient_Name DOB Date_Time Cons Duration Doctor_Name Contact_No Doctor_Name Cons Duration Patient Name DOB Date_Time Doctor_Name Contact_No Jitendra Tomar 31
- 32. Normalization Third Normal Form □ Thus the relation in 3NF is depicted as: PATIENT (PATIENT_NAME, DOB) PATIENT_DOCTOR (PATIENT_NAME, DOCTOR_NAME, DATE_TIME, CONSULT_DURATION) DOCTOR (DOCTOR_NAME, CONTACT_NO) Jitendra Tomar 32
- 33. Normalization Third Normal Form □ FFD of the relation in 3NF. Doctor_Name Cons Duration Patient_Name Date_Time Patient_Name DOB Doctor_Name Contact_No Jitendra Tomar 33