Presentation is loading. Please wait.

Presentation is loading. Please wait.

IT-501 Database Management Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University.

Similar presentations


Presentation on theme: "IT-501 Database Management Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University."— Presentation transcript:

1 IT-501 Database Management Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University

2 Lecture 04 Relational Database Design Normalization-Part-2

3 Outline Overview of Relational DBMS  Normalization

4 Example 3: Determine NF Part_ID  Description Part_ID  Price Part_ID, Comp_ID  No Comp_ID and No are not determined by the primary key; therefore, the relation is NOT in 1 NF. No sense in looking at partial or transitive dependencies. Part_IDDescrPriceComp_IDNo

5 Example 3: Determine NF Part_ID  Description Part_ID  Price Part_ID, Comp_ID  No In your solution you will write the following justification: 1) There are M/V attributes; therefore, not 1NF Conclusion: The relation is not normalized.

6 Bringing a Relation to 1NF

7 Option 1: Make a determinant of the repeating group (or the multivalued attribute) a part of the primary key. Composite Primary Key

8 Bringing a Relation to 1NF Option 2: Remove the entire repeating group from the relation. Create another relation which would contain all the attributes of the repeating group, plus the primary key from the first relation. In this new relation, the primary key from the original relation and the determinant of the repeating group will comprise a primary key.

9 Bringing a Relation to 1NF

10 Bringing a Relation to 2NF Composite Primary Key

11 Bringing a Relation to 2NF Composite Primary Key Goal: Remove Partial Dependencies Partial Dependencies

12 Bringing a Relation to 2NF Remove attributes that are dependent from the part but not the whole of the primary key from the original relation. For each partial dependency, create a new relation, with the corresponding part of the primary key from the original as the primary key.

13 Bringing a Relation to 2NF

14 Bringing a Relation to 3NF Goal: Get rid of transitive dependencies. Transitive Dependency

15 Bringing a Relation to 3NF Remove the attributes, which are dependent on a non-key attribute, from the original relation. For each transitive dependency, create a new relation with the non-key attribute which is a determinant in the transitive dependency as a primary key, and the dependent non-key attribute as a dependent.

16 Bringing a Relation to 3NF

