CHAPTER 18

IMPLEMENTING AN REA MODEL IN A RELATIONAL DATABASE

Learning Objectives:
1. Integrate separate REA diagrams for individual transaction cycles
into a single comprehensive organization-wide REA diagram.
2. Build a set of tables to implement an REA model of an AIS in a
relational database.
3. Explain how to write queries to retrieve information from an AIS
relational database built according to the REA data model.
Questions to be addressed in this chapter:
1. First, he will integrate the separate REA diagrams he has

developed into a single, comprehensive enterprise-wide data model.

2. Second, he will use the integrated data model to design a set of

relational database tables.

3. Third, he will show Fred how he can query the resulting database

to generate both traditional financial statements as well as any

custom performance reports.

Introduction
This chapter shows how to implement an REA diagram in a database.
The REA data modeling can also be used to design object-oriented
databases.
We begin by showing how to integrate separate REA diagrams developed for
individual transaction cycles into a single, comprehensive enterprise
wide data model.

Integrating REA Diagrams across Cycles

Figures 18-1, 18-2, and 18-3 present REA diagrams of Freds Train Shops
revenue, expenditure, and payroll cycles, respectively.
Figures 18-1 and 18-2 were explained in Chapter 15, so we focus in
Chapter 18 on Figure 18-3 for the HR/payroll cycle activities.
Freds Train Shop uses an electronic time clock to record the hours
worked by each employee each day by marking the time each employee began
and ended working.
Each event must be linked to a particular employee and his or her
supervisor.

Page 1 of 9

A paycheck is issued to a particular employee and signed by a particular

cashier.
The relationship among agents and events is 1:N. The minimum cardinality
on the agent side of those relationships is always 1. The minimum
cardinality on the event side of the relationships is always 0 in order
to store data about new employees before they start to work.
The relationship between the Time Worked and Disburse Cash events
reflects the use of an employees time and paying for it. The
relationship between these two events is 1:N. This is because each
Disburse Cash event is linked to many daily Time Worked events.
The Employee Time entity represents the fact that the resource being
acquired by the Time Worked event is the use of an employees skills and
knowledge for a particular period of time.
Every organization needs to monitor how much time each employee works.
The Time Worked event is an example of a Get resource event.
How an employee uses their time is an example of a Give resource
event.
These two events capture all of the information used to collect
and monitor each employees time.
Each check or electronic funds transfer must be linked to at least one
and only one cash account. However the same cash account may be linked
to many disbursement events.

Rules for Combining REA Diagrams

Figures 18-1, 18-2, and 18-3 each contain some of the same entities.
For example, the inventory resource appears in both Figures 18-1
and 18-2.
The cash disbursements event appears in both Figures 18-2 and 183.
Both the employee agent and the cash resource appear in all three
diagrams.
Such redundancies provide the basis for combining REA diagrams
into a single, comprehensive, enterprise-wide REA model. Refer to
Figure 18-4 on page 528 which shows such a model for Freds Train
Shop.
Notice that the diagram merges copies of resource and event
entities, but retains multiple copies of agent entities.

Merging Redundant Resource Entities

Remember that REA diagrams for individual transaction cycles involve
give-to-get economic exchanges.

Page 2 of 9

Figure 18-1 shows that inventory is reduced (Sales event) in exchange

for cash (Receive Cash event). However, it does not show how the
inventory was acquired or how the organization uses the cash it receives
from customers.
Figure 18-2 shows how the inventory was acquired by giving up cash.
However, it does not show what the organization does with the inventory
or how it acquired cash used to pay suppliers.
These problems are eliminated by merging redundant resource entities as
that shown in Figure 18-4.

Merging Redundant Event Entities

REA diagrams for individual transaction cycles may include some events
that also appear in the REA diagrams of another transaction cycle.
For example, Figures 18-2 and 18-3 both contain the Disburse Cash
event entity.
Figure 18-4 shows that the Disburse Cash event is linked to both
the Receive Inventory and the Time Worked events.
Merging redundant resources does not affect any cardinalities. However,
merging redundant events does alter the minimum cardinalities associated
with the other events.
In Figure 18-4, the cardinalities between the inventory resource and
each of the four events (Order Inventory, Receive Inventory, Take
Customer Order and Sales) are the same as that in Figures 18-1 and 18-2.
However, the cardinalities between the Disburse Cash event and the other
two events (Receive Inventory and Time Worked) in Figure 18-4 are
different from that in Figures 18-2 and 18-3.
The reason for this difference lies in the underlying semantics about
the nature of the relationship between the merged entity and other
entities.
In other words, the resource entity is linked to event entities in
one cycle and to event entities in the other cycle. Because both
are possible, none of the cardinalities need to be changed.
However, it is different when merging an event across transaction
cycles. The event that appears in both individual transaction
cycles can be linked to an event of one transaction cycle or to an
event in another transaction cycle. However, the event cannot be
linked to both events.
Consequently, the minimum cardinality associated with the other
event must be 0 in the integrated REA diagram.
In addition, merging two transaction cycles on a common event may also
affect the minimum cardinalities between the merged event and the agents
participating in that event.

