NG College, Department of Accounting

Chapter Three
Relational Databases

Introduction
Relational databases underlie most modern integrated AISs. How to participate in the design and
implementation of a database AIS will be explained. The emphasis is on understanding the structure of
the relational database system.
Files versus Databases
To fully appreciate the power of databases, it is important to understand some basic principles about
how data are stored in computer systems. Information about attributes of an entity is stored in fields. All
the fields that contain data about the same entity form a record. A set of related records are grouped to
form a file. For example, all customer receivable records are stored in an account receivable file. A set
of interrelated, centrally coordinated files is referred to as a database.
Example: Accounts Receivable File is shown below:

Database

Customer File Sales File Inventory file

Record 1: Record 2: Record 3: Record 1000:

Customer 1 Customer 2 Customer 3 Customer 1000
Field 1:
Customer No
Field 2:
Customer Name
Field 3:
Street Address

Types of files
Two basic types of files exist. A master file is conceptually similar to a ledger in manual AIS. Master
files sore cumulative information about an organization’s resources and the agents with whom it
interacts. For example the inventory and equipment master files store information about important
organizational resources. Similarly, the customer, supplier, and employee master files store information
about important agents with whom the organization interacts.
Master files are permanent; they exist across all periods. Individual records within a master file,
however, are frequently changed. The most common type of change made to the records in master files
involves updating the data to reflect the effect of specific transactions. Periodically, new records may
also be added to the master file and sometimes, individual records may even be deleted.
The second type of file is called a transaction file, which is conceptually similar to a journal in manual
AIS. Transaction files contain records of the individual business transactions (events) that occur during a
specific fiscal period. For example, a file containing records of sales events and another file containing
records of customer payments. Both of them would be used to update individual customer account
balances in the customers’ master file. Transaction files are not permanent, but are usually only
maintained on-line for one fiscal period.

Accounting Information System 1

 NG College, Department of Accounting

For many years companies created new files and programs each time an information need arose. The
result was a significant increase in the number of master files that organizations stored. This
proliferation of master files created problems. Often, the same data were stored in two ore more master
files. This made it difficult to effectively integrate data stored in different files and to obtain an
organization-wide view of the data. It also created problems because the specific data values stored in
the different files may not have been consistent. For example, new customer address used to ship
merchandise but the old address may be used for billing.

File-Oriented Approach
File 1
Fact A Sales
Fact B Program
Fact C
File 2
Fact B Shipping
Fact D Program
Fact E
File 3
Fact A Billing
Fact G Program
Fact E ©2003 Prentice Hall Business Publishing,
Accounting Information Systems, 9/e, Romney/Steinbart
4-10

Databases
Database systems were developed to address the problems associated with the proliferation of master
files. A database is a set of interrelated, centrally coordinated files. The database approach treats data as
an organizational resource that should be used by and managed for the entire organization, not just the
originating department or function. The focus is data integration and data sharing with all authorized
users. Integration is achieved by combining master files into larger pools of data that many application
programs can access. This is accomplished by a program called database management systems
(DBMSs), which acts as an interface between the database and the various application programs. The
combination of the database, the DBMS and the application programs that access the database through
the DBMS is referred to as the database system.

Database Approach
Database Sales Program

Fact A
Database
Fact B Shipping
management
Program
Fact C system
Fact D
Fact E Billing
Program

©2003 Prentice Hall Business Publishing, 4-13

Accounting Information Systems, 9/e, Romney/Steinbart

Database Systems

Accounting Information System 2

 NG College, Department of Accounting

Logical and Physical Views of Data

Database systems separate the logical and physical views of data. The logical view is how the user or
programmer conceptually organize and understand the data. For example, a sales manager may
conceptualize all information about customers as being stored in form of a table. The physical view
refers to how and where the data are physically arranged and stored on disk, tape, CD ROM, or other
media.

Separating the logical and the physical views of data facilitates developing new applications because
programmers can concentrate on coding the application logic (what the program will do) and do not
need to focus on how and where the various data items are stored or accessed. The database
management system software deals with the links between the way the data are physically stored and
each user’s logical view of the data. Hence, it controls the database so that users access, query, or update
it without reference to how or where the data are physically stored.
Separating the logical and the physical views of data also means that users can change their
conceptualization about relationships among data items (their logical view of the task) without making
changes in the way those data are physically stored. Likewise, the database administrator can change the
physical storage of the data to improve performance, without affecting users or application programs.
Schemas
A schema describes the logical structure of a database. There are three levels of schemas: the
conceptual, the external, and the internal.
 The conceptual level schema is the organization-wide view of the entire database. It lists all data
elements and the relationships between them.
 Te external level schema consists of a set of individual user views of portions of the database,
each of which is also referred to as a subschema.

Accounting Information System 3

 NG College, Department of Accounting

 The internal level schema provides a low level view of the database. It describes how the data are
actually stored and accessed, including information about pointers, indexes, record lengths, and
so forth.

