Chapter - 2

Data Modelling and

Relational Database Design
Database Design Using
the E-R Model
 What is
Conceptual Database Design?
 What is Conceptual Database Design?

 Process of describing the data, relationships between

the data, and the constraints on the data.

 After analysis - Gather all the essential data required

and understand how the data are related

 The focus is on the data, rather than on the processes.

 The output of the conceptual database design is a

Conceptual Data Model ( + Data Dictionary)
Gathering Information for Conceptual Data
Modeling

 Two perspectives
 Top-down
Data model is derived from an intimate understanding of
the business.
 Bottom-up
Data model is derived by reviewing specifications and
business documents.
Entity-Relationship (ER) Modeling :

The ER data mode was developed to facilitate database

design by allowing specification of an enterprise schema
that represents the overall logical structure of a
database.
Entity-Relationship (ER) Modeling :

• ER Modeling is a top-down approach to database

design.

• Entity Relationship (ER) Diagram

– A detailed, logical representation of the entities,
associations and data elements for an organization
or business
Entity-Relationship (ER) Modeling :

• The ER data model employs three basic concepts

– entity sets, Chen Model &
– relationship sets, Crow’s Foot
Model
– attributes.

The ER model also has an associated diagrammatic

representation, the ER diagram, which can express the
overall logical structure of a database graphically.
What is an Entity Sets ?
What is an Entity ?
What is an Entity ?

An entity is an object / fact /certain things

that exists and is distinguishable from other
objects.

– Example: Specific Person, Company, Event,

plant
Entity :

Ex : Each person in a university is an entity.

An entity has a set of properties, and the values for

some set of properties must uniquely identify an
entity.
Entity :

Ex. a person may have a person_id property whose

value uniquely identifies that person.

Thus, the value 677-89-9011 for person_id would

uniquely identify one particular person in the
university.
Entity :

Example : Course can be thought of as entities, and

course_id uniquely identifies a course entity in the
university.
Entity Example :

 Examples of entities:
 Person: EMPLOYEE, STUDENT, PATIENT

 Place: STORE, WAREHOUSE

 Object: MACHINE, PRODUCT, CAR

 Event: SALE,REGISTRATION, RENEWAL

 Concept: ACCOUNT, COURSE

Entity :

 Guidelines for naming and defining entity types:

 An entity type name is a singular noun

 An entity type should be descriptive and specific
 An entity name should be concise
 Evententity types should be named for the result of
the event, not the activity or process of the event.
Check is it Entity or not ? :

Country
Check is it Entity or not :

Game
Check is it Entity or not :

Nurse
Check is it Entity or not :

Car
Check is it Entity or not :

Bank Account
Check is it Entity or not :

Order
Check is it Entity or not :

Santro
Check is it Entity or not :

Location
Check is it Entity or not :

Region
Check is it Entity or not :

Artist
Check is it Entity or not :

Song
Check is it Entity or not :

Hrithik Roshan
Check is it Entity or not :

Publisher
Check is it Entity or not :

Book
Check is it Entity or not :

Author
Check is it Entity or not :

Name
Check is it Entity or not :

Movie
Check is it Entity or not :

Shipping
Check is it Entity or not :

Credit Card
Check is it Entity or not :

Agent
Check is it Entity or not :

MITCOM
Check is it Entity or not :

Job
Check is it Entity or not :

Position
Check is it Entity or not :

Apartment
Check is it Entity or not :

Loan
Entity Set ?
Entity Set :

• An entity set is a set of entities of the same

type that share the same properties.

– Example: set of all persons, companies, trees,

holidays

Entity
Entity Set :

• An entity is represented by a set of attributes; i.e.,

descriptive properties possessed by all members of
an entity set.

– Example:

instructor = (ID, name, salary )

course= (course_id, title, credits)
Entity Set :

A subset of the attributes form a primary key of the

entity set; i.e., uniquely identifying each member of
the set.
Entity Sets
Entity Sets
Relationship ?
Relationship :

A relationship is an association among several

entities.
Relationship :

For example, we can define a relationship advisor that

associates instructor Katz with student Shankar.
This relationship specifies that Katz is an advisor to
student Shankar
Relationship :

A relationship set is a set of relationships of the same

type.

A relationship set is represented in an E-R diagram by a

diamond, which is linked via lines to a number of
different entity sets (rectangles).
Example
Relationship Sets

• A relationship may also have attributes called

descriptive attributes
Relationship Sets
• An attribute can also be associated with a relationship set.
• For instance, the advisor relationship set between entity sets
instructor and student may have the attribute date which
tracks when the student started being associated with the
advisor

76766 Crick 98988 Tanaka

45565 Katz 3 May 2008 12345 Shankar
10 June 2007
10101 Srinivasan 00128 Zhang
12 June 2006

98345 Kim 6 June 2009 76543 Brown

76543 Singh 30 June 2007
76653 Aoi
31 May 2007
22222 Einstein 23121 Chavez
4 May 2006

instructor 44553 Peltier

student

Attribute of relationship
Relationship Sets

76766 Crick 98988 Tanaka

45565 Katz 3 May 2008 12345 Shankar
10 June 2007
10101 Srinivasan 00128 Zhang
12 June 2006

98345 Kim 6 June 2009 76543 Brown

76543 Singh 30 June 2007
76653 Aoi
31 May 2007
22222 Einstein 23121 Chavez
4 May 2006

instructor 44553 Peltier

student

Attribute of relationship
Relationship Sets with Attributes
 Relationship Sets with Attributes

An attribute of a relationship set is represented in an E-R

diagram by an simple attribute (ellipse).
Relationships

 Associations between instances of one or more entity types that is of interest

 Given a name that describes its function.
• relationship name is an active or a passive verb.

Relationship name:
writes

Author Book

An author writes one or more books

A book can be written by one or more authors.
Degree of Relationships ?
Degree of Relationships :

The number of entity sets that participate in a

relationship set is the degree of the relationship set.

Example :The relationship sets advisor and takes provide

examples of a binary relationship set—that is, one that
involves two entity sets
Degree of Relationships :

Most of the relationship sets in a database system are

binary.
 Degree of Relationships

 Degree: number of entity types that participate in a relationship

 Three cases
 Unary: between two instances of one entity type
 Binary: between the instances of two entity types
 Ternary: among the instances of three entity types
Example of Unary Relationship :
Example of Binary Relationship :
Example of Ternary Relationship :
Find out degree of relationship ?
The function that an entity plays in a relationship is
called that entity’s role.

Since entity sets participating in a relationship set are

generally distinct, roles are implicit and are not
usually specified.
However, they are useful when the meaning of a
relationship needs clarification.

Such is the case when the entity sets of a relationship

set are not distinct; that is, the same entity set
participates in a relationship set more than once, in
different roles.
In this type of relationship set, sometimes called a
recursive relationship set, explicit role names are
necessary to specify how an entity participates in a
relationship instance.
n-ary relationship
Person(NID, Name)
Exam(ExamID, ExamName)
Qualification(NID,EXAMID,QulifiedDate)
Attributes
Attributes :

An entity is represented by a set of attributes.

Attributes are descriptive properties possessed by each
member of an entity set.

Ellipses, which represent attributes.

Attributes :

The designation of an attribute for an entity set

expresses that the database stores similar information
concerning each entity in the entity set

Each entity may have its own value for each attribute.
Attributes :

For each attribute, there is a set of permitted values,

called the domain, or value set, of that attribute.
Attributes :

The domain of attribute course id might be the set of all

text strings of a certain length.

Similarly, the domain of attribute semester might be

