Conceptual Modeling and

Entity-Relationship Diagrams

Chapter 3: Elmasri/Navathe
 Outline
 Phases of Database Design
 Conceptual Modeling
 Abstractions in Conceptual Design
 Example Database Requirements
 Deconstructing the E-R Diagram
 Entities, Attributes and Relationships
 Participation, Cardinality and Keys

2
 Phases of Database Design
Application Domain

Requirements Analysis

DBMS Database Requirements

Independent
Conceptual Design

Conceptual Schema
Data Model Mapping
Implementation Schema

DBMS Physical Design

Dependent
Physical Schema
3
Conceptual Design
 Similar to the analysis phase in software
development
 produce a description of the data
 capture the semantics of the data
 Description in a high-level model
 close to the user’s view of the world
 abstract concepts
 means of communication between the user and
the developer

4
Reasons for Conceptual Modeling
 Independent of DBMS.
 Allows for easy communication between
end-users and developers.
 Has a clear method to convert from
high-level model to relational model.
 Conceptual schema is a permanent
description of the database
requirements.

5
Abstractions in Conceptual
Design
 As abstraction is a mental process
where we select some set of properties
of an object and exclude others.
 Examples?
 3 types of abstractions
 classification
 aggregation
 generalization

6
 Classification
 Define a class of real-world objects with
common properties
Month

January February … December

7
 Aggregation
 Define a new class from a set of other
classes that represent component parts

Car

Tires Steering Wheel Engine Gas pedal

8
Generalization
 Defines a subset relationship between
elements of 2 or more classes
Person

Employee

Faculty Staff Student

9
Entity-Relationship Model
 Most popular conceptual model for
database design
 Basis for many other models
 Describes the data in a system and how
that data is related
 Describes data as entities, attributes
and relationships

10
Database requirements
 We must convert the written database
requirements into an E-R diagram
 Need to determine the entities,
attributes and relationships.
 nouns = entities
 adjectives = attributes
 verbs = relationships

11
Acadia Teaching Database
Design an E-R schema for a database to store info about
professors, courses and course sections indicating the following:
 The name and employee ID number of each professor

 The salary and email address(es) for each professor

 How long each professor has been at the university

 The course sections each professor teaches

 The name, number and topic for each course offered

 The section and room number for each course section

 Each course section must have only one professor

 Each course can have multiple sections

12
 Visual View of the Database
Employee ID Start Date Years Teaching Section ID Room

N
Professor
1
teaches Section
Email

Salary First
Name Part of

Last
1

Number Course

Topic Name
The Pieces
 Objects
 Entity (including weak entities)
 Attribute
 Relationship
 “Structural” Constraints
 Cardinality
 Participation

14
Entities
 Entity – basic object of the E-R model
 Represents a “thing” with an independent
existence
 Can exist physically or conceptually
 a professor, a student, a course
 Entity type – used to define a set of
entities with the same properties.

15
 Entity and Entity Types
Name
Number Topic
Entity Type
Course

Number: 1123

Entity Name: Computer Programming 2

Topic: Computer Programming

16
Attributes
 Each entity has a set of associated properties
that describes the entity. These properties
are known as attributes.
 Attributes can be:
 Simple or Composite
 Single or Multi-valued
 Stored or Derived
 NULL

17
 Attributes (cont’d)

Simple Professor Start Date

First
Professor
Composite Name
Last

18
 Attributes (cont’d)

Single Professor Employee ID#

Multi-Valued Professor Email

19
 Attributes (cont’d)

Stored Professor Start Date

Derived Professor Years Teaching

20
Attributes (cont’d)
 NULL attributes have no value
 not 0 (zero)
 not a blank string
 Attributes can be “nullable” where a null
value is allowed, or “not nullable” where
they must have a value.

21
 Primary Keys
Professor Employee ID

 Employee ID is the primary key

 Primary keys must be unique for the
entity in question

22
Relationships
 defines a set of associations between
various entities
 can have attributes to define them
 are limited by:
 Participation
 Cardinality Ratio

23
 Relationships (cont’d)

Section part of Course

24
 Participation
 Defines if the existence of an entity depends
on it being related to another entity with a
relationship type.
 Partial
 Total

Section part of Course

25
Cardinality
 The number of relationships that an
entity may participate in.
 1:1, 1:N, N:M, M:1

N 1
Section part of Course

26
Weak entity
 Weak entities do not have key attributes of
their own.
 Weak entities cannot exist without another a
relationship to another entity.
 A partial key is the portion of the key that
comes from the weak entity. The rest of the
key comes from the other entity in the
relationship.
 Weak entities always have total participation
as they cannot exist without the identifying
relationship.
27
 Weak Entity (cont’d)
Section ID Section

Identifying Relationship part of

Number
Course
28
 Review of the E-R Diagram
Employee ID Start Date Years Teaching Section ID Room

N
Email Professor
1
teaches Section

Salary First
Name Part of

Last
1

Number Course

Topic Name
University DB Case Study
 Maintain the following information
about undergrad students:
 Name, address, student number, date of
birth, year of study, degree program (BA,
BSc, BCS), concentration (Major, Honours,
etc) and department of concentration.
 Note: An address is composed of a street, city,
province and postal code; the student number
is unique for each student

