Query-by-Example (QBE)

QBE is both a query language and the name of a DB system including it. The system is
no longer in use, but the language is part of IBM's Query Management Facility (QMF).

Basic Structure
• QBE has ``two-dimensional'' syntax.
• Queries are expressed by example.
• Close correspondence with domain relational calculus
• Non-procedural.
• Queries are expressed using skeleton tables.
• User selects the skeletons needed.
• User fills in skeletons with example rows.
• An example row consists of constants and example elements which are really
domain variables.
• Domain variables are preceded by an underscore character.
• Constants appear without any qualification.

QBE Skeleton Tables for the Bank Example

Queries on One Relation

_ Find all loan numbers at the Perryridge branch.

• A P. before the variable causes printing. P. means print (display)

• duplicates are removed by default
• A P.ALL. prefix suppresses duplicate elimination.
• A P. in front of the row prints all attributes.
• The domain variable may be omitted if it is not used elsewhere.
• Arithmetic expressions are allowed.
• Comparison operators are allowed, space on left hand side is left blank.
• _x is a variable (optional; can be omitted in above query)

Display full details of all loans

Method 1:

Method 2: Shorthand notation

Find the loan number of all loans with a loan amount of more than $700

Find names of all branches that are not located in Brooklyn

Find the loan numbers of all loans made jointly to Smith and Jones.

Find all customers who live in the same city as Jones

Queries on Several Relations

Find the names of all customers who have a loan from the Perryridge branch.

Find the names of all customers who have both an account and a loan at the bank.

Negation in QBE

Find the names of all customers whohave an account at the bank, but do not have a
loan from the bank.

¬ means “there does not exist”

Find all customers who have at least two accounts.

¬ means “not equal to”

The Condition Box

• Allows the expression of constraints on domain variables that are either

inconvenient or impossible to express within the skeleton tables.
• Complex conditions can be used in condition boxes.

Condition Box

E.g. Find the loan numbers of all loans made to Smith, to Jones, or to both jointly

QBE supports an interesting syntax for expressing alternative values

Find all account numbers with a balance between $1,300 and $1,500

Find all account numbers with a balance between $1,300 and 2,000 but not exactly
$1,500.

Find all branches that have assets greater than those of at least one branch located
in Brooklyn
The Result Relation

Find the customer-name, account-number, and balance for all customers who have an
account at the Perryridge branch.
We need to:
• Join depositor and account.
• Project customer-name, account-number and balance.

To accomplish this we:

Create a skeleton table, called result, with attributes customer-name, account-

number, and balance.

The resulting query is:

Ordering the Display of Tuples

AO = ascending order; DO = descending order.

E.g. list in ascending alphabetical order all customers who have an account at the
bank
When sorting on multiple attributes, the sorting order is specified by including with each
sort operator (AO or DO) an integer surrounded by parentheses.
E.g. List all account numbers at the Perryridge branch in ascending alphabetic
order with their respective account balances in descending order.

Aggregate Operations

The aggregate operators are AVG, MAX, MIN, SUM, and CNT .
The above operators must be postfixed with “ALL” (e.g., SUM.ALL.or AVG.ALL._x) to
ensure that duplicates are not eliminated.

E.g. Find the total balance of all the accounts maintained at the Perryridge branch.

UNQ is used to specify that we want to eliminate duplicates

Find the total number of customers having an account at the bank.

Query Examples

Find the average balance at each branch.

The “G” in “P.G” is analogous to SQL’s group by construct

The “ALL” in the “P.AVG.ALL” entry in the balance column ensures that all balances
are considered
To find the average account balance at only those branches where the average
account balance is more than $1,200, we simply add the condition box:

Query Example

Find all customers who have an account at all branches located in Brooklyn.

Approach: for each customer, find the number of branches in Brooklyn at which they
have accounts, and compare with total number of branches in Brooklyn
QBE does not provide subquery functionality, so both above tasks have to be combined
in a single query.
Can be done for this query, but there are queries that require subqueries and cannot be
expressed in QBE.
In the query on the next page
CNT.UNQ.ALL._w specifies the number of distinct branches in Brooklyn. Note: The
variable _w is not connected to other variables in the query
CNT.UNQ.ALL._z specifies the number of distinct branches in Brooklyn at which
customer x has an account.
Modification of the Database – Deletion

Deletion of tuples from a relation is expressed by using D. command. In case where we

delete information in only some of the columns, null values, specified by –, are inserted.

Delete customer Smith

Delete the branch-city value of the branch whose name is “Perryridge”.

Deletion Query Examples

Delete all loans with a loan amount between $1300 and $1500.
For consistency, we have to delete information from loan and borrower tables
Delete all accounts at branches located in Brooklyn.

Modification of the Database – Insertion

Insertion is done by placing the I. operator in the query expression.

Insert the fact that account A-9732 at the Perryridge branch has a balance of $700.

Provide as a gift for all loan customers of the Perryridge branch, a new $200 savings
account for every loan account they have, with the loan number serving as the account
number for the new savings account.
Modification of the Database – Updates

Use the U. operator to change a value in a tuple without changing all values in the tuple.
QBE does not allow users to update the primary key fields.
Update the asset value of the Perryridge branch to $10,000,000.
 Data Integrity

The aim of data integrity is to specify rules that implicitly or explicitly define a consistent
database state or changes of state. These rules may include facilities like those provided
by most programming languages for declaring data types which constrain the user from
operations like comparing data of different data types and assigning a variable of one
type to another of a different type. This is done to stop the user from doing things that
generally do not make sense. In a DBMS, integrity constraints play a similar role.
Integrity constraints guard against accidental damage to the database, by ensuring that
authorized changes to the database do not result in a loss of data consistency.
The integrity constraints are necessary to avoid situations like the following:
1. Some data has been inserted in the database but it cannot be identified (that is, it is not
clear which object or entity the data is about).
2. A student is enrolled in a course but no data about him is available in the relation that
has information about students.
3. During a query processing, a student number is compared with a course number (this
should never be required).
4. A student quits the university and is removed from the student relation but is still
enrolled in a course.
Integrity constraints on a database may be divided into two types:
1. Static Integrity Constraints - these are constraints that define valid states of the data.
These constraints include designations of primary keys etc.
2. Dynamic Integrity Constraints - these are constraints that define side-effects of
various kinds of transactions (e.g. insertions and deletions).
1. Primary Keys
2. Domains
3. Foreign Keys and Referential Integrity
4. Nulls

Primary Keys
From the definition of candidate key, it should be clear that each relation must have at
least one candidate key even if it is the combination of all the attributes in the relation
since all tuples in a relation are distinct. Some relations may have more than one
candidate keys.
The primary key of a relation is an arbitrarily but permanently selected candidate key.
The primary key is important since it is the sole identifier for the tuples in a relation. Any
tuple in a database may be identified by specifying relation name, primary key and its
value. Also for a tuple to exist in a relation, it must be identifiable and therefore it must
have a primary key. The relational data model therefore imposes the following two
integrity constraints:
(a) no component of a primary key value can be null;
(b) attempts to change the value of a primary key must be carefully controlled.
The first constraint is necessary because if we want to store information about some
entity, then we must be able to identify it, otherwise difficulties are likely to arise. For
example, if a relation
CLASS (STUNO, LECTURER, CNO)
has (STUNO, LECTURER) as the primary key then allowing tuples like