strings from the set {Fall, Winter, Spring, Summer}.
1) Simple Attribute
Simple Attribute :
Simple attributes are atomic values, which cannot be divided
further. It is simply represented by an oval. A simple attribute is
directly connected to the entity type. While making the E-R
diagram, we directly connect the oval with the rectangle.

Color Car Name

Fuel Type

Engine_no Car

Simple attribute
Simple Attribute :

Here, all the attributes are simple attributes as they can not be
divided further.
Simple Attribute :
2) Complex Attribute
Complex Attribute :

Composite attributes, on the other hand, can be divided into

subparts (i.e., other attributes).
Complex Attribute :

A composite attribute, not to be confused with a composite key, is

an attribute that can be further subdivided to yield additional
attributes.

For example, the attribute ADDRESS can be subdivided into street,

city, state, and zip code. Similarly, the attribute PHONE_NUMBER
can be subdivided into area code and exchange number.
Complex Attribute :

Definition:
- Attributes that can be divided into sub-parts like a tree structure
- Required to store detailed information of an attribute.
- This attribute have its own attribute

Representation:
- Attribute having child attribute
 Composite Attributes :

Simple
Attributes

Composite
Attributes
Composite Attributes :
Composite Attributes :
Flight_Number Date
No._of_passengers

Flight_ID

Flight
Composite Attributes :
Composite Attributes :
3) Single-valued Attributes
3) Single-valued Attributes :

The attributes in our examples all have a single value for

a particular entity.

For instance, the student ID attribute for a specific

student entity refers to only one student ID. Such
attributes are said to be single valued.
3) Single-valued Attributes :

For instance, the loan-number attribute for a specific

loan entity refers to only one loan number. Such
attributes are said to be single valued.
Definition:
Attributes that can have only one single value.
Required to show that it cannot contain multiple value of an
attribute.
Representation:
Attribute will contain single value only.
4) Multi-valued Attributes
4) Multi-valued Attributes :
Definition:
-> Attributes that can have more than one value.
-> Required to show that it can contain multiple value.

Representation:
-> Shown by dual oval.
4) Multi-valued Attributes

Multi Valued
Attribute
4) Multi-valued Attributes
4) Multi-valued Attributes
4) Multi-valued Attributes
 4) Multi-valued Attributes

Attribute dependent-name of the employee entity set

would be multi valued, since any particular employee
may have zero, one, or more dependent(s).
4) Multi-valued Attributes

Where appropriate, upper and lower bounds may be

placed on the number of values in a multi valued
attribute.
4) Multi-valued Attributes

For example, a bank may limit the number of phone

numbers recorded for a single customer to two.
Placing bounds in this case expresses that the phone-
number attribute of the customer entity set may have
between zero and two values.

Note : NULL value problem

4) Multi-valued Attributes
Note : NULL value problem
4) Multi-valued Attributes
Note : NULL value problem
5) Derived Attributes
5) Derived Attributes
The value for this type of attribute can be derived from
the values of other related attributes or entities.

For instance, let us say that the instructor entity set has
an attribute students advised, which represents how
many students an instructor advises.
5) Derived Attributes

We can derive the value for this attribute by counting

the number of student entities associated with that
instructor.
5) Derived Attributes
Definition:
Attributes that depends on another attribute using some
operations.

Required to show that the attribute value can be found

using other attribute value.

Representation:
Shown by dashed oval.
Symbol:
5) Derived Attributes

Emp_name
Emp_address

EMP_ID

Years_Employed

Skill
Employee
5) Derived Attributes

city
pin
Person_nam
e BirthDate
street

Address

Age

Favourite
Person
food
NULL Value :

An attribute takes a null value when an entity does not

have a value for it. The null value may indicate “not
applicable”—that is, the value does not exist for the
entity.
NULL Value :
Null can also designate that an attribute value is
unknown. An unknown value may be either missing (the
value does exist, but we do not have that information) or
not known (we do not know whether or not the value
actually exists).
Explain following examples
 Logical model

Physical model
Conceptual model
Mapping Cardinalities
Mapping Cardinalities :

Mapping cardinalities, or cardinality ratios, express the

number of entities to which another entity can be
associated via a relationship set.
Mapping Cardinalities :

Mapping cardinalities are most useful in describing

binary relationship sets, although they can contribute to
the description of relationship sets that involve more
than two entity sets.
Mapping Cardinalities :
1
 Chen Model
M
 1 to represent one.

 M to represent many

M
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

1) One-to-one : An entity in A is associated with at most

one entity in B, and an entity in B is associated with at
most one entity in A.

Mapping cardinalities. (a) One-to-one.

Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

1) One-to-one :

One-to-one
 Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

1) One-to-one :

One-to-one

The employee can manage only one department, and each department can be managed by one employee only:
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

1) One-to-one :

One-to-one
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

1) One-to-one :

One-to-one
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

2) One-to-many : When a single instance of an entity is

associated with more than one instances of another
entity then it is called one to many relationship.

One-to-many
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

2) One-to-many : For example – a customer can place

many orders but a order cannot be placed by many
customers.

One-to-many
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

2) One-to-many :

One-to-many
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:

2) One-to-many :

One-to-many
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
3) Many to one : When more than one instances of an
entity is associated with a single instance of another
entity then it is called many to one relationship.

Many to one
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
3) Many to one : For example – many students can
study in a single college but a student cannot study in
many colleges at the same time.

Many to one
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
3) Many to one :

Many to one
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
3) Many to one :

Many to one
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
4) Many to many : When more than one instances of
an entity is associated with more than one instances of
another entity then it is called many to many
relationship.

Many to many
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
4) Many to many : For example, a can be assigned to
many projects and a project can be assigned to many
students.

Many to many
Mapping Cardinalities :
For a binary relationship set R between entity sets A and B, the mapping
cardinality must be one of the following:
4) Many to many :

Many to many
Explain following examples ?
 Problem………..?
• Draw er diagram for each employee can work
in at most one project and each project
employees at most one employee.
 Problem………..?
Draw er diagram for each customer has at
most one account and each account
corresponds to at most one customer
 Problem………..?
• Draw er diagram for each engineer can work
in at most one project, each project can
employ many engineers
 Problem………..?
• Draw er diagram for each teacher teaches
more than one student and more than one
teacher teaches each student in a semester.
 Problem………..?
• Draw er diagram for consider that in your
library there are many copies of the
textbook and each student can issue more
than one book at a given time. Similarly,
more than one student issues each book
 Problem……….!
• Draw an ER diagram for order processing
system where a person can give order for
many items by specifying its quantity
 Relationship Sets with Attributes

Customer(customer_id, customer name, customer_street,customer_city)

Account(account_number, balance)
Depositor(customer_id,account_number,access_date)
 Multiple Relationship

• A set of entity sets can define more than one

relationship among them seleves.
 Multiple Relationship
name Emp_no Project_id Project_name

Work on N
M

employee project
1
1
manages

position
salary
budget
 Multiple Relationship

advisor

professor student

tutorial

examiner
Types of Key
Types of Key :
Super Key :
Super key is a set of an attribute which can uniquely
identify a tuple. Super key is a superset of a candidate key.

For example: In the above EMPLOYEE table,

for(EMPLOEE_ID, EMPLOYEE_NAME) the name of two
employees can be the same, but their EMPLYEE_ID can't
be the same. Hence, this combination can also be a key.
The super key would be EMPLOYEE-ID, (EMPLOYEE_ID,
EMPLOYEE-NAME), etc.
Super Key :
Super Key :
A super key or simply key is a combination of all possible
attribute which can uniquely identify the rows(tuples) in a
table. This means that a superkey may have some extra
attribute which isn't necessary for uniquely identifying the
rows in the table.
Super Key :

