Data Modeling

Introduction

 The presentation will address the following questions:

 What is systems modeling and what is the difference between
logical and physical system models?
 What is data modeling and what are its benefits?
 Can you recognize and understand the basic concepts and
constructs of a data model?
 Can you read and interpret a entity relationship data model?
 When in a project are data models constructed and where are they
stored?
 Can you discover entities and relationships?
 Can you construct an entity-relationship context diagram?

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
1
 Data Modeling
Introduction

 The presentation will address the following questions:

 Can you discover or invent keys for entities?
 Can you construct a fully attributed entity relationship diagram
and describe all data structures and attributes to the repository or
encyclopedia?

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
2
 Data Modeling
An Introduction to Systems Modeling

 Systems Modeling
 One way to structure unstructured problems is to draw models.
 A model is a representation of reality. Just as a picture is worth

a thousand words, most system models are pictorial

representations of reality.
 Models can be built for existing systems as a way to better
understand those systems, or for proposed systems as a way to
document business requirements or technical designs.
 What are Logical Models?
 Logical models show what a system ‘is’ or ‘does’. They are

implementation-independent; that is, they depict the system

independent of any technical implementation. As such, logical
models illustrate the essence of the system.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
3
 Data Modeling
An Introduction to Systems Modeling

 Systems Modeling
 What are Physical Models?
 Physical models show not only what a system ‘is’ or ‘does’,

but also how the system is physically and technically

implemented. They are implementation-dependent because
they reflect technology choices, and the limitations of those
technology choices.
 Systems analysts use logical system models to depict business
requirements, and physical system models to depict technical
designs.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
4
 Data Modeling
An Introduction to Systems Modeling

 Systems Modeling
 Systems analysis activities tend to focus on the logical system
models for the following reasons:
 Logical models remove biases that are the result of the way the

current system is implemented or the way that any one person

thinks the system might be implemented.
 Logical models reduce the risk of missing business

requirements because we are too preoccupied with technical

details.
 Logical models allow us to communicate with end-users in

non-technical or less technical languages.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
5
 Data Modeling
An Introduction to Systems Modeling

 Systems Modeling
 Data modeling is a technique for defining business requirements for a
database.
 Data modeling is a technique for organizing and documenting a

system’s DATA. Data modeling is sometimes called database

modeling because a data model is usually implemented as a
database. It is sometimes called information modeling.
 Many experts consider data modeling to be the most important of the
modeling techniques.
 Why is data modeling considered crucial?
 Data is viewed as a resource to be shared by as many processes as

possible. As a result, data must be organized in a way that is

flexible and adaptable to unanticipated business requirements –
and that is the purpose of data modeling.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
6
 Data Modeling
An Introduction to Systems Modeling

 Systems Modeling
 Why is data modeling considered crucial? (continued)
 Data structures and properties are reasonably permanent –

certainly a great deal more stable than the processes that use
the data. Often the data model of a current system is nearly
identical to that of the desired system.
 Data models are much smaller than process and object models

and can be constructed more rapidly.

 The process of constructing data models helps analysts and

users quickly reach consensus on business terminology and

rules.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
7
 Data Modeling

CUSTOMER ORDER

Customer Number (PK) Order Number (PK)

Customer Name has placed Order Date
Shipping Address Order Total Cost
Billing Address Customer Number (FK)
Balance Due

sold

ORDERED PRODUCT
INVENTORY PRODUCT
Ordered Product ID (PK)
Product Number (PK)
sold as . Order Number (FK)
Product Name
. Product Number (FK)
Product Unit of Measure
Quantity Ordered
Product Unit Price
Unit Price at Time of Order

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
8
 Data Modeling
System Concepts for Data Modeling

 System Concepts
 Most systems analysis techniques are strongly rooted in systems
thinking.
 Systems thinking is the application of formal systems theory

and concepts to systems problem solving.

 There are several notations for data modeling, but the actual model
is frequently called an entity relationship diagram (ERD).
 An ERD depicts data in terms of the entities and relationships

described by the data.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
9
 Data Modeling
System Concepts for Data Modeling

 Entities
 All systems contain data.
STUDENT
 Data describes ‘things’.
An entity
 A concept to abstractly represent all instances of a group of
similar ‘things’ is called an entity.
 An entity is something about which we want to store data.

Synonyms include entity type and entity class.

 An entity is a class of persons, places, objects, events, or

concepts about which we need to capture and store data.

 An entity instance is a single occurrence of an entity.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
10
 Data Modeling
System Concepts for Data Modeling

 Attributes
STUDENT
 The pieces of data that we want to store about each instance of a
Name
. Last Name
given entity are called attributes.
. First Name
. Middle Initial
Address  An attribute is a descriptive property or characteristic of an
. Street Address
. City
. State or Province
. Country
. Postal Code
entity. Synonyms include element, property, and field.
Phone Number
. Area Code
. Exchange Number
. Number Within Exchange
 Some attributes can be logically grouped into super-attributes
Date of Birth
Gender
Race
called compound attributes.
Major
Grade Point Average
 A compound attribute is one that actually consists of more
Attributes and
compound attributes primitive attributes. Synonyms in different data modeling
languages are numerous: concatenated attribute, composite
attribute, and data structure.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
11
 Data Modeling
