DatabaseManagementSystem MODULE3

MODULE 3
Introduction to Normalization using Functional and Multivalued
Dependencies
Each relation schema consists of a number of attributes, and the relational database schema consists of a
number of relation schemas. There are two levels at which we can discuss the "goodness" of relation schemas:
a) Logical(orconceptual)level:
➢ Itdiscusseshowusersinterprettherelationschemasandthemeaningoftheirattributes.
➢ Havinggoodrelationschemasatthis levelenables userstounderstandclearlythe meaningofthedata in the
relations, and hence to formulate their queries correctly.
➢ Atthislevelweareinterestedinschemasofbothbaserelationsandviews(virtualrelations).

b) Implementation(orstorage)level:
➢ Itdiscusseshowthetuplesinabaserelationarestoredandupdated.
➢ This levelappliesonlytoschemasofbaserelations-whichwillbephysicallystoredasfiles.

Databasedesignmaybeperformedusingtwoapproaches:
➢ Bottom-updesignmethodology (alsocalleddesignbysynthesis):
➢ Thisapproachconsidersthebasicrelationshipsamongindividualattributesasthestartingpoint and uses
those to construct relation schemas.
➢ Thisapproachis notverypopular inpractice because it suffers fromtheproblemofhavingtocollect a large
number of binary relationships among attributes as the starting point.

➢ Top-downdesignmethodology(alsocalleddesignbyanalysis):
➢ Thisapproachstartswithanumberofgroupingsofattributesintorelationsthatexisttogether naturally.
➢ Therelationsarethenanalyzed individuallyandcollectively, leadingtofurtherdecompositionuntil all
desirable properties are met.

4.1INFORMALDESIGNGUIDELINESFORRELATIONSCHEMAS:
Therearefour informalmeasuresofqualityforrelationschemadesign:
i) Semanticsoftheattributes
ii) Reducingtheredundantvalues intuples
iii) Reducingthenullvaluesintuples
iv) Disallowingthepossibilityofgeneratingspurioustuples

SemanticsoftheRelationAttributes:

DeptofCSE,CBIT-Kolar Page1
DatabaseManagementSystem MODULE3
➢ Wheneverwegroupattributesto formarelationschema,weassumethat attributesbelongingtoone
relation have certain real-world meaning and a proper interpretation associated with them.
➢ This meaning,orsemantics, specifieshowtointerprettheattributevaluesstoredinatupleofthe
relation-in other words, how the attribute values in a tuple relate to one another.
➢ Toillustratethis,considerFigure4.1,asimplifiedversionoftheCOMPANYrelationaldatabase schema and
Figure 4.2, which presents an example of populated relation states of this schema.
➢ The meaning of the EMPLOYEE relation schema is quite simple: Each tuple represents an employee,
with values for the employee's name (ENAMEl. social security number (SSN), birth date (BDATE),
and address (ADDRESS), and the number of the department that the employee works for (DNUMBER).
The DNUMBER attribute is a foreign key that represents an implicit relationship between EMPLOYEE
and DEPARTMENT.
➢ The semantics of the DEPARTMENT and PROJECT schemas are also straightforward: Each
DEPARTMENT tuple represents a department entity, and each PROJECT tuple represents a project
entity. The attribute DMGRSSN of DEPARTMENT relates a department to the employee who is its
manager, while DNUM of PROJECT relates a project to its controlling department; both are foreign
key attributes. The ease with which the meaning of a relation's attributes can be explained is an informal
measure of how well the relation is designed.
➢ Eachtuple inDEPT_LOCATIONS gives a department number (DNUMBER) and one ofthe locations of
the department (DLOCATION). Each tuple in WORKS_ON gives an employee social security number
(SSN), the project number of one of the projects that the employee works on (PNUMBER), and the
number of hours per week that the employee works on that project (HOURS).

FIGURE4.1:AsimplifiedCOMPANYrelationaldatabaseschema.

DeptofCSE,CBIT-Kolar Page2
DatabaseManagementSystem MODULE3

Fig:ExampledatabasestatefortherelationaldatabaseschemaofFigure6.1.

Wecan thusformulatethefollowing informaldesign guideline:

GUIDELINE 1: Design a relation schema so that it is easy to explain its meaning. Do notcombine attributes
from multiple entitytypes and relationship types into a single relation.

Examples of violating Guideline 1:The relation schemas in Figures 4.3a and 4.3b also have clear semantics.
A tuple in the EMP_DEPT relation schema of Figure 4.3a represents a single employee but includes additional
information-namely, the name (DNAME) of the department for which the employee works and the social
security number (DMGRSSN) of the department manager. For the EMP_PROJ

DeptofCSE,CBIT-Kolar Page3
DatabaseManagementSystem MODULE3
relationofFigure4.3b,eachtuplerelatesanemployeetoaproject but also includestheemployeename (ENAME),
project name (PNAME), and project location (PLOCATION).

FIGURE4.3Tworelationschemassufferingfromupdateanomalies.

RedundantInformation inTuplesandUpdateAnomalies:
➢ One goal of schema design is to minimize the storage space used by the base relations (and hence the
corresponding files).
➢ Grouping attributes into relation schemas has a significant effect on storage space. For example, compare
the space used by the two base relationsEMPLOYEE and DEPARTMENT in Figure 4.2 withthat
foranEMP_DEPT base relation in Figure 4.4,which isthe result ofapplying the NATURAL JOIN
operation to EMPLOYEE and DEPARTMENT.
InEMP_DEPT,theattributevaluespertainingtoaparticulardepartment (DNUMBER,DNAME,and
DMGRSSN) are repeated for every employee who works for that department.

FIGURE6.4Example statesforEMP_DEPTandEMP_PROJresultingfromapplyingNATURALJOINtotherelations in
Figure 4.2.

DeptofCSE,CBIT-Kolar Page4
DatabaseManagementSystem[21CS53] MODULE4
➢ Thevariousupdate anomaliesinnonnormalizeddatabase(DB)canbeclassifiedinto
a) Insertionanomalies
b) Deletionanomalies
c) Modificationanomalies.
a) InsertionAnomalies:Insertionanomaliescanbedifferentiated intotwotypes, illustrated bythe
following examples based on the EMP_DEPT relation.
1sttypeof Insertion Anomaly:

➢ To insert a new employee tuple into EMP_DEPT, we must include either all the attribute values for
the department that the employee works for, or nulls (if the employee does not work for a department
as yet).
➢ For example, to insert a new tuple for an employee who works in department number 5, we must enter
the attribute values of department 5 correctly so that they are consistent with values for department 5
in other tuples in EMP_DEPT.
➢ In the design of Figure 4.2, we do not have to worry about thisconsistency problem because we enter
only the department number in the employee tuple; all other attribute values of department 5 are
recordedonly once in the database, as a single tuple in the DEPARTMENT relation.

2ndtypeof InsertionAnomaly:
➢ It is difficult to insert a new department that has no employees as yet in the EMP_DEPT relation. The
onlywayto do this is to place null values in the attributes for employee.
➢ Thiscausesa problembecause SSN isthe primary keyofEMP_DEPT,and eachtuple issupposedto
represent an employee entity-not a department entity.
➢ This problem does not occur in the design of Figure 4.2, because a department is entered in the
DEPARTMENT relation whether or not any employees work for it, and whenever an employee is
assigned to that department, a corresponding tuple is inserted in EMPLOYEE.

b) Deletion Anomalies:Theproblemofdeletionanomalies isrelatedtothesecond insertionanomaly

