Modeling Data in the

Organization
Modern Database
Management
7th Edition
Jeffrey A. Hoffer, Mary B. Prescott,
Fred R. McFadden

Advanced Database Engineering 1

 Objectives
 Definition of terms
 Importance of data modeling
 Write good names and definitions for entities,
relationships, and attributes
 Distinguish unary, binary, and ternary relationships
 Model different types of attributes, entities,
relationships, and cardinalities
 Draw E-R diagrams for common business situations
 Convert many-to-many relationships to associative
entities
 Model time-dependent data using time stamps

2
 SDLC Revisited – Data Modeling is an
Analysis Activity
(figures 2-4, 2-5)
Project Identification
and Selection Purpose – thorough analysis
Project
Project Initiation
Initiation
Deliverable – functional system specifications
and
and Planning
Planning

Analysis
Analysis

Logical Design

Physical Design

Database activity –
Implementation
conceptual data modeling
Maintenance

3
 Business Rules
 Statements that define or constrain
some aspect of the business
 Assert business structure
 Control/influence business behavior
 Expressed in terms familiar to end
users
 Automated through DBMS software

4
 A Good Business Rule is:
 Declarative – what policy, not how
 Precise – clear, agreed-upon meaning
 Atomic – one statement
 Consistent – internally and externally
 Expressible – structured, natural
language
 Distinct – non-redundant
 Business-oriented – understood by
business people
5
 A Good Data Name is:
 Related to business, not technical,
characteristics
 Meaningful and self-documenting
 Unique
 Readable
 Composed of words from an approved
list
 Repeatable

6
 Data Definitions (structural
assertion)
 Explanation of a term or fact
 Term – word or phrase with specific meaning
 Fact – association between two or more terms
 Guidelines for good data definition
 Gathered in conjunction with systems
requirements
 Accompanied by diagrams
 Iteratively created and refined
 Achieved by consensus

7
 E-R Model Constructs
 Entity instance - person, place, object, event,
concept (often corresponds to a row in a table)
 Entity Type – collection of entities (often
corresponds to a table)
 Attribute - property or characteristic of an
entity type (often corresponds to a field in a
table)
 Relationship instance – link between entities
(corresponds to primary key-foreign key
equivalencies in related tables)
 Relationship type – category of
relationship…link between entity types
8
Sample E-R Diagram (Figure 3-1)

9
 Relationship symbols

Entity
symbols Attribute
symbols

A special entity
that is also a
relationship
Relationship
degrees specify
number of
entity types
involved
Relationship
cardinalities
specify how
many of each
entity type is
allowed
10
What Should an Entity 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:
 A user of the database system
 An output of the database system (e.g.
a report)
11
Figure 3-4 Inappropriate entities

System user System output

Appropriate entities

12
 Attributes
 Attribute - property or characteristic of
an entity type
 Classifications of attributes:
 Required versus Optional Attributes
 Simple versus Composite Attribute
 Single-Valued versus Multivalued Attribute
 Stored versus Derived Attributes
 Identifier Attributes (uniquely ident attrib instance)

13
 Identifiers (Keys)
 Identifier (Key) - An attribute (or
combination of attributes) that
uniquely identifies individual
instances of an entity type
 Simple Key versus Composite Key (Flt
Id)
 Candidate Key – an attribute that
could be a key…satisfies the
requirements for being a key
14
Characteristics of Identifiers
 Will not change in value
 Will not be null
 No intelligent identifiers (e.g.
containing locations or people that
might change)
 Substitute new, simple keys for long,
composite keys

15
Figure 3-7 – A composite attribute

An attribute
broken into
component parts

16
 Figure 3-9a – Simple key attribute

The key is underlined

17
Figure 3-9b – Composite key attribute

The key is composed

of two subparts

18
 Figure 3-8 – Entity with a multivalued attribute (Skill) and
derived attribute (Years_Employed)

What’s wrong with this?

Multivalued:
Derived an employee can have
from date employed and current date
more than one skill

19
Figure 3-19 – An attribute that is both multivalued and composite

This is an
example of
time-stamping

20
 More on Relationships
 Relationship Types vs. Relationship Instances
 The relationship type is modeled as the diamond
and lines between entity types…the instance is
between specific entity instances
 Relationships can have attributes
 These 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 Entity – combination of
relationship and entity

21
 Degree of Relationships
 Degree of a relationship is
the number of entity types
that participate in it
 Unary Relationship
 Binary Relationship

 Ternary Relationship

22
Degree of relationships – from Figure 3-2

Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each
other
23
 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
24
 Cardinality Constraints
 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

25
26
27
Note: a relationship can have attributes of its own
28
Basic relationship with only maximum cardinalities showing –
Figure 3-16a

Mandatory minimum cardinalities – Figure 3-17a

29
Figure 3-17c
Optional cardinalities with unary degree, one-to-one relationship

30
31
Figure 3-11a A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship

32
Figure 3-12c -- A ternary relationship with attributes

33
Figure 3-13a – A unary relationship with an attribute.
This has a many-to-many relationship

Representing a bill-of -materials structure

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

35
Here,max
cardinality
constraint is 4

36
Multivalued attributes can be represented via a relationships

37
 Strong vs. Weak Entities, and
Identifying Relationships
 Strong entities
 exist independently of other types of entities
 has its own unique identifier
 represented with single-line rectangle
 Weak entity
 dependent on a strong entity…cannot exist on its own
 does not have a unique identifier
 represented with double-line rectangle
 Identifying relationship
 links strong entities to weak entities
 represented with double line diamond

38
Strong entity Identifying relationship Weak entity

39
 Associative Entities

It’s an entity – it has attributes

AND it’s a relationship – it 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

40
Figure 3-11b – An associative entity (CERTIFICATE)

Associative entity involves a rectangle with a diamond inside.

Note that the many-to-many cardinality symbols face toward
the associative entity and not toward the other entities

41
Figure 3-13c – An associative entity – bill of materials structure

This could just be a relationship with

attributes…it’s a judgment call

42
Figure 3-18 – Ternary relationship as an associative entity

43
 Figure 3-22a
E-R diagram for Pine
Valley Furniture

44
 Microsoft Visio
Notation for Pine
Valley Furniture

Different modeling
software tools may
have different
notation for the same
constructs

45