database design-functional dependencies and normalization

8/7/2019 database design-functional dependencies and normalization

http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 1/45

11

UNITUNIT--VIVI

ChapterChapter--1010

Database Design:FunctionalDatabase Design:Functional

Dependencies and NormalizationDependencies and Normalizationfor Relational Databasefor Relational Database



22

10.1 Informal Design Guidelines for10.1 Informal Design Guidelines for

Relational SchemasRelational SchemasInformal measures of quality of relationalInformal measures of quality of relational

schemas:schemas:

Semantics of the attributesSemantics of the attributes Reducing the redundant information inReducing the redundant information in

tuplestuples

Reducing the NULL values in tuplesReducing the NULL values in tuples Disallowing the possibility of generationDisallowing the possibility of generation

spurious tuplesspurious tuples



3

1.Imparting clear semantics to1.Imparting clear semantics to

Attributes in RelationsAttributes in Relations Semantics refer to the interpretation of attributeSemantics refer to the interpretation of attribute

value in a tuplevalue in a tuple Meaning of Employee table : each tupleMeaning of Employee table : each tuple

represents ename, SSN, birthdate, address, Dno.represents ename, SSN, birthdate, address, Dno. Department table and project are alsoDepartment table and project are also

straightforwardstraightforward Semantic of dept_locations and works_on areSemantic of dept_locations and works_on are

complexcomplex Dept_locations has multivalued attribute andDept_locations has multivalued attribute and

works_on has N:M ralationship b/w emp andworks_on has N:M ralationship b/w emp andproject project



44

EnameEname SSNSSN BdateBdate AddressAddress DnoDno

DnameDname DnumberDnumber Dmgr_SSNDmgr_SSN

DnumberDnumber DlocationDlocation

PnamePname PnumberPnumber PlocationPlocation DnumDnum

SSNSSN PnumberPnumber HoursHours

EmployeeEmployee

Department Department

Dept_LocDept_Loc

Project Project

Works_onWorks_on



55

Guideline1Guideline1

Design a relational schema so that it is easy toDesign a relational schema so that it is easy toexplain its meaningexplain its meaning

Do not combine attributes from multiple entitiesDo not combine attributes from multiple entitiesand relationship types into single relationand relationship types into single relation

In Emp_dept mixes attributes of employee andIn Emp_dept mixes attributes of employee anddepartmentsdepartments

Emp_proj mixes attributes of employees andEmp_proj mixes attributes of employees and

projectsprojects Although there is nothing wrong but these areAlthough there is nothing wrong but these are

considered poor designsconsidered poor designs



66

EnameEname SSNSSN BdateBdate AddAdd DnumDnum DnameDname DmgrDmgr_SSN_SSN

SSNSSN PnumPnum HoursHours EnameEname PnamePname PlocationPlocation

Emp_projEmp_proj

Emp_dept Emp_dept



77

2. Redundant Information in tuples2. Redundant Information in tuples

and update anomaliesand update anomalies Minimize the redundancy so that storage spaceMinimize the redundancy so that storage space

is not wastedis not wasted

In emp_dept, the attribute values pertaining to aIn emp_dept, the attribute values pertaining to aparticular department are repeated for everyparticular department are repeated for everyemployee who works for that department employee who works for that department

In contrast each department info appears onlyIn contrast each department info appears only

once in department relationonce in department relation It may lead to insert, delete and updateIt may lead to insert, delete and update

anomaliesanomalies



99

Modification anomaly:Modification anomaly:

If we change the attribute of a particularIf we change the attribute of a particulardepartment then we have to makedepartment then we have to makechanges of all employees who work in that changes of all employees who work in that department department

If we fail to update then it will causeIf we fail to update then it will causeinconsistencyinconsistency

Guideline 2Guideline 2

Design the base relation schemas so that Design the base relation schemas so that no insertion, deletion and modificationno insertion, deletion and modificationanomalies are present anomalies are present



1010

. NULL values in tuple3. NULL values in tuple

Waste of storage spaceWaste of storage space

How to account them for aggregateHow to account them for aggregatefunctionsfunctions

Means unpredictable, unknown, absent Means unpredictable, unknown, absent



1111


Avoid placing NULL values in a baseAvoid placing NULL values in a baserelationrelation

If NULLs are unavoidable then make sureIf NULLs are unavoidable then make sure

