UNIT-III

ENTITY RELATIONSHIP MODEL

Database Design and ER Diagrams:

 Database Design:
The database design process can be divided into six steps.
Requirements Analysis: The very first step in designing a database applications 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.
Conceptual Database Design: The information which is gathered from requirement analysis step is used to
develop a high-level description of the data to be stored in the database along with the conditions. The goal
is to create a description of the data that matches to how both users and developers think of the data. This
facilitates all the people involved in the design process ie. Developers and as well as users who have no
technical background. Thus, the conceptual database design phase is used in drawing ER model.
Logical Database Design: This step converts the conceptual database design into a database schema in the
data model of the DBMS. It means, convert the ER model diagrams into a relational database schema.
Schema Refinement: This step is used to analyze the collection of relations (tables) in our relational
database schema to identify the future problems and to refine (clear) it.
Physical Database Design: This step involve for 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. Examples: users, user groups, departments etc.

E-R diagrams: The following diagrams are using to construct or build the ER models.

Strong entity Weak entity

Relationship Identifying relationship

Single Attribute Multivalve attributes

Derived attribute Associative entity

Key Attribute

C_Title
Date_of Course_id
Fee
Sno Sname

STUDENT Complete COURSE

1
Beyond ER (Entity-Relationship) Design: The Entity-Relationship (ER) data model allows us to describe
the data involved in real-world enterprises in terms of objects (entities) and their relationships and is widely
used to develop an initial database design.
The important role of ER model in database design is to provide a useful concept that allows
changing the detailed and informal description of what users want to implement in DBMS. The E-R
diagram is built up from the following components,

1. Rectangles: Which represent entity sets.

2. Diamonds: Which represent relationship among entity sets that are connected to the rectangles by lines.
3. Ellipses : Which represent attributes and are connected to the entities or relationship by lines.
4. Lines : Which link attributes to entity sets and entity sets to relationships.

Dept_name
Date_of depart_id
budget
emp_id ename

employee Works_in department

E-R MODEL[Entity Relationship Model]:

A logical representation of the data for an organization (or) for a business area is called E-R Model.

E-R MODEL CONSTRUCTS: The basic constructs of the entity-relationship model are entities,
relationships, and attributes.
Entities : An entity is a thing, person, place, object, event, or concept in the user environment about which
the organization wishes to maintain data.
Person : EMPLOYEE, STUDENT, PATIENT
Place : STORE, WAREHOUSE, STATE
Object : MACHINE, BUILDING, AUTOMOBILE
Event : SALE, REGISTRATION, RENEWAL
Concept: ACCOUNT, COURSE, WORK CENTER

Entity type: A collection of entities that share common properties or characteristics(attributes). Each entity
type in an E-R model is given a name. The name represents a collection of items and is always singular.

Entity Instance : A single occurrence of an entity type .

Relationship type: The Relationship type is a meaningful association between entity types. An association
between entity instances where each relationship instance includes exactly one entity from each participating
entity type is called relationship instance.
Attribute: An attribute is a property or characteristic of an entity type that is of interest to the organization.

ENTITIES, ATTRIBUTES AND ENTITY SETS:

Entity: An entity is an object in the real world that is distinguishable from other objects”. For examples
Building, room, chair, transaction, course, machine, department, employee etc.

Entities are the basic units used in modeling classes. Entities can have constitute ideas or concepts.

Entity Set: An entity set is a collection of similar entities or objects which maintains the data. Example, job
details, course details, staff details manager details, flight details etc.

Entity Types: Entities are two types. They are 1. Strong entity 2. Weak entity.

2
Strong entity : An entity that exists independently of other entity types is called Strong entity. Eg:
STUDENT, EMPLOYEE, AUTOMOBILE, and COURSE.
Sname
Sno
Course
Course

STUDENT

Weak entity : An entity type whose existence depends on some other entity type is called Weak entity and
which does not have a primary key. Middle
First
Las
t
Dept_No
Dept_Nam Date_of_join

DEPARTMENT

Attribute: An entity is represented by an ellipse symbol. An attribute is a property or characteristic of an

“entity type” of an organization. For example, employee entity has its own attributes such emp_number,
ename, salary etc.
Types:

