Chapter 9

Structuring system
data requirements
 Lesson learning objective
 Define key data modeling terms.
 Draw entity-relationship (E-R) and class diagrams to represent
common business situations.
 Explain the role of conceptual data modeling in IS analysis and
design.
 Distinguish between unary, binary, and ternary relationships.
 Define four types of business rules.
 Compare the capabilities of class diagrams vs. E-R diagrams.
 Relate data modeling to process and logic modeling.
Conceptual Data Modeling
A detailed model that captures the overall structure of
data in an organization
Independent of any database management system
(DBMS) or other implementation considerations
Process of Conceptual Data Modeling
Develop a data model for the current system
Develop a new conceptual data model that
includes all requirements of the new system
In the design stage, the conceptual data model is
translated into a physical design
Project repository links all design and data
modeling steps performed during SDLC
Deliverables and Outcome
• Primary deliverable is an entity-relationship (E-
R) diagram or class diagram
• As many as 4 E-R or class diagrams are
produced and analyzed
– E-R diagram that covers data needed in the project’s
application
– E-R diagram for the application being replaced
– E-R diagram for the whole database from which the
new application’s data are extracted
– E-R diagram for the whole database from which data
for the application system being replaced is drawn
Deliverables and Outcome (cont.)
Second deliverable is a set of entries about data
objects to be stored in repository or project
dictionary.
Repository links data, process, and logic models of an
information system.
Data elements included in the DFD must appear in the
data model and vice versa.
Each data store in a process model must relate to
business objects represented in the data model.
Gathering Information for Conceptual Data
Modeling
Two perspectives
Top-down
 Data model is derived from an intimate understanding of the
business.
Bottom-up
 Data model is derived by reviewing specifications and
business documents.
Requirements Determination Questions for
Data Modeling
What are subjects/objects of the business?
Data entities and descriptions
What unique characteristics distinguish between
subjects/objects of the same type?
Primary keys
What characteristics describe each subject/object?
Attributes and secondary keys
How do you use the data?
Security controls and user access privileges
Requirements Determination Questions for
Data Modeling (cont.)
Over what period of time are you interested in the data?
Cardinality and time dimensions
Are all instances of each object the same?
Supertypes, subtypes, and aggregations
What events occur that imply associations between
objects?
Relationships and cardinalities
Are there special circumstances that affect the way
events are handled?
Integrity rules, cardinalities, time dimensions
Introduction to Entity-Relationship (E-R)
Modeling
Entity-Relationship (E-R) Diagram
A detailed, logical representation of the entities,
associations and data elements for an organization or
business
Notation uses three main constructs
Data entities
Relationships
Attributes
 Association
between the
instances of one or
more entity types

Person, place, object, named property or

event or concept about characteristic of an
which data is to be entity
maintained
Entity type: collection of
entities with common
characteristics
Entity instance: single
entity
Identifier Attributes
Candidate key
Attribute (or combination of attributes) that uniquely
identifies each instance of an entity type
Identifier
A candidate key that has been selected as the unique
identifying characteristic for an entity type
Identifier Attributes
(cont.)
 Selection rules for an identifier
1. Choose a candidate key that will not change its value.
2. Choose a candidate key that will never be null.
3. Avoid using intelligent keys.
4. Consider substituting single value surrogate keys for
large composite keys.
Multivalued Attributes
An attribute that may take on more than one value for
each entity instance
Represented on E-R Diagram in two ways:
double-lined ellipse
weak entity
Entity and Attribute Example
Simple attributes

Identifier attribute… Multivalued attribute…

each employee has an employee may have
a unique ID. more than one skill.
Degree of Relationship
Degree: number of entity types that participate in a
relationship
Three cases
 Unary: between two instances of one entity type
 Binary: between the instances of two entity types
 Ternary: among the instances of three entity types
Cardinality
The number of instances of entity B that can or must be
associated with each instance of entity A
Minimum Cardinality
 The minimum number of instances of entity B that may be
associated with each instance of entity A
Maximum Cardinality
 The maximum number of instances of entity B that may be
associated with each instance of entity A
Mandatory vs. Optional Cardinalities
 Specifies whether an instance must exist or can be absent in the
relationship
Cardinality Symbols
Unary Relationship Example
Binary Relationship Examples
Associative Entities
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
An associative entity is:
An entity
A relationship
This is the preferred way of illustrating a
relationship with attributes
A relationship with an attribute

…as an associative entity

Ternary relationship

…as an associative entity

