37 views

Uploaded by Naman Verma

Relational Database Management System

save

- Lecture 37 Closest Pair
- rice strategy ppt
- Topic2050
- apCompSci2009FRQ_q4
- JAVA file
- C3921D_E-1.2_RevC_Electrical Schematic Wiring Diagram (Power System)_40546818
- s970-burdick
- Mesh Warping
- Mathematics
- Motion Planning for Multiple Autonomous Vehicles: Best PhD Award Presentation at ITSC, 2014
- Phil
- Overview
- Michaelangelo
- artificial intelligence paper
- MIT6_034F10_quiz1_2007
- Best First Search
- Decision Trees in Practice _ Coursera_programming_assignment-quiz.pdf
- Nc02
- MATH: Phone Special
- maximizing the profit of a business
- 2016 fall final review
- TWO PHASE RETRIAL QUEUEING SYSTEM WITH IMPATIENT CUSTOMERS, ADDITIONAL OPTIONAL SERVICE, SERVER BREAKDOWN, DELAYED REPAIR AND RESERVED TIME
- Determining Optimal Testing Facility Locations for Mining Concentrations in Benguet Using Non-capacitated P-k Median Model
- WB-Mech_120_WS_03.2
- Independent Thinking
- Geologic Modelling
- Code Design for Relay Channels
- Addison-Wesley - Franklin G.F., Powell J.D., Workman M.L. - Digital Control of Dynamic Systems, 3E
- lecture02.ppt
- Edit Distance
- Presentasi kasus demam berdarah dengue
- aguas residules.pdf
- 1.- Aspectos Psicosociales de La Criminalización.. 35-36
- 1_Kapitel-1.pdf
- Realismo Capitalista ¿No Hay Alternativa
- Article-on-Works-Contract-ilovepdf-compressed-10.pdf
- 4.2.3- Decision Making Processes
- NORMAS_PARA_DIBUJO_TECNICO (1).pdf
- Definisi.doc
- Estructura Juridica del Estado de Chile (Lectura).pdf
- Ejercicios Para Estudiar-1591
- Sr Juan1 Estructura Ciment
- 5 Momen dan 6 Langkah Cuci Tangan.docx
- Solicita Autorización Para Cambio de Nombre
- Ciencias naturales
- Docdownloader.com Bus Terminal Cum Commercial Complexdocx
- Doc2
- Ppt Css Agus
- Hegel - Fenomenologia del Espiritu - Edición Bilingüe.pdf
- biceps 3
- push pull.docx
- Mari
- Munir
- conventions ml4
- Abstract Nana
- HIDROCICLONES.pdf
- 01-08-18 Denuncia Adrián robo de 90 casillas electorales en Monterrey
- Manual Segurança em Serv. de impermeab..pdf
- Taller 3 Chgue
- A Logitica Agrega Valor Aos Processos Da Cadeia de Suprimentos Quando o Estoque é Estrategicamente Posicionado Para Gerar Vendas
- Corporate Social Responsibility
- Indian Institute of ManagementCalcutta
- Key Factors
- KMS-Week1
- ch06
- 13
- Corporate Social Responsibility
- Backup and Recovery
- Kitten
- HTMLppt [Autosaved]
- Lecture Notes 01 Knowledge Management Systems
- Bera
- Chapter 8
- Karna
- 34946012
- Part08 Fuzzy Logic
- W4A_Paper_1
- SQL Basics II
- Handout
- 5....Personality
- OS-IV
- hris11
- Download File
- Csr at Tisco
- Agro Products
- SA8000 - Wikipedia, The Free Encyclopedia
- Solver 2007
- Oracle Database Brief History4932 2
- OS-I
- Distribution Channel

You are on page 1of 8

**Consider a relation R that has two attributes A and B. The attribute B of
**

the relation is functionally dependent on the attribute A if and only if

for each value of A no more than one value of B is associated. In other

words, the value of attribute A uniquely determines the value of B and

if there were several tuples that had the same value of A then all these

tuples will have an identical value of attribute B. That is, if t1 and t2

are two tuples in the relation R and