situation discussed earlier.
➢ If we delete from EMP_DEPT an employee tuple that happens to represent the lastemployee working
for a particular department, the information concerning that department is lost from the database.
➢ This problem does not occur in the database ofFigure 4.2 because DEPARTMENT tuples are stored
separately.

c) Modification Anomalies:
➢ In EMP_DEPT, if we change the value of one of the attributes of a particular department-say, the
manager of department 5-we must update the tuples of all employees who work in that department;
otherwise, the database will become inconsistent.
➢ Ifwe failto update some tuples, the same department will be shown to have two different values for
manager in different employee tuples, which would be wrong.

DeptofCSE,CBIT-Kolar Page5
DatabaseManagementSystem[21CS53] MODULE4

Basedonthe precedingthreeanomalies,wecanstatetheguidelinethatfollows:
GUIDELINE 2: Design the base relation schemas so that no insertion, deletion, or modification
anomalies are present in the relations. If any anomalies are present, note them clearly and make sure
that the programs that update the database will operate correctly.

NullValues inTuples:

➢ Ifmanyoftheattributes donotapplytoalltuples intherelation, weendupwithmanynulls inthose tuples.

➢ Thiscanwastespaceatthestorageleveland mayalso leadtoproblemswithunderstandingthe
meaning of the attributes and with specifying JOIN operations at the logical level.
➢ Anotherproblemwithnulls ishowtoaccountforthemwhenaggregateoperationssuchasCOUNTor SUM
are applied.

➢ Moreover,nullscanhave multipleinterpretations, suchasthefollowing:

a) Theattributedoesnotapplytothistuple.
b) Theattributevalueforthistupleisunknown.
c) Thevalueisknownbutabsent;thatis,ithasnotbeenrecordedyet.

Wemayhave anotherguidelineto dealwithNULLvaluesasfollows:

GUIDELINE 3: As far as possible, avoid placing attributes in a base relation whose values may
frequently be null. If nulls are unavoidable, make sure that they apply inexceptional cases only and do
not apply to a majority of tuples in the relation.

Generation ofSpuriousTuples:
➢ Considerthetworelationschemas EMP_LOCSandEMP_PROJ1 inFigure4.5a,whichare
decomposed from EMP_PROJ relation of Figure 4.3b.
➢ Figure4.5bshowsrelationstatesofEMP_LOCSandEMP_PROJ1correspondingtotheEMP_PROJ
relation of Figure 4.4.

DeptofCSE,CBIT-Kolar Page6
DatabaseManagementSystem[21CS53] MODULE4

FIGURE 4.5Particularly poor design for the EMP_PROJ relationof Figure 4.3b. (a) The two relationschemas
EMP_LOCS and EMP_PROJ1. (b) The result of projecting the extension of EMP_PROJ from Figure 4.4 onto
the relations EMP_LOCS and EMP_PROJI.

➢ If we attempt a NATURAL JOIN operation on EMP_PROJ1 and EMP_LOCS, the result producesmany
more tuples than the original set oftuples in EMP_PROJ. In Figure 4.6, the result ofapplying the join to
onlythe tuples above the dotted lines in Figure 4.5b is shown.

FIGURE4.6:ResultofapplyingNATURALJOINtothe tuples abovethe dottedlinesinEMP_PROJ1and EMP_LOCS

of Figure 6.5. Generated spurious tuples are marked by asterisks.

DeptofCSE,CBIT-Kolar Page7
DatabaseManagementSystem[21CS53] MODULE4
➢ Additionaltuples inthe Figure4.6that werenot inEMP_PROJ(Figure4.4)
arecalledspurioustuplesbecause they represent spurious or wrong information that is not valid.
Wecannowinformallystateanotherdesignguidelineasfollows:
GUIDELINE4:Designrelationschemasso thattheycanbe joinedwithequalityconditionsonattributes that
areeither primarykeys or foreignkeys ina waythat guaranteesthat no spurious tuples are generated.

FUNCTIONALDEPENDENCIES:

DefinitionofFunctionalDependency:

Definition: A functional dependency denoted by, Y between two sets of attributes X and Y that are
subsets of R specifies a constraint on the possible tuples that can form a relation state ‗r‘ of ‗R‘. The
constraint is that, for any two tuples ‗t1‘ and ‗t2‘ in ‗r‘ that have t1[X] = t2[X], they must also have t1[Y]
= t2[Y].
➢ This means that the values of the ‗Y‘ component of a tuple in ‗r‘ depend on, or are determined by, the
values of the ‗X‘ component; alternatively, the values of the ‗X‘ component of a tuple uniquely (or
functionally) determine the values of the Y component.
➢ Wealsosaythatthereisa functionaldependencyfromXtoY,orthatYisfunctionallydependentonX.
Ex:State(Byknowingthevehicleiditispossibletodeterminethestatethatvehicle belongs to).
➢ TheabbreviationforfunctionaldependencyisFDorf.d.
➢ Theset ofattributesX iscalledtheleft-hand sideoftheFD,andY iscalledtheright- handside.
➢ Thus,‗X‘functionallydetermines‗Y‘inarelationschema‗R‘if,andonlyif,whenevertwotuplesof
r(R)agreeontheirX-value,theymustnecessarilyagreeontheirY-value.
➢ Considertherelationschema EMP_PROJandEMP_DEPT givenbelow.Fromthesemanticsofthe
attributes, we know that the following functional dependencies should hold:

a. SSN→ENAME
b. PNUMBER→{PNAME,PLOCATION}
c. {SSN,PNUMBER}→HOURS
These functional dependencies specify that (a) the value of an employee's social security number (SSN)
uniquely determines the employee name (ENAME), (b) the value of a project'snumber
(PNUMBER)uniquelydeterminestheprojectname(PNAME)andlocation(PLOCATION),and(c)a

DeptofCSE,CBIT-Kolar Page8
DatabaseManagementSystem[21CS53] MODULE4
combinationofSSNandPNUMBERvaluesuniquelydeterminesthenumberofhourstheemployee currently
works on the project per week (HOURS).

➢ Figure6.3introducesadiagrammaticnotationfordisplayingFDs:
• EachFDisdisplayed asahorizontalline.
• Theleft-hand-sideattributesoftheFDareconnectedbyverticallinestothelinerepresentingtheFD.
• Theright-hand-sideattributesareconnected byarrowspointingtowardtheattributes.

InferenceRulesforFunctionalDependencies:
➢ WedenotebyFthe set offunctionaldependenciesthatarespecifiedonrelationschemaR.
➢ Usually,however,numerousotherfunctionaldependenciesholdthatsatisfythedependenciesinF.
ThoseotherdependenciescanbeinferredordeducedfromtheFDsinF.

➢ Therefore,formallyit isusefulto defineaconceptcalled closurethatincludesallpossible

dependencies that can be inferred from the given set F.

Definition ofclosure : Formally, thesetofalldependenciesthat includeFaswellasalldependenciesthat can be

inferred from F is called the closure of F; it is denoted by F+.

➢ Forexample, supposethatwespecifythe followingset Fofobvious functionaldependenciesonthe

relation schema of EMP_DEPT:

F={SSN→{ENAME,BDATE,ADDRESS,DNUMBER},
DNUMBER → {DNAME, DMGRSSN}}

Someoftheadditionalfunctionaldependenciesthatwecan inferfromFarethefollowing:
SSN→{DNAME,DMGRSSN} SSN
→ SSN
DNUMBER→DNAME

➢ Asetofinference rulescanbeusedtoinfer newdependenciesfromagivensetofdependencies.

