MODELING DATA IN THE

ORGANIZATION
Conceptual Data Modeling
Entity Relationship Diagrams

OBJECTIVES

Define terms related to conceptual modeling

Understand importance of business rules
Learn basic notations for different ER constructs
Write good names and definitions for entities,
relationships, and attributes
Model different types of attributes, entities, and
relationships
Describe cardinality constraints
Convert many-to-many relationships with
attributes to associative entities
Draw an E-R diagram for Pine Valley Furniture
company
2

BUSINESS RULES

Statements that define or constrain some

aspect of the business

A student is a person who has applied for

admission or taken a course from the
university
Every student in the university must have a
faculty adviser

Identifying and understanding business

rules that govern data is what conceptual
data modeling is all about
Entity relationship (ER) diagrams represent
business rules so that they can be
implemented in databases

A GOOD DATA OBJECT NAME SHOULD

BE
Related to business, not technical characteristics

Meaningful and self-documenting

Unique

E.g. Grade Point Average, not Average Grade

Relative to A

Composed of words taken from an approved list

E.g. Home Address vs. Campus Address

Readable

E.g. Customer, not File10

E.g. Maximum instead of Upper Limit or Highest

E.g. Cust for Customer

Repeatable

E.g. Student Birth Date, Employee Birth Date

DATA DEFINITIONS

Explanation of a data object

A course is module of instruction in a particular

subject area
A student is a person who has been admitted
to the school and who has registered for at
least one course

Guidelines for good data definitions

Use common terms and be concise on

essential meaning
Gather definitions from the same sources as
data
Supplement the accompanying data diagrams

E-R MODELING CONSTRUCTS

E-R Model is a conceptual representation of

data using entities, relationships among
those entities, and attributes of both
entities and relationships
Entities

Attributes

Things (e.g., person, place, object, event, concept)

about which organization wishes to maintain data
Properties or characteristics of an entity or
relationship

Relationships

Associations representing interactions among

entities

Basic E-R notation (Figure 2-2)

(There is no industry-standard notation)
Entity
symbols
A special entity
that is also a
relationship
Relationship
degrees
specify
number of
entity types
involved

Attribute
symbols

Relationship
symbols

Relationship
cardinalities
specify how
many of each
entity type is
allowed
7

Sample E-R Diagram (Figure 2-1)

ENTITIES

Things (e.g., person, place, object, event, concept)

about which organization wishes to maintain data

Entity Typea collection of entities that share

common properties

Person: EMPLOYEE, STUDENT, PATIENT

Place: STORE, WAREHOUSE, STATE
Object: MACHINE, BUILDING, AUTOMOBILE
Event: SALE, REGISTRATION,RENEWAL
Concept: ACCOUNT, COURSE, WORK CENTER

A singular noun name in capital letters, placed inside

a box

Entity Instancea single occurrence of an entity type

Strong Entity vs. Weak Entity
Associative Entity
9

ENTITY TYPE AND ENTITY

INSTANCES

We often use the term entity rather than entity type or

entity instance when the meaning is clear from the

10

AN ENTITY

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:

A user of the database system

An output of the database system (e.g., a
report)

Do not confuse data entities with the elements

of data process modeling (such as data flow
diagrams)

11

Figure 2-4 Example of inappropriate entities

System
user

Inappropriate
entities

System
output

Appropriate
entities
12

ATTRIBUTES

Properties of an entity (or relationship) type

Has a singular noun name

Attribute names are placed inside the entity box

For STUDENT (Major, Student Name, Skill)

For VEHICLE (VIN, Color, Horsepower, Model, Year)
Initial capital letter followed by lowercase letters

Do NOT include attributes of related entities

Classifications of attributes

Required versus Optional Attribute

Simple versus Composite Attribute
Single-Valued versus Multivalued Attribute
Stored versus Derived Attribute
Identifier Attribute

13

REQUIRED VS. OPTIONAL

ATTRIBUTES

Required must have a value for

Optional may not have a value
each entity (or relationship)
for each entity (or relationship)
instance
instance
in boldface in ER Diagram
in normal font in ER Diagram
An (optional) attribute without a value is said
to be NULL.
Thus, a required attribute cannot be null .

14

SIMPLE VS. COMPOSITE

ATTRIBUTES

Composite attribute An attribute that

has meaningful component parts
Employee Address
is broken down
into component
parts
Figure 2-7 A composite attribute

Simple (or atomic) attribute An attribute that

cannot be broken down into smaller components
15

SINGLEVALUED VS. MULTIVALUED

