DATABASE DESIGN AND MANAGEMENT

UNIT-III
RELATIONAL DATABASE DESIGN AND NORMALIZATION

SYLLABUS:

3.1 ER and EER-to-Relational mapping

3.2 Update anomalies
3.3 Functional Dependencies-Inference rules
3.4 Minimal cover
3.5 Properties of relational decomposition
3.6 Normalization Upto BCNF.
3.1 RELATIONAL DATABASE DESIGN USING ER-TO-RELATIONAL MAPPING:
3.1.1 ER-to-Relational Mapping:
ER diagram is a visual representation of data based on the ER model, and it describes how entities are
related to each other in the database.
We use the COMPANY database example to illustrate the mapping procedure.
Step 1: Mapping of Regular Entity Types
✓ For each regular (strong) entity type E in the ER schema, create a relation R that includes all the
simple attributes of E.
✓ Includes only the simple component attributes of a composite attribute. Choose one of the key
attributes of E as the primary key for R. If the chosen key of E is a composite, then the set of simple
attributes that form it will together form the primary key of R.
Step 2: Mapping of Weak Entity Types.
✓ For each weak entity type W in the ER schema with owner entity type E, create a relation R and
include all simple attributes (or simple components of composite attributes) of W as attributes of
R.
✓ In addition, include as foreign key attributes of R, the primary key attribute(s) of the relation(s) that
correspond to the owner entity type(s); this takes care of mapping the identifying relationship type
of W.
✓ The primary key of R is the combination of the primary key(s) of the owner(s) and the partial key
of the weak entity type W.
✓ If there is a weak entity type E2 whose owner is also a weak entity type E1, then E1 should be
mapped before E2 to determine its primary key first.
Step 3: Mapping of Binary 1:1 Relationship Types.
✓ For each binary 1:1 relationship type R in the ER schema, identify the relations S and T that
correspond to the entity types participating in R.
✓ There are three possible approaches: (1) the foreign key approach, (2) the merged relationship
approach, and (3) the cross reference or relationship relation approach.

Foreign key approach:

✓ Choose one of the relations—S, say—and include as a foreign key in S the primary key of T.
✓ It is better to choose an entity type with total participation in R in the role of S. Include all the
simple attributes (or simple components of composite attributes) of the 1:1 relationship type R as
attributes of S.

Merged relation approach:

✓ An alternative mapping of a 1:1 relationship type is to merge the two entity types and the
relationship into a single relation.
✓ This is possible when both participations are total, as this would indicate that the two tables will
have the exact same number of tuples at all times.

Cross-reference or relationship relation approach:

✓ The third option is to set up a third relation R for the purpose of cross-referencing the primary keys
of the two relations S and T representing the entity types. As we will see, this approach is required
for binary M: N relationships.
✓ The relation R is called a relationship relation (or sometimes a lookup table), because each tuple in
R represents a relationship instance that relates one tuple from Swith one tuple from T.

Step 4: Mapping of Binary 1: N Relationship Types.

✓ There are two possible approaches: (1) the foreign key approach and (2) the cross-reference or
relationship relation approach.
✓ The first approach is generally preferred as it reduces the number of tables.
The foreign key approach:
✓ For each regular binary 1: N relationship type R, identify the relation S that represents the
participating entity type at the N-side of the relationship type.
✓ Include as foreign key in S the primary key of the relation T that represents the other entity type
participating in R; we do this because each entity instance on the N-side is related to at most one
entity instance on the 1-side of the relationship type.
✓ Include any simple attributes (or simple components of composite attributes) of the 1: N
relationship type as attributes of S.

The relationship relation approach:

✓ An alternative approach is to use the relationship relation (cross-reference) option as in the third
option for binary 1:1 relationship.
✓ We create a separate relation R whose attributes are the primary keys of S and T, which will also
be foreign keys to S and T.
✓ The primary key of R is the same as the primary key of S.
✓ This option can be used if few tuples in S participate in the relationship to avoid excessive NULL
values in the foreign key.

Step 5: Mapping of Binary M: N Relationship Types.

✓ In the traditional relational model with no multivalued attributes, the only option for M: N
relationships is the relationship relation (cross-reference) option.
✓ For each binary M: N relationship type R, create a new relation S to represent R.
✓ Include as foreign key attributes in S the primary keys of the relations that represent the
participating entity types; their combination will form the primary key of S.
Step 6: Mapping of Multivalued Attributes.
✓ For each multivalued attribute A, create a new relation R.
✓ This relation R will include an attribute corresponding to A, plus the primary key attribute K—as
a foreign key in R—of the relation that represents the entity type or relationship type that has A as
a multivalued attribute.
✓ The primary key of R is the combination of A and K.
✓ If the multivalued attribute is composite, we include its simple components.

Step 7: Mapping of N-array Relationship Types:

✓ We use the relationship relation option. For each n-ary relationship type R, where n > 2, create a
new relationship relation S to represent R.
✓ Include as foreign key attributes in S the primary keys of the relations that represent the
participating entity types.
✓ The primary key of S is usually a combination of all the foreign keys that reference the relations
representing the participating entity types.

Discussion and Summary of Mapping for ER Model Constructs:

3.1.2 MAPPING EER MODEL CONSTRUCTS TO RELATIONS:

Mapping of Specialization or Generalization:

There are several options for mapping a number of subclasses that together form a specialization (or
alternatively, that are generalized into a superclass), such as the {SECRETARY, TECHNICIAN,
ENGINEER} subclasses of EMPLOYEE.

The two main options are to map the whole specialization into a single table, or to map it into multiple
tables. Within each option are variations that depend on the constraints on the specialization/generalization.

Step 8: Options for Mapping Specialization or Generalization. Convert each specialization with m
subclasses {S1, S2, …, Sm} and (generalized) superclass C, where the attributes of C are {k, a1, …, an}
and k is the (primary) key, into relation schemas.
MAPPING OF SHARED SUBCLASSES (MULTIPLE INHERITANCE):
A shared subclass, such as ENGINEERING_MANAGER is a subclass of several super classes, indicating
multiple inheritance. These classes must all have the same key attribute; otherwise, the shared subclass
would be modeled as a category (union type).

MAPPING OF CATEGORIES (UNION TYPES):