➢ WeusethenotationF|=X→YtodenotethatthefunctionaldependencyX →Y isinferredfromthe set of

functional dependencies F.

DeptofCSE,CBIT-Kolar Page9
 DatabaseManagementSystem[21CS53] MODULE4
INFERENCERULESforfunctionaldependencies:
a) IRI(reflexive rule):
➢ Thereflexiverule(IR1)statesthat asetofattributesalwaysdeterminesitself oranyofitssubsets, which is
obvious.
➢ BecauseIRlgeneratesdependenciesthatarealwaystrue,suchdependenciesarecalledtrivial.
➢ Formally, afunctionaldependencyX YistrivialifY isasubsetofX(X⸧Y);otherwise,it is nontrivial.
IfX⸧Y,then Y
Ex:- X={ SSN,FNAME,LNAME} , Y={ FNAME,LNAME}
Therefore{SSN,FNAME,LNAME} {FNAME,LNAME}
b) IR2(augmentationrule):
➢ Theaugmentationrule(IR2)saysthat addingthesameset ofattributesto boththe left- andright- hand
sides of a dependency results in another valid dependency.

{X Y}|=XZ YZ
Ex:-X={SSN},Y={FNAME}
Therefore{SSN,LNAME} {FNAME,LNAME}

➢ IR3(transitiverule):
➢ AccordingtoIR3,functionaldependenciesaretransitive.
{X Y,Y Z}|= X Z
Ex:-X={SSN}, Y={DNUMBER},Z={DNAME}
Therefore{SSN} {DNAME}

➢ IR4(decomposition,orprojective,rule):
➢ Thedecompositionrule(IR4) saysthat wecanremoveattributes fromtheright-handsideofa
dependency;
➢ Applyingthisrulerepeatedlycandecomposethe FDX {A1,A2, .................... ,An}intothesetof
dependencies{X A1,X A2,....,X An}.

{X YZ}|=X Y
Ex:-X={SSN},Y={FNAME},Z={LNAME}
Therefore{SSN} {FNAME}
➢ IR5(union,oradditive,rule):
➢ The union rule (IRS)allows us to do the opposite; we can combine a setof dependencies A1), X
A2, .... , An} into the single FD {A1, A2, ........ ,An}

X Y,X Z}|=X YZ

DeptofCSE,CBIT-Kolar Page10
DatabaseManagementSystem[21CS53] MODULE4
Ex:- X={SSN}, Y={FNAME}, Z={LNAME}
Therefore {SSN} {FNAME,LNAME}
➢ IR6(pseudotransitive rule):
{X Y, Z}|= Z
Ex:-X={SSN},W={DNAME},Y={DNAME},Z={MGRSSN}
Therefore {DNAME, SSN} {MGRSSN}

PROOFOFINFERENCERULES:
➢ Eachofthe inferencerulescanbeproved fromthe definitionoffunctionaldependency, either by directproof
or by contradiction.
➢ Aproofbycontradictionassumesthattheruledoesnot holdandshowsthatthisisnotpossible.

PROOFOFIR1:
SupposethatXYandthattwotuplest1andt2existinsomerelationinstance‗r‘of‗R‘suchthatt1[X]
=t2[X].Thent1[Y]=t2[Y]becauseXY;hence, Ymustholdin‗r‘.

PROOFOFIR2 (BYCONTRADICTION):
Assumethat X Yholdsinarelationinstance‗r‘of‗R‘butthatXZ YZdoesnot hold. Thenthere must exist two
tuples ‗t1‘ and ‗t2‘ in ‗r‘ such that:
1. t1[X]=t2[X]
2. t1[Y]=t2[Y]
3. t1[XZ]=t2[XZ]
4. t1[Y]≠'t2[YZ].

This isnotpossiblebecause from(1)and (3)wededuce(5)t1[Z]=t2[Z],andfrom(2)and(5)wededuce

(6)t1[YZ]=t2[Y],contradicting(4).

PROOFOFIR3:
Assumethat(1)X Yand(2)Y Zbothholdin a relation‗r‘.Thenforanytwotuples‗t1‘and‗t2‘in
‗r‘ such thatt1[X]= t2[X].Wemusthave(3)t1[Y]= t2[Y],from assumption (1); hencewemustalso have (4) t1
[Z] = t2[Z], from(3) and assumption (2); hence X Z must hold in‗r‘.

PROOFOFIR4(USING IRlTHROUGH IR3):

1. X YZ(given).
2. YZY(usingIRIandknowingthatYZY).
3. XY(usingIR3on1and2).

PROOFOFIR5(USING IRlTHROUGH IR3):

1. X Y(given).
2. X Z(given).

3. XXY (usingIR2on1 byaugmentingwithX;noticethatXX = X).

DeptofCSE,CBIT-Kolar Page11
 DatabaseManagementSystem[21CS53] MODULE4
4. XYYZ(using IR2on2byaugmentingwithY).
5. XYZ(usinglR3 on3and4).
PROOFOFIR6(USING IRlTHROUGH IR3):
1. X Y(given).
2. WY Z(given).
3. WX WY(usingIR2on1 byaugmentingwithW).
4. WX Z(using IR3 on3 and 2).

➢ ThesetofdependenciesF+, whichwecalledtheclosureofF, canbedeterminedfrom Fbyusingonly

inference rules IRI through IR3.
➢ InferencerulesIR1 throughIR3 areknownasArmstrong'sinference rules.

➢ Asystematicwaytodetermine theseadditionalfunctionaldependencies is:

First determine each set of attributes ‘X’ that appears as a left-hand side of some functional dependency
in F and then to determine the set of all attributes that are dependent on X.
Definition:Foreachattributes‗X‘that appearsasaleft-handsideofsome functionaldependencyin ‗F‘, we
determine the set ‗X+‘ ofattributes that arefunctionallydetermined by‗X‘ based on‗F‘; here ‗X+‘ is called
the closure of X under F. Algorithm 4.1 can be used to calculate ‗X+‘.

Algorithm4.1: DeterminingX+,theClosureofXunderF
X+:=X;
Repeat
oldX+:=X+;
foreachfunctionaldependencyY ZinFdo if X+
Y then X+ := X+ Ụ Z;
until(X+=oldX+),
a) Algorithm4.1 startsbysetting X+to alltheattributesinX. ByIR1, weknow that allthese
attributes are functionally dependent on X.
b) Using inferencerulesIR3andIR4,weaddattributesto X+,usingeachfunctionaldependencyin F.
c) WekeepgoingthroughallthedependenciesinF(the repeat loop)untilno moreattributesare added
to X+ during a complete cycle (of the for loop) through the dependencies in F.

Forexample,considertherelationschemaEMP_PROJ.Fromthesemanticsoftheattributes,we specify the

following set F of functional dependencies that should hold on EMP_PROJ;

a. SSN→ENAME

DeptofCSE,CBIT-Kolar Page12
 DatabaseManagementSystem[21CS53] MODULE4
b. PNUMBER→{PNAME,PLOCATION}
c. {SSN,PNUMBER}→HOURS
UsingAlgorithm4.1, wecalculatethefollowing closuresetswithrespecttoF;
{SSN}+={SSN,ENAME}
{PNUMBER}+={PNUMBER,PNAME,PLOCATION}
{SSN,PNUMBER}+={SSN,PNUMBER,ENAME,PNAME,PLOCATION,
HOURS}

