BM2401

THE REA APPROACH TO DATABASE MODELING

The REA Approach
The REA approach was developed specifically for designing an accounting information system (AIS). It focuses
on the business semantics underlying an organization’s value-chain activities. It guides database design by
identifying what entities should be included in the AIS database and prescribing how to structure relationships
among the entities in that database (Romney & Steinbart, 2021).

Figure 1. Basic Elements of REA Diagram

Source: Accounting Information System (14th ed.), 2018, p. 530
The REA approach is so named because it classifies entities into three (3) distinct elements or categories
(Romney & Steinbart, 2021):
• Resources - These include economic value such as cash and inventory (see Figure 1), supplies, factories,
and land.
• Events - These are various business activities in which the management wants to collect information for
planning and controlling purposes. In the above figure, the events are the sale and receipt of cash.
• Agents - These are the people and organizations participating in events and about whom information is
desired for planning, control, and evaluation purposes.

The Basic REA Template

The REA model prescribes a basic pattern (see Figure 2) for how the three (3) types of entities (resources,
events, and agents) should relate to one another. The pattern has the following essential features (Romney &
Steinbart, 2021):
1. Each event is linked to at least one (1) resource that it affects - As shown in Figure 2, some events, such as
the one labeled “Get Resource A,” increase the resource quantity. Common examples of such “Get” events
include the receipt of goods from a supplier (which increases the quantity on hand of inventory) and the
receipt of payments from a customer (which increases the amount of cash). Other events, such as the one
labeled “Give Resource B” in Figure 2, directly decrease the quantity of a resource. Common examples of

08 Handout 1 *Property of STI

 student.feedback@sti.edu Page 1 of 5
 BM2401

such “Give” events are paying suppliers and selling merchandise, which decrease the amount of cash and
quantity on hand of inventory.
2. Each event is linked to at least one (1) other event - Also shown in Figure 2, Get Resource A is linked to
Give Resource B and labeled as an economic duality relationship. Such give-to-get duality relationships
reflect the basic business principles that organizations typically engage in activities that use up resources
only in the hopes of acquiring some other resource in exchange.
For example, the “Sale” event, which requires giving up (decreasing) inventories, is related to the “Receive
Cash” event, which involves getting (increasing) the amount of cash.
3. Each event is linked to at least two (2) participating agents - For accountability, organizations need to be
able to track the actions of employees and monitor the status of commitments and economic duality
exchanges engaged in with outside parties. As shown in the figure below, each event is linked to two (2)
participating agent entities. For events involving transactions with external parties, the internal agent is
the employee responsible for the resource affected by the event, and the external agent is the outside
party to the transaction. For internal events, such as the transfer of raw materials from the storeroom to
production, the internal agent is the employee giving up responsibility for or custody of resource, and the
external agent is the employee receiving custody of or assuming responsibility for the resource.

Figure 2. Standard REA Template

Source: Accounting Information System (14th ed.), 2018, p. 531

Developing an REA Model

There are three (3) steps in developing an REA model or diagram (Romney & Steinbart, 2021):
1. Identify relevant events - This involves recognizing the events the management wants to collect
information on. At a minimum, it must include two (2) events that comprise the basic give-to-get economic
duality relationships (see Figure 2).
2. Identify resources and agents - Once relevant events have been specified, the resources affected by those
events must be identified. It involves answering three (3) questions:
• What economic resources are reduced by the “Give” event?
• What economic resources are acquired by the “Get” event?
• What economic resources are affected by a commitment event?

08 Handout 1 *Property of STI

 student.feedback@sti.edu Page 2 of 5
 BM2401

For example, Anna had observed that the Sale event involves giving inventory to the customer and that
the Receive Cash event involves obtaining payments. She also observed that the Take Customer Order
event involves setting aside merchandise for a specific customer. To maintain the accuracy of inventory
records and facilitate timely reordering to avoid stockouts, each Take Customer Order event should reduce
the quantity available of that particular inventory item.