We add another step to the mapping procedure—step 9—to handle categories. A category (or union type)
is a subclass of the union of two or more super classes that can have different keys because they can be of
different entity types.
Step 9: Mapping of Union Types (Categories).
✓ For mapping a category whose defining super classes have different keys, it is customary to specify
a new key attribute, called a surrogate key, when creating a relation to correspond to the union type.
✓ The keys of the defining classes are different, so we cannot use any one of them exclusively to
identify all entities in the relation.

3.2UPDATE ANOMALIES:
Anomalies in the relational model refer to inconsistencies or errors that can arise when working with
relational databases, specifically in the context of data insertion, deletion, and modification.

These anomalies can be categorized into three types:

1. Insertion Anomalies
2. Deletion Anomalies
3. Update Anomalies.

Insertion Anomalies: These anomalies occur when it is not possible to insert data into a database because
the required fields are missing or because the data is incomplete.

For example, if a database requires that every record has a primary key, but no value is provided for a
particular record, it cannot be inserted into the database.

Deletion anomalies: These anomalies occur when deleting a record from a database and can result in the
unintentional loss of data.
For example, if a database contains information about customers and orders, deleting a customer record
may also delete all the orders associated with that customer.

Update anomalies: These anomalies occur when modifying data in a database and can result in
inconsistencies or errors.

For example, if a database contains information about employees and their salaries, updating an employee’s
salary in one record but not in all related records could lead to incorrect calculations and reporting.

FOR EXAMPLE:

Insertion Anomaly: If a tuple is inserted in referencing relation and referencing attribute value is not
present in referenced attribute, it will not allow insertion in referencing relation.

Example: If we try to insert a record in STUDENT_COURSE with STUD_NO =7, it will not allow it.

Deletion and Updating Anomaly: If a tuple is deleted or updated from referenced relation and the
referenced attribute value is used by referencing attribute in referencing relation, it will not allow deleting
the tuple from referenced relation.

Example: If we want to update a record from STUDENT_COURSE with STUD_NO =1, We have to update
it in both rows of the table. If we try to delete a record from STUDENT with STUD_NO =1, it will not
allow it.

REMOVAL OF ANOMALIES:
 ✓ These anomalies can be avoided or minimized by designing databases that adhere to the principles
of normalization.
✓ Normalization involves organizing data into tables and applying rules to ensure data is stored in a
consistent and efficient manner.
✓ By reducing data redundancy and ensuring data integrity, normalization helps to eliminate
anomalies and improve the overall quality of the database

According to E.F.Codd, who is the inventor of the Relational Database, the goals of Normalization include:

1. It helps in vacatingall the repeated data from the database.

2. It helps in removing undesirable deletion, insertion, and update anomalies.
3. It helps in making a proper and useful relationship between tables.

Advantages Anomalies in Relational Model

✓ Data Integrity: Relational databases enforce data integrity through various constraints such as
primary keys, foreign keys, and referential integrity rules, ensuring that the data is accurate and
consistent.
✓ Scalability: Relational databases are highly scalable and can handle large amounts of data without
sacrificing performance.
✓ Flexibility: The relational model allows for flexible querying of data, making it easier to retrieve
specific information and generate reports.
✓ Security: Relational databases provide robust security features to protect data from unauthorized
access.

Disadvantages of Anomalies in Relational Model

✓ Redundancy: When the same data is stored in various locations, a relational architecture may cause
data redundancy. This can result in inefficiencies and even inconsistent data.
✓ Complexity: Establishing and keeping up a relational database calls for specific knowledge and
abilities and can be difficult and time-consuming.
✓ Performance: Because more tables must be joined in order to access information, performance
may degrade as a database gets larger.
✓ Incapacity to manage unstructured data: Text documents, videos, and other forms of semi-
structured or unstructured data are not well-suited for the relational paradigm.
3.3 FUNCTIONAL DEPENDENCIES-INFERENCE RULES:
Functional Dependency:
✓ Describes the relationship between attributes in a relation.
✓ Functional dependency is a property of the meaning or semantics of the attributes in a relation. The
semantics indicate how attributes relate to one another, and specify the functional dependencies
between attributes.
✓ When a functional dependency is present, the dependency is specified as a constraint between the
attributes.

For example;
If A and B are attributes of relation R, B is functionally dependent on A (denoted A ® B), if each value of
A is associated with exactly one value of B. (A and B may each consist of one or more attributes.)

Functional Dependencies: An important concept associated with normalization is functional dependency,

which describes the relationship between attributes .
The functional dependency is a relationship that exists between two attributes. It typically exists between
the primary key and non-key attribute within a table.
X → Y
Characteristics of Functional Dependencies:
For the discussion on functional dependencies, assume that a relational schema has attributes (A, B, C, . .
., Z) and that the database is described by a single universal relation called R 5 (A, B, C, . . . , Z). This
assumption means that every attribute in the database has a unique name.
A Functional Dependency Diagram:

Types of Functional Dependencies in DBMS:

1) Multivalued Dependency
2) Trivial Functional Dependency
3) Non-Trivial Functional Dependency
4) Transitive Dependency
Multivalued Dependency—
✓ Multivalued dependency occurs in the situation where there are multiple independent multivalued
attributes in a single table.
✓ A multivalued dependency is a complete constraint between two sets of attributes in a relation. It
requires that certain tuples be present in a relation. Consider the following Multivalued
Dependency.

In this example, maf_year and color are independent of each other but dependent on car_model. In this
example, these two columns are said to be multi value dependent on car_model.
This dependence can be represented like this:
car_model ->maf_year
car_model-> color

Trivial Functional Dependency–

✓ The Trivial dependency is a set of attributes which are called trivial if the set of attributes are
included in that attribute.
✓ So, X -> Y is a trivial functional dependency if Y is a subset of X.

Consider this table with two columns Emp_id and Emp_name.

{Emp_id, Emp_name} ->Emp_id is a trivial functional dependency as Emp_id is a subset of
{Emp_id,Emp_name}.

Non-Trivial Functional Dependency–

✓ Functional dependency which is also known as a nontrivial dependency occurs when A->B holds
true where B is not a subset of A.
✓ In a relationship, if attribute B is not a subset of attribute A, then it is considered as a non-trivial
dependency.

