Presentation is loading. Please wait.

Presentation is loading. Please wait.

Functional Dependencies and Normalization for Relational Databases تنبيه : شرائح العرض (Slides) هي وسيلة لتوضيح الدرس واداة من الادوات في ذلك. حيث المرجع.

Similar presentations


Presentation on theme: "Functional Dependencies and Normalization for Relational Databases تنبيه : شرائح العرض (Slides) هي وسيلة لتوضيح الدرس واداة من الادوات في ذلك. حيث المرجع."— Presentation transcript:

1 Functional Dependencies and Normalization for Relational Databases تنبيه : شرائح العرض (Slides) هي وسيلة لتوضيح الدرس واداة من الادوات في ذلك. حيث المرجع الاساسي للمادة هي الكتاب المعتمد في وصف المقرر

2 Outline 2  Normalization Definition  Normal From  Definitions of Keys and Attributes Participating in Keys  First Normal Form  Second Normal Form 2NF  Third Normal Form 3NF  General Definition of 2NF (For Multiple Keys)  General Definition of 3NF (For Multiple Keys)  Boyce-Codd Normal Form (BCNF)

3 Normalization 3  The process of decomposing unsatisfactory "bad" relations by breaking up their attributes into smaller relations  Is a formal technique for analyzing relations based on their primary key and functional dependencies

4 Normalization Chapter 10-4  The technique involve a series of rules that can be used to test individual relation to certify whether it satisfy a certain normal form  When a requirement is not met, the relation violating the requirement must be decomposed into more than one relation that individually met the requirement of the normalization 4

5 Normal From 5  Normal form: Condition using keys and FDs of a relation to certify whether a relation schema is in a particular normal form  Three normal form were initially proposed by Codd  First Normal Form 1FN  Second Normal Form 2FN  Third Normal Form 3FN  Boyce-Codd introduce a stronger definition of third normal form called ByCode Normal Form (BCNF)  Higher normal form such as 4NF and 5NF deal with a situation that are very rare

6 Normal From Chapter 10-6  Normalization is often executed as a series of steps  Each step corresponds to a specific normal form  As a normalization proceeds, the relations become more stronger in format that avoid anomaly  In general, it is recommended that we proceed to at least third normal form to avoid update anomaly 6

7 Definitions of Keys and Attributes Participating in Keys Chapter 10-7  A superkey of a relation schema R = {A 1, A 2,...., A n }  is a set of attributes S subset-of R with the property that no two tuples t 1 and t 2 in any legal relation state r of R will have t 1 [S] = t 2 [S]  A key K is a superkey with the additional property that removal of any attribute from K will cause K not to be a superkey any more. 7

8 Definitions of Keys and Attributes Participating in Keys Chapter 10-8  If a relation schema has more than one key, each is called a candidate key.  One of the candidate keys is arbitrarily designated to be the primary key, and the others are called secondary keys.  Prime attribute  Is an attribute that is member of the primary key K  Nonprime attribute  is not a prime attribute  it is not a member of any candidate key. 8

9 First Normal Form Chapter 10-9  Disallows  composite attributes  multivalued attributes  nested relations attributes whose values for an individual tuple are non-atomic  It state that the domain of an attribute must include only atomic values (single)  In other word, it disallow relations within relation 9

10 1NF Example (1) Chapter 10-10 DEPARTMERNT DNAMEDNUMBERDMGRSSNDLOCATIONS  We assume that each department can have a number of locations  This relation is not in 1NF, because DLOCATION is not an atomic attribute  There are two ways we can look at the DLOCATIONS attribute 10

11 1NF Example (1) Chapter 10-11  The domain of DLOCATIONS contains atomic values  In this case, DLOCATIONS is not functionally dependent on the primary key, and cause update anomaly because it introduce redundancy in relation DNAMEDNUMBERDMGRSSNDLOCATIONS Researcher5333445555Houston Researcher5333445555Stanford 11