3123 Null CP302

Null Smith CP302

is going to lead to ambiguity since the two tuples above may or may not be identical and
the integrity of the database may be compromised. Unfortunately most commercial
database systems do not support the concept of primary key and it would be possible to
have a database state when integrity of the database is violated.
The second constraint above deals with changing of primary key values. Since the
primary key is the tuple identifier, changing it needs very careful controls. Codd has
suggested three possible approaches:
Method 1
Only a select group of users be authorised to change primary key values.
Method 2
Updates on primary key values be banned. If it was necessary to change a primary key,
the tuple would first be deleted and then a new tuple with new primary key value but
same other values would be inserted. Of course, this does require that the old values of
attributes be remembered and be reinserted in the database.
Method 3
A different command for updating primary keys be made available. Making a distinction
in altering the primary key and another attribute of a relation would remind users that
care needs to be taken in updating primary keys.

Domains
Many commercial database systems do not provide facilities for specifying domains.
Domains could be specified as below:

Create Domain Name1 Char(10)

Create Domain Stuno Integer
Create Domain Name2 Char(10)
Etc.

Note that NAME1 and NAME2 are both character strings of length 10 but they now
belong to different (semantic) domains. It is important to denote different domains to
(a) Constrain unions, intersections, differences, and equijoins of relations.
(b) Let the system check if two occurrences of the same database value denote the same
real world object.
The constraint on union-compatibility and join-compatibility is important so that only
those operations that make sense are permitted. For example, a join on class number and
student number would make no sense even if both attributes are integers and the user
should not be permitted to carry out such operations (or at least be warned when it is
attempted).

Domain Constraints
All the values that appear in a column of a relation must be taken from the same domain.
A domain usually consists of the following components.

1. Domain Name
2. Meaning
3. Data Type
4. Size or length
5. Allowable values or Allowable range ( if applicable)

Entity Integrity
The Entity Integrity rule is so designed to assure that every relation has a primary key and
that the data values for the primary key are all valid. Entity integrity guarantees that every
primary key attribute is non null. No attribute participating in the primary key of a base
relation is allowed to contain nulls. Primary key performs unique identification function
in a relational model. Thus a null primary key performs the unique identification function
in a relation would be like saying that there are some entity that had no known identity.
An entity that cannot be identified is a contradiction in terms, hence the name entity
integrity.

Operational Constraints
These are the constraints enforced in the database by the business rules or real world
limitations. For example if the retirement age of the employees in a organization is 60,
then the age column of the employee table can have a constraint “Age should be less than
or equal to 60”. These kinds of constraints enforced by the business and the environment
are called operational constraints.

Null constraints
NOT NULL constraint restricts attributes to not allow NULL values.
NULL is a special value:
Many possible interpretations: value unknown, value inapplicable, Value withheld, etc.
Often used as the default value

Example:
INSERT INTO Student VALUES (135, ’Maggie’, NULL, NULL); or
INSERT INTO Student (SID, name) VALUES (135, ’Maggie’);
Foreign Keys and Referential Integrity
Some problems related to primary key arise because primary key value of a tuple may be
referred in many relations of the database. When a primary key is modified, each of
these references to a primary key must either be modified accordingly or be replaced by
NULL values. Only then we can maintain referential integrity.
The concept of foreign key is important since a relational database consists of relations
only (no pointers) and relationships between the relations are implicit, based on
references to primary keys of other relations. These references are called foreign keys.
A foreign key in a relation R is a set of attributes whose values are required to match
those of the primary key of some relation S.
In the following relation the supervisor number is a foreign key (it is the primary key of
employee)
employee (empno, empname, supervisor-no, dept)
In the following relation Class, student-num and lecturer-num are foreign keys since
they appear as primary keys in other relations (relations student and lecturer).
Class (student-num, lecturer-num, subject) student ( ) lecturer ( )
Foreign keys are the implicit references in a relational database. The following constraint
is called referential integrity constraint:
If a foreign key F in relation R matches the primary key P of relation S than every value
of F must either be equal to a value of P or be wholly null.
The justification for referential integrity constraint is simple. If there is a foreign key in a
relation (that is if the relation is referring to another relation) then its value must match
with one of the primary key values to which it refers. That is, if an object or entity is
being referred to, the constraint ensures the referred object or entity exists in the database.
In the relational model the association between the tables is defined using foreign keys.
The association between the SHIPMENT and ELEMENT tables is defined by including
the Symbol attribute as a foreign key in the SHIPMENT table. This implies that before
we insert a row in the SHIPMENT table, the element for that order must already exist in
the ELEMENT table.

A referential integrity constraint is a rule that maintains consistency among the rows
of two tables or relations. The rule states that if there is a foreign key in one relation,
either each of the foreign key value must match a primary key value in the other table
or else the foreign key value must be null.

When Should Constraints Be Checked?

• Usually they are checked for each modification statement.
• But sometimes deferred constraint checking is necessary.
 Functional Dependencies

Functional dependencies assume that a relational schema has attributes (A, B, C... Z) and that the
whole database is described by a single universal relation called R = (A, B, C, ..., Z). This
assumption means that every attribute in the database has a unique name.

What is functional dependency in a relation?

A functional dependency is a property of the 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.
Consider a relation with attributes A and B, where attribute B is functionally dependent on
attribute A. If we know the value of A and we examine the relation that holds this dependency, we
will find only one value of B in all of the tuples that have a given value of A, at any moment in
time. Note however, that for a given value of B there may be several different values of A.

B is functionally depend on A
A B

In the figure above, A is the determinant of B and B is the consequent of A.

The determinant of a functional dependency is the attribute or group of attributes on the left-hand
side of the arrow in the functional dependency. The consequent of a fd is the attribute or group of
attributes on the right-hand side of the arrow.

Identifying Functional Dependencies

STAFFBRANCH

Staff # Sname Position Salary Branch# Baddress

SL21 Kristy Manager 30000 B005 22 Deer
Road
SG37 Debris Assistant 12000 B003 162 Main
Street
SG14 Alan Supervisor 18000 B003 163 Main
Street
SA9 Traci Assistant 12000 B007 375 Fox
Avenue
SG5 David Manager 24000 B003 163 Main
Street
The functional dependency staff# → position clearly holds on this relation instance. However, the
reverse functional dependency position → staff# clearly does not hold.
The relationship between staff# and position is 1:1 – for each staff member there is only one
position. On the other hand, the relationship between position and staff# is 1:M – there are several
staff numbers associated with a given position.

Position is functionally dependent on Staff#

Staff# Position

Staff# is NOT functionally dependent on Position

Staff# Position
For the purposes of normalization we are interested in identifying functional dependencies
between attributes of a relation that have a 1:1 relationship.

When identifying Fds between attributes in a relation it is important to distinguish clearly between
the values held by an attribute at a given point in time and the set of all possible values that an
attributes may hold at different times.

In other words, a functional dependency is a property of a relational schema (its intension) and
not a property of a particular instance of the schema (extension).