Accountants are frequently involved in developing the conceptual and the external level schemas.
The Data Dictionary
A key component of a DBMS is the data dictionary, which contains information about the structure of
the database. For each data element stored in the database, such as the customer number, there is a
corresponding record in the data dictionary describing it.
Accountants have a very good understanding of the data elements that exist in a business organization,
where they originate, and where they are used. Consequently, accountants should participate in the
development of the data dictionary.
The DBMS usually maintains the data dictionary. In fact, this is often one of the first applications of a
newly implemented database system. Inputs to the data directory include records of any new or deleted
data elements, as well as changes in names, descriptions, or uses of existing data elements. Outputs
include a variety of reports useful to programmers, database designers, and users of the information
system. Sample reports include:
1. A list of all programs in which a data item is used
2. A list of all synonyms for the data elements in a particular file
3. A list of all data elements used by a particular user and
4. A list of all output reports in which a data element used.
These reports are useful in the design and implementation of a database system, provide documentation
of the system, and can become part of the audit trail.
DBMS Languages
Every DBMS must provide a means of performing the three basic functions of creating, changing, and
querying the database. The set of commands used to perform these functions are referred to as the data
definition, data manipulation, and data query languages respectively.
The data definition language (DDL) is used to:
1. Build the data dictionary
2. Initialize or create the database
3. Describe the logical views for each individual user or programmer
4. Specify any limitations or constraints on security imposed on database records or fields
The data manipulation language (DML) is used for data maintenance, which includes such operations as
updating, inserting and deleting portions of the database. The DML simplifies the writing of programs to
accomplish these tasks by requiring references only to the names of data items, rather than to their
physical storage locations.

Accounting Information System 4

 NG College, Department of Accounting

The data query language (DQL) is used to interrogate the database. Whereas the DML is used to change
the contents of the database, the DQL merely retrieves, sorts, orders, and presents subsets of the
database in response to user queries. Most DQLs contain fairly powerful, but easy to use, set of
commands that enables users to satisfy many of their own information needs, without the programmer's
assistance.

Many DBMSs also include a report writer, which is a language that simplifies report creation.
Typically, users need only specify which data elements they want printed and how the report should be
formatted. The report writer then searches the database, extracts the specified data items, and prints them
out according to the user specified format.
All users generally have access to both the DQL and the report writer. Access to the DDL and DML,
however, should be restricted to those employees with administrative and programming responsibilities.
This helps the number of people who have the capability to make changes to the database.
Relational Databases
A DBMS is characterized by the type of logical data model on which it is based. A data model is an
abstract representation of the contents of the database. The overwhelming majority of new DBMSs are
called relational databases because they use the relational data model developed by Dr E.F.Codd in
1970. The relational data model represents everything in the database as being stored in the form of
tables. Technically, these tables are called relations (hence relational data model), but we will use the
two words interchangeably. The data model only describes how the data appear in the conceptual and
external level schemas. The data are not actually stored in tables but rather in the manner described in
the internal level schema.
Each row in a relation is called a tuple and contains data about specific occurrence of the type of entity
represented by that table. For example, each row in the inventory table below contains all the pertinent
data about a particular inventory item in the organization.
Sample Inventory Table
Item Number Description Quantity List price
2014 19" Monitor 32 Br 1,890
2015 21" Monitor 9 Br 2,890
3054 Color Printer 25 Br 3,900
Each column in a table contains information about one specific attribute about an entity.
Types of Attributes
Tables in a relational database have three types of attributes:
A primary key- is the attribute or combination of attributes that uniquely identifies a specific row in a
table. For example, the primary key for the inventory table previously is item number. Often, the
primary key is a single attribute. In some tables however, two or more attributes jointly form the primary
key. For example, in the sales inventory line items table, the primary keys are invoice number and item
number.
A foreign key- is an attribute appearing in one table that is a primary key in another table. Foreign keys
are used to link tables. For example, the attributes customer number and salesperson number are foreign
keys in the sales table; both are used to link the data about a particular sales transaction with information
about the sales person and the customer who participated in that event.
Other non-key attributes- in each table store important information about that entity. For example, in the
inventory table, quantity on hand, description and list price are non-key attributes.
Basic Requirements of the Relational Data Model
The relational data model imposes several requirements on the structure of tables. These include:
1. Every column in a row must be single valued- there shall be one and only one value in each cell.
Thus, each table is a flat table. This requirement is the reason why there is a table called sales
Accounting Information System 5
 NG College, Department of Accounting

