CHAPTER 8
Database Design
Using the REA
Data Model
INTRODUCTION
Questions to be addressed in this
chapter include:
What steps are followed to design and
implement a database system.
How is the REA data model used to
design an AIS database?
How is an entity-relationship (E-R)
diagram of an AIS database drawn?
How are E-R diagrams read, and what do
they reveal about the business activities
and policies of the organization being
modeled?
INTRODUCTION
Steps in database design include
the following:
Planning
Requirements analysis
Design
Coding
Implementation
Operation and maintenance
Eventually, changes in
business strategy and
practices or new IT
INTRODUCTION
Accountants can and should
participate in all stages of the
database design process, although
participation varies between stages.
Planning
stage
Accountants
provide
information to help evaluate
feasibility
Participate in the feasibility
decision
INTRODUCTION
Accountants can and should
participate in all stages of the
database design process, although
participation varies between stages.
Planning stage
Requirements
analysis
and
Accountants
participate
design stages
in:
Identifying user needs
Developing logical
schemas
Designing data
INTRODUCTION
Accountants can and should
participate in all stages of the
database design process, although
participation varies between stages.
Planning stage
Requirements analysis and design
stages
Accountants with
Coding stage
good AIS skills may
participate in coding.
INTRODUCTION
Accountants can and should
participate in all stages of the
database design process, although
participation varies between stages.
Planning stage
Requirements analysis and design
stages
Coding stage
Accountants help test
Implementation stage
accuracy of database and
application programs
INTRODUCTION
Accountants
can
and
should
participate in all stages of the
database design process, although
participation varies between stages.
Planning stage
Requirements analysis
stages
Coding stage
Implementation stage
and
design
Accountants use the
Operation
and
maintenance
database system to
stageprocess transactions
INTRODUCTION
Accountants
may
provide
the
greatest
value
by
taking
responsibility for data modeling
the process of defining a database to
faithfully represent all aspects of the
organization, including interactions
with the external environment.
Occurs during both requirements
analysis and design stage
Two important tools to facilitate
data modeling:
Entity-relationship diagramming
INTRODUCTION
Accountants may provide the greatest
value by taking responsibility for data
modelingthe process of defining a
database to faithfully represent all
aspects of the organization, including
interactions
with
the
external
environment.
Occurs during both requirements
analysis and design stage
Two important tools to facilitate data
modeling:
ENTITY-RELATIONSHIP
DIAGRAMS
An entity-relationship (E-R)
diagram
is
a
graphical
technique
for
portraying
a
database schema.
Shows the various entities
being
modeled
and
the
important relationships among
them.
An entity is anything about which
the organization wants to collect
and store information.
In a relational database, separate
tables would be created to store
information about each distinct
entity.
In an object-oriented database,
separate classes would be created
for each distinct entity.
E-R diagrams can be used to
represent the contents of any
kind of databases.
Our focus is on databases
designed
to
support
an
organizations
business
activities.
The diagrams we develop depict
the contents of a database and
graphically model those business
In addition to their use in
designing
databases,
E-R
diagrams can be used to:
Document
and
understand
existing databases.
Re-engineer
business
processes.
In this chapter, well use E-R
diagrams for designing new
databases and understanding
In addition to their use in
designing
databases,
E-R
diagrams can be used to:
Document
and
understand
existing databases.
Re-engineer
business
processes.
In this chapter, well use E-R
diagrams for designing new
databases and understanding
ENTITY-RELATIONSHIP
DIAGRAMS
E-R diagrams can include many
different kinds of entities and
relationships.
An important step in designing a
database is deciding which
entities need to be modeled.
The REA data model is useful for
this decision.
INTRODUCTION
Accountants may provide the greatest
value by taking responsibility for data
modelingthe process of defining a
database to faithfully represent all
aspects of the organization, including
interactions
with
the
external
environment.
Occurs during both requirements
analysis and design stage
Two important tools to facilitate data
modeling:
Entity-relationship diagramming
The REA data model was developed
specifically for use in designing
accounting information systems.
Focuses on business semantics
underlying an organizations value
chain activities.
Provides guidance for:
Identifying the entities to be
included in a database.
Structuring
the
relationships
among the entities.
REA data models are usually
depicted in the form of E-R diagrams.
Therefore, we refer to E-R diagrams
developed with the REA model as
Three Basic
Entities
Types
of
The REA data model is so
named because it classifies
entities into three distinct
categories:
Resources
that
organization acquires
uses.
Events
in
which
the
and
the
THE REA DATA MODEL
Structuring
Relationships:
The
Basic REA Template
The REA data model prescribes a
basic pattern for how the three types
of entities (resources, events, and
agents) should relate to one another.
Rule 1: Each event is linked to
at least one resource that it
affects.
THE REA DATA MODEL
Structuring Relationships: The
Basic REA Template
The REA data model prescribes a
basic pattern for how the three
types of entities (resources,
events, and agents) should relate
to one another.
Rule 1: Each event is linked to
at least one resource that it
affects.
THE REA DATA MODEL
Structuring
Relationships:
The
Basic REA Template
The REA data model prescribes a
basic pattern for how the three types
of entities (resources, events, and
agents) should relate to one another.
Rule 1: Each event is linked to at
least one resource that it affects.
Rule 2: Each event is linked to at
least one other event.
Rule 3: Each event is linked to
at least two agents.
THE REA DATA MODEL
Rule 1: Every event entity must be linked
to at least one resource entity
Events must be linked to at least one
resource that they affect.
Some events affect the quantity of a
resource:
If they increase the quantity of a resource,
they are called a get event.
If they decrease the quantity of a resource
they are called a give event.
EXAMPLE: If you purchase inventory for
cash:
The get event is that you receive
inventory.
THE REA DATA MODEL
Not every event directly
alters the quantity of a
resource.
If a customer orders goods
but has not paid and has not
received goods, this activity
is called a commitment
event.
Organizations track the
THE REA DATA MODEL
Rule 2: Every event entity must
be linked to at least one other
event entity
Give and get events are linked
together in what is labeled an
economic duality relationship.
These relationships reflect the
basic
business
principle
that
organizations engage in activities
that use up resources in hopes of
acquiring
other
resources
in
exchange.
THE REA DATA MODEL
Rule 3: Every event entity
must be linked to at least
two participating agents
For accountability, organizations
need to be able to track actions of
employees.
Also need to monitor the status of
commitments and exchanges with
outside parties.
Each event links to at least two
participating agents.
THE REA DATA MODEL
For events that involve transactions
with external parties:
The internal agent is the employee
responsible for the affected resource.
The external agent is the outside
party to the transaction.
For internal events, such as
transferring raw materials to the
production floor:
The internal agent is the employee
who gives up responsibility or custody
for the resource.
DEVELOPING AN REA DIAGRAM
Developing an REA diagram for a
specific transaction cycle consists of
three steps:
STEP ONE:
Identify the
events
about
which
management wants to collect
information.
STEP TWO: Identify the resources
affected by the events and the
agents who participated.
STEP ONE: IDENTIFY RELEVANT EVENTS
At a minimum, every REA model
must include the two events that
represent the basic give-to-get
economic exchange performed in
that transaction cycle.
The give event reduces one of
the organizations resources.
The get event increases a
resource.
There are usually other events
that management is interested in
STEP TWO: IDENTIFY RESOURCES AND AGENTS
When the relevant events have
been diagrammed in the center of
the REA diagram, the resources
that are affected by those events
need to be identified.
Involves determining:
The resource(s) reduced by the
give event.
The resource(s) increased by the
get event.
The resources that are affected
STEP TWO: IDENTIFY RESOURCES
AND AGENTS
The agents who participate in
each event should also be
identified.
There will always be at least one
internal agent (employee).
In most cases, there will also be
an external agent (e.g., customer
or supplier) who participates.
STEP THREE: DETERMINE CARDINALITIES OF
RELATIONSHIPS
The final step in an REA diagram for a
transaction cycle is to add information
about the relationship cardinalities.
A cardinality describes the nature of the
relationship between two entities.
It indicates how many instances of one
entity can be linked to a specific
instance of another entity.
For example, the cardinality between
the event Sales and the agent
Customer answers the question:
For each sale a company makes, how
STEP THREE: DETERMINE
CARDINALITIES OF RELATIONSHIPS
Unfortunately,
there
is
no
universal
standard
for
diagramming cardinalities.
In this text, we adopt the
graphical crows feet notation
style because:
It is becoming increasingly popular.
It is used by many software design
tools.
STEP
THREE:
DETERMINE
CARDINALITIES OF RELATIONSHIPS
Using the crows feet notation:
The symbol for zero is a circle:
O
The symbol for one is a single
stroke: |
The symbol for many is the
crows foot:
STEP THREE: DETERMINE CARDINALITIES OF
RELATIONSHIPS
Three Types of Relationships
Three types of relationships are possible
between entities.
Relationships depend on the maximum
cardinality on each side of a relationship.
A one-to-one relationship (1:1) exists
when the maximum cardinality for each
entity in the relationship is 1.
A one-to-many (1:N) relationship exists
when the maximum cardinality on one
side is 1 and the maximum on the other
side is many.
A many-to-many (M:N) relationship