Introduction to conceptual data
modeling
Lecture
Instructor Anna Sidorova
Slides
Agenda
g
 Project Proposal and HW 1 discussion
 Review
R
off ERD elements
l
 ERD exercise
 Enhanced ERDs



Weak entities and indentifying relationships
Subtype/ supertype relationships
Entityy clusteringg
 Oracle Designer demonstration – hands on next class
2
Next few classes
 Feb 14 – Introduction to relational DB, Oracle Designer
hands on practice in the lab
 HW 1 is due in class
 Feb
F b 21 – Relational
R l ti l DB
DB, Normalization
N
li ti
 Project Proposal is due
 Feb 28 – Review for the midterm exam
 HW 2 is due
 March 7 – Midterm exam
3
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
HW1
 Draw ERD models for the following descriptions:
 Ch. 2, problems 20, 23
 Ch. 3, problems 12, 15
4
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
Project Proposal
 Title page and the table of contents
 Executive summary
 Problem description including your understanding of the





5
ffunctionall area
The goal and benefits of the project
Th scope off th
The
the project
j t
Your approach to the project
Team composition and relevant experiences
Project Plan
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
Last Class
 DB Schemas
 External – what the users see
 Conceptual
p
– business view,, independent
p
of
technology
 Internal
 Logical
 Physical
6
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
Last class
 Conceptual data modeling
 Representing data in the organization and related business
rules using entity-relationship diagrams
 ERD elements
 Entity – business objects, things
 Attributes – properties of things
 Relationships – associations between things
7
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
ERD Elements
BCIS 4610, Spring 2010
An ERD Example
BCIS 4610, Spring 2010
Reading ERD
BCIS 4610, Spring 2010
What Should an Entityy Be?
 SHOULD BE:
 An object that will have many instances in the database
 An object that will be composed of multiple attributes
 An object that we are trying to model
 SHOULD NOT BE:
BE
 A user of the database system
 An output of the database system (e.g.,
g a report)
Based on Hoffer, Prescott and Topi Modern
11Management, (c) Prentice Hall 2009
Database
Figure 3-4 Example of inappropriate entities
System
user
System output
Inappropriate
pp p
entities
Appropriate
entities
12 on Hoffer, Prescott and Topi Modern Database Management, (c) Prentice Hall 2009
Based
Att ib t
Attributes
 Attribute
Attribute––pproperty
p y or characteristic of an entityy or
relationship type
 Classifications of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single
Si l -Valued
SingleV l d versus Multivalued
M lti l d Attribute
Att ib t
 Stored versus Derived Attributes
 Identifier Attributes
Based on Hoffer, Prescott and Topi Modern
13Management, (c) Prentice Hall 2009
Database
Figure 3-7 A composite attribute
An attribute
broken into
component parts
Figure 3-8 Entity with multivalued attribute (Skill)
and derived attribute (Years_Employed)
Multivalued
an employee can have
more than one skill
Based on Hoffer, Prescott and Topi Modern
14Management, (c) Prentice Hall 2009
Database
Derived
from date
employed and
current date
Id tifi
Identifiers
(Keys)
(K )
 Identifier (Key)
(Key)–
–an attribute (or combination of
attributes)
ib ) that
h uniquely
i l id
identifies
ifi iindividual
di id l iinstances off
an entity type
 Simple versus Composite Identifier
 Candidate Identifier
Identifier–
–an attribute that could be a
key…satisfies
y
the requirements
q
for beingg an identifier
15 on Hoffer, Prescott and Topi Modern Database Management, (c) Prentice Hall 2009
Based
Ch
Characteristics
t i ti off Identifiers
Id tifi
 Will not change
g in value
 Will not be null
 No intelligent
g identifiers (e.g.,
( g , containingg locations or
people that might change)
 Substitute new, simple keys for long,
g composite keys
16 on Hoffer, Prescott and Topi Modern Database Management, (c) Prentice Hall 2009
Based
Figure 3-9 Simple and composite identifier attributes
The identifier is boldfaced and underlined
Based on Hoffer, Prescott and Topi Modern
17Management, (c) Prentice Hall 2009
Database
Relationships
 Associations between entities
 Relationships are characterized by:
 Cardinalityy
 Maximum
 Minimum (also referred to as modality or optionality
optionality))
 Degree (some use the term degree to refer to cardinality)
cardinalit )
 Unary
 Binary
 Ternary
Based on Hoffer, Prescott and Topi Modern
18Management, (c) Prentice Hall 2009
Database
Figure
g
3-10 Relationship
p types
yp and instances
a) Relationship type
b) Relationship
instances
Based on Hoffer, Prescott and Topi Modern
19Management, (c) Prentice Hall 2009
Database
D g
Degree
off R
Relationships
l ti
hi
 Degree of a relationship is the number of entity types that
