Entity-Relationship (ER) Model

The entity-relationship (E-R) data model perceives the real world as consisting of basic objects,
called entities, and relationships among these objects. It was developed to facilitate database
design by allowing specification of a schema, which represents the overall logical structure of a
database. The E-R model is very useful in mapping the meanings and interactions of real-world
enterprises onto a conceptual schema. Thus 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 attribute.
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.
A relationship is an association among several entities
Example:
Hayes depositor A-02
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
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.
The 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.
Relationships between
more than two entity sets
are rare. Most
relationships are binary.

Attributes can be of the following types,

• Simple and composite attributes. Simple attributes can not divided into subparts.
Composite attributes, on the other hand, can be divided into subparts (that is, other
attributes). For example, an attribute name could be structured as a composite
attribute consisting of first-name, middle-initial, and last-name. Using composite
attributes in a design schema is a good choice if a user will wish to refer to an entire
attribute on some occasions, and to only a component of the attribute on other
occasions. Suppose we were to substitute for the customer entity-set attributes
customer-street and customer-city the composite attribute address with the attributes
street, city, state, and zip-code.2 Composite attributes help us to group together
related attributes, making the modeling cleaner. A composite attribute may appear as
a hierarchy. Eg. composite attribute address, can be further divided into street-
number, street-name, and apartment-number.
• Single-valued and multivalued attributes. Single-valued attributes have a single
value for a particular entity. For instance, the loan-number attribute for a specific loan
entity refers to only one loan number. There may be instances where an attribute has a
set of values for a specific entity. Eg. an employee entity set with the attribute phone-
number. An employee may have zero, one, or several phone numbers, and different
employees may have different numbers of phones. This type of attribute is said to be
multivalued.
• Derived attribute. The value for this type of attribute can be derived from the values
of other related attributes or entities. For instance, let us say that the customer entity
set has an attribute loans-held, which represents how many loans a customer has from
the bank. We can derive the value for this attribute by counting the number of loan
entities associated with that customer. The value of a derived attribute is not stored,
but is computed when required.
• An attribute takes a null value when an entity does not have a value for it. The null
value may indicate “not applicable”—that is, that the value does not exist for the
entity. For example, one may have
no middle name. Null can also
designate that an attribute value is
unknown. An unknown value may
be either missing (the value does
exist, but we do not have that
information) or not known (we do
not know whether or not the value
 actually exists).

Mapping Cardinality Constraints - express the

number of entities to which another entity can be
associated via a relationship set. It is 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. 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.
• One to many. An entity in A is associated with any
number (zero or more) of entities in B. An entity in B,
however, can be 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,
however, can be associated with any number (zero or more)
of entities in A.
• Many to many. An entity in A is associated with any number (zero or more) of entities
in B, and an entity in B is associated with any number (zero or more) of entities in A.

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, as the principal means of identifying entities within an entity set. 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

E-R Diagrams consists of the following major components:

Rectangles, which represent entity
sets Ellipses, which represent
attributes
O Double ellipses, which represent multivalued attributes
 O Dashed ellipses, which denote derived
attributes Diamonds, which represent relationship
sets
Lines, which link attributes to entity sets and entity sets to relationship sets
Double lines, which indicate total participation of an entity in a relationship set

Double rectangles, which represent weak entity sets

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.

Partialparticipation:
some entities may not participate in any relationship in the relationship set. Example:
participation of customer in borrower is partial.
An entity set that does not have sufficient attributes to form a primary key is called as a weak
entity set. Considering the entity set. payment, which has the three attributes: payment-
number, payment-date, and payment-amount. Payment numbers are typically sequential
numbers, starting from 1, generated separately for each loan. Thus, although each payment
entity is distinct, payments for
different loans may share the
same payment number. Thus,
this entity set does not have a
primary key; it is a weak entity
set. For a weak entity set to be meaningful, it must be associated with another entity set,
called the identifying or owner 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. The identifying relationship is many to one from the
weak entity set to the identifying entity set, and the participation of the weak entity set in the
relationship is total. In our example, the identifying entity set for payment is loan, and a
relationship loan-payment that associates payment entities with their corresponding loan
entities is the identifying relationship.
An entity set that has
a primary key is
termed a strong
entity set.
Key Attributes of an Entity Type: A minimal collection of attributes (often only one) that,
by design, distinguishes any two (simultaneously-existing) entities of that type.

Domains (Value Sets) of Attributes: The domain of an attribute is the "universe of values"
from which its value can be drawn. In other words, an attribute's domain specifies its set of
allowable values. The concept is similar to data type.

Example Database Application: COMPANY

Requirements of the Company

 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 departmentmanager.
 Each department controls a number of PROJECTs. Each project has a name, number
and islocated at a single location
 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 employee.

