Database Design and Normalization Techniques
Download as PPTX, PDF7 likes2,336 views
The document discusses database normalization and its goals. It defines various normalization forms including first, second, third normal forms and Boyce-Codd normal form. It explains concepts like functional dependencies, transitive dependencies and multi-valued dependencies. Examples are given to illustrate anomalies like update, deletion and insertion anomalies that can occur without normalization. The benefits of normalization in removing redundancy and ensuring data integrity are also highlighted.
Database Design and Normalization Techniques
- 2. Determinant and Dependent ā¢ The expression X ā Y means 'if I know the value of X, then I can obtain the value of Y' (in a table or somewhere). ā¢ In the expression X ā Y, X is the determinant and Y is the dependent attribute. ā¢ The value X determines the value of Y. ā¢ The value Y depends on the value of X.
- 3. Functional Dependencies (FD) ā¢ An attribute is functionally dependent if its value is determined by another attribute which is a key. ā¢ That is, if we know the value of one (or several) data items, then we can find the value of another (or several). ā¢ Functional dependencies are expressed as X ā Y, where X is the determinant and Y is the functionally dependent attribute. ā¢ If A ā(B,C) then A ā B and A ā C. ā¢ If (A,B) ā C, then it is not necessarily true that A ā C and B ā C. ā¢ If A ā B and B ā A, then A and B are in a 1-1 relationship. ā¢ If A ā B then for A there can only ever be one value for B.
- 4. ā¦ ā¢ Functional dependency is a relationship that exists when one attribute uniquely determines another attribute. ā¢ If R is a relation with attributes X and Y, a functional dependency between the attributes is represented as X->Y, which specifies Y is functionally dependent on X. Here X is a determinant set and Y is a dependent attribute. Each value of X is associated precisely with one Y value. ā¢ Functional dependency in a database serves as a constraint between two sets of attributes. Defining functional dependency is an important part of relational database design and contributes to aspect normalization. Example: In a table with attributes of employee name and Social Security number (SSN), employee name is functionally dependent on SSN because the SSN is unique for individual names. An SSN identifies the employee specifically, but an employee name cannot distinguish the SSN because more than one employee could have the same name.
- 5. Transitive Dependencies (TD) ā¢ An attribute is transitively dependent if its value is determined by another attribute which is not a key. ā¢ If X ā Y and X is not a key then this is a transitive dependency. ā¢ A transitive dependency exists when A ā B ā C but NOT A ā C.
- 6. Multi-Valued Dependencies (MVD) ā¢ A table involves a multi-valued dependency if it may contain multiple values for an entity. ā¢ XāY, i.e. X multi-determines Y, when for each value of X we can have more than one value of Y. ā¢ If AāB and AāC then we have a single attribute A which multi-determines two other independent attributes, B and C. ā¢ If Aā(B,C) then we have an attribute A which multi-determines a set of associated attributes, B and C.
- 7. Why Normalization: Redundancy Roll No. Name Age Branch Branch ID 1 Anmol 24 CSE 101 2 Ansh 23 CSE 101 3 Akshay 25 CSE 101 4 Bhuvnesh 26 CSE 101
- 8. Anomalies of Database Update anomalies ā If data items are scattered and are not linked to each other properly, then it could lead to strange situations. For example, when we try to update one data item having its copies scattered over several places, a few instances get updated properly while a few others are left with old values. Such instances leave the database in an inconsistent state. In the above example if the branch code 101 is updated to 102, in that case we need to update all the rows. Deletion anomalies ā We tried to delete a record, but parts of it was left undeleted because of unawareness, the data is also saved somewhere else. In the above slide example, when we delete all the record of students automatically the data of branch name and branch id is getting deleted, which is not required to delete. We are deleting student information because of which branch information is also being deleted. Insert anomalies ā We tried to insert data in a record that does not exist at all.
- 9. Normalization Normalization is a method to remove all these anomalies and bring the database to a consistent state or we can say it is the process to remove redundancy. It contains 4 ways to resolve anomalies using 4 normal forms. 1. First Normal Form 2. Second Normal Form 3. Third Normal Form 4. Boyce-Codd Normal Form
- 10. First Normal Form First Normal Form is defined in the definition of relations (tables) itself. This rule defines that all the attributes in a relation must have atomic domains. The values in an atomic domain are indivisible units. We re-arrange the relation (table), to convert it to First Normal Form. Before Normalization After Normalization
- 11. Second Normal Form If we follow second normal form, then every non-prime attribute should be fully functionally dependent on prime key attribute. That is, if X ā A holds, then there should not be any proper subset Y of X, for which Y ā A also holds true. Prime Key Attributes: Stud_ID, Proj_ID Non Key Attributes: Stu_Name, Proj_Name As per rule: Non-key attributes, i.e. Stu_Name and Proj_Name must be dependent upon both and not on any of the prime key attribute individually. But we find that Stu_Name can be identified by Stu_ID and Proj_Name can be identified by Proj_ID independently. This is called partial dependency, which is not allowed in Second Normal Form.
- 12. ā¦
- 13. Third Normal Form For a relation to be in Third Normal Form, and the following must satisfy ā ā¢ It must be in Second Normal form ā¢ No non-prime attribute is transitively dependent on prime key attribute. ā¢ Every non-prime attribute of R is non-transitively dependent on every key of R. We find that in the above Student_detail relation, Stu_ID is the key and only prime key attribute. We find that City can be identified by Stu_ID as well as Zip itself. Neither Zip is a superkey nor is City a prime attribute. Additionally, Stu_ID ā Zip ā City, so there exists transitive dependency.
- 14. ā¦
- 15. Boyce-Codd Normal Form Boyce-Codd Normal Form (BCNF) is an extension of Third Normal Form on strict terms. BCNF states that ā For any non-trivial functional dependency, X ā A, X must be a super-key. In the above image, Stu_ID is the super-key in the relation Student_Detail and Zip is the super- key to the relation ZipCodes. So, Stu_ID ā Stu_Name, Zip and Zip ā City Which confirms that both the relations are in BCNF.
- 16. Loss-less join Decomposition ā¢ Decomposition ā the process of breaking down in parts or elements. ā¢ Decomposition in database means breaking tables down into multiple tables From Database perspective means going to a higher normal form. ā¢ Important that decompositions are āgoodā, ā¢ Two Characteristics of Good Decompositions 1) Lossless: Means functioning without a loss. In other words, retain everything after being break in two or more tables. 2) Preserve dependencies
- 17. Lossless Decomposition Sometimes the same set of data is reproduced: (Word, 100) + (Word, WP) ļ (Word, 100, WP) (Oracle, 1000) + (Oracle, DB) ļ (Oracle, 1000, DB) (Access, 100) + (Access, DB) ļ (Access, 100, DB) Name Price Category Word 100 WP Oracle 1000 DB Access 100 DB Name Price Word 100 Oracle 1000 Access 100 Name Category Word WP Oracle DB Access DB
- 18. Lossy Decomposition Sometimes itās not: (Word, WP) + (100, WP) = (Word, 100, WP) (Oracle, DB) + (1000, DB) = (Oracle, 1000, DB) (Oracle, DB) + (100, DB) = (Oracle, 100, DB) (Access, DB) + (1000, DB) = (Access, 1000, DB) (Access, DB) + (100, DB) = (Access, 100, DB) Name Price Category Word 100 WP Oracle 1000 DB Access 100 DB Category Name WP Word DB Oracle DB Access Category Price WP 100 DB 1000 DB 100 Whatās wrong?
- 19. Column Name Data Type supplierID(primary key) Int suppliername varchar(20) products varchar(20) SupplierID Supplier Name Products 1 Yeki Inc. tshirt, shirt, jeans Column Name Data Type supplierID(primary key) Int suppliername varchar(20) Column Name Data Type Productid Int Productname varchar(20) Supplierid Int Suppliers Suppliers Products
- 20. Column Name Data Type Productid Int Productname varchar(20) StoreName Varchar(20) Price int Products ProductID ProductName StoreName Price 1 Blue Shirt Store1 2000 2 White Shirt Store2 2300 3 Grey Shirt Store5 2200 4 Blue Shirt Store4 2000 Column Name Data Type Productid Int Productname varchar(20) Price int Column Name Data Type Storeid Int StoreName varchar(20) ProductName Varchar(20) Products Stores 1. There should not be any partial key dependencies. Attribute must be depended upon key. 2. Another principle is there should not be no derived data or calculated fields, such as total, while you have price and quantity in the table. Here product is dependent on store but the attributes donāt have to be depend only on key, so product name in this case does depend on store, but it doesnāt only depend on store for its existence.
- 21. Column Name Data Type Productid Int Productname varchar(20) Price int Column Name Data Type Storeid Int StoreName varchar(20) Column Name Data Type Storeid Int Productid varchar(20) Products Stores Inventory Attribute must be solely dependent upon the key. Third normal form essentially removes the transitive dependency.
- 22. BCNF StudentID Name Course Duration 1 Tom Java 60 2 Jerry Database 90 3 Duck Database Adv 100 4 Donalds Database 100
- 23. THANKS