Modern Systems Analysis

and Design
Third Edition

Chapter 10
Structuring System Requirements:
Conceptual Data Modeling

10.1
10.1
 Conceptual Data Modeling

Process and logic modeling does not show the definition, structure and
relationships within the data but show how, where, and when data are used
or changed
Data model is most important part of information system requirements as:
 The characteristics of data captured during the data modeling are
crucial in design of databases, program, computer screens, and printed
reports – data element is numeric, a name is limited to a specified set, an
item on a customer order can’t be moved to another customer order
 Data rather than processes are most complex aspects (validating data,
coordinating movement of data) of many modern information systems like
MIS, DSS, ESS
 Characteristics about data(length, format, relationships with other data)
are reasonably permanent whereas paths of data flow are dynamic
Most common format used for data modeling is entity-relationship
(E-R) diagramming
 Conceptual Data Modeling

• Conceptual data model is a representation of organizational data

• Purpose is to show as many rules about the meaning and
interrelationships among data as are possible
• Entity-Relationship (E-R) diagrams are commonly used to show how
data are organized
• Main goal of conceptual data modeling is to create accurate E-R
diagrams
• Methods such as interviewing, questionnaires and JAD are used to
collect information
• Consistency and completeness must be maintained between
process flow, decision logic and data modeling descriptions

10.3
10.3
 Process of Conceptual Data Modeling

• First step is to develop a data model for the system being

replaced, if a system exists
• Next, a new conceptual data model is built that includes all the
requirements of the new system
• Conceptual data modeling is carried out throughout the
systems development process
• In the design stage, the E-R model developed is translated into
a format from which physical data storage decisions can be
made
• In implementation files and databases are defined as system is
coded
• Project repository links all design and data modeling steps
performed during SDLC

10.4
10.4
 Deliverables and Outcomes

• Primary deliverable is the entity-relationship diagram

• There may be as many as four E-R diagrams produced and
analyzed during conceptual data modeling
– An E-R diagram that covers just the data needed in the project’s
application
– An E-R diagram for system being replaced
– An E-R diagram for the whole database from which the new
application’s data is extracted
– An E-R diagram for the whole database from which data for the
application system being replaced is drawn

10.5
10.5
 Deliverables and Outcome

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 that are included in the DFD must appear in
the data model and visa versa
 Each data store in a process model must relate to business
objects represented in the data model
 Figure 10-3
Sample conceptual data model diagram

10.7
10.7
 Gathering Information for Conceptual Data Modeling

• Two perspectives
– Top-down
• Data model is derived from an intimate understanding of the
nature of business
– Bottom-up
• Data model is derived by reviewing specific business
documents – computer displays, reports, business forms

10.8
10.8
 Gathering Information for Conceptual Data
Modeling
Requirements Determination Questions for Data Modeling
What are the subjects/objects of business? What type of people,
places, things, events, etc., are used or interact in business whose
data must be maintained? How many instances of each object might
exist? – data entities and their descriptions
What unique characteristic (or characteristics) distinguishes each
object from other objects of same type? Does this distinguish
character change over time or is it permanent? – primary key
What characteristics describe each object? On what basis are
objects referenced, selected, sorted and categorized? – attributes
and secondary keys
How do you use this data? Are you the source of data, do you modify
it or just refer it? Who is not permitted to use it? – security controls
Gathering Information for Conceptual Data
Modeling
Over what period of time are you interested in this data? Do you
need historical trends, current snapshot values, or estimates? –
cardinality and time dimensions of data
Are all instances of each object the same? Are some objects
summaries or combinations of more detailed objects – supertypes,
subtypes, and aggregations
What events occur that imply associations between various objects?
– relationships and their cardinality and degree
Is each activity or event always handled the same way or are there
special circumstances? Can the associations between objects
change over time (employee change departments)? – integrity
rules, minimum and maximum cardinality
 Introduction to Entity-Relationship (E-R) Modeling

• The basic E-R modeling notation uses three main constructs

– Data entities
– Relationships
– Attributes
Several different E-R notations exist but we use crow’s foot notations
• Entity-Relationship Data Model (E-R model)
– A detailed, logical representation of the data for an organization or
for a business area
– E-R model is expressed in terms of entities in business
environment, the relationships or associations among those
entities, and attributes or properties of both the entities and their
relationships
• Entity-Relationship Diagram (E-R diagram)
10.11
10.11
– A graphical representation of an E-R model
 Entity-Relationship (E-R) Modeling
Key Terms
• Entity
– A person, place, object, event or concept in the user environment about which
the organization maintains data
– It has its own identity that distinguishes it from other entity
– Examples – Person: EMPLOYEE, STUDENT, PATIENT
Event: SALE, RENEWAL, REGISTRATION
Object: MACHINE, AUTOMOBILE, BUILDING
– Represented by a rectangle in E-R diagrams
– Distinction between entity types and entity instances
• Entity Type or Entity Class
– A collection of entities that share common properties or characteristics
– Each entity type is given a name – represents a set hence singular
– Use a simple noun to name an entity type – use capital letters
– Name is placed inside rectangle representing entity
• Entity Instance
– It is a single occurrence of an entity type
– An entity type can have many instances of that entity type represented by data
10.12
10.12 stored in the database
 Entity-Relationship (E-R) Modeling
Key Terms