and STORED VS. DERIVED ATTRIBUTES
Multivalued may take on more
Derived values can be calculated
than one value for a given entity (or from related attribute values (not
relationship) instance
physically stored in the database)

Figure 2-8 Entity with multivalued attribute {Skill} and derived attribute
[Years Employed]

Multivalued
An employee can
have more than
one skill

multivalued and composite are two different

Derived
Calculated
from Date
Employed
and
Current
Date
16

IDENTIFIER ATTRIBUTE

Identifieran attribute (or combination of

attributes) whose value distinguishes
individual instances of an entity type

no two instances of the same entity type may

have the same value for the identifier attribute
E.g. Identifier for AUTOMOBILE entity is VIN
Identifier attribute is also a required attribute

Simple versus Composite Identifier

Candidate Identifieran attribute that
satisfies the requirements for being an
identifier

E.g. SSN and Student ID for STUDENT entity

17

Figure 2-9 Simple and composite identifier attributes

The identifier
is boldfaced
and underlined

Components of
a composite
identifier is
boldfaced only

18

CRITERIA FOR SELECTING

IDENTIFIERS
Choose an identifier that

Will not change its value over the life of each

instance

Will not be null

Avoid intelligent identifiers whose structure

indicates locations or classifications

E.g. Combination of Employee Name and Payroll

Address should not serve as an identifier for EMPLOYEE
entity

E.g. the first two digits of an identifier value

indicates the warehouse location

Substitute simple identifiers (surrogate

identifier) for large composite identifiers

E.g. Game Number instead of Home Team plus

Visiting Team for GAME entity
19

NAMING ATTRIBUTES

A name should be a singular noun or noun

phrase

e.g. Customer ID, Age, Product Price, Major

A name should be unique

A name should follow a standard format

[Entity type name { [ Qualifier ] } ] Class

A class is a generic property of entities, like amount,

name, and date. A qualifier places a constraint on classes
e.g. Employee Birth Date, Employee Hire Date

Similar attributes of different entity types

should use the same qualifiers and classes

e.g. Faculty Residence City Name, Student

Residence City Name
20

DEFINING ATTRIBUTES

Make it clear what is included and not included in the

attributes value

State the source of attribute values whenever possible

e.g. Employee Department ID is optional if an employee is

not required to be assigned to a department when hired

State min and max number of occurrences allowed

e.g. Customer Standard Industrial Code is the code provided

by FTC

Specify if a value for the attribute is required or

optional

e.g. Employee Monthly Salary is the amount of money paid

each month exclusive of any benefits or bonuses

e.g. Employee Skill Name can list up to 10 skills

Indicate any relationships with other attributes

e.g. Employee Vacation Days is calculated using a formula

involving Employee Years of Service

21

MODELING RELATIONSHIPS

Relationship Types vs. Relationship Instances

Relationships can have attributes

Associations between (or among) entity types vs.

associations between (or among) entity instances
A relationship type is denoted by a line (labeled with
the name of the relationship) between entity types
A relationship instance associates exactly one entity
instance from each participating entity type
These attributes describe features pertaining to the
association between the entities in the relationship

Two entities can have more than one type of

relationship between them (multiple relationships)
Associative Entitycombination of relationship and
entity
22

Figure 2-10 Relationship types and instances

a) Relationship
type

b)
Relationship
instances
Relationships
have a verb
phrase
name in
present tense
You can name
a relationship
in each

23

Figure 2-11a Attribute on a relationship

Date Completed pertains specifically to the employees

completion of a courseit is an attribute of the relationship
An attribute on a relationship is denoted in a rectangle
connected to the relationship line with a dotted line
Attribute on a relationship cannot be associated with a
one-to-many relationship
24

STRONG VS. WEAK ENTITIES,

AND
Strong entity
RELATIONSHIPS
IDENTIFYING
exists independently of
other entities

Weak entity

has its own identifier (an attribute or a combination of

attributes that uniquely distinguish each occurrence of that
entity type) (boldfaced and underlined with a single line)
depends on a strong entity (the identifying owner)cannot
exist on its own
does not have its own identifier (can have a partial identifier)
entity box has a double-lined rectangle and partial identifier
is double underlined

Identifying relationship

links strong entities to weak entities (indicated by a double

line)
25

Figure 2-5 Example of a weak identity and its identifying relationship

Strong entity

Weak entity

Other examples of strong-weak entity pairs include Book-Book

Copy and Course-Course Offering.
26

WEAK ENTITY IS OFTEN A DESIGN

CHOICE
DEPENDENT

