DBMS

(DATABASE MANAGEMENT SYSTEM)

II Year ,IV Sem
 Integrity Constraints
•Integrity constraints are a set of rules.
•Condition that is satisfied.
•It is used to maintain the quality of information.
• Integrity constraints ensure that the changes ,data
insertion, updating, and other processes have to be
performed in such a way that data integrity is not
affected.
•Thus, integrity constraint is used to guard against
accidental damage to the database.
•It is the rules that database is not permitted to
violate.
 Integrity Constraints..
•Integrity constraints used to ensure accuracy and
consistency of the data in a relational database,
•Constraints may apply to each attribute or they
may apply to the relationship between
tables(foreign key).
•Here changes made to the database by authorized
users donot result in a loss of data consistency.
•Example :- Blood Group:- A,B,AB,O not C D E
1. Domain constraints
•Domain constraints can be defined as the definition of a valid set of
values for an attribute.
•It defines domain only.
•The data type of domain includes string, character, integer, time,
date, currency, etc. The value of the attribute must be available in
the corresponding domain. Example is phone number has only 10
digits.

Example:-
2. Entity integrity constraints

•The entity integrity constraint states that primary key

value can't be null.
•This is because the primary key value is used to identify
individual rows in relation and if the primary key has a null
value, then we can't identify those rows.
•Entity integrity constraints will violate here.
•A table can contain a null value other than the primary
key field.
2. Entity integrity constraints…..

Example:-
 3. Referential Integrity Constraints

•A referential integrity constraint is specified between

two tables.

•In the Referential integrity constraints, if a foreign key

in Table 1 refers to the Primary Key of Table 2, then
every value of the Foreign Key in Table 1 must be null or
be available in Table 2.
3. Referential Integrity Constraints……
4. Key constraints

Keys are the entity set that is used to identify an

entity within its entity set uniquely.
An entity set can have multiple keys, but out of
which one key will be the primary key. A primary
key can contain a unique and null value in the
relational table.
Example:
 Functional Dependency
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
The left side of FD is known as a determinant, the right
side of the production is known as a dependent.
For example:
Assume we have an employee table with attributes:
Emp_Id, Emp_Name, Emp_Address.
 Functional Dependency…

Here Emp_Id attribute can uniquely identify the

Emp_Name attribute of employee table because if we
know the Emp_Id, we can tell that employee name
associated with it.

Functional dependency can be written as:

Emp_Id → Emp_Name

Here Emp_Name is functionally dependent on Emp_Id.

Types of Functional dependency
 1. Trivial functional dependency
A → B has trivial functional dependency if B is a subset of
A.
The following dependencies are also trivial like: A → A, B
→B

Consider a table with two columns Employee_Id and Empl

oyee_Name. {Employee_id, Employee_Name} → Empl
oyee_Id is a trivial functional dependency as Employee_I
d is a subset of {Employee_Id, Employee_Name}. Also, E
mployee_Id → Employee_Id and Employee_Name → E
mployee_Name are trivial dependencies too.
2. Non- Trivial functional dependency

A → B has a non-trivial functional dependency if B is not a

subset of A.
When A intersection B is NULL, then A → B is called as
complete non-trivial.
Example:
ID → Name,
Name → DOB
Inference Rule (IR):

➢The 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. Reflexive Rule (IR1)
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)
The augmentation is also called as 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)
In the transitive rule, if X determines Y and Y determine Z,
then X must also determine Z.
If X → Y and Y → Z then X → Z
4. Union Rule (IR4)
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 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 (IR 6)
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)
 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 the undesirable characteristics
like Insertion, Update and Deletion Anomalies.
❖Normalization divides the larger table into the smaller
table and links them using relationship.
❖The normal form is used to reduce redundancy from the
database table.
 Normalization
➢ This is the process which allows you to winnow out
redundant data within your database.
➢ This involves restructuring the tables to successively
meeting higher forms of Normalization.
➢ A properly normalized database should have the
following characteristics
1. Scalar values in each fields
2. Absence of redundancy.
3. Minimal use of null values.
4. Minimal loss of information.
 Levels of Normalization
