CS3492 – DATABASE MANAGEMENT SYSTEMS

ACADEMIC YEAR 2024-2025 (EVEN)

Department of Computer Science and Engineering

UNIT-II - DATABASE DESIGN

Entity-Relationship model – E-R Diagrams – Enhanced-ER Model – ER-to-Relational Mapping –

Functional Dependencies – Non-loss Decomposition – First, Second, Third Normal Forms, Dependency
Preservation – Boyce/Codd Normal Form – Multi-valued Dependencies and Fourth Normal Form –
Join Dependencies and Fifth Normal Form

2.1 Entity-Relationship model

The entity-relationship (E-R) data model uses a collection of basic objects, called entities, and
relationships among these objects. An entity is a “thing” or “object” in the real world that is
distinguishable from other objects. The entity relationship model is widely used in database design.
Attributes are the properties that define the entity type.
For example, Roll_No, Name, DOB, Age, Address, and Mobile_No are the attributes that define
entity type Student.
In ER diagram,
 Entity set is represented by rectangle

 Weak entity set is represented by,

 Attribute is represented by is represented by an oval

 Key attribute - The attribute (or combination of attributes) which is unique for every entity
instance is called key attribute. In ER modeling, notation for key attribute is given
below.

 Multivalued attribute is represented by is represented by a double oval

SRMMCET / CSE / DBMS 1

 CS3492 – DATABASE MANAGEMENT SYSTEMS

Degree of a Relationship
Degree of a relationship is the number of entity types involved. The n-ary relationship is the
general form for degree n. Special cases are unary, binary, and ternary, where the degree is 1, 2, and 3,
respectively.
Example for unary relationship: An employee ia a manager of another employee
 Example for binary relationship: An employee works-for department.
 Example for ternary relationship : customer purchase item from a shop keeper

Cardinality of a Relationship
In a database, the mapping cardinality or cardinality ratio means to denote the number of entities to
which another entity can be linked through a certain relation set. Mapping cardinality is most useful in
describing binary relation sets, although it can contribute to the description of relation sets containing
more than two entity sets.

Types of cardinality in between tables are:

 One-to-One
 One-to-Many
 Many-to-One
 Many-to-Many
One-to-One
In this type of cardinality mapping, an entity in A is connected to at most one entity in B. Or we
can say that a unit or item in B is connected to at most one unit or item in A.

Fig. 2.1a One-to-One mapping

Example:
In a particular hospital, the surgeon department has one head of department. They both serve
one-to-one relationships.

Fig. 2.1b One-to-One relation

SRMMCET / CSE / DBMS 2

 CS3492 – DATABASE MANAGEMENT SYSTEMS

One-to-Many
In this type of cardinality mapping, an entity in A is associated with any number of entities in B.
Or we can say that one unit or item in B can be connected to at most one unit or item in A.

Fig. 2.2a One-to-Many mapping

Example:
In a particular hospital, the surgeon department has multiple doctors. They serve one-to-many
relationships.

Fig. 2.2b One-to-Many relation

Many-to-One
In this type of cardinality mapping, an entity in A is connected to at most one entity in B. Or we
can say a unit or item in B can be associated with any number (zero or more) of entities or items in A.

Fig. 2.3a One-to-Many mapping

Example:
In a particular hospital, multiple surgeries are done by a single surgeon. Such a type of
relationship is known as a many-to-one relationship.

Fig. 2.3b One-to-Many relation

SRMMCET / CSE / DBMS 3

 CS3492 – DATABASE MANAGEMENT SYSTEMS

2.2 E-R Diagrams

Entity Relationship Diagram – An Entity–relationship model (ER model) describes the structure of a
database with the help of a diagram, which is known as Entity Relationship Diagram. An ER model is a
design or blueprint of a database that can later be implemented as a database.

A simple ER Diagram:
In the following diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students however a
student cannot study in multiple colleges at the same time. Student entity has attributes such as Stu_Id,
Stu_Name & Stu_Addr and College entity has attributes such as Col_ID & Col_Name.

Fig. 2.4 Simple ER Diagram

Example 1:

Construct an E-R diagram for a car-insurance company whose customers own one or more cars
each. Each car has associated with it zero to any number of recorded accidents. Each insurance policy
covers one or more cars, and has one or more premium payments associated with it. Each payment is for
a particular period of time, and has an associated due date, and the date when the payment was received.

The ER diagram for the given example

Fig. 2.5 E-R Diagram for a Car-Insurance Company

SRMMCET / CSE / DBMS 4

 CS3492 – DATABASE MANAGEMENT SYSTEMS

Example 2:

A university registrar’s office maintains data about the following entities: (i) courses, including
number, title, credits, syllabus, and prerequisites; (ii) course offerings, including course number, year,
semester, section number, instructor(s), timings, and classroom; (iii) students, including student-id,
name, and program; and (iv)instructors, including identification number, name, department, and title.
Further, the enrollment of students in courses and grades awarded to students in each course they are
enrolled for must be appropriately modeled. Construct an E-R diagram for the registrar’s office.
Document all assumptions that you make about the mapping constraints.

Fig. 2.6 E-R Diagram for university registrar’s office maintains

2.3 Enhanced-ER Model

The ER Model has the power of expressing database entities in a conceptual hierarchical manner.
As the hierarchy goes up, it generalizes the view of entities, and as we go deep in the hierarchy, it gives
us the detail of every entity included.

Going up in this structure is called generalization, where entities are clubbed together to
represent a more generalized view. For example, a particular student named Mira can be generalized
along with all the students. The entity shall be a student, and further, the student is a person. The reverse
is called specialization where a person is a student, and that student is Mira.

SRMMCET / CSE / DBMS 5

 CS3492 – DATABASE MANAGEMENT SYSTEMS

Generalization:
As mentioned above, the process of generalizing entities, where the generalized entities contain
the properties of all the generalized entities is called generalization. In generalization, a number of
entities are brought together into one generalized entity based on their similar characteristics. For
example, pigeon, house sparrow, crow and dove can all be generalized as Birds.

Fig. 2.7 Generalization

Specialization:
Specialization is the opposite of generalization. In specialization, a group of entities is divided
into subgroups based on their characteristics. Take a group ‘Person’ for example. A person has name,
date of birth, gender, etc. These properties are common in all persons, human beings. But in a company,
persons can be identified as employee, employer, customer, or vendor, based on what role they play in
the company.

Fig. 2.8 Specialization

Similarly, in a school database, persons can be specialized as teacher, student, or a staff, based
on what role they play in school as entities.

Inheritance:
We use all the above features of ER-Model in order to create classes of objects in object-oriented
programming. The details of entities are generally hidden from the user; this process known as
abstraction. Inheritance is an important feature of Generalization and Specialization. It allows lower-
level entities to inherit the attributes of higher-level entities.

SRMMCET / CSE / DBMS 6

 CS3492 – DATABASE MANAGEMENT SYSTEMS

Fig. 2.9 Inheritance

For example, the attributes of a Person class such as name, age, and gender can be inherited by
lower-level entities such as Student or Teacher.

2.4 ER-to-Relational Mapping

The diamond shape showcases a relationship in the ER diagram. It depicts the relationship
between two entities. In the example below, both the student and the course are entities, and study is the
relationship between them.

Fig. 2.10 Simple ER-to-Relational

One-to-One Relationship
When a single element of an entity is associated with a single element of another entity, it is
called a one-to-one relationship. For example, a student has only one identification card and an
identification card is given to one person.

Fig. 2.11 One-to-One Relationship

One-to-Many Relationship
When a single element of an entity is associated with more than one element of another entity, it
is called a one-to-many relationship. For example, a customer can place many orders, but an order
cannot be placed by many customers.

SRMMCET / CSE / DBMS 7

 CS3492 – DATABASE MANAGEMENT SYSTEMS

Fig. 2.12 One-to-Many Relationship

Many-to-One Relationship
When more than one element of an entity is related to a single element of another entity, then it
is called a many-to-one relationship. For example, students have to opt for a single course, but a course
can have many students.

Fig. 2.13 Many-to-one Relationship

Many-to-Many Relationship
When more than one element of an entity is associated with more than one element of another
entity, this is called a many-to-many relationship. For example, you can assign an employee too many
projects and a project can have many employees.