System Concepts for Data Modeling

 Attributes
 Domains:
 The values for each attribute are defined in terms of three properties:

data type, domain, and default.

• The data type for an attribute defines what class of data can be stored in
that attribute.
• For purposes of systems analysis and business requirements definition, it
is useful to declare logical (non-technical) data types for our business
attributes.
• An attribute’s data type determines its domain.
– The domain of an attribute defines what values an attribute can
legitimately take on.
• Every attribute should have a logical default value.
– The default value for an attribute is that value which will be
recorded if not specified by the user.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
12
 Data Modeling
Logical Data Type Logical Business Meaning

NUMBER Any number, real or integer

TEXT A string of characters, inclusive of numbers. When numbers are

included in a TEXT attribute, it means we do not expect to

perform arithmetic or comparisons with those numbers.

MEMO Same as TEXT but of an indeterminate size. Some business

systems require the ability to attach potentially lengthy note to a

give database record.

DATE Any date in any format.

TIME Any time in any format.

YES/NO An attribute that can only assume one of these two values

VALUE SET A finite set of values. In most cases, a coding scheme would be

established (e.g., FR=freshman, SO=sophomore, JR=junior,

SR=senior, etc.)

IMAGE Any picture or image.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
13
 Data Modeling
Data Type Domain Examples

NUMBER For integers, specify the range: {10- 99}

{minimum - maximum}

For real numbers, specify the range and

{1.000 - 799.999}
precision:

{minimum.precision -

maximum.precision}

TEXT TEXT (maximum size of attribute) TEXT (30)

Actual values are usually infinite;

however, users may specify certain

narrative restrictions.

MEMO Not applicable. There are no restrictions Not applicable.

on size or content.

DATE Variation on the MMDDYYYY format. To MMDDYYYY

accommodate the year 2000, do not

MMYYYY

abbreviate year to YY. Formatting

YYYY
characters are rarely stored; therefore, do

not include hyphens or slashes.

TIME For AM/PM times: HHMMT HHMMT

- or - HHMM

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
14
 Data Modeling

Default Value Interpretation Examples

A legal value from the For an instance of the attribute, if the user 0

domain (as described above) does not specify a value, then use this value. 1.00

FR

NONE or NULL For an instance of the attribute, if the user NONE

does not specify a value, then leave it blank.

NULL

REQUIRED or NOT NULL For an instance of the attribute, require the REQUIRED

user to enter a legal value from the domain.

NOT NULL

(This is used when no value in the domain is

common enough to be a default, but a some

value must be entered.)

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
15
 Data Modeling
System Concepts for Data Modeling

 Attributes
 Identification:
 An entity typically has many instances; perhaps thousands or

millions and there exists a need to uniquely identify each

instance based on the data value of one or more attributes.
 Every entity must have an identifier or key.

• An key is an attribute, or a group of attributes, which assumes a

unique value for each entity instance. It is sometimes called an
identifier.
 Sometimes more than one attribute is required to uniquely
identify an instance of an entity.
• A group of attributes that uniquely identifies an instance of an entity
is called a concatenated key. Synonyms include composite key and
compound key.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
16
 Data Modeling
System Concepts for Data Modeling

 Attributes
 Identification:
 Frequently, an entity may have more than one key.

 Each of these attributes is called a candidate key.

• A candidate key is a ‘candidate to become the primary identifier’

of instances of an entity. It is sometimes called a candidate
identifier. (Note: A candidate key may be a single attribute or a
concatenated key.)
• A primary key is that candidate key which will most commonly
be used to uniquely identify a single entity instance.
• Any candidate key that is not selected to become the primary key
is called an alternate key.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
17
 Data Modeling
System Concepts for Data Modeling

 Attributes
 Identification:
 Sometimes, it is also necessary to identify a subset of entity

STUDENT instances as opposed to a single instance.

Student Number (Primary Key 1)
Name (Alternate Key 1)
• For example, we may require a simple way to identify all male
. Last Name
. First Name
. Middle Initial
students, and all female students.
• A subsetting criteria is a attribute (or concatenated attribute)
Address
. Street Address
. City
. State or Province
. Country whose finite values divide all entity instances into useful subsets.
Some methods call this an inversion entry.
. Postal Code
Phone Number
. Area Code
. Exchange Number
. Number Within Exchange
Date of Birth
Gender (Subsetting Criteria 1)
Race (Subsetting Criteria 2)
Major (Subsetting Criteria 3)
Grade Point Average

Keys and submitting criteria

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
18
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Conceptually, entities and attributes do not exist in isolation.
 Entities interact with, and impact one another via relationships to
support the business mission.
 A relationship is a natural business association that exists

between one or more entities. The relationship may represent

an event that links the entities, or merely a logical affinity that
exists between the entities.
 A connecting line between two entities on an ERD represents a

relationship.
 A verb phrase describes the relationship.

• All relationships are implicitly bidirectional, meaning that they

can interpreted in both directions.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
19
 Data Modeling

STUDENT is being studied by is enrolled in CURRICULUM

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
20
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Cardinality:
 Each relationship on an ERD also depicts the complexity or