participate
ti i t iin it
 Unary Relationship
 Binaryy Relationship
p
 Ternary Relationship
Based on Hoffer, Prescott and Topi Modern
20Management, (c) Prentice Hall 2009
Database
Degree of relationships – from Figure 3-2
One entity
related to
another
th off th
the
same entity
type
Entities of two
different types
related to each
other
h
Based on Hoffer, Prescott and Topi Modern
21Management, (c) Prentice Hall 2009
Database
Entities of three
different types
related to each
other
Figure 3-12 Examples of relationships of different degrees
a) Unary relationships
Based on Hoffer, Prescott and Topi Modern
22Management, (c) Prentice Hall 2009
Database
Figure 3-12 Examples of relationships of different degrees (cont.)
b) Binary relationships
Based on Hoffer, Prescott and Topi Modern
23Management, (c) Prentice Hall 2009
Database
Figure 3-12 Examples of relationships of different degrees (cont.)
c) Ternary relationship
Note: a relationship can have attributes of its own
Based on Hoffer, Prescott and Topi Modern
24Management, (c) Prentice Hall 2009
Database
Cardinality of a relationship
 Maximum
 The
Th maximum number
b off instances off entity type A can that
h can
simultaneously have a relationship with each instance of entity type
B
 Can be 1, or many
 Example: How many students (maximum) can be enrolled in a
course? How manyy courses ((maximum)) can each student take?
 Minimum
 The minimum number of instances of entity type A can that can
simultaneously
i lt
l have
h a relationship
l ti hi with
ith eachh iinstance
t
off entity
tit ttype
B
 Can be 0 (optional) or 1 (mandatory)
25
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
Cardinality of Relationships
 One
One--to
to--One
 Each
h entity in the
h relationship
l
h willll hhave exactly
l one related
l d
entity
 One
One--to
to--Manyy
 An entity on one side of the relationship can have many related
entities, but an entity on the other side will have a maximum of
one related entity
 Many
Many--to
to--Many
 Entities on both sides of the relationship can have many related
entities on the
h other
h side
d
Based on Hoffer, Prescott and Topi Modern Database Management, (c) Prentice Hall
26
2009
Figure 3-17 Examples of cardinality constraints
a)) M
Mandatory
d t
cardinalities
di liti
A patient
ti t history
hi t
is
i
recorded for one
and only one
patient
Based on Hoffer, Prescott and Topi Modern
27Management, (c) Prentice Hall 2009
Database
A patient must have
recorded at least one
sto y, and
a d ca
can have
a e
history,
many
Figure 3-17 Examples of cardinality constraints
a)) M
Mandatory
d t
cardinalities
di liti
A patient
ti t history
hi t
is
i
recorded for one
and only one
patient
Based on Hoffer, Prescott and Topi Modern
28Management, (c) Prentice Hall 2009
Database
A patient must have
recorded at least one
sto y, and
a d ca
can have
a e
history,
many
Figure 3-17 Examples of cardinality constraints (cont.)
b) One optional,
optional one mandatory
A project must be
assigned to at least one
employee, and may be
assigned to many
Based on Hoffer, Prescott and Topi Modern
29Management, (c) Prentice Hall 2009
Database
An employee can be
assigned to any number of
projects, or may not be
assigned to any at all
Figure 3-17 Examples of cardinality constraints (cont.)
c)) Optional
O ti l cardinalities
di liti
A person is
married to at most
one other person,
or may not be
married at all
Based on Hoffer, Prescott and Topi Modern
30Management, (c) Prentice Hall 2009
Database
Figure 3-21 Examples of multiple relationships
a) Employees and departments
Entities can be related to one another in more than one way
Based on Hoffer, Prescott and Topi Modern
31Management, (c) Prentice Hall 2009
Database
Figure 3-21 Examples of multiple relationships (cont.)
b) Professors and courses (fixed lower limit constraint)
Here, min
H
i
cardinality
constraint is 2
Based on Hoffer, Prescott and Topi Modern
32Management, (c) Prentice Hall 2009
Database
Oracle Notations
CUSTOMER
# CUST_NO
STUDENT
# SID
places
is_placed
is enrolled
enrolls
BCIS 4610, Spring 2010
ORDER
# ORDER_NO
COURSE1
Based on Hoffer, Prescott and Topi Modern
34Management, (c) Prentice Hall 2009
Database
Let’s practice
 As a part of its project management database, the company wants to store information about
resources (employees), projects and bookings.

For each employee, the following information is stored: Employee ID, First and Last name,
Rank, and billing rate.
 Employees are organized into solution sets, each solution set has a head of the solution set, who