• Attribute
– A named property or characteristic of an entity that is of interest to an
organization
– Examples of entities and their associated attributes
STUDENT: Student_ID, Student_Name, Student_Address, Major
AUTOMOBILE: Vehicle_ID, Color, Weight, Power, Wheels
– Attribute names are nouns with initial capital letter, followed by
lowercase letters
– Attributes are represented in E-R diagrams by an ellipse with name inside
and a line connecting it to the associated entity
 Entity-Relationship (E-R) Modeling
Key Terms
• Candidate keys and Identifiers
– Each entity type must have an attribute or set of attributes that
distinguishes one instance from other instances of the same type
– Candidate key
• Attribute (or combination of attributes) that uniquely identifies
each instance of an entity type
• Candidate key for STUDENT entity type may be Student_ID
– Sometimes more than one attribute is needed to identify a unique
entity
– Some entities may have more than one candidate key
– EMPLOYEE may have one candidate key Employee_ID or a
combination of Employee_Name and Address

10.14
10.14
 Entity-Relationship (E-R) Modeling
Key Terms

• Identifier
– A candidate key that has been selected as the unique identifying
characteristic for an entity type
– Selection rules for an identifier
1. Choose a candidate key that will not change its value like
Employee_Address
2. Choose a candidate key that will never be null
3. Avoid using intelligent keys whose structure indicates classifications,
locations, and so on like first 2 digits of a key for a STUDENT entity
might indicate college name
4. Consider substituting single value surrogate keys for large composite
keys
– The name of the identifier is underlined on an E-R diagram
10.15
10.15
 Entity-Relationship (E-R) Modeling
Key Terms

• Multivalued Attribute
– An attribute that may take on more than one value for each entity
instance
– A STUDENT can attend more than one class – multivalued attribute
– Represented on E-R Diagram in two ways:
• double-lined ellipse
• weak entity – separate repeating data into another entity and then
using relationship link it to its associated regular entity
• Repeating group – several attributes that repeat together like
EMPLOYEE Dependents – name, age, relation (spouse, child)
• Relationships
– An association between the instances of one or more entity types that is
of interest to the organization
– Association indicates that an event has occurred or that there is a natural
10.16
10.16
link between entity types
– Relationships are always labeled with verb phrase
 Degree of Relationship

• Degree
– Number of entity types that participate in a relationship
• Three cases
– Unary
• A relationship between two instances of one entity type (also
called recursive relationship)
– Binary
• A relationship between the instances of two entity types
– Ternary
• A simultaneous relationship among the instances of three entity
types
• Not the same as three binary relationships
• It is recommended that all ternary and higher relationships be
10.17
10.17 represented as associative entities
 Figure 10-6
Example relationships of different degrees

10.18
10.18
 Cardinality

• The number of instances of entity B that can 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
– If minimum cardinality of an entity is 0, then that entity is optional
participant in relationship
– If minimum cardinality of an entity is 1, then that entity is mandatory
participant in relationship
• Maximum Cardinality
– The maximum number of instances of entity B that may be associated
with each instance of entity A
Associative Entity
– An entity type that associates the instances of one or more entity types
and contains attributes that are peculiar to the relationship between
10.19
10.19 those entity instances (also called gerund)
 Naming and Defining Relationships

• Relationship name is a verb phrase

• Avoid vague names
• Guidelines for defining relationships
– Definition explains what action is being taken and why it is
important
– Give examples to clarify the action
– Optional participation should be explained
– Explain reasons for any explicit maximum cardinality
– Explain any restrictions on participation in the relationship
– Explain extent of the history that is kept in the relationship
– Explain whether an entity instance involved in a relationship instance
can transfer participation to another relationship instance
10.20
10.20
 Representing Supertypes and Subtypes

Often two or more entity types share common properties but also have
one or more distinct attributes or relationships
Subtype – a subgrouping of the entities in an entity types meaningful
to an organization. Example – STUDENT is an entity type that has two
subtypes GRADUATE STUDENT and UNDERGRADUATE STUDENT
Supertype – a generic entity type that has a relationship with one or
more subtypes
Total specialization rule – each entity instance of the supertype must be
a member of some subtype in the relationship (shown by double line)
Partial specialization rule – an entity instance of the supertype is allowed
not to belong to any subtype in the reationship (shown by single line)
Disjoint rule – if an entity instance of the supertype is a member of one
subtype, it cannot simultaneously be a member of any other subtype
Overlap rule – an entity instance can simultaneously be a member of two
or more subtypes.
Disjoint is shown by a “d” and overlap is shown by a “o” in the circle
 Business Rules
The specifications that preserve the integrity of logical data model
Four basic types of business rules:
– Entity integrity – each instance of an entity type must have unique identifier that is
not null
– Referential integrity constraints – rules concerning the relationships between entity
types
– Domains – constraints on valid values for attributes
– Triggering operations – other business rules to protect validity of attribute values
Domains
• The set of all data types and ranges of values that an attribute can assume – data
type, length, format, range, allowable values, meaning
• 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

10.22
10.22
 Triggering Operations

• An assertion or rule that governs the validity of data manipulation

operations such as insert, update and delete
• Scope of triggering operations may be limited to attributes with one entity
or attributes of two or more entities
• Includes the following 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
10.23
10.23 • Action taken when the operation is triggered
 • Responsibility for data integrity lies within scope of database
management system, not individual applications
• Business rules should be documented in CASE repository so that
rules would be checked automatically by database software

The Role of CASE in Conceptual Data

• CASE tools provide two important functions:
– Maintain E-R diagrams as a visual depiction of structured data
requirements
– Link objects on E-R diagrams to corresponding descriptions in a
repository

10.24
10.24