degree of each relationship and this is called cardinality.

• Cardinality defines the minimum and maximum number of
occurrences of one entity for a single occurrence of the related
entity. Because all relationships are bi-directional, cardinality must
be defined in both directions for every relationship.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
21
 Data Modeling

C a r d in a lit y M in im u m M a x im u m G r a p h ic N o t a t io n
I n t e r p r e t a t io n In sta n c e s In sta n c e s

E x a c t ly o n e 1 1

Z ero o r o n e 0 1

O n e o r m o re 1 m any ( > 1 )

Z ero , o n e, o r m o re 0 m any ( > 1 )

M o re th a n o n e > 1 > 1

F ig u r e 5 .3

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
22
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Degree:
 The degree of a relationship is the number of entities that

participate in the relationship.

• A binary relationship has a degree = 2, because two different
entities participated in the relationship.
 Relationships may also exist between different instances of the
same entity.
• This is called a recursive relationship (sometimes called a unary
relationship; degree = 1).

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
23
 Data Modeling

COURSE

Course Id (Primary Key)

. Subject Abbreviation
. Course Number is a prerequisite for
Course Title
Course Credit

has as a prerequisite

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
24
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Degree: (continued)
 Relationships can also exist between more than two different

entities.
• These are sometimes called N-ary relationships.
• A relationship existing among three entities is called a 3-ary or
ternary relationship.
• An N-ary relationship maybe associated with an associative entity.
– An associative entity is an entity that inherits its primary key
from more than one other entity (parents). Each part of that
concatenated key points to one and only one instance of each
of the connecting entities.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
25
 Data Modeling
INSTRUCTOR
COURSE

Instructor ID Code (Primary

Course ID (Primary Key)
Key)
. Subject Abbreviation
Instructor Name
. Course Number
. Last Name
Course Title
. First Name
Credit
. Middle Initial

meets as
is assigned to

SCHEDULED CLASS

Scheduled Class ID (Primary Key)

. Course ID
. Instructor ID
. Room ID
Division Number
Days of Week
Start Time
End Time

is assigned to

ROOM

Classroom ID
. Building Abbreviation
. Room Number
Number of Seats

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
26
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Foreign Keys:
 A relationship implies that instances of one entity are related to

instances of another entity.

 To be able to identify those instances for any given entity, the

primary key of one entity must be migrated into the other entity
as a foreign key.
• A foreign key is a primary key of one entity that is contributed to
(duplicated in) another entity for the purpose of identifying
instances of a relationship. A foreign key (always in a child entity)
always matches the primary key (in a parent entity).

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
27
 Data Modeling

CURRICULUM
Program of Study Code (Primary Key) DEPARTMENT
Title of Program Department Number (Primary Key)
offers is offered by
Type of Degree Awarded (Subsetting Criteria 1) Department Name
Department Number (Foreign Key)

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
28
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Foreign Keys: (continued)
 When you have a relationship that you cannot differentiate

between parent and child it is called a non-specific relationship.

• A non-specific relationship (or many-to-many relationship) is
one in which many instances of one entity are associated with
many instances of another entity. Such relationships are suitable
only for preliminary data models, and should be resolved as
quickly as possible.
• All non-specific relationships can be resolved into a pair of one-to-
many relationships by inserting an associative entity between the
two original entities.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
29
 Data Modeling
STUDENT

Student Number (Primary Key 1)

Name (Alternate Key 1)
. Last Name
. First Name
. Middle Initial
Address
. Street Address
CURRICULUM
. City
. State or Province
applies to is enrolled in Program of Study Code (Primary Key)
. Country
Title of Program
. Postal Code
Type of Degree Awarded (Subsetting Criteria 1)
Phone Number
. Area Code
. Exchange Number
. Number Within Exchange
Date of Birth
Gender (Subsetting Criteria 1)
Race (Subsetting Criteria 2)
Grade Point Average

FIGURE(a)

STUDENT

Student Number (Primary Key 1) MAJOR

Name (Alternate Key 1)
. Last Name Major ID (Primary Key)
. First Name has declared . Student Number (Foreign Key)
. Middle Initial . Program of Study Code (Foriegn Key)
Address Date Enrolled
. Street Address Current Candidate for Degree?
. City
. State or Province
. Country
. Postal Code
Phone Number
. Area Code
. Exchange Number is being studied by
. Number Within Exchange
Date of Birth
Gender (Subsetting Criteria 1)
Race (Subsetting Criteria 2)
Grade Point Average
CURRICULUM
Program of Study Code (Primary Key)
Title of Program
Type of Degree Awarded (Subsetting Criteria 1)

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed FIGURE (b)

by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998

30
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Generalization:
 Generalization is an approach that seeks to discover and exploit

the commonalties between entities.

• Generalization is a technique wherein the attributes that are
common to several types of an entity are grouped into their own
entity, called a supertype.
• An entity supertype is an entity whose instances store attributes
that are common to one or more entity subtypes.
– The entity supertype will have one or more one-to-one
relationships to entity subtypes. These relationships are
sometimes called IS A relationships (or WAS A, or COULD
BE A) because each instance of the supertype ‘is also an’
instance of one or more subtypes.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
31
 Data Modeling