that they are applied in exceptional casesthat they are applied in exceptional casesonly and donot apply it on majority of only and donot apply it on majority of tuplestuples



1212

4. Generation of spurious tuples4. Generation of spurious tuples

In relation emp_proj1 and emp_locs areIn relation emp_proj1 and emp_locs arethe base relations instead of emp_projthe base relations instead of emp_proj

We cannot recover info that was originallyWe cannot recover info that was originallyin emp_proj from emp_proj1 andin emp_proj from emp_proj1 andemp_locsemp_locs

Because in this case Ploc is an attributeBecause in this case Ploc is an attribute

that is neither a primary key nor a foreignthat is neither a primary key nor a foreignkeykey



1313

SSNSSN PnumPnum HoursHours EnameEname PnamePname PlocPloc

EnameEname PlocPloc

SSNSSN PnumPnum HoursHours PnamePname PlocPloc

Emp_proEmp_pro

Emp_pro1Emp_pro1

Emp_locsEmp_locs



1414


Design relations so that they can be joinedDesign relations so that they can be joinedon primary keys and foreign keys in a wayon primary keys and foreign keys in a waythat guarantees for no spurious tuplesthat guarantees for no spurious tuples

Avoid relations that contain matchingAvoid relations that contain matchingattributes that are not primary keys andattributes that are not primary keys andforeign keys because joining of these leadforeign keys because joining of these leadto spurious attributesto spurious attributes



1515

Functional DependenciesFunctional Dependencies Functional Dependency denoted by X Functional Dependency denoted by X Y Y

between two sets of attributes X and Y that arebetween two sets of attributes X and Y that aresubsets of R specifies a constraint on thesubsets of R specifies a constraint on the

possible tuples that can form a relation r from Rpossible tuples that can form a relation r from R The constraint is that for any two tuples t1 andThe constraint is that for any two tuples t1 and

t 2 in r that have t1[X]=t 2[X] then t1[y]=t 2[y].t 2 in r that have t1[X]=t 2[X] then t1[y]=t 2[y].

Values of the X component determine the valuesValues of the X component determine the valuesof Y component or Y is functionally dependent of Y component or Y is functionally dependent on X on X



1616

Consider relationConsider relation

emp_proj1(ssn,ename,pnum, pname,emp_proj1(ssn,ename,pnum, pname,ploc, hours)ploc, hours)

From the semantics of attributesFrom the semantics of attributes

SSNSSN EnameEname PnumPnum{Pname,Ploc}{Pname,Ploc}

{SSN,Pnum}{SSN,Pnum} HoursHours



1717

In some cases FD cannot be inferred fromIn some cases FD cannot be inferred froma given relationa given relation

FD must be defined explicitly by someoneFD must be defined explicitly by someonewho knows the sementics of the attributeswho knows the sementics of the attributesof relationof relation

Eg: CourseEg: Course teacherteacher

This cannot be true for all the legal statesThis cannot be true for all the legal states

If teacher teaches two subjects then weIf teacher teaches two subjects then wecannot conclude that teacher is FD oncannot conclude that teacher is FD oncoursecourse



1818

Inference rules for FDInference rules for FD

The set of all the dependencies that include F asThe set of all the dependencies that include F aswell as all the dependencies that can be inferredwell as all the dependencies that can be inferredfrom f is calledfrom f is called closureclosure of F denoted by F+of F denoted by F+

Eg Dept noEg Dept no mgrssnmgrssn

And mgrssnAnd mgrssn mgrphone thenmgrphone then

deptnodeptno mgrphonemgrphone

To determine a systematic way to inferTo determine a systematic way to infer

dependencies from a given set of dependenciesdependencies from a given set of dependenciesthere arethere are inference rulesinference rules

IRIR11 (Reflexive rule): If X (Reflexive rule): If X Y then X Y then X Y Y

IRIR22 (Augmentation rule): X (Augmentation rule): X Y thenXZY thenXZ Y ZY Z



1919

IR2 holds only if t1(X)=t 2 (X), t1(Y )=t 2(Y ),IR2 holds only if t1(X)=t 2 (X), t1(Y )=t 2(Y ),t1(XZ)=t 2(XZ), t1(Y Z)=t 2(Y Z)t1(XZ)=t 2(XZ), t1(Y Z)=t 2(Y Z)