t1(A) = t2(A) then we must have t1(B) = t2(B).

A and B need not be single attributes. They could be any subsets of the

attributes of a relation R (possibly single attributes). We may then write

R.A -> R.B

if B is functionally dependent on A (or A functionally determines B).

unctional dependency does not imply a one!to!one relationship

between A and B although a one!to!one relationship may e"ist

between A and B.

# simple e"ample of the above functional dependency is when A is a

primary $ey of an entity (e.g. student number) and A is some single!

valued property or attribute of the entity (e.g. date of birth). A -> B

then must always hold. unctional dependencies also arise in

relationships. %et C be the primary $ey of an entity and D be the

primary $ey of another entity. %et the two entities have a relationship.

If the relationship is one!to!one, we must have C -> D and D -> C. If

the relationship is many!to!one, we would have C -> D but not D -> C.

or many!to!many relationships, no functional dependencies hold. or

e"ample, if C is student number and D is sub&ect number, there is no

functional dependency between them. If however, we were storing

mar$s and grades in the database as well, we would have

(student_number, subject_number) -> marks

and we might have

marks -> grades

The second functional dependency above assumes that the grades are

dependent only on the mar$s. This may sometime not be true since

the instructor may decide to ta$e other considerations into account in

assigning grades, for e"ample, the class average mar$.

or e"ample, in the student database that we have discussed earlier,

we have the following functional dependencies'

sno -> sname

sno -> address

cno -> cname

cno -> nstructor

nstructor -> o!ce

These functional dependencies imply that there can be only one name

for each sno, only one address for each student and only one sub&ect

name for each cno. It is of course possible that several students may

have the same name and several students may live at the same

address. If we consider cno -> nstructor, the dependency implies

that no sub&ect can have more than one instructor (perhaps this is not

a very realistic assumption). unctional dependencies therefore place

constraints on what information the database may store. In the above

e"ample, one may be wondering if the following (s hold

sname -> sno

cname -> cno

Certainly there is nothing in the instance of the e"ample database