Levels of normalization based on the amount of
redundancy in the database.
Various levels of normalization are:
1. First Normal Form (1NF)
2. Second Normal Form (2NF)

Redundancy

Number of Tables
3. Third Normal Form (3NF)

Complexity
4. Boyce-Codd Normal Form (BCNF)
5. Fourth Normal Form (4NF)
6. Fifth Normal Form (5NF)

Most databases should be 3NF or BCNF in order to avoid the database anomalies.
Levels of Normalization
1NF
2NF
3NF
4NF
5NF

Each higher level is a subset of the lower level

 First Normal Form (1NF)
➢A relation will be 1NF if it contains an atomic value.
➢It states that an attribute of a table cannot hold
multiple values. It must hold only single-valued
attribute.
➢First normal form disallows the multi-valued
attribute, composite attribute, and their combinations.
 First Normal Form (1NF)
A table is considered to be in 1NF if all the fields contain
only scalar values (as opposed to list of values).
Example (Not 1NF)
AuName & Auphone is not in 1NF

ISBN Title AuName AuPhone PubName PubPhone Price

0-321-32132-1 Balloon Sleepy, 321-321-1111, Small House 714-000-0000 $34.00

Snoopy, 232-234-1234,
Grumpy 665-235-6532

0-55-123456-9 Main Street Jones, 123-333-3333, Small House 714-000-0000 $22.95

Smith 654-223-3455
0-123-45678-0 Ulysses Joyce 666-666-6666 Alpha Press 999-999-9999 $34.00

1-22-233700-0 Visual Roman 444-444-4444 Big House 123-456-7890 $25.00

Basic

Author and AuPhone columns are not scalar

 1NF - Decomposition
1. Place all items that appear in the repeating group in a new
table
2. Designate a primary key for each new table produced.
3. Duplicate in the new table the primary key of the table from
which the repeating group was extracted or vice versa.
Example (1NF)

ISBN AuName AuPhone

0-321-32132-1 Sleepy 321-321-1111

ISBN Title PubName PubPhone Price 0-321-32132-1 Snoopy 232-234-1234

0-321-32132-1 Balloon Small House 714-000-0000 $34.00 0-321-32132-1 Grumpy 665-235-6532

0-55-123456-9 Main Street Small House 714-000-0000 $22.95 0-55-123456-9 Jones 123-333-3333

0-123-45678-0 Ulysses Alpha Press 999-999-9999 $34.00 0-55-123456-9 Smith 654-223-3455

1-22-233700-0 Visual Big House 123-456-7890 $25.00 0-123-45678-0 Joyce 666-666-6666

Basic
1-22-233700-0 Roman 444-444-4444
 Functional Dependencies
1. If one set of attributes in a table determines another
set of attributes in the table, then the second set of
attributes is said to be functionally dependent on the
first set of attributes.

Example 1

ISBN Title Price Table Scheme: {ISBN, Title, Price}

0-321-32132-1 Balloon $34.00 Functional Dependencies: {ISBN} → {Title}
0-55-123456-9 Main Street $22.95
{ISBN} → {Price}
0-123-45678-0 Ulysses $34.00

1-22-233700-0 Visual $25.00

Basic
 Functional Dependencies
Example 2
PubID PubName PubPhone Table Scheme: {PubID, PubName, PubPhone}
1 Big House 999-999-9999 Functional Dependencies: {PubId} → {PubPhone}
2 Small House 123-456-7890 {PubId} → {PubName}
3 Alpha Press 111-111-1111 {PubName, PubPhone} → {PubID}

Example 3

AuID AuName AuPhone

1 Sleepy 321-321-1111
Table Scheme: {AuID, AuName, AuPhone}
2 Snoopy 232-234-1234
Functional Dependencies: {AuId} → {AuPhone}
3 Grumpy 665-235-6532
{AuId} → {AuName}
4 Jones 123-333-3333
{AuName, AuPhone} → {AuID}
5 Smith 654-223-3455

6 Joyce 666-666-6666

7 Roman 444-444-4444
 Second Normal Form (2NF)