(Company} -> {CEO} (if we know the Company, we knows the CEO name)
But CEO is not a subset of Company, and hence it’s non-trivial functional dependency.

Transitive Dependency– A Transitive Dependency is a type of functional dependency which happens

when “t” is indirectly formed by two functional dependencies.
{Company} -> {CEO} (if we know the company, we know its CEO’s name)
{CEO } -> {Age} If we know the CEO, we know the Age
Therefore according to the rule of rule of transitive dependency:
{Company} -> {Age} should hold, that makes sense because if we know the company name, we can know
his age.

Advantages of Functional Dependency:

1. Functional Dependency avoids data redundancy. Therefore, same data do not repeat at multiple
locations in that database
2. It helps you to maintain the quality of data in the database
3. It helps you to defined meanings and constraints of databases
4. It helps you to identify bad designs
5. It helps you to find the facts regarding the database design

Full functional dependency:

✓ An additional characteristic of functional dependencies that is useful for normalization is that their
determinants should have the minimal number of attributes necessary to maintain the functional
dependency with the attribute(s) on the right-handside. This requirement is called full functional
dependency.
✓ Indicates that if A and B are attributes of a relation, B is fully functionally dependent on A if B is
functionally dependent on A, but not on any proper subset of A.
✓ A functional dependency A ® B is a full functional dependency if removal of any attribute from A
results in the dependency no longer existing.
✓ A functional dependency A ® B is a partial dependency if there is some attribute that can be
removed from A and yet the dependency still holds.

Transitive dependency:
✓ There is an additional type of functional dependency called a transitive dependency,that we need
to recognize, because its existence in a relation can potentially cause the types of update anomaly.

Example of a transitive functional dependency:

➢ Consider the following functional dependencies within the StaffBranch relation shown:
staffNo ® sName, position, salary, branchNo, bAddress
branchNo ® bAddress
➢ The transitive dependency branchNo ® bAddress exists on staffNo via branchNo. In other words,
the staffNo attribute functionally determines the bAddress via the branchNoattribute and neither
branchNo nor bAddress functionally determines staffNo.

THE PURPOSE OF NORMALIZATION:

✓ A technique for producing a set of relations with desirable properties, given the data requirements
of an enterprise.
✓ The purpose of normalization is to identify a suitable set of relations that support the data
requirements of an enterprise.
The characteristics of a suitable set of relations include the following:
• The minimal number of attributes necessary to support the data requirements of the enterprise;
• Attributes with a close logical relationship (described as functional dependency) are found in the same
relation;
• Minimal redundancy, with each attribute represented only once, with the important exception of attributes
that form all or part of foreign keys.
• The benefits of using a database that has a suitable set of relations is that the database will be easier for
the user to access and maintain the data, and take up minimal storage space on the computer. The problems
associated with using a relation that is not appropriately normalized.

HOW NORMALIZATION SUPPORTS DATABASE DESIGN:

Normalization is a formal technique that can be used at any stage of database design. However, in this
section we highlight two main approaches for using normalization.
1. Approach 1 shows how normalization can be used as a bottom-up standalone database design
technique;
2. Approach 2 shows how normalization can be used as a validation technique to check the structure
of relations, which may have been created using a top-down approach such as ER modeling.
3. No matter which approach is used, the goal is the same; creating a set of well-designed relations
that meet the data requirements of the enterprise.
4. However, this limitation is not applicable when normalization is used as a validation technique
(Approach 2), as the database designer focuses on only part of the database, such as a single
relation, at any one time.
5. Therefore, no matter what the size or complexity of the database, normalization can be usefully
applied.
NORMALIZATION:
✓ Normalization is the process of organizing the data in the database.
✓ Normalization is used to minimize the redundancy from a relation or set of relations. It is also used
to eliminate undesirable characteristics like Insertion, Update, and Deletion Anomalies.
✓ Normalization divides the larger table into smaller and links them using relationships.
✓ The normal form is used to reduce redundancy from the database table.
✓ Normalization is often executed as a series of steps.
✓ Each step corresponds to a specific normal form that has known properties. As normalization
proceeds, the relations become progressively more restricted (stronger) in format and also less
vulnerable to update anomalies.
✓ For the relational data model, it is important to recognize that it is only First Normal Form (1NF)
that is critical in creating relations; all subsequent normal forms are optional.

Database Normal Forms

Here is a list of Normal Forms in SQL:
1. 1NF (First Normal Form)
2. 2NF (Second Normal Form)
3. 3NF (Third Normal Form)
4. BCNF (Boyce-Codd Normal Form)
5. 4NF (Fourth Normal Form)
6. 5NF (Fifth Normal Form)
7. 6NF (Sixth Normal Form)
Normalization Process Example: example, we assume that a client rents a given property only once and
cannot rent more than one property at any one time.
FIRST NORMAL FORM (1NF):
✓ The table will be in First Normal Form (1NF) if all the attributes of the table contain only atomic
values.
✓ We can also say that if a table holds the multivalued data items in attributes or composite values,
the relation cannot be in the first normal form. So, we need to make it the first normal form by
making the entries of the table atomic.
1. Unnormalized Form (UNF)– A table that contains one or more repeating groups.
2. First Normal Form (1NF) --A relation in which the intersection of each row and column contains
one and only one value.
Rules of 1st Normal Form:
✓ Each table should contain a single value.
✓ Each record needs to be unique.
SECOND NORMAL FORM (2NF):
A Relation will be in 2NF if it follows the following condition:
1. The table or relation should be in 1NF or First Normal Form.
2. All the non-prime attributes should be fully functionally dependent on the candidate key.
3. The table should not contain any partial dependency.
Rules of 2nd Normal Form:
✓ The table should be in 1NF.
✓ Primary Key does not functionally dependents on any subset of Candidate Key.

Example 14.10 Second Normal Form (2NF)

As shown in Figure 14.12, the ClientRental relation has the following functional dependencies:
fd1. clientNo, propertyNo ® rentStart, rentFinish (Primary key)
fd2 clientNo ® cName (Partial dependency)
fd3 propertyNo ® pAddress, rent, ownerNo, oName (Partial dependency)
fd4 ownerNo ® oName (Transitive dependency)
fd5 clientNo, rentStart ® propertyNo, pAddress, rentFinish,
rent, ownerNo, oName (Candidate key)
fd6 propertyNo, rentStart ® clientNo, cName, rentFinish (Candidate key)