presented above that contradicts the above functional dependencies.

)owever, whether above (s hold or not would depend on whether the

university or college whose database we are considering allows

duplicate student names and sub&ect names. If it was the enterprise

policy to have unique sub&ect names than cname -> cno holds. If

duplicate student names are possible, and one would thin$ there

always is the possibility of two students having e"actly the same

name, then sname -> sno does not hold.

unctional dependencies arise from the nature of the real world that

the database models. *ften A and B are facts about an entity where A

might be some identi+er for the entity and B some characteristic.

unctional dependencies cannot be automatically determined by

studying one or more instances of a database. FDs can be

determined only by a careful study of the real world and a

clear understanding of what each attribute means.

We have noted above that the de+nition of functional dependency does

not require that A and B be single attributes. In fact, A and B may be

collections of attributes. or e"ample

(sno, cno) -> (mark, date)

When dealing with a collection of attributes, the concept of full

functional dependence is an important one. %et A and B be distinct

collections of attributes from a relation R end let R.A -> R.B. B is then

fully functionally dependent on A if B is not functionally dependent on

any subset of A. The above e"ample of students and sub&ects would

show full functional dependence if mark and date are not functionally

dependent on either student number ( sno) or sub&ect number ( cno)

alone. The implies that we are assuming that a student may have more

than one sub&ects and a sub&ect would be ta$en by many di,erent

students. urthermore, it has been assumed that there is at most one

enrolment of each student in the same sub&ect.

The above e"ample illustrates full functional dependence. )owever the

following dependence

(sno, cno) -> nstructor

is not full functional dependence because cno -> nstructor holds.

#s noted earlier, the concept of functional dependency is related to the

concept of candidate $ey of a relation since a candidate $ey of a

relation is an identi+er which uniquely identi+es a tuple and therefore

determines the values of all other attributes in the relation. Therefore

any subset X of the attributes of a relation R that satis+es the property

that all remaining attributes of the relation are functionally dependent

on it (that is, on X), then X is candidate $ey as long as no attribute can

be removed from X and still satisfy the property of functional

dependence. In the e"ample above, the attributes (sno, cno) form a

candidate $ey (and the only one) since they functionally determine all

the remaining attributes.

unctional dependence is an important concept and a large body of

formal theory has been developed about it. We discuss the concept of

closure that helps us derive all functional dependencies that are

implied by a given set of dependencies. *nce a complete set of

functional dependencies has been obtained, we will study how these

may be used to build normalised relations.

Closure

%et a relation R have some functional dependencies F speci+ed. The

closure of F (usually written as "#) is the set of all functional

dependencies that may be logically derived from F. *ften F is the set of

most obvious and important functional dependencies and "#, the

closure, is the set of all the functional dependencies including F and

those that can be deduced from F. The closure is important and may,

for e"ample, be needed in +nding one or more candidate $eys of the

relation.

or e"ample, the student relation has the following functional

dependencies

sno -> sname cno -> cname sno -> address cno -> nstructor

nstructor -> o!ce

%et these dependencies be denoted by F. The closure of F, denoted by

"#, includes F and all functional dependencies that are implied by F.

To determine "#, we need rules for deriving all functional

dependencies that are implied by F. # set of rules that may be used to

infer additional dependencies was proposed by #rmstrong in -./0.

These rules (or a"ioms) are a complete set of rules in that all possible

functional dependencies may be derived from them. The rules are'

1. Reflexivity Rule --- If X is a set of attributes and Y is a subset of X, then X -> Y

holds.

The re1e"ivity rule is the most simple (almost trivial) rule. It

states that each subset of X is functionally dependent on X.

2. Augmentation Rule --- If X -> Y holds and W is a set of attributes, then WX -> WY

holds.

The augmentation rule is also quite simple. It states that if Y is

determined by X then a set of attributes W and Y together will be

determined by W and X together. 2ote that we use the notation

WX to mean the collection of all attributes in W and X and write

WX rather than the more conventional (W, X) for convenience.

3. Transitivity Rule --- If X -> Y and Y -> Z hold, then X -> Z holds.

The transitivity rule is perhaps the most important one. It states

that if X functionally determines Y and Y functionally determines

Z then X functionally determines Z.

These rules are called Armstron!s A"ioms.

urther a"ioms may be derived from the above although the above

three a"ioms are sound and complete in that they do not generate any

incorrect functional dependencies (soundness) and they do generate

all possible functional dependencies that can be inferred from F

(completeness). 3ome of the most important additional a"ioms are'

1. Union Rule --- If X -> Y and X -> Z hold, then X -> YZ holds.

2. Decomposition Rule --- If X -> YZ holds, then so do X -> Y and X -> Z.

3. Pseudotransitivity Rule --- If X -> Y and WY -> Z hold then so does WX -> Z.

4ased on the above a"ioms and the functional dependencies speci+ed

for relation student, we may write a large number of functional

dependencies. 3ome of these are'

(sno, cno) -> sno (5ule -)

(sno, cno) -> cno (5ule -)

(sno, cno) -> (sname, cname) (5ule 6)

cno -> o!ce (5ule 7)

sno -> (sname, address) (8nion 5ule) etc.

*ften a very large list of dependencies can be derived from a given set

F since 5ule - itself will lead to a large number of dependencies. 3ince

we have seven attributes (sno, sname, address, cno, cname,

instructor, o#ce), there are -69 (that is, 6:/) subsets of these

attributes. These -69 subsets could form -69 values of X in functional

dependencies of the type $ -> %. *f course, each value of X will then

be associated with a number of values for Y ( Y being a subset of X)

leading to several thousand dependencies. These large number of

dependencies are not particularly helpful in achieving our aim of

normali;ing relations.

#lthough we could follow the present procedure and compute the

closure of to +nd all the functional dependencies, the computation

requires e"ponential time and the list of dependencies is often very

large and therefore not very useful. There are two possible approaches

that can be ta$en to avoid dealing with the large number of

dependencies in the closure. *ne is to deal with one attribute or a set

of attributes at a time and +nd its closure (i.e. all functional

dependencies relating to them). The aim of this e"ercise is to +nd what

attributes depend on a given set of attributes and therefore ought to

be together. The other approach is to +nd the minimal co$ers. We will

discuss both approaches brie1y.

#s noted earlier, we need not deal with the large number of

dependencies that might arise in a closure since often one is only

interested in determining closure of a set of attributes given a set of

functional dependencies. Closure of a set of attributes X is all the

attributes that are functionally dependent on X given some functional

dependencies F while the closure of F was all functional dependencies

that are implied by F. Computing the closure of a set of attributes is a

much simpler tas$ if we are dealing with a small number of attributes.

We will denote the closure of a set of attributes X given F by $#.

#n algorithm to determine the closure'

3tep - %et $# &- $

3tep 6 %et the ne"t dependency be A -> B. If A is in $# and B is not,

$# &- $#' B.

3tep 7 Continue step 6 until no new attributes can be added to $#

The result of the algorithm is equal to $#.

The above algorithm may also be used to remove redundant

dependencies. or e"ample, to chec$ if $ -> A is redundant, we +nd

closure of X without using $ -> A. If A is in $#, we can eliminate $ ->

A as redundant.

Consider the following relation

student(sno, sname, cno, cname).

We wish to determine the closure of (sno, cno). We have the following

functional dependencies.

sno -> sname

cno -> cname

We apply the above algorithm using $(c as the place holder for all the

attributes that have been found to be dependent on X so far.

%tep & !!! $# &- $, that is, $# &- (sno, cno)

%tep ' !!! Consider sno -> sname, since sno is in $# and sname is

not, we have

$# &- (sno, cno) # sname

%tep ( !!! Consider cno -> cname, since cno is in $# and cname is

not, we have

$# &- (sno, cno, sname) # cname

%tep ) !!! #gain, consider sno -> sname but this does not change $#

%tep * !!! #gain, consider cno -> cname but this does not change $#

Therefore $# = (sno, cno, sname, cname).

This shows that all the attributes in the relation student (sno, cno,

sname, cname) are dependent on (sno, cno) and therefore (sno, cno) is

a candidate $ey of the present relation. In this case, it is the only

candidate $ey.

3imilarly we may wish to investigate the closure of (sname, cname).

We will +nd that the closure of (sname, cname) is only (sname,

cname). Therefore these two attributes together cannot form the $ey

of the above relation.

We de+ne some further concepts about functional dependencies'

%et F1 and F2 be two sets of (s. The two (s are called equivalent if

- < 6. *f course, it is not always easy to test that the two sets are

equivalent since each of them may consist of hundreds of (s. *ne

way to carry out the chec$ing would be to ta$e each dependency $ ->

% in turn from - and c+eck if it is in 6,

3ometime the term F1 covers F2 and F2 covers F1 is used to denote

equivalence.

Minimal Functional

Dependencies

In discussing the concept of equivalent (s, it is useful to de+ne the

concept of minimal functional dependencies or minimal co$er which is

useful in eliminating unnecessary functional dependencies so that only

the minimal number of dependencies need to be enforced by the

system. The concept of minimal cover of F is sometimes called

-rreduci.e %et of F. To +nd the minimal cover of a set of functional

dependencies F, we transform F such that each ( in it that has more

than one attribute in the right hand side is reduced to a set of (s that

have only one attribute on the right hand side. This can be done easily

using the decomposition rule that we have already discussed. The

minimal cover of F is then a set of (s such that'

(a) every right hand side of each dependency is a single attribute=

(b) for no $ -> A in F is the set " - )$ -> A* equivalent to F=

(c) for no $ -> A in F and proper subset Z of X is " - )$ -> A* ' )+

-> A* equivalent to F.

5equirements (a), as already noted, can be met easily given any set of

dependencies F. 5equirement (b) guarantees that we cannot remove

any dependencies from F and still have a set of dependencies

equivalent to F or no attribute on the left hand side of a dependency is

redundant. 5equirement (c) ma$es sure that no dependencies may be

replaced by a dependency that involves a subset of the left hand side.

The concept of minimal set of dependencies is useful in normali;ation

as we shall discuss later. The minimal set may be considered a

standard or canonical form of (s with no redundancies that is

equivalent to F. 8nfortunately however the minimal cover is not

unique.

Compiled by 3.5.5oy

The script is only a supplement to the class room discussions.

- Lecture 37 Closest PairUploaded byLalith Krishnan
- rice strategy pptUploaded byapi-240909170
- Topic2050Uploaded byZeineb Ben Fatma
- apCompSci2009FRQ_q4Uploaded bylfaraone
- JAVA fileUploaded byNatalie Ngo
- C3921D_E-1.2_RevC_Electrical Schematic Wiring Diagram (Power System)_40546818Uploaded byUlilAnwar
- s970-burdickUploaded byRajkumar Mandal
- Mesh WarpingUploaded bykazem_mir
- MathematicsUploaded byanon-966077
- Motion Planning for Multiple Autonomous Vehicles: Best PhD Award Presentation at ITSC, 2014Uploaded byRahul Kala
- PhilUploaded byYogesh Kumar
- OverviewUploaded byAayush Patidar
- MichaelangeloUploaded byMh Nurul Huda
- artificial intelligence paperUploaded bygaganrism
- MIT6_034F10_quiz1_2007Uploaded byDerhel Teste
- Best First SearchUploaded byMiroslav Martvoň
- Decision Trees in Practice _ Coursera_programming_assignment-quiz.pdfUploaded bysleepyhollowinoz
- Nc02Uploaded bykiran
- MATH: Phone SpecialUploaded byIoannus de Verani
- maximizing the profit of a businessUploaded byapi-218867570
- 2016 fall final reviewUploaded byapi-262098224
- TWO PHASE RETRIAL QUEUEING SYSTEM WITH IMPATIENT CUSTOMERS, ADDITIONAL OPTIONAL SERVICE, SERVER BREAKDOWN, DELAYED REPAIR AND RESERVED TIMEUploaded byebenesarb
- Determining Optimal Testing Facility Locations for Mining Concentrations in Benguet Using Non-capacitated P-k Median ModelUploaded byKristine Joy Ruz Bravo
- WB-Mech_120_WS_03.2Uploaded byjesycuban
- Independent ThinkingUploaded byIvan Panev
- Geologic ModellingUploaded byAwab
- Code Design for Relay ChannelsUploaded bymayna91
- Addison-Wesley - Franklin G.F., Powell J.D., Workman M.L. - Digital Control of Dynamic Systems, 3EUploaded byvikasnar
- lecture02.pptUploaded byhoo
- Edit DistanceUploaded bybinodrit98

- Corporate Social ResponsibilityUploaded byNaman Verma
- Indian Institute of ManagementCalcuttaUploaded byNaman Verma
- Key FactorsUploaded byNaman Verma
- KMS-Week1Uploaded byNaman Verma
- ch06Uploaded byNaman Verma
- 13Uploaded byNaman Verma
- Corporate Social ResponsibilityUploaded byNaman Verma
- Backup and RecoveryUploaded byNaman Verma
- KittenUploaded byNaman Verma
- HTMLppt [Autosaved]Uploaded byNaman Verma
- Lecture Notes 01 Knowledge Management SystemsUploaded byNaman Verma
- BeraUploaded byNaman Verma
- Chapter 8Uploaded byNaman Verma
- KarnaUploaded byNaman Verma
- 34946012Uploaded byNaman Verma
- Part08 Fuzzy LogicUploaded byNaman Verma
- W4A_Paper_1Uploaded byNaman Verma
- SQL Basics IIUploaded byNaman Verma
- HandoutUploaded byNaman Verma
- 5....PersonalityUploaded byNaman Verma
- OS-IVUploaded byNaman Verma
- hris11Uploaded byNaman Verma
- Download FileUploaded byNaman Verma
- Csr at TiscoUploaded byNaman Verma
- Agro ProductsUploaded byNaman Verma
- SA8000 - Wikipedia, The Free EncyclopediaUploaded byNaman Verma
- Solver 2007Uploaded byNaman Verma
- Oracle Database Brief History4932 2Uploaded byNaman Verma
- OS-IUploaded byNaman Verma
- Distribution ChannelUploaded byNaman Verma