EMPLOYEE
Employee ID
Employee Name

Carries

Dependent SSN
Dependent Name
(First Name, Middle
Initial, Last Name)
Date of Birth

Alternative is to have a unique identifier, such as Dependent SSN.

Then DEPENDENT entity can exist independently because
Dependent SSN can identify each instance of the entity without any
identifying owner.
27

DEGREE OF A RELATIONSHIP

Degree of a relationship is the number

of entity types that participate in a
relationship

Unary Relationship (degree 1)

Binary Relationship (degree 2)
Ternary Relationship (degree 3)

28

Degree of a relationship from Figure 2-2

One entity is
related to
itself

Entities of
two different
types are
related to
each other

Entities of three
different types
are related to
each other

29

CARDINALITY OF A
RELATIONSHIP
The maximum number of instances of one

The maximum number of instances of one

entity that can be associated with each
instance of another entity

One-to-One

One-to-Many

Each entity in the relationship will have

exactly one related entity
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-to-Many

Entities on both sides of the relationship can

have many related entities on the other side

30

Figure 2-12 Examples of relationships of different cardinalities

a) Unary relationships (i.e. relationships between the instances of
a single entity type)

31

Figure 2-12 Examples of relationships of different cardinalities (cont

b) Binary relationships (i.e. relationships between the instances of
two entity types)

32

Figure 2-12 Examples of relationships of different cardinalities (cont

c) Ternary relationship (i.e. relationships among the instances of
three entity types)

A ternary relationship is NOT the same as three binary relationships !

33

CARDINALITY CONSTRAINTS

Minimum Cardinality - the minimum number of

instances of entity B that may be associated with
each instance of entity A

If zero, then entity B is optional for entity A

If one, then entity B is mandatory for entity A

Denoted by zero on relationship line next to entity B

Denoted by vertical bar on relationship line next to
entity B

Maximum Cardinality - the maximum number of

instances of entity B that may be associated with
each instance with entity A

If many, then denoted by a crows foot symbol on

relationship line next to entity B
Is used to define the cardinality of a relationship

34

MINIMUM AND MAXIMUM

CARDINALITY CONSTRAINTS
Basic
Relationsh
ip

Relationsh
ip with
cardinality
constraint
s
DVD is an optional participant in a relationship with MOVIE (i.e. DVD is
optional for MOVIE). That is, there can be an instance of MOVIE without
any related instance of DVD). MOVIE is mandatory for DVD. There cannot
be an instance of DVD without a related instance of MOVIE.

35

Figure 2-17 Examples of cardinality constraints

a) Mandatory cardinalities
(min cardinality is one on both sides)

A PATIENT HISTORY
is recorded for one
and only one
PATIENT

A PATIENT must have

recorded at least one
PATIENT HISTORY, and
can have many
36

Figure 2-17 Examples of cardinality constraints (cont.)

b) One optional, one mandatory
(min cardinality is zero on one side
and one on the other side)

A PROJECT must have

at least one
EMPLOYEE assigned
to it, and may have
many EMPLOYEEs

An EMPLOYEE can be
assigned to any number of
PROJECTs, or may not be
assigned to any PROJECT
at all

37

Figure 2-17 Examples of cardinality constraints (cont.)

c) Optional cardinalities
(min cardinality is zero on both sides)

A PERSON is
married to at
most one other
PERSON, or may
not be married
at all

38

MODELING MULTIPLE RELATIONSHIPS BETWEEN ENTITY

TYPES
Entities can be related to one another in more

than one way

a) Employees and departments

One relationship associates employees with the department in

which they work, while the other relationship associates each
department with the employee who manages that department

39

MODELING MULTIPLE RELATIONSHIPS BETWEEN ENTITY

TYPES
(Cont.)
b) Professors and courses

Minimum or maximum cardinality can be a "fixed number",

not "one" or many. In this case, you can place the number
above or below the cardinality symbol.
40

ATTRIBUTE or ENTITY ?
Figure 2-15a Simple
Multivalued
Attributes versus
Relationships
Unary
relationship

Has
Prerequisites

COURSE
Course ID
Course Title

Is Prerequisite For

Minimum Grade

By creating a relationship,
we can also add some
attributes

41

2-15b Composite Multivalued Attributes versus Relationships

Binary
relationship
EMPLOYEE
Employee ID
Employee Name

Possesse
s

SKILL
Skill Code
Skill Title
Skill Type

An employee has skills, which can be viewed as an

attribute the employee entity or instances of a

42

ASSOCIATIVE ENTITIES

