Database Systems

(The Entity-Relationship Model)

By
Mazhar Iqbal Noor
M.Sc. Computer Sciences (UET)
Head of IT Department
The Children’s Hospital, Lahore-Pakistan.
 Overview of Database Design
• Conceptual design: (ER Model is used at this
stage)
• What are the entities and relationships in the
enterprise?
• What information about these entities and
relationships should we store in the database?
• What are the integrity constraints or business
rules that hold?
• A database `schema’ in the ER Model can be
represented pictorially (ER diagrams).
• Can map an E-R diagram into a relational schema.
E-R Model
• The entity-relationship model (or E-R model)
is a way of graphically representing the logical
relationships of entities in order to create a
database. E-R diagrams are used to express
the logical structure of the model.
• The ER model was first proposed by Peter
Pin-Shan Chen of Massachusetts Institute of
Technology (MIT) in the 1970s.
ER Model Basics
 Entity: Real-world object distinguishable from
other objects. An entity is described (in DB) using
a set of attributes.
Entity Set: A collection of similar entities.
E.g. all employees.
• All entities in an entity set have the same set of
attributes.
• Each entity set has a key.
• Each attribute has a domain.
 Enterprise: For which the Database is designed.
e.g. Goernment agency, school or a hospital.
 Entities: The persons, places, objects or a
concepts in an enterprise for which we collect
information.
e.g. customer, student, class or a patient etc.
 Attributes: The characteristics or properties of an
entity and that the organization considers
important.
e.g. Stu-ID, Name, Pat-ID, address etc.
 Domains: The set of values for each
attribute is called domain of that attribute. For
the student entity example, the domain of
credit attribute might be the set of integer
values between 0 and 150 inclusive.
 Null Values: Some attributes are permitted to
have null values for some entity instances.
This simply means that the value of that
attribute is unknown at that time.
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-tomany relationship set
(one owner, many weak entities).
• Weak entity set must have total participation
in this identifying relationship set.
Example of Weak Entity
 Entity vs. Attribute:
• Should address be an attribute of Employees or an
entity (connected to Employees by a relationship)?
• Depends upon the use we want to make of address
information, and the semantics of the data:
• If we have several addresses per employee, address
must be an entity.
• If the structure (city, street, etc.) is important, e.g., we
want to retrieve employees in a given city, address
must be modeled as an entity (since attribute values
are atomic.
Aggregation
• Used when we have to model a relationship
involving (Entity sets and) a relationship set.
• Aggregation allows us to treat a relationship
set as an entity set .
• for purposes of participation in (other)
relationships.
 A binary relationship type is a relationship
type involving
• exactly two entity types (not necessarily
distinct).
• relationship instance involving exactly two
entity instances.
• binary relationship instance in which the two
entity instances
• Ternary Relationship
• There is at most one related A entity and at
most one related B entity". Is it that it doesn't
apply to a specific kind of relationship?? So, if I
have an example of a student who is in
attendance to a course with a type of subject.
The entities are student, attendance, course
and subject. Student makes attendance in a
room. Also, a student can make attendance
for a subject.
THANKS