For a table to be in 2NF, there are two requirements
➢ The database is in first normal form
➢ All non-key attributes in the table must be functionally
dependent on the entire primary key
➢ The table should not contain any partial dependency.
Note: Remember that we are dealing with non-key attributes

Example 1 (Not 2NF)

Scheme → {Title, PubId, AuId, Price, AuAddress}
1. Key → {Title, PubId, AuId}
2. {Title, PubId, AuID} → {Price}
3. {AuID} → {AuAddress}
4. AuAddress does not belong to a key
5. AuAddress functionally depends on AuId which is a
subset of a key
 Second Normal Form (2NF)
Example 2 (Not 2NF)
Scheme → {City, Street, HouseNumber, HouseColor, CityPopulation}
1. key → {City, Street, HouseNumber}
2. {City, Street, HouseNumber} → {HouseColor}
3. {City} → {CityPopulation}
4. CityPopulation does not belong to any key.
5. CityPopulation is functionally dependent on the City which is a proper subset of
the key

Example 3 (Not 2NF)

Scheme → {studio, movie, budget, studio_city}
1. Key → {studio, movie}
2. {studio, movie} → {budget}
3. {studio} → {studio_city}
4. studio_city is not a part of a key
5. studio_city functionally depends on studio which is a proper subset of the key
 2NF - Decomposition
1. If a data item is fully functionally dependent on only a part of the
primary key, move that data item and that part of the primary key
to a new table.
2. If other data items are functionally dependent on the same part of
the key, place them in the new table also
3. Make the partial primary key copied from the original table the
primary key for the new table. Place all items that appear in the
repeating group in a new table
Example 1 (Convert to 2NF)
Old Scheme → {Title, PubId, AuId, Price, AuAddress}
New Scheme → {Title, PubId, AuId, Price}
New Scheme → {AuId, AuAddress}
 2NF - Decomposition
Example 2 (Convert to 2NF)
Old Scheme → {Studio, Movie, Budget, StudioCity}
New Scheme → {Movie, Studio, Budget}
New Scheme → {Studio, City}

Example 3 (Convert to 2NF)

Old Scheme → {City, Street, HouseNumber, HouseColor, CityPopulation}
New Scheme → {City, Street, HouseNumber, HouseColor}
New Scheme → {City, CityPopulation}
 Third Normal Form (3NF)
This form dictates that all non-key attributes of a table must be functionally
dependent on a candidate key i.e. there can be no interdependencies among
non-key attributes.

For a table to be in 3NF, there are two requirements

The table should be second normal form
No attribute is transitively dependent on the primary key
➢. The table or relation should be in 2NF.
➢It should not contain any transitive dependency. A Transitive Dependency is that
any non-prime attribute determines or depends on the other non-prime attribute.
➢It is used to reduce the data duplication. It is also used to achieve the data integrity.
➢If there is no transitive dependency for non-prime attributes, then the relation must
be in third normal form
Example (Not in 3NF)
Scheme → {Title, PubID, PageCount, Price }
1. Key → {Title, PubId}
2. {Title, PubId} → {PageCount}
3. {PageCount} → {Price}
4. Both Price and PageCount depend on a key hence 2NF
5. Transitively {Title, PubID} → {Price} hence not in 3NF
 Third Normal Form (3NF)
Example 2 (Not in 3NF)
Scheme → {Studio, StudioCity, CityTemp}
1. Primary Key → {Studio}
2. {Studio} → {StudioCity}
3. {StudioCity} → {CityTemp}
4. {Studio} → {CityTemp}
5. Both StudioCity and CityTemp depend on the entire key hence 2NF
6. CityTemp transitively depends on Studio hence violates 3NF

Example 3 (Not in 3NF)

Scheme → {BuildingID, Contractor, Fee} BuildingID Contractor Fee
1. Primary Key → {BuildingID} 100 Randolph 1200
2. {BuildingID} → {Contractor}
150 Ingersoll 1100
3. {Contractor} → {Fee}
4. {BuildingID} → {Fee} 200 Randolph 1200
5. Fee transitively depends on the BuildingID 250 Pitkin 1100
6. Both Contractor and Fee depend on the entire key hence 2NF
300 Randolph 1200
 3NF - Decomposition