1) {Roll_no}
2) {Registration_no}
3) {Roll_no, Registration_no},
4) {Roll_no, Name}
5) {Name, Registration_no}
6) {Roll_no, Name, Registration_no}
All the above keys are able to uniquely identify each row.
Candidate Key :
A candidate key is an attribute or set of an attribute
which can uniquely identify a tuple.
The remaining attributes except for primary key are
considered as a candidate key. The candidate keys are
as strong as the primary key.
Candidate Key :
A candidate is a subset of a super key.

Any attribute that uniquely identifies in a table is a

candidate for the primary key such an attribute is called
candidate key.

Every table must have at least one candidate key but at

the same time can have a lot. A super key with no
unnecessary attribute is known as candidate key.
Candidate Key :
A candidate key is a minimal super key or a super key with no
redundant attribute. It is called a minimal superkey because we
select a candidate key from a set of super key such that selected
candidate key is the minimum attribute required to uniquely
identify the table.
It is selected from the set of the super key which means that all
candidate keys are super key. Candidate Keys are not allowed to
have NULL values.
Candidate Key :

If the subset of the candidate key is a super key,

then that candidate key is not a valid candidate
key.
Candidate Key :

{Roll_no}: This key doesn't have any redundant or

repeating attribute. So, it can be considered as a
candidate key.

{Registration_no}: This key also doesn't have any

repeating attribute. So, it can be considered as a
candidate key.
Candidate Key :

{Roll_no, Registration_no}: This key cannot be

considered as a candidate key because when we
take the subset of this key we get two attributes
i.e Roll_no or Registration_no. Each of these
attributes is the candidate key. So, it is not a
minimal super key. Hence, this key is not a
candidate key.
Candidate Key :

{Roll_no, Name}: This key cannot be considered

as a candidate key because when we take the
subset of this key we get two attributes i.e.
Roll_no or Name. Roll_no is a candidate key. So, it
is not a minimal super key. Hence, this key is not a
candidate key.
Candidate Key :

{Name, Registration_no}: This key cannot be

considered as a candidate key because when we
take the subset of this key we get two attributes
i.e Registration_no or Name. Registration_no is a
candidate key. So, it is not a minimal super key.
Hence, this key is not a candidate key.
Candidate Key :

{Roll_no, Name, Registration_no}: This key

cannot be considered as a candidate key because
when we take the subset of this key we get three
attributes i.e Roll_no, Registration_no and Name.
Two of these attributes i.e Roll_no and
Registration_no are the candidate key. So, it is not
a minimal superkey. Hence, this key is not a
candidate key.
Candidate Key :
Candidate Key :
For example: In the EMPLOYEE table, id is best suited for the
primary key. Rest of the attributes like SSN, Passport_Number, and
License_Number, etc. are considered as a candidate key.
Primary Key
Primary Key :

We must have a way to specify how entities within a

given entity set and relationships within a given

relationship set are distinguished.

Primary Key :

Conceptually, individual entities are distinct; from a

database perspective, however, the differences among
them must be expressed in terms of their attributes.
Primary Key :

Therefore, the values of the attribute values of an

entity must be such that they can uniquely identify the
entity.

In other words, no two entities in an entity set are

allowed to have exactly the same value for all
attributes.
Primary Key :

A key for an entity is a set of attributes that suffice to

distinguish entities from each other.

The concepts of superkey, candidate key, and primary

key are applicable to entity sets just as they are
applicable to relation schemas.
Primary Key :

Keys also help to identify relationships uniquely, and

thus distinguish relationships from each other.
Primary Key :
For example: In Student table, ID is used as a key because it is
unique for each student. In PERSON table, passport_number,
license_number, SSN are keys since they are unique for each
person.
Primary Key :

It is the first key which is used to identify one and only

one instance of an entity uniquely.

An entity can contain multiple keys as we saw in PERSON table. The

key which is most suitable from those lists become a primary key.

In the EMPLOYEE table, ID can be primary key since it is unique for

each employee. In the EMPLOYEE table, we can even select
License_Number and Passport_Number as primary key since they
are also unique.
Primary Key :
Primary Key :
The primary key is the minimal set of attributes which
uniquely identifies any row of a table. It is selected from a
set of candidate keys.

Any candidate key can become a primary key. It depends

upon the requirements and is done by the Database
Administrator (DBA).

The primary key cannot have a NULL value. It cannot

have a duplicate value.
Primary Key :
Super key-: Super Key is a superset of Candidate key. A
Super key is the set of fields within a table that uniquely
identifies each record within that table.
Alternate key-: It is also known as secondary key.
Those key which are not selected as primary key are
known as secondary keys or alternative keys.

Composite key-: It is the key that consists of more

than one attribute to uniquely identify rows (also known
as records & tuples) in a table is called composite key.
Foreign key :
Foreign keys are the column of the table which is used to
point to the primary key of another table.
Foreign key :
Explain Example
Weak Entity Sets
Weak Entity Sets :

An entity type should have a key attribute which uniquely

identifies each entity in the entity set, but there exists
some entity type for which key attribute can’t be
defined. These are called Weak Entity type.
Weak Entity Sets :

The entity sets which do not have sufficient attributes to

form a primary key are known as weak entity sets and

the entity sets which have a primary key are known as

strong entity sets.

Weak Entity Sets :

The weak entities do not have any primary key, they

cannot be identified on their own, so they depend on
some other entity (known as owner entity).
Weak Entity Sets :

The weak entities have total participation

constraint (existence dependency) in its identifying
relationship with owner identity.

Weak entity types have partial keys. Partial Keys are

set of attributes with the help of which the tuples of the
weak entities can be distinguished and identified.
Weak Entity Sets :

The weak entities have total participation

constraint (existence dependency) in its identifying
relationship with owner identity.

Weak entity types have partial keys. Partial Keys are

set of attributes with the help of which the tuples of the
weak entities can be distinguished and identified.
Note – Weak entity always has total participation but
Strong entity may not have total participation.
Weak Entity Sets :

Weak entity is depend on strong entity to ensure the

existence of weak entity.

Like strong entity, weak entity does not have any primary
key, It has partial discriminator key.
Weak Entity Sets :

Weak entity is represented by double rectangle.

The relation between one strong and one weak entity is

represented by double diamond.
Weak Entity Sets :
Weak Entity Sets :
Weak Entity Sets :
Weak Entity Sets :
Weak Entity Sets :
Generalization in ER Model
Generalization in ER Model :
Generalization is the process of extracting common
properties from a set of entities and create a
generalized entity from it. It is a bottom-up
approach in which two or more entities can be
generalized to a higher level entity if they have
some attributes in common.
Generalization in ER Model :
Generalization in ER Model :
The refinement from an initial entity set into
successive levels of entity subgroupings represents a
top-down design process in which distinctions are
made explicit.
The design process may also proceed in a bottom-
up manner, in which multiple entity sets are
synthesized into a higher-level entity set on the
basis of common features.
Generalization in ER Model :
Generalization in ER Model :
It works using bottom-up approach.
The size of schema is reduced.
It is generally applied to a group of entities.
Inheritance is not used in generalization.
It can be defined as a process where grouping are created from
multiple entity sets.
It takes the union of two or more lower-level entity sets, and
produces a higher-level entity set.
Some of the common features are obtained in the resultant higher-
level entity set.
The differences and similarities between the entities that need to
be in union operation are ignored.
Specialization in ER Model :
An entity set may include subgroupings of entities that
are distinct in some way from other entities in the set.

For instance, a subset of entities within an entity set

may have attributes that are not shared by all the
entities in the entity set.

The E-R model provides a means for representing these