THIRD NORMAL FORM (3NF):

The table will be in Third Normal Form (3NF) if it follows the given conditions:
✓ The table or relation should be in 2NF.
✓ A Transitive Dependency is that any non-prime attribute determines or depends on the other non-
prime attribute.
A relation is in 3NF if FD X determines Y ('X' -> 'Y') satisfies one of the following conditions:
1. If X -> Y is a trivial FD, i.e., Y is a subset of X.
2. If X -> Y, where X is a Super key.
3. If X -> Y, (Y - X) is a prime attribute.
Rules of 3rd Normal Form:
 ✓ The tables should be in 2NF.
✓ There will be no Transitive Dependency.

Example 14.11 Third Normal Form (3NF)

The functional dependencies for the Client, Rental, and PropertyOwner relations, derived
in Example 14.10, are as follows:

Client
fd2. clientNo ® cName (Primary key)
Rental
fd1 clientNo, propertyNo ® rentStart, rentFinish (Primary key)
fd5' clientNo, rentStart ® propertyNo, rentFinish (Candidate key)
fd6' propertyNo, rentStart ® clientNo, rentFinish (Candidate key)
PropertyOwner
fd3 propertyNo ® pAddress, rent, ownerNo, oName (Primary key)
fd4 ownerNo ® oName (Transitive dependency)

➢ To transform the PropertyOwner relation into 3NF, we must first remove this transitive dependency
by creating two new relations called PropertyForRent and Owner, as shown in Figure 14.15.
➢ The new relations have the following form:
PropertyForRent (propertyNo, pAddress, rent, ownerNo)
Owner (ownerNo, oName)
➢ The PropertyForRent and Owner relations are in 3NF, as there are no further transitive
dependencies on the primary key.
Example: 1NF,2NF,3NF:

BCNF: It stands for Boyce Codd Normal form, which is the next version of 3NF. Sometimes, it is also
pronounced as 3.5 NF. A normal form is said to be in BCNF if it follows the given conditions:

1. A table or relation must be in 3NF.

2. If a relation R has functional dependencies (FD) and if A determines B, where A is a super Key,
the relation is in BCNF.

FOURTH NORMAL FORM (4 NF): A relation is said to be Fourth Normal Form (4NF) if it follows the
given conditions:

1. A table must be in BCNF.

2. There should be no multivalued dependency in the table.
For example, if the dependency A -> B, for a single value of A, more than one value of B exists. Then the
relation is said to be a multivalued dependency.

Following is the condition for being multivalued dependency:

1. For a multivalued dependency A -> B, for a single value of A, there are multiple values of B.
2. If a table has at least three columns, they have a multivalued dependency.
3. For a relation with A, B and C columns, where B and C should be independent.

FIFTH NORMAL FORM (5 NF):

A relation is said to be 5NF if it follows the given conditions:
1. The table should be in 4NF.
2. There should not be Join Dependency or further non-loss decomposed.
3. It is also known as Project Join Normal Form (PJNF).

JOIN DEPENDENCY:
A relation (R) is said to be a Join dependency if the relation (R) schema can be divided into smaller sets of
tables R1, R2 … Rn that can be redesigned by joining multiple tables to the original table(R).
•General definition for Second Normal Form (2NF) --is a relation that is in first normal form and
everyone-candidate-key attribute is fully functionally dependent on any candidate key. In this definition, a
candidate-key attribute is part of any candidate key.
•General definition for Third Normal Form (3NF) --is a relation that is in first and second normal formin
which no non-candidate-key attribute is transitively dependent on any candidate key. In this definition, the
candidate-key attribute is part of any candidate key.

INFERENCE RULE (IR):

✓ Armstrong's axioms are the basic inference rule.
✓ Armstrong's axioms are used to conclude functional dependencies on a relational database.
✓ The inference rule is a type of assertion. It can apply to a set of FD (functional dependency) to
derive other FD.
✓ Using the inference rule, we can derive additional functional dependency from the initial set.

The Functional dependency has 6 types of inference rule:

(1) Reflexivity: If B is a subset of A, then A ® B
(2) Augmentation: If A ® B, then A, C ® B, C
(3) Transitivity: If A ® B and B ® C, then A ® C
(4) Self-determination: A ® A
(5) Decomposition: If A ® B, C, then A ® B and A ® C
(6) Union: If A ® B and A ® C, then A ® B, C
(7) Composition: If A ® B and C ® D then A, C ® B,D

1. Reflexive Rule (IR1)

✓ Reflexive Rule states that a set of attributes always determines any of its subsets or itself.
✓ Because these rules generate functional dependencies that are always true, such dependencies are
trivial and, as stated earlier, are generally not interesting or useful.
✓ In the reflexive rule, if Y is a subset of X, then X determines Y.
If X ⊇ Y then X → Y
Example:
X = {a, b, c, d, e}
Y = {a, b, c}

2. Augmentation Rule (IR2)

✓ (Augmentation) states that adding the same set of attributes to both the left-hand and right-hand
sides of a dependency results in another valid dependency.
✓ The augmentation is also called a partial dependency. In augmentation, if X determines Y, then XZ
determines YZ for any Z.
If X → Y then XZ → YZ
Example:
For R(ABCD), if A → B then AC → BC

3. Transitive Rule (IR3)

✓ (Transitivity) states that functional dependencies are transitive.
✓ In the transitive rule, if X determines Y and Y determines Z, then X must also determine Z.
If X → Y and Y → Z then X → Z

4. Union Rule (IR4)

✓ (Union) states that we can do the opposite: we can combine a set of dependencies A ® B, A ® C,
and A ® D into a single functional dependency A ® B, C, D.
✓ Union rule says, if X determines Y and X determines Z, then X must also determine Y and Z.
If X → Y and X → Z then X → YZ

Proof:
1. X → Y (given)
2. X → Z (given)
3. X → XY (using IR2 on 1 by augmentation with X. Where XX = X)
4. XY → YZ (using IR2 on 2 by augmentation with Y)
5. X → YZ (using IR3 on 3 and 4)