EquivalenceofSetsofFunctionalDependencies:
Definition:A set of functional dependencies F is said to coveranother set of functional dependencies E if every
FD in E is alsoin F+; that is,if every dependency in E can be inferred from F; alternatively,we can say that E
is covered by F.
Definition: Two sets of functional dependencies E and F are equivalentif E+ = F+. Hence, equivalence means
that every FD in E can be inferred from F, and every FD in F can be inferred from E; that is, E is equivalent
to F if boththe conditions E covers F and F covers Ehold.

MinimalSetsofFunctionalDependencies:
➢ Aminimalcoverofaset offunctionaldependenciesE isaset offunctionaldependencies Fthat
satisfies the propertythat everydependency in E is in the closure F+ ofF.
➢ Thispropertyislost ifanydependencyfromthesetFisremoved;Fmust have no redundanciesinit,and the
dependencies in E are in a standard form.
➢ Tosatisfytheseproperties, wecanformallydefine asetoffunctionaldependenciesFto be minimalifit
satisfies the following conditions:
a) EverydependencyinFhasasingleattributeforitsright-handside.
b) Wecannot replaceanydependencyX → AinFwithadependencyY → A, where Y isaproper subset
of X, and still have a set of dependencies that is equivalent to F.
c) WecannotremoveanydependencyfromFandstillhaveasetofdependenciesthat isequivalent to F.
➢ AminimalcoverofasetoffunctionaldependenciesE isa minimalset ofdependencies Fthat is
equivalent to E. There can be several minimal covers for a set of functionaldependencies.
➢ Wecanalwaysfind at leastoneminimalcover Fforanyset ofdependenciesEusingAlgorithm4.2.

Algorithm4.2:FindingaMinimalCoverFforaSetofFunctionalDependenciesE
1. SetF:=E.
2. ReplaceeachfunctionaldependencyX →{A1, A2,...,An} inFbythe nfunctionaldependencies X →
A1, X → A2, ..., X → An.

3. ForeachfunctionaldependencyX→ AinF
foreachattributeBthatisanelementofX

DeptofCSE,CBIT-Kolar Page13
 DatabaseManagementSystem[21CS53] MODULE4
if{{F- {X→A}}U{(X- {B})→A}}isequivalent toF, then
replace X → A with (X - {B}) → A in F.

4. Foreachremaining functionaldependencyX →AinF if {

F - {X → A} } is equivalent to F,
thenremove X→AfromF.

Example:LetthegivensetofFD‘sbeE:{B→A,D→A,AB→D}.Findthe minimal cover of E.

Answer:
• All the above dependencies are in canonical form, so we have completed step 1 ofthe algorithm and
can proceed to step2.In step2 we need to determine if AB→D has any redundant attributes on the left
hand side; that is can it be replaced by B→D or A→D?
• SinceB→A, byaugmentingwithBonbothsides(IR2), weget BB→AB, orB→AB(i). However
AB→D as given (ii).
• Hencebythetransitiverule(IR3),weget from(i)and(ii),B→D.HenceAB→D maybereplacedby B→D.
• Nowwehaveaset E’={B→A, D→A, B→D}.No furtherreductionispossible instep2sinceall FDs
have a single attribute on the left hand side.
• Instep3welookfor aredundant FD inE’. ByusingthetransitiveruleonB→DandD→A, we derive
B→ A. hence B→ A is redundant in E‘ and can be eliminated.
• HencetheminimumcoverofEis{B→ D,D→ A }

NORMALFORMSBASEDONPRIMARYKEYS:

NormalizationisaprocessofanalyzingthegivenrelationschemasbasedontheirFunctional Dependencies and

primary keys to achieve the desirable properties of
(1) Minimizingredundancyand
(2) Minimizingtheinsertion,deletion,andupdateanomalies

NormalizationofRelations:
➢ Thenormalizationprocess, asfirst proposedbyCodd(l972), takesarelationschemathroughaseries of
tests to "certify" whether it satisfies a certain normal form.
➢ Coddproposedthreenormalforms:1NF,2NF, and3NF.

➢ Theprocessproceedsinatop-downfashionbyevaluatingeachrelationagainst thecriteria fornormal forms

and decomposing relations as necessary. It is also called as relational design byanalysis.

➢ Thus,thenormalizationprocedureprovidesdatabasedesignerswiththefollowing:
i) Aformalframeworkforanalyzingrelationschemasbasedontheirkeysandonthefunctional
dependencies among their attributes.
ii) Aseriesofnormalformteststhat canbecarried outon individualrelationschemasso that the
relational database can be normalized to any desired degree.

DeptofCSE,CBIT-Kolar Page14
 DatabaseManagementSystem[21CS53] MODULE4
➢ Thenormalformofarelationreferstothehighestnormalformconditionthat it meets, andhence
indicates the degree to which it has been normalized.
➢ Theprocess of normalization through decompositionmustalsoconfirm theexistenceof additional
properties that the relational schemas should possess. These would include two properties:
a) Thelosslessjoinornonadditivejoinproperty: Thisguaranteesthatthespurioustuplegeneration
problem does not occur with respect to the relation schemas created after decomposition.
b) Thedependencypreservationproperty: Thisensuresthateachfunctionaldependencyis
represented in some individual relation resulting after decomposition.

➢ The process ofstoring the join ofhigher normal formrelations as a base relation-which is in a lower
normalform-isknownas―denormalization‖.Thisissometimesdoneforsomeperformancereasons.

PracticalUseofNormalForms
• Normalization is carried out in practice so that the resulting designs are of high quality and meet the
desirable properties stated previously.
• Database design as practicedin industry today pays particularattention to normalization only up
to3NF, BCNF, or at most 4NF.

DefinitionsofKeysandAttributesParticipatinginKeys:
a) Definition:Asuperkeyofa relation schema R ={A1, A2,... , An} is a set ofattributes S C R with the
propertythat no twotuples ‗t1‘ and ‗t2‘inanylegalrelation state ‗r‘of‗R‘ will have t1[S] =t2[S].
b) Definition:Akey‗K‘isasuperkeywiththeadditionalpropertythat removalofanyattributefrom‗K‘ will
cause ‗K‘ not to be a superkey any more.
Thedifferencebetweenakeyandasuperkeyisthatakeyhasto beminimal;thatis,ifwehaveakey
K={A1,A2,...,Ak}of‗R‘,thenK-{Ai}isnotakeyof‗R‘foranyAiwhere1≤i≤k.
Inthefollowing figure, {SSN}isakeyforEMPLOYEE,whereas{SSN},{SSN,ENAME},{SSN, ENAME,
BDATE}, and any set of attributes that includes SSN are all superkeys.

c) Definition: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 secondarykeys.
Each relation schema must have a primary key.
{SSN}istheonlycandidatekeyforEMPLOYEE,soitisalsothe primarykey.
d) Definition:An attribute of relation schema R is called a prime attributeof R if itis a member of some
candidate keyof R. An attribute is called nonprimeif itis not a prime attribute-that is, if itis not a member
of any candidate key.
Inthe following figure,bothSSNandPNUMBER areprimeattributesof WORKS_ON,whereasother
attributes of WORKS_ON are nonprime.

DeptofCSE,CBIT-Kolar Page15
 DatabaseManagementSystem[21CS53] MODULE4

FirstNormalForm:
➢ First normal form (INF) is defined to disallow multivalued attributes, composite attributes, and
theircombinations.
➢ 1NF states that ―the domain of an attribute must include only atomic (simple, indivisible) valuesand
that the value ofanyattribute in a tuple must be a single valuefromthe domain ofthat attribute‖.
➢ Consider the DEPARTMENT relation schema shown in Figure 6.7a, whose primary key is DNUMBER,
and suppose that we extend it by including the DLOCATIONS attribute as shown in Figure 6.7a. We
assume that each departmentcan have a number of locations. The example relation state for
DEPARTMENT is shown in Figure 6.7b.

