Download integrating rea diagrams across cycles

CHAPTER 16
IMPLEMENTING AN REA MODEL
IN A RELATIONAL DATABASE
INTRODUCTION
•
Questions to be addressed in this chapter:
– How are REA diagrams for individual transaction cycles integrated into a single
comprehensive organization-wide REA diagram?
– How are tables constructed from the REA model of an AIS in a relational database?
– How can queries be written to retrieve information from an AIS relational database built
according to the REA data model?
INTEGRATING REA DIAGRAMS ACROSS CYCLES
•
•
The previous chapter covered development of an REA diagram for an individual transaction
cycle. This chapter demonstrates how to implement an REA diagram in a database. We focus on
relational databases because they are commonly used to support transaction-processing systems
and they are familiar to most business students. But REA modeling can also be used to design
object-oriented databases.
In Chapter 15, we looked at REA diagrams for the revenue and expenditure cycles. Before we
integrate these diagrams with the payroll cycle, let’s take a look at the HRM/payroll cycle
activities.
HUMAN RESOURCE/PAYROLL CYCLE
Employee
(Supervisor)
Record Time
Worked
Employee
Time
Disburse
Cash
Cash
Employees
Employee
(Payroll
Clerk)
•
•
•
The basic economic exchange is: get employee time and skills; give a paycheck.
The record time worked event must be linked to a particular employee and supervisor and will
have a cardinality with a minimum and maximum of one. However, each agent can be linked to
zero or many record time worked events. The zero minimum allows for inclusion of a new
employee or supervisor who has not yet been involved in a time recording.
A similar situation exists with the disburse cash event. (We regard each individual paycheck as a
separate cash disbursement.) The assumption is made that employees record time worked on a
daily basis. Record time worked is therefore linked to a maximum of one cash disbursement,
since employees aren’t paid for half a day on one paycheck and the other half of the day on
another check. For each cash disbursement, however, there are one-to-many record time worked
Chapter 16: Implementing an REA Model in a Database
1
•
•
events. In other words, a paycheck could pay an employee for anywhere from one day’s work to
many.
With respect to the employee time entity, the resource being acquired by the record time worked
event is the use of an employee’s skills and knowledge for a period of time. Time is different
from other resources in that it cannot be stored. The relevant attributes about employee time are
hours worked and how the time was used, and these attributes are captured by the record time
worked and disburse cash events. So, the employee time resource entity is almost never
implemented in an actual database, which is why it is depicted with dotted lines.
The relationship between cash disbursement and the cash resource is identical to the expenditure
cycle. Each check or EFT must be linked to at least one cash account (and usually only one).
Therefore, the cardinality between the event and the resource has a minimum of one and a
maximum of one. Each cash account can be linked to as few as zero cash disbursements (e.g., a
new account) and up to many. Therefore, the cardinality between resource and event has a
minimum of zero and a maximum of many.
RULES FOR COMBINING REA DIAGRAMS
•
•
Some entities appear in more than one transaction cycle diagram. Inventory appears in the
revenue and expenditure cycles. Cash disbursements appear in the expenditure and payroll
cycles. Employees (agent) and cash (resource) appear in all three cycles. These redundancies
provide the basis for combining the diagrams.
The integrated diagram merges multiple copies of resource and event entities but retains multiple
copies of agent entities.
Suppliers
Employees
(Salesperson)
Take Cust.
Order
Customer
Inventory
Employees
Order
Inventory
Suppliers
Receive
Inventory
Employees
(Cashier)
Disburse
Cash
Cash
Employees
(as Payees)
Record Time
Worked
Employee
Time
Employees
(Salesperson)
Sales
Employees
(Supervisor)
2
Call on
Customer
Chapter 16: Implementing an REA Model in a Database
Receive Cash
Customer
Employees
(Cashier)
•
•
•
•
•
•
•
•
•
Merging Redundant Resource Entities--The REA diagrams for individual transaction cycles are
built around basic give-get economic exchanges. Diagrams for individual cycles provide only
partial information. To integrate the cycles, we redraw the REA diagram to place common
resources between the events that affect them, reflecting the economic duality that every resource
must be connected to at least one event that increases the resource and at least one event that
decreases it.
The inventory resource links the revenue and expenditure cycles, because it is increased by the
expenditure cycle and decreased by the revenue cycle. Cash is increased by the revenue cycle
and decreased by both the expenditure and payroll cycles.
Merging Redundant Event Entities--Some events (e.g., disburse cash) may appear in multiple
transaction cycles. Merging these multiple occurrences improves the legibility of the resulting
diagram. Our integrated diagram shows the disburse cash event is linked to both receive
inventory (in the expenditure cycle) and record time worked (from payroll cycle).
Difference between merging redundant events and merging redundant resources--Merging
redundant resources does not affect any cardinalities. Merging redundant events alters minimum
cardinalities associated with the other events that are related to the merged event. Therefore,
cardinalities between inventory and each of the four events to which it is related are the same as
before. However, the cardinalities between the cash disbursement event and other events with
which it is linked are different.
The cardinality between disburse cash and receive inventory is now (0,N) instead of (1,N) as it
was in the expenditure cycle. The cardinality between disburse cash and record hours worked is
now (0,N) instead of (1,N) as it was in the payroll cycle.
The reason lies in the semantics. A resource entity can and usually is linked to multiple events.
For example, inventory is linked to a receive inventory event in the expenditure cycle and a sales
(or deliver inventory) event in the sales cycle. Since both links are possible, none of the
cardinalities in the individual diagrams need to change when the diagrams are merged.
However, an event that occurs in one cycle can be linked to an event that is part of one
transaction cycle or an event that is part of another transaction cycle, but not both. For example,
a cash disbursement is to pay an employee (payroll) or buy inventory (expenditure), but not both.
Therefore, the minimum cardinality associated with the other event must be zero in the integrated
diagram.
Merging two transaction cycles on a common event may also affect the minimum cardinalities
between the merged event and the agent participating. A cash disbursement in the expenditure
cycle is a payment to a supplier, so every cash event is linked to at least one supplier. A cash
disbursement in the payroll cycle is a payment to an employee, so every cash event is linked to at
least one employee. A cash disbursement in the two cycles combined is linked either to a
supplier or an employee, but not both. So the linking of the diagrams changes the minimum
cardinality between event and agent from 1 to 0.
Validating the Accuracy of Integrated REA Diagrams--Chapter 15 presented three basic
principles for drawing REA diagrams for individual cycles. The preceding discussion on
combining diagrams adds two more rules. So an integrated REA diagram must satisfy these five
rules:
– Rule 1: Every event must be linked to at least one resource.
– Rule 2: Every event must be linked to at least two agents.
– Rule 3: Every event that involves disposition of a resource must be linked to an event
that involves acquiring a resource (reflects give-get economic duality).
– Rule 4: Every resource must be linked to at least one event that increases the resource
and one that decreases it.
– Rule 5: If a specific event, referred to as the focal event, can be linked to more than one
other type of event, but cannot be linked simultaneously to all of those other events, then
Chapter 16: Implementing an REA Model in a Database
3
•
the minimum cardinality between the focal event and the other linked events, must be
zero.
The preceding five rules can be used to develop an integrated REA diagram and can also be used
as “check figures” to validate the accuracy of a completed diagram. Our integrated diagram is
not yet complete because the fourth rule is not satisfied for the employee time resource. This
situation will be corrected in Chapter 17.
IMPLEMENTING AN REA DIAGRAM IN A RELATIONAL DATABASE
•
•
The three steps to implementing an REA diagram in a relational database are:
 STEP 1: Create a table for each distinct entity in the diagram and each many-to-many