distinctive entity groupings.
Specialization in ER Model :
The process of designating subgroupings within an entity
set is called specialization.

The specialization of person allows us to distinguish

among persons according to whether they are employees
or customers.
Specialization in ER Model :
Specialization in ER Model :
Specialization in ER Model :
Specialization in ER Model :
It uses a top-down approach.
The size of schema is increased.
It can be applied to a single entity.
It can be defined as process of creation of subgroups within an
entity set.
It is the reverse of generalization.
It takes a subset of higher level entity, and forms a lower-level
entity set.
A higher entity is split to form one or more low entity.
Inheritance can be used in this approach.
Explain Following Example
Explain Following Example
Aggregation
Aggregation :

One limitation of the E-R model is that it cannot

express relationships among relationships.
Aggregation :
Aggregation :
Aggregation :

Aggregation is an abstraction through which we can

represent relationships as higher level entity sets.

In aggregation, the relation between two entities is

treated as a single entity. In aggregation, relationship
with its corresponding entities is aggregated into a
higher level entity.
Aggregation :
Aggregation :
Aggregation :
Aggregation :
 Total and Partial Participation
 Total participation (indicated by double line): every entity in the
entity set participates in at least one relationship in the relationship set

participation of student in advisor relation is total

 every student must have an associated instructor
 Partial participation: some entities may not participate in any
relationship in the relationship set
• Example: participation of instructor in advisor is partial
 Problem………..?

• 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.
 Answer…………

Cust_name Cust_id Chasis_no Model

customer owns Car

1 M
1

Acc_id
Address color
Accident associated
M
Date
Place
 2 nd answer…..!
Cust_name Cust_id Chasis_no Model

customer owns Car

1 M
1

Acc_no
Address color
Accident associated
M
Date
Place
 Problem………..?
Technocrates Limited manufacture specialty engineering
components for automobiles. They are considering
computerization of their purchase ordering system.
During the requirement analysis, it was observed that the
company purchases a large number of items. The materials
planning department generates indents for the items which are to
be procured. These items have to be procured from the vendors.
Based on Indents, the purchase orders are prepared. Draw ER
diagram.
 Answer…………
• Entity :
Indent
Item
Purchase Order
Vendor
 Answer…………
1 M
Can have Vendor have

Purchase Order have ITEM

M M
1
M

have Indent have

M M
 Problem………..?
A general hospital where the operations are as follows :

In hospital many doctors are working. Their personal

information is maintained because they get fixed salary per
month. The patients are admitted to the hospital into the
room. They are treated by various doctor. Sometimes patients
performs certain pathological tests which are actually carried
out into the labs.
 Answer…………

• Entity :
Doctor
Patient
Room
Test
Path Lab
 Pat_id
Name Answer………… Test_id
T_name

Descri.
1 M
Patient perform Test
1
n
Admitted to M

1
Carried into
Room

Treated by 1
Rate
Type
Room_id Lab

m
Doctor Lab_id
Ph_no Name
Address

Name Address
Doc_id
 T_name
Test_id
Pat_id
Name
2nd answer…..! Descri.
1 M
Patient perform Test
1
n
Admitted to M

1
Carried into
Room

Treated by 1
Rate
Type
Room_id Lab

m
Doctor Lab_id
Ph_no Name
Address

Name Address
Doc_id
 Problem………..?

Consider a database used to record the marks

that students get in different exams of
different course offerings.
Answer…………
2nd answer…….!

M 1

M 1

M
N
 Problem……!

• A movie studio wishes to institute a database to

manage their files of movies actor and directors.
The following facts are relevant
- Each actor has appeared in many movies
- Each director has directed many movies
- Each movies has one director and one or more
actors.
- Each actor and director may have several addresses.
 A_name Answer….! Movie_id M_name

M N
actor Act movie movie

1 M

Actor_id
A_address Directed by

1
Director
D_address

Dir_id
D_name
 Problem………..?

• Draw an ER diagram for airlines reservations

system. Here a passenger can book ticket from
agent or passenger can directly book a ticket
for a flight.
 Answer…………

• Entity :
Flight
Passenger
Agent
Ticket
 Answer…………
M
Passenger Book from

Book 1 1
Book Agent

M
Ticket
M
1
for Flight
 Problem………..? Example: Department Store

 A department store operates in several cities

 In a city there is one headquarter coordinating
the local operations
 A city may have several stores
 Stores hold any amount of items
 Customers place their orders for any number
of items to a given store
GOAL: Optimize shopping in each city
 Answer…….?
STORES 1 CITIES
Store ID N LOCATED City Name
Address IN State
Manager ID HeadQtr Address

N
N
CUSTOMER
Customer Name
Address
HOLD IN-CITIES
Phone Number
Qty Held Qty_in_cities

N N
1

ITEMS
Item ID N N ORDERS N
ITEMS ORDERED
Description Order Number PLACE
Qty Ordered
Size Order Date
Color
 Problem……?

In organization there are many departments.

Departments budgets decided by managers of
that department. Accounts of that department
place orders to supplier depends on
requisitions. Draw ER diagram.
 Answer………!
Account Department Get
Have

on Budgets

Requisitions Manager Set by

raise Orders with Suppliers

 Problem……? Soccer Database

• A team has players, one coach, fans

• Teams play according to a schedule
• Teams need to practice in a Stadium
• Attendance and scores must be recorded
 P-no Name
Address Person
Personal
info
ISA Total
Desci Exp.

Fan Player Coach

N Uniform N Shoe 1
size size

support manges
Player for
TName
1 1
Team
practices
N
capacity
N N Play N
N
attends againts
Stadium
date attendance
1
Game Take Place
N N
 Contract-Supplies System

• A company negotiates contracts with suppliers to

provide certain amount of items at a fixed price

• Orders are placed against any of the already

negotiated contracts

• A contract could provide items to any number of

orders
 Contract-Supplies System
• An order may include any number of items
negotiated in the contract

• Orders should not exceed the maximum

amount of items quoted in the contract

• All items in an order must be provided as part

of a single contract and a single project
answer
 Research Project Database
• Some employees are researchers
• Every project has a leader investigator
• Every project must be funded by an agency
• A project may include several topics
• A topic could appear in several projects
• Researchers must produce report(s)
• Each employee must have a supervisor
answer
Relational Data Model
Relational Data Model :
Relational Data Model :

Relational Model (RM) represents the database as a

collection of relations. A relation is nothing but a table
of values.

Every row in the table represents a collection of related

data values. These rows in the table denote a real-
world entity or relationship.
Relational Data Model :

The table name and column names are helpful to

interpret the meaning of values in each row. The data
are represented as a set of relations.
In the relational model, data are stored as tables.
However, the physical storage of the data is
independent of the way the data are logically
organized.
Relational Data Model :

Top 10 Relational Databases Software

MS SQL.
Oracle Database.
MySQL.
IBM Db2.
Amazon Relational Database Service (RDS)
PostgreSQL.
Amazon Aurora.
SAP HANA.
Relational Model Concepts :

Attribute ?
Relational Model Concepts :

Attribute: Each column in a Table. Attributes are the

properties which define a relation.
e.g., Student_Rollno, NAME,etc.
Relational Model Concepts :

Tables ?
 Relational Model Concepts :

Tables – In the Relational model the, relations are saved in

the table format. It is stored along with its entities. A table
has two properties rows and columns. Rows represent
records and columns represent attributes.
Relational Model Concepts :

Tuple ?
Relational Model Concepts :

Tuple – It is nothing but a single row of a table, which

contains a single record.
Relational Model Concepts :

Relation Schema ?
Relational Model Concepts :

Relation Schema: A relation schema represents the

name of the relation with its attributes.
Relational Model Concepts :