inventory line item. Each sales transaction may involve more than one item and a single item
may be sold to different customers with different invoice numbers.
2. Primary keys can't be null- the primary key is the attribute or a combination of attributes that
uniquely identifies a specific row in a table. For this to be true, the primary key for any row can't
be null or blank, for then there would never be a way to uniquely identify that row and retrieve
data stored there. A non-null value for primary key indicates that a specific object exists and can
be identified by reference to its primary key value. This constraint is referred to as the entity
integrity rule; because it ensures that every row in every relation must represent data about some
specific object in the real world.
3. Foreign keys, if not null, must have values that correspond to the value of the primary key in
another relation- foreign keys are used to link rows in one table to rows in another table. This is
only possible if the values correspond to their values in the row of the original table. This
constraint is referred to as the referential integrity rule because it ensures the consistency of the
database. But foreign keys can contain null values. For example, some customers may pay cash
to the seller and the want not to be identified. Hence, the customer number field in the sales table
would be blank.
4. All non-key attributes in a table should describe a characteristic about the job identified by the
primary key- most tables contain other attributes in addition to the primary and foreign keys.
These are other important facts about the entity under consideration.
These four constraints produce a well structured (normalized) database in which data are consistent and
redundancy is minimized and controlled.
Problems associated with storing all Data in One table
- One problem with trying to store all the data in one table is that it creates a great deal of redundancy.
Such redundancy will make file maintenance unnecessarily time consuming and error prone. Three
specific types of problems can occur.
 The first is called update anomaly because updates or changes to data values are not correctly
recorded. For example, changing a customer's address requires searching the entire table and
changing every occurrence of that customer's address. Overlooking even one row would create
inconsistency in the database and multiple rows with different addresses exist for the same
customer. It costs in wrong mailing and error analysis of sales etc.
 The second one is insert anomaly, because there is no way to store information about prospective
customers until they actually make the purchase. Until then, the sales invoice number column
would be blank. But, the invoice number is part of the primary key and it cannot be blank.
 The third one is delete anomaly, because it involves unintended results that arise when deleting a
row in that table. If a customer has made only one purchase, consisting of a single item, deleting
that row from the table would result in the loss of all information about that customer.
The Solution: A set of tables
The problem associated with trying to store all the data in one table can be avoided by creating a set of
tables- one table for each entity of interest. This is because:
o Redundancy is greatly reduced- non-key attributes are stored only once. This avoids update
anomaly problems. If some attributes are repeated, these are foreign keys and referential integrity
rule will ensure update anomaly problems.
o Adding new data to the system is easy- this avoids the insert anomaly
o Improves the deletion of information- deletion of one row will not result in entire loss of
information about a specific entity. This will rectify the problem of delete anomaly.
Two Approaches to Database Design
There are two basic approaches to design a well structured relational database:

Accounting Information System 6

 NG College, Department of Accounting

- One approach called normalization. It starts with the assumption that everything is initially stored in
one large table. A set of rules is then followed to decompose that initial table into a set of normalized
tables. The objective is to produce a set of tables what are called third normal form (3NF), because
such tables are free of the types of update, insert and delete anomalies (problems described earlier).
- An alternative way to design well structured relational databases involves semantic data modeling.
Under this approach, the database designer uses knowledge about how business processes typically
work and about the information needs associated with transaction processing to first draw a
graphical picture of what should be included in the database. The resulting figure can then be
directly used to create a set of relational tables that are in 3NF.
Semantic data modeling has two significant advantages over simply following the rules of
normalization.
1. Because it makes use of the system designer's domain knowledge about business processes and
practices, it facilitates the efficient design of transaction processing databases.
2. Because the resulting graphical model explicitly represents information about the organization's
business processes and policies, it facilitates communicating with the intended users of the
system. Such communication is extremely important in ensuring that the resulting system meets
the actual needs of users.
Database Systems and the Future of Accounting
Database systems may profoundly affect the fundamental nature of accounting. Some of these include:
1. Database systems may lead to the abandonment of the double entry accounting model. The basic
rational for the double entry model is that the redundancy of recording the amount of a
transaction twice provides a check on the accuracy of data processing. But data redundancy is the
antithesis of the database concept. If the amounts associated with a transaction are entered into a
database system correctly, then it is necessary to store them only once, not twice. Computer data
processing is sufficiently accurate making checks and double checks unnecessary.
2. Database systems also have the potential to significantly alter the nature of external reporting.
Considerable time and effort are currently being invested in defining how companies should
summarize and report accounting information for external users. A copy of the company's
financial database may be simply made available to external users in lieu of the traditional
financial statements so that they would be free to manipulate and analyze the raw data in
whatever manner they see fit.
3. The most significant effect of database systems will be in the way that accounting information is
used in decision making. The difficulty of formulating ad hoc queries in accounting systems
based on traditional files or non-relational DBMS meant that accountants act in effect as
information gatekeepers. Financial information was readily available only in predefined formats
and at specified times. Relational databases, however, provide query languages that are powerful
and easy to use. Thus, managers need not get bogged down in procedural details about how to
receive information. Instead, they can concentrate solely on specifying what they want. As a
result, financial reports can be easily prepared to cover whatever time periods managers want to
examine, not just the time frames accountants traditionally use.
4. Relational DBMSs can also accommodate multiple views of the same underlying phenomenon.
For example, tables storing information about assets can include columns not only for historical
cost, but also for current replacement costs and market values. Thus, managers will no longer be
forced to look at data in ways predefined by accountants.
5. Relational DBMSs provide the capability of integrating financial and operational data. For
example, data about customer satisfaction, collected by surveys or interviews could be stored in
the same table used to store information about current account balances and credit limits.

Accounting Information System 7

 NG College, Department of Accounting