The reason that we need to identify Fds that hold for all possible values for attributes of a relation
is that these represent the types of integrity constraints that we need to identify. Such constraints
indicate the limitations on the values that a relation can legitimately assume. In other words, they
identify the legal instances which are possible.
Let’s identify the functional dependencies that hold using the relation schema STAFFBRANCH
In order to identify the time invariant Fds, we need to clearly understand the semantics of the
various attributes in each of the relation schemas in question.
For example, if we know that a staff member’s position and the branch at which they are located
determines their salary. There is no way of knowing this constraint unless you are familiar with the
enterprise, but this is what the requirements analysis phase and the conceptual design phase are all
about!

staff# → sname, position, salary, branch#, baddress

branch# → baddress
baddress → branch#
branch#, position → salary
baddress, position → salary

Trivial Functional Dependencies

As well as identifying Fds which hold for all possible values of the attributes involved in the fd, we
also want to ignore trivial functional dependencies. A functional dependency is trivial if, the
consequent is a subset of the determinant. In other words, it is impossible for it not to be satisfied.
 Example: the trivial dependencies include:

{ staff#, sname} → sname

{ staff#, sname} → staff#

Although trivial Fds are valid, they offer no additional information about integrity constraints for
the relation. As far as normalization is concerned, trivial Fds are ignored.

Inference Rules for Functional Dependencies

F denotes, the set of functional dependencies that are specified on a relational schema R.
Typically, the schema designer specifies the Fds that are semantically obvious; usually however,
numerous other Fds hold in all legal relation instances that satisfy the dependencies in F.
These additional Fds that hold are those Fds which can be inferred or deduced from the Fds in F.
The set of all functional dependencies implied by a set of functional dependencies F is called the
closure of F and is denoted F+.

The notation: F  X → Y denotes that the functional dependency X → Y is implied by the set of
Fds F.

Formally, F+ ≡ {X → Y | F  X → Y}

A set of inference rules is required to infer the set of Fds in F+.

For example, if I tell you that Kristi is older than Debi and that Debi is older than Traci, you are able
to infer that Kristi is older than Traci. How did you make this inference? Without thinking about it or
maybe knowing about it, you utilized a transitivity rule to allow you to make this inference. The set
of all Fds that are implied by a given set S of Fds is called the closure of S, written S+. Clearly we
need an algorithm that will allow us to compute S+ from S. You know the first attack on this
problem appeared in a paper by Armstrong which gives a set of inference rules. The following are
the six well-known inference rules that apply to functional dependencies.

IR1: reflexive rule – if X ⊇ Y, then X →Y

IR2: augmentation rule – if X → Y, then XZ → YZ
IR3: transitive rule – if X → Y and Y→ Z, then X → Z
IR4: projection rule – if X→ YZ, then X → Y and X→ Z
IR5: additive rule – if X →Y and X →Z, then X →YZ
IR6: pseudo transitive rule – if X→ Y and YZ→ W, then XZ→ W

The first three of these rules (IR1-IR3) are known as Armstrong’s Axioms and constitute a necessary
and sufficient set of inference rules for generating the closure of a set of functional dependencies.

These rules can be stated in a variety of equivalent ways. Each of these rules can be directly proved
from the definition of functional dependency. Moreover the rules are complete, in the sense that,
given a set S of Fds, all Fds implied by S can be derived from S using the rules. The other rules are
derived from these three rules.

Given R = (A,B,C,D,E,F,G,H, I, J) and

F = {AB → E, AG → J, BE → I, E → G, GI → H}
Does F  AB → GH?

Proof
1. AB → E, given in F
2. AB → AB, reflexive rule IR1
3. AB → B, projective rule IR4 from step 2
4. AB → BE, additive rule IR5 from steps 1 and 3
5. BE → I, given in F
6. AB → I, transitive rule IR3 from steps 4 and 5
7. E → G, given in F
8. AB → G, transitive rule IR3 from steps 1 and 7
9. AB → GI, additive rule IR5 from steps 6 and 8
10. GI → H, given in F
11. AB → H, transitive rule IR3 from steps 9 and 10
12. AB → GH, additive rule IR5 from steps 8 and 11 - proven

Irreducible sets of dependencies

Let S1 and S2 be two sets of Fds, if every FD implied by S1 is implied by S2- i.e.; if S1+ is a subset
of S2+-we say that S2 is a cover for S1+(Cover here means equivalent set). What this means that if
the DBMS enforces the Fds in S2, then it will automatically be enforcing the Fds in S1.

Next if S2 is a cover for S1 and S1 is a cover for S2- i.e.; if S1+=S2+ -we say that S1 and S2 are
equivalent, clearly, if S1 and S2 are equivalent, then if the DBMS enforces the Fds in S2 it will
automatically be enforcing the Fds in S1, And vice versa.

Now we define a set of Fds to be irreducible( Usually called minimal in the literature) if and only if
it satisfies the following three properties

1. The right hand side (the dependent) of every Fds in S involves just one attribute (that is, it is
singleton set)

2. The left hand side (determinant) of every in S is irreducible in turn-meaning that no attribute can
be discarded from the determinant without changing the closure S+(that is, with out converting S
into some set not equivalent to S). We will say that such an Fd is left irreducible.

3. No Fd in S can be discarded from S without changing the closure S+(That is, without converting s
into some set not equivalent to S)

Relation R {A,B,C,D,E,F} satisfies the following Fds

AB → C
C →A
BC → D
ACD → B
BE → C
CE → FA
CF → VD
D →EF

Find an irreducible equivalent for this set of Fds?

The solution is simple. Let us find the solution for the above.

1. AB → C
2. C →A
3. BC → D
4. ACD → B
5. BE →C
6. CE → A
7. CE → F
8. CF → B
9. CF → D
10. D → E
11. D → F

Now:

• 2 implies 6, so we can drop 6

• 8 implies CF → BC (By augmentation), by which 3 implies CF → D (By Transitivity), so we can
drop 10.
• 8 implies ACF → AB (By augmentation), and 11 implies ACD → ACF (By augmentation), and
so ACD → AB (By Transitivity), and so ACD → B(By Decomposition), so we can drop 4

No further reductions are possible, and so we are left with the following irreducible set:
AB → C
C→A
BC → D
BE → C
CE → F
CF → B
D→E
D→F
Alternatively:
• 2 implies CD → ACD (By Composition), which with 4 implies CD → BE (By Transitivity),
so we can replace 4 CD → B
• 2 implies 6, so we can drop 6(as before)
• 2 and 10 implies CF → AD (By composition), which implies CF → ADC (By Augmentation),
which with (the original) 4 implies CF → B(By Transitivity), So we can drop 8.
No further reductions are possible, and so we are left with following irreducible set:
AB → C
C→A
BC → D
CD → B
BE → C
CE → F
CF → D
D→E
D→F
Observe, therefore, that there are two distinct irreducible equivalence for the original set of Fds.
 Concept Of redundancy (Updation Anomalies)

Analysis of Redundancies
A redundancy in a conceptual schema corresponds to a piece of information that can be
derived (that is, obtained through a series of retrieval operations) from other data in the
database.
Examples of Redundancies

Deciding About Redundancies

The presence of a redundancy in a database may be decided upon the following factors
An advantage: a reduction in the number of accesses necessary to obtain the derived
information;

A disadvantage: because of larger storage requirements, (but, usually at negligible

cost) and the necessity to carry out additional operations in order to keep the
derived data consistent.
The decision to maintain or delete a redundancy is made by comparing the cost of
operations that involve the redundant information and the storage needed, in the case of
presence or absence of redundancy.

Cost Comparison: An Example

The impact of redundancy with the help of an example.
Load and Operations for the Example
Numberofinhabitants

(1,1) (1,n)
Person Residence Town

In this schema the attribute Numberofinhabitants is redundant.

Table of volumes
Concept Type Volume
Town E 200
Person E 10 00 000
Residence R 10 00 000

Table of operation
Operation Type Frequency
Operation 1 1 500 per day
Operation 2 1 2 per day

Operation 1: adds a new person with a person’s town of residence.

Operation 2: print all the data of a town (including the number of inhabitants).

Table of Accesses, with Redundancy

Operation 1
Concept Type Accesses Type
Person Entity 1 W
Residence Relationship 1 W
Town Entity 1 W

Operation 2
Concept Type Accesses Type
Town Entity 1 R
Issues related to Redundancies (Anomalies)

The time has come to reveal the actual facts why normalization is needed. We will look
in to the matter in detail now.

The serious problem with using the relations is the problem of update anomalies. These
can be classified in to

Insertion anomalies

Deletion anomalies

Modification anomalies

Insertion Anomalies
An "insertion anomaly" is a failure to place information about a new database entry into
all the places in the database where information about that new entry needs to be stored.
In a properly normalized database, information about a new entry needs to be inserted
into only one place in the database; in an inadequately normalized database, information
about a new entry may need to be inserted into more than one place and, human fallibility
being what it is, some of the needed additional insertions may be missed.
This can be differentiated in to two types based on the following example

Emp_Dept
EName SSN BDate Address DNumber Dname DMGRSSN

Smith 123456789 1965-01-09 Kandivly 5 Research 333445555

Rajeev 333445555 1955-12-08 Vashi 5 Research 333445555

Geeta 999887777 1968-07-19 Sion 4 Admin 987654321

Rajesh 987654321 1941-06-20 Dadar 4 Admin 987654321

First Instance: - To insert a new employee tuple in to Emp_Dept table, we must include
either the attribute values for the department that the employee works for, or nulls (if the
employee does not work for a department as yet). For example to insert a new tuple for
an employee who works in department no 5, we must enter the attribute values of
department number 5 correctly so that they are consistent, with values for the department
5 in other tuples in emp_dept.
Second Instance: - It is difficult to insert a new department that has no employees as yet
in the emp_dept relation. The only way to do this is to place null values in the attributes
for the employee this causes a problem because SSN in the primary key of emp_dept
table and each tuple is supposed to represent an employee entity- not a department entity.
Moreover, when the first employee is assigned to that department, we do not need this
tuple with null values anymore.
Deletion Anomalies
A "deletion anomaly" is a failure to remove information about an existing database entry
when it is time to remove that entry. In a properly normalized database, information
about an old, to-be-gotten-rid-of entry needs to be deleted from only one place in the
database; in an inadequately normalized database, information about that old entry may
need to be deleted from more than one place, and, human fallibility being what it is, some
of the needed additional deletions may be missed.
The problem of deletion anomaly is related to the second insertion anomaly situation, if
we delete from emp_dept an employee tuple that happens to represent the last employee
working for a particular department, the information concerning that department is lost
from the database.
Modification Anomalies
In Emp_Dept, if we change the value of one of the attribute of a particular department-
say, the manager of department 5-we must update the tuples of all employees who work
in that department; other wise, the database will become inconsistent. If we fail to update
some tuples, the same department will be shown to have 2 different values for manager in
different employee tuple which would be wrong.
All three kinds of anomalies are highly undesirable, since their occurrence constitutes
corruption of the database. Properly normalized databases are much less susceptible to
corruption than are unnormalized databases.
Update Anomalies --- Redundant information not only wastes storage but makes updates
more difficult since, for example, changing the name of the instructor of CP302 would
require that all tuples containing CP302 enrolment information be updated. If for some
reason, all tuples are not updated, we might have a database that gives two names of
instructor for subject CP302. This difficulty is called the update anomaly.
Insertional Anomalies -- Inability to represent certain information --- Let the primary
key of the above relation be (sno, cno). Any new tuple to be inserted in the relation must
have a value for the primary key since existential integrity requires that a key may not be
totally or partially NULL. However, if one wanted to insert the number and name of a
new course in the database, it would not be possible until a student enrols in the course
and we are able to insert values of sno and cno. Similarly information about a new
student cannot be inserted in the database until the student enrols in a subject. These
difficulties are called insertion anomalies.
Deletion Anomalies -- Loss of Useful Information --- In some instances, useful
information may be lost when a tuple is deleted. For example, if we delete the tuple
corresponding to student 85001 doing CP304, we will loose relevant information about
course CP304 (viz. course name, instructor, office number) if the student 85001 was the
only student enrolled in that course. Similarly deletion of course CP302 from the
database may remove all information about the student named Jones. This is called
deletion anomalies.
 Normalization

Normalization is a formal process for determining which fields belong in which tables in
a relational database. Normalization follows a set of rules worked out at the time
relational databases were born. A normalized relational database provides several
benefits:
• Elimination of redundant data storage.
• Close modeling of real world entities, processes, and their relationships.
• Structuring of data so that the model is flexible.
• Normalization ensures that you get the benefits relational databases offer. Time
spent learning about normalization will begin paying for itself immediately.

Normalized Design: Pros and Cons

There are various advantages to producing a properly normalized design before you
implement your system. A detailed list of the pros and cons are given below:

Pros of Normalizing Cons of normalizing

• More efficient database structure. You can’t start building the database before
you know what the user needs.

• Better understanding of your data.

• More flexible data structure.
• Easier to maintain database
structure.
• Few (if any) costly surprises down
the road.
• Validates your common sense and
intuition. Avoid redundant fields.
• Ensures that distinct tables exist
when necessary.

1st Normal Form (1NF)

Def: A table (relation) is in 1NF if
1. There are no duplicated rows in the table.
2. Each cell is single-valued (i.e., there are no repeating groups).
3. Entries in a column (attribute, field) are of the same kind.
Note: The order of the rows is immaterial; the order of the columns is immaterial. The
requirement that there be no duplicated rows in the table means that the table has a key
(although the key might be made up of more than one column—even, possibly, of all the
columns).
A relation is in 1NF if and only if all underlying domains contain atomic values only.
The first normal form deals only with the basic structure of the relation and does not
resolve the problems of redundant information or the anomalies.
For example consider the following example relation:
student(sno, sname, dob) Add some other attributes so it has anomalies and is not in 2NF
The attribute dob is the date of birth and the primary key of the relation is sno with the
functional dependencies sno -> sname and eno → dob The relation is in 1NF as long as
dob is considered an atomic value and not consisting of three components (day, month,
year). The above relation of course suffers from all the anomalies and needs to be
normalized. (add example with date of birth)
A relation is in first normal form if and only if, in every legal value of that relation
every tuple contains one value for each attribute
The above definition merely states that the relations are always in first normal form
which is always correct. However the relation that is only in first normal form has a
structure those undesirable for a number of reasons.
First normal form (1NF) sets the very basic rules for an organized database:
• Eliminate duplicative columns from the same table.
• Create separate tables for each group of related data and identify each row with a
unique column or set of columns (the primary key).

2nd Normal Form (2NF)

Def: A table is in 2NF if it is in 1NF and if all non-key attributes are dependent on the
entire key.
The second normal form attempts to deal with the problems that are identified with the
relation above that is in 1NF. The aim of second normal form is to ensure that all
information in one relation is only about one thing.
A relation is in 2NF if it is in 1NF and every non-key attribute is fully dependent on
each candidate key of the relation.
Note: Since a partial dependency occurs when a non-key attribute is dependent on only a
part of the (composite) key, the definition of 2NF is sometimes phrased as, "A table is in
2NF if it is in 1NF and if it has no partial dependencies."
Recall the general requirements of 2NF:
• Remove subsets of data that apply to multiple rows of a table and place them in
separate rows.
• Create relationships between these new tables and their predecessors through the use of
foreign keys.
These rules can be summarized in a simple statement: 2NF attempts to reduce the amount
of redundant data in a table by extracting it, placing it in new table(s) and creating
relationships between those tables.
For example. Imagine an online store that maintains customer information in a database.
Their Customers table might look something like this:

CustNum FirstNam LastName Address City State ZIP

e

1 John Doe 12Main Sea Cliff NY 11579

Street

2 Alan Johnson 82 Sea Cliff NY 11579

Evergreen
Tr

3 Beth Thompson 1912 NE Miami FL 33157

Ist St

4 Jacob Smith 142 Irish South IN 46637

Way Bend

5 Sue Ryan 412 NE Ist Miami FL 33157

St

A brief look at this table reveals a small amount of redundant data. We're storing the "Sea
Cliff, NY 11579" and "Miami, FL 33157" entries twice each. Now, that might not seem
like too much added storage in our simple example, but imagine the wasted space if we
had thousands of rows in our table. Additionally, if the ZIP code for Sea Cliff were to
change, we'd need to make that change in many places throughout the database.
In a 2NF-compliant database structure, this redundant information is extracted and stored
in a separate table. Our new table (let's call it ZIPs) might look like this:

ZIP City State

11579 Sea Cliff NY
33157 Miami FL
46637 South Bend IN

If we want to be super-efficient, we can even fill this table in advance -- the post office
provides a directory of all valid ZIP codes and their city/state relationships. Surely,
you've encountered a situation where this type of database was utilized. Someone taking
an order might have asked you for your ZIP code first and then knew the city and state
you were calling from. This type of arrangement reduces operator error and increases
efficiency.
Now that we've removed the duplicative data from the Customers table, we've satisfied
the first rule of second normal form. We still need to use a foreign key to tie the two
tables together. We'll use the ZIP code (the primary key from the ZIPs table) to create
that relationship. Here's our new Customers table:

CustNum FirstName LastName Address ZIP

1 John Doe 12Main 11579

Street

2 Alan Johnson 82 Evergreen 11579

Tr

3 Beth Thompson 1912 NE Ist 33157

St

4 Jacob Smith 142 Irish 46637

Way

5 Sue Ryan 412 NE Ist St 33157

We've now minimized the amount of redundant information stored within the database
and the structure is in second normal form.
Let’s take one more example
The concept of 2NF requires that all attributes that are not part of a candidate key be fully
dependent on each candidate key. If we consider the relation
student (sno, sname, cno, cname)
and the functional dependencies
eno → ename
cno -> cname
and assume that (sno, cno) is the only candidate key (and therefore the primary key), the
relation is not in 2NF since sname and cname are not fully dependent on the key. The
above relation suffers from the same anomalies and repetition of information, since
sname and cname will be repeated. To resolve these difficulties we could remove those
attributes from the relation that are not fully dependent on the candidate keys of the
relations. Therefore we decompose the relation into the following projections of the
original relation:
S1 (sno, sname) S2 (cno, cname) SC (sno, cno)
Use an example that leaves one relation in 2NF but not in 3NF. We may recover the
original relation by taking the natural join of the three relations. If however we assume
that sname and cname are unique and therefore we have the following candidate keys
(sno, cno) (sno, cname) (sname, cno) (sname, cname)
The above relation is now in 2NF since the relation has no non-key attributes. The
relation still has the same problems as before but it then does satisfy the requirements of
2NF. Higher level normalization is needed to resolve such problems with relations that
are in 2NF and further normalization will result in decomposition of such relations

3rd Normal Form (3NF)

Def: A table is in 3NF if it is in 2NF and if it has no transitive dependencies.
The basic requirements of 3NF are as follows
• Meet the requirements of 1NF and 2NF
• Remove columns that are not fully dependent upon the primary key.
Although transforming a relation that is not in 2NF into a number of relations that are in
2NF removes many of the anomalies that appear in the relation that was not in 2NF, not
all anomalies are removed and further normalization is sometime needed to ensure further
removal of anomalies. These anomalies arise because a 2NF relation may have attributes
that are not directly related to the thing that is being described by the candidate keys of
the relation.
A relation R is in third normal form if it is in 2NF and every non-key attribute of R is
non-transitively dependent on each candidate key of R.
To understand the third normal form, we need to define transitive dependence which is
based on one of Armstrong's axioms. Let A, B and C be three attributes of a relation R
such that
A→ B and B→ C
From these FDs, we may derive A→ C , this dependence A→ C is transitive.
The 3NF differs from the 2NF in that all non-key attributes in 3NF are required to be
directly dependent on each candidate key of the relation. The 3NF therefore insists, in the
words of Kent (1983) that all facts in the relation are about the key (or the thing that the
key identifies), the whole key and nothing but the key. If some attributes are dependent
on the keys transitively then that is an indication that those attributes provide information
not about the key but about a non-key attribute. So the information is not directly about
the key, although it obviously is related to the key.
Consider the following relation
subject (cno, cname, instructor, office)
Assume that cname is not unique and therefore cno is the only candidate key. The
following functional dependencies exist
Eno → ename
Eno → instructor
Instructor → office
We can derive Eno → office from the above functional dependencies and therefore the
above relation is in 2NF. The relation is however not in 3NF since office is not directly
dependent on cno. This transitive dependence is an indication that the relation has
information about more than one thing (viz. course and instructor) and should therefore
be decomposed. The primary difficulty with the above relation is that an instructor might
be responsible for several subjects and therefore his office address may need to be
repeated many times. This leads to all the updation problems. To overcome these
difficulties we need to decompose the above relation in the following two relations:
s (cno, cname, instructor)
ins (instructor, office)
s is now in 3NF and so is ins.
An alternate decomposition of the relation subject is possible:
s(cno, cname)
inst(instructor, office)
si(cno, instructor)
The decomposition into three relations is not necessary since the original relation is based
on the assumption of one instructor for each course.
The 3NF is usually quite adequate for most relational database designs. There are
however some situations, for example the relation student(sno, sname, cno, cname) is in
2NF above, where 3NF may not eliminate all the redundancies and inconsistencies. The
problem with the relation student(sno, sname, cno, cname) is because of the redundant
information in the candidate keys. These are resolved by further normalization using the
BCNF.

Imagine that we have a table of widget orders:

Order Number Customer Unit Price Quantity Total

Number

1 241 $10 2 $20

2 842 $9 20 $180

3 919 $19 1 $19

4 919 $12 10 $120

Remember, our first requirement is that the table must satisfy the requirements of 1NF
and 2NF. Are there any duplicative columns? No. Do we have a primary key? Yes, the
order number. Therefore, we satisfy the requirements of 1NF. Are there any subsets of
data that apply to multiple rows? No, so we also satisfy the requirements of 2NF.
Now, are all of the columns fully dependent upon the primary key? The customer number
varies with the order number and it doesn't appear to depend upon any of the other fields.
What about the unit price? This field could be dependent upon the customer number in a
situation where we charged each customer a set price. However, looking at the data
above, it appears we sometimes charge the same customer different prices. Therefore, the
unit price is fully dependent upon the order number. The quantity of items also varies
from order to order.
What about the total? It looks like we might be in trouble here. The total can be derived
by multiplying the unit price by the quantity; therefore it's not fully dependent upon the
primary key. We must remove it from the table to comply with the third normal form:

Order Number Customer Number Unit Price Quantity

1 241 $10 2

2 842 $9 20

3 919 $19 1

4 919 $12 10

Now our table is in 3NF.

Boyce-Codd Normal Form (BCNF)

The relation student(sno, sname, cno, cname) has all attributes participating in candidate
keys since all the attributes are assumed to be unique. We therefore had the following
candidate keys:
(sno, cno)
(sno, cname)
(sname, cno)
(sname, cname)
Since the relation has no non-key attributes, the relation is in 2NF and also in 3NF, in
spite of the relation suffering the modification problems.
The difficulty in this relation is being caused by dependence within the candidate keys.
The second and third normal forms assume that all attributes not part of the candidate
keys depend on the candidate keys but does not deal with dependencies within the keys.
BCNF deals with such dependencies.
A relation R is said to be in BCNF if whenever X → A holds in R, and A is not in X,
then X is a candidate key for R.

It should be noted that most relations that are in 3NF are also in BCNF. Infrequently, a
3NF relation is not in BCNF and this happens only if
(a) the candidate keys in the relation are composite keys (that is, they are not single
attributes),
(b) there is more than one candidate key in the relation, and (c) the keys are not disjoint,
that is, some attributes in the keys are common.

The BCNF differs from the 3NF only when there are more than one candidate keys and
the keys are composite and overlapping. Consider for example, the relationship
enrol (sno, sname, cno, cname, date-enrolled)
Let us assume that the relation has the following candidate keys:
(sno, cno)
(sno, cname)
(sname, cno)
(sname, cname)
(we have assumed sname and cname are unique identifiers). The relation is in 3NF but
not in BCNF because there are dependencies

sno → sname
eno → ename
where attributes that are part of a candidate key are dependent on part of another
candidate key. Such dependencies indicate that although the relation is about some entity
or association that is identified by the candidate keys e.g. (sno, cno), there are attributes
that are not about the whole thing that the keys identify. For example, the above relation
is about an association (enrolment) between students and subjects and therefore the
relation needs to include only one identifier to identify students and one identifier to
identify subjects. Providing two identifiers about students (sno, sname) and two keys
about subjects (cno, cname) means that some information about students and subjects
that is not needed is being provided. This provision of information will result in repetition
of information and the anomaliess. If we wish to include further information about
students and courses in the database, it should not be done by putting the information in
the present relation but by creating new relations that represent information about entities
student and subject.
These difficulties may be overcome by decomposing the above relation in the following
three relations:
(sno, sname)
(cno, cname)
(sno, cno, date-of-enrolment)
We now have a relation that only has information about students, another only about
subjects and the third only about enrolments. All the anomalies and repetition of
information have been removed.
So, a relation is said to be in the BCNF if and only if it is in the 3NF and every non-
trivial, left-irreducible functional dependency has a candidate key as its determinant. In
more informal terms, a relation is in BCNF if it is in 3NF and the only determinants are
the candidate keys.

Desirable properties of decompositions

So far our approach has consisted of looking at individual relations and checking if they
belong to 2NF, 3NF or BCNF. If a relation was not in the normal form that was being
checked for and we wished the relation to be normalized to that normal form so that some
of the anomalies can be eliminated, it was necessary to decompose the relation in two or
more relations. The process of decomposition of a relation R into a set of relations R1,R2,
…..Rn was based on identifying different components and using that as a basis of
decomposition. The decomposed relations R1,R2,…..Rn are projections of R and are of
course not disjoint otherwise the glue holding the information together would be lost.
Decomposing relations in this way based on a recognize and split method is not a
particularly sound approach since we do not even have a basis to determine that the
original relation can be constructed if necessary from the decomposed relations.
Desirable properties of decomposition are:
1. Attribute preservation
2. Lossless-join decomposition
3. Dependency preservation
4. Lack of redundancy

Attribute Preservation
This is a simple and an obvious requirement that involves preserving all the attributes that
were there in the relation that is being decomposed.

Lossless-Join Decomposition
We decomposed a relation intuitively. We need a better basis for deciding
decompositions since intuition may not always be correct. We illustrate how a careless
decomposition may lead to problems including loss of information.
Consider the following relation
enrol (sno, cno, date-enrolled, room-No., instructor)
Suppose we decompose the above relation into two relations enrol1 and enrol2 as
follows
enrol1 (sno, cno, date-enrolled)
enrol2 (date-enrolled, room-No., instructor)
There are problems with this decomposition but we wish to focus on one aspect at the
moment. Let an instance of the relation enrol be

Sno Cno Date-Enrolled Room-no. Instructor

830057 CP302 1FEB1984 MP006 Gupta
830057 CP303 1FEB1984 MP006 Jones
820159 CP302 10JAN1984 MP006 Gupta
825678 CP304 1FEB1984 CE122 Wilson
826789 CP305 15JAN1984 EA123 Smith

and let the decomposed relations enrol1 and enrol2 be:

Sno Cno Date-Enrolled

830057 CP302 1FEB1984
830057 CP303 1FEB1984
820159 CP302 10JAN1984
825678 CP304 1FEB1984
826789 CP305 15JAN1984

Date-Enrolled Room-no. Instructor

1FEB1984 MP006 Gupta
1FEB1984 MP006 Jones
10JAN1984 MP006 Gupta
1FEB1984 CE122 Wilson
15JAN1984 EA123 Smith

All the information that was in the relation enrol appears to be still available in enrol1
and enrol2 but this is not so. Suppose, we wanted to retrieve the student numbers of all
students taking a course from Wilson, we would need to join enrol1 and enrol2. The join
would have 11 tuples as follows:

Sno Cno Date-Enrolled Room-No. Instructor

830057 CP302 1FEB1984 MP006 Gupta
830057 CP302 1FEB1984 MP006 Jones
830057 CP303 1FEB1984 MP006 Gupta
830057 CP303 1FEB1984 MP006 Jones
830057 CP302 1FEB1984 CE122 Wilson
830057 CP303 1FEB1984 CE122 Wilson

(add further tuples ...)

The join contains a number of spurious tuples that were not in the original relation Enrol.
Because of these additional tuples, we have lost the information about which students
take courses from WILSON. (we have more tuples but less information because we are
unable to say with certainty who is taking courses from WILSON). Such decompositions
are called lossy decompositions.
A nonloss or lossless decomposition is that which guarantees that the join will result in
exactly the same relation as was decomposed.
We need to analyze why some decompositions are lossy. The common attribute in above
decompositions was Date-enrolled. The common attribute is the clue that gives us the
ability to find the relationships between different relations by joining the relations
together. If the common attribute is not unique, the relationship information is not
preserved. If each tuple had a unique value of Date-enrolled, the problem of losing
information would not have existed. The problem arises because several enrolments may
take place on the same date.
A decomposition of a relation R into relations R1,R2,…..Rn is called a lossless-join
decomposition (with respect to FDs F) if the relation R is always the natural join of the
relations R1,R2,…..Rn It should be noted that natural join is the only way to recover the
relation from the decomposed relations. There is no other set of operators that can
recover the relation if the join cannot. Furthermore, it should be noted when the
decomposed relations R1,R2,…..Rn are obtained by projecting on the relation R, for
example R1 by projection π(R) the relation R1 may not always be precisely equal to the
projection since the relation R1 might have additional tuples called the dangling tuples.
It is not difficult to test whether a given decomposition is lossless-join given a set of
functional dependencies F. We consider the simple case of a relation R being
decomposed into R1 and R2 . the decomposition is lossless-join, then one of the following
two conditions must hold
R1 ∩ R2 → R1– R2
R1 ∩ R2 → R2 – R1
That is, the common attributes in R1 and R2 must include a candidate key of either R 1 or
R2.

Dependency Preservation
It is clear that decomposition must be lossless so that we do not lose any information
from the relation that is decomposed. Dependency preservation is another important
requirement since a dependency is a constraint on the database and if X → Y holds than
we know that the two (sets) attributes are closely related and it would be useful if both
attributes appeared in the same relation so that the dependency can be checked easily.
Let us consider a relation R(A, B, C, D) that has the dependencies F that include the
following:

A→ B
A→C
etc

If we decompose the above relation into R1(A, B) and R2(B, C, D) the dependency A→C
cannot be checked (or preserved) by looking at only one relation. It is desirable that
decompositions be such that each dependency in F may be checked by looking at only
one relation and that no joins need be computed for checking dependencies. In some
cases, it may not be possible to preserve each and every dependency in F but as long as
the dependencies that are preserved are equivalent to F, it should be sufficient.

Let F be the dependencies on a relation R which is decomposed in relations R1,R2,….,Rn.

We can partition the dependencies given by F such that F1,F2,….,Fn. Fn are dependencies
that only involve attributes from relations R1,R2,….,Rn. If the union of dependencies F1
imply all the dependencies in F, then we say that the decomposition has preserved
dependencies, otherwise not.
If the decomposition does not preserve the dependencies F, then the decomposed
relations may contain relations that do not satisfy F or the updates to the decomposed
relations may require a join to check that the constraints implied by the dependencies still
hold.

Consider the following relation

sub(sno, instructor, office)
We may wish to decompose the above relation to remove the transitive dependency of
office on sno. A possible decomposition is
S1(sno, instructor)
S2(sno, office)
The relations are now in 3NF but the dependency instructor → office cannot be verified
by looking at one relation; a join of S1 and S2 is needed. In the above decomposition, it is
quite possible to have more than one office number for one instructor although the
functional dependency instructor → office does not allow it.

Lack of Redundancy

Lossless-join, dependency preservation and lack of redundancy not always possible with
BCNF. Lossless-join, dependency preservation and lack of redundancy is always possible
with 3NF.

Deriving BCNF
Given a set of dependencies F, we may decompose a given relation into a set of relations
that are in BCNF using the following algorithm. The algorithm consists of
(1) Find out the facts about the real world. (2) Reduce the list of functional relationships.
(3) Find the keys. (4) Combine related facts.
If there is any relation R that has a dependency A→ B and A is not a key, the relation
violates the conditions of BCNF and may be decomposed in AB and R - A. The relation
AB is now in BCNF and we can now check if R - A is also in BCNF. If not, we can apply
the above procedure again until all the relations are in fact in BCNF.

Multivalued dependencies
Several difficulties that can arise when an entity has multivalue attributes. It was because
in the relational model, if all of the information about such entity is to be represented in
one relation, it will be necessary to repeat all the information other than the multivalue
attribute value to represent all the information that we wish to represent. This results in
many tuples about the same instance of the entity in the relation and the relation having a
composite key (the entity id and the mutlivalued attribute). Of course the other option
suggested was to represent this multivalue information in a separate relation.
The situation of course becomes much worse if an entity has more than one multivalued
attributes and these values are represented in one relation by a number of tuples for each
entity instance such that every value of one the multivalued attributes appears with every
value of the second multivalued attribute to maintain consistency. The multivalued
dependency relates to this problem when more than one multivalued attributes exist.

Consider the following relation that represents an entity employee that has one
mutlivalued attribute proj:

emp (e#, dept, salary, proj)

normalization upto BCNF are based on functional dependencies; dependencies that apply
only to single-valued facts. For example, e#→ dept implies only one dept value for each
value of e#. Not all information in a database is single-valued, for example, proj in an
employee relation may be the list of all projects that the employee is currently working
on. Although e# determines the list of all projects that an employee is working on, eno→
proj is not a functional dependency.

Multivalued facts about an entity is represented by having a separate relation for that
multivalue attribute and then inserting a tuple for each value of that fact. This resulted in
composite keys since the multivalued fact must form part of the key.

The fourth and fifth normal forms deal with multivalued dependencies.

programmer (emp_name, qualifications, languages)

The above relation includes two multivalued attributes of entity programmer;

qualifications and languages. There are no functional dependencies.
The attributes qualifications and languages are assumed independent of each other. If we
were to consider qualifications and languages separate entities, we would have two
relationships (one between employees and qualifications and the other between
employees and programming languages). Both the above relationships are many-to-many
i.e. one programmer could have several qualifications and may know several
programming languages. Also one qualification may be obtained by several programmers
and one programming language may be known to many programmers.

The above relation is therefore in 3NF (even in BCNF) but it still has some
disadvantages. Suppose a programmer has several qualifications (B.Sc, Dip. Comp. Sc,
etc) and is proficient in several programming languages; how should this information be
represented? There are several possibilities.

Cmp name Qualifications Languages

Smith B.Sc Fortran
Smith B.Sc Cobol
Smith B.Sc Pascal
Smith Dip. CS Fortran
Smith Dip. CS Cobol
Smith Dip. CS Pascal

Cmp Name Qualification Language

Smith B.Sc NULL
Smith Dip. CS NULL
Smith NULL Fortran
Smith NULL Cobol
Smith NULL Pascal

Cmp Name Qualificatiom Language

Smith B.Sc Fortran
Smith Dip CS Cobol
Smith NULL Pascal

Other variations are possible (there is no relationship between qualifications and

programming languages). All these variations have some disadvantages. If the
information is repeated we face the same problems of repeated information and
anomalies as we did when second or third normal form conditions are violated. If there is
no repetition, there are still some difficulties with search, insertions and deletions. For
example, the role of NULL values in the above relations is confusing.
Also the candidate key in the above relations is (emp name, qualifications, language) and
existential integrity requires that no NULLs be specified. These problems may be
overcome by decomposing a relation like the one above as follows:
Cmp Name Qualifications
Smith B.Sc
Smith Dip. CS

Cmp Name Languages

Smith Fortran
Smith Cobol
Smith Pascal

The basis of the above decomposition is the concept of multivalued dependency (MVD).
Functional dependency A→ B relates one value of A to one value of B while multivalued
dependency A→→ B defines a relationship in which a set of values of attribute B are determined by a
single value of A.
The concept of multivalued dependencies was developed to provide a basis for
decomposition of relations like the one above. Therefore if a relation like enrolment(sno,
subject#) has a relationship between sno and subject# in which sno uniquely determines
the values of subject#, the dependence of subject# on sno is called a trivial MVD since
the relation enrolment cannot be decomposed any further. More formally, a MVD
X→→Y is called trivial MVD if either Y is a subset of X or X and Y together form the
relation R. The MVD is trivial since it results in no constraints being placed on the
relation. Therefore a relation having non-trivial MVDs must have at least three attributes;
two of them multivalued. Non-trivial MVDs result in the relation having some constraints
on it since all possible combinations of the multivalue attributes are then required to be in
the relation.
Let us now define the concept of multivalued dependency. The multivalued dependency
X→→Y is said to hold for a relation R(X, Y, Z) if for a given set of value (set of values if
X is more than one attribute) for attributes X, there is a set of (zero or more) associated
values for the set of attributes Y and the Y values depend only on X values and have no
dependence on the set of attributes Z.

In the example above, if there was some dependence between the attributes qualifications
and language, for example perhaps, the language was related to the qualifications
(perhaps the qualification was a training certificate in a particular language), then the
relation would not have MVD and could not be decomposed into two relations as abve. In
the above situation whenever X→→Y holds, so does X→→Z since the role of the
attributes Y and Z is symmetrical.

Consider two different situations.

(a) Z is a single valued attribute. In this situation, we deal with R(X, Y, Z) as before by
entering several tuples about each entity.
(b) Z is multivalued.
Now, more formally, X→→Y is said to hold for R(X, Y, Z) if t1 and t2 are two tuples in
R
that have the same values for attributes X and therefore with t1[x] = t2[x] then R also
contains tuples t3 and t4 (not necessarily distinct) such that

t1[x] = t2[x] = t3[x] = t4[x]

t3[Y] = t1[Y] and t3[Z] = t2[Z]
t4[Y] = t2[Y] and t4[Z] = t1[Z]

In other words if t1 and t2 are given by

t1 = [X, Y1, Z1], and
t2 = [X, Y2, Z2]

then there must be tuples t3 and t4 such that

t3 = [X, Y1, Z2], and
t4 = [X, Y2, Z1]

We are therefore insisting that every value of Y appears with every value of Z to keep the
relation instances consistent. In other words, the above conditions insist that Y and Z are
determined by X alone and there is no relationship between Y and Z since Y and Z appear
in every possible pair and hence these pairings present no information and are of no
significance. Only if some of these pairings were not present, there would be some
significance in the pairings.
Give example (instructor, quals, subjects) --- explain if subject was single valued;
otherwise all combinations must occur.
(Note: If Z is single-valued and functionally dependent on X then Z1 = Z2. If Z is
multivalue dependent on X then Z1 <> Z2).
The theory of multivalued dependencies in very similar to that for functional
dependencies. Given D a set of MVDs, we may find D+, the closure of D using a set of
axioms.

Multivalued Normalization --- Fourth Normal Form

Def: A table is in 4NF if it is in BCNF and if it has no multi-valued dependencies.
An example of Programmer(Emp name, qualification, languages) and problems that may
arise if the relation is not normalised further. The relation could be decomposed into
P1(Emp name, qualifications) and P2(Emp name, languages) to overcome these
problems. The decomposed relations are in fourth normal form (4NF).
A relation R is in 4NF if, whenever a multivalued dependency X→ Y holds then either
(a) the dependency is trivial, or (b) X is a candidate key for R.
The dependency X→→ Y in a relation R(X, Y) is trivial since they must hold for all R(X,
Y). Similarly (X,Y) →Z must hold for all relations R(X, Y, Z) with only three attributes.
In fourth normal form, we have a relation that has information about only one entity. If a
relation has more than one multivalue attribute, we should decompose it to remove
difficulties with multivalued facts.
Intuitively R is in 4NF if all dependencies are a result of keys. When multivalued
dependencies exist, a relation should not contain two or more independent multivalued
attributes. The decomposition of a relation to achieve 4NF would normally result in not
only reduction of redundancies but also avoidance of anomalies.

Fifth Normal Form

Def: A table is in 5NF, also called "Projection-Join Normal Form" (PJNF), if it is in 4NF
and if every join dependency in the table is a consequence of the candidate keys of the
table.
The normal forms discussed so far required that the given relation R if not in the given
normal form be decomposed in two relations to meet the requirements of the normal
form. In some rare cases, a relation can have problems like redundant information and
update anomalies because of it but cannot be decomposed in two relations to remove the
problems. In such cases it may be possible to decompose the relation in three or more
relations using the 5NF.
The fifth normal form deals with join-dependencies which is a generalisation of the
MVD. The aim of fifth normal form is to have relations that cannot be decomposed
further. A relation in 5NF cannot be constructed from several smaller relations.
A relation R satisfies join dependency (R1,R2,…..,Rn) if and only if R is equal to the join of
R1,R2,….,Rn where Ri are subsets of the set of attributes of R.
A relation R is in 5NF (or project-join normal form, PJNF) if for all join dependencies at
least one of the following holds.
(a) (R1,R2,…..,Rn) is a trivial join-dependency (that is, one of Ri is R)
(b) Every Ri is a candidate key for R.
An example of 5NF can be provided by the example below that deals with departments,
subjects and students.

Dept Subject Student

Comp Sc. CP1000 John Smith
Mathematics MA1000 John Smith
Comp Sc. CP2000 Arun Kumar
Comp Sc. CP3000 Reena Rani
Physics PH1000 Raymond Chew
Chemistry CH2000 Albert Garcia

The above relation says that Comp. Sc. offers subjects CP1000, CP2000 and CP3000
which are taken by a variety of students. No student takes all the subjects and no subject
has all students enrolled in it and therefore all three fields are needed to represent the
information.
The above relation does not show MVDs since the attributes subject and student are not
independent; they are related to each other and the pairings have significant information
in them. The relation can therefore not be decomposed in two relations
(dept, subject), and
(dept, student)
without loosing some important information. The relation can however be decomposed in
the following three relations
(dept, subject), and
(dept, student)
(subject, student)
and now it can be shown that this decomposition is lossless.
Domain-Key Normal Form (DKNF)
Def: A table is in DKNF if every constraint on the table is a logical consequence of the
definition of keys and domains.