Single valued attribute: The attributes that have a single value for a particular entity is known as single
valued attribute. For example, emp_number can be only a single value for a particular employee.

Dept_No

Multivalued valued Attribute: An attribute that may take on more than one value for a given entity instance.
Eg:
Addres

Street Name
City District Pin Code

Derived attribute: An attribute whose values can be calculated from related attribute values.

Years_Employed
Dept
Ename
Emp_No

EMPLOYEE
In this, the attribute “year employed” calculated from join date and present date.

Composite attribute: An attribute that can be broken down into component parts.

Null Attributes: A null attribute is an attribute that uses a null value when a entity does not have a value for
an attribute.

3
Relationship and Relationship Sets: The Relationship is an association between two or more entities.
This relation is denoted by a diamond symbol that containing the name of the relationship.

C_Title
Date_of Course_id
Sno Fee
Sname

Completes COURSE
STUDENT

Relationship instances: It is an association between among entity instances which establish the relationship
with more than one instance. For example, A student may taken more than one course at the same time. I.e.

Student course
PRADEEP C
SEENU C++
RAJA JAVA
YUGANDAR ORACLE

Identifying Relationship : The relationship between strong entity type and weak entity type is called
“Identifying Relationship”
C_Title
Date_of Course_id
Fee
Sno Sname

Completes COURSE
STUDENT cour

In the above example in student entity property „sno‟ is primary key and course entity property „course_id‟
is discriminator key

Associative entity: An entity type that associates the instances of one or more entity types and contains
attributes that are peculiar to the relationship between those entity instances.

Certificat_no C_Title

Sname Course_id
Sno Fee

Certifica
STUDENT COURSE

TYPES OF RELATIONSHIPS
Unary relationship: A unary relationship exists when an association is maintained within a single entity.
For example boss and worker distinguish the two employees participating in the manage association

4
Binary relationship: A binary relationship exists when two entities are associated. For example the book,
publisher relationship shown below.

Ternary Relationship: A ternary relationship exists when there are three entities associated for example,
the entities teacher, subject and student are related using ternary relationship called „teaches‟.

Quaternary relationship: A quaternary relationship exists when there are four entities associated. An
example of quaternary relationship is „studies‟ where four entities are involved student, teacher, subject and
course-material.

Mappin Cardinalities: mapping cardinalities the number of entities to which another entity can be
associated via a relationship set.
For a binary relationship set R between entity sets A and B, the mapping cardinalites must be one of the
falowing:
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.

A1 B1

A2 B2

A3 B3

A4 B4

5
Example: A customer with single account at given branch.

Depositor
Customer Account

One-to-many: An entity in A is associated with any number in B. An entity in B is associated with at most
one entity in A

B1

A1 B2

A2 B3

A3 B4

A4 B5

B6

Example: A customer having two account at given branch.

Depositor
Customer Account

Many-to-one: An entity in A is associated with at most one entity in B. An entity in B is associated with any
number of entities in A.

A1

A2 B1

A3B2

A4 B3

A5

Example: Many employees works for a company. This relationship is shown by mant-to-one

Employee Works for Company

6
Many-to-Many: An entity in A is associated with any number of entities in B. An entity in B is associated
with any number entities in A.

A1 B1

A2 B2

A3 B3

A4 B4

Example: Employee works on number of projects and project is handled by number of employees.
Therefore the relationship between employee and project is manu-to-many

Employee Works in Company

Cardinality constraints: It specifies the number of instances of one entity that can be associated with each
instance of another entity.
Mandatory one: It means an instance of entity must be associated with another instances of entity. For
example, examine the following relationship “PROFESSOR GUIDE THE STUDENTS” . In this,
professor must guide the students.
One one
STUDENT
PROFESSOR GUIDE

A professor guide only one student

Optional one : It means an instance of entity optionally associated with another instance of entity. For
example, examine the following relationship “PROFESSOR GUIDE THE STUDENTS” . In this, professor
may or may not guide the students.
One one
STUDENT
PROFESSOR GUIDE

A professor may guide only one student

Mandatory many: It means the number of instances of an entity must be associated with another instance of
entity.
take course
student

Many students take many courses

Optional many : It means, the number of instances of an entity optionally associated with another instance of
entity. student take course

Many students optianally take many courses