Column: The column represents the set of values for a

specific attribute.
Relational Model Concepts :

Relation instance – Relation instance is a finite set of

tuples in the RDBMS system. Relation instances never
have duplicate tuples.
Relational Model Concepts :

Attribute domain – Every attribute has some pre-

defined value and scope which is known as attribute
domain
Relational Integrity Constraints :

Relational Integrity constraints in DBMS are referred to

conditions which must be present for a valid relation.

These Relational constraints in DBMS are derived from

the rules in the mini-world that the database
represents.
Relational Integrity Constraints :

There are many types of Integrity Constraints in DBMS.

Constraints on the Relational database management
system is mostly divided into three main categories are:

1) Domain Constraints

2) Key Constraints

3) Referential Integrity Constraints

Domain Constraints :

Domain constraints can be violated if an attribute value is

not appearing in the corresponding domain or it is not of
the appropriate data type.

Domain constraints specify that within each tuple, and the

value of each attribute must be unique. This is specified as
data types which include standard data types integers, real
numbers, characters, Booleans, variable length strings, etc.
Guru site
Best Practices for creating a Relational Model :
Data need to be represented as a collection of relations
Each relation should be depicted clearly in the table
Rows should contain data about instances of an entity
Columns must contain data about attributes of the entity
Cells of the table should hold a single value (atomic )
Each column should be given a unique name
No two rows can be identical
The values of an attribute should be from the same domain
Name of the relation is distinct from all other relations.
Order of tuple can have a different sequence
Advantages of using Relational Model :

Simplicity: A Relational data model in DBMS is simpler than the

hierarchical and network model.

Structural Independence: The relational database is only

concerned with data and not with a structure. This can improve the
performance of the model.

Easy to use: The Relational model in DBMS is easy as tables

consisting of rows and columns are quite natural and simple to
understand
Advantages of using Relational Model :

Query capability: It makes possible for a high-level query language

like SQL to avoid complex database navigation.

Data independence: The Structure of Relational database can be

changed without having to change any application.

Scalable: Regarding a number of records, or rows, and the number

of fields, a database should be enlarged to enhance its usability.
Disadvantages of Relational Model :

Few relational databases have limits on field lengths which can't

be exceeded.

Relational databases can sometimes become complex as the

amount of data grows, and the relations between pieces of data
become more complicated.

Complex relational database systems may lead to isolated

databases where the information cannot be shared from one
system to another.
Disadvantages of Relational Model :

Cost : The under laying cost involved in a relational database is

quite expensive.

Performance :
Always the performance of the relational database depends on the
number of tables. If there are more number of tables, the
response given to the queries will be slower. Additionally, more
data presence not only slows down the machine, it eventually
makes it complex to find information. Thus, a relational database is
known to be a slower database.
Disadvantages of Relational Model :

Physical Storage :
A relational database also requires tremendous amount of physical
memory since it is with rows and columns. Each of the operations
depend on separate physical storage. Only through proper
optimization, the targeted applications can be made to have
maximum physical memory.
Disadvantages of Relational Model :

Complexity :
Although a relational database is free from complex structuring,
occasionally it may become complex too. When the amount of
data in a relational database increases, it eventually makes the
system more complicated. Each and every data is been complex
since the data is arranged using common characteristics.
Disadvantages of Relational Model :

Information Loss :
Large organizations tends to use more number of number of
database systems with more tables. These information can be
used to be transferred from one system to another. This could
pose a risk of data loss.
Disadvantages of Relational Model :

Structure Limitations :
The fields that is present on a relational database is with
limitations. Limitations in essence means that it cannot
accommodate more information. Despite if more information are
provided, it may lead to data loss. Therefore, it is necessary to
describe the exact amount of data volume which the field will be
given.
Disadvantages of Relational Model :

RDBMS – a view point

• RDBMS representation of a pet called “cat’
Disadvantages of Relational Model :

OODBMS – a view point

• Wholesome ‘view’ of the object!!
Disadvantages of Relational Model :
Poor representation of real world entities

Homogeneous data Structure

- All rows have the same number of attributes.
- All values in a column are of the same type.
- All attribute values are atomic.

Fixed length of data type, Limited data types

-Can not store images, audio, video clips etc
-Spatial, Temporal data can not be added.

Reusability of relation is not possible.

E F CODD's RULES
 E F CODD's RULES
Codd presented twelve rules that a database must
obey if it is to be considered truly relational.
1. The information rule.
All data should be presented in table form.
2. Guaranteed access rule.
All data should be accessible without
ambiguity. This can be accomplished through a
combination of the table name, primary key
value, and column name.
3. Systematic treatment of null values :.
Null values are supported in a fully relational
DBMS for representing missing information and
inapplicable information in a systematic way,
independent of the data type.
4. Dynamic online catalog based on the relational model.

A relational database must provide access

to its structure through the same tools that are
used to access the data. This is usually
accomplished by storing the structure definition
within special system tables.
The database description is represented
at the logical level in the same way as ordinary
data, so that authorized users can apply the
same relational language to its interrogation as
they apply to the regular data.
 4. Dynamic online catalog based on the relational model.

Database dictionary is a catalog which shows structural

description of the complete database and it must be
stored online

This rule states that a database dictionary must be

governed by the same rules and same query language
as used for general database.
5. Comprehensive data sublanguage rule.
The database must support at least one clearly
defined language that includes functionality for Data
definition ,View definition ,Data manipulation (interactive
and by program) , Integrity constraints ,Authorization
,Transaction boundaries (begin, commit, and rollback).
All commercial relational databases use forms of

standard SQL as their supported comprehensive

language.
5. Comprehensive data sublanguage rule.
The database should be accessible through
a language which supports definition, manipulation and
all transaction management activities, such a language is
called structured language

For example, SQL, if database uses a

different language for data access and manipulation
then it is a violation of the rule.
6. View updating rule.

Data can be presented in different logical combinations

called views. Each view should support the same full
range of data manipulation that has direct access to a
table available. In practice, providing update and delete
access to logical views is difficult and is not fully
supported by any current database.

Difference views created for different purposes should

be automatically updated by the system itself.
7. High-level insert, update, and delete.

The capability of handling a base relation or a

derived relation as a single operand applies not only to
the retrieval of data but also to the insertion, update, and
deletion of data.
7. High-level insert, update, and delete.

Data can be retrieved from a relational database in

sets constructed of data from multiple rows and or
multiple tables. This rule states that insert, update, and
delete operations should be supported for any retrievable
set rather than just for a single row in single table.
7. High-level insert, update, and delete.

Operations like insert, delete and update operations

must be supported at each level of relation even though
it might be a nested relation or a complex relation

Set operations like union, intersection, minus must be

supported.
8. Physical data independence.
The user is isolated from the physical method
of storing and retrieving information from the database.
Changes can be made to the underlying architecture
(hardware disk storage method) without affecting how
the user access it.
8. Physical data independence.

Any change in the physical location of the table should

not reflect the change at the application level

Example: If you rename or move a file from one disk to

another then it should not affect the application.
9. Logical data independence.

How data is viewed should not be changed when

the logical structure (table’s structure) of the database
changes. This rule is particularly difficult to satisfy.
Most databases rely on strong ties between the data
viewed and the actual structure of the underlying tables.
9. Logical data independence.

If there are any changes done to the logical

structure of the database table, then users view of data
should not be changed

If the table is split into two tables, then a new view

