Implementing an REA Database Model in Accounting information System.

1. IMPLEMENTING A REA
MODEL IN A RELATIONAL
DATABASE

2. IMPLEMENTING A REA
MODEL IN A RELATIONAL
DATABASE

3. INTRODUCTION
• • 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.
• – They are familiar to most business students.
• • But REA modeling can also be used to design object-oriented
databases.

4. EXPENDITURE CYCLE

5. EXPENDITURE CYCLE
STEP 1:
1. Order inventory
2. Receive inventory
3. Pay inventory

6. EXPENDITURE CYCLE
STEP 2:

7. EXPENDITURE CYCLE
STEP 2:

8. EXPENDITURE CYCLE
STEP 2:

9. EXPENDITURE CYCLE
STEP 2:

10. EXPENDITURE CYCLE
STEP 3:

11. EXPENDITURE CYCLE
STEP 3:
• Event - Agent
Relationship

12. EXPENDITURE CYCLE
STEP 3:
• Event - Agent
Relationship

13. EXPENDITURE CYCLE
STEP 3:
Event - Resource
Relationship

14. EXPENDITURE CYCLE
STEP 3:
Event - Event
Relationship

15. PAYROLL CYCLE

16. INTEGRATING REA DIAGRAMS ACROSS CYCLES

17. INTEGRATING REA DIAGRAMS ACROSS CYCLES

18. INTEGRATING REA DIAGRAMS ACROSS CYCLES
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.

19. INTEGRATING REA DIAGRAMS ACROSS CYCLES

20. INTEGRATING REA DIAGRAMS ACROSS CYCLES
• For each cash disbursement, however, there are one-
to-many record time worked events.

21. INTEGRATING REA DIAGRAMS ACROSS CYCLES

22. INTEGRATING REA DIAGRAMS ACROSS CYCLES
• There are only a few
relevant attributes about
employee time:
– Hours worked
– How the time was used

23. INTEGRATING REA DIAGRAMS ACROSS CYCLES
• The record time worked and
disburse cash events capture
all the information about
employee time that it is practical
to collect and monitor.

24. INTEGRATING REA DIAGRAMS ACROSS CYCLES
• In the relationship between cash disbursement and the cash
resource:
– Each check or EFT must be linked to at least one cash account
(and usually only one), leading to a (1:1) cardinality.
– Each cash account can be linked to:
• As few as zero cash disbursements (e.g., a new account);
• And up to many.

25. 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.

32. RULES FOR
COMBINING
REA
DIAGRAMS
• 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.
• Example: The expenditure cycle tells
you how the company gets inventory, but
doesn’t tell you what becomes of the
inventory.

33. RULES FOR
COMBINING
REA
DIAGRAMS
• Merging Redundant
Resource Entities
– To integrate the cycles, we redraw the
REA diagram to place common
resources between the events that affect
them.
– Reflects 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.

36. RULES FOR
COMBINING
REA
DIAGRAMS
• 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.

38. RULES FOR
COMBINING
REA
DIAGRAMS
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.

43. RULES FOR COMBINING
REA DIAGRAMS
* Reason lies in the
semantics.
– A resource entity can
and usually is linked to
multiple events.
Example: Inventory is linked to
a receive inventory event in
the expenditure cycle and a
sales (or deliver inventory)
event in the sales cycle.

44. RULES FOR COMBINING
REA DIAGRAMS
• 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;
– The minimum cardinality
associated with the other
event must be zero in the
integrated diagram.

45. RULES FOR COMBINING
REA DIAGRAMS
• Remember:
A minimum of one means that each
instance of that entity has to be
associated with at least one
instance of
the other entity.

46. RULES FOR
COMBINING REA
DIAGRAMS
• Merging two transaction cycles
on a common event may also
affect the minimum cardinalities
between the merged event and
the agent participating.
• Same basic reasoning:
– Changes the minimum
cardinality between event and
agent from 1 to 0.

49. 1.
Every event
must be
linked to at
least one
resource.
2.
Every event
must be
linked to at
least two
agents.
RULES FOR COMBINING REA DIAGRAMS
3.
Every event that
involves disposition
of a resource
must be linked to
an event that
involves acquiring a
resource.

50. RULES FOR COMBINING REA DIAGRAMS
4.
Every resource must be
linked to at least one
event that increases the
resource and one that
decreases it.
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 minimum
of 0 of each of those other events.

51. RULES FOR COMBINING REA DIAGRAMS
6.
If an event can be linked to any one set
of agents, but cannot be linked
simultaneously to all of those agents,
then the REA diagram should show that
event is linked to minimum of 0 of each
of those other agents.

52. RULES FOR COMBINING REA DIAGRAMS
• 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.

53. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• The three steps to implementing an REA diagram in a
relational database are:
– Create a table for:
• Each distinct entity in the diagram
• Each many-to-many relationship
– Assign attributes to appropriate tables
– Use foreign keys to implement one-to-one and one-to-
many relationships.

54. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• The three steps to implementing an REA diagram in a
relational database are:
• Each many-to-many relationship
– Assign attributes to appropriate tables
– Use foreign keys to implement one-to-one and one-to-
many relationships.

55. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

56. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

57. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

58. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

59. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Total entities to be represented in separate tables:
Events 8
Resources 2
Agents 3
13

60. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• The three steps to implementing an REA diagram in a
relational database are:
• Each distinct entity in the diagram
– Assign attributes to appropriate tables
– Use foreign keys to implement one-to-one and one-to-
many relationships.

61. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

62. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
Table names for these 20 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.
– Makes it easier:
• To verify that all necessary tables have been created.
• To use the REA diagram as a guide when querying the database.

63. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Total number of tables in database:
Events 8
Resources 2
Agents 3
13
Plus: Many-to-Many Relationship 7
20

64. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Table names for our integrated diagram:
• Call on Customer
• Take Customer Order
• Sales
• Receive Cash
• Order Inventory
• Receive Inventory
• Disburse Cash
• Record Time Worked
• Inventory
• Cash
• Customer
• Supplier
• Employee
• Call on Customer-Inventory
• Take Order-Inventory
• Sales-Inventory
• Sales-Receive Cash
• Order Inventory-Inventory
• Receive Inventory-Inventory
• Receive Inventory-Disburse Cash

65. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• The three steps to implementing an REA diagram in a
relational database are:
– Create a table for:
• Each distinct entity in the diagram
• Each many-to-many relationship
– Use foreign keys to implement one-to-one and one-to-
many relationships.

66. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Step 2: Assign Attributes to Each Table
– The next step is to determine which attributes should be included in
each table.
– The designer needs to interview users and management to identify
which facts need to be included in the database.
– Should use the REA diagram to determine in which tables those
facts should be placed.
– Depends on whether the fact is a primary key or just a descriptive
attribute

67. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Identify Primary Keys
– Every table in a relational database must have a primary key.
• The primary key is an attribute or combination of attributes that
uniquely identifies each row in a table.
• It is typically a numeric identifier.
– The primary key is usually a single attribute.
– However for M:N relationship tables, it consists of two
attributes that represent the primary key of each linked entity.

68. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Assign Other Attributes to Appropriate Tables
– Attributes other than the primary key are also included in
tables:
• To provide for accurate transaction processing and the production
of financial statements; or
• To facilitate effective management of the entity’s resources, events,
and agents.
– Any attribute in a table must be a fact about the object
represented by the primary key.

69. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Some non-key attributes even need to be
stored in M:N tables.
• Example: The inventory-sales table may
include a “quantity sold” attribute.

70. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Price and Cost Data
– Information about prices and costs are stored as
attributes in several different tables.
– The inventory table stores the suggested list price,
which is generally constant for the fiscal period.
– The sales-inventory table stores the actual sales price,
which can vary during the year.

71. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
– Just like sales prices, the standard and actual purchase
costs of each item are stored in different tables.
– 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.

72. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Cumulative Data
– Attributes like “quantity on hand” or “account balance” are
cumulative data.
– Quantity on hand is calculated as:
• Sum of quantities purchased from the table linking inventory to
the receive inventory event.
• LESS: Sum of quantity sold from the sales-inventory table.
– Customer balance:
• Sum of all sales to the customer.
• LESS: Sum of all cash receipts from customer.

73. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• The preceding types of items do not have to be
stored and can be calculated.
• However, explicitly storing them may improve
response time to queries.
– Should be done if the DBMS has the capability to
automatically update these summary values as each
new event occurs.
– Otherwise they will be incorrect.

74. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• The three steps to implementing an REA diagram in a
relational database are:
– Create a table for:
• Each distinct entity in the diagram
• Each many-to-many relationship
– Assign attributes to appropriate tables

75. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Step 3: Use foreign keys to implement 1:1 and 1:N
relationships.
– Many-to-many relationships have been implemented by the
creation of separate tables.
– One-to-one and one-to-many relationships still need to be
implemented in the database.
– But it is usually more efficient to implement them by the
creation of foreign keys.

76. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Step 3: Use foreign keys to implement 1:1 and 1:N
relationships.
– A foreign key is an attribute of one entity that is the primary
key of another entity.
– Customer Number might appear in the customer table as a
primary key and in the sales table as a foreign key.

77. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Using Foreign Keys to Implement 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

78. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

79. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

80. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

81. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

82. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Using Foreign Keys to Implement One-to-Many
Relationships
– Place the primary key of the entity that can occur only once
as a foreign key in the entity that can occur many times.
– EXAMPLE: The primary key for salesperson (which can
occur only once per sale) is a foreign key in the sales table
(which can occur many times for a particular salesperson).

83. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Possible exception:
– 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, you may wish to implement
the relationship with a separate table.

84. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

85. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

86. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE

87. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• It would be useful to step through a complete
process of converting an REA diagram into a
database model.
• The integrated diagram is too extensive to provide
a good, short example.
• Therefore, let’s use a simple, individual transaction
cycle for purposes of this example only.

88. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• Completeness Check
– The list of attributes that users and management want
included in the database provide a means to check and validate
the implementation process.
– Each of those attributes should appear in at least one table as
a primary key or an other 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.

89. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• The need to modify the REA diagram as a result of
this completeness check is not unusual.
• In fact, it is often helpful to create tables and assign
attributes before completion of the REA diagram—
helps clarify what each entity represents.

90. IMPLEMENTING AN REA DIAGRAM IN A
RELATIONAL DATABASE
• When all attributes have been assigned, the basic
requirements for a well-structured relational
database can be used as a final accuracy check:
– Every table has a primary key.
– Other attributes in the table are either a fact that
describes the entity or a foreign key used to link tables.
– Every attribute in every table is single-valued.