Minimum cardinality: A cardinality constraint specifies the minimum number of instances of one entity that
can be associated with each instance of another entity.
Maximum cardinality : A cardinality constraint that specifies the maximum number of instances one entity
that can be associated with each instance of another entity.

7
Rules for naming relationships:
1) A relationship name is verb phrase.
2) A relationship name is in lower case letter.
3) Relationship names represents action being taken , i.e., usually in present tense.
Rules for defining relationships:
A relationship definition explains what relationship is and what is important.
1) It may be important to state that who does the action.
2) It may be important to give examples to clarify the action.
3) The definition should explain any optional participation.
4) A relationship definition should explain any restrictions on participating in relationship.

Additional Features of ER model:

The additional features of ER model allow us to describe some common properties (attributes) of the data.
Key constraints: The Key constraints are used to provide the restrictions to an entity. So that allows unique
instance. Consider the “Works_In relationship” example shown in fig that an employee can work in several
departments and a department can have several employees.

Emp_no-1

Emp_no-2 5

8
Emp_no-3
9
Emp_no-4 7

Employee Works_in (date) Department

In the above fig. each employee is denoted by its “emp_no” and each department is denoted by number such
as 5,8,9,7. Here “works_in” is a relationship that establish the relationship b/w employee and department.
Here the emp_no 2 works in 5 & 8 departments and emp_no4 works in 9 & 7 departments.

Now consider another relationship set called “manages” b/w employee and department entities. This is
shown in following Dept_Title
Date_of Dept_id
Emp_no ename budget

manages department
employee

In this example, we applied “key constraint” by indicating the arrow mark from “department” entity to
“manages” relationship. So that each department entity appears in at most one manages relationship. Thus,
the arrow mark said that given a department entity is uniquely determine the “manages” relationship in
which it appears.

Participation Constraints: The participation of entity set E in a relationship set R is said to be total if
every entity in E participates in at least one relationship in R.
If only some entities in E participate in relationships in R, the participation of entity set E in relationship
R is said to be partial.
For example, we expect every loan entity to be related to at least one customer through the borrower
relationship. Therefore, the participation of loan in the relationship set borrower is total. While, a bank

8
customer may or may not have a loan. Therefore, the participation of customer in the borrower relationship
is partial.

Class Hierarchies: To classify the entities in an entity set into subclass entity is known as class hierarchy.
This hierarchy contains the model that has resulted from extending the original E-R model with new
modeling constructs. Such type of new modeling constructs are Sub type/Super type relationship. This
facility allows us to model a general entity type, called super type and then subdivide it into several
specialized entity types, called subtype.

For example, the entity type EMPLOYEE can be modeled as a super type with subtypes such as “hourly
employees”, “salaried employees”, and “contract consultants”.
super type entity and sub type entity.

Sub type: A sub grouping of entities in an entity type that is meaningful to organization and that share the
common attributes that are distinct from other attribute of other type.

Super type : It is a generic entity type that has a relationship with one or more subtypes. The relationship of
Super type and sub type is shown in simple example. Suppose that an organization has three basic types of
employee: i.e. hourly employees, salaried employees, and contract consultants.

Ex: Hourly employees contain Employee no, emp name ,address, date hired, hourly rate.

Salaried employees contain emp no,emp name ,address, date hired, annual salary, stock option.

Contract consultants contain emp no ,emp name, address, date hired, contract no, billing rate .

address
Emp name Super type

Datehired
Emp no EMPLOYEE
SALARIED EMP

subtype
CONSULTANT
HOURLY
Stock
Annual

Contact no
Billing rate
Hourly rate

In the above example, the subtype entities inherit the values of all attributes of the super
type. This type of process is called Attribute inheritance. i.e. emp no, empname, address etc are also
assigned to subtypes.

9
Extended E-R model:
The E-R model that is supported with the additional semantic concepts is called the extended entity
relationship model or EER model. The EER model includes all the concepts of the original E-R together
with the following additional concepts:
 Specialization
 Generalization
 Aggregation
Specialization:
“Specialization is the process of designating sub grouping within an entity set.”
Specialization is a top-down process. Consider an entity set person, with attributes name, street, and city. A
person may be further classified as one of the following
 Customer
 Employee