Suppose that Requirements Collection and Analysis results in the following (informal)
description of the COMPANY miniworld:

The company is organized as a collection of departments.

 Each department
o has a unique name
o has a unique number
o is associated with a set of locations
o has a particular employee who acts as its manager (and who assumed that
position on some date)
o has a set of employees assigned to it
o controls a set of projects
 Each project
o has a unique name
o has a unique number
 o has a single location
o has a set of employees who work on it
o is controlled by a single department
 Each employee
o has a name
o has a SSN that uniquely identifies her/him
o has an address
o has a salary
o has a gender
o has a birthdate
o has a direct supervisor
o has a set of dependents
o is assigned to one department
o works some number of hours per week on each of a set of projects (which
need not all be controlled by the same department)
 Each dependent
o has first name
o has a gender
o has a birthdate
o is related to a particular employee in a particular way (e.g., child, spouse, pet)
o is uniquely identified by the combination of her/his first name and the
employee of which (s)he is a dependent

Initial Conceptual Design of COMPANY database

Using the above structured description as a guide, we get the following preliminary design
for entity types and their attributes in the COMPANY database:

 DEPARTMENT(Name, Number, { Locations }, Manager, ManagerStartDate,

{ Employees }, { Projects })
 PROJECT(Name, Number, Location, { Workers }, ControllingDept)
 EMPLOYEE(Name(FName, MInit, LName), SSN, Sex, Address, Salary, BirthDate,
Dept, Supervisor, { Dependents }, { WorksOn(Project, Hours) })
 DEPENDENT(Employee, FirstName, Sex, BirthDate, Relationship)

Relationship Types, Sets, Roles, and Structural Constraints

Relationship: This is an association between two entities. As an example, one can imagine a
STUDENT entity being associated to an ACADEMIC_COURSE entity via, say, an
ENROLLED_IN relationship.

Whenever an attribute of one entity type refers to an entity (of the same or of a different
entity type), we say that a relationship exists between the two entity types.
From our preliminary COMPANY schema, we identify the following relationship types
(using descriptive names and ordering the participating entity types so that the resulting
phrase will be in active voice rather than passive):

 EMPLOYEE  MANAGES  DEPARTMENT (arising from Manager attribute in

DEPARTMENT)
 DEPARTMENT  CONTROLS  PROJECT (arising from ControllingDept attribute in
PROJECT and the Projects attribute in DEPARTMENT)
 EMPLOYEE  WORKS_FOR  DEPARTMENT (arising from Dept attribute in
EMPLOYEE and the Employees attribute in DEPARTMENT)
 EMPLOYEE  SUPERVISES  EMPLOYEE (arising from Supervisor attribute in
EMPLOYEE)
 EMPLOYEE  WORKS_ON  PROJECT (arising from WorksOn attribute in
EMPLOYEE and the Workers attribute in PROJECT)
 DEPENDENT  DEPENDS_ON  EMPLOYEE (arising from Employee attribute in
DEPENDENT and the Dependents attribute in EMPLOYEE)

In ER diagrams, relationship types are drawn as diamond-shaped boxes connected by lines to

the entity types involved. See Figure 7.2, page 204. Note that attributes are depicted by ovals
connected by lines to the entity types they describe (with multi-valued attributes in double
ovals and composite attributes depicted by trees). The original attributes that gave rise to the
relationship types are absent, having been replaced by the relationship types.

A relationship set is a set of instances of a relationship type. If, say, R is a relationship type
that relates entity types A and B, then, at any moment in time, the relationship set of R will be
a set of ordered pairs (x,y), where x is an instance of A and y is an instance of B. What this
means is that, for example, if our COMPANY miniworld is, at some moment, such that
employees e1, e3, and e6 work for department d1, employees e2 and e4 work for department d2,
and employees e5 and e7 work for department d3, then the WORKS_FORrelationship set will
include as instances the ordered pairs (e1, d1), (e2, d2), (e3, d1), (e4, d2), (e5, d3), (e6, d1), and (e7,
d3).

Degree of a relationship type:

Also note that, in our COMPANY example, all relationship instances will be ordered pairs, as
each relationship associates an instance from one entity type with an instance of another (or
the same, in the case of SUPERVISES) entity type. Such relationships are said to be binary,
or to have degree two. Relationships with degree three (called ternary) or more are also
possible, but they do not arise as often in practice.

Roles in relationships: Each entity that participates in a relationship plays a particular role in
that relationship, and it is often convenient to refer to that role using an appropriate name. For
example, in each instance of a WORKS_FOR relationship set, the employee entity plays the
role of worker or (surprise!) employee and each department plays the role of employer or
(surprise!) department. Indeed, as this example suggests, often it is best to use the same name
for the role as for the corresponding entity type.

