Chapter 2:

Modeling Data in the

Organization
Modern Database Management
10th Edition
Jeffrey A. Hoffer, V. Ramesh,
Heikki Topi
2011 Pearson Education, Inc.
Publishing as Prentice Hall 1
Figure13Comparisonofenterpriseandprojectleveldatamodels

Segmentofanenterprisedatamodel

3
Figure13Comparisonofenterpriseandprojectleveldatamodels

Segmentofaprojectleveldatamodel

4
Sample E-R Diagram (Figure 2-1)

5
Basic E-R notation (Figure 2-2)

Entity Attribute
symbols symbols

A special entity
Relationship
that is also a
symbols
relationship

Relationship
degrees
specify number Relationship
of entity types cardinalities
involved specify how
many of each
entity type is
allowed
6
 Business Rules
Foundations of data models
govern how data are handled and stored.
examples data names and definitions
Names and definitions must be provided for the main data
objects
entity types (e.g., Customer), attributes (Customer Name), and
relationships (Customer Places Orders).

May constraint data objects

May govern people, places, events, processes, networks, and
objectives of the organization,

7
 Business Rule Examples
Every student in the university must have a
faculty advisor
A student is any person who has applied for
admission or taken a course or training
program from any credit or noncredit unit of
the university.
Implies alumni are students
A high school student who has attended a college
fair, but has not applied is not a student.

8
 E-R Model Constructs
Entities

Attributes
Identifiers

Relationships

9
 Data Names
A good data name is:
Related to business characteristics
Meaningful and self-documenting
Unique
Composed of words from an approved list
Repeatable

10
 Data Definitions
A definition is an explanation of a term or fact
Termword or phrase with specific meaning
Course, section, rental car

Factassociation between two or more terms

A customer may request a model of car from a rental branch
on a particular date.

11
 Data Definitions
Guidelines for good data definition
A concise description of essential data meaning. It
may also state such characteristics of a data object
as
Special or exceptional conditions,
examples,
where, when and how the data are created,
whether the data are static or not,
who determines the value of data

12
 Entities
Entity Type vs. Entity Instance
Entity Type
Collection of entities that share common properties or
characteristics
Often corresponds to a table

Entity Instance
Single occurrence of an entity type
Often corresponds to a row in a table

13
 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)

14
 Sample E-R Diagram (Figure 2-1)

15
Entities in E-R Diagram (Figure 2-1)

16
Figure 2-4 Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities

17
 Strong vs. Weak Entities, and
Identifying Relationships
Strong entity
exists independently of other types of entities
has its own unique identifier- that is an attribute or a
combination of attributes that uniquely distinguishes
each occurrence of that entity
identifier underlined with single line

18
Strong vs. Weak Entities, and
Identifying Relationships
Weak entity
dependent on a strong entity (identifying owner)cannot exist on its
own
does not have a unique identifier (only a partial identifier)
partial identifier underlined with double line

entity box has double line

The relationship between a weak entity type and its owner is
called an identifying relationship
Indicated by the double line

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

Strong entity Weak entity

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

Strong entity Weak entity

21
 Naming Entity Types
An entity type name is a singular noun
CUSTOMER, STUDENT, AUTOMOBILE
Should be concise, using as few words as possible
REGISTRATION instead of STUDENT REGISTRATION FOR CLASS

Event entity types should be named for the result of the

event not the process
ASSIGNMENT instead of ASSIGNING
An entity type name should be the same on all ER diagrams
on which the entity type appears

22
 Defining Entity Types
Definition usually starts with An X is
Should state the unique characteristic for each instance of
the entity type.
An expense is characterized by a journal entry number

Often includes a description of when an instance of the

entity type is created and deleted.
A customer ceases to be a customer if it has not placed an order for
more than three years.

For some entity types, should specify when an instance

might change into an instance of another entity type.

23
 Attributes
Property or characteristic of an entity or
relationship type
Often corresponds to a field in a table
An attribute name
is a singular noun or a noun phrase
should be unique

24
 Identifiers (Keys)
Identifier (Key)an attribute (or combination
of attributes) that uniquely identifies
individual instances of an entity type
Identifier names are underlined
Identifiers are required attributes
Simple versus Composite Identifier

25
 Criteria for Identifiers
Choose Identifiers that
Will not change in value
Will not be null
Avoid intelligent identifiers (e.g., containing
locations or people that might change)
Substitute new, simple keys for long, composite
keys

26
 Classifications of Attributes
Required versus Optional Attributes
Simple versus Composite Attribute
Single-Valued versus Multivalued Attribute
Stored versus Derived Attributes
Identifier Attributes

27
Figure 2-7 A composite attribute

An attribute
broken into
component parts