Associative entity is an entity type that

associates the instances of one or more entity
types and contains attributes that are peculiar to
the relationship between those entity instances
When to convert a relationship with attributes to
an associative entity?

All relationships for the participating entities are

many AND
The resulting associative entity has meaning
independent of the other entities AND
The associative entity has one or more attributes in
addition to the identifier AND/OR
The associative entity participates in other
relationships other than the entities related in the
associated relationship

43

Figures 2-11a Attribute on a relationship

Figures 2-11b An associative entity (CERTIFICATE)

Converting a relationship to an associative entity causes the

relationship notation for cardinality to move

44

Figure 2-13a A unary relationship with an attribute

Used In Assemblies

Bill-of-materials (BOM) structure for two

items

45

Figure 2-13c An associative entity bill of materials stru

No relationship names on the lines between the

associative entity and participating entities because the
associative entity represents the relationship
This could just be a relationship
with attributes
Its a judgment call.

ITEM

Effective Data
Quantity

46

Figure 2-18 Ternary relationship as an associative entity

(see Figure 2.12c for comparison)

Each SUPPLY SCHEDULE instance must be related to

exactly one instance of each of the participating entity types
47

DEVELOPING AN ERD FOR PINE VALLEY FURNITURE

COMPANY

The company sells a number of furniture products.

These products are grouped into several product lines.
The identifier for a product is Product ID, whereas the
identifier for a product line is Product Line ID. The
attributes for a product: Product Description, Product
Finish, Standard Price. Another attribute for a product
line is Product Line Name. A product line may group any
number of products but must group at least one
product. Each product must belong to exactly one
product line.
Customers submit orders for products. The identifier for
an order is Order ID, and another attribute is Order
Date. A customer may submit any number of orders,
but need not submit any orders. Each order is
submitted by exactly one customer. The identifier for a
customer is Customer ID. Other attributes are Customer
Name, Customer Address, and Customer Postal Code.
A given order must request at least one product. Any
product sold by Pine Valley Furniture may not appear on
any order, or may appear on many orders. Each product
48
in a given order includes an attribute Ordered Quantity.

49

50

DEVELOPING AN ERD FOR PINE VALLEY FURNITURE

COMPANY
Pine

Valley Furniture has established sales

territories for its customers. Each customer may
do business in any number of these territories or
may not do business in any territory. A sales
territory has one to many customers. The identifier
for a sales territory is Territory ID, and an attribute
is Territory Name.
Pine Valley Furniture has several salespersons.
The identifier for a salesperson is Salesperson ID.
Other attributes include Salesperson Name,
Salesperson Telephone, and Salesperson Fax. A
salesperson serves exactly one sales territory.
Each sales territory is served by one or more
salespersons.

51

52

DEVELOPING AN ERD FOR PINE VALLEY FURNITURE

COMPANY

Each product is assembled from a specified

quantity of one or more raw materials. The
identifier for raw material is Material ID. Other
attributes include Unit Of Measure, Material Name,
and Material Standard Cost. Each raw material is
assembled into one or more products, using a
specified quantity of raw material for each product.
Raw materials are supplied by vendors. The
identifier for a vendor is Vendor ID. Other attributes
are Vendor Name, Vendor Address. Each raw
material can be supplied by one or more vendors. A
vendor may supply any number of raw materials,
or may not supply any raw materials to Pine Valley
Furniture. Supply Unit Price is the unit price at
which a particular vendor supplies a particular raw
material.
53

54

DEVELOPING AN ERD FOR PINE VALLEY FURNITURE

COMPANY

Pine Valley Furniture has established a number of

work centers. The identifier for a work center is Work
Center ID. Another attribute is Work Center Location.
Each product is produced in one or more work
centers. A work center may be used to produce any
number of products or may not be used to produce
any products.
The company has over 100 employees. The identifier
for employee is Employee ID. Other attributes
include Employee Name, Employee Address, and
Skill. An employee may have more than one skill.
Each employee may work in one or more work
centers. A work center must have at least one
employee working in that center, but may have any
number of employees. A skill may be possessed by
more than one employee or possibly no employees.
Each employee has exactly one supervisor; however,
a manager has no supervisor. An employee who is a
supervisor may supervise any number of employees,
55

Data model
for Pine Valley
Furniture
Company
using the
textbook
notation

56

Figure 2-21
Data model for
Pine Valley
Furniture
Company using
Microsoft Visio
notation
Each many-tomany relationship
is converted into
two one-to-many
relationships
Different modeling
software tools may
have different
notation for the
same constructs
57