should give result as the join of these two tables but
this rule is very difficult to satisfy.
10. Integrity independence.
Integrity constraints specific to a particular
relational database must be definable in the relational
data sublanguage and storable in the catalog, not in the
application programs. At a minimum, all databases do
preserve two constraints through SQL. No component of
a primary key can have a null value. If a foreign key is
defined in one table, any value in it must exist as a
primary key in another table.
11. Distribution independence.
A relational DBMS has distribution independence
.The database language must be able to manipulate
distributed data location on other computer systems.
A user should be totally unaware of whether or not
the database is distributed( whether parts of the database
exist in multiple locations). A variety of reasons make this
rule difficult to implement.
12. Non subversion rule.
There should be no way to modify the
database structure other than through the
multiple row database language like SQL. Most
databases today support administrative tools
that allow some direct manipulation of the data
structure.
 Rule 0 :
For any system to be called as RDBMS it must
be able to manage database entirely through
all relational capabilities.
Database Design using E-R
E-R to Relational
 Database Design using E-R
E-R to Relational

Student(RollNo, Name, Class, Subject)

 Database Design using E-R
E-R to Relational

location (latitude, longitude, description, last_visited )

 Database Design using E-R
E-R to Relational

customer(cust_id, name, street, city, state, zipcode )

 Database Design using E-R
E-R to Relational

customer(cust_id, name )
cust_addrs (cust_id, street, city, state, zipcode )
– Large primary keys aren’t ideal – tend to be costly
 Database Design using E-R
E-R to Relational

Persons(SSN, FirstName, LastName, Address, Birthdate)

Hobbies(SSN, Hobby)
 Database Design using E-R
E-R to Relational

Student ( Roll_no , First_name , Last_name , House_no , Street , City )

 Database Design using E-R
E-R to Relational

Student ( Roll_no , City )

Student_mobile(Roll_no,Mobile_no)
 Database Design using E-R
E-R to Relational

borrower mapping cardinality is Many to Many

A ( a1 , a2 )
R ( a1 , b1 )
B ( b1 , b2 )
 Database Design using E-R
E-R to Relational

borrower mapping cardinality One to Many

A ( a1 , a2 )
BR ( b1 , b2, a1 (FK) )
 Database Design using E-R
E-R to Relational

borrower mapping cardinality Many to One

AR ( a1 , a2 , b1(FK) )
B ( b1 , b2 )
 Database Design using E-R
E-R to Relational

R mapping cardinality One to One

Way-01:
AR ( a1 , a2 , b1(FK+ Unique) )
B ( b1 , b2 )
Way-02:
A ( a1 , a2 )
BR ( a1(FK+Unique) , b1 , b2 )
 Database Design using E-R
E-R to Relational

borrower mapping cardinality is One – to - One

customer(cust_id, name, street_address, city, loan_id (FK+Unique))
loan (loan_id, amount )
Or
customer(cust_id, name, street_address, city)
loan (loan_id, amount, cust_id (FK+Unique)) )
 Database Design using E-R
E-R to Relational

borrower mapping cardinality is many-to-many

customer(cust_id, name, street_address, city )

loan (loan_id, amount )
borrower(cust_id, loan_id, access_date )
 Database Design using E-R
E-R to Relational

Work for mapping cardinality is one-to-many

employee (
employee_id,
name,
manager_id(FK of same table)
)
 Database Design using E-R
E-R to Relational

Check-txn mapping cardinality is one-to-many and weak entity

account (account_number, balance )

check (account_number, check_number, check_date,

recipient, amount, memo )
Example
Database Design using E-R to Relational
Database Design using E-R to Relational

Account (Ac_no , Balance , b_name)

Branch (b_name , b_city , Assets)
Loan (L_no , Amt , b_name)
Borrower (C_name , L_no)
Customer (C_name , C_street , C_city)
Depositor (C_name , Ac_no)
Database Design using E-R to Relational
Database Design using E-R to Relational

Applying the rules, minimum 4

tables will be required-

AR1R2 (a1 , a2 , b1 , c1)

B (b1 , b2)

C (c1 , c2)

R3 (b1 , c1)
 Database Design using E-R to Relational

BR1R4R5 (b1 , b2 , a1 , c1 , d1)

A (a1 , a2)
R2 (a1 , c1)
CR3 (c1 , c2 , d1)
D (d1 , d2)
Database Design using E-R to Relational
 Database Design using E-R to Relational

Account-schema = (account-number, branch-name, balance)

Branch-schema = (branch-name, branch-city, assets)
Customer-schema = (customer-name, customer-street, customer-city)
Loan-schema = (loan-number, branch-name, amount)
Borrower-schema = (customer-name, loan-number)
Depositor -schema = (customer-name, account-number)
Normalization
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.
Normalization :

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.
Normalization :

The normal form is used to reduce redundancy from

the database table.

The purpose of Normalisation in SQL is to eliminate

redundant (repetitive) data and ensure data is stored
logically.
Normalization :
 Anomalies in DBMS

emp_id emp_name emp_address emp_dept

101 Rick Delhi D001

101 Rick Delhi D002
123 Maggie Agra D890
166 Glenn Chennai D900
166 Glenn Chennai D004

The above table is not normalized

 Anomalies in DBMS
emp_id emp_name emp_address emp_dept

101 Rick Delhi D001

101 Rick Delhi D002
123 Maggie Agra D890
166 Glenn Chennai D900
166 Glenn Chennai D004

Update Anomaly :
In the above table we have two rows for employee Rick as he belongs to two departments
of the company. If we want to update the address of Rick then we have to update the same
in two rows or the data will become inconsistent. If somehow, the correct address gets
updated in one department but not in other then as per the database, Rick would be having
two different addresses, which is not correct and would lead to inconsistent data.
 Anomalies in DBMS
emp_id emp_name emp_address emp_dept

101 Rick Delhi D001

101 Rick Delhi D002
123 Maggie Agra D890
166 Glenn Chennai D900
166 Glenn Chennai D004

Insert anomaly: Suppose a new employee joins the company, who

is under training and currently not assigned to any department then
we would not be able to insert the data into the table if emp_dept
field doesn’t allow nulls.
 Anomalies in DBMS
emp_id emp_name emp_address emp_dept

101 Rick Delhi D001

101 Rick Delhi D002
123 Maggie Agra D890
166 Glenn Chennai D900
166 Glenn Chennai D004

Delete anomaly: Suppose, if at a point of time the company closes

the department D890 then deleting the rows that are having
emp_dept as D890 would also delete the information of employee
Maggie since she is assigned only to this department.
rollno name branch hod office_tel
401 Akon CSE Mr. X 53337
402 Bkon CSE Mr. X 53337
403 Ckon CSE Mr. X 53337
404 Dkon CSE Mr. X 53337

Find out problems ?

Solution - Normalization
Normalization – 1NF
Normalization – 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.
Normalization – 1NF

EMP_ID EMP_NAME EMP_PHON EMP_STATE

E
14 John 7272826385, UP
9064738238
20 Harry 8574783832 Bihar
12 Sam 7390372389, Punjab
8589830302

Is it in 1NF?
Normalization – 1NF

EMP_ID EMP_NAME EMP_PHONE EMP_STATE

14 John 7272826385 UP
14 John 9064738238 UP
20 Harry 8574783832 Bihar
12 Sam 7390372389 Punjab
12 Sam 8589830302 Punjab

1NF
Example
Normalization – 1NF

Is it in 1NF ?
Normalization – 1NF

1NF
Normalization – 1NF

Domain is atomic if elements of the domain are

considered to be indivisible units.

We say that a relation schema R is in first normal

form (1NF) if the domains of all attributes of R are
atomic.
Normalization – 1NF

IS IT in 1NF ?
Normalization – 2NF
Normalization – 2NF
In the 2NF, relational must be in 1NF.

In the second normal form, all non-key

attributes are fully functional dependent on the
primary key.
Normalization – 2NF

TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

47 English 35

83 Math 38

83 Computer 38

Is it in 1NF ?
Normalization – 2NF

TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

47 English 35

83 Math 38

83 Computer 38

Find out candidate keys ?

Normalization – 2NF

TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

47 English 35

83 Math 38

83 Computer 38

Find out candidate keys ?

Teacher_id + subject
In a school, a teacher can teach more than one
subject and one subject can teach many teacher.
Normalization – 2NF

TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

47 English 35

83 Math 38

83 Computer 38

Decide Primary key

Teacher_id + subject
Normalization – 2NF

TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

47 English 35

83 Math 38

83 Computer 38

Check relation in 2NF ?

Teacher_id + subject
Teacher_id Teacher_age
Normalization – 2NF
To convert the given table into 2NF, we decompose it into
two tables:
TEACHER_ID (PK+FK) SUBJECT

25 Chemistry
25 Biology
47 English
83 Math
83 Computer

TEACHER_ID(PK) TEACHER_AGE

25 30
47 35
83 38
Normalization – 2NF
TEACHER_ID SUBJECT TEACHER_AGE

25 Chemistry 30

25 Biology 30

47 English 35

83 Math 38

83 Computer 38

Check relation in 2NF ?

Teacher_id + subject
Teacher_id Teacher_age
Normalization – 2NF

STUD_NO COURSE_NO COURSE_FEE

1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000

Check relation in 2NF ?

Normalization – 2NF
STUD_NO COURSE_NO COURSE_FEE
1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000

Check relation in 2NF ?

Yes it is in 1NF – Each cell contain
Atomic value
Normalization – 2NF
STUD_NO COURSE_NO COURSE_FEE
1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000

Check relation in 2NF ?

To be in second normal form, a relation must be in first normal form and
relation must not contain any partial dependency. A relation is in 2NF if it
has No Partial Dependency, i.e., no non-prime attribute (attributes which
are not part of any candidate key) is dependent on any proper subset of
any candidate key of the table.
Partial Dependency – If the proper subset of candidate key determines
non-prime attribute, it is called partial dependency.
Normalization – 2NF
STUD_NO COURSE_NO COURSE_FEE
1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000

Find out candidate keys ?

Normalization – 2NF
STUD_NO COURSE_NO COURSE_FEE
1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000

Candidate keys :

{STUD_NO, COURSE_NO}
Normalization – 2NF
STUD_NO COURSE_NO COURSE_FEE
1 C1 1000
2 C2 1500
1 C4 2000
4 C3 1000
4 C1 1000
2 C5 2000

Candidate keys : {STUD_NO, COURSE_NO}

COURSE_NO -> COURSE_FEE , i.e., COURSE_FEE is dependent on
COURSE_NO, which is a proper subset of the candidate key. Non-
prime attribute COURSE_FEE is dependent on a proper subset of
the candidate key, which is a partial dependency and so this
relation is not in 2NF.
Normalization – 2NF
Normalization – 3NF
 Normalization – 3NF
A relation will be in 3NF if it is in 2NF and not contain
any transitive partial dependency.

3NF 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.
X->Y
Y->Z
X->Z
 Normalization – 3NF
X->Y
Y->Z
X->Z

A relation is in third normal form if it holds at least one

of the following conditions for every non-trivial function
dependency X → Y.

X is a super key.

Y is a prime attribute, i.e., each element of Y is part of

some candidate key.
 Normalization – 3NF

EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida

333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

Check relation is in Third normal form ?

 Normalization – 3NF

EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida

333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

1NF -Yes it is in 1NF because Each cell contain

Atomic value.
 Normalization – 3NF
EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida

333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

Super key in the table above:

{EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_
NAME, EMP_ZIP}....so on
Candidate key: {EMP_ID}
 Normalization – 3NF
EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida

333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

Super key in the table above:

{EMP_ID}, {EMP_ID, EMP_NAME}, {EMP_ID, EMP_
NAME, EMP_ZIP}....so on
Candidate key: {EMP_ID}
Primary Key : {EMP_ID}
 Normalization – 3NF
EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY

222 Harry 201010 UP Noida

333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

2NF : Primary Key {EMP_ID}

In this relation all non key attributes we can retrieve by
PK. No partial dependency. All attributes are fully
dependent on primary key attribute.
 Normalization – 3NF
EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY
222 Harry 201010 UP Noida
333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

3NF : Primary Key {EMP_ID}

Here, EMP_STATE & EMP_CITY dependent on EMP_ZIP and EMP_ZIP
dependent on EMP_ID. The non-prime attributes (EMP_STATE,
EMP_CITY) transitively dependent on super key(EMP_ID). It violates the
rule of third normal form.
 Normalization – 3NF
EMP_ID EMP_NAME EMP_ZIP EMP_STATE EMP_CITY
222 Harry 201010 UP Noida
333 Stephan 02228 US Boston
444 Lan 60007 US Chicago
555 Katharine 06389 UK Norwich
666 John 462007 MP Bhopal

3NF : Primary Key {EMP_ID}

That's why we need to move the EMP_CITY and EMP_STATE to the new
<EMPLOYEE_ZIP> table, with EMP_ZIP as a Primary key.
 Normalization – 3NF
EMP_ID EMP_NAME EMP_ZIP(FK)

222 Harry 201010

333 Stephan 02228
444 Lan 60007
555 Katharine 06389
666 John 462007

EMP_ZIP EMP_STATE EMP_CITY

201010 UP Noida
02228 US Boston
60007 US Chicago
06389 UK Norwich
462007 MP Bhopal
 Normalization – 3NF

Check relation is in Third normal form ?

Normalization – 3NF

Is it in 1NF?
 Normalization – 3NF

1NF -Yes it is in 1NF because Each cell contain

Atomic value.
 Normalization – 3NF

Super key in the table above:

{Book ID} ,{Book ID + Genre ID}……. so on
Candidate key: {Book ID}
 Normalization – 3NF

Super key in the table above:

{Book ID} ,{Book ID + Genre ID}……. so on
Candidate key: {Book ID}
primary key: {Book ID}
 Normalization – 3NF

2NF : Primary Key {Book ID}

In this relation all non key attributes we can retrieve by
PK. No partial dependency. All attributes are fully
dependent on primary key attribute
 Normalization – 3NF

3NF : Primary Key {Book ID}

In the table able, [Book ID] determines [Genre ID], and [Genre
ID] determines [Genre Type]. Therefore, [Book ID] determines
[Genre Type] via [Genre ID] and we have transitive functional
dependency, and this structure does not satisfy third normal
form.
 Normalization – 3NF

PK – Genre ID

PK – Book ID
FK – Genre ID
Case Studies
Case Study - 1
Case study 1

Solve up to 3NF?
Case study 1

Is it in 1NF ?
Case study 1

1NF
1) Find out Candidate Keys ?
2) Find out primary key ?
Case study 1

1NF
Primary Key (Proj_no+Emp_no)
Case study 1
Case study 1
Case study 1
FK 2NF
Case study 1
Case study 1
Case study 1

FK

3NF
Case study 1 with all tables
Case Study - 2
Case Study 2
Case Study 2

UNF
1NF = Each Cell contain Atomic Value
Case Study 2

1NF
2NF = 1NF + NO PARTIAL DEPENDENCY
Find out Candidate Keys ?
Decide Primary key :

(Order ID + Item ID)

Case Study 2
Case Study 2
Case Study 2

2NF
3NF = 2NF + NO TRANSITIVE DEPENDENCY
Case Study 2

