Inference Rules For Functional Dependencies: F (SSN (Ename, Bdate, Address, Dnumber)
Inference Rules For Functional Dependencies: F (SSN (Ename, Bdate, Address, Dnumber)
Definition:-
Formally, the set of all dependencies that include F as well as all dependencies that can be inferred
from F is called the closure of F; it is denoted by F+.
For example, suppose that we specify the following set F of obvious functional dependencies on
the relation schema,
F = {Ssn → {Ename, Bdate, Address, Dnumber},
Dnumber → {Dname, Dmgr_ssn} }
Some of the additional functional dependencies that we can infer from F are the following:
Ssn → {Dname, Dmgr_ssn}
Ssn → Ssn
Dnumber → Dname
To determine a systematic way to infer dependencies, we must discover a set of inference rules
that can be used to infer new dependencies from a given set of dependencies.
We use an abbreviated notation, concatenate attribute variables and drop the commas for
convenience.
Hence, the FD {X, Y} →Z is abbreviated to XY→Z, and the FD {X, Y, Z} → {U, V} is abbreviated
to XYZ → UV.
The following six rules IR1 through IR6 are well-known inference rules for functional
dependencies:
IR1 (reflexive rule) 1: If X ⊇ Y, then X→Y.
IR2 (augmentation rule) 2: {X→Y} |=XZ→YZ.
By complete, we mean that using IR1 through IR3 repeatedly to infer dependencies until no more
dependencies can be inferred results in the complete set of all possible dependencies that can be
inferred from F.
In other words, the set of dependencies F+, which we called the closure of F, can be determined
from F by using only inference rules IR1 through IR3. Inference rules IR1 through IR3 are known
as Armstrong’s inference rules.
Using above Algorithm we calculate the following closure sets with respect to F:
{Ssn} + = {Ssn, Ename}
{Pnumber} + = {Pnumber, Pname, Plocation}
{Ssn, Pnumber} + = {Ssn, Pnumber, Ename, Pname, Plocation, Hours}
***------------------------------------------------------***
***------------------------------------------------------***
2. Replace each functional dependency X→ A1, A2, ..., An} in F by the n functional
dependencies X→ A1, X→ A2, ..., X→ An.
3. For each functional dependency X→ A in F
for each attribute B that is an element of X
if { {F – {X→ A} } ∪ { (X – {B} ) → A} } is equivalent to F
then replace X→ A with (X – {B} ) →A in F.
4. For each remaining functional dependency X→ A in F
if {F – {X→A} } is equivalent to F,
then remove X→A from F.
Example:
Let the given set of FDs be E : {B→A, D→A, AB→D}.We have to find the minimal cover of E.
■ All above dependencies are in canonical form (that is, they have only one attribute on the right-
hand side), so we have completed step 1 and can proceed to step 2.
In step 2 we need to determine if AB→D has any redundant attribute on the left-hand side; that is,
can it be replaced by B→D or A→D?
Since B →A, by augmenting with B on both sides (IR2), we have BB →AB, or B→AB (i).
However, AB→D as given (ii).
■ Hence by the transitive rule (IR3), we get from (i) and (ii), B →D. Thus AB→D may be replaced
by B→D.
■ We now have a set equivalent to original E, say E_: {B→A, D→A, B→D}. No further reduction
is possible in step 2 since all FDs have a single attribute on the left-hand side.
■ In step 3 we look for a redundant FD in E_. By using the transitive rule on B →D and D →A, we
derive B →A. Hence B →A is redundant in E_ and can be eliminated.
■ Therefore, the minimal cover of E is {B→D, D→A}.
***------------------------------------------------------***
Definition :
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 of all the relations in D: *(πR1(r),
..., πRm(r)) = r.
Input: A universal relation R, a decomposition D = {R1, R2, ..., Rm} of R, and a set F of
functional dependencies.
Note: Explanatory comments are given at the end of some of the steps.
They follow the format: (* comment *).
1. Create an initial matrix S with one row i for each relation Ri in D, and one column j for each
attribute Aj in R.
2. Set S(i, j):= bij for all matrix entries. (* each bij is a distinct symbol associated with indices (i, j)
*).
3. For each row i representing relation schema Ri {for each column j representing attribute Aj
{if (relation Ri includes attribute Aj) then set S(i, j):= aj;};}; (* each aj is a distinct symbol
associated with index ( j) *).
4. Repeat the following loop until a complete loop execution results in no changes to S
{for each functional dependency X→Y in F {for all rows in S that have the same symbols in the
columns corresponding to attributes in X
{make the symbols in each column that correspond to an attribute in Y be the same in all these
rows as follows: If any of the rows has an a symbol for the column, set the other rows to that same
a symbol in the column. If no a symbol exists for the attribute in any of the rows, choose one of
the b symbols that appears in one of the rows for the attribute and set the other rows to that same b
symbol in the column ;} ; } ;};
5. If a row is made up entirely of a symbols, then the decomposition has the nonadditive join
property; otherwise, it does not.
Example:
***------------------------------------------------------***
5. Other Dependencies and Normal Forms
1. Inclusion Dependencies:
Inclusion dependencies were defined in order to formalize two types of inter-relational constraints:
■ The foreign key (or referential integrity) constraint cannot be specified as a functional or
■ The constraint between two relations that represent a class/subclass relationship also has no
formal definition in terms of the functional, multivalued, and join dependencies.
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 any specific time when r is a relation state
of R and s a relation state of S,
we must have
πX(r(R)) ⊆ πY(s(S))
We can specify the following inclusion dependency from above fig. 15.1
2. Template Dependencies
Template dependencies provide a technique for representing constraints in relations that typically
have no easy and formal definitions. No matter how many types of dependencies we develop,
some peculiar constraint may come up based on the semantics of attributes within relations that
cannot be represented by any of them. The idea behind template dependencies is to specify a
template—or example—that defines each constraint or dependency.
A template consists of a number of hypothesis tuples that are meant to show an example of the
tuples that may appear in one or more relations. The other part of the template is the template
conclusion.
- For tuple-generating templates, the conclusion is a set of tuples that must also exist in the
relations if the hypothesis tuples are there.
- For constraint-generating templates, the template conclusion is a condition that must hold
on the hypothesis tuples. Using constraint generating templates, we are able to define
semantic constraints—those that are beyond the scope of the relational model in terms of
its data definition language and notation.
There is no hard-and-fast rule about defining normal forms only up to 5NF. Historically, the
process of normalization and the process of discovering undesirable dependencies were carried
through 5NF, but it has been possible to define stricter normal forms that take into account
additional types of dependencies and constraints.
The idea behind domain-key normal form (DKNF) is to specify (theoretically, at least) the
ultimate normal form that takes into account all possible types of dependencies and constraints. A
relation schema is said to be in DKNF if all constraints and dependencies that should hold on the
valid 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 of the appropriate domain and that every key
constraint is enforced.
However, because of the difficulty of including complex constraints in a DKNF relation,
its practical utility is limited, since it may be quite difficult to specify general integrity constraints.
For example, consider a relation CAR(Make, Vin#) (where Vin# is the vehicle identification
number) and another relation MANUFACTURE(Vin#, Country) (where Country is the country of
manufacture).
A general constraint may be of the 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.’
There is no simplified way to represent such constraints short of writing a procedure (or general
assertions) to test them. The procedure COMPUTE_TOTAL_PRICE above is an example of such
procedures needed to enforce an appropriate integrity constraint.
***------------------------------------------------------***
4th Normal Form (Fourth Normal form)
Multivalued dependencies are a conse- quence 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 relation into 1NF.
If we have two or more multivalued independent attributes in the same relation schema, we get
into a problem of having to repeat every value of one of the attributes with every value of the
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.
An employee may work on several projects and may have several dependents, and the employee’s
projects and dependents are independent of one another. To keep the relation state consistent, and
to avoid any spurious relationship between the two independent attributes, we must have a
separate tuple to represent every combination of an employee’s dependent and an employee’s
project.
two tuple t3 and t4 should also exist in r with the following properties,
where we use Z to denote (R – (X ∪ Y)):
= R. For example, the relation EMP_PROJECTS in Figure 15.15(b) has the trivial
MVD Ename →→ Pname. An MVD that satisfies neither (a) nor (b) is called a
nontrivial MVD. A trivial MVD will hold in any relation state r of R; it is called
triv- ial because it does not specify any significant or meaningful constraint on
R.
-------****-----
5th Normal Form (Fifth Normal form)
5th Normal Form also called as join dependency and project-join normal form, if it is present,
carry out a multiway decomposition into fifth normal form (5NF)
Definition:
A relation schema R is in fifth normal form (5NF) (or project-join normal form (PJNF)) with
respect to a set F of functional, multivalued, and join dependencies if, for every nontrivial join
dependency JD(R1, R2, ..., Rn) in
F+ (that is, implied by F), every Ri is a superkey of R.
***------------------------------------------------------***