Fig. 2.14 Many-to-Many Relationship

How to Draw an ER Diagram?

Below are some important points to draw ER diagram:
 First, identify all the Entities. Embed all the entities in a rectangle and label them properly.
 Identify relationships between entities and connect them using a diamond in the middle,
illustrating the relationship. Do not connect relationships with each other.
 Connect attributes for entities and label them properly.
 Eradicate any redundant entities or relationships.
 Make sure your ER Diagram supports all the data provided to design the database.
 Effectively use colors to highlight key areas in your diagrams.

SRMMCET / CSE / DBMS 8

 CS3492 – DATABASE MANAGEMENT SYSTEMS

2.5 Functional Dependencies

Functional Dependencies
Functional dependency (FD) is a constraint between two sets of attributes from the database.
 A functional dependency is a property of the semantics or meaning of the attributes. In every
relation R(A1, A2,…, An) there is a FD called the PK -> A1, A2, …, An Formally the FD is
defined as follows
 If X and Y are two sets of attributes, that are subsets of T
For any two tuples t1 and t2 in r , if t1[X]=t2[X], we must also have t1[Y]=t2[Y].
Notation:
 If the values of Y are determined by the values of X, then it is denoted by X -> Y
 Given the value of one attribute, we can determine the value of another attribute X f.d. Y or
X -> y
Example: Consider the following,
Student Number -> Address, Faculty Number -> Department,
Department Code -> Head of Dept
Functional dependencies allow us to express constraints that cannot be expressed using super
keys.
Consider the schema:
Loan-info-schema = (customer-name, loan-number, branch-name, amount).
We expect this set of functional dependencies to hold:
loan-number amount
loan-number branch-name
but would not expect the following to hold:
loan-number customer-name

Use of Functional Dependencies

We use functional dependencies to:
 Test relations to see if they are legal under a given set of functional dependencies.
 If a relation r is legal under a set F of functional dependencies, we say that r satisfies F.
 Specify constraints on the set of legal relations
 We say that F holds on R if all legal relations on R satisfy the set of functional dependencies F.

Example - Employee
SSN Name JobType DeptName
557-78-6587 Lance Smith Accountant Salary
214-45-2398 Lance Smith Engineer Product

SRMMCET / CSE / DBMS 9

 CS3492 – DATABASE MANAGEMENT SYSTEMS

Name is functionally dependent on SSN because an employee‘s name can be uniquely determined
from their SSN. Name does not determine SSN, because more than one employee can have the same
name.
Keys
 Whereas a key is a set of attributes that uniquely identifies an entire tuple, a functional dependency
allows us to express constraints that uniquely identify the values of certain attributes.
 However, a candidate key is always a determinant, but a determinant doesn‘t need to be a key.
Axioms
Before we can determine the closure of the relation, Student, we need a set of rules.
i. Reflexivity Rule
ii. Augmentation Rule
iii. Transitivity Rule
iv. Union Rule
v. Decomposition Rule
vi. Pseudo transitivity Rule

2.6 Non-loss Decomposition

Relational Decomposition
 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

Fig. 2.15 Types of Decomposition

SRMMCET / CSE / DBMS 10

 CS3492 – DATABASE MANAGEMENT SYSTEMS

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.

Advantages of Lossless Decomposition

 Reduced Data Redundancy: Lossless decomposition helps in reducing the data redundancy that
exists in the original relation. This helps in improving the efficiency of the database system by
reducing storage requirements and improving query performance.
 Maintenance and Updates: Lossless decomposition makes it easier to maintain and update the
database since it allows for more granular control over the data.
 Improved Data Integrity: Decomposing a relation into smaller relations can help to improve data
integrity by ensuring that each relation contains only data that is relevant to that relation. This
can help to reduce data inconsistencies and errors.
 Improved Flexibility: Lossless decomposition can improve the flexibility of the database system
by allowing for easier modification of the schema.

Disadvantages of Lossless Decomposition

 Increased Complexity: Lossless decomposition can increase the complexity of the database
system, making it harder to understand and manage.
 Increased Processing Overhead: The process of decomposing a relation into smaller relations