System Concepts for Data Modeling

 Relationships
 Generalization: (continued)
• An entity subtype is an entity whose instances inherit some
common attributes from an entity supertype, and then add other
attributes that are unique to an instances of the subtype.
 An entity can be both a supertype and subtype.
 Through inheritance, the concept of generalization in data
models permits the the reduction of the number of attributes
through the careful sharing of common attributes (data yang
bersifat efektif dan efisien)
• The subtypes not only inherit the attributes, but also the data types,
domains, and defaults of those attributes.
• In addition to inheriting attributes, subtypes also inherit
relationships to other entities.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
32
 Data Modeling
PERSON
Personal ID Number (Primary Key)
Name
. Last Name can be
. First Name contacted ADDRESS
. Middle Initial at
Gender (Subsetting Criteria 1)
Race (Subsetting Criteria 2)
Marital Status (Subsetting Criteria 3)

is a
is a

EMPLOYEE
STUDENT
Personal ID Number = Social Security Number (Primary
Personal ID Number = Student Number (Primary Key)
Key) all attributes from PERSON plus
all attributes from PERSON Pension Plan Code is bound by CONTRACT
Life Insurance Plan Code
Medical Insurance Plan Code
Vacation Days Accumulated
Sick Days Acculumlated

PROSPECT

all attributes from PERSON and STUDENT plus

is a First Contact Date
Last Contact Date
Has Visited Campus?

CURRENT STUDENT

all attributes from PERSON and STUDENT plus

Number of Credits Earned
is a Grade Point Average
Encumberance Status
Financial Aid Eligibility Status

FORMER STUDENT

could be a all attributes from PERSON and STUDENT plus

Reason for Withdrawal
Plans to Return?

ALUMNUS

all attributes from PERSON and STUDENT plus AWARDED

could be a Member of Alumni Association? has earned
DEGREE
Job in Field of Study?
Last Known Salary

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
33
 Data Modeling
The Process of Logical Data Modeling

 Strategic Data Modeling

 Many organizations select application development projects based
on strategic information system plans.
 Strategic planning is a separate project.
 This project produces an information systems strategy plan that

defines an overall vision and architecture for information

systems.
• Almost always, the architecture includes an enterprise data
model.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
34
 Data Modeling
The Process of Logical Data Modeling

 Strategic Data Modeling

 An enterprise data model typically identifies only the most
fundamental of entities.
 The entities are typically defined (as in a dictionary) but they

are not described in terms of keys or attributes.

 The enterprise data model may or may not include relationships
(depending on the planning methodology’s standards and the level
of detail desired by executive management).
 If relationships are included, many of them will be non-

specific.
 The enterprise data model is usually stored in a corporate
repository.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
35
 Data Modeling
The Process of Logical Data Modeling

 Data Modeling During Systems Analysis

 The data model for a single system or application is usually called
an application data model.
 Logical data models have a DATA focus and a SYSTEM USER
perspective.
 Logical data models are typically constructed as deliverables of
the study and definition phases of a project.
 Logical data models are not concerned with implementation
details or technology, they may be constructed (through reverse
engineering) from existing databases.
 Data models are rarely constructed during the survey phase of
systems analysis.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
36
 Data Modeling
INFORMATION SYSTEMS FRAMEWORK

FOCUS ON FOCUS ON FOCUS ON FOCUS ON FAST

SYSTEM SYSTEM SYSTEM SYSTEM
DATA PROCESSES INTERFACES GEOGRAPHY Methodology

Business Subjects Survey Phase

Customers order zero,
(establish scope
SYSTEM one, or more products. and project plan)
OWNERS Products may be ordered
by zero, one, or more
customers.
(scope)
Study Phase

entities and definitions (establish

Data Requirements
system
PRODUCT improvement
CUSTOMER product-no

objectives)
customer-no product-name
customer-name unit-of-measure
SYSTEM customer-rating unit-price
S balance-due quantity-available
USERS
Y
S
(requirements) ORDER
T order-no
order-date
E products-ordered
quantities-ordered Definition Phase
M
(establish and
A data models
N prioritize
A business system
L
Y requirements)
S
T SYSTEM
S DESIGNERS Reverse
(specification) Engineering
(optional)

SYSTEM
BUILDERS

(components)

Existing
Existing Interfaces Existing
Existing Applications and Networks
Databases and Technology and
and Technology Technology
Technology

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
37
 Data Modeling
The Process of Logical Data Modeling

 Data Modeling During Systems Analysis

 Data modeling is rarely associated with the study phase of systems
analysis. Most analysts prefer to draw process models to document
the current system.
 Many analysts report that data models are far superior for the

following reasons:
• Data models help analysts to quickly identify business vocabulary
more completely than process models.
• Data models are almost always built more quickly than process
models.
• A complete data model can be fit on a single sheet of paper.
Process models often require dozens of sheets of paper.
• Process modelers too easily get hung up on unnecessary detail.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
38
 Data Modeling
The Process of Logical Data Modeling

 Data Modeling During Systems Analysis

 Many analysts report that data models are far superior for the
