Archives of Business Research – Vol. 9, No.

7
Publication Date: July 25, 2021
DOI:10.14738/abr.97.10534.
Adamson, I. L. (2021). Using the REA Data Model in Order to Reduce Design Complexity in an Inventory Management Relational
Database, and the Need for a Relational Database Complexity Metric. Archives of Business Research, 9(7). 71-78.

Using the REA Data Model in Order to Reduce Design Complexity

in an Inventory Management Relational Database, and the Need
for a Relational Database Complexity Metric
Ian L Adamson Ph.D., CPA, CITP
Brock University, St. Catharines, Ontario

ABSTRACT
With the extensive use of relational databases in the business environment there is
a need to reduce database complexity in order to avoid data inconsistency and
redundancy, which can provide a company with unreliable and/or meaningless
data and information. The use of the REA Data Model in database design can
significantly help with this problem. The model can eliminate the need for
unnecessary data artifacts which should only be generated by the system when
needed. This paper also addresses the need for a Relational Database Complexity
Metric. A simple and easy to understand metric is presented.

RELATIONAL DATABASES DESIGN

Relational databases are used extensively in today’s business environment, from simple small
enterprises using Microsoft Access to large corporations using Oracle or Microsoft SQL Server.
One common use is for the management of Inventory.

A database must be efficiently designed in order to avoid errors and data inconsistencies
redundancies. Data redundancy occurs when the same piece of data exists in multiple places,
whereas data inconsistency is when the same data exists in different formats in multiple tables.
Unfortunately, data redundancy can cause data inconsistency, which can provide a company
with unreliable and/or meaningless information.

Poorly designed relational databases can be very complex, difficult to maintain and prone to
anomalies. In order to avoid this situation, an effective design methodology should be used. A
common methodology is the use of the Entity-Relationship Model (ERM).

THE TRADITIONAL ENTITY-RELATIONSHIP MODEL (ERM)

Relational database design involves developing a detailed data model that can then be used to
create the database. Historically software engineers have used the Entity Relationship Model
(ERM), a graphical tool that represents the logical relationships between entities. Entities are
typically shown as rectangles with the connections between the entities portraying the
relationships. In a logical sense, entities are the equivalent of grammatical nouns, such as
employees, inventory, payables, or fixed assets, with the characteristics of the entity defined by
means of its properties called attributes. Relationships are the equivalent of verbs or
associations, such as the act of purchasing or selling, or an employee being a member of a
department.

Services for Science and Education – United Kingdom

Archives of Business Research (ABR) Vol. 9, Issue 7, July-2021

On implementation of the database, the entities become relations or tables while the
relationships reveal the logical connection between the tables. Such connections can be one-to-
one, one-to-many, or many-to-many. Fore example the figure below shows a one-to-many
relationship between the Vendor and Raw Materials Inventory entities.

This shows that the Vendor entity can provide many types of Raw Materials, but Raw Materials
can only be provided by one Vendor. The diamond shape shows the relationship has been
identified as R which could also be the verb ‘supplies’. For a number of relationships in an ERM
they can be shown as R1 to Rn. On implementation in a relational database both Vendor and Raw
Materials Inventory become tables.

How are the relationships established? Both Vendor and Raw Materials Inventory have to have
a unique identifier in order to identify each instance of the entity class. Such identifiers are
called primary keys and are usually numeric. The primary key for Vendor could be
VendNumber and for Raw Materials Inventory, RmNumber. The one-to-may relational
connection would be implemented with the Raw Materials Inventory entity having
VendNumber as the foreign key. The foreign key is implemented on the many side of the
relationship. This example can be shown by the following figure. Primary Keys are shown as PK
while the Foreign Key is shown as FK.

The database schema for the two tables that can be directly implemented into the database. The
term "schema" denotes how the database is organized or divided into tables. Th schema also
shows the primary keys, the attributes of the tables as well as the relationships between the
tables. It can be directly implemented in the database.

