Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Int306 04

583 views

Published on

Relational Database Design - E F Codd Rules for RDBMS, Normalization, De-Normalization

Published in: Education
  • Be the first to comment

Int306 04

  1. 1. INT306 Database Management Systems RELATIONAL DATABASE DESIGN Text book Database System Concepts A. Silberschatz, H. F. Korth, S. Sudarshan Course Instructor Mr. Sumit Mittu Assistant Professor and Placement Coordinator, CSE/IT Lovely Professional University, Punjab (India) sumit.12735@lpu.co.in sumit.mittu@gmail.com http://tinyurl.com/askSumit 01-03-2014 11:40:41
  2. 2. IN THIS CHAPTER • e. f. codd rules for rdbms • normalization of database 01-03-2014 11:40:42 Sumit Mittu, Assistant Professor, CSE/IT 2
  3. 3. E. F. CODD RULES • Codd's Rules for RDBMS • E.F Codd was a Computer Scientist who invented Relational model for Database management. • Based on relational model, Relation database was created. • Codd proposed 13 rules popularly known as Codd's 12 rules to test DBMS's concept against his relational model. • Codd's rule actually define what quality a DBMS requires in order to become a Relational Database Management System(RDBMS). • Till now, there is hardly any commercial product that follows all the 13 Codd's rules. • Even Oracle follows only eight and half out(8.5) of 13. 01-03-2014 11:40:42 Sumit Mittu, Assistant Professor, CSE/IT 3
  4. 4. E. F. CODD RULES Rule zero Rule 1 : Information rule Rule 2 : Guaranteed Access 01-03-2014 11:40:42 • This rule states that for a system to qualify as an RDBMS, it must be able to manage database entirely through the relational capabilities. • All information(including metadeta) is to be represented as stored data in cells of tables. The rows and columns have to be strictly unordered. • Each unique piece of data(atomic value) should be accesible by : Table Name + primary key(Row) + Attribute(column). Sumit Mittu, Assistant Professor, CSE/IT 4
  5. 5. E. F. CODD RULES Rule 3 : Systemetic treatment of NULL •Null has several meanings, it can mean missing data, not applicable or no value. It should be handled consistently. Primary key must not be null. Expression on NULL must give null. Rule 4 : Active Online Catalog •Database dictionary(catalog) must have description of Database. Catalog to be governed by same rule as rest of the database. The same query language to be used on catalog as on application database. Rule 5 : Powerful language •One well defined language must be there to provide all manners of access to data. Example: SQL. If a file supporting table can be accessed by any manner except SQL interface, then its a violation to this rule. 01-03-2014 11:40:42 Sumit Mittu, Assistant Professor, CSE/IT 5
  6. 6. E. F. CODD RULES Rule 6 : View Updation rule Rule 7 : Relational Level Operation Rule 8 : Physical Data Independence 01-03-2014 11:40:43 •All view that are theoretically updatable should be updatable by the system. •There must be Insert, Delete, Update operations at each level of relations. Set operation like Union, Intersection and minus should also be supported. •The physical storage of data should not matter to the system. If say, some file supporting table were renamed or moved from one disk to another, it should not effect the application. Sumit Mittu, Assistant Professor, CSE/IT 6
  7. 7. E. F. CODD RULES Rule 9 : Logical Data Independence •If there is change in the logical structure(table structures) of the database the user view of data should not change. Say, if a table is split into two tables, a new view should give result as the join of the two tables. This rule is most difficult to satisfy. Rule 10 : Integrity Independence •The database should be able to enforce its own integrity rather than using other programs. Key and Check constraints, trigger etc. should be stored in Data Dictionary. This also make RDBMS independent of front-end. Rule 11 : Distribution Independence •A database should work properly regardless of its distribution across a network. This lays foundation of distributed database. 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 7
  8. 8. E. F. CODD RULES Rule 12 : Nonsubversion rule 01-03-2014 11:40:43 • If low level access is allowed to a system it should not be able to subvert or bypass integrity rule to change data. This can be achieved by some sort of looking or encryption. Sumit Mittu, Assistant Professor, CSE/IT 8
  9. 9. SCRATCH YOUR MIND!!! • 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 9
  10. 10. NORMALIZATION • • • • Normalization Need for Normalization Anomalies in database Decomposition • Desirable Properties • Attribute Dependency • FD, FFD, PFD, TD, MVD, etc. 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 10
  11. 11. NORMALIZATION • Normal Forms • Phases/Levels of Normalization • • • • • • • • 1 NF – First Normal Form 2 NF – Second Normal Form 3 NF – Third Normal Form BCNF – Boyce Codd Normal Form 4 NF – Fourth Normal Form 5 NF – Fifth Normal Form DKNF – Domain Key Normal Form Etc. 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 11
  12. 12. NORMALIZATION • Normal Forms • • • • 1 NF 2 NF 3 NF BCNF • 4 NF – Eliminate groups + Preserve Functional Dependencies – Eliminate Transitive Dependencies + Preserve FDs that determinants are irreducible candidate key – Eliminate Multi-valued Dependencies • at most 1 multi-valued dependency can be allowed • 5 NF 01-03-2014 11:40:43 + Preserve Join Dependency Sumit Mittu, Assistant Professor, CSE/IT 12
  13. 13. NORMALIZATION • First Normal Form • • • • • The data must be represented as tables Fields must be atomic domains There should be no multivalued attributes Data must be represented as non-repeating groups Do not have null values against record fields • Example… 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 13
  14. 14. NORMALIZATION • Second Normal Form • Tables must be in 1NF • There must be a candidate key in each table • Preserve Fully-Functional Dependencies • Partial FDs should not exist • Determinant may be composite key • All non-key attributes must be dependent on key attribute • Example… 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 14
  15. 15. NORMALIZATION • Third Normal Form • Tables must be in 2NF • There must be a candidate key in each table • Eliminate all Transitive Dependencies • Example… 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 15
  16. 16. NORMALIZATION • Boyce-Codd Normal Form • • • • Tables must be in 2NF There must be a candidate key in each table Every determinant must be non-composite (irreducible) Every irreducible determinant must be a candidate key • Example… 01-03-2014 11:40:42 Sumit Mittu, Assistant Professor, CSE/IT 16
  17. 17. NORMALIZATION • Fourth Normal Form • Tables must be in 3NF / BCNF • Eliminate all multi-valued dependencies • If not possible, decompose the relations such that each relation after decomposition must not have more than one multi-valued dependency • Example… 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 17
  18. 18. NORMALIZATION • Fifth Normal Form • Tables must be in 4NF • Preserve Join Dependency • There are certain conditions under which after decomposing a relation, it cannot be reassembled losslessly back into its original form. • It is 5NF when this stage is reached • This normal form is also known as Project-Join normal Form (PJNF) • Example… 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 18
  19. 19. DE-NORMALIZATION • De-normalization • In order to improve performance, the designers sometimes choose a schema that has redundant information • De-normalization presents a trade-off between performance and modification anomalies / data redundancy. • Example… 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 19
  20. 20. DE-NORMALIZATION • The relation CUSTOMER (CustomerID, Name, Address, City, State, Zip) can be normalized as: • CUSTOMER (CustomerID, Name, Address, Zip) • ZIPCODES (Zip, City, State) • This suffers with a performance penalty like: • Each customer address lookup requires we look in two relations (tables). • More technically, obtaining a complete customer and address record requires us to join CUSTOMER and ZIPCODES together. • Hence, de-normalization is performed • re-assemble the original CUSTOMER relation we started with that will contain all of the attributes. 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 20
  21. 21. SCRATCH YOUR MIND!!! • • 01-03-2014 11:40:43 Sumit Mittu, Assistant Professor, CSE/IT 21

×