FIGURE4.7:Normalizationinto1NF.(a)Arelationschemathatisnotin1NF.

FIGURE4.7:Normalizationinto1NF.(b)ExamplestateofrelationDEPARTMENTwithoutnormalization.

➢ Aswecansee, stateof relation DEPARTMENT inFigure4.7isnot in 1NFbecauseDLOCATIONSis not

an atomic attribute.

Therearethree main techniquestoachievefirstnormalformforsucha relation:

a) RemovetheattributeDLOCATIONSthatviolates1NFandplaceitinaseparaterelation
DEPT_LOCATIONS alongwiththeprimarykeyDNUMBERofDEPARTMENT.
i) Theprimarykeyofthisrelationisthecombination{DNUMBER, DLOCATION}, asshownin
following Figure.
ii) AdistincttupleinDEPT_LOCATIONSexistsforeachlocationofadepartment.
iii) Thisdecomposesthenon-1NFrelationintotwo1NFrelations.

DeptofCSE,CBIT-Kolar Page16
 DatabaseManagementSystem[21CS53] MODULE4

b) Expand the keyso that there will be a separate tuple in the original DEPARTMENT relation for each
location of a DEPARTMENT, as shown in the following Figure 6.8.
i) Inthiscase,theprimarykeybecomesthecombination{DNUMBER,DLOCATION}.
ii) Thissolutionhasthedisadvantageofintroducing redundancyintherelation.

Figure6.8:1NFversionofDEPARTMENTrelationwithredundancy.

➢ First normal form also disallows multivalued attributes that are themselves composite. These are called
nested relations because each tuple can have a relation within it.
➢ Figure 4.9a shows how the EMP_PROJ relation schema could appear if nesting is allowed. Each tuple
Represents an employee entity, and a relation PROJS(PNUMBER, HOURS) within each tuple represents
the employee's projects and the hours per week that employee works on each project.
➢ Theschema ofthisEMP_PROJ relationcanberepresented as follows:
EMP_PROJ(SSN,ENAME,{PROJS(PNUMBER, HOURS)})
Theset braces{}identifytheattributePROJSasmultivalued,andwelist thecomponent attributes that form
PROJS between parentheses ( ).

DeptofCSE,CBIT-Kolar Page17
DatabaseManagementSystem[18CS53] MODULE4

FIGURE 4.9Normalizingnestedrelationsinto1NF. (a) Schema of theEMP_PROJrelationwitha"nestedrelation" attribute

PROJS. (b) Example extension of the EMPROJ relation showing nested relations withineach tuple.

To normalize this into INF, we remove the nested relation attributes into a new relation and
propagate the primary key into it; the primary key of the new relation will combine the partial key with
the primary key of the original relation. Decomposition and primary key propagation yield the schemas
EMP_PROJl and EMP_PROJ2.

SecondNormalForm:
➢ Secondnormalform(2NF)isbasedonthe concept ofFullfunctionaldependency.
➢ AfunctionaldependencyX→Yisafullfunctionaldependencyifremovalofanyattribute‗A‘from
‗X‘meansthatthedependency doesnotholdany more.Thatis,forany attributeA €X,(X-{A}) does not
functionally determine ‗Y‘.
➢ AfunctionaldependencyX→YisapartialdependencyifsomeattributeA€Xcanberemovedfrom
‗X‘andthedependencystillholds.
Thatis,for someA€X,(X-{A})→Y.

Asst,Prof.ANJALIDV,DeptofCSE,CBIT-Kolar Page18
DatabaseManagementSystem[18CS53] MODULE4
➢ In the following Figure 6.10, {SSN, PNUMBER}→HOURS is a full dependency(neither SSN →
HOURS nor PNUMBER→HOURS holds). However, the dependency {SSN, PNUMBER} →
ENAME is partialbecause SSN → ENAME holds.

Figure6.10:RelationEMP_PROJisin1NFbutnotin2NF

➢ Definition: A relation schema ‘R’ is in 2NF if every nonprime attribute ‘A’ in ‘R’ is fully functionally
dependent on the primary key of ‘R’. or A relation schema ‘R’ is in second normal form (2NF) if
every nonprime attribute ‘A’ in R is not partially dependent on any key of‘R’.
➢ The test for 2NF involves testing for functional dependencies whose left-hand side is a primary key
composed of multiple attributes. If the primary key contains a single attribute, the test need not be applied
at all.

➢ TheEMP_PROJrelationintheabovefigureis in1NFbutisnotin2NF.
a) ThenonprimeattributeENAMEviolates2NFbecauseofFD2.ENAMEispartiallydependenton
{SSN,PNUMBER}andnotdependentonPNUMBER.(GivenENAMEcanbedeterminedonlyby SSN. So
the other attributes are not needed for that table)
b) ThenonprimeattributesPNAMEandPLOCATIONviolates2NFbecauseofFD3.PNAMEand
PLOCATION are partially dependent on {SSN,PNUMBER} and not dependent on SSN.
➢ The functional dependencies FD1, FD2 and FD3 in Figure 4.10 hence lead to the decomposition of
EMP_PROJ intothe three relation schemas EPl, EP2, and EP3 shown below, each ofwhich is in2NF.

Asst,Prof.ANJALIDV,DeptofCSE,CBIT-Kolar Page19
DatabaseManagementSystem[18CS53] MODULE4
ThirdNormalForm:
➢ Thirdnormalform(3NF)isbasedontheconceptofTransitivedependency.
➢ A functional dependency X→Y in a relation schema ‗R‘ is a transitive dependency if there is a set of
attributes‗Z‘ that isneitheracandidatekeynor asubset of anykeyofR, andbothX→Zand Z→Yhold.
➢ Definition:A relation schema ‗R‘ is in 3NF if it satisfies 2NFand no nonprime attribute of ‗R‘ is
transitively dependent on the primary key. A relation schema ‗R‘ is in third normal form (3NF) if,
whenever a nontrivialfunctional dependency X → A holds in ‗R‘, either
(a) ‗X‘isasuperkeyof‗R‘,or
(b) ‗A‘isaprimeattributeofR.

➢ ThedependencySSN→DMGRSSNistransitivethroughDNUMBERinEMP_DEPTofFigure4.11
because:
a) BoththedependenciesSSN→DNUMBERand DNUMBER→DMGRSSNhold.
b) DNUMBERisneitherakeyitselfnorasubsetofthe keyofEMP_DEPT.
c) WecanseethatthedependencyofDmgr_ssnonDnumber isundesirable inEMP_DEPT since
Dnumber is not a key of EMP_DEPT.

Figure4.11RelationEMP_DEPTisin1NFand2NFbutnotin3NF

➢ The relation schema EMP_DEPT in Figure 4.11 is in 2NF, since no partialdependencies on a keyexist.
However, EMP_DEPT is not in 3NF because of the transitive dependency of DMGRSSN (and also
DNAME) on SSN via DNUMBER.
➢ WecannormalizeEMP_DEPTbydecomposingitintothetwo3NFrelationschemasEDlandED2
showninfollowing Figure.

Table6.1 informallysummarizesthethree normalforms basedonprimarykeys, thetestsusedineach case, and

the corresponding "remedy" or normalization performed to achieve the normal form.

Asst,Prof.ANJALIDV,DeptofCSE,CBIT-Kolar Page20
DatabaseManagementSystem[18CS53] MODULE4

