Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Sets of Attributes - Database Design - Lecture Slides, Slides of Database Management Systems (DBMS)

This lecture slide is very easy to understand and very helpful to built a concept about the foundation of computers and Database Design.The key points in these slides are:Sets of Attributes, Functional Dependency, Determinant Set, Dependent Attribute, Express Constraints, Closure of Relation, Set of Rules, Reflexivity Rule, Augmentation Rule, Transitivity Rule, Theorems from Axioms

Typology: Slides

2012/2013

Uploaded on 04/27/2013

asavari
asavari 🇮🇳

4.7

(14)

94 documents

1 / 14

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Definition
A functional dependency is defined as a
constraint between two sets of attributes in a
relation from a database.
Given a relation R, a set of attributes X in R is
said to functionally determine another
attribute Y, also in R, (written X Y) if and
only if each X value is associated with at most
one Y value.
Docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe

Partial preview of the text

Download Sets of Attributes - Database Design - Lecture Slides and more Slides Database Management Systems (DBMS) in PDF only on Docsity!

Definition

A functional dependency is defined as a constraint between two sets of attributes in a relation from a database.

Given a relation R , a set of attributes X in R is said to functionally determine another attribute Y , also in R , (written XY ) if and only if each X value is associated with at most one Y value.

In other words….

X is the determinant set and Y is the dependent attribute. Thus, given a tuple and the values of the attributes in X , one can determine the corresponding value of the Y attribute.

Keys

Whereas a key is a set of attributes that uniquely identifies an entire tuple, a functional dependency allows us to express constraints that uniquely identify the values of certain attributes.

However, a candidate key is always a determinant, but a determinant doesn’t need to be a key.

Closure

Let a relation R have some functional dependencies F specified. The closure of F (usually written as F+ ) is the set of all functional dependencies that may be logically derived from F. Often F is the set of most obvious and important functional dependencies and F+ , 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 example, be needed in finding one or more candidate keys of the relation.

Axioms

Before we can determine the closure of the relation, Student, we need a set of rules.

Developed by Armstrong in 1974, there are six rules (axioms) that all possible functional dependencies may be derived from them.

Axioms Cont.

1. Reflexivity Rule --- If X is a set of attributes and

Y is a subset of X , then X → Y holds.

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.

3. Transitivity Rule --- If X → Y and Y → Z holds,

then X → Z holds.

Back to the Example

SNo SName CNo CName Addr Instr. Office

Based on the rules provided, the following dependencies can be derived.

(SNo, CNo) → SNo (Rule 1) -- subset (SNo, CNo) → CNo (Rule 1) (SNo, CNo) → (SName, CName) (Rule 2) -- augmentation CNo → office (Rule 3) -- transitivity SNo → (SName, address) (Union Rule) etc.

Too Many FDs

Using the first rule alone, from our example we have 2^7 = 128 subsets. This will further lead to many more functional dependencies. This defeats the purpose of normalizing relations. So what now?

One way is to deal with one attribute or a set of attributes at a time and find its closure (i.e. all functional dependencies relating to them). The aim of this exercise is to find what attributes depend on a given set of attributes and therefore ought to be together. Docsity.com

Back To Our Example

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

  • Step 1 --- X^c <- X , that is, X^c <- (SNo, CNo) Step 2 --- Consider SNo -> SName , since SNo is in X^c and SName is not, we have: X^c <- (SNo, CNo) + SName Step 3 --- Consider CNo -> CName , since CNo is in X^c and CName is not, we have: X^c <- (SNo, CNo, SName) + CName Step 4 --- Again, consider SNo -> SName but this does not change X^c. Step 5 --- Again, consider CNo -> CName but this does not change X^c.
  • Therefore X+ = X^c = (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 key of the present relation. In this case, it is the only candidate key.

Normal Form

  • Initially Codd (1972) presented three normal forms (1NF, 2NF and 3NF) all based on functional dependencies among the attributes of a relation. Later Boyce and Codd proposed another normal form called the Boyce-Codd normal form (BCNF). The fourth and fifth normal forms are based on multi- value and join dependencies and were proposed later.
  • The primary objective of normalization is to avoid anomalies.