Entity – Relationship Model

 The overall logical structure of a

database can be expressed graphically
using E-R diagrams.
 Features of E-R Model
 This is used to give structure to the data.
 Model can be evolved independent of any
DBMS
 It is an aid for database design.
 It is easy to visualize and understand.
Basic Concepts
 Entity set
 Attributes
 Relational sets

 Entity set
 An entity is a ‘thing’ or an ‘object’ in a real
world.
 Example
 Person, car, house, book, publisher etc..,
 Attributes
 The properties that describe an entity are
called attributes.
 Example
 Customer (entity)
 Customer_id, Customer_name, city are called
attributes.
 An attribute can be classified into various type
 Simple Attributes
 Composite attributes
 Single valued attributes
 Multi valued attributes
 Derived attribute
 Simple attributes
 An attribute that cannot be divided into
further subparts
 Example
 Roll_no, Acc_no
 Composite attributes
 An attribute that can be divided into a set of
subparts.
 Example
 Customer_name divided
 Firstname , Middlename, Lastname
 Address
 Street, City, Pincode
 Single valued Attribute
 An attribute having only one value in a particular entity
 Example
 In a customer entity,
 Name, id, street are single valued attribute
 Multi valued attribute
 An attribute having more than one value for a particular entity
 Example
 Customer (entity) – (attribute) phone no
 Student (entity)- (attribute) hobby (reading,music, painting etc.,)
 Derived attribute
 An attribute that is derived from other related attributes or
entities
 Example
 Age of a customer entity set is derived from the attribute
date_of _birth of a customer.
 Relationship set
 Relationship is an association among several
entities.
 Example
 Person and company relationship
Types of Relationships
 Unary relationship
 An unary relationship exists when an
association is maintained within a single
entity.
 Example
 Boss and worker are two employees
 Manage is association
 Binary relationship
 A binary relationship exists when two entities
are associated.
 Ternary relationship
 A binary relationship exists when three
entities are associated.
 Example
 Quaternary relationship
 A quaternary relationship exists when there
are four entities associated.
 Example
Constraints
 Two main important types of constraints
are:-
 Mapping cardinalities
 Participation constraints
Mapping Cardinalities
 Mapping cardinalities or cardinality ratio
express the number of entities to which
another entity can be associated via
relationship set.
 Types are
 One to one
 One to many
 Many to one
 Many to many
One to one
 An entity in A is associated with at most
one entity in B.
 An entity in B is associated with at most
one entity in A
One to Many
 An entity in A is associated with any
number of (0 or more) entities in B.
 An entity in B is associated with at most
one entity in A
Many to one
 An entity in A is associated with at most
one entity in B.
 An entity in B is associated with Zero or
more number of entities in A.
Many to Many
 An entity in A is associated with any
number (0 or more) of entities in B and
vice versa.
Participation Constraints
 Total participation
 The participation of an 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.
 Example
 Salary relationship employees
 Partial participation
 If only some entities in E participate in
relationships in R
 Employees relationship commission
 Weak Entity set
 An entity set may not have sufficient attributes to
from a primary key. Such an entity set is termed as
weak entity set.
 Example
 Payment entity set with the attributes of payment_type,
payment_amount and payment_date.
 Strong Entity set
 An entity set that has a primary key is termed as a
strong entity set.
 Example
 Loan entity set with the attributes of loan_id, loan_amount,
loan_type
E-R diagram symbols
Alternative E-R Notations
 Crow’s Foot Notation
 Known as IE notation (most popular)
 Entity:
 Represented by a rectangle, with its name on the
top. The name is singular (entity) rather than
plural (entities).

21
Attributes
 Identifiers are represented by underlying the
name of the attribute(s)

22
 Basic Cardinality Type
 1-to-1 relationship

 1-to-M relationship

 M-to-N relationship
Example Model

24
E-R Diagram with relationships
E-R Diagram with relationships cont…
Example COMPANY Database
 We need to create a database schema design based
on the following (simplified) requirements of the
COMPANY Database:
 The company is organized into DEPARTMENTs.
Each department has a name, number and an
employee who manages the department. We
keep track of the start date of the department
manager. A department may have several
locations.
 Each department controls a number of
PROJECTs. Each project has a unique name,
unique number and is located at a single
location.

Slide 3- 28
Example COMPANY
Database (Contd.)
 We store each EMPLOYEE’s social security number, address,
salary, sex, and birthdate.
 Each employee works for one department but may work on

several projects.
 We keep track of the number of hours per week that an

employee currently works on each project.

 We also keep track of the direct supervisor of each

employee.
 Each employee may have a number of DEPENDENTs.
 For each dependent, we keep track of their name, sex,

birthdate, and relationship to the employee.

Slide 3- 29
 Initial Design of Entity Types
for the COMPANY Database Schema
 Based on the requirements, we can identify four initial
entity types in the COMPANY database:
 DEPARTMENT

 PROJECT

 EMPLOYEE

 DEPENDENT

 Their initial design is shown on the following slide

 The initial attributes shown are derived from the
requirements description

Slide 3- 30
Initial Design of Entity Types:
EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

Slide 3- 31
Refining the initial design by introducing
relationships

 The initial design is typically not complete

 Some aspects in the requirements will be represented as relationships
 ER model has three main concepts:
 Entities (and their entity types and entity sets)
 Attributes (simple, composite, multivalued)
 Relationships (and their relationship types and relationship sets)
 We introduce relationship concepts next