1. Move all items involved in transitive dependencies to a new
entity.
2. Identify a primary key for the new entity.
3. Place the primary key for the new entity as a foreign key on the
original entity.

Example 1 (Convert to 3NF)

Old Scheme → {Title, PubID, PageCount, Price }
New Scheme → {PubID, PageCount, Price}
New Scheme → {Title, PubID, PageCount}
 3NF - Decomposition
Example 2 (Convert to 3NF)
Old Scheme → {Studio, StudioCity, CityTemp}
New Scheme → {Studio, StudioCity}
New Scheme → {StudioCity, CityTemp}

Example 3 (Convert to 3NF) BuildingID Contractor Contractor Fee

Old Scheme → {BuildingID, Contractor, Fee} 100 Randolph Randolph 1200

150 Ingersoll Ingersoll 1100
New Scheme → {BuildingID, Contractor}
200 Randolph Pitkin 1100
New Scheme → {Contractor, Fee} 250 Pitkin
300 Randolph
 Boyce-Codd Normal Form (BCNF)
BCNF does not allow dependencies between attributes that belong to candidate keys.
BCNF is a refinement of the third normal form in which it drops the restriction of a non-key
attribute from the 3rd normal form.
Third normal form and BCNF are not same if the following conditions are true:
The table has two or more candidate keys
At least two of the candidate keys are composed of more than one attribute
The keys are not disjoint i.e. The composite candidate keys share some attributes

•A table or relation must be in 3NF.

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

Example 1 - Address (Not in BCNF)

Scheme → {City, Street, ZipCode }
1. Key1 → {City, Street }
2. Key2 → {ZipCode, Street}
3. No non-key attribute hence 3NF
4. {City, Street} → {ZipCode}
5. {ZipCode} → {City}
6. Dependency between attributes belonging to a key
 Boyce Codd Normal Form (BCNF)
Example 2 - Movie (Not in BCNF)
Scheme → {MovieTitle, MovieID, PersonName, Role, Payment }
1. Key1 → {MovieTitle, PersonName}
2. Key2 → {MovieID, PersonName}
3. Both role and payment functionally depend on both candidate keys thus 3NF
4. {MovieID} → {MovieTitle}
5. Dependency between MovieID & MovieTitle Violates BCNF

Example 3 - Consulting (Not in BCNF)

Scheme → {Client, Problem, Consultant}
1. Key1 → {Client, Problem}
2. Key2 → {Client, Consultant}
3. No non-key attribute hence 3NF
4. {Client, Problem} → {Consultant}
5. {Client, Consultant} → {Problem}
6. Dependency between attributess belonging to keys violates BCNF
 BCNF - Decomposition
1. Place the two candidate primary keys in separate
entities
2. Place each of the remaining data items in one of the
resulting entities according to its dependency on the
primary key.
Example 1 (Convert to BCNF)
Old Scheme → {City, Street, ZipCode }
New Scheme1 → {ZipCode, Street}
New Scheme2 → {City, Street}
Loss of relation {ZipCode} → {City}
Alternate New Scheme1 → {ZipCode, Street }
Alternate New Scheme2 → {ZipCode, City}
 Decomposition – Loss of
Information
1. If decomposition does not cause any loss of information it is
called a lossless decomposition.
2. If a decomposition does not cause any dependencies to be lost it
is called a dependency-preserving decomposition.
3. Any table scheme can be decomposed in a lossless way into a
collection of smaller schemas that are in BCNF form. However
the dependency preservation is not guaranteed.
4. Any table can be decomposed in a lossless way into 3rd normal
form that also preserves the dependencies.
• 3NF may be better than BCNF in some cases

Use your own judgment when decomposing schemas

 BCNF - Decomposition
Example 2 (Convert to BCNF)
Old Scheme → {MovieTitle, MovieID, PersonName, Role, Payment }
New Scheme → {MovieID, PersonName, Role, Payment}
New Scheme → {MovieTitle, PersonName}

Loss of relation {MovieID} → {MovieTitle}