Managers would thus have access to a richer set of data for making tactical and strategic
decisions.
In all these ways, relational DBMSs have the potential to increase the use and value of accounting
information for making the tactical and strategic decisions involved in running an organization.
Accountants, however, must become knowledgeable about database systems so that they can participate
in designing the accounting information systems of the future. Such participation is important for
ensuring that adequate controls are included in those systems to safeguard the data and ensure the
reliability of the information provided.
Data Modeling and Database Design
Design of a database is much more than simply learning the syntax of a how to use a particular DBMS.
Building accurate databases requires a great deal of careful planning and design before even sitting
down at the computer. The issues of data modeling will be emphasized next. The REA accounting
model and the entity relationship (E-R) diagramming and how to use these tools to build a data model of
AIS will be seen in the next discussions. Finally, how to implement the resulting data model in a
relational database will be considered.
Database Design Process
There are six basic steps in database design:
1. Planning Sage- involves the initial planning to determine the need for and feasibility of
developing the new system. This includes preliminary judgments about the proposals
technological and economic feasibility.
2. Requirements Analysis Stage- involves identifying user information needs, defining the scope of
the proposed new system, and using information about the expected number of users and
transaction volumes to make preliminary decisions about hardware and software requirements.
3. Design Stage- involves developing the different schemas for the new system, at the conceptual,
external, and internal levels. The requirements analysis and design stages are the stages of data
modeling.
4. Coding- involves translating the internal level schema into the actual database structures that will
be implemented in the new system. This is also the stage when new applications are developed.
5. Implementation- this stage includes all activities associated with transferring data from existing
systems to the new database AIS, testing the new system, and training employees how to use it.
6. Operation and Maintenance- involves using and maintaining the system including carefully
monitoring system performance and user satisfaction to determine the need for making system
enhancements and modifications. Eventually, changes in business strategies and practices or
significant new developments in information technology initiate investigation into the feasibility
of developing a new system and the entire process starts again.

Figure 3-2 Data modeling in the database design process

Accounting Information System 8
 NG College, Department of Accounting

Accountants can and should participate in all stages of the database design process, although the level of
their participation in each stage is likely to vary.
- In the planning stage, accountants both provide some of the information used to evaluate the
feasibility of the proposed project and participate in making that decision.
- In the requirements analysis and design stages, accountants participate in identifying user
information needs, developing the logical schemas, designing the data dictionary, and specifying
controls.
- During the implementation stage, accountants can also help test the accuracy of the new database
and the application programs that will use that data.
- Finally, accountants use the database system to process transactions, and sometimes they even help
manage it.
Accountants may provide the greatest value to their organizations by taking responsibility for data
modeling. Data modeling is the process of defining a database so that it faithfully represents all aspects
of the organization, including its transactions with the external environment.
Data modeling occurs during both the requirements analysis and design stages of the database design.
Two important tools that accountants can use to facilitate participation in data modeling are entity
relationships diagramming and the REA data model.
Entity Relationship Diagrams
An entity relationship (E-R) diagram is a graphical technique for portraying a database schema. It is
called an ER diagram because it shows the various entities being modeled and the important
relationships among them. In an ER diagram, entities appear as rectangles and relationships between
entities are represented as diamonds.
An ER diagram not only depicts the contents of a database but also graphically models an organization.
Thus, the ER diagrams can be used not only to design databases but also to document and understand
existing databases and to reengineer business processes. An important step in database design is
deciding which entities need to be modeled. The REA data model is useful for making that decision.
The REA Data Model
Specifically used for AIS database design, the REA data model is conceptual modeling tool that focuses
on the business semantics underlying an organization's value chain activities. The REA data model
provides guidance for database design by identifying what entities should be included in the AIS
database and by prescribing how to structure relationships among the entities in that database.
Types of Entities
The REA model classifies entities into three distinct categories: the resources that the organization
acquires to use, the events (business activities) in which the organization engages, and the agents
participating in the events. Recently, some researchers proposed a fourth type of entity-locations such as
stores, warehouses, etc. But they may be considered as resources, or attributes of the event entity.
Resources- are those things that have economic value to the organization. These include cash,
inventories, equipment and machinery, supplies, warehouses, factories, and land.
Events- are the various business activities about which management wants to collect information for
planning or control purposes. The REA data model helps people design databases that support the
management of an organization's value chain activities. Therefore, most of the events in an REA data
model fall into one of the two categories: economic exchanges or commitments.
- Economic exchanges- are the value chain activities that directly affect the quantity of resources. For
example, the sales event decreases the quantity of inventory and the cash receipts event increases the
amount of cash.
- Commitments- represent promises to engage in future economic exchanges. For example, customer
orders are commitments that lead to future sales. Often such commitments are necessary precursors
to the subsequent economic exchanges. Moreover, management needs to track commitments for
Accounting Information System 9
 NG College, Department of Accounting