A relationship
that itself is
related to
other entities
via another
relationship
must be
represented
as an
associative
entity.
Supertypes and Subtypes
Subtype: a subgouping of the entities in an entity type
that shares common attributes or relationships
distinct from other subtypes
Supertype: a generic entity type that has a relationship
with one or more subtype
Rules for Supertype/Subtypes Relationships
Total specialization: an entity instance of the
supertype must be an instance of one of the
subtypes
Partial specialization: an entity instance of the
supertype may or may not be an instance of one of
the subtypes
Disjoint: an entity instance of the supertype can be
an instance of only one subtype
Overlap: an entity instance of the supertype may
be an instance of multiple subtypes
Business Rules
Specifications that preserve the integrity of the
logical data model
Four types
Entity integrity: unique, non-null identifiers
Referential integrity constraints: rules governing
relationships
Domains: valid values for attributes
Triggering operations: other business rules regarding
attribute values
Domains
 The set of all data types and ranges of values that an
attribute can assume
 Several advantages
1. Verify that the values for an attribute are valid
2. Ensure that various data manipulation operations are
logical
3. Help conserve effort in describing attribute
characteristics
Triggering

Operations
An assertion or rule that governs the validity of data
manipulation operations such as insert, update and
delete
Components:
 User rule: statement of the business rule to be enforced by the
trigger
 Event: data manipulation operation that initiates the operation
 Entity Name: name of entity being accessed or modified
 Condition: condition that causes the operation to be triggered
 Action: action taken when the operation is triggered
Packaged Data Models
Generic data models that can be applied and modified
for an organization
Two categories
Universal
Industry-specific
Benefits
Reduced implementation time and cost
High-quality modeling
Packaged data models
provide generic models
that can be customized
for a particular
organization’s business
rules
Object Modeling Using Class Diagrams
Object-oriented approach
Based on Unified Modeling Language (UML)
Features
Objects and classes
Encapsulation of attributes and operations
Polymorphism
Inheritance
Objects
Object: an entity with a well-defined role in an
application
Each object has:
State: encompasses the attributes, their values, and
relationships of an object
Behavior: represents how an object acts and reacts
Identity: uniqueness, no two objects are the same
Classes
Class: a logical grouping of objects with similar
attributes and behaviors
Operation: a function or service provided by all
instances of a class
Encapsulation: the technique of hiding internal
implementation details of an object from external view
Class Diagram
A diagram showing the static structure of an
object-oriented model

UML classes are

analogous to E-R entities
Types of Operations
Constructor
Creates a new instance of a class
Query
Accesses the state of an object
Update
Alters the state of an object
Scope
Applies to a full class rather than an individual
instance
Representing Associations
Association: a relationship among instances of object
classes
Association role: the end of an association where it
connects to a class
Multiplicity: indicates how many objects participate in
a give relationship
UML associations
are analogous to
E-R relationships.

UML multiplicities
are analogous to
E-R cardinalities.
 roles
multiplicities

Multiplicity notation:
0..10 means minimum of 0 and maximum of 10
1, 2 means can be either 1 or 2
* means any number
Association Class
An association with its own attributes, operations,
or relationships

UML
association
classes are
analogous
to E-R
associative
entities.
Derived Attributes, Associations, and Roles
Derived attributes are calculated
based on other attributes

Derived items are represented with a slash (/).

Generalization
Superclass-subclass relationships
Subclass inherits attributes, operations, and
associations of the superclass
Types of superclasses
Abstract: cannot have any direct instances
Concrete: can have direct instances
Generalization and inheritance implemented via
superclass/subclasses in UML,
supertypes/subtypes in E-R
Polymorphic Operations
The same operation may apply to two or more classes
in different ways
Abstract operations
defined in abstract classes
defined the protocol, but not the implementation of an
operation
Methods
the implementation of an operation
 Abstraction:
Student is an abstract class and calc-
tuition() is an abstract operation (italicized)

Polymorphism:
Here, each type of student has
its own version of calc-tuition()

Class scope:
tuitionPerCred is a class-wide attribute
Aggregation and Composition
Aggregation
A part-of relationship between a component and an
aggregate object
Composition
An aggregation in which the part object belongs to only
one aggregate object and lives and dies with the
aggregate object
 Aggregation is represented with
open diamonds

Composition is represented with

filled diamonds
Summary

In this chapter you learned how to:
 Define key data modeling terms.
 Draw entity-relationship (E-R) and class diagrams to
represent common business situations.
 Explain the role of conceptual data modeling in IS
analysis and design.
 Distinguish between unary, binary, and ternary
relationships.
 Define four types of business rules.
 Compare the capabilities of class diagrams vs. E-R
diagrams.
 Relate data modeling to process and logic modeling.