Page 3 of 9

For example, in Figure 18-4 the minimum cardinality between the

Disburse Cash event and the Supplier entity is now 0 instead of 1.

Validating the Accuracy of Integrated REA Diagrams

In Chapter 15 there were three basic principles for drawing REA diagrams
for individual transaction cycles. There are now five rules for
integrated REA diagrams:
1. Every event must be liked to at least one resource.
2. Every event must be linked to two agents who participate in that
event.
3. Every event that involves the disposition of a resource must be
linked to an event that involves the acquisition of a resource.
(This reflects the economic duality underlying give-to-get
economic exchanges.)
4. Every resource must be linked to at least one event that
increments that resource and to at least one event that decrements
that resource.
5. If event A can be linked to more than one other event, but cannot
be linked simultaneously to all of those other events, then the
REA diagram should show that event A is linked to a minimum of 0
of each of those other events.

Implementing an REA Diagram in a Relational Database

There are three steps to implementing an REA diagram in a relational
database:
1. Create a table for each distinct entity in the diagram and for
each many-to-many relationship.
2. Assign attributes to appropriate tables.
3. Use foreign keys to implement one-to-one and one-to-many
relationships.

Step 1: Create Tables for Each Distinct Entity and M:N

Relationship
A properly designed relational database has a table for each distinct
entity and for each many-to-many relationship in an REA diagram.
Figure 18-4 has 13 distinct entities. We will not be implementing
Employee Time in the database.
Seven tables will represent the event entities in the diagram:
Order Inventory, Receive Inventory, Disburse Cash, Time Worked,
Take Customer Orders, Sales, and Receive Cash.
Two tables will be used for resource entities: Inventory and Cash.

Page 4 of 9

Three tables are needed to implement the distinct agent entities:

Employees, Customers, and Suppliers.
In Figure 18-4 there are five M:N relationships.
Three are from the revenue cycle:
1. Take Customer Orders-Inventory
2. Sales-Inventory
3. Sales-Receive Cash
Two are from the expenditure cycle:
1. Inventory-Order Inventory
2. Inventory-Receive Inventory
17 Tables will be needed to implement Figure 18-4 into a
relational database.

Step 2: Assign Attributes to Each Table

The next step is to determine which attributes should be included
in each table.
Identify Primary Keys
Remember from Chapter 4 that every table in a relational database
must have a primary key, consisting of an attribute, or
combination of attributes, that uniquely identifies each row in
that table.
Freds Train Shop uses invoice numbers as the primary key of
the sales table and customer number for the Customer table.
M:N relationship tables consist of two primary keys. The SalesInventory table consists of both the invoice number and product
number as primary keys. These multiple-attribute primary keys are
called concatenated keys.
Assign Other Attributes to Appropriate Tables
Other attributes included in a relational database table must be a
fact about the object represented in the primary or foreign key.
These other attributes could include such items as customer
name and address.
A foreign key is an attribute in a table that is a primary
key in another table. Foreign keys are used to link tables.
The 17 Tables needed to implement Figure 18-4 into a relational
database are listed in Table 18-1. In addition to the name of the

Page 5 of 9

table, it lists the primary key, foreign keys, and other

attributes.
Note that the last five tables in Table 18-1 have concatenated
keys (two primary keys). In Figure 18-4 four of these event
entities (tables in Table 18-1) have a M:N relationship with the
inventory resource entity.
Note that the employee number primary key in the Employees table
is the foreign key in seven other tables: 1) Order Inventory, 2)
Receive Inventory, 3) Disburse Cash, 4) Take Customer Orders, 5)
Sales, 6) Receive Cash, and 7) Record Time Worked.
Table 18-1 also includes nonkey attributes in some of the M:N
relationship tables.
Nonkey attributes are items in a table that are neither a
primary key nor a foreign key.
All nonkey attributes in a table should describe a
characteristic about the object identified by the primary
key.
Nonkey attributes are listed in Table 18-1 under the Other
Attributes column.
Price and Cost Data
In Table 18-1, notice that information about prices and costs are stored
as an attribute in several different tables.
The Inventory table stores the suggested list price for the item.
The Sales-Inventory stores the actual sales price.
Cumulative and Calculable Data
Notice that Table 18-1 does not contain cumulative data, such as
quantity on hand in the Inventory table, or calculate data, such as
total amount of sale in the Sales table.
The reason this data is not provided in these two tables is
because the information is already available:
The inventory quantity on hand equals the quantity on hand
at the beginning on the current fiscal period (Inventory
table) plus the total quantity purchased this period (total
quantity purchased in Receive-Inventory table) minus the
quantity sold in the Sales-Inventory table.
The total amount of sale equals quantity sold by the actual
sales price in the Sales-Inventory table.