planning purposes. For example, manufacturing firms often use information from customer orders to
plan production.
Agents- are the people and organizations that participate in the events and about whom information is
desired for planning, control, and evaluation purposes. Examples include employees, customers, vendors
etc.
Basic REA Template
The REA data model prescribes a basic pattern for how the three types of entities should relate to one
another. Each event entity is linked to a resource entity. Events such as the sale of merchandise that
change the quantity of a resource are linked to that resource in what is called a stock flow relationship.
Other events such as taking a customer order that represent future commitments are linked to resources
in what are called reserve relationships. Each event entity is also linked to two agent entities. The
internal agent is the employee who is responsible for the resource affected by the event; the external
agent is the outside party to the transaction. Each economic exchange event is linked in a give to get
duality relationship with another economic exchange event. These economic duality relationships reflect
the basic business principle that organizations typically engage in activities that use up resources only in
hopes of acquiring some other resource in exchange. For example, the sales event, which requires giving
up (decreasing) inventory is related to the cash receipts event which requires getting (increasing) the
amount of cash.

Developing an REA Diagram for One Transaction Cycle

Developing an REA diagram for a specific transaction cycle consists of the following four steps:
1. Identify the pair of economic exchange events that represent the basic give to get economic
duality relationship in that cycle.
2. Identify the resources affected by each economic exchange event and the agents who participate
in those events.
3. Analyze each economic exchange event to determine whether it should be decomposed into a
combination of one or more commitment events and an economic exchange event. If necessary,

Accounting Information System 10

 NG College, Department of Accounting

replace the original economic exchange event with the resulting set of commitment and
economic exchange events.
4. Determine the cardinalities of each relationship.
Let’s look at the above steps how to develop the revenue cycle for a hypothetical company:
Step 1 Identify Economic Exchange Events
The basic REA template consists of a pair of events, one that increases some resource and one that
decreases some resource. The events are drawn as rectangles and the economic duality relationship
between them as a diamond. In drawing REA model, the paper is divided into three columns-one for
each type of entity:
 The left column is used for resources
 The center column for events, and
 The right column for agents.
Readability is further enhanced if the events entities are drawn from top to bottom corresponding to the
sequence in which they occur.
Step 2: Identify Resources and Agents
Once the events of interest have been specified, the resources that are affected by those events need to
be identified. For example, the sales event is translated to giving inventory to customers and the cash
receipts event is translated to receiving cash from customers. Hence, the inventory and cash entities are
added in the resource column and the stockflow relationship is drawn between those entities and the
events that affected them.
What about A/R? Accounts receivable is not modeled as a separate entity because it is not an
independent object but simply represents a timing difference between two events: sales and cash
receipts. That is, accounts receivable simply represents sales for which customer payments have not yet
been received. Consequently, if data about both sales and cash collections are already stored in the
database, all the information needed to calculate A/R can be derived from the information stored about
those two events. How to extract this information will be discussed later.
After specifying the resources affected by each event, it is necessary to identify the agents who
participate in those events. There will always be at least one internal agent (an employee) and in most
cases an external agent (the customer or vendor) who participate in each event. For example, customers
and salespersons participate in the sale event and customers and cashiers participate in the cash
collection event. Hence, in the REA diagram, these three agent entities shall be added: salespersons,
customers, and cashiers. Relationships shall be included to indicate which agent participated in which
events.
It is important to understand that the agents in the REA data model represent functions, not specific
people. For example, the salesperson and the cashier are shown as separate entities but the same person
may take both roles. The REA data model requires that each event be linked to at least one resource and
at least two agents. This information needs to be supplemented by interviews with management to
identify other possible relationships of interest. For example, if the organization assigns customers to
specific salespeople to provide customized service, then a direct relationship between the two agent
entities (salesperson and customer) would be added to the diagram.

Accounting Information System 11

 NG College, Department of Accounting

Step 3:
Include Commitment Events
This step is analyzing each economic exchange event to determine whether it can be decomposed into a
combination of one or more commitment and exchange events. It is important for management to get up
to date information about various orders to reorder various inventory items. It is also important to know
which orders have been shipped and when. Then, the single economic exchange event labeled sales may
be replaced with a combination of a commitment event which is labeled customer orders and the
economic exchange event that was labeled sales. The cash receipts economic exchange event will not be
decomposed because whether payment is received immediately or later by mail, what shall be tracked is
actual receipts from customers.
Billing as an event is not modeled because it is neither an economic exchange nor a commitment.
Printing an invoice and mailing it to the customer doesn't increase or decrease the amount of any
resource. It is simply an information processing event that merely retrieves information from the
database about previous customer orders and sales events. Organizations build databases to collect,
process, and store information about their value chain activities. Printing documents and reports or
querying the database is just different ways of retrieving information about those activities for use in
making decisions. Such information processing activities do not change the contents of the database and
are not modeled as events in an REA diagram.
Step 4: Determine Cardinalities of Relationships
This is a step to add information about the nature of relationships between the various entities.
Cardinalities indicate how many instances of one entity can be linked to one specific instance another
entity. For example, cardinalities indicate how many sales transactions can be linked to each individual
customer and, conversely, how many customers can be linked to each individual sales transaction.
In a relational database, each entity is a table and each instance is a row in that table. Therefore, in
relational databases, cardinalities indicate how many rows in one table can be linked to each row in
another table.