can result in increased processing overhead. This can lead to slower query performance and
reduced efficiency.
 Join Operations: Lossless decomposition may require additional join operations to retrieve
data from the decomposed relations. This can also result in slower query performance.
 Costly: Decomposing relations can be costly, especially if the database is large and complex.
This can require additional resources, such as hardware and personnel.

SRMMCET / CSE / DBMS 11

 CS3492 – DATABASE MANAGEMENT SYSTEMS

2.7 First, Second, Third Normal Forms, Dependency Preservation

Normalization of Database Database

Normalization is a technique of organizing the data in the database. Normalization is a systematic
approach of decomposing tables to eliminate data redundancy and undesirable characteristics like
Insertion, Update and Deletion Anamolies. It is a multi-step process that puts data into tabular form by
removing duplicated data from the relation tables.

First Normal Form (1NF)

As per First Normal Form, no two Rows of data must contain repeating group of information i.e
each set of column must have a unique value, such that multiple columns cannot be used to fetch the
same row. Each table should be organized into rows, and each row should have a primary key that
distinguishes it as unique. The Primary key is usually a single column, but sometimes more than one
column can be combined to create a single primary key. For example consider a table which is not in
First normal form.
Example: - Student Table:

Student Age Age Subject

Adam 15 Biology, Maths
Alex 14 Maths
Stuart 17 Maths

In First Normal Form, any row must not have a column in which more than one value is saved,
like separated with commas. Rather than that, we must separate such data into multiple rows.
Student Table following 1NF will be:

Student Age Age Subject

Adam 15 Biology
Adam 15 Maths
Alex 14 Maths
Stuart 17 Maths

Using the First Normal Form, data redundancy increases, as there will be many columns with
same data in multiple rows but each row as a whole will be unique.

Second Normal Form (2NF)

As per the Second Normal Form there must not be any partial dependency of any column on
primary key. It means that for a table that has concatenated primary key, each column in the table that is
not part of the primary key must depend upon the entire concatenated key for its existence. If any
column depends only on one part of the concatenated key, then the table fails Second normal form.

SRMMCET / CSE / DBMS 12

 CS3492 – DATABASE MANAGEMENT SYSTEMS

In example of First Normal Form there are two rows for Adam, to include multiple subjects that
he has opted for. While this is searchable, and follows First normal form, it is an inefficient use of space.
Also in the above Table in First Normal Form, while the candidate key is {Student, Subject}, Age of
Student only depends on Student column, which is incorrect as per Second Normal Form. To achieve
second normal form, it would be helpful to split out the subjects into an independent table, and match
them up using the student names as foreign keys.
New Student Table following 2NF will be:
Student Age Age
Adam 15
Alex 14
Stuart 17
In Student Table the candidate key will be Student column, because all other column i.e Age is
dependent on it.
New Subject Table introduced for 2NF will be:
Student Age Subject
Adam Biology

Adam Maths
Alex Maths
Stuart Maths

In Subject Table the candidate key will be {Student, Subject} column. Now, both the above tables
qualify for Second Normal Form and will never suffer from Update Anomalies. Although there are a
few complex cases in which table in Second Normal Form suffers Update Anomalies, and to handle
those scenarios Third Normal Form is there.

Third Normal Form (3NF)

Third Normal form applies that every non-prime attribute of table must be dependent on primary
key, or we can say that, there should not be the case that a non-prime attribute is determined by another
non-prime attribute. So this transitive functional dependency should be removed from the table and also
the table must be in Second Normal form. For example, consider a table with following fields.

Student_Detail Table:

Student_id Student_name DOB Street city State Zip

SRMMCET / CSE / DBMS 13

 CS3492 – DATABASE MANAGEMENT SYSTEMS

In this table Student_id is Primary key, but street, city and state depends upon Zip. The
dependency between zip and other fields is called transitive dependency. Hence to apply 3NF, we need
to move the street, city and state to new table, with Zip as primary key.

New Student_Detail Table:

Student_id Student_name DOB Zip
Address Table:
Street city State Zip

The advantage of removing transitive dependency is,

 Amount of data duplication is reduced.
 Data integrity achieved.