12 1NF Example (1) Chapter 10-12  The domain of DLOCATIONS contains set of values and hence is none-atomic  In this case, DLOCATIONS is functionally dependent on the primary key because each set is considered a single member DNAMEDNUMBERDMGRSSNDLOCATIONS Researcher5333445555{Houston, Stanford} 12

13 1NF Example (1) 13  In either cases, the DEPARTMENT relation is not 1NF  There are three main techniques to achieve first normal form for such relation 1- Remove the attribute DLOCATIONS that violate 1NF and place it in separate relation DEPT_LOCATION along with the primary key DNUMBER DEPARTMERNT DNAMEDNUMBERMGRSSN DNUMBERDLOCATION DEPT_LOCATION  This decompose the non-1NF into 1NF

14 1NF Example (1) 14 2- Expand the key to be DNUMBER and DLOCATION in the same relation  This solution has a disadvantage of introducing redundancy

15 1NF Example (1) 15 3- if a maximum number of values is known for the attribute DLOCATION to be three locations at most for the department then replace the attribute DELOCATIONS into three atomic attributes DLOCATION1, DLOCATION2, and DLOCATION 3 DNAMEDNUMBERMGRSSNDLOCATION1DLOCATION2DLOCATION3

16 1NF Example (1) 16  This solution has a disadvantage  introducing null values if most of the department have fewer than three locations  Querying on this attribute become more difficult,for example, consider how you would write the query “List the departments that have “Bellair” as one of their locations”  Select Dname from Department where Dlocation1=“Bellair” OR Dlocation2=“Bellair” OR Dlocation3=“Bellair”

17 1NF Example (1) 17  The first solution is generally considered the best one because  it does not suffer from redundancy  completely general, and  having no limit placed on a maximum number of values

18 Normalization nested relations into 1NF 18  1NF also disallows multivalued attributes that are themselves composite.  These are called nested relations because each tuple can have a relation within it

19 Normalization nested relations into 1NF 19  The schema of the above relation can be represented as  EMP_PROJ(SSN, ENAME, {PROJS(PNUMBER, HOURS)})  The set braces {} identify the attribute PROJS as multivalued and the compound attributes that form PROJS listed between parentheses()  Notice that, SSN is the primary key of the EMP_PROJ while PNUMBER is the partial key of the nested relation,

20 Normalization nested relations into 1NF 20  To normalize this relation to 1NF, we remove the nested relation attributes into a new relation and propagate the primary key into it