Accounting Information System 12

 NG College, Department of Accounting

Cardinalities are represented as pairs of numbers next to each entity. The first number is the minimum
cardinality. It indicates whether a row in this table must be linked to at least one row in the table on the
opposite side of that relationship. A minimum cardinality of 0 means that a new row can be added to that
table without being linked to any specific rows in the table on the other side of the relationship.
The second number in each cardinality pair is the maximum cardinality. It indicates whether one row in
that table can be linked to more than one row in the other table. A maximum cardinality of 1 means that
each row in that table can be linked to at most only one row in another table.

Documentation of
Business Practices

 The one minimum for the cash receipts event

indicates that cash is not received prior to
delivering the merchandise
 The N maximum for the cash receipts event
means that customers may pay for several
sales with one check

Cash Sales-
(1, N) Cash Receipts (0, N) Sales
Receipts
©2003 Prentice Hall Business Publishing, 5-57
Accounti ng Information Systems, 9/e, Romney/Steinbart

Accounting Information System 13

 NG College, Department of Accounting

REA diagram for a sample revenue cycle

Customer
Inventory- (1,N) (1,1) Participant (0,N) Customer
Orders
Orders

(0,N) (1,1)

(0,1) Participant

(0,N)
Inventory- Leads to
Inventory (0,N) Salesperson
Sales (0,N)

(0,1)
(1,N)
Participant

(1,1)
Sales

(1,1) Participant (0,N) Customer

©2003 Prentice Hall Business Publishing, 5-28

Accounting Information Systems, 9/e, Romney/Steinbart

Three basic types of relationships between entities are possible depending on the maximum cardinality
associated with each entity.
1. A one to one (1:1) relationship exists when the maximum cardinality for each entity in that
relationship is one.
2. A one to many (1:N) relationship exists when the maximum cardinality of one entity in that
relationship is 1 and the maximum cardinality of the other entity in that relationship is N
3. Many to many (M:N) relationship exists when a maximum cardinality for both entities in the
relationship is N.
Do not confuse the notation used for minimum and maximum cardinalities (a pair of numbers separated
by a comma) with the notation used to describe the cardinality of a relationship between two entities (a
pair of numbers separated by a colon).
Rules for Specifying Cardinalities
The database designer doesn't arbitrarily choose cardinalities. Instead, cardinalities reflect facts about the
organization being modeled and its business practices. This information is obtained during the
requirements definition stage of the database design process. Certain general principles can provide a
starting point for developing an REA data model for any organization.
Cardinality Rules for Agent-Event Relationship
Almost always, the minimum and maximum cardinalities associated with the event entity in every
agent-event relationship will be both 1.
- The minimum cardinality associated with the event is 1 because there must be some agent
who participates in that event.
- The maximum cardinality is 1 because the organization wants to be able to hold some
specific agent responsible for that event.
There is also a general principle concerning cardinalities associated with the agent entity in the agent-
event relationship. The cardinalities associated with each agent entity in the agent-event relationship all
have zero minimums and N maximums.

Accounting Information System 14

 NG College, Department of Accounting

The maximum cardinality associated with internal agent entities is almost always N, because
organizations expect their employees will participate in numerous events. It is also usually N for
external agents, because organizations often engage in repeat transactions with the same suppliers and
customers.
There are two reasons why the minimum cardinality associated with agent entities in the agent-event
relationship is usually zero:
- Organizations want to be able to add information about potential customers and suppliers even
though those agents may not have participated yet in the business transactions
- Event entities are analogous to transaction files, where as agent entities are analogous to master
files. At the end of the fiscal year, the contents of events tables are archived and the new fiscal
year begins with no rows in various event tables. In contrast, information about agents is
permanent in nature and is carried over from one fiscal period to the next. Therefore, at the
beginning of a new fiscal year customers may not be linked to any current sales.
Cardinality Rules for Resource-Event Relationships
The minimum and maximum cardinalities associated with each resource in resource-event relationship
are zero and N, respectively. This is by the same reasoning as the case for cardinalities associated with
agents in agent-event relationship.
One exception to this rule is that the maximum cardinality associated with the inventory resource is
sometimes one. This is when organizations track specific physical inventory items such as original
artwork, vehicles, or houses that are identified by a primary key which is some type of serial number. In
such cases, a given row in inventory table could be associated with at most one sales transaction and
would have maximum cardinality of 1 instead of N.
The minimum cardinality associated with event entities in resource-event relationship is usually 1. For
example, each sale event must include at least one row in the inventory table and each payment received
from a customer must be deposited into some cash account.
The only exception to this general rule arises if an event potentially can be linked to more than one
resource entity. For example, consider a household appliance repair business. Some services may not
require parts whereas others may include labor plus parts. Thus, the sale event for such repair business
could be linked with inventory entity, or to repair service entity or both types of resources.
Consequently, the minimum cardinality for the sales event would be zero in both of those relationships.
In rare situations, an event might be linked to one of several unique agent entities. In such cases, the
minimum cardinality associated with the event entity again will be 0 instead of the normal 1.
However, there is no general principle concerning the maximum cardinality associated with event
entities in resource event relationship. Instead, the maximum cardinality depends on the nature of the
resources affected by that event and by the organizations policies. For example, customers may by and
are encouraged to buy as many as products of a company. Hence, customer order and sales events can be
linked to many rows in inventory table.
Cardinality Rules for Event-Event Relationships
Almost any kind of cardinality pair is possible for each event entity in event-event relationships. The
organization's business practices and policies must be understood to decide which possibility is correct.
For example, collections from customers may be at once (1:1) or in installments (1: N).
The only general modeling principle that applies to event-event relationships is that for two temporally
ordered events, the minimum cardinality for the first event is 0, because at the time it occurs, the other
event has not yet happened. Often, but not always, the minimum cardinality for the event that occurs
second is 1, indicating that the first event had already occurred.