28
 Figure 2-8 Entity with multivalued attribute (Skill)
and derived attribute (Years Employed)

Multivalued
Derived
anemployeecanhave
fromdate
morethanoneskill
employed
andcurrent
date

29
Figure 2-9 Simple and composite identifier attributes

The identifier
is boldfaced
and
underlined

30
Figure 2-19 Simple example of time-stamping

Thisattributeis
bothmultivalued
andcomposite

31
 Relationships
Relationship Types vs. Relationship Instances
Relationship type
Meaningful association between entity types
Modeled as lines between entity types

Relationship instance
Between specific entity instances

32
Figure210Relationshiptypesandinstances

a)Relationship
type
(Completes)

b)
Relationship
instances

33
 Relationships
Entities can have multiple relationships between
them
Relationship name is a verb phrase that states the
action taken
Relationship names should be descriptive,
vague names should be avoided

34
Figure221Examplesofmultiplerelationships

a) Employees and departments

Entities can be related to one another in more than one way

35
 Degree of Relationships
The number of entity types that
participate in it
Unary Relationship
Binary Relationship
Ternary Relationship

36
Degree of relationships from Figure 2-2

Entities of
One entity two different
related to types related Entities of three
another of to each other different types
the same
related to each
entity type
other

37
Cardinality of Relationships
One-to-One
Each entity in the relationship will have exactly one related
entity
One-to-Many
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

38
Figure212Examplesofrelationshipsofdifferentdegrees

a)Unaryrelationships

39
Figure212Examplesofrelationshipsofdifferentdegrees(cont.)

b)Binaryrelationships

40
Figure212Examplesofrelationshipsofdifferentdegrees(cont.)

c)Ternaryrelationship

Note: a relationship can have attributes of its own

41
 Cardinality Constraints
The number of instances of one entity that can or
must be associated with each instance of another
entity
Minimum Cardinality
If zero, then optional
If one or more, then mandatory
Maximum Cardinality
The maximum number

42
Figure217Examplesofcardinalityconstraints

a) Mandatory cardinalities

Apatienthistoryis Apatientmusthave
recordedforoneand recordedatleastone
onlyonepatient history,andcanhave
many
43
Figure217Examplesofcardinalityconstraints(cont.)

b) One optional, one mandatory

Aprojectmustbe Anemployeecanbe
assignedtoatleast assignedtoanynumber
oneemployee,and ofprojects,ormaynot
maybeassignedto beassignedtoanyatall
many 44
Figure217Examplesofcardinalityconstraints(cont.)

c) Optional cardinalities

Apersonis
marriedtoat
mostoneother
person,ormay
notbemarried
atall

45
Figure221Examplesofmultiplerelationships

a) Employees and departments

Entities can be related to one another in more than one way

46
Figure221Examplesofmultiplerelationships(cont.)

b) Professors and courses (fixed lower limit constraint)

Here, min cardinality constraint is 2. At least two

professors must be qualified to teach each course. Each
professor must be qualified to teach at least one course.

47
Figure215aMultivaluedattributescanberepresented
asrelationships

48
Figure215bMultivaluedattributescanberepresented
asrelationships

49
 More on Relationships
Relationships can have attributes
Describe features pertaining to the association between
the entities in the relationship
An attribute cannot be associated with a one-to-
many relationship

50
Figure211aAbinaryrelationshipwithanattribute

Here, the date completed attribute pertains specifically to the

employees completion of a courseit is an attribute of the
relationship

51
 Associative Entities
Entity type that associates the instances of one or
more entity types
When should a relationship with attributes instead
be an associative entity?
1. All relationships should be many
2. Could have meaning independent of the other entities
3. Preferably has a unique identifier, and other attributes
4. May participate in other relationships other than the entities of the
associated relationship
5. Ternary relationships should be converted to associative entities

52
Figure211bAnassociativeentity(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 2-11a has been replaced by two one-to-many relationships
with the associative entity

53
Figure213cAnassociativeentitybillofmaterialsstructure

This could just be a relationship with

attributesits a judgment call

54
Figure212Examplesofrelationshipsofdifferentdegrees(cont.)

c)Ternaryrelationship

55
Figure218Cardinalityconstraintsinaternaryrelationship

56
 Figure 2-22
Data model for
Pine Valley
Furniture
Company in
Microsoft Visio
notation

Differentmodeling
softwaretoolsmay
havedifferent
notationforthe
sameconstructs

57
All rights reserved. No part of this publication may be reproduced, stored in a
retrieval system, or transmitted, in any form or by any means, electronic,
mechanical, photocopying, recording, or otherwise, without the prior written
permission of the publisher. Printed in the United States of America.

Copyright2011PearsonEducation,Inc.Publishingas
PrenticeHall

58