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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 2/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 3/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 4/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 5/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 6/45
66
EnameEname SSNSSN BdateBdate AddAdd DnumDnum DnameDname DmgrDmgr_SSN_SSN
SSNSSN PnumPnum HoursHours EnameEname PnamePname PlocationPlocation
Emp_projEmp_proj
Emp_dept Emp_dept
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 7/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 8/45
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 9/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 10/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 11/45
1111
Guideline 3Guideline 3
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 12/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 13/45
1313
SSNSSN PnumPnum HoursHours EnameEname PnamePname PlocPloc
EnameEname PlocPloc
SSNSSN PnumPnum HoursHours PnamePname PlocPloc
Emp_proEmp_pro
Emp_pro1Emp_pro1
Emp_locsEmp_locs
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 14/45
1414
Guideline 4Guideline 4
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 15/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 16/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 17/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 18/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 19/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 20/45
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+
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 21/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 22/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 23/45
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]
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 24/45
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.
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 25/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 26/45
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:
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 27/45
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}
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 28/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 29/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 30/45
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 31/45
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}
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 32/45
3232
SSNSSN PnumberPnumber HoursHours EnameEname PnamePname PlocationsPlocations
SSNSSN PnumberPnumber HoursHours
SSNSSN EnameEname
PnumberPnumber PnamePname PlocationsPlocations
Emp_ProjEmp_Proj
EPEP11
EP2EP2
EP3EP3
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 33/45
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 34/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 35/45
3535
EnameEname SSNSSN BdateBdate AddressAddress DnumDnum DnameDname DmgrssnDmgrssn
EnameEname SSNSSN BdateBdate AddressAddress DnumDnum
DnumDnum DnameDname DmgrssnDmgrssn
Emp_Dept Emp_Dept
ED2ED2
ED1ED1
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 36/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 37/45
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 38/45
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 39/45
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 40/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 41/45
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
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 42/45
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 43/45
4343
TeachTeach
Student Student CourseCourse InstructorInstructor
Student Student InstructorInstructor
InstructorInstructor CourseCourse
Teach2Teach2
TeachTeach11
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 44/45
4444
Prop_idProp_id Country_naCountry_na
meme
LotnoLotno AreaArea
Prop_iProp_idd
AreaArea lotnolotno
lots1Alots1A
AreaArea CountrynaCountrynameme
lots1Axlots1Ax
lots1Aylots1Ay
Example:BCNFExample:BCNF
8/7/2019 database design-functional dependencies and normalization
http://slidepdf.com/reader/full/database-design-functional-dependencies-and-normalization 45/45
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