ER Model Design

Conducted by
Hasan Muhammad Kafi
Assistant Professor, Dept. of CSE
Bangladesh Army University of Science and Technology (BAUST)
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
Representing Cardinality Constraints in
ER Diagram
• 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 between an instructor and a student :

 A student is associated with at most one instructor via the relationship
advisor
 A student is associated with at most one department via stud_dept
One-to-Many Relationship
• One-to-many relationship between an instructor and a student

 an instructor is associated with several (including 0) students via advisor

 a student is associated with at most one instructor via advisor
Many-to-One Relationships
• In a many-to-one relationship between an instructor and a student

 an instructor is associated with at most one student via advisor,

 and a student is associated with several (including 0) instructors via advisor
Many-to-Many Relationship
• An instructor is associated with several (possibly 0) students via advisor
• A student is associated with several (possibly 0) instructors via advisor
Total and Partial Participation
• Total participation (indicated by double line): every entity in the entity
set participates in at least one relationship in the relationship set

participation of student in advisor relation is total

 every student must have an associated instructor
• Partial participation: some entities may not participate in any
relationship in the relationship set
 Example: participation of instructor in advisor is partial
Notation for Expressing More Complex
Constraints
• A line may have an associated minimum and maximum cardinality, shown in
the form l..h, where l is the minimum and h the maximum cardinality
 A minimum value of 1 indicates total participation.
 A maximum value of 1 indicates that the entity participates in at most one
relationship
 A maximum value of * indicates no limit.
• Example

 Instructor can advise 0 or more students. A student must have 1 advisor; cannot
have multiple advisors
Cardinality Constraints on Ternary
Relationship
• We allow at most one arrow out of a ternary (or greater degree) relationship to
indicate a cardinality constraint
• For example, an arrow from proj_guide to instructor indicates each student has at
most one guide for a project
• If there is more than one arrow, there are two ways of defining the meaning.
 For example, a ternary relationship R between A, B and C with arrows to B and C
could mean
 Each A entity is associated with a unique entity from and C or
 Each pair of entities from (A, B) is associated with a unique C entity, and
each pair (A, C) is associated with a unique B

 Each alternative has been used in different formalisms

 To avoid confusion we outlaw more than one arrow
Primary Key
• Primary keys provide a way to specify how entities and relations are
distinguished. We will consider:

 Entity sets
 Relationship sets.
 Weak entity sets
Primary key for Entity Sets
• By definition, individual entities are distinct.
• From database perspective, the differences among them must be expressed
in terms of their attributes.
• The values of the attribute values of an entity must be such that they can
uniquely identify the entity.
• No two entities in an entity set are allowed to have exactly the same value for
all attributes.

• A key for an entity is a set of attributes that suffice to distinguish entities

from each other
Primary Key for Relationship Sets
• To distinguish among the various relationships of a relationship set we use
the individual primary keys of the entities in the relationship set.
 Let R be a relationship set involving entity sets E1, E2, .. En
 The primary key for R is consists of the union of the primary keys of entity sets E1,
E2, ..En
 If the relationship set R has attributes a1, a2, .., am associated with it, then the primary
key of R also includes the attributes a1, a2, .., am

• Example: relationship set “advisor”.

 The primary key consists of instructor.ID and student.ID

• The choice of the primary key for a relationship set depends on the mapping
cardinality of the relationship set.
Choice of Primary key for Binary
Relationship
• Many-to-Many relationships. The preceding union of the primary keys is a
minimal superkey and is chosen as the primary key.
• One-to-Many relationships . The primary key of the “Many” side is a
minimal superkey and is used as the primary key.
• Many-to-one relationships. The primary key of the “Many” side is a
minimal superkey and is used as the primary key.
• One-to-one relationships. The primary key of either one of the participating
entity sets forms a minimal superkey, and either one can be chosen as the
primary key.
Weak Entity Sets
• Consider a section entity, which is uniquely identified by a course_id,
semester, year, and sec_id.
• Clearly, section entities are related to course entities. Suppose we create a
relationship set sec_course between entity sets section and course.
• Note that the information in sec_course is redundant, since section already
has an attribute course_id, which identifies the course with which the
section is related.
• One option to deal with this redundancy is to get rid of the relationship
sec_course; however, by doing so the relationship between section and
course becomes implicit in an attribute, which is not desirable.
Weak Entity Sets (Cont.)
• An alternative way to deal with this redundancy is to not store the attribute
course_id in the section entity and to only store the remaining attributes section_id,
year, and semester.
 However, the entity set section then does not have enough attributes to identify a
particular section entity uniquely
• To deal with this problem, we treat the relationship sec_course as a special
relationship that provides extra information, in this case, the course_id, required
to identify section entities uniquely.
• A weak entity set is one whose existence is dependent on another entity, called
its identifying entity
• Instead of associating a primary key with a weak entity, we use the identifying
entity, along with extra attributes called discriminator to uniquely identify a
weak entity.
Weak Entity Sets (Cont.)
• An entity set that is not a weak entity set is termed a strong entity set.
• Every weak entity must be associated with an identifying entity; that is, the
weak entity set is said to be existence dependent on the identifying entity
set.
• The identifying entity set is said to own the weak entity set that it identifies.
• The relationship associating the weak entity set with the identifying entity
set is called the identifying relationship.
• Note that the relational schema we eventually create from the entity set
section does have the attribute course_id, for reasons that will become clear
later, even though we have dropped the attribute course_id from the entity
set section.
Expressing Weak Entity Sets
• In E-R diagrams, a weak entity set is depicted via a double rectangle.
• We underline the discriminator of a weak entity set with a dashed line.
• The relationship set connecting the weak entity set to the identifying strong
entity set is depicted by a double diamond.
• Primary key for section – (course_id, sec_id, semester, year)
Redundant Attributes
• Suppose we have entity sets:
 student, with attributes: ID, name, tot_cred, dept_name
 department, with attributes: dept_name, building, budget
• We model the fact that each student has an associated department using a
relationship set stud_dept
• The attribute dept_name in student below replicates information present in the
relationship and is therefore redundant
 and needs to be removed.
• BUT: when converting back to tables, in some cases the attribute gets reintroduced,
as we will see later.
E-R Diagram for a University Enterprise