is the resource owner for all employees in that SS. For each solution set we record the SS ID
and the SS name. For scheduling purposes, we want to store information about the head of each
solution set, and about assignment of employees to solution sets. An employee can belong to
only
l one solution
l i set.
 The scheduling system also stores information about projects. For each project, the following
information is stored: Project ID, Status, Location and Client name.

35
As a part off the
A
h scheduling
h d li system, we store information
i f
i about
b bookings.
b ki
When
Wh a bbooking
ki iis
requested for an employee, the employee is scheduled to work on a particular project, on a
particular day for the specified amount of time (10%-100%). So,for each booking we record
date, % of time and current status.
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
Weak and associative entities
Strong vs. Weak Entities, and
Identifying Relationships
 Strongg entities
 exist independently of other types of entities
 has its own unique identifier
 identifier underlined with single line
 Weak
k entity
 dependent on a strong entity (identifying owner)…cannot exist on its own
 does not have a unique identifier (only a partial identifier)
 partial
ti l identifier
id tifi underlined
d li d with
ith double
d bl line
li
 entity box has double line
 Identifying relationship
 links strong entities to weak
eak entities
37
Identifying relationship (Figure 3-5)
Strong entity
38
Weak entity
Associative Entities
 An entity–has attributes
 A relationship– links entities together
 When should a relationship
with attributes instead be an associative entity?
 All relationships for the associative entity should be many
 The associative entity could have meaning independent of the other entities
 The associative entity preferably has a unique identifier, and should also have other
attributes
 The associative entity may participate in other relationships other than the entities of
the associated relationship
 Ternary relationships should be converted to associative entities
Based on Hoffer, Prescott and Topi Modern Database Management, (c) Prentice Hall
39
2009
Figure
g
3-11a A binaryy relationship
p with an attribute
Here, the date completed
p
attribute pertains
p
specifically
p
y to the
employee’s completion of a course…it is an attribute of the
relationship
Based on Hoffer, Prescott and Topi Modern
40Management, (c) Prentice Hall 2009
Database
Figure 3-11b An associative entity (CERTIFICATE)
Associative entity is like a relationship with an attribute, but it is
also considered to be an entity in its own right
Note that the many-to-many cardinality between entities in Figure
3-11a has been replaced by two one-to-many relationships with
the associative entity
Based on Hoffer, Prescott and Topi Modern
41Management, (c) Prentice Hall 2009
Database
Figure 3-13c An associative entity – bill of materials structure
This could just be a relationship with
attributes…it’s a judgment call
Based on Hoffer, Prescott and Topi Modern
42Management, (c) Prentice Hall 2009
Database
Figure 3-18
3 18 Ternary relationship as an associative entity
Based on Hoffer, Prescott and Topi Modern
43Management, (c) Prentice Hall 2009
Database
Alternative notations for associative
entities
titi
PO_LINE
Qty
P_ORDER
PO_No
MATERIAL
Material_No
 PO_LINE is identified by:
 PO_No
 Material_No
_
P_ORDER
# ORDER
ORDER_NO
NO
includes
f
from
PO_LINE
o QTY
BCIS 4610, Spring 2010
is_in
i l d
includes
MATERIAL
# MATERIAL
MATERIAL_NO
NO
Let’s practice
 Ch. 2 problem 15 a, d, e
45
Based on Hoffer, Prescott and Topi Modern
Database Management, (c) Prentice Hall 2009
Subtype/supertype relationships
Supertypes and Subtypes
 Subtype: A subgrouping of the entities in an entity type that has
attributes distinct from those in other subgroupings
 Supertype
Supertype:: A generic entity type that has a relationship with one
or more subtypes
bt
 Attribute Inheritance:
 Subtype
yp entities inherit values of all attributes of the supertype
p yp
 An instance of a subtype is also an instance of the supertype
47
Figure 4-1 Basic notation for supertype/subtype notation
a) EER
notation
Based on Hoffer, Prescott and Topi Modern
48
Database Management, (c) Prentice Hall 2009
Figure 4-1 Basic notation for supertype/subtype notation (cont.)
b) Microsoft
Visio
Notation
Different modeling tools may have different notation
for the same modeling constructs
49
Figure 4-2 Employee supertype with three subtypes
All employee subtypes
will have emp nbr,
name, address, and date
hired
Each employee subtype
will also have its own
attributes
Based on Hoffer, Prescott and Topi Modern
50
Database Management, (c) Prentice Hall 2009
Relationships and Subtypes
 Relationships at the supertype level indicate that all subtypes
will participate in the relationship
 The instances of a subtype may participate in a relationship