Each of these person types is described by a set of attributes that includes all the attributes of entity set
person plus additional attributes. For example, customer entities may be further described by customer_id
and employee entities by employee_code and salary.
Specialization which is represented by triangle. The lable ISA stands for “is a” and represents for example
that customer “is a” person. The ISA relationship may also be referred to as a super class-subclass
relationship.

Generalization:
“Generalization is the process of defining a more general entity type from a set of more specialized entity
types”
Generalization is a bottom-up approach. This approach results in the identification of a generalized super
class from the original subclasses.
Consider that the attributes of „customer‟ entity are customer_id, name, street, city and an „employeee‟
entity attributes are employee_code, street, city and salary. Thus, the entity sets employee and customer
have several attributes in common. This commonality can be expressed by generalization which is a
containment relationship that exists between a higher-level entity set and one or more lower-level entity sets.
Person is higher-level entity set and customer and employee can lower-level entity sets. In other words,
person is a super class if customer and employee are subclasses.

10
Aggregation
One limitation on E-R model is that cannot express relationships among relationships.
Consider a quaternary relationship manages between employee, branch, job and manager, Using the
basic E-R modeling constructs, we obtain the E-R diagrams as shown below,

There is redundant information in the resultant figure, since every employee, branch, job combination in
manages is also in Works_on.
The best way to model above situation is to use aggregation. Aggregation is an abstraction through hich
relationships are treated as higher-level entities. Thus, the relationship set Works_on relating the entity sets
employee, branch and job is considered as a higher_level entity set called Works_on. We can then create a
binary relationship manages between Works_on and manager to represent who manages what tasks.

CONCEPTUAL DESIGN WITH THE ER MODEL:

Developing an ER diagram presents several design issues including the following:
1. Entity versus Attribute.
2. Entity versus Relationship
3. Binary versus Ternary Relationships
4. Aggregation versus Ternary Relationships.

Entity Versus Attribute: While identifying the attributes of an entity set, it is sometimes not clear whether
a property should be modeled as an attribute or as an entity set.
For example Should address be an attribute of Employees or an entity (connected to Employees by a
relationship)?
Depends upon the use we want to make of address information, and the semantics of the data:
If we have several addresses per employee, address must be an entity (since attributes cannot be set-valued).
If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address
must be modeled as an entity (since attribute values are atomic).
Entity Vs Relationship: It is not always clear whether an object is best expressed by an entity set or a
relationship set.
For example, A bank loan is modeled as an entity. An alternative is to model a loan not as an entity, but
rather as a relationship b/w customers and branches, with loan number and amount as descriptive attributes.
Each loan is represented by a relationship b/w a customer and a branch.
If every loan is held by exactly one customer and customer is associated with exactly one branch,
we may find satisfactory the design, where a loan is represented as a relationship.

11
 But, with this design, we cannot represent conveniently a situation in which several customers hold a
loan jointly. We must define a separate relationship for each holder of the joint loan. Then we must
replicate the values for the descriptive attribute loan_number and amount in each such relationship. Each
such relationship must of course, have the same value for the descriptive attributes loan_number and
amount.
Two problems arise as a result of the replication.
1. The data is stored multiple times, wasting storage space.
2. Updates, leave the data in an inconsistent state.
One possible guideline is determining whether to use an entity set or a relationship set to designate a
relationship set, an action that occurs b/w entities. This approach can also be useful in deciding whether
certain attributes may be more appropriately expressed as relationships.

12
Binary Vs Ternary Relationships: It is always possible to replace a non-binary relationship set by a
number of distinct binary relationship sets.
This example an employee can own several policies each policy can be owned by several employees and
each dependent can be covered by several policies.
suppose that we have the following additional requirements.
A policy cannot be owned jointly by two or more employees.
Every policy must be owned by some employee.

Aggregation Vs Ternary Relationship: The choice b/w using aggregation or a ternary relationship is
mainly determined by the existence of a relationship that relates a relationship set to an entity set. The
choice may also be guided by certain integrity constraints that we want to express.
Example, Consider the constraint that each sponsorship be monitored by at most one employee. We can
express this constraint in terms of the sponsors relationship set. On the other hand, we can relationship
sponsors to the relationship monitors. Thus, the presence of such a constraint serves a another reason for
using aggregation rather than a ternary relationship set.

13
14