NORMALIZATION Relation P: P# PNAME COLOR WEIGHT CITY P1 Nut Red 12.0 London P2 Bolt Green 17.0 Paris P3 Screw Blue 17.0 Rome P4 Screw Red 14.0 London P5 Cam Blue 12.0 Paris P6 Cog Red 19.0 London Relation S: S# SNAME STATUS CITY S1 Smith 20 London S2 Jones 10 Paris S3 Black 30 Paris S4 Clerk 20 London S5 Adams 30 Athens Relation SP: S# S1 S1 S1 S1 S1 S1 S2 S2 S3 S4 P# P1 P2 P3 P4 P5 P6 P1 P2 P2 P2 QTY 300 200 400 200 100 100 300 400 200 200 SCP S# S1 S1 S2 S2 S3 S4 S4 S4 CITY London London Paris Paris Paris London London London P# P1 P2 P1 P2 P2 P2 P4 P5 QTY 100 100 200 200 300 400 400 400 • Problem with SCP is redundancy. • Relation are always normalized so far as it has legal values. • Than we can say that relation are always normalized or in first normal form “1NF”. • A given relation might be normalized yet still possess certain undesirable properties. • The principal of further normalization allow us to recognize such cases and to replace such relation by ones that are more desirable in some way. • In the case of SCP, they would tell us how to replace it by two more desirable relations {s#,city} and {s#,p#,qty}. Normalization • Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy. • Normalization usually involves dividing large tables into smaller (and less redundant) tables and defining relationships between them. • The objective is to isolate data so that additions, deletions, and modifications of a field can be made in just one table and then propagated through the rest of the database using the defined relationships. Non loss decomposition • Normalization procedure involves breaking down or decomposing a given relation into other relation and that decomposition is required to be reversible so that no information is lost. • S- S# STATUS CITY S3 S5 (A) 30 30 Paris Athens SST- S# STATUS S3 30 S5 30 SC- S# CITY S3 Paris S5 Athens --NONLOSS DECOMPOSTION (B) SST - S# STATUS S3 30 S5 30 --LOSSY DECOMPOSTION STC - STATUS CITY 30 Paris 30 Athens FD diagram SNAME S# S# QTY STATUS P# CITY FIRST, SECOND, THIRD NORMAL FORMS • (informal defi): • Third normal form: A relvar is in 3NF if and only if the nonkey attributes (if any) are A. mutually independent, and B. irreducibly dependent on the primary key. • (even more informal defi): • Third normal form: A relvar is in 3NF if and only if, for all time, each tuple consists of primary key value that identifies entity, together with a set of 0 or more mutually independent attribute values that describe that entity in some way. First NF • A relvar is in 1NF if and only if, in every legal value of that relvar, every tuple contains exactly one value for each attribute. • First { s#, status, city, p#, qty} primary key {s#,p#} S# STATUS QTY P# CITY S# S1 S1 S1 S1 S1 S1 S2 S2 S3 S4 S4 S4 STATUS 20 20 20 20 20 20 10 10 10 20 20 20 CITY London London London London London London Paris Paris Paris London London London P# P1 P2 P3 P4 P5 P6 P1 P2 P2 P2 P4 P5 QTY 300 200 400 200 100 100 300 400 200 200 300 400 • SECOND -SP S# STATUS CITY S# P# QTY S1 20 London S1 P1 100 S2 10 Paris S1 P2 100 S3 10 Paris S2 P1 200 S4 20 London S2 P2 200 S5 30 Athens S3 P2 300 S4 P2 400 S4 P4 400 S4 P5 400 Second NF • A relvar is in 2NF if and only if, it is in 1NF and every nonkey attribute is irreducibly dependent on the primary key. • SC--- S# CITY CS -- city status S1 s2 s3 s4 s5 London Paris paris london Athens Athens London paris rome 30 20 10 50 Third NF • A relvar is in 3NF if and only if it is in 2NF and every nonkey attribute is nontransitively dependent on the primary key. BCNF • Boyce/Codd normal form • Upto now it was assumed that every relation has just one candidate key • Consider what happens when more than one candidate keys • 3NF did not adequately deal with the case of relation that – Had two or more candidate keys – Candidate keys were composite – They overlapped • So the original definition of 3NF was replaced by a stronger definition due to Boyce and Codd, that catered for this case. • Before explanation of BCNF, reminder should be of – Determinant (left side of FD) • {A} --> {B} A is called as determinant – Trival and nontrival FD Defination of BCNF • Formal defi.: • A relation is in BCNF if and only if every nontrival , left irreducible FD has a candidate key as its determinant. • Informal defi.: – A relation is in BCNF if and only if every determinant is a candidate key. – In other words, the only arrow in FD diagram are arrows out of candidate keys. • Before considering some examples involving more than one candidate key, let us convince ourselves that relation FIRST and SECOND which were not in 3NF, are not in BCNF. • Relation FIRST contains 3 determinants, {sup_no}, {city}, {sup_no, part_no} • Relation SECOND is also not in BCNF because the determinant {city} is not a candidate key and FD is {city} {status}. • Consider another example having two candidate keys. • Relation SUPPLIER { sup_no, aadhar_no, sup_name, city} • Candidate keys: {sup_no} and {aadhar_no} • Assumption: – for all time, it is the case that every supplier has a unique sup_no and also a unique aadhar_no. Sup_no Aadhar_no Sup_nama city S1 12483847 John London S2 57475688 Devid Paris S3 67578488 Prince Athens S4 57465663 John Rome S5 34344567 Madonna New York • so FD diagram will be Sup_no Aadhar_no Sup_name city 4NF Course DBMS Maths Teachers Texts Teacher Text Devangimam Henry korth Tejassir Ivan bayross Teacher Text Krishnamam Vector analysis Patatsir Trigonometry Relation: CTX Course Teachers Texts DBMS Devangimam Hery korth DBMS Devangimam Ivan bayross DBMS Tejassir Hery korth DBMS Tejassir Ivan bayross Maths Krishnamam Vector analysis Maths Krishnamam Trigonometry Maths Patatsir Vector analysis Maths Patatsir Trigonometry • In relation CTX Multi-Valued Dependancy – Course->-> Teacher and – Course->->Text are there. • MVDs occur when two or more independent multi valued facts about the same attribute occur within the same table. • Here MVD means that – A course does not have a unique corresponding teacher – But each course have well-defined set of teachers – So we can say that, for a given value of course C-Maths and a given text x-vector analysis, the set of teachers t matching the pair (C,x) in CTX depends on the value C alone because it makes no difference which particular value of x we choose. • Problem with CTX: – It involved good deal of redundancy – Leads to update anomalies • For e.g. to add information that DBMS course can be taught by a new teacher, it is necessary to insert two separate tuples, one for each of the two texts. • Here problem is caused by the fact that teachers and texts are completely independent of one another. – So CTX can be decomposed into two projections called CT and CX • CT Course Teachers DBMS Devangimam DBMS Tejassir Maths Krishnamam Maths Patatsir • CX Course Texts DBMS Hery Korth DBMS Ivan bayross Maths Vector analysis Maths Trigonometry Definition of 4NF • A relation R is in Fourth Normal Form (4NF) if and only if the following conditions are satisfied simultaneously: – R is already in 3NF or BCNF. – If it contains no multi-valued dependencies. 5NF • A relation R is in Fifth Normal Form (5NF) if and only if the following conditions are satisfied simultaneously: • -R is already in 4NF. • -It cannot be further non-loss decomposed. • In all of the further normal forms discussed so far, no loss decomposition was achieved by the decomposing of a single table into two separate tables. • No loss decomposition is possible because of the availability of the join operator as part of the relational model. • In considering 5NF, consideration must be given to tables where this non-loss decomposition can only be achieved by decomposition into three or more separate tables. • Such decomposition is not always possible as is shown by the following example. Under these circumstances, the 'agent company product' table as shown below: This table can be decomposed into its three projections without loss of information as demonstrated below: If the natural join of PI and P2 IS taken, the result is: (The spurious row as asterisked. ) -Now, if this result is joined with P3 over the column 'company 'product_name' the following table is obtained: -The original table, therefore, violated 5NF simply because it was non-loss decomposable into its three projections. -But see the below table, named ‘Agent_Company_product’. If we devide it in two table P1 and P2 than spurious record will be there when P1 and P2 joins. • but if it is devided into three table than join of all three projection P1, P2 and P3 (company, product_name) than also it contains spurious record. - so it is not simply possible of decompose the 'AGENT_COMPANY_PRODUCT' table, populated as shown, without losing information.