REA Diagram

C
HAPTER 15
Database Design Using the REA Data Model
2008 Prentice Hall Business Publishing
Accounting Information Systems, 11/e
Romney/Steinbart
1 of 138
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 REA diagram of an AIS database drawn? How are REA diagrams read, and what do they reveal about the business activities and policies of the organization being modeled?
2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart 2 of 138
Data Modeling
Data modeling is the process of defining a database so that it faithfully represents all aspects of the organization, including its interactions with the external environment.
Two important tools to facilitate data modeling:
Entity-relationship diagramming REA data model
Romney/Steinbart
3 of 138
ENTITY-RELATIONSHIP DIAGRAMS
An entity is anything about which the organization wants to collect and store information.
Example: Your university collects and stores information about students, courses, enrollment activity, etc.
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.
In an E-R diagram, entities are depicted as rectangles. But there are no industry standards for other aspects of these diagrams.
Enrollment
Students
Romney/Steinbart
5 of 138
Some data modelers, tools, and authors use diamonds to depict relationships.
Enrollment
Line Items
Students
Romney/Steinbart
6 of 138
In this book, we will create E-R diagrams with a large number of entities and relationships. To reduce clutter and improve readability list attributes in a separate table.
Enrollment
Students
Entity Name
Enrollment Student
Attributes
Enrollment No., Enrollment Date, Enrollment Time Student ID No., Student Name, Student Address
Accounting Information Systems, 11/e Romney/Steinbart 7 of 138
THE REA DATA MODEL

The REA data model is a conceptual modeling tool specifically designed to provide structure for designing AIS databases. The REA data model provides structure by:
Identifying what entities should be included in the AIS database. Prescribing how to structure relationships among the entities in the AIS database.
Romney/Steinbart
8 of 138
THE REA DATA MODEL

Three basic types of entities
The REA data model is so named because it classifies entities into three distinct categories:
Resources that the organization acquires and uses. Events in which the organization engages Agents participating in these events.
Romney/Steinbart
9 of 138
THE REA DATA MODEL
Inventory
Sales
Employee
Customer
Cash Accounts
Receive Cash
Employee
Romney/Steinbart 10 of 138
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.
Romney/Steinbart
11 of 138
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 give event is that you pay cash.
Relationships that affect the quantity of a resource are sometimes referred to as stockflow relationships.
Romney/Steinbart
12 of 138
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 effects of commitments to provide better service and for planning purposes.
Romney/Steinbart
13 of 138
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. Each accounting cycle can be described in terms of give-to-get economic duality relationships.
Romney/Steinbart
14 of 138
THE REA DATA MODEL

Rule 3: Every event entity must be linked to at least two participating agents. 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.
Romney/Steinbart
15 of 138
THE REA DATA MODEL

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. The external agent is the one who receives it.
Romney/Steinbart
16 of 138
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 THREE: Determine the cardinalities between the relationships.
Lets walk through an example.

STEP ONE: IDENTIFY RELEVANT EVENTS

Example: Typical activities in the revenue cycle include:
Take customer order Fill customer order Bill customer Collect payment
Romney/Steinbart
18 of 138
STEP TWO: IDENTIFYING RESOURCES AND AGENTS

Identifying resources involves determining:
The resource(s) reduced by the give event. The resource(s) increased by the get event. The resources that are affected by the commitment event.
Romney/Steinbart
19 of 138
IDENTIFY RELEVANT EVENTS

At a minimum, every REA model must include the two events that represent the basic give-to-get economic exchange for that particular transaction cycle. Event entities are typically drawn from top to bottom in the sequence in which they normally occur.
Romney/Steinbart
20 of 138
IDENTIFY RELEVANT EVENTS

Take Order
Sale
Receive Cash
Romney/Steinbart
21 of 138
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 by a commitment event.
STEP TWO: IDENTIFY RESOURCES AND AGENTS

The agents who participate in each event should also be identified.
Will there always be at least one internal agent (employee)? Will there also be an external agent (e.g., customer or supplier) who participates?
Romney/Steinbart
23 of 138
REA Diagram: The Revenue Cycle

Take Order Inventory Customer Sales Employee
Employee
Cash Accounts
Receive Cash
Customer
Romney/Steinbart
24 of 138
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 THREE: Determine the cardinalities between the relationships.
Lets walk through an example.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS

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. Cardinalities are often expressed as a pair of numbers. The first number is the minimum, and the second number is the maximum.
Romney/Steinbart
26 of 138
Cardinalities
Minimum Cardinality
Indicates whether a specific instance of the entity next to the cardinality must be linked to at least one instance of the entity on the opposite side of the relationship. Can be either 0 or 1 0 represents an optional relationship 1 represents a mandatory relationship
Romney/Steinbart
27 of 138
Cardinalities
Maximum Cardinality
Indicates whether one instance of the same entity can be linked to more than one instance of the other entity participating in that relationship. Can be either 1 or N.
Romney/Steinbart
28 of 138

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:
Romney/Steinbart
29 of 138
Sale
Customer
There is typically a minimum and maximum cardinality for each entity participating in a relationship.
Romney/Steinbart
30 of 138
Sale
Customer
Minimum Relationships Can I have a sales record that is not related to a customer? Can I have a customer in the customer table that is not related to a sale? Yes = No =
Romney/Steinbart
31 of 138

Sale Customer
Maximum Relationships Can a Sales record be related to more than one customer? Can a customer be related to more than one sales record? Yes = No =
Romney/Steinbart
32 of 138
3 TYPES OF RELATIONSHIPS
There are 3 basic types of relationships between entities (depending 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.
Romney/Steinbart
33 of 138
3 TYPES OF RELATIONSHIPS
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 exists when the maximum on both sides is many.
Romney/Steinbart
34 of 138
Developing an REA Diagram

Agent event cardinalities:
The cardinality between agent and event is typically (0:N) on the event side.
Resource event cardinalities:

The minimum cardinality is typically one. The maximum could be one or many.
Event - resource cardinalities:

The minimum is typically zero.
Romney/Steinbart
35 of 138
Developing an REA Diagram

Cardinalities between events When events occur in a sequence, the minimum cardinality between the first event and the second event is always zero. The minimum cardinality between the second event and the first event is typically one. An exception could occur if the first event is not required for the second event to occur. The maximums in the cardinalities between events can be either one or many.
Romney/Steinbart
36 of 138

Uniqueness of REA diagrams
Each organization will have its own unique REA diagram.
Business practices differ across companies, so cardinalities and relationships will differ. A given organization can change business practices, leading to a change in its REA diagram:
A change in practice could cause a change in cardinalities. Could even lead to the inclusion of different entities on the diagram.
Romney/Steinbart
37 of 138

REA Diagram

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

REA Diagram

Caricato da

Copyright:

Formati disponibili

C

Database Design Using the REA Data Model

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

2008 Prentice Hall Business Publishing

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

THE REA DATA MODEL

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

THE REA DATA MODEL

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

DEVELOPING AN REA DIAGRAM

Lets walk through an example.

STEP ONE: IDENTIFY RELEVANT EVENTS

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

STEP TWO: IDENTIFYING RESOURCES AND AGENTS

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

IDENTIFY RELEVANT EVENTS

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

IDENTIFY RELEVANT EVENTS

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

STEP TWO: IDENTIFY RESOURCES AND AGENTS

STEP TWO: IDENTIFY RESOURCES AND AGENTS

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

REA Diagram: The Revenue Cycle

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

DEVELOPING AN REA DIAGRAM

Lets walk through an example.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS

2008 Prentice Hall Business Publishing

Accounting Information Systems, 11/e

2008 Prentice Hall Business Publishing