5. Decomposition Rule (IR5)

✓ (Decomposition) states that we can remove attributes from the right-hand side of a dependency.
Applying this rule repeatedly, we can decompose A ® B, C, D functional dependency into the set
of dependencies A ® B, A ® C, and A ® D.
✓ Decomposition rule is also known as project rule. It is the reverse of union rule.
✓ This Rule says, if X determines Y and Z, then X determines Y and X determines Z separately.
If X → YZ then X → Y and X → Z

Proof:
1. X → YZ (given)
2. YZ → Y (using IR1 Rule)
3. X → Y (using IR3 on 1 and 2)
6. Pseudo transitive Rule (IR6)
Rule 6 states that we can combine a set of nonoverlapping dependencies to form another valid dependency.
In Pseudo transitive Rule, if X determines Y and YZ determines W, then XZ determines W.
If X → Y and YZ → W then XZ → W

Proof:
1. X → Y (given)
2. WY → Z (given)
3. WX → WY (using IR2 on 1 by augmenting with W)
4. WX → Z (using IR3 on 3 and 2)

Each of the preceding inference rules can be proved from the definition of functional dependency, either
by direct proof or by contradiction. A proof by contradiction assumes that the rule does not hold and shows
that this is not possible. We now prove that the first three rules IR1 through IR3 are valid. The second proof
is by contradiction.

Proof of IR1. Suppose that X ⊇ Y and that two tuples t1 and t2 exist in some relation instance r of R such
that t1 [X] = t2 [X]. Then t1[Y] = t2[Y] because X ⊇ Y;
hence, X → Y must hold in r.

Proof of IR2 (by contradiction). Assume that X → Y holds in a relation instance r of R but that XZ →
YZ does not hold. Then there must exist two tuples t1and t2 in r such that (1) t1 [X] = t2 [X], (2) t1 [Y] =
t2 [Y], (3) t1 [XZ] = t2 [XZ], and (4) t1 [YZ] ≠ t2 [YZ]. This is not possible because from (1) and (3) we
deduce (5) t1 [Z] = t2 [Z], and from (2) and (5) we deduce (6) t1 [YZ] = t2 [YZ], contradicting (4).

Proof of IR3. Assume that (1) X → Y and (2) Y → Z both hold in a relation r. Then for any two tuples t1
and t2 in r such that t1 [X] = t2 [X], we must have (3) t1 [Y] = t2 [Y], from assumption (1); hence we must
also have (4) t1 [Z] = t2 [Z] from (3) and assumption (2); thus X → Z must hold in r.

There are three other inference rules that follow from IR1, IR2 and IR3. They are as follows:
1. IR4 (decomposition, or projective, rule): {X → YZ} |=X → Y.
2. IR5 (union, or additive, rule): {X → Y, X → Z} |=X → YZ.
3. IR6 (pseudo transitivity rule): {X → Y, WY → Z} |=WX → Z.

✓ The decomposition rule (IR4) says that we can remove attributes from the righthand side of a
dependency; applying this rule repeatedly can decompose the FD X → {A1, A2, …, An} into the
set of dependencies {X → A1, X → A2, …, X → An}.
✓ The union rule (IR5) allows us to do the opposite; we can combine a set of dependencies {X →
A1, X → A2, …, X → An} into the single FD X → {A1, A2, …, An}.
✓ The pseudo transitivity rule (IR6) allows us to replace a set of attributes Y on the lefthand side of
a dependency with another set X that functionally determines Y, and can be derived from IR2 and
IR3 if we augment the first functional dependency X → Y with W (the augmentation rule) and then
apply the transitive rule.
 ✓ One important cautionary note regarding the use of these rules: Although X → A and X → B
implies X → AB by the union rule stated above, X → A and Y → B does imply that XY → AB.
Also, XY → A does not necessarily imply either X → A or Y → A.

Proof of IR5 (using IR1 through IR3).

1. X →Y (given).
2. X → Z (given).
3. X → XY (using IR2 on 1 by augmenting with X; notice that XX = X).
4. XY → YZ (using IR2 on 2 by augmenting with Y).
5. X → YZ (using IR3 on 3 and 4).

Definition. For each such set of attributes X, we determine the set X+ of attributes that are functionally
determined by X based on F; X+ is called the closure of X under F.

Algorithm 15.1 can be used to calculate X+.

Algorithm 15.1. Determining X+, the Closure of X under F
Input: A set F of FDs on a relation schema R, and a set of attributes X, which is
a subset of R.
X+: = X;
repeat
oldX+: = X+;
for each functional dependency Y → Z in F do
if X+ ⊇ Y then X+: = X+ ∪ Z;
until (X+ = oldX+);

MINIMAL SETS OF FUNCTIONAL DEPENDENCIES:

✓ A minimal cover of a set of functional dependencies (FD) E is a minimal set of dependencies F that
is equivalent to E.
✓ Definition: An attribute in a functional dependency is considered an extraneous attribute if we can
remove it without changing the closure of the set of dependencies.
✓ Formally, given F, the set of functional dependencies, and a functional dependency X → A in F,
attribute Y is extraneous in X if Y ⊂ X, and F logically implies (F − (X → A) ∪ {(X − Y) → A} ).

The formal definition is: A set of FD F to be minimal if it satisfies the following conditions–
1. Every dependency in F has a single attribute for its right-hand side.
2. We cannot replace any dependency X->A in F with a dependency Y->A, where Y is a proper subset
of X, and still have a set of dependencies that is equivalent to F.
3. We cannot remove any dependency from F and still have a set of dependencies that are equivalent
to F.

Canonical cover is called minimal cover which is called the minimum set of FDs. A set of FD FC is called
canonical cover of F if each FD in FC is a −

1. Simple FD.
 2. Left reduced FD.
3. Non-redundant FD.

•Simple FD − X->Y is a simple FD if Y is a single attribute.

•Left reduced FD − X->Y is a left reduced FD if there are no extraneous attributes in X. {extraneous
attributes: Let XA->Y then, A is a extraneous attribute if X_>Y}
•Non-redundant FD − X->Y is a Non-redundant FD if it cannot be derived from F- {X->y}.

Example:
Consider an example to find canonical cover of F.

The given functional dependencies are as follows −

