CT – 494 INTRODUCTION TO DATABASES

LECTURE 3
DATA MODELS:
ENTITY RELATIONSHIP MODEL
HUMA TABASSUM
DEPARTMENT OF COMPUTER SCIENCE & INFORMATION TECHNOLOGY
NED UNIVERSITY OF ENGINEERING & TECHNOLOGY
DATA MODEL
• A model is the representation of reality that retains only selected
details.
• A data model is a collection of conceptual tools for describing data
(about entities, activities, events), data relationships, data semantics,
and integrity constraints.
• Purpose is to represent data and make the data understandable.
• DDL is too low-level to be used as an easily understandable
representation of data for many users.
• Therefore, data model provides a high-level description of data requirements
of an organization.
• Limitations?
• Semantics
Components of a Data Model

• Structural – rules to construct db.

• Manipulative – types of operations allowed on data and db.

• Integrity Rules – to ensure data is accurate.

Categories of Data Models
• Object-based Data Models – describe data at external and conceptual level.
• Entity Relationship Model
• Semantic Model
• Functional Model
• Object-Oriented Model

• Record-based Data Models – describe data at external, conceptual and to

some extent, internal level.
• Relational Data Model
• Network Data Model
• Hierarchical Data Model

• Physical Data Model – describe how data is stored in the computer.

ENTITY-RELATIONSHIP (ER) MODEL
• Detailed and conceptual representation of data of an organization.

• Based on perception of real-world.

• ER Model is considered as a semantic data model.

• Used for interaction between end-user and db designer

Basic Concepts
• Entity Set (ES)
• Entity
• A thing or object in the real-world that is distinguishable from all other objects.
• Every entity has some set of properties some of which have values distinguishable from
others.
• Can be
• Concrete: For example, student, book, automobile, employee.
• Abstract: For example, bank account, course, exam.
• Entity Set
• Collection of entities of same type that share the same set of properties.
• Each entity is an extension of its associated ES.
• ESs need not be disjoint.
• Each entity may be a part of different ESs.
• Attributes
• An attribute is a descriptive property of an ES or RS.
• Domain:
• Set of allowable values of an attribute.
• For example, Roll No. is a set of positive integers, Name is a set of character strings of a
maximum length containing alphabets only.
• Types of Attributes
• Simple vs Composite
• Simple: No sub-parts (Marks obtained)
• Composite: Have sub-parts (Address, Telephone Number)
• Single vs Multi-Valued
• Single: LoanID, Bank Balance
• Multi-Valued: Possess multiple values for a given entity. (Tel. No., Dependent Name, Degree)
• Stored vs Derived
• Stored: Date of Birth, Hiring Date
• Derived: Age, Tenure
• Null: Not a value, but absence of a value. Can be
• Not Applicable: Middle Name
• Unknown
• Missing: Exists, but don’t have the information.
• Not known: Don’t know if the value exists or not.
• Relationship Set (RS)
• Relationship: Association between entities.
• May have descriptive attributes.
• Relationship Set (RS): Set of relationships of same type.
• Participation: Involvement of an ES in a RS.
• Role: The function that an entity plays in a relationship.
• Degree of RS: Number of ESs participating in a RS.
• Unary, binary, ternary, n-ary.
• Constraints:
• Mapping Cardinality or Cardinality Ratio
• Expresses the number of entities to which another entity can be associated via RS.
• 1-1, 1-M, M-1, M-M.
• Participation Constraint
• Total: Each entity in ES is involved in at least one relationship in the RS.
• Partial: Not all entities are involved.
Notations
• Chen’s Notation

• Crow’s Foot Notation

• UML Notation

• Martin Style

• Refer to separately provided material.

Keys
• A form of constraint.
• Keys are the mechanism to uniquely identify an entity in an ES.
• Super Key: Set of one or more attributes that taken collectively, uniquely
identifies an entity in an ES.
• Empno, Ename
• {Roll No., Batch, Dname, Sname, Telno}