Services for Science and Education – United Kingdom 72

Adamson, I. L. (2021). Using the REA Data Model in Order to Reduce Design Complexity in an Inventory Management Relational Database, and the
Need for a Relational Database Complexity Metric. Archives of Business Research, 9(7). 71-78.

In order to construct an Entity Relationship Model of a system the entities or nouns are first
identified and then the relationship constructed. It would be too much for this paper to look at
a complete Inventory Management System, thus a simple example of the purchase of Raw
Materials will be examined. Possible entities, but not all, are shown in the following table:

Vendor
Purchase
Purchasing Agent
Raw Materials
Receiving
Receiving Clerk
Cash Disbursement
Cash
Cash Disbursements Journal
Controller

Relationships are shown in the following ERM as identified by R1 to R9. Each of the relationships
would have to be implemented by primary keys and foreign keys. All together there are eight
entity classes and nine relationships for this scenario. This can be seen in the following figure.

Purchasing Agent, Receiving Clerk, and Controller are all employees in an Employee table which
should be present in the database. There would be no point in creating additional tables for
these entities.

URL: http://dx.doi.org/10.14738/abr.97.10534 73
Archives of Business Research (ABR) Vol. 9, Issue 7, July-2021

In a full inventory management database system, the number of tables and relationships would
be very large resulting in a degree of complexity that would be significant. This complexity
could result in multiple data redundancies and duplication of tables. By looking at the Resource-
Event-Agent Data Model it is possible to significantly reduce such complexity.

THE RESOURCES, EVENTS, AGENTS (REA) MODEL (WILLIAM MCCARTHY 1982)

Pavel Hruby shows that REA is a business process modeling methodology that is closer to
business reality than any other known alternative. An increasing number of business analysts
have found that the models they develop become better when they have REA in mind. REA is a
minimal model. McCarthy and his colleagues have spent years distilling business relationships
down to the smallest set of objects required to do the job. Other data may well be required in
particular industries or situations, which the REA model permits, but there is no extra baggage
to get in the way. For example, Purchase Orders may be used, but are not needed. (Haugen &
McCarthy, 2000).

They go on to say that it is easier to adapt a minimal model which provides for extensions, than
a complicated model with assumptions that do not fit particular situations.

Researchers have shown that using the REA Data Model to develop a relational database results
in a product that is concise and easy to understand. Rosli et. Al. (2009) applied the REA model
approach and process into a real case study of sales order and cash receipt systems. Their result
showed that REA model captures only essential aspects of economic phenomena and thus, (1)
models are kept concise and easy to understand, (2) models can be used for many applications,
and (3) derived artefacts are always consistent by means of the models. This new developed
system has resulted in the improvement in business processes efficiency. This would also imply
that such REA database systems are less complex.

Dunn et. al. (2016) discussed the issue that enterprise systems typically include constructs such
as ledgers and journals with debit and credit entries as central pillars of the systems’
architecture due in part to accountants and auditors who demand those constructs. At best,
structuring systems with such constructs as base objects results in the storing the same data at
multiple levels of aggregation, which creates inefficiencies in the database. Once again this
shows that the REA model can reduce these inefficiencies and result in a less complex database.

USING THE REA MODEL IN DATABASE DESIGN

REA systems are usually modeled as relational databases, though this is not necessarily a
requirement, typically using entity-relationship diagrams.

The REA model derives its name from the three distinct categories of entities resources, events,
and agents:
• Resources are acquired and used by the company and have economic value to the
organization.
• Events are typically business activities in which the company engages, and about which
management wishes to gather data for planning or control purpose.
• Agents include people and organizations who participate in events. Management also
needs gather data on these entities for planning, control, and evaluation purposes.
Services for Science and Education – United Kingdom 74
Adamson, I. L. (2021). Using the REA Data Model in Order to Reduce Design Complexity in an Inventory Management Relational Database, and the
Need for a Relational Database Complexity Metric. Archives of Business Research, 9(7). 71-78.