following reasons: (continued)
• Data models for existing and proposed systems are far more
similar than process models for existing and proposed systems.
Consequently, there is less work to throw away as you move into
later phases.
 A study phase model should include only entities relationships, but
no attributes – a context data model.
 The intent is to refine the understanding of scope; not to get

into details about the entities and business rules.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
39
 Data Modeling
The Process of Logical Data Modeling

 Data Modeling During Systems Analysis

 The definition phase data model will be constructed in at least two
stages:
1 A key-based data model will be drawn.

• This model will eliminate non-specific relationships, add associative

entities, include primary, alternate keys, and foreign keys, plus
precise cardinalities and any generalization hierarchies.
2 A fully attributed data model will be constructed.
• The fully attributed model includes all remaining descriptive
attributes and subsetting criteria.
– Each attribute is defined in the repository with data types,
domains, and defaults.
 The completed data model represents all of the business
requirements for a system’s database.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
40
 Data Modeling
The Process of Logical Data Modeling

 Looking Ahead to Systems Configuration and Design

 The logical data model from systems analysis describes business
data requirements, not technical solutions.
 The purpose of the configuration phase is to determine the best
way to implement those requirements with database technology.
 During system design, the logical data model will be transformed
into a physical data model (called a database schema) for the
chosen database management system.
 This model will reflect the technical capabilities and limitations

of that database technology, as well as the performance tuning

requirements suggested by the database administrator.
 The physical data model will also be analyzed for adaptability

and flexibility through a process called normalization.

Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
41
 Data Modeling
The Process of Logical Data Modeling

 Fact-Finding and Information Gathering for Data

Modeling
 Data models cannot be constructed without appropriate facts and
information as supplied by the user community.
 These facts can be collected by a number of techniques such as

sampling of existing forms and files; research of similar

systems; surveys of users and management; and interviews of
users and management.
 The fastest method of collecting facts and information, and

simultaneously constructing and verifying the data models is

Joint Application Development (JAD).

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
42
 Data Modeling
Purpose Candidate Questions

Discover the system What are the subjects of the business? In other words, what
entities types of persons, organizations, organizational units, places,
things, materials, or events are used in, or interact with this
system, about which data must be captured or maintained?
How many instances of each subject exist?
Discover the entity keys What unique characteristic (or characteristics) distinguishes an
instance of each subject from other instances of the same
subject? Are there any plans to change this identification
scheme in the future?
Discover entity subsetting Are there any characteristics of a subject that divide all
criteria instances of the subject into useful subsets? Are there any
subsets of the above subjects for which you have no convenient
way to group instances?
Discover attributes and What characteristics describe each subject? For each of these
domains characteristics: (1) what type of data is stored? (2) who is
responsible for defining legitimate values for the data? (3) what
are the legitimate values for the data? (4) is a value required?
and (5) is there any default value that should be assigned if you
don’t specify otherwise?
Discover security and Are there any restrictions on who can see or use the data? Who
control needs is allowed to create the data? Who is allowed to update the
data? Who is allowed to delete the data?
Discover data timing How often does the data change? Over what period of time is
needs the data of value to the business? How long should we keep the
data? Do you need historical data or trends? If a characteristic
changes, must you know the former values?
Discover generalization Are all instances of each subject the same? That is, are there
hierarchies special types of each subject that are described or handled
differently? Can any of the data be consolidated for sharing?
Discover relationships What events occur that imply associations between subjects?
and degrees What business activities or transactions require involve
handling or changing data about several different subjects of the
same or a different type?
Discover cardinalities Is each business activity or event handled the same way or are
there special circumstances? Can an event occur with only
some of the associated subjects, or must all the subjects be
Prepared by Kevin C. Dittman for
involved?
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
43
 Data Modeling
The Process of Logical Data Modeling

 Computer-Aided Systems Engineering (CASE) for

Data Modeling
 Data models are stored in the repository.
 In a sense, the data model is metadata – that is, data about the

business’ data.
 Computer-aided systems engineering (CASE) technology,
provides the repository for storing the data model and its detailed
descriptions.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
44
 Data Modeling
The Process of Logical Data Modeling

 Computer-Aided Systems Engineering (CASE) for

Data Modeling
 Using a CASE product, you can easily create professional,
readable data models without the use of paper, pencil, erasers, and
templates.
 The models can be easily modified to reflect corrections and

changes suggested by end-users.

 Most CASE products provide powerful analytical tools that can

check your models for mechanical errors, completeness, and

consistency.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
45
 Data Modeling
The Process of Logical Data Modeling

 Computer-Aided Systems Engineering (CASE) for

Data Modeling
 Not all data model conventions are supported by all CASE
products.
 It is very likely that any given CASE product may force the

company to adapt their methodology’s data modeling symbols

or approach so that it is workable within the limitations of their
CASE tool.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
46
 Data Modeling
How to Construct Data Models

 1st Step - Entity Discovery

 The first task in data modeling is to discover those fundamental
entities in the system that are or might be described by data.
 There are several techniques that may be used to identify entities.
 During interviews or JAD sessions with system owners and

users, pay attention to key words in their discussion.

 During interviews or JAD sessions, specifically ask the system

owners and users to identify things about which they would