Accounting Information System 15

 NG College, Department of Accounting

Implementing an REA Diagram in a Relational Database

Once the REA diagram has been developed, it can be used to design a well structured
relational database. Implementing an REA diagram in a relational database is a three-
step process:
1. Create a table for each distinct entity and for each many to many relationships
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 Entity and M:N Relationships
A properly designed relational database has a table for each distinct entity and for each
many to many relationships in an REA diagram. Some of the distinct entities include:
cash, inventory, customer orders, sales, cash receipts, employees, and customers. The
expected many to many relationships include customer order-inventory, sales inventory,
and sales-cash receipts.
It is good practice to give each table the same name as the entity that it represents. Tables
representing M:N relationships, however, are often titled by hyphenating the names of the
two entities that are linked. For example, Sales-Inventory line table.
Step 2: Assign Attributes to Each Table
During the data modeling process, users and management will have identified facts that
they want to collect. For example, for inventory items the attributes may include item
number, description, cost and selling price.
- Assign primary keys- every table in a relational database must have a primary key,
consisting of attributes or a combination of attributes. Companies often create numeric
identifiers for specific resources, events and agents. These numeric identifiers are
good candidates for primary keys. Usually, the primary key of a table representing an
entity is a single attribute. The primary key for M:N relationship tables, however,
always consists of two attributes that represent the primary keys of each entity linked
in that relationship. For example, the primary key of a sales-inventory table consists
of both the invoice number (primary key of the sales entity) and item number (primary
key of the inventory entity). Such multiple-attribute primary keys are called
concatenated keys.
- Assign other attributes to appropriate tables- additional attributes besides the primary
key are included in each table to satisfy transaction processing requirements and
management's information needs. Some of the attributes such as the date and amount
of each sale are necessary for complete and accurate transaction processing and the
production of financial statements and managerial reports. Other attributes are stored
because they facilitate the effective management of an organization's resources, events
and agents.
- Non-key attributes in M:N relationship tables- attributes that help keep the table flat
and that can't be stored in separate tables are listed as attributes in M:N relationship
tables. For example, quantity sold can't be an attribute in the sales table because a
Accounting Information System 16
 NG College, Department of Accounting

single invoice may have several values. In addition, a single item may be sold in many
different sales transactions. Hence, it may not be an attribute in inventory table.
Hence, as it applies to a specific item included in a specific sales transaction, it
belongs in the M:N relationship table that links these two entities.
o Price data- may be stored in both the inventory and sales-inventory tables. The
inventory table lists suggested selling price that remains constant. But the sales
inventory table stores actual sales price which varies during the year in relation to
promotions.
o Cumulative data- includes such information as quantity on hand (in inventory table)
and account balance (in the customer table). Theoretically, it is unnecessary to store
such information separately in the database because the system can readily compute
them when necessary. Explicitly storing cumulative totals and balances, however,
may improve response time to queries.
Step 3: Use Foreign Keys to Implement 1:1 and 1:N Relationships
M:N relationships must be implemented as separate tables to have a well structured
relational database. Although 1:1 and 1:N relationships can be implemented as separate
tables, it is usually more efficient to implement them by means of foreign keys.
One to one Relationships- in a relational database, one to one relationships between
entities can be implemented by including the primary key of one entity as a foreign key in
the table representing the other entity. The choice is arbitrary. Careful analysis of the
minimum cardinalities of the relationship may suggest which approach is likely to be
more efficient. For example, in the 1:1 relationship between sales and customer
payments,
- the minimum cardinality for the sales event is 0 indicating the existence of
credit sales
- the minimum cardinality for the cash receipt event is 1 indicating that customer
payments only occur after a sale has been made (assuming no advance
collections are made)
In this case including invoice number as foreign key in cash receipts event may be more
efficient because then only that one table would have to be accessed and updated to
process data about each customer payment. When events are sequential, including the
primary key of the event that occurs first as a foreign key in the event that occurs second
may improve internal control.
One to many relationships- As with 1:1 relationships, 1:N relationships also can be
implemented in relational databases with foreign keys. To do this, place the primary key
of the entity with the maximum cardinality of N as a foreign key in the entity that has
maximum cardinality of 1. For example, the primary keys of the salesperson and
customer tables are included as foreign keys in the sales table.
A potential exception to this general rule for implementing 1:N relationships may occur if
the relationship includes two sequential event entities, and the event that occurs first is