• Candidate Key: A super key whose proper subset is not a super key.
• Empno – 1 key (simple)
• {Roll No., Batch, Dname} – 1 key (composite)
• Has two properties
• Uniqueness
• Irreducibility
• An ES can have more than one C.Ks.
• Primary Key: The C.K. that is chosen by the db designer as the
principal means of identifying an entity in an ES.
• Can never be null.
• Should be chosen so that attributes do not change frequently.
• P.K. can be simple or composite.

• Alternate Key: A C.K. that is not selected as P.K.

• Concept of key is applicable not only on ES, but on RS as well.

DRAW AN ERD OF YOUR CHOICE
DESIGN ISSUES
• Notions of ES and RS are not precise, and the same set of entities and
their relationships can be associated in several ways.
• Use of ES vs Attributes
• Use of ES vs RS
• Placement of Attributes
• Depends on mapping cardinality (MC).
• Unary RS/ Recursive RS
• Ternary RS
• Weak ESs
EXTENDED ER MODEL
• Specialization
• An ES may include subgroupings of entities that are distinct in some way from
other entities in the set.
• For example, Person can be Employee or Customer.
• Each of these Person types is described by a set of attributes that includes all the
attributes of entity set person plus possibly additional attributes.
• The process of designating subgroupings within an entity set is called
specialization.
• The specialization of Person allows us to distinguish among person entities according to
whether they correspond to employees or customers.
• This is a top-down approach.
• As another example, suppose the university divides students into two
categories: graduate and undergraduate.
• Generalization
• The design process may also proceed in a bottom-up manner, in which multiple
ESs are synthesized into a higher-level ES based on common features.
• For example, the db designer may have first identified Officer ES, Secretary ES, and Teller ES.

• There are similarities between these ESs as they have several attributes that are
conceptually the same across the three ESs: namely, the id, name, and salary
attributes.

• This commonality can be expressed by generalization, which is a containment

relationship that exists between a higher-level ES and one or more lower-level ESs.
• In our example, employee is the higher-level entity set and officer, secretary, and teller are
lower-level entity sets.
• Aggregation
• One limitation of the E-R model is that it cannot express relationships among relationships.
• Consider the ternary relationship works-on between employee, branch, and job.
• Suppose we want to record managers for tasks performed by an employee at a branch.
• That is, we want to record managers for (employee, branch, job) combinations.
• One alternative for representing this relationship is to create a quaternary (4-way) RS manages
between employee, branch, job, and manager.
• A quaternary relationship is required—a binary relationship between manager and employee would not
permit us to represent the (branch, job) combination of an employee are managed by which manager.
• It appears that the RSs works-on and manages can be combined into one single RS.
• But we should not combine them into a single relationship, since some employee, branch, job
combinations may not have a manager.
• The best way to model a situation such as the one just described is to use aggregation.
• Aggregation is an abstraction through which relationships are treated as higher level entities.
• Thus, for our example, we regard the RS works-on (relating the entity sets employee, branch, and job) as
a higher-level ES called works-on.
• Such an ES is treated in the same manner as any other ES.
• We can then create a binary relationship manages between works-on and manager to represent who
manages what tasks.
Problem
• Consider a hospital with a set of medical doctors and a set of patients.
For each doctor, hospital records doctorID, name, join date, and field
of specialization. For each patient the hospital records patient name,
date of birth, blood group, and gender. Patient may either be an out-
patient or admitted patient. For out-patient the hospital records visit
date, blood pressure, and medicines recommended. For admitted
patients, hospital records date of admission, date of discharge, and
room number. Associated with each patient is a log of various tests
and examinations conducted. For each test, record test date, test
type, and observation.
• Construct an ER model showing entities, relationships, mapping
cardinalities, and other constraints.
Assumptions
• A doctor examines different patients and a patient can consult
multiple doctors.
• Every doctor examines at least one patient.
• A given patient undergoes only one type of test on a given date.