The Entity-Relationship Model

The Entity-Relationship model

The E-R model is a detailed, logical representation of the
data for an organisation or business area
It should be understandable to both the user and to the IT
technologist
The model must be as open as possible and not tied to
any technology or to any particular business methodology
It must be flexible enough so that it can be used and
understood in practically any environment where
information is modelled
 The ER model
It is expressed in terms of entities in the business
environment, the relationships (or associations) among
those entities and the attributes (properties) of both the
entities and their relationships
The E-R model is usually expressed as an E-R diagram
 E-R Model Constructs
Entity - person, place, object, event, concept
Entity Type - is a collection of entities that share common
properties or characteristics. Each entity type is given a name,
since this name represents a set of items, it is always singular.
It is placed inside the box representing the entity type (Fig. 3-
1)
Entity instance is a single occurrence of an entity type. An
entity type is described just once (using metadata) in a
database, while many instances of that entity type may be
represented by data stored in the database. e.g. there is one
EMPLOYEE entity type in most organisations, but there may
be hundreds of instances of this entity stored in the database
Sample E-R Diagram
 Entity type versus system input,
output or user
A common mistake is to confuse data entities with other
elements of the IS model
A simple rule is that a true data entity will have many
possible instances, each with a distinguishing
characteristic
Treasurer is the person entering data and data about the
treasurer need not be kept
 Entity type versus system input,
output or user
Is the expense report entity necessary? It is only the result
of extracting data from the database. Even though there
will be multiple instances of expense reports given to the
treasurer over time, data needed to compute the report
contents each time are already represented by the
ACCOUNT and EXPENSE entity types
Gives-to and Receives are business activities, not
relationships between entities.
 Example of inappropriate entities
(a) System user (Treasurer) and output
(Expense Report) shown as entities
(b) E-R model with only the necessary entities
Strong versus Weak entity type

Most of the basic entity types are classified as strong entity

types [Rectangle] one that exists independently from
other entity types (such as EMPLOYEE)
Always have a unique characteristic (identifier) an
attribute or combination of attributes that uniquely
distinguish each occurrence of that identity
A weak entity type [[Double Rectangle]] existence depends
on some other entity type. It has no meaning in the ER
diagram without the entity on which it depends (such as
DEPENDENT)
The entity type on which the weak entity type depends is
called the Identifying owner (or owner for short).
Strong versus Weak entity type
Identifying relationship is the relationship
between a weak entity type and and its owner
(such as Has in the following Fig.)
Weak entity identifier is its partial identifier
(double underline) combined with that of its
owner. During a later design stage dependent
name will be combined with Employee_ID (the
identifier of the owner) to form a full identifier
for DEPENDENT.
Example of a weak entity
 Attributes
An attribute is a property or characteristic of an entity
type, for example the entity EMPLOYEE may have
attributes Employee_Name and Employee_Address.
In ER diagrams place attributes name in an ellipse with a
line connecting it to its associated entity
Attributes may also be associated with relationships
An attribute is associated with exactly one entity or
relationship
 Simple versus composite
attributes (following Fig.)
Some attributes can be broken down into meaningful
component parts, such as Address, which can be broken
down into Street_Address, City..etc.
The component attributes may appear above or below the
composite attribute on an ER diagram
Provide flexibility to users, as can refer to it as a single
unit or to the individual components
A simple (atomic) attribute is one that cannot be broken
down into smaller components
A composite attribute
 Single-Valued versus
Multivalued Attribute
It frequently happens that there is an attribute that may
have more than one value for a given instance, e.g.
EMPLOYEE may have more than one Skill.
A multivalued attribute is one that may take on more than
one value it is represented by an ellipse with double lines
Entity with a multivalued attribute (Skill)
and derived attribute (Years_Employed)
Ternary relationships
Introducing cardinality constraints

(a) Basic relationship

(b) Relationship with cardinality constraints
Mandatory cardinalities
Cardinality constraints in a ternary relationship
Simple example of time stamping
(b) Professors and courses (fixed upon constraint)