17 Unnormalised Normal Form (UNF) ORDER (order-no, order-date, cust-no, cust-name, cust-add, (prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total

18 First Normal Form (1NF) Definition: A relation is in 1NF if, and only if, all its underlying attributes contain atomic values only. Steps from UNF to 1NF:  Remove the outermost repeating group (and any nested repeated groups it may contain) and create a new relation to contain it.  Add to this relation a copy of the PK of the relation immediately enclosing it.  Name the new entity (appending the number 1 to indicate 1NF)  Determine the PK of the new entity  Repeat steps until no more repeating groups. Remove repeating groups into a new relation A repeating group is shown by a pair of brackets within the relational schema. ORDER (order-no, order-date, cust-no, cust-name, cust-add, (prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total

19 Example - UNF to 1NF ORDER (order-no, order-date, cust-no, cust-name, cust-add, (prod-no, prod-desc, unit-price, ord-qty, line-total)*, order-total 1. Remove the outermost repeating group (and any nested repeated groups it may contain) and create a new relation to contain it. (rename original to indicate 1NF) ORDER-1 (order-no, order-date, cust-no, cust-name, cust-add, order-total (prod-no, prod-desc, unit-price, ord-qty, line-total) 2. Add to this relation a copy of the PK of the relation immediately enclosing it. ORDER-1 (order-no, order-date, cust-no, cust-name, cust-add, order-total (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total) 3. Name the new entity (appending the number 1 to indicate 1NF) ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total) 4. Determine the PK of the new entity ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total)

20 Second Normal Form (2NF) Definition: A relation is in 2NF if, and only if, it is in 1NF and every non-key attribute is fully dependent on the primary key. Steps from 1NF to 2NF:  Remove the offending attributes that are only partially functionally dependent on the composite key, and place them in a new relation.  Add to this relation a copy of the attribute(s) which are the determinants of these offending attributes. These will automatically become the primary key of this new relation.  Name the new entity (appending the number 2 to indicate 2NF)  Rename the original entity (ending with a 2 to indicate 2NF) Remove partial functional dependencies into a new relation

21 Example - 1NF to 2NF ORDER-LINE-1 (order-no, prod-no, prod-desc, unit-price, ord-qty, line-total) 1. Remove the offending attributes that are only partially functionally dependent on the composite key, and place them in a new relation. ORDER-LINE-1 (order-no, prod-no, ord-qty, line-total) (prod-desc, unit-price) 2. Add to this relation a copy of the attribute(s) which determines these offending attributes. These will automatically become the primary key of this new relation.. (prod-no, prod-desc, unit-price) ORDER-LINE-1 (order-no, prod-no, ord-qty, line-total) 3. Name the new entity (appending the number 2 to indicate 2NF) PRODUCT-2 (prod-no, prod-desc, unit-price) 4. Rename the original entity (ending with a 2 to indicate 2NF) ORDER-LINE-2 (order-no, prod-no, ord-qty, line-total)

22 Third Normal Form (3NF) Definition: A relation is in 3NF if, and only if, it is in 2NF and every non-key attribute is non-transitively dependent on the primary key. Steps from 2NF to 3NF:  Remove the offending attributes that are transitively dependent on non-key attribute(s), and place them in a new relation.  Add to this relation a copy of the attribute(s) which are the determinants of these offending attributes. These will automatically become the primary key of this new relation.  Name the new entity (appending the number 3 to indicate 3NF)  Rename the original entity (ending with a 3 to indicate 3NF) Remove transitive dependencies into a new relation

23 Example - 2NF to 3NF ORDER-2 (order-no, order-date, cust-no, cust-name, cust-add, order-total 1. Remove the offending attributes that are transitively dependent on non-key attributes, and place them in a new relation. (cust-name, cust-add ) ORDER-2 (order-no, order-date, cust-no, order-total 2. Add to this relation a copy of the attribute(s) which determines these offending attributes. These will automatically become the primary key of this new relation.. (cust-no, cust-name, cust-add ) ORDER-2 (order-no, order-date, cust-no, order-total 3. Name the new entity (appending the number 3 to indicate 3NF) CUSTOMER-3 (cust-no, cust-name, cust-add ) 4. Rename the original entity (ending with a 3 to indicate 3NF) ORDER-3 (order-no, order-date, cust-no, order-total

24 Example - Relations in 3NF CUSTOMER-3 (cust-no, cust-name, cust-add ) ORDER-3 (order-no, order-date, cust-no, order-total ORDER-LINE-2 (order-no, prod-no, ord-qty, line-total) PRODUCT-2 (prod-no, prod-desc, unit-price) CUSTOMER ORDER ORDER-LINE PRODUCT places placed by contains part of shows belongs to cust-no order-no prod-no order-no, prod-no

25 Case Study on Normalization Consider the table EMP_DEPT_PROJ And the following dependencies which exist in the above table: Slide 25

26 Steps to Normalize the database D Thus we will have 3 tables Slide 26

27 Step 2  Let us now identify the transitive dependency and remove it. Slide 27 Steps to Normalize the database

28 Step 3:  Let us now identify the non key determinants and remove them.  Thus we will have 5 tables Slide 28 Steps to Normalize the database

29 Suppose The Gill Art Gallery wishes to maintain data on their customers, artists and paintings. They may have several paintings by each artist in the gallery at one time. Paintings may be bought and sold several times. In other words, the gallery may sell a painting, then buy it back at a later date and sell it to another customer. UNF:  customer [ custno, cust_name, cust_addr, cust_phone, ( artist_id, artist_name, art_title, pur_date, price) ] 1NF:  customer [ custno, cust_name, cust_addr, cust_phone]  cust_art [ custno, art_code, pur_date, artist_id, artist_name, art_title, price ] Slide 29 Case Study on Normalization

30 UNF:  customer [ custno, cust_name, cust_addr, cust_phone, ( artist_id, artist_name, art_title, pur_date, price) ] 1NF:  customer [ custno, cust_name, cust_addr, cust_phone]  cust_art [ custno, art_code, pur_date, artist_id, artist_name, art_title, price ] o note: the key chosen for the repeating group is the piece of art itself (a code was assigned), however because a piece of art may be bought by a customer more than once, the purchase date was added as part of the key to make the rows unique. Slide 30 Case Study on Normalization

31 1NF:  customer [ custno, cust_name, cust_addr, cust_phone]  cust_art [ custno, art_code, pur_date, artist_id, artist_name, art_title, price ] 2NF:  customer [ custno, cust_name, cust_addr, cust_phone]  cust_art [ custno, art_code, pur_date, price ]  art [ art_code, art_title, artist_id, artist_name ] Slide 31 Case Study on Normalization

32 2NF:  customer [ custno, cust_name, cust_addr, cust_phone]  cust_art [ custno, art_code, pur_date, price ]  art [ art_code, art_title, artist_id, artist_name ] 3NF:  customer [ custno, cust_name, cust_street, cust_city, cust_prov, cust_pstlcd, cust_phone]  cust_art [ custno, art_code, pur_date, price ]  art [ art_code, art_title, artist_id(FK) ]  artist [ artist_id, artist_fname, artist_lname ] Slide 32 Case Study on Normalization

33 3NF:  customer [ custno, cust_name, cust_street, cust_city, cust_prov, cust_pstlcd, cust_phone]  cust_art [ custno, art_code, pur_date, price ]  art [ art_code, art_title, artist_id(FK) ]  artist [ artist_id, artist_fname, artist_lname ] Slide 33 Case Study on Normalization

34 Review Class on Relational Algebra Slide 34

35 Natural Join Operation – Example Relations r, s: AB  1241212412 CD  aababaabab B 1312313123 D aaabbaaabb E  r AB  1111211112 CD  aaaabaaaab E  s r s Slide 35  r.A, r.B, r.C, r.D, s.E (  r.B = s.B  r.D = s.D (r x s))

36 The customer Relation 36 The branch Relation The depositor Relation Account Relation

37 borrower Relation 37 The Loan Relation Loan-numberBranch-nameamount L-11Round Hill900 L-14Downtown1500 L-15Perryridge1500 L-16Perryridge1300 L-17Downtown1000 L-23Redwood2000 L-93Mianus500

38 Result of  customer-name, branch-name (depositor account) 38 Result of  customer-name, loan-number, amount (borrower loan)

39 Division Operation – Example Relations r, s: r  s:r  s: A B  1212 AB  1231113461212311134612 r s 39

40 Another Division Example AB  aaaaaaaaaaaaaaaa CD  aabababbaabababb E 1111311111113111 Relations r, s: r  s:r  s: D abab E 1111 AB  aaaa C  r s 40

41 Find all customers who have an account at all branches located in Brooklyn city. Example Queries  customer-name, branch-name (depositor account)   branch-name (  branch-city = “Brooklyn” (branch)) Slide 41 depositor account branch

42 Result of  customer-name, branch-name (depositor account) 42 Result of  branch-name (  branch-city = “Brooklyn” (branch))  customer-name, branch-name (depositor account)   branch-name (  branch-city = “Brooklyn” (branch)) Customer-name Johnson

43 Thank You


Download ppt "IT-501 Database Management Systems By- Jesmin Akhter Assistant Professor, IIT, Jahangirnagar University."

Similar presentations


Ads by Google