An exception to this rule occurs when the same entity type plays two (or more) roles in the
same relationship. (Such relationships are said to be reCURsive, which I find to be a
misleading use of that term. A better term might be self-referential.) For example, in each
instance of a SUPERVISES relationship set, one employee plays the role of supervisor and
the other plays the role of supervisee.

Constraints on Binary Relationship Types

Often, in order to make a relationship type be an accurate model of the miniworld concepts
that it is intended to represent, we impose certain constraints that limit the possible
corresponding relationship sets. (That is, a constraint may make "invalid" a particular set of
instances for a relationship type.)

There are two main kinds of relationship constraints (on binary relationships). For
illustration, let R be a relationship set consisting of ordered pairs of instances of entity types
A and B, respectively.

 cardinality ratio:
o 1:1 (one-to-one): Under this constraint, no instance of A may particpate in
more than one instance of R; similarly for instances of B. In other words, if
(a1, b1) and (a2, b2) are (distinct) instances of R, then neither a1 = a2 nor b1 = b2.
Example: Our informal description of COMPANY says that every department
has one employee who manages it. If we also stipulate that an employee may
not (simultaneously) play the role of manager for more than one department, it
follows that MANAGES is 1:1.
o 1:N (one-to-many): Under this constraint, no instance of B may participate in
more than one instance of R, but instances of A are under no such restriction.
In other words, if (a1, b1) and (a2, b2) are (distinct) instances of R, then it
cannot be the case that b1 = b2.
Example: CONTROLS is 1:N because no project may be controlled by more
than one department. On the other hand, a department may control any number
of projects, so there is no restriction on the number of relationship instances in
which a particular department instance may participate. For similar reasons,
SUPERVISES is also 1:N.
o N:1 (many-to-one): This is just the same as 1:N but with roles of the two
entity types reversed.
Example: WORKS_FOR and DEPENDS_ON are N:1.
o M:N (many-to-many): Under this constraint, there are no restrictions.
(Hence, the term applies to the absence of a constraint!)
Example: WORKS_ON is M:N, because an employee may work on any
 number of projects and a project may have any number of employees who
work on it.

participation: specifies whether or not the existence of an entity depends upon its being
related to another entity via the relationship.

total participation (or existence dependency): To say that entity type A is constrained to
participate totally in relationship R is to say that if (at some moment in time) R's instance
set is
{ (a1, b1), (a2, b2), ... (am, bm) },

then (at that same moment) A's instance set must be { a1, a2, ..., am }. In other words, there can
be no member of A's instance set that does not participate in at least one instance of R.

According to our informal description of COMPANY, every employee must be assigned to

some department. That is, every employee instance must participate in at least one instance of
WORKS_FOR, which is to say that EMPLOYEE satisfies the total participation constraint
with respect to the WORKS_FOR relationship.

In an ER diagram, if entity type A must participate totally in relationship type R, the two are
connected by a double line

partial participation: the absence of the total participation constraint! (E.g., not every
employee has to participate in MANAGES; hence we say that, with respect to MANAGES,
EMPLOYEE participates partially. This is not to say that for all employees to be managers is
not allowed; it only says that it need not be the case that all employees are managers.

Attributes of Relationship Types

Relationship types, like entity types, can have attributes. A good example is
WORKS_ON, each instance of which identifies an employee and a project on which (s)he
works. In order to record (as the specifications indicate) how many hours are worked by each
employee on each project, we include Hours as an attribute of WORKS_ON. In the case of
an M:N relationship type (such as WORKS_ON), allowing attributes is vital. In the case of
an N:1, 1:N, or 1:1 relationship type, any attributes can be assigned to the entity type opposite
from the 1 side. For example, the StartDate attribute of the MANAGES relationship type can
be given to either the EMPLOYEE or the DEPARTMENT entity type.

Weak Entity Types: An entity type that has no set of attributes that qualify as a key is called
weak. (Ones that do are strong.)

An entity of a weak identity type is uniquely identified by the specific entity to which it is
related (by a so-called identifying relationship that relates the weak entity type with its so-
called identifying or owner entity type) in combination with some set of its own attributes
(called a partial key).
Example: A DEPENDENT entity is identified by its first name together with the
EMPLOYEE entity to which it is related via DEPENDS_ON. (Note that this wouldn't work
for former heavyweight boxing champion George Foreman's sons, as they all have the name
"George"!)

Because an entity of a weak entity type cannot be identified otherwise, that type has a total
participation constraint (i.e., existence dependency) with respect to the identifying
relationship.

This should not be taken to mean that any entity type on which a total participation constraint
exists is weak. For example, DEPARTMENT has a total participation constraint with respect
to MANAGES, but it is not weak.

In an ER diagram, a weak entity type is depicted with a double rectangle and an identifying
relationship type is depicted with a double diamond.