TABLE6.1:SUMMARYOFNORMALFORMSBASEDONPRIMARYKEYSANDCORRESPONDING NORMALIZATION

EXAMPLE:
• Suppose that there are two candidate keys: 1) PROPERTY_ID# and 2) {COUNTY_NAME, LOT#};
that is, lot numbers are unique only within each county, but PROPERTY_ID numbers are unique
across counties for the entire state.

Candidate key

Figure4.12:TheLOTSrelationwithitsfunctionaldependenciesFD1and FD2

• BasedonthetwocandidatekeysPROPERTY_ID#and{COUNTY_NAME,LOT#},thefunctional
dependencies FD1 and FD2 of Figure 4.12 hold.

• WechoosePROPERTY_ID#astheprimarykey,soitisunderlinedinFigure4.12.

• SupposethatthefollowingtwoadditionalfunctionaldependenciesholdinLOTS:
FD3:COUNTY_NAME→TAX_RATE FD4:
AREA → PRICE

Asst,Prof.ANJALIDV,DeptofCSE,CBIT-Kolar Page21
DatabaseManagementSystem[18CS53] MODULE4
• TheLOTSrelationschemaviolatesthegeneraldefinitionof2NFas TAX_RATE ispartially
dependent on the candidate key {COUNTY_NAME, LOT#} because:
a) DuetoFD2{COUNTY_NAME,LOT#}→TAX_RATE
b) DuetoFD3{COUNTY_NAME}→TAX_RATE

• TonormalizeLOTSinto2NF, wedecomposeitintothetworelationsLOTS1andLOTS2,shown below.

Figure 4.13:LOTS1andLOTS2in2NF

➢ TonormalizeLOTS1 into3NF,wedecompose it intotherelationschemasLOTS1AandLOTS1Bas shown

in Figure 4.14

Figure4.14:LOTS1AandLOTS1Bin3NF

Asst,Prof.ANJALIDV,DeptofCSE,CBIT-Kolar Page22
DatabaseManagementSystem[18CS53] MODULE4
a)We constructLOTS1A by removing the attribute PRICE thatviolates 3NF from LOTS1 and placingit
with AREA (the left-hand side of FD4 that causes the transitive dependency) into another relation
LOTS1B.

➢ Twopointsareworthnoting aboutthisexampleandthegeneraldefinitionof3NF:
a) LOTS1 violates 3NF because PRICE is transitively dependent on each of the candidate keys of LOTS1
via the nonprime attribute AREA.

b) we find that both FD3 and FD4 violate 3NF. We could hence decompose LOTS into LOTSlA,
LOTSlB, and LOTS2 directly.

BOYCE-CODD NORMALFORM:
➢ Boyce-Coddnormalform(BCNF)wasproposedasasimpler formof3NF, but it wasfoundtobe stricter
than 3NF.

➢ Everyrelationin BCNFisalso in 3NF;however,arelation in3NFisnotnecessarilyinBCNF.

➢ Definition. ArelationschemaR is inBCNFifwhenevera nontrivialfunctionaldependencyX→A holds

in R, then X is a superkey of R.

➢ ConsidertherelationschemaofLOTS1Agivenbelow

FD5:AREA→ COUNTY_NAME

• TherelationschemaLOTS1Astillisin3NFbecauseCOUNTY_NAMEisaprimeattribute.

➢ TheonlydifferencebetweenthedefinitionsofBCNFand3NFisthat condition(b)of3NF,whichallows A
to be prime, is absent from BCNF.
➢ Inourexample,FD5violatesBCNFin LOTS1AbecauseAREAisnota superkeyofLOTS1A.
➢ Notethat FD5satisfies3NFinLOTSIAbecauseCOUNTY_NAMEisaprimeattribute(conditionb), but this
condition does not exist in the definition of BCNF.

Asst,Prof.ANJALIDV,DeptofCSE,CBIT-Kolar Page23
DatabaseManagementSystem[18CS53] MODULE4
➢ WecandecomposeLOTSIAinto twoBCNFrelationsLOTS1AXandLOTS1AYasshownbelow.

➢ TherelationschemaRshowninfollowing Figure illustratesthegeneralcaseofarelationbeing in3NF but not

in BCNF.

MULTIVALUEDDEPENDENCY(MVD)ANDFOURTHNORMALFORM

➢ Multivalued dependencies are a consequence of first normal form(1NF), which disallows an attribute in a
tuple to have a set of values, and the accompanying process of converting an unnormalized relationinto
1NF.
➢ If we have two or more multivalued independent attributes in the same relation schema, we get into a
problemof having to repeat every value ofone ofthe attributes with every value ofthe other attribute to keep
the relation state consistent and to maintain the independence among the attributes involved. This
constraint is specified by a multivalued dependency.

FormalDefinitionofMultivaluedDependency
Definition ofMultivalued dependency: Amultivalued dependency specified on relation schema R,
where X and Y are both subsets of R, specifies the following constraint on any relation state r of R: If two
tuples t1 and t2 exist in r such that t1[X] = t2[X], then two tuples t3 and t4 should also exist in r with the
following properties, where we use Z to denote (R – (X 𝖴Y)):

t3[X]=t4[X]=t1[X]=t2[X].
t3[Y]=t1[Y]andt4[Y]=t2[Y].
t3[Z]=t2[Z] andt4[Z]=t1[Z].

Whenever holds, we say that X multidetermines Y. Because of the symmetry in the definition,
whenever holds in R,so does . Hence, implies ,and therefore itis sometimes
written as .

Asst,Prof.ANJALIDV,DeptofCSE,CBIT-Kolar Page24
DatabaseManagementSystem[21CS53] MODULE4
Definition of 4NF: A relation schema R is in 4NF with respect to a set ofdependencies F (that includes
functionaldependenciesandmultivalueddependencies)if, foreverynontrivialmultivalueddependencyX
→→YinF+XisasuperkeyforR.

➢ Inferencerules followed in4NFare:

In the EMP relation of Figure 4.15(a), the values ‗X‘ and ‗Y‘ of Pname are repeated with each value of
Dname(or,bysymmetry,thevalues‗John‘and‗Anna‘ofDnamearerepeatedwitheachvalueofPname).
In4.15(c),noteverySnamedeterminesvariousPart_nameandnot everySnamedeterminesmultiple Proj_name. so it
is not MVD. Therefore it is in 4NF.
Example1:Figure4.15

DeptofCSE,CBIT-Kolar Page25
DatabaseManagementSystem[21CS53] MODULE4

Example 2:

JOINDEPENDENCIESANDFIFTHNORMALFORM(5NF)
Definition of join dependency: A join dependency (JD), denoted by JD(R1, R2, ..., Rn), specified on relation
schema R,specifies a constrainton the statesr of R.The constraintstates thatevery legal stater of R should have
a nonadditive join decomposition into R1, R2, ..., Rn.
Hence,foreverysuchrwe have

Definition of 5 NF: A relation schema R is in fifth normal form (5NF) (or project-join normal form
(PJNF)) withrespect to aset Foffunctional, multivalued, and joindependencies if, for everynontrivialjoin
dependency JD(R1, R2, ..., Rn) in F+ (that is, implied by F), everyRi is a superkeyof R.

Figure4.16(d)showshowtheSUPPLYrelation withthejoin dependencyisdecomposedintothree relations

R1,R2,and R3that are eachin 5NF.
Noticethat applyinganaturaljointo anytwooftheserelationsproducesspurioustuples, but applyinga natural join
to all three together does not.

DeptofCSE,CBIT-Kolar Page26
DatabaseManagementSystem[21CS53] MODULE4