2.8 Boyce / Codd Normal Form

Boyce and Codd Normal Form is a higher version of the Third Normal form. This form deals
with certain type of anomaly that is not handled by 3NF. A 3NF table which does not have multiple
overlapping candidate keys is said to be in BCNF. For a table to be in BCNF, following conditions must
be satisfied:
 R must be in 3rd Normal Form and, for each functional dependency ( X -> Y ), X should be a
super Key.
Consider the following relationship: R(A , B, C, D) and following dependencies:
ABCD
BC AD
DB
Keys are A and BC.
Hence, in the functional dependency, ABCD, A is the super key.
In second relation, BCAD, BC is also a key, but in, DB, D is not a key.
Hence we can break our relationship R into two relationships R1 and R2.
A(A, B, C, D)

R1(A, D, C) R2(D,B)
Breaking table into two tables, one with A,D and C while the other with D and B.

SRMMCET / CSE / DBMS 14

 CS3492 – DATABASE MANAGEMENT SYSTEMS

2.9 Multi-valued Dependencies and Fourth Normal Form

Multivalued dependency
Multivalued dependency occurs when two attributes in a table are independent of each other but,
both depend on a third attribute. A multivalued dependency consists of at least two attributes that are
dependent on a third attribute that's why it always requires at least three attributes. Mutiivalued
dependencies are consequences of 1NF which did not allow an attribute in a tuple to have a set of
values.
In a relation, the functional dependency A -> B relates a value of A to a value of B while
multivalued dependency represented A -> B represents a relationship that defines a relationship in
which attribute B are determined by a single value of A. The multivalued dependency is the result of
1NF that prohibits an attribute from having a set of values.

Example: Suppose there is a bike manufacturer company which produces two colors(white and
black) of each model every year.
BIKE_MODEL MANUF_YEAR COLOR
M2011 2008 White
M2001 2008 Black
M3001 2013 White
M3001 2013 Black
M4006 2017 White
M4006 2017 Black

Here columns COLOR and MANUF_YEAR are dependent on BIKE_MODEL and independent
of each other. In this case, these two columns can be called as multivalued dependent on
BIKE_MODEL. The representation of these dependencies is shown below:
BIKE_MODEL → → MANUF_YEAR
BIKE_MODEL → → COLOR

Multivalued Dependency consists of the following properties:

Consider the following relationship: R(A , B, C, D) and following dependencies:
ABCD
BC AD
DB
Keys are A and BC.
Hence, in the functional dependency, ABCD, A is the super key.
In second relation, BCAD, BC is also a key, but in, DB, D is not a key.

SRMMCET / CSE / DBMS 15

 CS3492 – DATABASE MANAGEMENT SYSTEMS

i. For a relation to maintain multivalued dependency, it must have atleast three attributes.
Since Multivalued Dependency always occurs in pairs i.e. A->->C also holds in a relation
R (A, B, C).
ii. The attributes giving rise to the multivalued facts must be independent of each other.
iii. Functional dependency is a special case of multivalued dependency. If we restrict the set
determined by multivalued dependency to a single set then multivalued dependency
reduces to a functional dependency.

Fourth Normal Form (4NF):

 It should meet all the requirement of 3NF
 Attribute of one or more rows in the table should not result in more than one rows of the same
table leading to multi-valued dependencies
To understand it clearly, consider a table with Subject, Lecturer who teaches each subject and
recommended Books for each subject.
COURSE
SUBJECT
LECTURER
BOOKS

SUBJECT LECTURER BOOKS

Maths Alex Maths Book 1
Maths Boscoo Maths Book 2
Physics Rose Physics Book
Chemistry Adam Chemistry Book

If we observe the data in the table above it satisfies 3NF. But LECTURER and BOOKS are two
independent entities here. There is no relationship between Lecturer and Books. In the above example,
either Alex or Bosco can teach Maths. For Maths subject , student can refer either 'Maths Book1' or
'Maths Book2'.
That is,
SUBJECT --> LECTURER
SUBJECT-->BOOKS
This is a multivalued dependency on SUBJECT. If we need to select both lecturer and books
recommended for any of the subject, it will show up (lecturer, books) combination, which implies lecturer
who recommends which book. This is not correct.
SELECT c.LECTURER, c.BOOKS FROM COURSE c WHERE SUBJECT = 'Maths';