IR3 (transition rule): X IR3 (transition rule): X Y ,Y Y ,Y Z then X Z then X ZZ

IR4 (decomposition or projection rule): X IR4 (decomposition or projection rule): X Y ZY Znot equal to X not equal to X ZZ

IR5 (union or additive rule): X IR5 (union or additive rule): X Y ,X Y ,X Z thenZ thenthis is not equal to X this is not equal to X Y ZY Z

IR6 (pseudotransitive rule):X IR6 (pseudotransitive rule):X Y ,WY Y ,WY Z theZ theWX WX ZZ

IR1 generates dependencies that are always true,IR1 generates dependencies that are always true,such dependencies are known assuch dependencies are known as trivialtrivial othersothersasas nontrivialnontrivial



2020

Proof of rules:Proof of rules:

IRIR44: X : X Y Z then Y ZY Z then Y Z Y (IRY (IR11, Y Z, Y Z Y Y ))

IRIR55: X : X Y and X Y and X Z then X Z then X X Y (IRX Y (IR22))

X Y X Y Y Z(IRY Z(IR22) and X ) and X Y Z(IRY Z(IR33))

IRIR66: X : X Y , WY Y , WY Z then WX Z then WX WY (IRWY (IR22) and) and

WX WX Z(IRZ(IR33))

A set of functional dependencies F is said toA set of functional dependencies F is said tocovercover functional dependencies E if everyfunctional dependencies E if everydependency in E can be inferred from Fdependency in E can be inferred from F

Two sets E and F areTwo sets E and F are equivalentequivalent if E+=F+if E+=F+



2121

NormalizationNormalization process first proposed byprocess first proposed byCodd (1972) takes a relation through aCodd (1972) takes a relation through a

series of tests to certify that whether it series of tests to certify that whether it satisfies a certain normal form or not satisfies a certain normal form or not

This process starts from top down fashionThis process starts from top down fashion

Codd proposed 3 normal forms, all theseCodd proposed 3 normal forms, all thesenormal forms are based on singlenormal forms are based on singleanalytical tool :functional dependenciesanalytical tool :functional dependencies

Normal forms based on primaryNormal forms based on primary

keyskeys



2222

Later, 4 normal form and 5 normal form wasLater, 4 normal form and 5 normal form wasproposed based on multivalued and joinproposed based on multivalued and joindependenciesdependencies

This approach is called relational design byThis approach is called relational design bysynthesissynthesis

NormalizationNormalization is a process of analyzing theis a process of analyzing the

given relation schemas based on FD and primarygiven relation schemas based on FD and primarykeys to achieve these:keys to achieve these:

1) minimizing redundancy1) minimizing redundancy

2) minimizing insertion, deletion and update2) minimizing insertion, deletion and update

anomaliesanomaliesThe process of storing to join of higher normalThe process of storing to join of higher normalform relations as a base relation which is of form relations as a base relation which is of lower form is known as denormalizationlower form is known as denormalization



2323

Process of normalization through decompositionProcess of normalization through decompositionshould also confer two additional properties:should also confer two additional properties:

1) lossless join or nonadditive join property:1) lossless join or nonadditive join property:guarantees that there are no spurious tuplesguarantees that there are no spurious tuples

2) dependency preservation property: ensures2) dependency preservation property: ensures

that each FD is represented in some individualthat each FD is represented in some individualrelation after decompositionrelation after decomposition

Super Key: A superkey in a given relationSuper Key: A superkey in a given relationR={A1,A2,An} is a set of attributes S isR={A1,A2,An} is a set of attributes S is

superset of R with the property that no twosuperset of R with the property that no twotupes t1 and t 2 in any relation will havetupes t1 and t 2 in any relation will havet1[S]=t 2[S]t1[S]=t 2[S]



2424

Key is a superkey wih additional property that Key is a superkey wih additional property that removal of any attributes from K will cause K not removal of any attributes from K will cause K not

to be a super keyto be a super key If a relation has more than one keys than eachIf a relation has more than one keys than each

is called a candidate keyis called a candidate key

One of the candidate key will be a primary keyOne of the candidate key will be a primary keyothers will be secondary keysothers will be secondary keys

An attribute of a relation is called prime if it is aAn attribute of a relation is called prime if it is amember of some candidate keys and others aremember of some candidate keys and others are