A -> BC
B -> C
A -> B
AB -> C

Minimal cover: The minimal cover is the set of FDs which are equivalent to the given FDs.
Canonical cover: In canonical cover, the LHS (Left Hand Side) must be unique.
First of all, we will find the minimal cover and then the canonical cover.

First step − Convert RHS attribute into singleton attribute.

A -> B
A -> C
B -> C
A -> B
AB -> C

Second step − Remove the extra LHS attribute

Find the closure of A.
A+ = {A, B, C}
So, AB -> C can be converted into A -> C
A -> B
A -> C
B -> C
A -> B
A -> C

Third step − Remove the redundant FDs.

A -> B
B -> C

Now, we will convert the above set of FDs into canonical cover.
The canonical cover for the above set of FDs will be as follows −
A -> BC
B -> C

Finding the Minimal Cover Given a set of functional dependencies F:

1. Start with F
2. Remove all trivial functional dependencies
3. Repeatedly apply (in whatever order you like), until no changes are possible• Union Simplification (it is
better to do it as soon as possible, wheneverpossible) • RHS Simplification• LHS Simplification.
4. Result is the minimal cover

Algorithm: Finding a Minimal Cover F for a Set of Functional Dependencies E

Input: A set of functional dependencies E.
Note: Explanatory comments are given at the end of some of the steps. They follow the format:
(*comment*).
1. Set F: = E.
2. Replace each functional dependency X → {A1, A2, …, An} in F by the functional dependencies X →A1,
X →A2, …, X → An. (*This places the FDs in a canonical form for subsequent testing*)
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.
(*This constitutes removal of an extraneous attribute B contained in the left-hand side X of a functional
dependency X → A when possible*)
4. For each remaining functional dependency X → A in F
if {F − {X → A} } is equivalent to F,then remove X → A from F. (*This constitutes removal of a
redundant functional dependency X → A from F when possible*)

Example 1: 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 of Algorithm 15.2 and can proceed to step 2.
In step 2 we need to determine if AB → D has any redundant (extraneous) 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
■ We now have a set equivalent to the 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 F: {B → D, D → A}.

EXAMPLE:
Identifying the minimal set of functional dependencies of the Staff-Branch relation
We apply the three conditions described previously on the set of functional dependencies
for the StaffBranch relation listed in Example 14.5 to produce the following functional dependencies:
staffNo ® sName
staffNo ® position
staffNo ® salary
staffNo ® branchNo
branchNo ® bAddress
bAddress ® branchNo
branchNo, position ® salary
bAddress, position ® salary

These functional dependencies satisfy the three conditions for producing a minimal set of functional
dependencies for the StaffBranch relation.
1. Condition 1 ensures that every dependency is in a standard form with a single attribute on the right-
hand side.
2. Conditions 2 and 3 ensure that there are no redundancies in the dependencies, either by having
redundant attributes on the left-hand side of a dependency (Condition 2) or by having a dependency
that can be inferred from the remaining functional dependencies in X (Condition 3).

BOYCE–CODD NORMAL FORM (BCNF):

✓ Application of the general definitions of 2NF and 3NF may identify additional redundancy caused
by dependencies that violate one or more candidate keys.
✓ However, despite these additional constraints, dependencies can still exist that will cause
redundancy to be present in 3NF rela-tions.
✓ This weakness in 3NF resulted in the presentation of a stronger normal form called Boyce–Codd
Normal Form (BCNF: Codd, 1974).

Definition of BCNF:
✓ BCNF is based on functional dependencies that take into account all candidate keys in a relation;
however, BCNF also has additional constraints compared with the general definition of 3NF.
✓ Boyce–Codd Normal Form (BCNF)--A relation is in BCNF if and only if every determinant is a
candidate key.

Rules for BCNF:

Rule 1: The table should be in the 3rd Normal Form.
Rule 2: X should be a super key for every functional dependency (FD) X−>Y in a given relation.
Note: To test whether a relation is in BCNF, we identify all the determinants and make sure that they are
candidate keys.
Example:
In this example, we extend the Dream Home case study to include a description of client interviews by
members of staff. The information relating to these interviews is in the Client Interview relation shown in
Figure 15.1.

The Client Interview relation has—-

➢ Three candidate keys: (clientNo, interviewDate), (staffNo, interviewDate, interviewTime), and
(roomNo, interviewDate, interviewTime).
The Client Interview relation has—-
➢ Three composite candidate keys, which overlap by sharing the common attribute interviewDate.
We select (clientNo, interviewDate) to act as the primary key for this relation.

The Client Interview relation has the following form:

Client Interview (clientNo, interviewDate. interviewTime, staffNo, roomNo)

The Client Interview relation has the following functional dependencies:

fd1 clientNo, interviewDate ® interviewTime, staffNo, roomNo (Primary key)
fd2 staffNo, interviewDate, interviewTime ® clientNo (Candidate key)
fd3 roomNo, interviewDate, interviewTime ® staffNo, clientNo (Candidate key)
fd4 staffNo, interviewDate ® roomNo
Figure 15.2. The Interview and StaffRoom relations have the following form:
Interview (clientNo, interviewDate, interviewTime, staffNo)
StaffRoom (staffNo, interviewDate, roomNo)

PROPERTIES OF RELATIONAL DECOMPOSITIONS:

✓ When a relation in the relational model is not in appropriate normal form then the decomposition
of a relation is required.
✓ In a database, it breaks the table into multiple tables.
✓ If the relation has no proper decomposition, then it may lead to problems like loss of information.
✓ Decomposition is used to eliminate some of the problems of bad design like anomalies,
inconsistencies, and redundancy.

Types of Decomposition

Lossless Decomposition:
✓ If the information is not lost from the relation that is decomposed, then the decomposition will be
lossless.
✓ The lossless decomposition guarantees that the join of relations will result in the same relation as
it was decomposed.
 ✓ The relation is said to be lossless decomposition if natural joins of all the decomposition give the
original relation.

Example:

The above relation is decomposed into two relations EMPLOYEE and DEPARTMENT:

DEPARTMENT table:

Now, when these two relations are joined on the common column "EMP_ID", then the resultant relation
will look like:
Employee ⋈ Department:
Hence, the decomposition is Lossless join decomposition.