like to capture, store, and produce information.
 Study existing forms and files.

 Some CASE tools can reverse engineer existing files and

databases into physical data models.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
47
 Data Modeling
How to Construct Data Models

 1st Step - Entity Discovery

 A true entity has multiple instances—dozens, hundreds, thousands, or
more!
 Entities should be named with nouns (kata benda) that describe the
person, event, place, or tangible thing about which we want to store data.
 Try not to abbreviate or use acronyms.

 Names should be singular so as to distinguish the logical concept of

the entity from the actual instances of the entity.

 Define each entity in business terms.
 Don’t define the entity in technical terms, and don’t define it as ‘data

about …’.
 Your entity names and definitions should establish an initial glossary

of business terminology that will serve both you and future analysts
and users for years to come.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
48
 Data Modeling
Entity Name Business Definition

AGREEMENT A contract whereby a member agrees to purchase a certain number of

products within a certain time. After fulfilling that agreement, the
member becomes eligible for bonus credits that are redeemable for free
or discounted products.
Note: A major system improvement objective is to make agreements
more flexible with respect to other clubs. Currently, only purchases
within the club that issued an agreement count toward credits. Another
system improvement objective would award bonus credits for each
purchase leading up to fulfillment of the agreement, with accelerated
bonuses after fulfillment of the agreement.
CLUB A SoundStage membership group to which members can belong. Clubs
tend to be organized according to product interests such as music versus
movies versus games; or specialized media interests such as Digital
Video Disks (DVD) or Nintendo.
Note: Cross-club interaction is a desired objective for the new system.
MEMBER An active member of one or more clubs.
Note: A target system objective is to re-enroll inactive members as
opposed to deleting them.
MEMBER ORDER An order generated for a member as part of a monthly promotion, or an
order initiated by a member.
Note: The current system only supports orders generated from
promotions; however, customer initiated orders have been given a high
priority as an added option in the proposed system.
PRODUCT An inventoried product available for promotion and sale to members.
Note: System improvement objectives include (1) compatibility with
new bar code system being developed for the warehouse, and (2)
adaptability to a rapidly changing mix of products.
PROMOTION A monthly or quarterly event whereby dated orders are generated for all
members in a club. Members then have some period of time to cancel or
accelerate fulfillment of that order, after which the order is automatically
filled.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
49
 Data Modeling
How to Construct Data Models

 2nd Step - The Context Data Model

 The second task in data modeling is to construct the context data
model.
 The context data model includes the fundamental or independent

entities that were previously discovered.

• An independent entity is one which exists regardless of the
existence of any other entity. Its primary key contain no attributes
that would make it dependent on the existence of another entity.
• Independent entities are almost always the first entities discovered
in your conversations with the users.
 Relationships should be named with verb phrases that, when
combined with the entity names, form simple business sentences
or assertions.
• Always name the relationship from parent-to-child.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
50
 Data Modeling

responds to

MEMBER ORDER MEMBER

places
Comment Comment
sells binds

belongs to
PRODUCT generates
Comment
AGREEMENT
Comment

PROMOTION sponsors CLUB

is featured in establishes
Comment Comment

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
51
 Data Modeling
How to Construct Data Models

 3rd Step - The Key-Based Data Model

 The third task is to identify the keys of each entity.
 The following guidelines are suggested for keys:
 The value of a key should not change over the lifetime of each

entity instance.
 The value of a key cannot be null (batal).

 Controls must be installed to ensure that the value of a key is

valid.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
52
 Data Modeling
How to Construct Data Models

 3rd Step - The Key-Based Data Model

 The following guidelines are suggested for keys: (continued)
 Some experts suggest that you avoid intelligent keys because

the key may change over the lifetime of the entity instance.
• An intelligent key is a business code whose structure
communicates data about an entity instance (such as its
classification, size, or other properties).
• A code is a group of characters and/or digits that identifies and
describes something in the business system.
 Other experts suggest that you avoid intelligent keys because
business codes can return value to the organization because
they can be quickly processed by humans without the
assistance of a computer.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
53
 Data Modeling
How to Construct Data Models

 3rd Step - The Key-Based Data Model

 The following guidelines are suggested for keys: (continued)
 Consider inventing a surrogate key instead to substitute for

large concatenated keys of independent entities.

• This suggestion is not practical for associative entities since
because each part of the concatenated key is a foreign key that
must precisely match its parent entity’s primary key.
 If you cannot define keys for an entity, it may be that the entity
doesn’t really exist—that is, multiple occurrences of the so-called
entity do not exist.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
54
 Data Modeling
How to Construct Data Models

 3rd Step - The Key-Based Data Model

 Business Codes
 There are several types of codes and they can be combined to

form effective means for entity instance identification.

• Serial codes assign sequentially generated numbers to entity
instances.
– Many database management systems can generate and constrain
serial codes to a business’ requirements.
• Block codes are similar to serial codes except that serial numbers are
divided into groups that have some business meaning.
• Alphabetic codes use finite combinations of letters (and possibly
numbers) to describe entity instances.
– Alphabetic codes must usually be combined with serial or block
codes in order to uniquely identify instances of most entities.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
55
 Data Modeling