21 Normalization nested relations into 1NF 21  Example  PERSON(SS#, {CAR_LIC}, {PHONE#})  This relation represents the fact that a person has multiple cars and multiple phones  The right way to deal with this relations is to decompose it into separate relations  P_Cars(SS#, CAR_LIC)  P_Phone(SS#, PHONE#)

22 Second Normal Form 2NF Chapter 10-22  2NF Uses the concepts of FDs, primary key  Full functional dependency  a FD Y → Z where removal of any attribute from Y means the FD does not hold any more  Examples:  {SSN, PNUMBER} → HOURS is a full FD since neither SSN → HOURS nor PNUMBER → HOURS hold  {SSN, PNUMBER} → ENAME is not a full FD (it is called a partial dependency ) since SSN → ENAME also holds 22

23 Chapter 10-23  A relation schema R is in second normal form (2NF) if every non-prime attribute A in R is fully functionally dependent on the primary key  R can be decomposed into 2NF relations via the process of 2NF normalization Second Normal Form 2NF 23

24 24  The test for 2NF involves testing for FDs whose left- hand side attributes are part of the primary key.  If the primary key contains a single attribute, the test need not be applied at all Second Normal Form 2NF 24

25 Normalizing into 2NF Chapter 10-25 25  Consider the following relation  The non-prime attribute ENAME in FD2 SSN → ENAME violate 2NF  The non-prime attribute PNAME and PLOCATION in FD3 PNUMBER → PNAME and PNUMBER → PLOCATION violate 2NF 25

26 Chapter 10-26  Transitive functional dependency  a FD X → Z that can be derived from two FDs X → Y and Y → Z  Examples  SSN → DMGRSSN is a transitive FD Since SSN → DNUMBER and DNUMBER → DMGRSSN hold  SSN → ENAME is non-transitive since there is no set of attributes X where SSN → X and X → ENAME Third Normal Form 3NF 26

27 Chapter 10-27  A relation schema R is in third normal form (3NF) if  It is in 2NF and  No non-prime attribute A in R is transitively dependent on the primary key  R can be decomposed into 3NF relations via the process of 3NF normalization Third Normal Form 3NF 2727

28 28 Third Normal Form 3NF  The relation EMP_DEPT is in 2NF since there is no partial dependencies on a key exist  It is not in 3NF because non-prime attribute DNAME and DMGRSSN is transitively based on the primary key SSN 28

29 General Definition of 2NF (For Multiple Keys) Chapter 10-29  The above definitions consider the primary key only  The following more general definitions take into account relations with multiple candidate keys  A relation schema R is in second normal form (2NF) if every non-prime attribute A in R is fully functionally dependent on every key of R  The test for 2NF involves testing for FDs whose left-hand side attributes are part of the primary key.  If the primary key contains a single attribute, the test need not be applied at all 29

30 2NF Example 30  Consider the relation schema LOTS which describes parcels of land for sale in various country  Suppose that there is two candidate keys PROPERTY_ID#, {COUNTY_NAME, LOT#}, we choose PROPERTY_ID# as a primary key, so FD1, FD2 are hold 30

31 2NF Example 31  The FD3 violate 2NF because TAX_RATE is partially dependent on the candidate key {COUNTY_NAME, LOT# }  The FD4 doe not violate the 2NF  Suppose that the following two additional FDs hold in LOTS FD3: COUNTY_NAME → TAX_RATE FD4: AREA → PRICE 31

32 2NF Example 32  To Normalize LOTS into 2NF, we decompose it into two relations LOTS1, LOTS2  by removing the attribute TAX_RATE that violates 2NF and placing it into another relation LOTS2 32

33 General Definition of 3NF (For Multiple Keys) Chapter 10-33  Superkey of relation schema R  a set of attributes S of R that contains a key of R  A relation schema R is in third normal form (3NF) if whenever a FD X → A holds in R, then either: (a) X is a superkey of R, or (b) A is a prime attribute of R 33

34 3NF Example 34  According to this definition, LOTS2 is in 3NF  However, FD4 in LOTS1 violates 3NF because AREA is not a superkey and PRICE is not a prime attribute in LOTS1 34

35 3NF Example 35  To normalize LOTS1 into 3NF, we decompose it into the relation schemas LOTS1A and LOTS1B  We construct LOTS1A by removing the attribute price that violate 3NF 35

36 General Definitions of Second and Third Normal Forms

37 BCNF Example 37  Suppose that we have thousands of lots in the relation but the lots are from only two countries: Quebec, Toronto  Suppose also that the size in Quebec are only 0.5, 0.6, 0.7, 0.8, 0.9, and 1.0 acres  Whereas the lot sizes in Toronto are restricted to 1.1, 1.2, ….., 1.9, and 2.0 acres

38 BCNF Example 38  The LOTS1A still in 3NF because COUNTY_NAME is a prime attribute but it is not in BCNF because AREA is not a superkey In such a situation we would have the additional FD FD5: Area → County_NAME

39 BCNF Example 39  To normalize it into BCNF we decompose LOTS1A into two relations LOTS1AX, LOTS1AY

40 Example 40

41 Example 41  Un-Normalized Form R(ID, Name, Type, Age, Owner, {Visit(VDate, PNO, PNAME)})

42 Example 42 R1(ID,Name, Type Age, Owner) R2(ID, Visit Date, PNO, PName) R2A(ID, VisitDate, PNO ) R2B(PNO, PName ) R2A(ID, VisitDate, PNO ) R2B(PNO, PName )


Download ppt "Functional Dependencies and Normalization for Relational Databases تنبيه : شرائح العرض (Slides) هي وسيلة لتوضيح الدرس واداة من الادوات في ذلك. حيث المرجع."

Similar presentations


Ads by Google