Dependency Preserving:
✓ It is an important constraint of the database.
✓ In the dependency preservation, at least one decomposed table must satisfy every dependency.
✓ If a relation R is decomposed into relation R1 and R2, then the dependencies of R either must be a
part of R1 or R2 or must be derivable from the combination of functional dependencies of R1 and
R2.
✓ For example, suppose there is a relation R (A, B, C, D) with functional dependency set (A->BC).
The relational R is decomposed into R1(ABC) and R2(AD) which is dependency preserving
because FD A->BC is a part of relation R1(ABC).

Properties of Decomposition:
Decomposition must have the following properties:
1. Decomposition Must be Lossless
2. Dependency Preservation
3. Lack of Data Redundancy

1. Decomposition Must be Lossless–

Decomposition must always be lossless, which means the information must never get lost from a
decomposed relation. This way, we get a guarantee that when joining the relations, the join would
eventually lead to the same relation in the result as it was actually decomposed.

2. Dependency Preservation–
Dependency is a crucial constraint on a database, and a minimum of one decomposed table must satisfy
every dependency. If {P → Q} holds, then two sets happen to be dependent functionally. Thus, it becomes
more useful when checking the dependency if both of these are set in the very same relation. This property
of decomposition can be done only when we maintain the functional dependency. Added to this, this
property allows us to check various updates without having to compute the database structure’s natural join.

For example:
R = (A, B, C)
F = {A ->B, B->C}
Key = {A}
R is not in BCNF.
Decomposition R1 = (A, B), R2 = (B, C)

3. Lack of Data Redundancy–

It is also commonly termed as a repetition of data/information. According to this property, decomposition
must not suffer from data redundancy. When decomposition is careless, it may cause issues with the overall
data in the database. When we perform normalization, we can easily achieve the property of lack of data
redundancy.

NORMALIZATION UPTO BCNF:

Example 15.3 First normal form (1NF) to Boyce–Codd Normal Form (BCNF).
In this example we extend the DreamHome case study to include property inspection by members of
staff.Examples of the DreamHome Property Inspection Report are presented in Figure 15.3.

FIRST NORMAL FORM (1NF):

✓ We first transfer sample data held on two property inspection reports into table format with rows
and columns.
✓ This is referred to as the StaffPropertylnspection unnormalized table and is shown in Figure 15.4.
We identify the key attribute for this unnormalized table as propertyNo.We identify the repeating
group in the unnormalized table as the property inspection and staff details, which repeats for each
property.

The structure of the repeating group is:

Repeating Group 5 (iDate, iTime, comments, staffNo, sName, carReg)
The StaffPropertylnspection relation is defined as follows:
StaffPropertylnspection (propertyNo, iDate, iTime, pAddress, comments, staffNo, sName, carReg)
1. The StaffPropertylinspection relation is in 1NF, as there is a single value at the intersection of each
row and column.
2. The relation contains data describing the inspection of property by members of staff, with the
property and staff details repeated several times.
3. As a result, the StaffPropertylnspection relation contains significant redundancy. If implemented,
this INF relation would be subject to update anomalies.To remove some of these, we must
transform the relation into a second normal form.

SECOND NORMAL FORM (2NF):

✓ The normalization of INF relations to 2NF involves the removal of partial dependencies on the
primary key.
✓ If a partial dependency exists, we remove the functionally dependent attributes from the relation
by placing them in a new relation with a copy of their determinant.
As shown in Figure 15.6, the functional dependencies (fdl to fd6) of the StaffPropertylnspection relation
are as follows:
fd1 propertyNo, iDate ® iTime, comments, staffNo,
sName, carReg (Primary key)
fd2 propertyNo ® pAddress (Partial dependency)
fd3 staffNo ® sName (Transitive dependency)
fd4 staffNo, iDate ® carReg
fd5 carReg, iDate, iTime ® propertyNo, pAddress,
comments, staffNo, sName (Candidate key)
fd6 staffNo, iDate, iTime ® propertyNo, pAddress, comments (Candidate key)

➢ The StaffPropertylnspection relation is transformed into second normal form by removing the
partial dependency from the relation and creating two new relations called Property and
Propertylnspection with the following form:
Property (propertyNo, pAddress)
Propertylnspection (propertyNo, iDate, iTime, comments, staffNo, sName, carReg)
➢ These relations are in 2NF, as every non-primary-key attribute is functionally dependent on the
primary key of the relation.

THIRD NORMAL FORM (3NF):

✓ The normalization of 2NF relations to 3NF involves the removal of transitive dependencies.
✓ If a transitive dependency exists, we remove the transitively dependent attributes from the relation
by placing them in a new relation along with a copy of their determinant.
✓ The functional dependencies within the Property and Property inspection relations are as follows:

Property Relation
fd2 propertyNo ® pAddress
Property Inspection Relation
fd1 propertyNo, iDate ® iTime, comments, staffNo, sName, carReg
fd3 staffNo ® sName
fd4 staffNo, iDate ® carReg
fd5 carReg, iDate, iTime ® propertyNo, comments, staffNo, sName
fd6 staffNo, iDate, iTime ® propertyNo, comments

➢ To transform the Propertylnspection relation into 3NF, we remove the transitive dependency
(staffNo ® sName) by creating two new relations called Staff and Propertylnspect with the form:
Staff (staffNo, sName)
Propertylnspect (propertyNo, iDate, iTime, comments, staffNo, carReg)

➢ The Staff and PropertyInspect relations are in 3NF as no non-primary-key attribute is wholly
functionally dependent on another non-primary-key attribute.
➢ Thus, the StaffPropertylnspection relation shown in Figure 15.5 has been transformed by the
process of normalization into three relations in 3NF with the following form:
Property (propertyNo, pAddress)
Staff (staffNo, sName)
Propertylnspect (propertyNo, iDate, iTime, comments, staffNo, carReg)

BOYCE–CODD NORMAL FORM (BCNF):

✓ We now examine the Property, Staff, and PropertyInpsect relations to determine whether they are
in BCNF.
✓ Recall that a relation is in BCNF if every determinant of a relation is a candidate key.
✓ Therefore, to test for BCNF, we simply identify all the determinants and make sure they are
candidate keys.