Page 6 of 9

Step 3: Use Foreign Keys to Implement 1:1 and 1:N Relationships

1:1 and 1:N relationships are more efficiently implemented by means of
foreign keys instead of being implemented as separate tables.
Using Foreign Keys to Implement 1:1 Relationships
In a relational database, 1:1 relationships between entities can be
implemented by including the primary key of either entity as a foreign
key in the other table.
Careful analysis of the minimum cardinalities of the relationship
suggests that this approach is more efficient.
Consider the case of a 1:1 relationship between sales and customer
payments (see Figure 17-7, panel A).
The minimum cardinality for the Receive Cash event is 0.
The minimum cardinality for the Sale event is 1.
Using Foreign Keys to Implement 1:N Relationships
1:N relationships can also be implemented in relational databases with
foreign keys.
There is only one way to do this: The primary key of the entity that can
be linked to multiple instances of the other entity must become a
foreign key in that other entity.
The primary keys of the Salesperson and Customer tables are
included as foreign keys in the Sales table. Reversing this
procedure would violate one of the fundamental rules of relational
database design.
M:N relationships must be implemented as separate tables. Because each
entity can be linked to multiple occurrences of the entity on the other
side of the relationship, it is not possible to make either entitys
primary key a foreign key in the other entity.

Completeness Check
The list of attributes that users and management want included in the
database provides a means to check and validate the implementation
process.
Checking this list against the table column names may reveal not only
the fact that a particular attribute has not been assigned to the
appropriate table in the database but may even indicate the need to
modify the REA diagram itself.
Paul Stone double-checked the list of desired attributes; he found that
he did not have any table to cover the attribute product discussed
during sales calls.
Paul realizes that this necessitates creating another entity Call on

Page 7 of 9

Customers.
It is often useful to create tables even before completely finishing an
REA diagram and assign attributes to them.
Once all attributes have been assigned to tables, a final accuracy check
of relational databases is required:
1. Every table must have a primary key.
2. Other nonkey attributes in each table must be either a fact about
the thing designed by the primary key or foreign keys used to link
that able to another table.
3. Every attribute in every table is single-valued.

Using REA Diagrams to Retrieve Information from a Database

In this section we refer to Figure 18-4 and Table 18-1 to show how to
use completed REA diagrams to retrieve information to evaluate
performance.

Creating Journals and Ledgers

The traditional journals and ledgers can be created through the use of
queries.
Deriving Journals from Queries
In a relational database, event entities store information about
transactions.
Information found in a journal is contained in the tables used to record
data about events.
For example, the Sales and Sales-Inventory tables contain information
for sales transactions. Thus, a sales journal can be produced through
sales queries.
However, this would produce a list of all sales transactions (cash and
credit sales). Sales journals only include credit sales.
To be able to determine the credit sales, the REA model would create a
new role sale of merchandise to a customer in the Sales table and
receipt of payment from a customer in the Receive Cash table.
For cash sales, both rows would have the same values in the date
and customer number columns.
Rows in the Receive Cash table with dates later than the date of
the corresponding sales would present payments on credit sales.
Ledgers
In AISs, ledgers are master files that contain cumulative information
about specific accounts.

Page 8 of 9

Resource and agent entities contain permanent information that is

carried over from one fiscal year to the next.
Information about an organizations assets that is posted in ledgers is
stored in Resource tables.
Each of the resource accounts is affected by increment and decrement
events. For example, equipment is purchased and used, cash is received
and disbursed and inventory is purchased and sold.
Queries to display the current cumulative balance for these accounts
must reference not only the appropriate table for that resource entity
but also the event tables that affect it.
Many financial statement accounts are represented as resources in the
REA model.
An important exception is claims: Figure 18-4 does not include
Accounts Receivable or Accounts Payable.
Accounts Receivable represents sales transactions for which
customer payments have not yet been received, and Accounts Payable
represents purchases from suppliers that have not yet been paid
for.
Therefore, neither accounts needs to be explicitly stored as
separate tables.

Generating Financial Statements

It is possible to use a completed REA diagram to guide the writing of
queries to produce the information that would be included in financial
statements.

Creating Managerial Reports

A major advantage of the REA data model is that it integrates
nonfinancial and financial data in the AIS and makes both types of data
easily accessible to management.
For example, Table 18-4 show that the Sales table in Figure 18-4
includes an attribute to record the time that the sale occurred. This
will allow the tracking of sales activity during different times of the
day to better plan staffing needs at Freds Train Shop.
The general ledger is normally designed in AISs using the chart of
accounts based on the structure of financial statements. Therefore, the
nonfinancial data needs to be stored in a separate database or
information system.

Page 9 of 9