How to Construct Data Models

 3rd Step - The Key-Based Data Model

 Business Codes
 There are several types of codes and they can be combined to

form effective means for entity instance identification.

(continued)
• In significant position codes, each digit or group of digits
describes a measurable or identifiable characteristic of the entity
instance.
– Significant digit codes are frequently used to code inventory
items.
• Hierarchical codes provide a top-down interpretation for an entity
instance.
– Every item coded is factored into groups, subgroups, and so
forth.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
56
 Data Modeling
How to Construct Data Models

 3rd Step - The Key-Based Data Model

 Business Codes
 The following guidelines are suggested when creating a

business coding scheme:

• Codes should be expandable to accommodate growth.
• The full code must result in a unique value for each entity
instance.
• Codes should be large enough to describe the distinguishing
characteristics, but small enough to be interpreted by people
without a computer.
• Codes should be convenient. A new instance should be easy to
create.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
57
 Data Modeling

responds to

MEMBER ORDER MEMBER

sells places
Key Data Key Data
Order-Number [PK1] Member-Number [PK1]
Member-Number [PK2] [FK]

PRODUCT ON ORDER enrolls in

Key Data
Order-Number [PK1] [FK]
Member-Number [PK2] [FK] CLUB MEMBERSHIP
Product-Number [PK3] [FK] Key Data AGREEMENT
binds
Universal-Product-Code [PK4] [FK] Member-Number [PK2] [FK] Key Data
generates
Club-Name [PK3] [FK] Club-Name [PK2] [FK]
Agreement-Number [PK1]
sold as

PRODUCT
sponsors
Key Data
Product-Number [PK1]
Universal-Product-Code [PK2]
PROMOTION sponsors CLUB establishes
is featured in Key Data Key Data
Product-Number [PK2] [FK] Club-Name [PK1]
Club-Name [PK1] [FK]
Universal-Product-Code [PK3] [FK]

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
58
 Data Modeling
How to Construct Data Models

 4th Step - Generalized Hierarchies

 At this time, it would be useful to identify any generalization
hierarchies in a business problem.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
59
 Data Modeling
responds to
MEMBER
MEMBER ORDER placed Key Data
sells
Key Data Member-Number [PK1]
Order-Number [PK1]
PRODUCT ON AN ORDER
CLUB MEMBERSHIP
Key Data
enrolls in Key Data
Order-Number [PK1] [FK]
Product-Number [PK2] [FK] Club-Name [PK1] [FK]
Universal-Product-Code [PK3] [FK] Member-Number [PK2] [FK]
Agreement-Number [PK3] [FK]

generates

sold as

binds

PRODUCT
Key Data
Product-Number [PK1]
Universal-Product-Code [PK2] sponsors

is a

AGREEMENT
Key Data
Club-Name [PK2] [FK]
Agreement-Number [PK1]

MERCHANDISE TITLE
Key Data Key Data
generates PROMOTION
Product-Number [PK1] [FK] Product-Number [PK1] [FK] sponsors
Key Data establishes
Universal-Product-Code [PK2] [FK] Universal-Product-Code [PK2] [FK]
Club-Name [PK1] [FK] CLUB
is a Key Data
Club-Name [PK1]

AUDIO TITLE VIDEO TITLE

Key Data Key Data GAME TITLE
Product-Number [PK1] [FK] Product-Number [PK1] [FK] Key Data
Universal-Product-Code [PK2] [FK] Universal-Product-Code [PK2] [FK] Product-Number [PK1] [FK]
Universal-Product-Code [PK2] [FK]

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
60
 Data Modeling
How to Construct Data Models

 5th Step - The Fully Attributed Data Model

 The fifth task is to identify the remaining data attributes.
 The following guidelines are offered for attribution.

• Many organizations have naming standards and approved

abbreviations (singkatan).
– The data or repository administrator usually maintains such
standards.
• Many attributes share common base names such as NAME,
ADDRESS, DATE.
– Unless the attributes can be generalized into a supertype, it is best
to give each variation a unique name such as:
CUSTOMER NAME vs SUPPLIER NAME
– Names must be distinguishable across projects.
• Logical attribute names should not be abbreviated.
Prepared by Kevin C. Dittman for
ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
61
 Data Modeling
How to Construct Data Models

 5th Step - The Fully Attributed Data Model

 The following guidelines are offered for attribution.
(continued)
• For attributes that have only YES or NO values, name as
questions.
– For example, CANDIDATE FOR A DEGREE?
• Each attribute should be mapped to only one entity.
– Foreign keys are the exception – they identify associated
instances of related entities.
• An attribute’s domain should not be based on logic.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
62
 Data Modeling