called non prime attributescalled non prime attributes Unique key is attribute that uniquely identifiesUnique key is attribute that uniquely identifies

each row in a table and allow Null values in it.each row in a table and allow Null values in it.



2525

Primary key is attribute or combination of Primary key is attribute or combination of attributes that uniquely identifies a row in aattributes that uniquely identifies a row in a

table and should be not Null.table and should be not Null. Foreign key is attribute or combination of Foreign key is attribute or combination of

attributes whose value match a primary key inattributes whose value match a primary key inanother tableanother table

Composite or compound key consist of Composite or compound key consist of 2 2 orormore attributesmore attributes

Candidate key is a collection of keys in a tableCandidate key is a collection of keys in a tablewhich has ability to become a primary keywhich has ability to become a primary key

Alternate or secondary key is a candidate keyAlternate or secondary key is a candidate keythat is not a part of primary keythat is not a part of primary key



2626

First Normal Form1NFFirst Normal Form1NF

It states that domain of an attribute must It states that domain of an attribute must include only atomic values and that the value of include only atomic values and that the value of any attribute in an tuple must be a single valueany attribute in an tuple must be a single valuefrom the domain of that attributefrom the domain of that attribute

1NF disallows having set of values, a tuple of 1NF disallows having set of values, a tuple of values or the combination of valuesvalues or the combination of values

Consider department relation , its not in 1NFConsider department relation , its not in 1NFbcause Dloc is not atomicbcause Dloc is not atomic

DnumDnum Dloc because Dnum is primary key soDloc because Dnum is primary key sothere are three main techniques to make it inthere are three main techniques to make it in1NF:1NF:



2727

1)1) Remove Dloc and make it in a separate relationRemove Dloc and make it in a separate relationDept_locations which will have primary key DnumDept_locations which will have primary key Dnumand Dloc, this will form two 1NF relationsand Dloc, this will form two 1NF relations

2)2) Expand the key so that there is a separate tuple inExpand the key so that there is a separate tuple indept where primary key is combination of dept where primary key is combination of {Dnum,Dloc}{Dnum,Dloc}

3)3) Max number of values in Dloc as three and place NullMax number of values in Dloc as three and place Null

for other tuples but it will generate spurious tuplesfor other tuples but it will generate spurious tuples

DnameDname DnumDnum DmgrssnDmgrssn DlocDloc

ResearchResearch 55 33344453334445 {Bellaire, Sugarland,Houstan}{Bellaire, Sugarland,Houstan}

AdminisAdminis 44 98765439876543 {Stafford}{Stafford}

HeadQuaterHeadQuater 11 88866778886677 {Houston}{Houston}



2828

DnameDname DnumDnum DmgrssnDmgrssn

ResearchResearch 55 33344453334445

AdminisAdminis 44 98765439876543

HeadquaterHeadquater 11 88866778886677

DnameDname DnumDnum DmgrssnDmgrssn DlocDloc

ResearchResearch 55 33344453334445 BellaireBellaire

ResearchResearch 55 33344453334445 SugarlandSugarland

ResearchResearch 55 33344453334445 HoustanHoustan

AdminisAdminis 44 98765439876543 StaffordStafford

HeadquaterHeadquater 11 88866778886677 HoustonHouston

DnumDnum DlocDloc

55 BellaireBellaire

55 SugarlanSugarlandd

55 HoustanHoustan

44StaffordStafford

11 HoustonHouston



2929

SSNSSN EnameEname PnumberPnumber HoursHours

12341234 Smith,JohnSmith,John 1,21,2 32,4332,43

56785678 Narayan,Narayan,

JoyceJoyce

33 4040

91239123 Ramseh,Ramseh,

RakeshRakesh

4,54,5 20,1020,10

45674567 Wong,Wong,FranklinFranklin

6,76,7 35,1035,10



3131

These are the given FDs:These are the given FDs:

{SSN,Pnumber}{SSN,Pnumber} HoursHours {SSN,Pnumber}{SSN,Pnumber} EnameEname

{SSN,Pnumber}{SSN,Pnumber} {Pname,Plocations}{Pname,Plocations}

This should hold but Ename,This should hold but Ename,Pname,Plocations are partially dependent Pname,Plocations are partially dependent because SSNbecause SSN EnameEname

and Pnumberand Pnumber {Pname,Plocations}{Pname,Plocations}



3232