The functional dependencies for the Property, Staff, and Propertylnspect relations are as follows:
Property Relation
fd2. propertyNo ® pAddress
Staff Relation
fd3 staffNo ® sName
Property Inspect Relation
fd1 propertyNo, iDate ® iTime, comments, staffNo, carReg
fd4 staffNo, iDate ® carReg
fd5 carReg, iDate, iTime ® propertyNo, comments, staffNo
fd6 staffNo, iDate, iTime ® propertyNo, comments

➢ To transform the Propertylnspect relation into BCNF, we must remove the dependency that violates
BCNF by creating two new relations called StaffCar and Inspection with the form:
StaffCar (staffNo, iDate, carReg)
Inspection (propertyNo, iDate, iTime, comments, staffNo)
➢ The StaffCar and Inspection relations are in BCNF, as the determinant in each of these relations
are also a candidate key.
The resulting BCNF relations have the following form:
Property (propertyNo, pAddress)
Staff (staffNo, sName)
Inspection (propertyNo, iDate, iTime, comments, staffNo)
StaffCar (staffNo, iDate, carReg)

FOURTH NORMAL FORM (4NF):

✓ Although BCNF removes any anomalies due to functional dependencies, further research led to the
identification of another type of dependency called a Multi-Valued Dependency (MVD),which can
also cause data redundancy (Fagin, 1977).
✓ In this section, we briefly describe a multi-valued dependency and the association of this type of
dependency with Fourth Normal Form (4NF).

MULTI-VALUED DEPENDENCY:
✓ The possible existence of multi-valued dependencies in a relation is due to 1NF, which disallows
an attribute in a tuple from having a set of values.
✓ For example, if we have two multi-valued attributes in a relation, we have to repeat each value of
one of the attributes with every value of the other attribute, to ensure that tuples of the relation are
consistent. This type of constraint is referred to as a multivalued dependency and results in data
redundancy.
✓ Multi-Valued Dependency (MVD)----Represents a dependency between attributes (for example,
A, B, and C) in a relation, such that for each value of A there is a set of values for B and a set of
values for C. However, the set of values for B and C are independent of each other. We represent
a MVD between attributes A, B, and C in a relation using the following notation:
A —>> B
A —>> C
✓ A multivalued dependency constraint potentially exists in the BranchStaffOwnerrelation, because
two independent 1: * relationships are represented in the same relation. We specify the MVD
constraint in the BranchStaffOwner relation shown in Figure 15.8(a) as follows:
branchNo —>>sName
branchNo —>>oName
 ✓ A multi-valued dependency can be further defined as being trivial or nontrivial. A MVD A —>>
B in relation R is defined as being trivial if (a) B is a subset of A or (b) A < B = R. A MVD is
defined as being non trivial if neither (a) nor (b) are satisfied. A trivial MVD does not specify a
constraint on a relation; a nontrivial MVD does specify a constraint.

Definition of Fourth Normal Form:

✓ Fourth Normal Form (4NF)---A relation is in 4NF if and only if for every nontrivial multivalued
dependency A —>> B, A is a candidate key of the relation.
✓ Fourth normal form (4NF) prevents a relation from containing a nontrivial MVD without the
associated determinant being a candidate key for the relation (Fagin, 1977).
✓ When the 4NF rule is violated, the potential for data redundancy exists, as shown previously in
Figure 15.8(a).
✓ The normalization of a relation breaking the 4NF rule requires the removal of the offending MVD
from the relation by placing the multi-valued attribute(s) in a new relation along with a copy of the
determinant.

FIFTH NORMAL FORM (5NF):

✓ Whenever we decompose a relation into two relations, the resulting relations have the lossless-join
property.
✓ This property refers to the ability to rejoin the resulting relations to produce the original relation.
However, there are cases in which there is a requirement to decompose a relation into more than
two relations. Although rare, these cases are managed by join dependency and Fifth Normal Form
(5NF).

LOSSLESS-JOIN DEPENDENCY:
✓ A property of decomposition that ensures that no spurious tuples are generated when relations are
reunited through a natural join operation.
✓ In splitting relations by projection, we are very explicit about the method of decomposition. In
particular, we are careful to use projections that can be reversed by joining the resulting relations,
so that the original relation is reconstructed.
✓ Such a decomposition is called a lossless-join (also called a non-loss- or non-additive-join)
decomposition, because it preserves all the data in the original relation and does not result in the
creation of additional spurious tuples.

Definition of Fifth Normal Form:

 ✓ Fifth Normal Form (5NF)--- Fifth normal form (5NF) prevents a relation from containing a
nontrivial join dependency (JD) without the associated projection including a candidate key of the
original relation (Fagin, 1977). Nontrivial JDs that are not associated with candidate keys are very
rare, so 4NF relations are normally also in 5NF.
✓ A relation is in 5NF if and only if for every join dependency (R1, R2, . . . Rn) in a relation R, each
projection includes a candidate key of the original relation.

To identify the type of constraint on the Property item Supplier relation in Figure 15.9(a), consider the
following statement:
If Property PG4 requires Bed (from data in tuple 1)
Supplier S2 supplies property PG4 (from data in tuple 2)
Supplier S2 provides Bed (from data in tuple 3)
Then Supplier S2 provides Bed for property PG4

This is an example of a type of update anomaly and we say that this relation contains a nontrivial join
dependency (JD) constraint.

Join dependency (JD):

✓ Describes a type of dependency. For example, for a relation R With subsets of the attributes of R
denoted as A, B, . . ., Z, a relation R satisfies a join dependency if and only if every legal value of
R is equal to the join of its projections on A, B, . . ., Z.
✓ As the PropertyltemSupplier relation contains a join dependency, it is therefore not in 5NF. To
remove the join dependency, we decompose the PropertyltemSupplierrelation into three 5NF
relations—namely, Propertyltem (R1), ItemSupplier (R2), and PropertySupplier (R3) relations—
as shown in Figure 15.10. We say that the PropertyltemSupplier relation with the form (A, B, C)
satisfies the join dependency JD (R1(A, B), R2(B, C), R3(A, C)).
**It is important to note that performing a natural join on any two relations will produce spurious tuples;
however, performing the join on all three will recreate the original PropertyltemSupplierrelation. **

*************************************************************************************