As a rule, central to an REA model is as a pair of events associated with an exchange

relationship. The structure of this relationship is based upon the duality principle. The REA
duality principle: An event generating an outflow of resources must be paired in duality
relationship with an event generating an inflow of resources, and vice-versa. These
corresponding events are also called give and take events. Therefore, an exchange transaction
is basically a pair of dual events that links the act of giving, the decrement event, with the act of
taking, the increment event. If there is no duality then the transaction is meaningless, with the
exception of a transaction such as a charitable donation where there would be an inflow of a
resource such as cash, but no outflow, thus no duality.

One of these events usually corresponds to a resource being given away, while the other
corresponds to a resource being received. For example, an event resulting in the purchase or
inflow of raw materials inventory must be related to an event of equal outflow of a cash
disbursement for the raw materials.

An REA diagram for the purchase of Raw Materials is shown in the following figure. It should
be noted that this is only one interpretation, depending upon the perspective of the designer.
(Source: Armitage 1985) Instead of using R1 to R5, verbal descriptions of the relationships have
been used in order to provide more clarity.

Notice that all but one agent are employees, the Vendor being an outside agent. Thus, the total
number of entities is only six with five relationships. The summary of the differences between
the Entity-Relationship Model and the REA Model can be seen in the following table.

URL: http://dx.doi.org/10.14738/abr.97.10534 75
Archives of Business Research (ABR) Vol. 9, Issue 7, July-2021

Entity Relationship Model REA Model

8 Entities 6 Entities
9 Relationships 5 Relationships

There is no journal such as the cash disbursements journal or the material receipts journal.
Such entities are an artifact of the traditional accounting/inventory control system and cannot
be classified as resources, events, or agents. The REA Model eliminates data structures that are
not necessary in the electronic era. These entities disappear since they can be generated in real
time using record detail in an REA system. An example, using pseudocode, to produce a material
receipts journal using the following tables is shown below.

From this data there would be an application program, written in a language such as PLSQL,
C++ or even COBOL, to construct the cash disbursements journal. Simple partial pseudo code
for a program is shown below.

Any reports, listings, journals and ledgers can be generated in a similar manner whenever they
are needed, not just at month or year end. It therefore can be readily seen that a database
designed utilizing the REA Data Model will produce a less complex database. But what is really
needed is a simple metric that be used to determine the complexity of any relational database.
Piattini, et. al. demonstrated metrics for relational databases, but for the average user, they are
difficult to understand and implement.

Services for Science and Education – United Kingdom 76

Adamson, I. L. (2021). Using the REA Data Model in Order to Reduce Design Complexity in an Inventory Management Relational Database, and the
Need for a Relational Database Complexity Metric. Archives of Business Research, 9(7). 71-78.

A RELATIONAL DATABASE COMPLEXITY METRIC

The purpose is to develop an easy-to-understand metric that can determine the complexity of
any relational database. The starting point is that the database must be in at least Boyce-Codd
normal form, (BCNF). BCNF significantly reduces the redundancies and repetitions in a
database, thus making it less complex.

BCNF is a slightly stronger version of the third normal form in that all redundancies based on
functional dependency have been removed. By examining the Vendor and Material Receipts
tables, the following functional dependencies can be demonstrated.

FD:VendNumber → VendName, VendAddress, VendPhone, VendContact

FD: RecptNumber: → Amount, Date, VendNumber

Thus VendName, VendAddress, VendPhone, and VendContact are functionally dependent on

VendNumber. There are no other functional dependencies in the Vendor table. The same
situation applies to the Materials Receipt table.

The proposed metric can be divided into two distinct parts:

1. A table-oriented matric; and
2. A schema-oriented metric.

