UNIT III: Entity Relationship Model (PART – 1)

Syllabus:

Entity Relationship Model: Introduction, Representation of entities, attributes, entity set,

relationship, relationship set, constraints, sub classes, super class, inheritance, specialization,
generalization using ER Diagrams.
SQL: Creating tables with relationship, implementation of key and integrity
constraints,
nested queries, sub queries, grouping, aggregation, ordering, implementation of
different types of joins, view(updatable and non-updatable), relational set operations.

3.1Introduction

The entity-relationship (ER) data model allows us to describe the data

involved in a real-world enterprise in terms of objects and their relationships
and is widely used to develop an initial database design.
The ER model is important primarily for its role in database design. It
provides useful concepts that allow us to move from an informal description
of what users want from their database to a more detailed and precise,
description that can be implemented in a DBMS.
Even though the ER model describes the physical database model, it is
basically useful in the design and communication of the logical database
model.

3.2Overview of Database Design

Our primary focus is the design of the database. The database design process
can be divided into six steps:

Requirements Analysis

The very first step in designing a database application is to understand what

data is to be stored in the database, what applications must be built on the
database, and what operations must be performed on the database. In other
words, we must find out what the users want from the database. This process
involves discussions with user groups, a study of the current operating
environment, how it is expected to change an analysis of any available
documentation on existing applications and so on.
Conceptual Database Design

The information gathered in the requirement analysis step is used to develop

a high-level description of the data to be stored in the database, along with
the conditions known to hold this data. The goal is to create a description of
the data that matches both—how users and developers think of the data (and
the people and processes to be represented in the data). This facilitates
discussion among all the people involved in the design process i.e.,
developers and as well as users who have no technical background. In simple
words, the conceptual database design phase is used in drawing ER model.

Logical Database Design

We must implement our database design and convert the conceptual database
design into a database schema (a description of data) in the data model (a
collection of high-level data description constructs that hide many low-level
storage details) of the DBMS. We will consider only relational DBMSs, and
therefore, the task in the logical design step is to convert the conceptual
database design in the form of E-R Schema (Entity-Relationship Schema)
into a relational database schema.

Schema Refinement

The fourth step in database design is to analyze the collection, of relations (tables) in
our relational database schema to identify future problems, and to refine (clear) it.
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER
MODEL

Physical Database Design

This step may simply involve building indexes on some tables and clustering
some tables, or it may involve redesign of parts of the database schema
obtained from the earlier design steps.

Application and Security Design

Any software project that involves a DBMS must consider applications that
involve processes and identify the entities.

3.3Entities, Attributes and Entity Sets

Entity: An entity is an object in the real world that is distinguishable from other objects.
Entity set: An entity set is a collection of similar entities. The Employees
entity set with attributes ssn, name, and lot is shown in the following figure.

Attribute: An attribute describes a property associated with entities.

Attribute will have a name and a value for each entity.
Domain: A domain defines a set of permitted values for an attribute
Entity Relationship Model: An ERM is a theoretical and conceptual way of
showing data relationships in software development. It is a database
modeling technique that generates an abstract diagram or visual
representation of a system's data that can be helpful in designing a relational
database.
ER model allows us to describe the data involved in a real-world enterprise in
terms of objects and their relationships and is widely used to develop an
initial database design.

3.4Representation of Entities and Attributes

ENTITIES: Entities are represented by using rectangular boxes. These are named with
the entity
name that they represent.
ATTRIBUTES: Attributes are the properties of entities. Attributes are
represented by means of ellipses. Every ellipse represents one attribute and is
directly connected to its entity.

Types of attributes:
⮚ Simple attribute − Simple attributes are atomic values, which cannot be

divided further. For example, a student's roll number is an atomic value.

DATABASE MANAGEMENT SYSTEMS UNIT – III : ER
MODEL

⮚ Composite attribute − Composite attributes are made of more than one

simple attribute. For example, a student's complete name may have

first_name and last_name.

⮚ Derived attribute − Derived attributes are the attributes that do not exist
in the physical database, but their values are derived from other attributes
present in the database. For example, average_salary in a department
should not be saved directly in the database, instead it can be derived. For
another example, age can be derived from data_of_birth.

⮚ Single-value attribute − Single-value attributes contain single value. For

example − Social_Security_Number.
⮚ Multi-value attribute − Multi-value attributes may contain more than one

values. For example, a person can have more than one phone number,
email_address, etc.

3.5Relationship and Relationship set

Relationships are represented by diamond-shaped box. Name of the
relationship is written inside the diamond-box. All the entities
(rectangles) participating in a relationship, are connected to it by a line.
Types of relationships:

Degree of Relationship is the number of participating entities in a relationship defines the

degree of the
relationship. Based on degree the relationships are categorized as

▪ Unary = degree 1
▪ Binary = degree 2
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER
MODEL