MEMBER ORDER
Key Data
Order-Number [PK1] MEMBER
PRODUCT ON AN ORDER Non-Key Data Key Data CLUB MEMBERSHIP
Key Data Order-Creation-Date Member-Number [PK1] Key Data
Order-Number [PK1] [FK] Order-Fill-Date responds to Non-Key Data Club-Name [PK1] [FK]
Product-Number [PK2] [FK] Shipping-Address-Name Member-Name Member-Number [PK2] [FK]
Universal-Product-Code [PK3] [FK] sells Shipping-Street-Address enrolls in
. Last-Name Agreement-Number [PK3] [FK]
Non-Key Data Shipping-City . First-Name Non-Key Data
Quantity-Ordered Shipping-State . Middle-Initial
Quantity-Shipped Shipping-Zip Date-Enrolled
placed Member-Status
Quantity-Backordered Shipping-Instructions Expiration-Date
Member-Street-Address Number-of-Credits-Required
Purchase-Unit-Price Order-Sub-Total Member-Post-Office-Box
Credits-Earned Order-Sales-Tax Number-of-Credits-Earned
Member-City
Order-Shipping-Method Member-State
Order-Shipping-&-Handling-Cost Member-Zip-Code
sold as Order-Status Member-Daytime-Phone-Number
Order-Prepaid-Amount . Area-Code
generates
Order-Prepayment-Method . Phone-Number
PRODUCT
Member-Number [FK] . Extension ()
Key Data Club-Name [FK] binds
Member-Date-of-Last-Order
Product-Number [PK1] Promotion-Number Member-Balance
Universal-Product-Code [PK2]
Member-Credit-Card-Type
Non-Key Data
Member-Credit-Card-Number
Product-Quantity-in-Stock Member-Credit-Card-Expire-Date sponsors
Product-Type Member-Bonus-Balance
Manf-Suggested-Price
Club-Default-Price
Special-Price
Units-Sold-Month-to-Date
Units-Sold-Year-to-Date AGREEMENT
Units-Sold-Lifetime Key Data
Club-Name [PK2] [FK]
Agreement-Number [PK1]
is a
Non-Key Data
Agreement-Active-Date
Agreement-Expire-Date
Fulfillment-Period
establishes
Required-Number-of-Credits

MERCHANDISE TITLE
Key Data Key Data
PROMOTION
Product-Number [PK1] [FK] Product-Number [PK1] [FK]
Universal-Product-Code [PK2] [FK] Key Data
Universal-Product-Code [PK2] [FK]
Non-Key Data Club-Name [PK1] [FK] CLUB
Non-Key Data
Title-of-Work Non-Key Data sponsors Key Data
Merchandise-Name
Title-Cover generates Promotion-Number Club-Name [PK1]
Merchandise-Description
Catalog-Description Promotion-Release-Date
Merchadise-Type Non-Key Data
Copyright-Date Promotion-Status
Unit-of-Measure Club-Description
Entertainment-Category Promotion-Type
Automatic-Fill-Delay Club-Charter-Date
Credit-Value
Product-Number [FK]
is a Universal-Product-Code [FK]

AUDIO TITLE VIDEO TITLE

Key Data Key Data GAME TITLE
Product-Number [PK1] [FK] Product-Number [PK1] [FK] Key Data
Universal-Product-Code [PK2] [FK] Universal-Product-Code [PK2] [FK] Product-Number [PK1] [FK]
Non-Key Data Non-Key Data Universal-Product-Code [PK2] [FK]
Artist Producer Non-Key Data
Audio-Category Director Manufacturer
Audio-Sub-Category Video-Category Game-Category
Number-of-Units-in-Package Video-Sub-Category Game-Sub-Category
Audio-Media-Code Closed-Captioned Game-Platform
Content-Advisory-Code Language Game-Media-Type
Running-Time Number-of-Players
Video-Media-Type Parent-Advisory-Code
Video-Encoding
Screen-Aspect
MPA-Rating-Code

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
63
 Data Modeling
How to Construct Data Models

 6th Step - The Fully Described Model

 The last task is to fully describe the data model.
 This task is the most time consuming.

 This task can be started in parallel with the key-based model or

fully attributed model, but it is usually the last data modeling

task completed.
 At this time the descriptions for the attributes are still

incomplete – they require domains.

• Most CASE tools provide extensive facilities for describing the
data types, domains, and defaults for all attributes to the
repository.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
64
 Data Modeling
How to Construct Data Models

 6th Step - The Fully Described Model

 Additional descriptive properties may be recorded for attributes
such as:
• Who should be able to create, delete, update, and access each
attribute?
• How long should each attribute (or entity) be kept before the data
is deleted or archived?

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
65
 Data Modeling
The Next Generation

 Data modeling should remain a value-added skill for many

years.
 The demand for data modeling as a skill is dependent on two factors:
 (1) the need for databases, and

 (2) the use of relational database management system technology

to implement those databases.

• There is some belief that relational database technology will
eventually be replaced by object technology.
• If that were to happen, data modeling would be replaced by object
modeling techniques.
• Even as object database technology becomes available, we expect
the relational database industry to add object features and
technologies to their product lines.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
66
 Data Modeling
The Next Generation

 CASE technology will continue to improve.

 Today’s better CASE tools provide a two-way synchronization
between the logical data models and their database designs.
 This synchronization will likely extend as CASE vendors enable
their tools to directly communicate and interoperate with database
management systems and working databases.

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
67
 Data Modeling

Summary
 Introduction
 An Introduction to Systems Modeling
 System Concepts for Data Modeling
 The Process of Logical Data Modeling
 How to Construct Data Models
 The Next Generation

Prepared by Kevin C. Dittman for

ystems Analysis & Design Methods 4ed
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
68