SRMMCET / CSE / DBMS 16

 CS3492 – DATABASE MANAGEMENT SYSTEMS

To eliminate this dependency, we divide the table into two as below

COURSE_LECTURER COURSE_BOOKS
SUBJECT SUBJECT
LECTURER BOOKS
4NF
SUBJECT LECTURER SUBJECT BOOKS
Maths Alex Maths Maths Book 1
Maths Boscoo Maths Maths Book 2
Physics Rose Physics Physics Book
Chemistry Adam Chemistry Chemistry Book

Now if we want to know the lecturer names and books recommended for any of the subject, we
will fire two independent queries. Hence it removes the multi-valued dependency and confusion around
the data. Thus the table is in 4NF.

2.10 Join Dependencies and Fifth Normal Form

Join Dependency
Join decomposition is a further generalization of Multivalued dependencies.
Consider the following relationship: R(A , B, C, D) and following dependencies:
ABCD
BC AD
DB
Keys are A and BC.
Hence, in the functional dependency, ABCD, A is the super key.
In second relation, BCAD, BC is also a key, but in, DB, D is not a key.
If the join of R1 and R2 over C is equal to relation R, then we can say that a join dependency
(JD) exists, where R1 and R2 are the decompositions R1(A, B, C) and R2(C, D) of a given relations R
(A, B, C, D).
Alternatively, R1 and R2 are a lossless decomposition of R.
A JD ⋈ {R1, R2,..., Rn} is said to hold over a relation R if R1, R2,....., Rn is a lossless-join
decomposition.
The *(A, B, C, D), (C, D) will be a JD of R if the join of join's attribute is equal to the relation R.
Here, *(R1, R2, R3) is used to indicate that relation R1, R2, R3 and so on are a JD of R.

Fifth Normal Form (5NF):

A database is said to be in 5NF, if and only if,
 It's in 4NF

SRMMCET / CSE / DBMS 17

 CS3492 – DATABASE MANAGEMENT SYSTEMS

 If we can decompose table further to eliminate redundancy and anomaly, and when we rejoin
the decomposed tables by means of candidate keys, we should not be losing the original data
or any new record set should not arise. In simple words, joining two or more decomposed
table should not lose records nor create new records.
Consider an example of different Subjects taught by different lecturers and the lecturers taking
classes for different semesters.

COURSE
SUBJECT
LECTURER
CLASS

SUBJECT LECTURER CLASS

Maths Alex SEMESTER 1
Maths Boscoo SEMESTER 1
Physics Rose SEMESTER 1
Chemistry Adam SEMESTER 1

In above table, Rose takes both Mathematics and Physics class for Semester 1, but she does not
take Physics class for Semester 2. In this case, combination of all these 3 fields is required to identify a
valid data. Imagine we want to add a new class - Semester3 but do not know which Subject and who
will be taking that subject. We would be simply inserting a new entry with Class as Semester3 and
leaving Lecturer and subject as NULL. As we discussed above, it's not a good to have such entries.
Moreover, all the three columns together act as a primary key, we cannot leave other two columns
blank.

Hence we have to decompose the table in such a way that it satisfies all the rules till 4NF and
when join them by using keys, it should yield correct record. Here, we can represent each lecturer's
Subject area and their classes in a better way. We can divide above table into three - (SUBJECT,
LECTURER), (LECTURER, CLASS), (SUBJECT, CLASS)
5NF
SUBJECT LECTURER CLASS LECTURER CLASS SUBJECT
Maths Alex SEMESTER 1 Alex SEMESTER 1 Maths
Maths Boscoo SEMESTER 1 Boscoo SEMESTER 1 Maths
Physics Rose SEMESTER 1 Rose SEMESTER 1 Physics
Chemistry Adam SEMESTER 1 Adam SEMESTER 1 Chemistry

Now, each of combinations is in three different tables. If we need to identify who is teaching
which subject to which semester, we need join the keys of each table and get the result.

SRMMCET / CSE / DBMS 18