This document discusses the entity-relationship (ER) model for conceptual database design. It defines key concepts like entities, attributes, relationships, keys, and participation constraints. Entities can be strong or weak, and attributes can be simple, composite, multi-valued, or derived. Relationships associate entities and can specify cardinality like one-to-one, one-to-many, or many-to-many. The ER model diagrams the structure and constraints of a database before its logical and physical implementation.

1. Chapter 3:
CONCEPTUAL DESIGN-ER-
MODEL
(Entity-Relational)

2. The Entity Relationship Model
 Perspective
Organisation Information System
Relational
Model
Physical
data
storage
ERM
Conceptual Model Logical Model Physical Model

3. Steps in Database Design
 Requirements Analysis
 user needs; what must database do?
 Conceptual (Database) Design
 high level (or semantic) description.
 often done with the ER model
 Logical (Database) Design
 translate ER into DBMS data model (e.g., Relational Model)
 Schema Refinement
 consistency, normalization
 Physical (Database) Design - indexes, disk layout
 Security Design - who accesses what, and how

4. Identify the entities, its attributes and the relationships between entities.
Identify entities
For the list of activities, identify the subject areas you need to maintain information
about. These will become tables.
An entity may be an object with a physical existence - a particular person, car, house, or
employee –
or it may be an object with a conceptual existence - a company, a job, or a university course.
For example, to develop a company's database for maintaining information on
employees, the application should be able to store and provide data on employee such as when
was the employee was hired; is the employee still with the company; if the employee has
left the company when did he leave the company; which department does employee work for;
who is his/her manager; what is his/her skill level etc.
In this example, the entities are company, department, employee, manager.
An Attribute is a property that describes an entity.
In the above example,
Entity : employee
Attribute: employee’s name, age, address, salary and job etc

5. So the concepts we want you to learn
today are:
The basics of Entity-Relationship
modelling
Entities
Relationships
Attributes

6. 6
Entities
 Entity - distinguishable “thing” in the real world
– Strong entity - entities have an independent
existence
– Weak entity - existence dependent on some
other entity
EntityName
Entity
space for attributes

7. Notation for attributes
Primary Key
marked {PK}
Composite
attribute
Derived
Attribute
Multi-Valued
Attribute
(number of values
in [ ] brackets)
{PPK}
Partial Key
- part of composite PK
- or of a weak entity
EntityName
keyAttribute {PK}
compositeAttribute
partOne
partTwo
/ derivedAttribute
multiValued [min..max]

8. Relationships
 A relationship is
“.. An association among entities (the
participants)..”
 Relationships link entities with each other

9. Concept of Entity and Relationship:

10. The entity set which does not have sufficient attributes to
form a primary key is called asWeak entity set.
A member of a strong entity set is called dominant entity and
member of weak entity set is called as subordinate entity.
The primary key of a weak entity set is formed by the primary
key of the strong entity set .
The relationship between weak entity and strong entity set is
called as Identifying Relationship.

12. For example, payment_number acts as discriminator for payment entity
set. It is also called as the Partial key of the entity set.
In the above example {loan_number, payment_number} acts as
primary key for payment entity set.
The primary key of a weak entity set is formed by the primary key of the
strong entity set on which the weak entity set is existence dependent plus
the weak entity sets discriminator.
Here double lines indicate total participation of weak entity in strong entity
set it means that every payment must be related via loan-payment to
some account.
The discriminator of a weak entity set is underlined with dashed lines
rather than solid line.

14. Weak Entities
• A weak entity can be identified uniquely only by considering the
primary key of another (owner) entity.
– Owner entity set and weak entity set must participate in a one-to-many
relationship set (one owner, many weak entities).
– Weak entity sets must have total participation in this identifying
relationship set.
– Trans_no is a discriminator within a group of transactions in an ATM.
since
address
Trans_no amount
ATM Transactions
atmID
type

15. 15
Attributes
 Entity types have Attributes (or properties) which associate
each entity with a value from a domain of values for that
attribute
 Attributes can be
– simple (atomic) e.g. license_no
– composite e.g. address (street, town, postcode)
– multi-valued e.g. phone number
– derived e.g. D.O.B. ; age
– Null
– Single valued e.g. name
 Relationship types can also have attributes!

16. Types of attributes:
Simple attribute:
Simple attributes are atomic values, which cannot be divided further.
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 attributes, which do not exist physical in the database, but there
values are derived from other attributes presented in the database. For example,age can be
derived from data_of_birth.
Single-valued attribute:
Single valued attributes contain on single value. For example: Social_Security_Number.
Multi-value attribute:
Multi-value attribute may contain more than one values. For example, a person can have
more than one phone numbers, email_addresses etc.

17. Keys
Key is an attribute or collection of attributes that
uniquely identifies an entity among entity set.
For example, roll_number of a student makes her/him
identifiable among students.

18. Degree of relationship
The number of participating entities in an relationship
defines the degree of the relationship.
Unary=degree 1
Binary = degree 2
Ternary = degree 3
n-ary = degree n

19. 19
Relationships: constraints
 The degree of a relationship type
– binary (connects 2 entity types)
– unary/ recursive (connects 1 entity type with itself)
– Ternary (connects 3)
– complex (connects 3 or more entity types)
 Relationship constraints - cardinality
– one to one (1:1)
– one to many (1:m)
– many to many (m:n)
 Relationship constraints – participation
– full/mandatory
– or partial/optional
Degree

20. Binary relationship
Entity1 Entity3
TernaryRelationship
Entity2
Relationships: Degree
Entity1 Entity2
HasLinkWith
Supervisor Supervises
ESnttaitfyf1
Supervisee
Complex relationship –
here ternary
Recursive (Unary) relationship -
example