▪ Ternary = degree 3
▪ n-array = degree
Unary Relationship: A relationship with one entity set. It is like a
relationship among 2 entities of same entity set. Example: A professor (
in-charge) reports to another professor (Head Of the Dept).

Binary Relationship: A relationship among 2 entity sets. Example: A

professor teaches a course and a course is taught by a professor.

Ternary Relationship: A relationship among 3 entity sets. Example: A
professor teaches a course in so and so semester.

n-array Relationship: A relationship among n entity sets.

Cardinality:
Defines the number of entities in one entity set, which can be associated with
the number of entities of other set via relationship set. Cardinality ratios are
categorized into 4. They are.

1. One-to-One relationship: When only one instance of entities is

associated with the relationship, then the relationship is one-to-one
relationship. Each entity in A is associated with at most one entity in B
and each entity in B is associated with at most one entity in A.
DATABASE MANAGEMENT SYSTEMS UNIT – III : ER
MODEL

2. One-to-many relationship: When more than one instance of an entity is

associated with a relationship, then the relationship is one-to-many

relationship. Each entity in A is associated with zero or more entities in B

and each entity in B is associated with at most one entity in A.
3. Many-to-one relationship: When more than one instance of entity is
associated with the relationship, then the relationship is many-to-one
relationship. Each entity in A is associated with at most one entity in B and
each entity in B is associated with 0 (or) more entities in A.

4. Many-to-Many relationship: If more than one instance of an entity on the

left and more than one instance of an entity on the right can be associated
with the relationship, then it depicts many-to-many relationship. Each
entity in A is associated with 0 (or) more entities in B and each entity in B
is associated with 0 (or) more entities in A.
Relationship Set:
A set of relationships of similar type is called a relationship set. Like entities,
a relationship too can have attributes. These attributes are called descriptive
attributes.

Participation Constraints:
⮚ Total Participation − If Each entity in the entity set is involved in the
relationship then the participation of the entity set is said to be total. Total
participation is represented by double lines.
⮚ Partial participation − If, Not all entities of the entity set are involved in
the relationship then such a participation is said to be partial. Partial
participation is represented by single lines.
Example:

3.6 Additional Features Of The ER

Model Key Constraints
Consider a relationship set called Manages between the Employees and

Departments entity sets such that each department has at most one manager,
although a single employee is allowed to manage more than one department.
The restriction that each department has at most one manager is an example of
a key constraint, and it implies that each Departments entity appears in at
most one Manages relationship in any allowable instance of Manages. This
restriction is indicated in the ER diagram of below Figure by using an arrow
from Departments to Manages. Intuitively, the arrow states that given a
Departments entity, we can uniquely determine the Manages

Key Constraints for Ternary Relationships

If an entity set E has a key constraint in a relationship set R, each entity in an
instance of E appears in at most one relationship in (a corresponding instance
of) R. To indicate a key constraint on entity set E in relationship set R, we
draw an arrow from E to R.

Below figure show a ternary relationship with key constraints. Each employee
works in at most one department, and at a single location.

Weak Entities
Strong Entity set: If each entity in the entity set is distinguishable or it has a
key then such an entity set is known as strong entity set.

Weak Entity set: If each entity in the entity set is not distinguishable or it
doesn't has a key then such an entity set is known as weak entity set.
eno is key so it is represented by solid underline. dname is partial key. It can't
distinguish the tuples in the Dependent entity set. so dname is represented by
dashed underline.
Weak entity set is always in total participation with the relation. If entity set is
weak then the relationship is also known as weak relationship, since the
dependent relation is no longer needed when the owner left.
Ex: policy dependent details are not needed when the owner (employee) of
that policy left or fired from the company or expired. The detailed ER
Diagram is as follows.

The cardinality of the owner entity set is with weak relationship is 1 : m.

Weak entity set is uniquely identifiable by partial key and key of the owner
entity set.
Dependent entity set is key to the relation because the all the tuples of weak
entity set are associated with the owner entity set tuples.

Dependents is an example of a weak entity set. A weak entity can be

identified uniquely only by considering some of its attributes in conjunction
with the primary key of another entity, which is called the identifying owner.
The following restrictions must hold:
● The owner entity set and the weak entity set must participate in a
one-to-many relationship set (one owner entity is associated with one or
more weak entities, but each weak entity has a single owner). This
relationship set is called the identifying relationship set of the weak
entity set.
 ● The weak entity set must have total participation in the identifying relationship set

3.7E-R Diagrams Implementation

Now we are in a position to write the ER diagram for the Company database
which was introduced in the beginning of this unit. The readers are strictly
advised to follow the steps shown in this unit to design an ER diagram for any
chosen problem.

Step 1: Identify the Strong and Weak Entity Sets

