LECTURE 8

ENTITY RELATIONSHIP MODEL

PART I
08 SEPTEMBER 2011
MODELING

A database can be modeled as:

 a collection of entities,
 relationship among entities.

An entity is an object that exists and is distinguishable from other

objects.
 Example: specific person, company, event, plant

Entities have attributes

 Example: people have names and addresses

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 SETS CUSTOMER AND LOAN
customer_id customer_ customer_ customer_ loan_ amount
name street city number
RELATIONSHIP SETS

A relationship is an association among several entities

Example:
Hayes depositor A-102
customer entity relationship set account entity

A relationship set is a mathematical relation among n  2 entities, each

taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en  En}

where (e1, e2, …, en) is a relationship

 Example:
(Hayes, A-102)  depositor
RELATIONSHIP SET BORROWER
RELATIONSHIP SETS (CONT.)

An attribute can also be property of a relationship set.

For instance, the depositor relationship set between entity sets customer and
account may have the attribute access-date
DEGREE OF A RELATIONSHIP SET

 Refers to number of entity sets that participate in a relationship set.

 Relationship sets that involve two entity sets are binary (or degree
two). Generally, most relationship sets in a database system are
binary.
 Relationship sets may involve more than two entity sets.

Example: Suppose employees of a bank may have jobs

(responsibilities) at multiple branches, with different jobs at
different branches. Then there is a ternary relationship set
between entity sets employee, job, and branch

 Relationships between more than two entity sets are rare. Most
relationships are binary. (More on this later.)
ATTRIBUTES

An entity is represented by a set of attributes, that is descriptive properties

possessed by all members of an entity set.

Example:
customer = (customer_id, customer_name,
customer_street, customer_city )
loan = (loan_number, amount )

Domain – the set of permitted values for each attribute

Attribute types:
 Simple and composite attributes.
 Single-valued and multi-valued attributes
 Example: multivalued attribute: phone_numbers

 Derived attributes
 Can be computed from other attributes
 Example: age, given date_of_birth
COMPOSITE ATTRIBUTES
MAPPING CARDINALITY CONSTRAINTS

 Express the number of entities to which another entity can be

associated via a relationship set.
 Most useful in describing binary relationship sets.
 For a binary relationship set the mapping cardinality must be one of the
following types:

 One to one
 One to many
 Many to one
 Many to many
MAPPING CARDINALITIES

One to one One to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
MAPPING CARDINALITIES

Many to one Many to many

Note: Some elements in A and B may not be mapped to any
elements in the other set
KEYS

A super key of an entity set is a set of one or

more attributes whose values uniquely
determine each entity.
A candidate key of an entity set is a minimal
super key
Customer_id is candidate key of customer
account_number is candidate key of account
Although several candidate keys may exist, one
of the candidate keys is selected to be the
primary key.
KEYS FOR RELATIONSHIP SETS

 The combination of primary keys of the participating entity sets

forms a super key of a relationship set.

 (customer_id, account_number) is the super key of depositor

 Must consider the mapping cardinality of the relationship set when

deciding what are the candidate keys
 Need to consider semantics of relationship set in selecting the
primary key in case of more than one candidate key
E-R DIAGRAMS

 Rectangles represent entity sets.

 Diamonds represent relationship sets.
 Lines link attributes to entity sets and entity sets to relationship sets.
 Ellipses represent attributes
 Double ellipses represent multivalued attributes. (E.g. Mobile Phone, a
person may have one or many moblle)
 Dashed ellipses denote derived attributes. ( Age can be derived from Date
of Birth)
 Underline indicates primary key attributes (will study later)
E-R DIAGRAM WITH COMPOSITE, MULTIVALUED, AND
DERIVED ATTRIBUTES
RELATIONSHIP SETS WITH ATTRIBUTES
ROLES

 Entity sets of a relationship need not be distinct

 The labels ―manager‖ and ―worker‖ are called roles; they specify how
employee entities interact via the works_for relationship set.
 Roles are indicated in E-R diagrams by labeling the lines that connect
diamonds to rectangles.
 Role labels are optional, and are used to clarify semantics of the
relationship
CARDINALITY CONSTRAINTS

 We express cardinality constraints by drawing either a directed line

(), signifying ―one,‖ or an undirected line (—), signifying ―many,‖
between the relationship set and the entity set.

 One-to-one relationship:
 A customer is associated with at most one loan via the relationship
borrower
 A loan is associated with at most one customer via borrower
ONE-TO-MANY RELATIONSHIP

In the one-to-many relationship a loan is associated with at most one customer

via borrower, a customer is associated with several (including 0) loans via
borrower
MANY-TO-ONE RELATIONSHIPS

In a many-to-one relationship a loan is associated with several

(including 0) customers via borrower, a customer is associated with
at most one loan via borrower
MANY-TO-MANY RELATIONSHIP

 A customer is associated with several (possibly 0) loans via

borrower
 A loan is associated with several (possibly 0) customers via
borrower
 PARTICIPATION OF AN ENTITY SET IN A
RELATIONSHIP SET
 Total participation (indicated by double line): every entity in the entity set
participates in at least one relationship in the relationship set
 E.g. participation of loan in borrower is total
 every loan must have a customer associated to it via borrower
 Partial participation: some entities may not participate in any relationship in
the relationship set
 Example: participation of customer in borrower is partial
ALTERNATIVE NOTATION FOR CARDINALITY LIMITS

 Cardinality limits can also express participation constraints

 1..1 Each loan must have atleast one associted customer

 0..* means a customer can have 0 or more associtied loan
E-R DIAGRAM WITH A TERNARY RELATIONSHIP
DESIGN ISSUES

 Use of entity sets vs. attributes

Choice mainly depends on the structure of the enterprise being
modeled, and on the semantics associated with the attribute in
question.
 Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship set to describe an
action that occurs between entities
 Binary versus n-ary relationship sets
Although it is possible to replace any nonbinary (n-ary, for n > 2)
relationship set by a number of distinct binary relationship sets, a n-
ary relationship set shows more clearly that several entities
participate in a single relationship.
 Placement of relationship attributes
ENTITY SET AND MULTIVALUED ATTRIBUTE

 Employee may have attributed Id, name, street, city , tel-number. The
telephone number is multivalued attribute.

 The telephone may be modeled as Entity relating Customer through

relationship emp-telephone.

Employee emp-telephone telephone

Id name city tel_number location

BINARY VS. NON-BINARY RELATIONSHIPS

Some relationships that appear to be non-binary may be better represented

using binary relationships

 E.g. A ternary relationship parents, relating a child to his/her father and

mother, is best replaced by two binary relationships, father and mother
 Using two binary relationships allows partial information (e.g. only mother
being know)
 But there are some relationships that are naturally non-binary
 Example: works_on
CONVERTING NON-BINARY RELATIONSHIPS TO
BINARY FORM
In general, any non-binary relationship can be represented using binary relationships by
creating an artificial entity set.
 Replace R between entity sets A, B and C by an entity set E, and three relationship sets:
1. RA, relating E and A 2.RB, relating E and B
3. RC, relating E and C
 Create a special identifying attribute for E
 Add any attributes of R to E
 For each relationship (ai , bi , ci) in R, create
1. a new entity ei in the entity set E 2. add (ei , ai ) to RA
3. add (ei , bi ) to RB 4. add (ei , ci ) to RC