In examining a table-oriented metric (TCM) the user needs to consider the simplest, least
complex version of the table in question. For example, the Vendor table has five attributes. If
this is the least number of attributes that can describe a Vendor, then the complexity metric can
be defined as follows:
TCM = 1 - Σ(number of attributes in the table)/Σ(least number of attributes needed)

Or TCM = 1 - 5/5 = 0, the lowest level of complexity.

If a Vendor table has seven attributes, then:

TCM = 1- 7/5 = 0.4, or 40% increased complexity for a Vendor table.

This means that any table in a database must have a standard reference for the least number of
attributes needed to describe the entity. This should not be a difficult task. Any increase in the
number above zero would need to be questioned as to the necessity of the additional attributes.
A schema-oriented metric (SCM) can be determined in a similar manner.

SCM = 1 - Σ(number of tables in the database)/Σ(least number of tables needed)

Trying to keep the number of tables to a minimum would decease the database complexity and
encourage the designer not to add unnecessary or redundant tables. Future work will be
looking at refining these metrics, because they do not consider metrics for primary or foreign
keys as well as additional tables such as an M:N relational table or index tables.

URL: http://dx.doi.org/10.14738/abr.97.10534 77
Archives of Business Research (ABR) Vol. 9, Issue 7, July-2021

CONCLUSION
In comparing the REA Model of Raw Materials Purchase with the Entity Relationship Diagram
it is evident that there are fewer entities and relationships. The result would be reduced data
redundancy and a less complex database. The traditional model would include tables for the
Purchases Journal and the Cash Disbursements Journal which contain data that are already
present in other tables such as Purchases, Receiving and Cash Disbursements. This would be an
increase in data redundancy and adds to the complexity of the database. Any changes to these
tables would require corresponding changes to Purchases, Receiving and Cash Disbursements.
This could result in insert, update, and deletion anomalies and data inconsistencies within the
database, a situation prone to error.

Thus the REA Model results in a more simplified relational data base which significantly
reduces the chance of data duplication, data redundancy, and as a result, a data base that
requires less maintenance and is less complex.

The need for a Relational Database Complexity Metric in todays extensive use of relational
databases is obvious. The example shown is very simple but is only in the preliminary stages. It
needs to be further researched.

References
Adamson, I.L., “Reducing Complexity in an Accounting System by Using the REA Data Model to Design a
Relational Database", Journal of Accounting & Marketing,Vol. 6, No. 2, 2017.
Armitage, Howard M., “Linking Management Accounting Systems with Computer Technology,” The Society of
Management Accountants of Canada, 1985.
Calero, C., Piattini, M., and Genero, M., “Database Complexity Metrics”, QUATIC, 2001.
Piattini, M., Calero, C., and Genero, M., “Table Oriented Metrics for Relational Databases”, Software Quality
Journal, Vol. 9, 2001.
Chen, Peter, “The Entity-Relationship Model--Toward a Unified View of Data.” ACM Transactions on Database
Systems, Vol. 1, No. 1, March 1976.
Dunn, Cheryl L., Gerard, G., Grabski, S., “Resources-Events-Agents Design Theory: A Revolutionary Approach to
Enterprise System Design” Communications of the Association for Information Systems, 2016.
Haugen, Robert., and McCarthy, William E., “REA, a Semantic Model for Internet Supply Chain Collaboration”
Business Object Component Workshop VI: Enterprise Application Integration, 2000
McCarthy, William E., “The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared
Data Environment.” The Accounting Review, Vol. LVII, No. 3, (July 1982).
Hruby, P., Model-Driven Design Using Business Patterns, Springer, 2006.
Rosli, Khairina, Ahmi, Aidi, and Mohamad, Liana, “Resource-Event-Agent Modelling in Revenue Information
System RiS Development: Smart Application for Direct-Selling Dealers and SMEs” Journal for the Advancement of
Science & Arts, Vol. , No. 1, January – June 2009.

Services for Science and Education – United Kingdom 78