After careful analysis of the problem we come to a conclusion that there are
four possible entity sets as shown below:
1.Employees Strong Entity Set
2.Departments Strong Entity Set
3.Projects Strong Entity Set
4.Dependents Weak Entity Set

Step 2: Identify the Relevant Attributes

The next step is to get all the attributes that are most applicable for each entity
set. Do this work by considering each entity set in mind and also the type of
attributes. Next job is to pick the primary key for strong entity sets and partial
key for weak entity sets.

Example: Following are the attributes:

1.Employees SSN. Name, Addr, DateOfBirth, Sex, Salary
2.Departments DNo. DName, DLocation
3.Projects PNo. PName, PLocation
4.Dependents (weak) DepName, DateOf Birth, Sex, Relationship

The underlined attributes are the primary keys and DepName is the partial
key of Dependents. Also, DLocation may be treated as a multivalued
attribute.

Step 3: Identify the Relationship Sets

In this step we need to find all the meaningful relationship sets among
possible entity sets. This step is very tricky, as redundant relationships may
lead to complicated design and in turn a bad implementation.

Example: Let us show below what the possible relationship sets are:
1.Employees and Departments WorksFor
2.Employees and Departments Manages
3.Departments and Projects Controls
4. Projects and Employees WorksOn
5.Dependents and Employees Has
6.Employees and Employees Supervises

Some problems may not have recursive relationship sets but some do have. In
fact, our Company database has one such relationship set called Supervises.
You can complete this step adding possible descriptive attributes of the
relationship sets (Manages has StartDate and WorksOn has Hours).

Step 4: Identify the Cardinality Ratio and Participation Constraints

This step is relatively a simple one. Simply apply the business rules and
your common sense. So, we write the structural constraints for our example
as follows:

1.WorksFor N: 1 Total on either side

2.Manages 1: 1 Total on Employees and Partial on Departments side
3.Controls 1: N Total on either side
4.WorksOn M: N Total on either side
5.Has 1: M Total on Dependents and Partial on Employees

Step 5: Identify the IS-A and Has-A Relationship Sets

The last step is to look for “is-a” and “has-a” relationships sets for the
given problem. As far as the Company database is concerned, there are no
generalization and aggregation relationships in the Company database.

The complete single ER diagram by combining all the above five steps is shown in figure
3.8Class Hierarchies
To classify the entities in an entity set into subclass entity is known as class
hierarchies. Example, we might want to classify Employees entity set into
subclass entities Hourly-Emps entity set and Contract-Emps entity set to
distinguish the basis on which they are paid. Then the class hierarchy is
illustrated as follows.
This class hierarchy illustrates the inheritance concept. Where, the subclass attributes ISA
(read as
: is a) super class attributes; indicating the “is a” relationship (inheritance
concept).Therefore, the attributes defined for a Hourly-Emps entity set are the attributes
of Hourly-Emps plus attributes of Employees (because subclass can have superclass
properties). Likewise the attributes defined for a Contract-Emps entity set are the
attributes of Contract-Emps plus attributes of Employees.

Class Hierarchy based on Sub-super Set

1. Specialization: Specialization is the process of identifying subsets
(subclasses) of an entity set (superclass) that share some special
distinguishable characteristic. Here, the superclass (Employee) is defined
first, then the subclasses (Hourly-Emps, Contract-Emps, etc.) are defined
next.
In short, Employees is specialized into subclasses.
2. Generalization: Generalization is the process of identifying (defining)
some generalized (common) characteristics of a collection of (two or more)
entity sets and creating a new entity set that contains (possesses) these
common characteristics. Here, the subclasses (Hourly-Emps,
Contract-Emps, etc.) are defined first, then the Superclass (Employee) is
defined, next.
In shortly, Hourly-Emps and Contract-Emps are generalized by Employees.

Class Hierarchy based on Constraints

1. Overlap constraints: Overlap constraints determine whether two
subclasses are allowed to contain the same entity.

Example: Can Akbar be both an Hourly-Emps entity and a

Contract-Emps entity? The answer is, No.
Other example, can Akbar be both a Contract-Emps entity and a
Senior-Emps entity (among them)?
The answer is, Yes. Thus, this is a specialisation hierarchy property. We
denote this by writing “Contract-Emps OVERLAPS Senior-Emps”.

2. Covering Constraints: Covering constraints determine

whether the entities in the subclasses collectively include all
entities in the superclass.

Example: Should every Employee be a Hourly-Emps or

.Contract-Emps? The Answer is, No. He can be a
Daily-Emps.
Other example, should every Motor-vehicle (superclass) be a
Bike (subclass) or a Car (subclass)?
The Answer is YES. Thus generalization hierarchies property is that every
instance of a superclass is an instance of a subclass.
We denote this by writing “ Bikes and Cars COVER Motor-vehicles”.