3NF
Case Study - 3
Case Study 3
Order no Order Invoice Invoice Product Product Qty
date no date no descritpion order
25 15/8/97 1568 28/8/97 4567 Computer 5
form
128 16/8/97 1569 28/8/97 4568 ribbon 10

535 20/8/97 1570 28/8/97 4568 ribbon 20

4567 Computer 20
form

4555 A4 paper 25

4550 Size1 pad 50

UNF
1NF = Each Cell contain Atomic Value
Case Study 3
Order no Order Invoice Invoice Product Product Qty
date no date no descritpion order
25 15/8/97 1568 28/8/97 4567 Computer 5
form
128 16/8/97 1569 28/8/97 4568 ribbon 10

535 20/8/97 1570 28/8/97 4568 ribbon 20

535 20/8/97 1570 28/8/97 4567 Computer 20

form

535 20/8/97 1570 28/8/97 4555 A4 paper 25

535 20/8/97 1570 28/8/97 4550 Size1 pad 50

2NF = 1NF + NO PARTIAL DEPENDENCY
Find out Candidate Keys ?
Decide Primary key :

(Order No + Product No)

Case Study 3

Order no Order Invoice Invoice Product Product Qty

date no date no descritpion order
25 15/8/97 1568 28/8/97 4567 Computer 5
form
128 16/8/97 1569 28/8/97 4568 ribbon 10

535 20/8/97 1570 28/8/97 4568 ribbon 20

535 20/8/97 1570 28/8/97 4567 Computer 20

form

535 20/8/97 1570 28/8/97 4555 A4 paper 25

535 20/8/97 1570 28/8/97 4550 Size1 pad 50

Case Study 3

Functional Dependency
Order no  order date, invoice no, invoice date

Product no  product description

Order no + product no  Qty order

Case Study 3
2NF
Order no Order Invoice Invoice
Order Product Qty
date no date
no no order
25 15/8/97 1568 28/8/97
25 4567 5
128 16/8/97 1569 28/8/97
128 4568 10
535 20/8/97 1570 28/8/97
535 4568 20
Product no Product
535 4567 20 descritpion
4567 Computer
535 4555 25 form
4568 ribbon
535 4550 50
4555 A4 paper
4550 Size1 pad
3NF = 2NF + NO TRANSITIVE DEPENDENCY
Case Study 3

Transitivity Dependency

Order no invoice no
invoice no  invoice date
Case Study 3
Order Product Qty Order no Order Invoice
no no order date no
25 4567 5 25 15/8/97 1568

128 16/8/97 1569

128 4568 10
535 20/8/97 1570
535 4568 20
Product Product
no descritpion
535 4567 20
4567 Computer
form
535 4555 25
Invoice Invoice 4568 ribbon
no date 4555 A4 paper
535 4550 50
1568 28/8/97 4550 Size1 pad
1569 28/8/97
1570 28/8/97

3NF
Case Study - 4
Case Study 4
A software contract and consultancy firm maintains details of all the various projects in
which its employees are currently involved. These details comprise:
Employee Number
Employee Name
Date of Birth
Department Code
Department Name
Project Code
Project Description
Project Supervisor

Assume the following:

Each employee number is unique.
Each department has a single department code.
Each project has a single code and supervisor.
Each employee may work on one or more projects.
Employee names need not necessarily be unique.
Project Code, Project Description and Project Supervisor are repeating fields.

Normalise this data to Third Normal Form.

1NF = Each Cell contain Atomic Value
Case Study 4

1NF
R1(Employee Number, Employee Name, Date of Birth,
Department Code, Department Name, Project Code,
Project Description, Project Supervisor)
2NF = 1NF + NO PARTIAL DEPENDENCY
Find out Candidate Keys ?
Decide Primary key :

Employee Number + Project Code

 Case Study 4

2NF
R2(Employee Number, Employee Name, Date of Birth,
Department Code, Department Name)

R3(Employee Number, Project Code,)

R4(Project Code, Project Description, Project Supervisor)

3NF = 2NF + NO TRANSITIVE DEPENDENCY
Case Study 4

3NF
R5(Employee Number, Employee Name, Date of Birth, Department
Code)

R6(Department Code, Department Name )

R3(Employee Number, Project Code)

R4(Project Code, Project Description, Project Supervisor)

Case Study - 5
Case Study - 5
A college maintains details of its lecturers' subject area skills.
These details comprise:
Lecturer Number
Lecturer Name
Lecturer Grade
Department Code
Department Name
Subject Code
Subject Name
Subject Level

Assume that each lecturer may teach many subjects but may not
belong to more than one department.
Subject Code, Subject Name and Subject Level are repeating
fields.
Normalise this data to Third Normal Form.
Case Study - 5

UNF
R1 (Lecturer Number , Lecturer_Name, Lecturer_Grade ,
Department Code,Department Name, Subject Code,
Subject_Name, Subject Level)
1NF = Each Cell contain Atomic Value
Case Study - 5

1NF
R1 (Lecturer Number , Lecturer_Name, Lecturer_Grade ,
Department Code,Department Name, Subject Code,
Subject_Name, Subject Level)
2NF = 1NF + NO PARTIAL DEPENDENCY
Case Study - 5

1NF
Lecturer Number + Subject Code
Case Study - 5

2NF
R2(Lecturer Number, Lecturer Name, Lecturer Grade, Department
Code, Department Name )

R3(Lecturer Number, Subject Code )

R4(Subject Code, Subject Name, Subject Level)

3NF = 2NF + NO TRANSITIVE DEPENDENCY
Case Study - 5

3NF
R5(Lecturer Number,Lecturer Name,Lecturer Grade,
Department code)
R6(Department Code, Department Name)
R3(Lecturer Number, Subject Code )
R4(Subject Code,Subject Name,Subject Level)
1NF

R1 (Lecturer Number , Lecturer_Name, Lecturer_Grade , Department

Code,Department Name, Subject Code, Subject_Name, Subject Level)

2NF

R2(Lecturer Number, Lecturer Name, Lecturer Grade, Department Code, Department

Name )
R3(Lecturer Number, Subject Code )
R4(Subject Code, Subject Name, Subject Level)

3NF

R5(Lecturer Number,Lecturer Name,Lecturer Grade, Department code)

R6(Department Code, Department Name)
R3(Lecturer Number, Subject Code )
R4(Subject Code,Subject Name,Subject Level)
 BCNF
( Boyce Codd Normal Form)
BCNF ( Boyce–Codd Normal Form) :

1] A table is in Boyce-Codd normal form (BCNF) when

every determinant in the table is a candidate key.

2] When a table contains only one candidate key then

the 3NF and BCNF are equivalent.

3] BCNF can be violated only when the table contains

more than one candidate key.
BCNF ( Boyce–Codd Normal Form) :

A B C D

A+B → C,D
C→B
A table that is in 3NF but not in BCNF ( Boyce–Codd Normal Form)
BCNF ( Boyce–Codd Normal Form) :

Definition :
One of the more desirable normal forms that we can obtain is Boyce–
Codd normal form (BCNF). A relation schema R is in BCNF with respect
to a set F of functional dependencies if, for all functional dependencies
in F+ of the form α → β, where α ⊆ R and β ⊆ R, at least one of the
following holds :

• α → β is a trivial functional dependency (that is, β ⊆ α).

• α is a superkey for schema R.

A database design is in BCNF if each member of the set of relation

schemas that constitutes the design is in BCNF.
 BCNF Example

member sport coach

Anil rao soccer kurian
Raju pai soccer kurian
Vivek das hockey Rao

Candidate key :
member+sport
Or
member+coach
 BCNF example

member sport

Anil rao soccer sport coach

soccer kurian
Raju pai soccer hockey Rao

Vivek das hockey