unique to that subtype
subtype. In this situation,
situation the relationship is
shown at the subtype level
51
Figure 4-3 Supertype/subtype relationships in a hospital
Both
outpatients
and resident
patients are
cared for by
a responsible
physician
Only resident patients are
assigned to a bed
Based on Hoffer, Prescott and Topi Modern
52
Database Management, (c) Prentice Hall 2009
Generalization and Specialization
 Generalization: The process of defining a more general entity type from
a set of more specialized entity types. BOTTOMBOTTOM-UP
 Specialization: The process of defining one or more subtypes of the
supertype and forming supertype
supertype/subtype
/subtype relationships. TOP
TOP--DOWN
53
Figure 4-4 Example of generalization
a) Three entity types: CAR, TRUCK, and MOTORCYCLE
All these types
yp of vehicles have common attributes
54
Figure 4-4 Example of generalization (cont.)
b) Generalization to VEHICLE supertype
So we put
p
the shared
attributes in
a supertype
Note: no subtype for motorcycle, since it has no unique attributes
55
Figure 4-5 Example of specialization
a)) Entityy type
yp PART
Only applies to
manufactured parts
Applies only to
purchased parts
Based on Hoffer, Prescott and Topi Modern
56
Database Management, (c) Prentice Hall 2009
Figure 4-5 Example of specialization (cont.)
b) Specialization to MANUFACTURED PART and PURCHASED PART
Created 2
subtypes
Note: multivalued attribute was replaced by an
associative entity relationship to another entity
Based on Hoffer, Prescott and Topi Modern
57
Database Management, (c) Prentice Hall 2009
Constraints in Supertype/
Supertype/
Completeness
C
l t
Constraint
C
t i t
 Completeness Constraints:
Constraints: Whether an instance of a supertype must also
be a member of at least one subtype
yp
 Total Specialization Rule:Yes (double line)
 Partial Specialization Rule: No (single line)
58
Figure 4-6 Examples of completeness constraints
a) Total specialization rule
A patient must be either
an outpatient or a
resident patient
Based on Hoffer, Prescott and Topi Modern
59
Database Management, (c) Prentice Hall 2009
Figure 4-6 Examples of completeness constraints (cont.)
b) Partial specialization rule
A vehicle
could be a
car, a truck,
or neither
Based on Hoffer, Prescott and Topi Modern
60
Database Management, (c) Prentice Hall 2009
Constraints in Supertype:
Supertype: Disjointness
constraint
t i t
 Disjointness Constraints: Whether an instance of a supertype may
simultaneously
i l
l be
b a member
b off two
t (or
( more)) subtypes
bt
 Disjoint Rule: An instance of the supertype can be only ONE of the subtypes
 Overlap Rule: An instance of the supertype could be more than one of the subtypes
61
Figure 4-7 Examples of disjointness constraints
a)) Disjoint
j
rule
A patient can either be outpatient
or resident, but not both
Based on Hoffer, Prescott and Topi Modern
62
Database Management, (c) Prentice Hall 2009
Figure 4-7 Examples of disjointness constraints (cont.)
b) Overlap rule
A part may be
both purchased
and
manufactured
Based on Hoffer, Prescott and Topi Modern
63
Database Management, (c) Prentice Hall 2009
Constraints in Supertype/
Supertype/ Subtype
Di i i t
Discriminators
 Subtype Discriminator:
Discriminator: An attribute of the supertype whose
values determine the target subtype(s)
 Disjoint – a simple attribute with alternative values to indicate
the possible subtypes
 Overlapping – a composite attribute whose subparts pertain to
different subtypes. Each subpart contains a boolean value to
indicate whether or not the instance belongs to the associated
subtype
64
Figure 4-8 Introducing a subtype discriminator (disjoint rule)
A simple attribute
with different
possible values
i di ti the
indicating
th
subtype
Based on Hoffer, Prescott and Topi Modern
65
Database Management, (c) Prentice Hall 2009
Figure 4-9 Subtype discriminator (overlap rule)
A composite
attribute with
sub-attributes
indicating “yes”
or “no” to
determine
whether it is of
each subtype
Based on Hoffer, Prescott and Topi Modern
66
Database Management, (c) Prentice Hall 2009
Figure 4-10 Example of supertype/subtype hierarchy
Based on Hoffer, Prescott and Topi Modern
67
Database Management, (c) Prentice Hall 2009
How to show a subtype/supertype
relationship
l ti
hi
ACCOUNT1
# ACCT_NO
o BALANCE
o DATE_OPEN
CHECKING_ACCT
SAVINGS_ACCT
o MONTHLY_FEE
o INTEREST_RATE
BCIS 4610, Spring 2010
Reading ERD
BCIS 4610, Spring 2010
HW 1 discussion