Figure4.16

Algorithm4.12(a).FindingaKey KforRGivenaset FofFunctionalDependencies: Input:

A relation R and a set of functional dependencies F on the attributes of

R.
1. Set K :=R.
2. Foreachattribute AinK
{compute(K– A)+withrespecttoF;
if(K–A)+containsalltheattributesinR,thensetK:= K–{A}};

PROPERTIESOFRELATIONALDECOMPOSITIONS
RelationDecompositionandInsufficiencyofNormal Forms:
➢ Letuniversalrelationschema R= {A1,A2,...,An}thatincludesallthe attributesofthedatabase.
➢ Weimplicitlymaketheuniversalrelationassumption,whichstatesthateveryattributenameisunique.
➢ Theset Foffunctionaldependenciesthat should holdontheattributesofR isspecified bythedatabase
designers and is made available to the design algorithms.
➢ Using the functionaldependencies, the algorithms decompose the universal relation schema R into a set
ofrelationschemas D = {R1, R2, ..., Rm} that will become the relationaldatabase schema;D is called a
decomposition of R.
➢ We must make sure that each attribute in R will appear in at least one relation schema Ri in the
decomposition so that no attributes are lost. This is called the attribute preservation condition of a
decomposition.

DeptofCSE,CBIT-Kolar Page27
DatabaseManagementSystem[21CS53] MODULE4

consider the EMP_LOCS(Ename, Plocation) relation in below, which is in 3NF and also in BCNF. In fact,
anyrelation schema with onlytwo attributes is automatically in BCNF. Although EMP_LOCSis inBCNF, it
stillgives rise to spurious tuples when joined with EMP_PROJ (Ssn, Pnumber, Hours, Pname, Plocation),
which is not in BCNF.

DependencyPreservation PropertyofaDecomposition
➢ It would be useful if each functional dependency X->Y specified in F either appeared directly in one of
the relation schemas Ri in the decomposition D or could be inferredfrom the dependencies thatappearin
some Ri. This is the dependency preservation condition.
➢ Wewantto preservethedependenciesbecauseeachdependencyinFrepresentsaconstraint onthe
database.
➢ Ifoneofthedependencies is notrepresentedinsome individualrelationRiofthe decomposition, we
cannot enforce this constraint by dealing with an individual relation.
➢ Wemayhavetojoinmultiplerelationssoastoincludeallattributesinvolvedinthatdependency.
➢ GivenasetofdependenciesFonR,theprojectionofFonRi,denotedby whereRiisasubsetof
R,isthesetofdependencies inF+suchthat theattributesin areallcontainedinRi.
➢ If a decomposition is not dependency-preserving, some dependency is lost in the decomposition. To check
that a lost dependency holds, we must take the JOIN of two or more relationsinthe decompositionto get
arelationthat includesallleft andright-hand-sideattributesofthe lost dependency, and then check that the
dependency holds on the result of the JOIN.

DeptofCSE,CBIT-Kolar Page28
DatabaseManagementSystem[21CS53] MODULE4

Nonadditive(Lossless) JoinPropertyofaDecomposition
➢ Thenonadditive joinproperty, whichensuresthatno spurioustuplesaregeneratedwhenaNATURAL JOIN
operation is applied to the relations resulting from the decomposition.
➢ Because this is a property of a decomposition of relation schemas, the condition of no spurious tuples
should hold on every legal relation state—that is, every relation state that satisfies the functional
dependencies in F.
➢ Hence,thelosslessjoinpropertyisalwaysdefinedwithrespectto aspecificsetFofdependencies.

Definition: Formally, a decomposition D = {R1, R2, ..., Rm} of R has the lossless (nonadditive) join property
with respect to the set of dependencies F on R if, for every relation state r of R that satisfies F, the following
holds, where * is the NATURAL JOIN ofallthe relations in D: *(πR1(r), ..., πRm(r) ) = r.
➢ The decomposition of EMP_PROJ(Ssn, Pnumber, Hours, Ename, Pname, Plocation) in into
EMP_LOCS(Ename, Plocation) and EMP_PROJ1(Ssn, Pnumber, Hours, Pname, Plocation) does not have
the nonadditive join property.

Algorithm4.8.TestingforNonadditiveJoin Property
Input: AuniversalrelationR, adecompositionD={R1, R2,..., Rm}ofR, andaset Foffunctional dependencies.
Note:commentsfollowtheformat:(*comment*).
1. Createan initial matrixS withonerowiforeachrelationRiin D,andonecolumnjforeachattributeAj
inR.
2. SetS(i,j):=bijforallmatrixentries.(*eachbijisadistinctsymbolassociatedwithindices(i,j)*).
3. Foreachrow irepresentingrelationschemaRi
{foreachcolumn jrepresentingattributeAj
{if(relationRi includesattributeAj)thenset S(i, j):=aj;};};(*eachajisadistinct
symbol associated with index ( j) *).
4. RepeatthefollowingloopuntilacompleteloopexecutionresultsinnochangestoS
{for eachfunctionaldependencyX→YinF
{forallrowsinSthathavethesamesymbolsinthecolumnscorrespondingtoattributes in X
{makethesymbols ineachcolumnthat correspondtoanattributein Y bethesame in all
these rows as follows:
Ifanyofthe rowshasanasymbolforthecolumn,settheotherrowstothatsame a
symbolinthe column.
Ifno a symbolexists fortheattribute inanyofthe rows,chooseoneofthe b symbols that
appears in one ofthe rows for the attribute and set the other rowsto that same b symbol
in the column}}}
5. Ifarowismadeup entirelyof‗a’symbols,thenthedecompositionhasthe nonadditive
joinproperty;otherwise,itdoes not.

DeptofCSE,CBIT-Kolar Page29
DatabaseManagementSystem[21CS53] MODULE4

Figure: 4.8
R1(Emp_ssn,Esal,Ephone,Dno) R2
(Pno, Pname, Plocation)
R3(Emp_ssn,Pno)
Thisdesignachievesboththedesirablepropertiesofdependencypreservationandnonadditivejoin.

DeptofCSE,CBIT-Kolar Page30
DatabaseManagementSystem[21CS53] MODULE4
TestingBinaryDecompositionsfortheNonadditiveJoinProperty (NJB)
➢ There isaspecialcaseofadecompositioncalleda binarydecomposition—decompositionofarelation R into
two relations, PropertyNJB (Nonadditive Join Test for BinaryDecompositions).
➢ AdecompositionD={R1, R2}ofRhasthe lossless (nonadditive) joinpropertywithrespect toasetof
functional dependencies F on R if and only if either
TheFD((R1∩R2)→(R1 –R2))isinF+,or The
FD ((R1 ∩ R2)→(R2 – R1)) is in F+

➢ Exampledecompositionof theTEACH(Instructor,Course,Student)relationintothetworelations
{Instructor,Course}and{Instructor,Student}.Thesearevaliddecompositionsbecausetheyare nonadditive per
the above test.

SuccessiveNonadditiveJoinDecompositions
If a decomposition D = {R1, R2, ..., Rm} of R has the nonadditive (lossless) join property with respect to a set
of functional dependencies F on R, and if a decomposition Di = {Q1, Q2, ..., Qk} of Ri has the nonadditive
join propertywith respect to the projection of F on Ri,
thenthedecompositionD2={R1, R2,...,Ri−1, Q1, Q2,..., Qk,R i+1,..., Rm}ofR hasthe nonadditive join property
with respect to F.

ABOUTNULLS,DANGLINGTUPLES, ANDALTERNATIVERELATIONALDESIGNS

