Escolar Documentos
Profissional Documentos
Cultura Documentos
Introduction
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
Systems 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.
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.
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
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.
CUSTOMER ORDER
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
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.
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.
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
. Street Address
An attribute is a descriptive property or characteristic of an
. 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
Attributes and
compound attributes
primitive attributes. Synonyms in different data modeling
languages are numerous: concatenated attribute, composite
attribute, and data structure.
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
Prepared by Kevin C. Dittman for
Systems Analysis & Design Methods 4ed recorded if not specified by the user.
by J. L. Whitten & L. D. Bentley Copyright Irwin/McGraw-Hill 1998
12
Data Modeling
Logical Data Type Logical Business Meaning
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
SR=senior, etc.)
{minimum - maximum}
{minimum.precision -
maximum.precision}
narrative restrictions.
on size or content.
- or - HHMM
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
REQUIRED or NOT NULL For an instance of the attribute, require the REQUIRED
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.
Attributes
Identification:
Frequently, an entity may have more than one key.
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.
Address
. Street Address
. City
• A subsetting criteria is a attribute (or concatenated attribute)
. State or Province
. Country
whose finite values divide all entity instances into useful subsets.
. Postal Code
Phone Number Some methods call this an inversion entry.
. 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
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.
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.
Exactly one 1 1
Zero or one 0 1
Figure 5.3
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).
COURSE
has as a prerequisite
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.
meets as
is assigned to
SCHEDULED CLASS
is assigned to
ROOM
Classroom ID
. Building Abbreviation
. Room Number
Number of Seats
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).
CURRICULUM
Program of Study Code (Primary Key) DEPARTMENT
Title of Program offers Department Number (Primary Key)
is offered by
Type of Degree Awarded (Subsetting Criteria 1) Department Name
Department Number (Foreign Key)
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.
FIGURE(a)
STUDENT
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
Systems 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.
• 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.
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
CURRENT STUDENT
FORMER STUDENT
ALUMNUS
SYSTEM
customer-name
customer-rating
unit-of-measure
unit-price
objectives)
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
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?
Systems 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
responds to
belongs to
PRODUCT generates
Comment
AGREEMENT
Comment
responds to
PRODUCT
sponsors
Key Data
Pr oduct-Number [PK1]
Univ ersal-P roduct-Code [P K2]
PROMOTION sponsor s CLUB establishes
is featur ed in Key Data Key Data
Pr oduct-Number [PK2] [FK] Club-Name [P K1]
Club-Name [P K1] [FK]
Univ ersal-P roduct-Code [P K3] [FK]
generates
sold as
binds
PRODUCT
Key Data
Produc t-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
Produc t-Number [PK1] [FK] Produc t-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]
MERCHANDISE TITLE
Key Data Key Data
PROMOTION
Product-Number [PK1] [FK] Product-Number [PK1] [FK]
Univers al-Product-Code [PK2] [FK] Key Data
Univers al-Product-Code [PK2] [FK]
Club-Name [PK1] [FK]
Non-Key Data Non-Key Data CLUB
Non-Key Data sponsors
Merc handise-Name Title-of-Work Key Data
Title-Cover generates Promotion-Number
Merc handise-Des cription Club-Name [PK1]
Catalog-Description Promotion-Release-Date
Merc hadise-Ty pe Non-Key Data
Copyright-Date Promotion-Status
Unit-of-Measure Club-Desc ription
Entertainment-Category Promotion-Type
Automatic-Fill-Delay Club-Charter-Date
Credit-Value
Product-Number [FK]
is a Univers al-Product-Code [FK]
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