New Scheme → {MovieID, PersonName, Role, Payment}
New Scheme → {MovieID, MovieTitle}

We got the {MovieID} → {MovieTitle} relationship back

Example 3 (Convert to BCNF)
Old Scheme → {Client, Problem, Consultant}
New Scheme → {Client, Consultant}
New Scheme → {Client, Problem}
 Fourth Normal Form (4NF)
Fourth normal form eliminates independent many-to-one relationships
between columns.
To be in Fourth Normal Form,
a relation must first be in Boyce-Codd Normal Form.
a given relation may not contain more than one multi-valued attribute.
•A table must be in BCNF.
•There should be no multivalued dependency in the table.

Example (Not in 4NF)

Scheme → {MovieName, ScreeningCity, Genre)
Primary Key: {MovieName, ScreeningCity, Genre)
1. All columns are a part of the only candidate key, hence BCNF
2. Many Movies can have the same Genre Movie ScreeningCity Genre
3. Many Cities can have the same movie
Hard Code Los Angles Comedy
4. Violates 4NF
Hard Code New York Comedy

Bill Durham Santa Cruz Drama

Bill Durham Durham Drama

The Code Warrier New York Horror

 Fourth Normal Form (4NF)
Example 2 (Not in 4NF) Manager Child Employee
Scheme → {Manager, Child, Employee} Jim Beth Alice
1. Primary Key → {Manager, Child, Employee}
Mary Bob Jane
2. Each manager can have more than one child
Mary NULL Adam
3. Each manager can supervise more than one employee
4. 4NF Violated

Example 3 (Not in 4NF)

Scheme → {Employee, Skill, ForeignLanguage}
1. Primary Key → {Employee, Skill, Language }
2. Each employee can speak multiple languages
3. Each employee can have multiple skills
4. Thus violates 4NF

Employee Skill Language

1234 Cooking French

1234 Cooking German

1453 Carpentry Spanish

1453 Cooking Spanish

2345 Cooking Spanish
 4NF - Decomposition
1. Move the two multi-valued relations to separate tables
2. Identify a primary key for each of the new entity.

Example 1 (Convert to 3NF)

Old Scheme → {MovieName, ScreeningCity, Genre}
New Scheme → {MovieName, ScreeningCity}
New Scheme → {MovieName, Genre}

Movie Genre Movie ScreeningCity

Hard Code Comedy Hard Code Los Angles

Bill Durham Drama Hard Code New York

The Code Warrier Horror Bill Durham Santa Cruz

Bill Durham Durham

The Code Warrier New York

 4NF - Decomposition
Example 2 (Convert to 4NF) Manager Employee
Manager Child
Old Scheme → {Manager, Child, Employee} Jim Beth Jim Alice

New Scheme → {Manager, Child} Mary Bob Mary Jane

New Scheme → {Manager, Employee} Mary Adam

Example 3 (Convert to 4NF)

Old Scheme → {Employee, Skill, ForeignLanguage}
New Scheme → {Employee, Skill}
New Scheme → {Employee, ForeignLanguage}

Employee Skill Employee Language

1234 Cooking 1234 French

1453 Carpentry 1234 German

1453 Cooking 1453 Spanish

2345 Cooking 2345 Spanish

 Fifth Normal Form (5NF)
Fifth normal form is satisfied when all tables are broken into as
many tables as possible in order to avoid redundancy.
Once it is in fifth normal form it cannot be broken into
smaller relations without changing the facts or the
meaning.
•The table should be in 4NF.
•There should not be Join Dependency or further non-loss
decomposed.
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).
 Levels of Normalization
Normal Form
•1NF A relation is in 1NF if it contains an atomic value.
•2NF A relation will be in 2NF if it is in 1NF and all non-
key attributes are fully functional dependent on the
primary key.
•3NFA relation will be in 3NF if it is in 2NF and no
transition dependency exists.
•4NFA relation will be in 4NF if it is in Boyce Codd normal
form and has no multi-valued dependency.
•5NFA relation is in 5NF if it is in 4NF and not contains
any join dependency and joining should be lossless.