Problemswith NULLValuesandDanglingTuples:
➢ We must carefullyconsiderthe problemsassociatedwithNULLswhendesigninga
relational database schema.
➢ OneproblemoccurswhensometupleshaveNULLvaluesforattributesthat willbeusedto join
individual relations in the decomposition.
To illustrate this, consider the database shown in Figure 16.2(a), where two The lasttwoemployee tuples—
‗Berger‘ and ‗Benitez‘—represent newly hired employees who have not yet been assigned to a department).
Now suppose thatwe want toretrievealistof (Ename,Dname)valuesforall the employees.If we apply the
NATURAL JOIN operation on EMPLOYEE and DEPARTMENT (Figure 16.2(b)), the two forementioned
tuples will not appear in the result. The OUTER JOIN operation can deal with this problem.

➢ In general, whenever a relational database schema is designed in which two or more relations are
interrelated via foreign keys, particular care must be devoted to watching for potential NULL values in
foreign keys. This can cause unexpected loss of information in queries that involve joins on that foreign
key. Moreover, ifNULLs occur in other attributes, such as Salary, their effect on built-in functions such as
SUM and AVERAGE must be carefully evaluated.
➢ Arelated problem isthat ofdangling tuples, which mayoccur ifwecarryadecompositiontoo far.
Suppose that we decompose the EMPLOYEE relation in Figure
16.2(a)furtherintoEMPLOYEE_1andEMPLOYEE_2,showninFigure16.3(a)and
16.3(b).

DeptofCSE,CBIT-Kolar Page31
DatabaseManagementSystem[21CS53] MODULE4
If we apply the NATURAL JOIN operation to EMPLOYEE_1 and EMPLOYEE_2, we get the original
EMPLOYEE relation. However, we may use the alternative representation, shown in Figure 16.3(c), where
we do not include a tuple in EMPLOYEE_3 ifthe employee has not been assigned a department (instead of
including a tuple with NULL for Dnum as in EMPLOYEE_2).
If we use EMPLOYEE_3 instead of EMPLOYEE_2 and apply a NATURAL JOIN on EMPLOYEE_1 and
EMPLOYEE_3, the tuples for Berger and Benitez will not appear in the result; these are called dangling
tuples in EMPLOYEE_1 because they are represented in only one of the two relations that represent
employees, and hence are lost if we apply an
(INNER)JOINoperation.
Figure16.2(a)

DeptofCSE,CBIT-Kolar Page32
DatabaseManagementSystem[21CS53] MODULE4

OTHERDEPENDENCIES ANDNORMALFORMS
Othertypesofdependencies:
InclusionDependencies
Inclusiondependenciesweredefinedinordertoformalizetwotypesofinterrelationalconstraints:
➢ The foreignkey(orreferentialintegrity)constraint cannotbespecifiedasafunctionalormultivalued
dependency because it relates attributes across relations.
Definition: An inclusion dependency R.X < S.Y between two sets of attributes— X of relation schema R, and
Y of relation schema S—specifies the constraint that, at anyspecific time when r is a relation stateof R and s a
relation state of S, we must have

Forexample,wecanspecifythe following inclusiondependenciesontherelationalschema inwhich represent

represent referential integrity constraints:
DEPARTMENT.Dmgr_ssn<EMPLOYEE.Ssn
WORKS_ON.Ssn <EMPLOYEE.Ssn
EMPLOYEE.Dnumber<DEPARTMENT.Dnumber
PROJECT.Dnum <DEPARTMENT.Dnumber
WORKS_ON.Pnumber <PROJECT.Pnumber
DEPT_LOCATIONS.Dnumber<DEPARTMENT.Dnumber

Wecanalsouseinclusiondependenciesto represent class/subclassrelationships.Forexample,wecan specify the

following inclusion dependencies:

DeptofCSE,CBIT-Kolar Page33
DatabaseManagementSystem[21CS53] MODULE4
EMPLOYEE.Ssn<PERSON.SsnSTUDENT.Ssn<PERSON.Ssn
Aswithothertypesofdependencies,thereareinclusiondependencyinferencerules(IDIRs).The following are
three examples:
IDIR1(reflexivity):R.X<R.X.
IDIR2(attributecorrespondence): IfR.X<S.Y,whereX={A1, A2, ...,An}andY={B1, B2, ...,
Bn} and Aicorresponds to Bi, then R.Ai< S.Bi for 1 ≤ i≤ n.
IDIR3(transitivity):IfR.X< S.Y and S.Y<T.Z,thenR.X< T.Z.

TemplateDependencies

➢ The idea behindtemplatedependenciesistospecifyatemplate—orexample—that

defines each constraint or dependency.
➢ Therearetwotypesoftemplates:tuple-generatingtemplatesandconstraint generating
templates.
➢ Atemplateconsistsofanumber ofhypothesistuplesthat aremeant toshowanexampleofthetuples that
mayappear in one or more relations.The other part of the template is the templateconclusion.
➢ Fortuple-generatingtemplates,theconclusionisasetoftuplesthat must also exist intherelations if the
hypothesis tuples are there.
➢ Forconstraint-generatingtemplates,thetemplateconclusionisaconditionthat must holdonthe
hypothesis tuples.

DeptofCSE,CBIT-Kolar Page34
DatabaseManagementSystem[21CS53] MODULE4

FunctionalDependenciesBasedonArithmeticFunctionsandProcedures
➢ Sometimessomeattributesinarelationmayberelatedviasomearithmetic functionoramore
complicated functional relationship.
Forexample,intherelation
ORDER_LINE(Order#,Item#,Quantity,Unit_price,Extended_price,Discounted_price)
eachtuplerepresentsan itemfromanorderwithaparticularquantity,and the price

DeptofCSE,CBIT-Kolar Page35
DatabaseManagementSystem[21CS53] MODULE4
perunitforthatitem.Inthisrelation, (Quantity, Unit_price)→Extended_price
bytheformula
Extended_price=Unit_price*Quantity.

Hence,thereisauniquevalue forExtended_price foreverypair(Quantity,Unit_price), and thus

it conforms to the definition of functional dependency.
➢ Therefore,wecan say
(Item#, Quantity, Unit_price ) → Discounted_price, or
(Item#,Quantity,Extended_price)→Discounted_price.

Domain-KeyNormalForm
➢ The ideabehinddomain-keynormalform(DKNF) isto specify(theoretically,at least)the ultimate
normal form that takes into account all possible types of dependencies and constraints.
➢ Arelationschema is saidto be inDKNF ifallconstraintsanddependenciesthat should holdonthevalid relation
states can be enforced simply by enforcing the domain constraints and key constraints on the relation.
➢ For a relation in DKNF, it becomes very straightforward to enforce all database constraints by simply
checking that each attribute value in a tuple is ofthe appropriate domain and that everykeyconstraint is
enforced.
➢ However, becauseofthedifficultyofincludingcomplexconstraints inaDKNFrelation, its
practical utility is limited,
Forexample,considerarelationCAR(Make,Vin#)(where Vin# isthevehicle identificationnumber)and
another relation MANUFACTURE(Vin#, Country) (where Country is the countryof manufacture).
Ageneralconstraintmaybeofthe following form:
If the Make is either ‘Toyota’ or ‘Lexus,’ then the first character of the Vin# is a ‘J’ if the country of
manufacture is ‘Japan’; if the Make is ‘Honda’ or ‘Acura,’ the second character of the Vin# is a ‘J’ if the
country of manufacture is ‘Japan.’

DeptofCSE,CBIT-Kolar Page36