SSNSSN PnumberPnumber HoursHours EnameEname PnamePname PlocationsPlocations

SSNSSN PnumberPnumber HoursHours

SSNSSN EnameEname

PnumberPnumber PnamePname PlocationsPlocations

Emp_ProjEmp_Proj

EPEP11

EP2EP2

EP3EP3



3434

So because of this transitive dependencySo because of this transitive dependency

between SSN , Dnumber and Dmgrssn thisbetween SSN , Dnumber and Dmgrssn thisrelation is not in 3NFrelation is not in 3NF

So we have to decompose relation into twoSo we have to decompose relation into twotables independent of transitive dependencytables independent of transitive dependency

such that natural join operation will result insuch that natural join operation will result inoriginal base table emp_dept relationoriginal base table emp_dept relation

It is not important to remove partialIt is not important to remove partialdependencies before transitive dependency but dependencies before transitive dependency but

normal forms are made such that in 2NF partialnormal forms are made such that in 2NF partialdependencies are removed and in 3NF transitivedependencies are removed and in 3NF transitivedependencies are removeddependencies are removed



3535

EnameEname SSNSSN BdateBdate AddressAddress DnumDnum DnameDname DmgrssnDmgrssn

EnameEname SSNSSN BdateBdate AddressAddress DnumDnum

DnumDnum DnameDname DmgrssnDmgrssn

Emp_Dept Emp_Dept

ED2ED2

ED1ED1



3636

Def 2 of 2NF: A relation schema R is in 2NF if itsDef 2 of 2NF: A relation schema R is in 2NF if itsin 1NF and every non prime attribute A in R isin 1NF and every non prime attribute A in R is

not partially dependent on any key in Rnot partially dependent on any key in R Def 2 of 3NF:A relation R is in 3NF if its in 2NFDef 2 of 3NF:A relation R is in 3NF if its in 2NF

and whenever nontrivial functional dependencyand whenever nontrivial functional dependencyX X A holds in R either X is a superkey or A is aA holds in R either X is a superkey or A is a

prime attribute of Rprime attribute of R Def 3 of 3NF: A relation R is in 3NF if everyDef 3 of 3NF: A relation R is in 3NF if every

nonprime attribute meets both conditions:nonprime attribute meets both conditions:

It is fully functionally dependent on every key of It is fully functionally dependent on every key of RR

It is non transitively dependent on every key of It is non transitively dependent on every key of RR



4040

Prop_idProp_id Country_Country_

namename

LotnoLotno AreaArea PricePrice

Prop_idProp_id Country_Country_namename LotnoLotno AreaArea

lots1lots1

AreaArea PricePrice

lots1Blots1B

lots1Alots1A

Example:3 NFExample:3 NF



4141

FD4 violates 3NF becaues Area is not a key andFD4 violates 3NF becaues Area is not a key and

price is not a prime attributeprice is not a prime attribute To make it 3NF we decompose reation lots1 intoTo make it 3NF we decompose reation lots1 into

lots1A and lots1B by removing transitivelots1A and lots1B by removing transitivedependencydependency

Price is transitively dependent on each of Price is transitively dependent on each of candidate keys via Areacandidate keys via Area

This lots1A is in 3NF but not BCNF because of This lots1A is in 3NF but not BCNF because of FD5 because Area is not a superkey andFD5 because Area is not a superkey and

Countryname is a prime attribute so weCountryname is a prime attribute so wedecompose relation lots1A into lots1Ax anddecompose relation lots1A into lots1Ax andlots1Aylots1Ay



4343

TeachTeach

Student Student CourseCourse InstructorInstructor

Student Student InstructorInstructor

InstructorInstructor CourseCourse

Teach2Teach2

TeachTeach11



4444

Prop_idProp_id Country_naCountry_na

meme

LotnoLotno AreaArea

Prop_iProp_idd

AreaArea lotnolotno

lots1Alots1A

AreaArea CountrynaCountrynameme

lots1Axlots1Ax

lots1Aylots1Ay

Example:BCNFExample:BCNF



4545

Benefits or Advantages of normalization:Benefits or Advantages of normalization:

Greater overall database organizationGreater overall database organization Reduction of redundant valuesReduction of redundant values

Data consistency within databaseData consistency within database

A much more flexible designA much more flexible design A better handle of database securityA better handle of database security

database design-functional dependencies and normalization

Documents