21. 21
Relationships example
Manages
Manager Department
responsibility]
dateAllocated
Each
department
is managed by
ONE manager
Each manager
Relationship manages departments
attributes

22. Unary Example with Data
Staff
supervises
A member of staff may
supervise another staff
member, but a staff
member may be
supervised by one or more
staff members
STAFF
Member Age Supervisor
A 43 C
B 27 B
C 35 D
D 33 A

23. In a one-one relationship an entity of either entity set can be
connected to at most one entity of the other set.

24. 24
Ternary Diagram
registers
“a client at a branch will
be registered by one
member of staff”
“a member of staff will
register a client at one
branch”
Staff Branch
“a member of staff at a
branch may register many
clients”
Client
Try to determine participation/cardinality by operating in pairs

25. the Works_In Relationship Set
lot
name
Employees
ssn
since
Works_In
dname
did budget
Departments

26. A Ternary Relationship Set:
Works_In2

27. Key Constraints(ternary relationships)
dname
did budget
name
lot
name
ssn
Location
Employees works_In Departments
12-233
12-354
12-243
D12 •
12-299 Rome
London
Paris
D10
D13
•••
Each employee can work at
most in one department at
a single location

28. ER Model…..
Relationship:
 Association among two or more entities. E.g., Peter works in Pharmacy
department.
 Relationship sets can also have descriptive attributes (e.g., the since
attribute of Works_In).
subor-dinate
super-visor
Reports_To
since
Works_In
dname
did budget
Departments
lot
name
Employees
ssn

29. Participation Constraints
 The participation of the
entity set Departments in
the relationship set
Manages is said to be
total if we assume every
department have a
manager.
 Connect Departments and
Manages by a thick line.
 The participation of the
entity set Employees in
Manages is partial.

30. Participation Constraints
• Does every department have a manager?
– If so, this is a participation constraint: the participation of
Departments in Manages is said to be total (vs. partial).
• Every Department MUST have at least an employee
• Every employee MUST work at least in one department
name dname
lot
did budget
since
Employees Departments
Manages
since
ssn
Works_In

31. Mapping Cardinalities:
Cardinality defines the number of entities in one entity set which can be
associated to the number of entities of other set via relationship set.
One-to-one:
one entity from entity set A can be associated with at most one entity of entity set
B and vice versa.
One-to-one relation]

32. Many-to-one:
More than one entities from entity set A can be associated
with at most one entity of entity set B but one entity from
entity set B can be associated with more than one entity
from entity set A.
Many-to-one relation]

33. Many-to-many:
one entity from A can be associated with more than one
entity from B and vice versa.
Many-to-many relation]

34. •One-to-many:
One entity from entity set A can be associated with more than one entities
of entity set B but from entity set B one entity can be associated with at
most one entity.
One-to-many relation]

35. CASE STUDY:
“Yatra company” has branches situated all over Maharashtra.
• Each branch is treated as an independent travelling agency
• Each such agency arranges tours.
• For each tour they have schedule of buses.
• Each bus is allocated a team of workers:
Driver, cleaner, conductor, helper.
• Passenger book the tour by booking a specific schedule and bus.
• The agency has many employee working as:
Clearks,agents,stenos.
• Each of the tour have many Schedules based on time of departure
and similarly Many buses for one tour but each schedule can
have one bus only.

36. Entity Primary Key
Branch Br_no
Tours T_no
Buses Bus_no
Employees Emp_id
Pasengers P_no
Scheduledby T_no,Bus_no
Allocated Emp_id,Bus_no
Bookedby P_no,Bus_no
Physical entity
relationship

37. Branch

38. Relational Model with all entity:
• Tours (tno, title, no_of_days, capacity ,departure,date)
• Branch(________________)
• Buses(_________________)
• passenger(________________)
• Employee(__________________________)
Relationship(AS per E-R-D)
• One branch of YATRA COMPANY forms many tours
• Many tours scheduled as many buses.
• Many passenger booked many buses.
• Many buses allocates many employees.

46. ISA Hierarchies
Contract_Emps
name
ssn
Employees
lot
hourly_wages
Hourly_Emps
contractid
hours_worked
ISA
If we declare A ISA B, every A entity is also considered to be a B entity.
» Reasons for using ISA:
To add descriptive attributes specific to a subclass.
To identify entities that participate in a relationship.

47. Aggregation
– Aggregation
allows us to treat a
relationship set as an
entity set for
purposes of
participation in
(other) relationships.
– Employees are
assigned to monitor
SPONSORSHIPS.
ssn
started_on
until
name
Employees
Monitors
lot
since
pid pbudget
did budget
dname
Projects Sponsors Departments

48.  Aggregation vs. ternary relationship:
 Monitors and Sponsors are distinct relationships,
with descriptive attributes of their own.
 Also, can say that each sponsorship
is monitored by at most one employee (which we
cannot do with a ternary relationship).

49. Design choices:
• Should a concept be modeled as an entity or an
attribute?
• Should a concept be modeled as an entity or a
relationship?
• Identifying relationships: Binary or ternary?
Aggregation?

51. CASE STUDY:
• Design Database for banking enterprise, with record
information about CUSTOMER ,EMPLOYEES of the bank.
• A customer can be a DEPOSITOR OR BORROWER,
• A EMPLOYEE of the bank can be CUSTOMER of the bank.
• There are two types of account SAVING or CURRENT account.
• Questions:(***Hint: Use unary relationship, specialization, generalization)
• Identify all entities.
• Identify all attributes.
• Identify all relations.
• Draw E-R-Diagram.
• Relational data model.

52. Primary key
Customer_no
Account_no Customer_no
Primary key Foreign key