3. Determine the cardinalities of relationships - Cardinalities describe the relationship between two (2)
entities by indicating how many instances of one (1) entity can be linked to each specific instance of
another entity. No universal standard exists for representing information about cardinalities in REA
diagrams. This handout uses the graphical “crow’s foot” notation style to represent cardinality
information.

Crow’s foot notation - Also called an inverted arrow or “fork.” It was introduced by Gordon Everest in 1976
and is used as a symbol to indicate a relationship's multiple or many sides.

Figure 3. Graphical Symbols for Representing Cardinality Information

Source: Accounting Information System (14th ed.), 2018, p. 536

Figure 3 depicts four (4) possible combinations of minimum and maximum cardinalities.

• The minimum cardinality can be either zero (0) or one (1), depending upon whether the
relationship between the two (2) entities is optional (the minimum cardinality is zero; see rows
one [1] and three [3] in Figure 3) or mandatory (the minimum cardinality is one [1], as in rows two
[2] and four [4]).
• The maximum cardinality, on the other hand, can be either one (1) or many (crow’s feet symbol),
depending upon whether each instance of entity A can be linked to at most one (1) instance or
potentially many instances of entity B.

08 Handout 1 *Property of STI

 student.feedback@sti.edu Page 3 of 5
 BM2401

Figure 4. Sample REA diagram for a Company’s Revenue Cycle

Source: Accounting Information System (14th ed.), 2018, p. 533

The details about cardinalities in Figure 4 can be interpreted using Figure 3, as follows.

➢ Sales-customer relationship. The minimum and maximum cardinalities next to the customer
entity are both one (1). This pattern is the same as in the second row of Figure 3. Thus, the
minimum cardinality of one (1) next to the Customer entity in Figure 4 indicates that each sale
transaction (entity A) must be linked to some specific customer (entity B). The maximum
cardinality of one (1) means that each sale transaction can be linked to, at most, only one (1)
specific customer.
This reflects the normal business practice that only one (1) legally identifiable customer (which
could be an individual or business is held responsible for a sale and its subsequent payment.
➢ Cardinality pair next to the Sale entity. As shown in the third row of Figure 3, the minimum
cardinality is zero (0), and the maximum cardinality is many. The zero (0) cardinality means
the relationship is optional: A customer does not have to be associated with any specific sale
transaction.
This can allow the company to enter information about prospective customers (e.g., the Leads
in SAP B1) to whom it can send advertisements before they have ever purchased anything.
The maximum cardinality is many, indicating that a specific customer may be associated with
multiple sale transactions.

08 Handout 1 *Property of STI

 student.feedback@sti.edu Page 4 of 5
 BM2401

➢ Cardinality pairs next to the Inventory entity in Figure 4 have a minimum of one (1) and a
maximum of many for every relationship. This is the same pattern as in row four (4) of Figure
3. This means that every customer order or sale transaction must involve at least one (1)
inventory item (for the company cannot sell “nothing”) but may involve multiple items (e.g.,
a customer could purchase a television and an aircon in the same transaction).
➢ Cardinality pairs next to the Sale entity in its relationship with Take Customer Order entity
are like the pattern in the first row of Figure 3. The minimum cardinality of zero (0) reflects
that an order may not have been turned into an actual sale transaction. The maximum
cardinality of one (1) indicates that the company fills all customer orders in full rather than
making several partial deliveries.

Three (3) Types of Relationships

Three (3) basic types of relationships between entities are possible, depending on the maximum cardinality
associated with each entity (Romney & Steinbart, 2021):
1. A one-to-one (1:1) relationship - It exists when the maximum cardinality for each entity in that
relationship is one (1).

2. A one-to-many (1: N) relationship - It exists when the maximum cardinality for each entity in that
relationship is one (1) and the maximum cardinality for the other entity in that relationship is many.

3. A many-to-many (M: N) relationship - It exists when the maximum cardinality for both entities in the
relationship is many.

Note: The minimum cardinality does not matter in determining the relationships.

Reference
Romney, M. B., & Steinbart, P. J. (2021). Accounting Information Systems (15th Ed.). Pearson Education, Inc.

08 Handout 1 *Property of STI

 student.feedback@sti.edu Page 5 of 5