relationship.
 STEP 2: Assign attributes to appropriate tables.
 STEP 3: Use foreign keys to implement one-to-one and one-to-many relationships.
As discussed previously, REA diagrams will differ across organizations because of differences in
business policies.
STEP 1: CREATE A TABLE FOR EACH ENTITY AND MANY-TOMANY RELATIONSHIP
•
Table names for these entities correspond to the names of the entities in the REA diagram. The
tables for M:N relationships are hyphenated concantenations of the entities involved in the
relationship. This treatment makes it easier to verify that all necessary tables have been created
and to use the REA diagram as a guide when querying the database.
STEP 2: ASSIGN ATTRIBUTES TO EACH TABLE
•
•
•
•
•
•
4
The designer interviews users and management to identify which facts need to be included in the
database. The REA diagram is used to determine in which tables those facts should be placed.
Placement depends on whether the fact is a primary key or just a descriptive attribute.
Every table in a relational database must have a primary key, an attribute or combination of
attributes that uniquely identifies each row in a table. It is typically a numeric identifier and is
usually a single attribute. For M:N relationship tables, the primary key consists of two attributes
that represent the primary key of each linked entity. These multiple-attribute primary keys are
called concantenated keys.
Attributes other than the primary key are also included in tables. Any attribute in a table must be
a fact about the object represented by the primary key.
Some non-key attributes even need to be stored in M:N tables. Example: quantity sold can’t be
placed in the inventory table, because there can be many sales of any particular inventory item,
and each sale produces a different quantity sold. The quantity sold can’t be placed in the sales
table, because an individual sale can include several inventory items. So it is placed in the salesinventory table.
As a general rule, time-independent data (such as standard costs or list prices) should be stored as
an attribute of a resource or agent. Data that vary across time (such as actual costs and prices)
should be stored with event entities or in M:N relationships that involve at least one event.
Attributes like “quantity on hand” or “account balance” are cumulative data items. These types
of items do not have to be stored and can be calculated. However, explicitly storing them may
improve response time to queries. They should only be stored if the DBMS has the capability to
automatically update these summary values as each new event occurs.
Chapter 16: Implementing an REA Model in a Database
STEP 3: USE FOREIGN KEYS TO IMPLEMENT ONE-TO-ONE AND
ONE-TO-MANY RELATIONSHIPS
•
•
•
•
Many-to-many relationships have been implemented by the creation of separate tables. One-toone and one-to-many relationships still need to be implemented in the database. It is usually
more efficient to implement them by the creation of foreign keys. A foreign key is an attribute of
one entity that is the primary key of another entity.
One-to-one relationships can be implemented by including the primary key of one entity as a
foreign key in the other. Minimum cardinalities may suggest which choice is more efficient. It is
usually best to insert the primary key of the entity that can occur a minimum of one time as a
foreign key in the entity that can occur a minimum of zero times. When there are two sequential
events, the primary key of the event that occurs first is usually the foreign key in the event that
occurs second. This approach provides better control.
One-to-many relationships can be implemented by placing the primary key of the entity that can
occur only once as a foreign key in the entity that can occur many times. A possible exception
occurs if you have two sequential events with a one-to-many relationship and the event that
occurs first is the event that can occur many times. In this case, you may wish to implement the
relationship with a separate table.
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. Each item on the
list should appear in at least one table as a primary key or another attribute. Checking this list
may reveal that a particular attribute has not been assigned or may even indicate the need to
modify the REA diagram itself.
USING REA DIAGRAMS TO RETRIEVE INFORMATION FROM A
DATABASE
•
•
•
•
•
•
It may appear that a number of traditional AIS elements are missing, e.g., journals, ledgers, and
accounts receivable balances. The information is simply present in a different format. Journals
and ledgers can be created through appropriate queries.
Journals--The information found in a journal is contained in the tables used to record data about
events. For example, a sales journal would involve creating a query that prints only sales
transactions from the sales table for which there is not a matching transaction in the cash receipts
table for the same customer on the same date in the same amount.
Ledgers--Much information about assets that is traditionally recorded in ledgers would be stored
in the resource tables. Accounts receivable represents sales transactions for which customer
payments have not yet been paid. This amount can be calculated as total sales (from the sales
table) less total cash receipts (from the cash receipts table).
Including calculated values as stored attributes is referred to as implementation compromise
because it violates the principles of designing well-structured relational databases.
Creating Financial Statements--Many financial statement items can be displayed by querying a
single table. For example, summing the amount column in the sales table would yield sales
revenue for the current period. Other account balances, such as accounts receivable or cost of
goods sold, may require queries of several tables.
Creating Managerial Reports--A major advantage of the REA model is its integration of nonfinancial and financial data to make both types of data easily accessible to management.
Chapter 16: Implementing an REA Model in a Database
5
SUMMARY OF MATERIAL COVERED
•
•
•
How REA diagrams for individual transaction cycles are integrated into a single comprehensive
organization-wide REA diagram.
How tables are constructed from the REA model of an AIS in a relational database.
How queries can be written to retrieve information from an AIS relational database built
according to the REA data model.
TEACHING TIPS
•
•
•
•
6
There are two aspects of this chapter that are particularly difficult for students. One is the
assignment of foreign keys, and the other is the creation of journals and ledgers.
Drill students in class with a variety of scenarios requiring foreign keys before they have to create
a full database. A few students will catch on very quickly, but most won’t. If you pace the
lecture on the basis of the few who are answering quickly, the rest will be lost. You may want to
present scenarios and ask students to write down the foreign keys, if any. Give them plenty of
time to do so and then discuss the answers. This approach may keep them from becoming
intimidated or flustered by the students who are able to grab the concept and run.
Teaching journals and ledgers will require some review of the type of data that should show up in
these documents.
For Chapters 15 and 16, you will probably see more variation in student capabilities than for any
other chapters in the book.
Chapter 16: Implementing an REA Model in a Database