30
University Case Study (cont’d)
 Maintain information about departments
 Name, code (CS, Phy), office phone, and faculty
members
 Maintain information about courses:
 Course number (3753), title, description,
prerequisites.
 Maintain information about course sections:
 Section (A, B, C), term (X1), slot #, instructor

31
University Case Study (cont’d)
 Maintain information about faculty:
 Name, rank, employee number, salary,
office number, phone number and email
address.
 Note: employee number is unique
 Maintain a program of study for the
current year for each student:
 i.e. courses that each student is enrolled in
32
Extended E-R Model
 E-R model is sufficient for traditional
database applications
 Nontraditional applications (CAD,
multimedia) have more complex
requirements
 Can extend traditional E-R diagrams
with semantic data modeling concepts

33
IS-A Relationship
 EER model includes concepts of
subclass and superclass
 subclass is a subgroup of an entity type

E1 IS-A E2 and e ∈ E1 ⇒ e ∈ E2
 provides type inheritance
 supports specialization and
generalization abstractions
34
 IS-A Relationship (cont’d)
Name Employee S.I.N.

Staff Teaching Assistant

Faculty

Position Rank Student #

35
Specialization & Generalization
 Specialization
 process of taking an entity and creating
several specialized subclasses
 Generalization
 process of taking several related entities
and creating a general superclass
 We will talk mainly of specialization, but
most information will also apply to
generalization
36
Specialization constraints
 Specializations can be predicate-defined
or attribute-defined (otherwise called
user-defined)
 Disjointness constraint – specializaion is
disjoint or overlapping
 Completeness constraint – specialization
is total or partial

37
Predicate-defined subclass
 An attribute value is used to determine the
members of a subclass
 Not all members of every subclass can be
determined by the attribute value
 In the following example, the Pension Plan
type can be used to determine faculty from
staff, but has no effect on students or those
who opted out of the pension plan.

38
 Predicate-defined subclass
Pension Employee S.I.N.
Plan Type
Note: not all
d
employees included

Staff Faculty

Position Rank
39
Attribute-defined subclass
 There is one defining attribute for all
subclasses
 Each member of the superclass can be
assigned to the appropriate subclass
based on this one attribute

40
 Attribute-defined subclass
Jobtype Employee S.I.N.
Jobtype
d
“Staff” “Faculty”

“Student”
Staff Students Faculty

Rank Year Rank

41
User-defined subclass
 When there is no condition to
automatically determine membership in
a subclass, it must be done at the
discretion of the user.

42
Disjointness constraint
 Specifies that an entity can be a
member of at most one subclass
 There can be no overlap between the
subclasses
 We use the notation of a d in a circle to
symbolize that the subclasses are
disjoint

43
 Disjoint constraint
Name Employee S.I.N.

Staff Teaching Assistant

Faculty

Position Rank Student #

44
Overlap
 Entities are able to belong to more than
one subclass
 Notation is an o inside of a circle

45
 Overlap
Jobtype Employee S.I.N.

A staff member may

o also be a student

Staff Students Faculty

Rank Year Rank

46
Completeness Constraint
 May be total or partial
 for total, every entity in the superclass
must belong to a subclass
 for partial, entities in the superclass do
not need to be part of any subclass
 notation for total and partial are the
same as in a regular E-R diagram –
single and double lines

47
 Partial
Jobtype Employee S.I.N.

Staff Students Faculty

Rank Year Rank

48
 Total
Jobtype Employee S.I.N.

Staff Students Faculty

Rank Year Rank

49
Case Study-1
Employee Database
A company is organized into departments. Each department has a unique name,
unique number and a particular employer who manages the department. We keep
track of the start date when that employee began managing the department.

A department controls the number of projects each of which has a unique name,
unique number and a single location.

We store each employees name ,number address, salary, gender and dob. An
employee is assigned to one department but may work on several projects which
are not necessarily controlled by the same department. We keep track of number
of hours per week than as employee works on each project. We also keep track of
the direct supervisor of each employee.

We want to keep track of the dependents of each employee for insurance purpose.
We keep each dependents full name, gender, dob and relationship to the employee .

50
Case Study-2 for Practise
Chain of pharmacies

 Patients are identified by an SSN, and their names, addresses, and ages must be recorded.
 Doctors are identified by an SSN. For each doctor, the name, specialty, and years of
experience must be recorded.
 Each pharmaceutical company is identified by name and has a phone number.
 For each drug, the trade name and formula must be recorded.
 Each drug is sold by a given pharmaceutical company, and the trade name identifies a drug
uniquely from among the products of that company. If a pharmaceutical company is
deleted, you need not keep track of its products any longer.
 Each pharmacy has a name, address, and phone number.
 Every patient has a primary physician. Every doctor has at least one patient.
 Each pharmacy sells several drugs and has a price for each. A drug could be sold at several
pharmacies.
 Doctors prescribe drugs for patients. Each prescription has a date and a quantity associated
with it.
 Pharmaceutical company have long-term contracts with pharmacies. A company can
contract with several pharmacy and a pharmacy can contract with several company. Each
contract store a start date, end date and text of contract.
 Each pharmacy appoint a supervisor for each contract. There must be always a supervisor
for each contract. 51
https://onlinecourses.nptel.ac.
in/noc18_cs36/preview
​

52