Accounting Information System 17

 NG College, Department of Accounting

also the one that participates many times in that relationship. In that case, implementing
the relationship as a separate table might improve internal control.
REA Diagram for Documenting Business Processes
REA diagrams are especially useful for documenting advanced AIS built using databases,
because the cardinalities in REA diagrams provide information about the organization's
business practices and the nature of its economic exchanges.
Correctly interpreting what the cardinalities in an REA diagram mean requires
understanding exactly what the occurrence of each entity represents. This is usually easy
for both agent and event entities.
Understanding what each occurrence of resource entity represents may be difficult.
Consider inventory, for example. An individual occurrence of this entity might represent
either a specific physical object or a class of objects depending on the nature of the
inventory. In such cases, examining the attributes associated with that entity may indicate
what it represents. For example, if there is a column entitled ''quantity on hand'', each row
refers to a specific kind of inventory, not an individual object. In the case of sales-
inventory relationship, such column will not exist because items may be identified by
serial number and there could only be one of each item.
Every organization will have its own unique REA diagram at least because business
practices and relationship cardinalities differ across companies. Differences in business
practices also result in differences in entities being modeled.
The cardinalities in REA diagram also provide information about business controls. For
instance, each row in the cash entity represents a specific account. One may be checking
account, another payroll account, another money market investment account etc. Cash-
cash receipts relationship being modeled as 1:N reflects a sound control practice of
depositing all cash collections from customers into the company's checking account.
Extracting Information from the AIS
A completed REA diagram also serves as a useful guide for querying an AIS database.
Elements such as journals, ledgers and information about receivables as well as payables
may seem missing in a database AIS. But they are present though stored in a different
format.
Producing journals and ledgers- queries can be used to generate journals and ledgers
from a relational database built on the REA model. The information normally found in a
journal is stored in the tables used to record data about events. For example, a sales
journal can be produced by writing a query that displays the appropriate entries in the
sales table for a given period. A query can be written to display every entry in a sales
table, to produce a list of all sales events, both cash and credit sales. Traditionally, sales
journals are used to record all credit sales. Therefore, the query to produce a credit sales
journal would have to include both the sales and cash receipts tables. The logic on the
query is would include restricting the output to display only those sales that are not linked
to a corresponding customer payment event that occurred on the same day as a sale.

Accounting Information System 18

 NG College, Department of Accounting

The information traditionally contained in ledgers is often stored in a relational database

in a combination of resources and events tables. For example, accounts receivable doesn't
appear as a table. Instead, it is derived by calculating the total amount of sales for which
customer payments have not been received.
Extracting Information
From the AIS
(0, 1) (1, N) Cash
Sales collections

 Each sales transaction is paid in full by a

cash collection event.
 Each customer payment may be for more
than one sale.
 What is the query logic?
 Total accounts receivable is the sum of all
sales for which there is no remittance
number. ©2003 Prentice Hall Business Publishing,
5-60
Accounting Information Systems, 9/e, Romney/Steinbart

 Each sales transaction can be paid in installments.

 Each customer payment is for just one sale.
 What is the query logic?
 (1) sum all sales; (2) sum cash collections; then A/R = (1)-(2)
Extracting Information
From the AIS
(0, 1) (1, 1) Cash
Sales collections

 Each sales transaction is paid in full by a

cash collection event.
 Each customer payment is for one sale.
 What is the query logic?
 Total accounts receivable is the sum of all
sales for which there is no remittance
number.
©2003 Prentice Hall Business Publishing, 5-62
Accounting Information Systems, 9/e, Romney/Steinbart

Extracting Information
From the AIS
(0, N) (1, N) Cash
Sales collections

 Each sales transaction may be paid for in

installments.
 Each customer payment may be for more
than one sale.
 W hat is the query logic?
 (1) Sum all sales; (2) Sum all cash
collections; Then A/R = (1)
- (2)
©2003 Prentice Hall Business Publishing, 5-63
Accounting Information Systems , 9/e, Romney/Steinbart

Providing other financial statement information- an REA diagram can guide the writing
of queries to produce other information that would be included in financial statements.

Accounting Information System 19

 NG College, Department of Accounting

Querying a single table can derive many financial statement items. For example,
summing the amount column of the sales table would yield sales for the current period.
Preparing 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, information such as time of sale, returns and
allowances etc can be included as attributes in the sales table. New attributes such as
credit rating could be added easily. The REA data model can be used to build a database
that allows the AIS to change in response to management's changing information
requirements. The REA data model shows that accounting need not be limited to the
traditional double entry model with its journals, ledgers, and chart of accounts. Instead,
the REA data model supports the view that accounting a process or system of collecting
and disseminating information about an organization's business transactions. Although
the mechanics of accounting may change, the need for the results (managerial reports and
financial statements) of accounting remains.

Accounting Information System 20