Slide 3- 32
Relationships and Relationship Types (1)
 A relationship relates two or more distinct entities with a
specific meaning.
 For example, EMPLOYEE John Smith works on the ProductX
PROJECT, or EMPLOYEE Franklin Wong manages the Research
DEPARTMENT.
 Relationships of the same type are grouped or typed into a
relationship type.
 For example, the WORKS_ON relationship type in which
EMPLOYEEs and PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and DEPARTMENTs
participate.
 The degree of a relationship type is the number of
participating entity types.
 Both MANAGES and WORKS_ON are binary relationships.

Slide 3- 33
 Refining the COMPANY database schema by
introducing relationships
 By examining the requirements, six relationship types are identified
 All are binary relationships( degree 2)
 Listed below with their participating entity types:
 WORKS_FOR (between EMPLOYEE, DEPARTMENT)
 MANAGES (also between EMPLOYEE, DEPARTMENT)
 CONTROLS (between DEPARTMENT, PROJECT)
 WORKS_ON (between EMPLOYEE, PROJECT)
 SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE (as
supervisor))
 DEPENDENTS_OF (between EMPLOYEE, DEPENDENT)

Slide 3- 34
 Discussion on Relationship
Types
 In the refined design, some attributes from the initial entity types are
refined into relationships:
 Manager of DEPARTMENT -> MANAGES
 Works_on of EMPLOYEE -> WORKS_ON
 Department of EMPLOYEE -> WORKS_FOR
 etc
 In general, more than one relationship type can exist between the
same participating entity types
 MANAGES and WORKS_FOR are distinct relationship types between
EMPLOYEE and DEPARTMENT
 With different meanings and different relationship instances.

Slide 3- 35
 Recursive Relationship Type
 Is a relationship type with the same participating entity type in
distinct roles
 Example: the SUPERVISION relationship
 EMPLOYEE participates twice in two distinct roles:
 supervisor (or boss) role
 supervisee (or subordinate) role
 Each relationship instance relates two distinct EMPLOYEE entities:
 One employee in supervisor role
 One employee in supervisee role

Slide 3- 36
Weak Entity Type

Slide 3- 37
Recursive Relationship Type is: SUPERVISION
(participation role names are shown)

Slide 3- 38
 Attributes of Relationship
types
 A relationship type can have attributes:
 For example, HoursPerWeek of WORKS_ON
 Its value for each relationship instance describes the number of hours per week
that an EMPLOYEE works on a PROJECT.
 A value of HoursPerWeek depends on a particular (employee, project)
combination
 Most relationship attributes are used with M:N relationships
 In 1:N relationships, they can be transferred to the entity type on the N-side
of the relationship

Slide 3- 39
Description Of Total And
Partial Participant
 1. MANAGES, a 1:1 relationship type between EMPLOYEE and DEPARTMENT.
EMPLOYEE participation is partial. DEPARTMENT participation is not clear from the
requirements. We question the users, who say that a department must have a
manager at all times, which implies total participation. The attribute StartDate is
assigned to this relationship type.
 2. WORKSJOR, a I:N relationship type between DEPARTMENT and EMPLOYEE. Both
participations are total.
 3. CONTROLS, a I:N relationship type between DEPARTMENT and PROJECT. The
participation of PROJECT is total, whereas that of DEPARTMENT is determined to be
partial, after consultation with the users indicates that some departments may
control no projects.
 4. SUPERVISION, a I:N relationship type between EMPLOYEE (in the supervisor
role) and EMPLOYEE (in the supervisee role). Both participations are determined to
be partial, after the users indicate that not every employee is a supervisor and not
every employee has a supervisor.
 5. WORKS_ON, determined to be an M:N relationship type with attribute Hours,
after the users indicate that a project can have several employees working on it.
Both participations are determined to be total.
 6. DEPENDENTS_OF, a l:N relationship type between EMPLOYEE and DEPENDENT,
which is also the identifying relationship for the weak entity type DEPENDENT. The
participation of EMPLOYEE is partial, whereas that of DEPENDENT is total.
UML class diagram for COMPANY database
schema

Slide 3- 41
 Some of the Currently Available
Automated Database Design Tools
COMPANY TOOL FUNCTIONALITY
Embarcad ER Studio Database Modeling in ER and IDEF1X
ero
DB Artisan Databaseadministration, spaceand security
Technologi
management
es
Oracle Developer 2000/Designer Database modeling, application development
2000
Popkin System Architect 2001 Data modeling, object modeling, process modeling,
Software structured analysis/design
Platinum Enterprise Modeling Suite: Data, process, and business component
(Computer Erwin, BPWin, Paradigm modeling
Associat Plus
es)
Persistence Pwertier Mapping from O-O to relational model
Inc.
Rational (IBM) Rational Rose UMLModeling & application generationin C++/JAVA
Resolution Xcase Conceptual modeling up to code maintenance
Ltd.
Sybase Enterprise Application Data modeling, business logic modeling
Suite
Visio Visio Enterprise Data modeling, design/reengineering Visual
Basic/C++
Slide 3- 42
Construct an E-R diagram for a hospital with a set of patients and a set of
medical doctors. Associate with each patient a log of various tests and
examinations conducted.
P.Gupta
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.
60