Accounting Information Systems

CHAPTER FOUR
RELATIONAL DATABASES
4.1) The Database Systems;
4.1.1) What does it mean Data?
For financial and/or legal reasons, organizations collect and store vast amounts of data about employees,
customers, finances, vendors, inventory, competitors, and markets, to name only a few. The amount of
data needed is important, because people generally make better decisions if they have more data available
to them.
For example, a car dealership, bank, or credit union will make better decisions about who to give car
loans by looking at a person's credit report information than if they simply based their decision on the
word of the customer. Looking at your credit report, a bank representative would see a listing of your
payment history on loans and credit cards, including your mortgage. She would also see information
about outstanding loans, debt repayment and credit limits. The report may also contain information about
jobs you have held and public record information (birth date and address).
Likewise, a factory will improve its ability to manufacture products by tracking and managing data
about inventory, (name, identification number, location, and quantity), production schedule, quality
control measures, and much more. You can begin to see why collecting data is important. However, the
true value of data cannot be realized until it is appropriately organized, stored, analyzed, and eventually
used for a specific purpose.
4.1.2) What ate the Elements of Data?
Data are raw facts and figures that are processed to produce information, which are used as a raw
material for information. Thus, the following are some of the most common elements of data.
(1) Character; a character is the most basic element of data that can be observed and manipulated.
Behind it are the invisible data elements we call bits and bytes, referring to physical storage
elements used by the computer hardware. A character is a single symbol such as a digit, letter, or
other special character, (example, $, #, and ?).
(2) Field; a field contains an item of data; that is, a character, or group of characters that are related.
For instance, a grouping of related text characters such as "John Smith" makes up a name in the
name field. Let's look at another example. Suppose a political action group advocating gun
control in Pennsylvania is compiling the names and addresses of potential supporters for their
new mailing list. For each person, they must identify the name, address, city, state, zip code and
telephone number. A field would be established for each type of information in the list. The
name field would contain all of the letters of the first and last name. The zip code field would
hold all of the digits of a person's zip code, and so on. In summary, a field may contain an
attribute, (example, employee salary) or the name of an entity, (example, person, place, or event).
(3) Record; a record is composed of a group of related fields. As another way of saying it, a record

CH 4; Relational Database; Page 1

 Accounting Information Systems

contains a collection of attributes related to an entity such as a person or product. Looking at the
list of potential gun control supporters, the name, address, zip code and telephone number of a
single individual would constitute a record. A payroll record would contain the name, address,
social security number, and title of each employee.
(4) Database File; as we move up the ladder, a database file is defined as a collection of related
records. A database file is sometimes called a table. A file may be composed of a complete list of
individuals on a mailing list, including their addresses and telephone numbers. Files are
frequently categorized by the purpose or application for which they are intended. Some common
examples include mailing lists, quality control files, inventory files, or document files. Files may
also be classified by the degree of permanence they have. Transition files are only temporary,
while master files are much more long-lived.
(5) Database; organizations and individuals use databases to bring independent sources of data
together and store them electronically. Thus, a database is composed of related files that are
consolidated, organized and stored together. One collection of related files might pertain to
employee information. Another collection of related files might contain sports statistics.
Organizations and individuals may have and use many different databases, depending on the
nature of the work involved. For example, a library database might consist of several related, but
separate, databases including book titles and author names, book description, books on order,
books checked out, and similar sets of information. Most organizations have product information
databases, customer databases, and human resource databases that contain information about
employees, salaries, home address, stock purchase plans, and tax deduction information. In each
case, the data stored in a database is independent from the application programs which use and
process the data.
(6) Data Management System; data management systems are used to access and manipulate data in
a database. A database management system is a software package that enables users to edit, link,
and update files as needs dictate.
(7) Key; in order to track and analyze data effectively, each record requires a unique identifier or
what is called a key. The key must be completely unique to a particular record just as each
individual has a unique social security number assigned to them. In fact, social security numbers
are often used as keys in large databases. You might think that the name field would be a good
choice for a key in a mailing list. However, this would not be a good choice because some people
might have the same name. A key must be identified or assigned to each record for computerized
information processing to function correctly. An existing field may be used if the entries are
entirely unique, such as a social security or telephone number. In most cases, a new field will be
developed to hold a key, such as a customer number or product number.
4.1.3) What is a Database?
A database is a large collection of related data that are typically stored in computerized, linked files
and manipulated by specialized software packages called database management systems (DBMSs).
Examples of databases include the repositories of information and related files for inventory systems,
general ledger systems, and production scheduling systems. In most applications, these systems are
complex combinations of data, processing software, and perhaps separate hardware that interact with one
another to support the specific storage and retrieval tasks required of them.

CH 4; Relational Database; Page 2

 Accounting Information Systems

Technically, not every collection of data is a database. For example, the time-card data from a weekly
payroll system might be stored in a computer, but a single file containing such data alone is generally too
simplistic to be called a „„database.‟‟ Similarly, the budget or other financial information typically created
in spreadsheet programs such as Excel is not a database. Most commercial databases are very large,
invaluable collections of proprietary data that developers carefully design and protect, and that often form
the core of efficient accounting information systems.
4.1.4) The Database Management Systems;
A database is a collection of related files that are usually integrated, linked or cross-referenced to one
another. The advantage of a database is that data and records contained in different files can be easily
organized and retrieved using specialized database management software called a database management
system, (DBMS) or database manager.
4.1.4.1) The Fundamentals of Database Management Systems (DBMS);
A database management system is a set of software programs that allows users to create, edit and update
data in database files, and store and retrieve data from those database files. Data in a database can be
added, deleted, changed, sorted or searched all using a DBMS. If you were an employee in a large
organization, the information about you would likely be stored in different files that are linked together.
One file about you would pertain to your skills and abilities, another file to your income tax status,
another to your home and office address and telephone number, and another to your annual performance
ratings. By cross-referencing these files, someone could change a person's address in one file and it would
automatically be reflected in all the other files. DBMSs are commonly used to manage;
 Membership and subscription mailing lists,  Accounting and bookkeeping
information,
 The data obtained from scientific research,  Customer information,
 Library information,
 Inventory information,  Personal records,
4.1.4.2) The DBMSs and File Management Systems;
Computerized file management systems (sometimes called file managers) are not considered true
database management systems because files cannot be easily linked to each other. However, they can
serve as useful data management functions by providing a system for storing information in files. For
example, a file management system might be used to store a mailing list or a personal address book.
When files need to be linked, a relational database should be created using database application software
such as Oracle, Microsoft Access, IBM DB2, or FileMaker Pro.

CH 4; Relational Database; Page 3

 Accounting Information Systems

4.1.4.3) What are the advantages and disadvantages of DBMS?

The following points are the most common advantages and disadvantages of database managements
system (DBMS).
The Advantages of a DBMS;
(A) Improved availability; one of the principle advantages of a DBMS is that the same
information can be made available to different users.
(B) Minimized redundancy; the data in a DBMS is more concise because, as a general rule, the
information in it appears just once. This reduces data redundancy, or in other words, the need to
repeat the same data over and over again. Minimizing redundancy can therefore significantly
reduce the cost of storing information on hard drives and other storage devices. In contrast, data
fields are commonly repeated in multiple files when a file management system is used.
(C) Accuracy; accurate, consistent, and up-to-date data is a sign of data integrity. DBMSs foster
data integrity because updates and changes to the data only have to be made in one place. The
chances of making a mistake are higher if you are required to change the same data in several
different places than if you only have to make the change in one place.
(D) Program and file consistency; using a database management system, file formats and system
programs are standardized. This makes the data files easier to maintain because the same rules
and guidelines apply across all types of data. The level of consistency across files and programs
also makes it easier to manage data when multiple programmers are involved.
(E) User-friendly; data is easier to access and manipulate with a DBMS than without it. In most
cases, DBMSs also reduce the reliance of individual users on computer specialists to meet their
data needs.
(F) Improved security; as stated earlier, DBMSs allow multiple users to access the same data
resources. This capability is generally viewed as a benefit, but there are potential risks for the
organization. Some sources of information should be protected or secured and only viewed by
select individuals. Through the use of passwords, database management systems can be used to
restrict data access to only those who should see it.
The Disadvantages of a DBMS;
(A) Cost; implementing a DBMS system can be expensive and time-consuming, especially in large
organizations. Training requirements alone can be quite costly.
(B) Security; even with safeguards in place, it may be possible for some unauthorized users to
access the database. In general, database access is an all or nothing proposition. Once an
unauthorized user gets into the database, they have access to all the files, not just a few.
Depending on the nature of the data involved, these breaches in security can also pose a threat
to individual privacy. Steps should also be taken to regularly make backup copies of the
database files and store them because of the possibility of fires and earthquakes that might
destroy the system.
4.1.5) The Database View Models;
There are two view models in Database systems. These are the logical view of data, and physical view
of data.

CH 4; Relational Database; Page 4

 Accounting Information Systems

4.1.7.1) Logical Data View Model;

In computing and more specifically systems engineering, a logical data model (LDM) is a
representation of an organization's data, organized in terms of entities and relationships and is
independent of any particular data management technology. It is a type of data model.
Logical data models represent the abstract structure of a domain of information. They are often
diagrammatic in nature and are most typically used in business processes that seek to capture things of
importance to an organization and how they relate to one another. Once validated and approved, the
logical data model can become the basis of a physical data model and inform the design of a database.
Logical data models should be based on the structures identified in a preceding conceptual data model,
since this describes the semantics of the information context, which the logical model should also reflect.
Even so, since the logical data model anticipates implementation on a specific computing system, the
content of the logical data model is adjusted to achieve certain efficiencies.
The term “Logical Data Model” is sometimes used as a synonym of “Domain Model” or as an
alternative to the domain model. While the two concepts are closely related, and have overlapping goals,
a domain model is more focused on capturing the concepts in the problem domain rather than the
structure of the data associated with that domain. Thus, the following are the reasons for building a
logical data model;
 Helps common understanding of business data elements and requirements,
 Provides foundation for designing a database,
 Facilitates avoidance of data redundancy and thus prevent data and business transaction
inconsistency
 Facilitates data re-use and sharing,
 Decreases development and maintenance time and cost, and
 Confirms a logical process model and helps impact analysis.
4.1.7.2) Physical View Model;
A physical data model, (or database design), is a representation of a data design which takes into
account the facilities and constraints of a given database management system. In the lifecycle of a project,
it typically derives from a logical data model, though it may be reverse-engineered from a given database
implementation. A complete physical data model will include all the database artifacts required to create
relationships between tables or to achieve performance goals, such as indexes, constraint definitions,
linking tables, partitioned tables or clusters. Analysts can usually use a physical data model to calculate
storage estimates, that it may include specific storage allocation details for a given database system.

CH 4; Relational Database; Page 5

 Accounting Information Systems

4.1.7.3) Data Dictionary;

Thus, one of the key components of a DBMS is a special file called the data dictionary. The data
dictionary contains information about the structure of the data base. For each data element stored in the
data base, such as the customer number, there is a corresponding record in the data dictionary describing
it. The data dictionary is usually maintained automatically by the DBMS. In fact, this is often one of the
first applications of a newly implemented data base system. Inputs to the data dictionary 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, data base designers, and users of
the information system. Sample reports include;
(1) A list of all programs in which a data items 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 elements is used. Thus, these reports are
useful in the design and implementation of a data base system, provides documentation
of the system, and can become part of the audit trail.
4.1.6) What are the DBMS Languages?
Thus, every DBMS must provide a means of performing the three basic functions of creating, changing,
and querying the data base. The sets of commands used to perform these functions are referred to as the
data definition, data manipulation, and data query languages, respectively.
(A) The Defined Definition Language (DDL); the DDL is used to, (1) build the data dictionary, (2)
initialize or create the database (3) describe the logical views for each individual use or
programmer, and (4) specify any limitations or constraints on security imposed on data base
records or fields.
(B) Data manipulation languages DML; the DML is used for data maintenance, which includes
such operations as updating, inserting, and deleting portions of the data base. 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.
(C) Data Query Language (DQL); the Query language allows the user to interact directly with the
database software in order to perform information-processing tasks using data in a database. It is
usually an easy-to-use computer language that relies on basic words such as SELECT, DELETE,
or MODIFY. Using query language and a computer keyboard, the user enters commands that
instruct the DBMS to retrieve data from a database or update data in a database.

CH 4; Relational Database; Page 6

 Accounting Information Systems

(D) Structured Query Language (SQL); is one type of query language that is widely used to
perform operations using relational databases. Remember that relational databases are composed
of tables with rows and columns. SQL can be used to retrieve information from related tables in a
database or to select and retrieve information from specific rows and columns in one or more
tables. One of the keys to understanding how SQL works in a relational database is to realize that
each table and column has a specific name associated with it. In order to query a table, the user
specifies the name of the table (indicating the rows to be displayed) and the names of the columns
to be displayed. A typical SQL query contains three key elements;
 SELECT, (the column names to be displayed),
 FROM, (indicates the table name from which column
names will be derived), and
 WHERE, (describes the condition for the query).
Example of SQL; to illustrate the application of this type of query, let's assume a particular user wishes
to query a relational database containing information about donors to a charitable organization. If the user
wants to know the name and address of all individuals donating Birr 100 or more, the following query
might be used;
SELECT - Name, FROM - Donor WHERE - Donation
Address List Amount > 100
Thus, once this command has been executed, the computer will display a list of donors that meets the
predefined criteria. In this case, all of the data are extracted from a single table. Similar queries can be
made to extract data from multiple tables. Such a strategy might be used to analyze customer information
involving billing data and order data, using two separate tables. In this case, the FROM command would
list the names of the two tables involved.
4.1.7) The Relational Databases;
In relational databases, the relationship between data files is relational, not hierarchical. Hierarchical
and network databases require the user to pass down through a hierarchy in order to access needed data.
Relational databases connect data in different files by using common data elements or a key field. Data in
relational databases is stored in different tables, each having a key field that uniquely identifies each row.
Relational databases are more flexible than either the hierarchical or network database structures. In
relational databases, tables or files filled with data are called relations, tuples designates a row or record,
and columns are referred to as attributes or fields. Relational databases work on the principle that each
table has a key field that uniquely identifies each row, and that these key fields can be used to connect one
table of data to another.

CH 4; Relational Database; Page 7

 Accounting Information Systems

Thus, one table might have a row consisting of a customer account number as the key field along with
address and telephone number. The customer account number in this table could be linked to another
table of data that also includes customer account number (a key field), but in this case, contains
information about product returns, including an item number (another key field). This key field can be
linked to another table that contains item numbers and other product information such as production
location, color, quality control person, and other data. Therefore, using this database, customer
information can be linked to specific product information.
The relational database has become quite popular for two major reasons. First, relational databases can
be used with little or no training. Second, database entries can be modified without redefining the entire
structure. The downside of using a relational database is that searching for data can take more time than if
other methods are used.
Figure 4.1; The Relational Database;

4.2) The Database Design Process;

Database design is the process of producing a detailed data model of a database. This logical data
model contains all the needed logical and physical design choices and physical storage parameters needed
to generate a design in a Data Definition Language, which can then be used to create a database. A fully
attributed data model contains detailed attributes for each entity.
The term database design can be used to describe many different parts of the design of an overall
database system. Principally, and most correctly, it can be thought of as the logical design of the base data
structures used to store the data. In the relational model these are the tables and views. In an object
database the entities and relationships map directly to object classes and named relationships. However,
the term database design could also be used to apply to the overall process of designing, not just the base

CH 4; Relational Database; Page 8

 Accounting Information Systems

data structures, but also the forms and queries used as part of the overall database application within the
database management system (DBMS).
Thus, the process of doing database design generally consists of a number of steps which will be carried
out by the database designer. Usually, the designer must;
Determine the relationships between the different data elements.
Superimpose a logical structure upon the data on the basis of these relationships.
Determine the purpose of the database; this helps prepare for the remaining steps.
Find and organize the information required; gather all of the types of information to record
in the database, such as product name and order number.
 Divide the information into tables; divide information items into major entities or subjects,
such as Products or Orders. Each subject then becomes a table.
 Turn information items into columns; decide what information needs to be stored in each
table. Each item becomes a field, and is displayed as a column in the table. For example, an
Employees table might include fields such as Last Name and Hire Date.
 Specify primary keys; choose each table‟s primary key. The primary key is a column, or a set
of columns, that is used to uniquely identify each row. An example might be Product ID or
Order ID.
 Set up the table relationships; look at each table and decide how the data in one table is
related to the data in other tables. Add fields to tables or create new tables to clarify the
relationships, as necessary.
 Refine the design; analyze the design for errors. Create tables and add a few records of
sample data. Check if results come from the tables as expected. Make adjustments to the
design, as needed.
 Apply the normalization rules; apply the data normalization rules to see if tables are
structured correctly. Make adjustments to the tables
A database is a large collection of related data that are typically stored in computerized, linked files
and manipulated by specialized software packages called database management systems (DBMSs).
Examples of databases include the repositories of information and related files for inventory systems,
general ledger systems, and production scheduling systems. Thus, the following simple design process
applying by the organizations.
Figure 4.2; Database design process;

CH 4; Relational Database; Page 9

 Accounting Information Systems

4.3) The Resources, Events and Agents (REA) Data Model;

The REA model is an accounting framework for modeling an organization‟s critical resources, events,
and agents and the relationships between them. Unlike some traditional accounting systems, REA systems
permit both accounting and non-accounting data to be identified, captured, and stored in a centralized
database. From this repository, user views can be constructed that meet the needs of all users in the
organization. REA models may be implemented within either relational or object-oriented database
architectures. For purposes of discussion in this chapter, we will assume a relational database as this is the
more common architecture for business applications.
The following Figure illustrates the basic REA model, which is a unique version of an entity
relationship (ER) diagram consisting of three entity types (resources, events, and agents) and a set of
associations linking them. From this point, we will refer to this documentation technique as an REA
diagram.
Figure 4.3; REA Model;

(1) Resources; the economic resources are things of economic value to the organization. They are
defined as objects that are both scarce and under the control of the enterprise. Resources are used
in economic exchanges with trading partners and are either increased or decreased by the
exchange.
(2) Events; the REA modeling embraces two classes of events. These are the economic events and
support events. The economic events are phenomena that effect changes, (increases or
decreases), in resources as represented by the stock flow relation. They result from activities such
as sales of products to customers, receipt of cash from customers, and purchases of raw material
from vendors. Economic events are the critical information elements of the accounting system
and must be captured in as disaggregated, (highly detailed) form as possible to provide a rich
database. The support events, (not shown in the above figure) include control, planning, and
management activities that are related to economic events, but do not directly effect a change in
resources. Examples of support events include;

CH 4; Relational Database; Page 10

 Accounting Information Systems

 Determining inventory availability for a customer prior to making a sale,

 Verifying supporting information (performing a three-way-match) prior to disbursing
cash to a vendor, and
 Checking customer credit before processing a sale.
(3) Agents; the economic agents are individuals and departments that participate in economic and
support events. They are parties both inside and outside the organization with discretionary power
to use or dispose of economic resources. Each economic event is associated with at least one
internal agent and one external agent who participate in the exchange. The respective roles of
internal and external agents in transactions with outsiders are usually apparent. For example, in a
sales transaction, the internal agents are various employees of the company and the external agent
is the customer. For purely internal transactions, however, the roles of internal and external agent
may not be so obvious. The convention in REA modeling is to treat such transactions as if they
were sales. For example, in the transfer of products from work-in-process to finished goods
inventory, the work-in-process clerk is viewed as selling the product to the finished goods clerk.
Therefore, the clerk giving up control and reducing the resource, (work-in-process clerk) is the
internal agent and the clerk assuming control and increasing the resource (finished goods clerk) is
the external agent. Internal and external agents are also involved in support events, but the
exchange involves information rather than economic resources. For example, a customer
(external agent) checking on product prices receives information from the sales clerk (internal
agent), who gives up the information. Linking internal agents to events in this way promotes
control and permits organizations to assess the actions taken by their employees.
(4) Duality; the REA‟s semantic features derive from the elements of an economic transaction. The
rationale behind an economic transaction is that two agents each give the other a resource in
exchange for another resource. In actuality, the exchange is a pair of economic events, which is
expressed via the duality association shown in the above figure. In other words, each economic
event is mirrored by an associated economic event in the opposite direction, Like.. give event and
receive event. From the perspective of the organization function being modeled, the give half of
the exchange decreases the economic resource, as represented by the outflow association. The
receive half of the exchange increases the economic resources represented by an inflow
association. Following Figure presents several examples of the give and receive events as they
relate to the revenue, expenditure, and conversion cycles. Note that an economic exchange does
not require duality events to occur simultaneously.

CH 4; Relational Database; Page 11

 Accounting Information Systems

Figure 4.4; Examples of Give and Receive Events;

For example, inventory is reduced immediately by the sale to a customer, but cash may not be
increased by the customer‟s remittance for several weeks. The REA model accommodates credit-based
transactions and the associated time lags, but does not employ traditional mechanisms such as AR or AP
ledgers in accounting for these events. In fact, REA rejects the need for any accounting artifacts,
including journals, ledgers, and double-entry book keeping. As mentioned previously, economic
phenomena should be captured in a disaggregated form consistent with the needs of multiple users. To
reflect all relevant aspects of economic events, therefore, business data must not be preformatted or
artificially constrained. Journals, ledgers, and double-entry bookkeeping are the traditional mechanisms
for formatting and transmitting accounting data, but they are not essential elements of an accounting
database. REA systems capture the essence of what accountants account for by modeling the underlying
economic phenomena directly. Organizations employing REA can thus produce financial statements,
journals, ledgers, and double-entry accounting reports directly from event database tables via user views.
Thus, the following are the advantages of REA model;
 The REA model helps managers identify non-value added activities that can be eliminated.
Thus, increased productivity via elimination of non-value added activities generates excess
capacity
 Storing both financial and nonfinancial data in the same central database reduces multiple data
collection, data storage, and maintenance
 Detailed financial and nonfinancial business data supports a wider range of management
decisions. Thus, increased competitive advantage by providing more relevant, timely, and
accurate information to managers
4.3.1) Developing an REA Model (View Modeling - Creating an Individual
REA Diagram);
This section describes the view modeling process as applied to creating an REA diagram. The process
involves the following steps;

CH 4; Relational Database; Page 12

 Accounting Information Systems

(1) Identify the event entities, (2) Identify the resource entities,
(3) Identify the agent entities, (4) Determine associations and cardinalities
and. between entities.
These procedures are performed for each organizational function being modeled. The result is several
individual REA diagrams. The modeling process is completed during the view integrating phase
(described later) where the individual models are consolidated into a single global model. To illustrate
REA view modeling, we will use a simplified description of a revenue cycle process. The following are
its key features;
4.3.1.1) Step-1; Identify the Event Entities;
The first step in developing an REA model is to identify the event entities in the function being
modeled. The events in this revenue cycle example can be identified as the value-added actions that Apex
employees take. These entities include verify availability, take order, ship product, and receive cash.
Thus, an REA model must, at a minimum, include the two economic events that constitute the give and
receive activities that reduce and increase economic resources in the exchange. In addition, it may include
support events, which do not change resources directly. We will next examine each identified event above
to determine whether it should be classified an economic event or a support event.
(1) Verify Availability; the Verify Availability event is a support event because it does not
directly increase or decrease a resource. The decision to add this entity to the model will
depend on management‟s need for information regarding customer inquiries. Such
information could help them determine which inventory items customers most frequently
demand. This may be different from what Apex is actually selling to customers. For example,
an analysis of inquiries that do not lead to placed orders may indicate that customers are
shopping around for, and getting, better deals from Apex competitors. We will assume,
therefore, that Verify Availability is a value-added activity that should be modeled in the
REA diagram.
(2) Take Order; taking an order typically involves only a commitment on the part of the seller
to sell goods to the customer. It may even involve adjusting (decreasing) the inventory
available for sale to prevent it from being sold or promised to other customers. This
commitment, however, does not cause a real decrease in inventory and is not an economic
exchange. Furthermore, if the client subsequently cancels the order before it is shipped, no
economic exchange will occur. On the other hand, if taking an order causes the buyer to
expend resources to obtain or manufacture the product on behalf of the customer, then an
economic event will have occurred. For the purposes of this example, we will assume that no
economic consequences derive directly from the Take Order event and it is, therefore, a
support event.
(3) Ship Product; ship product is an economic event. This is the give half of an economic
exchange and reduces the inventory resource directly.
(4) Receive Cash. Similarly, the Receive Cash event is an economic event. This is the receive
half of the exchange that increases the cash resource.

CH 4; Relational Database; Page 13

 Accounting Information Systems

(5) Invalid Entity Types; the REA modeling focuses on value chain events. These are the
activities that use cash to obtain resources including equipment, materials, and labor and then
employ those resources to earn new revenues. Bookkeeping tasks such as recording a sale in
the journal and setting up an account receivable are not value chain activities. These are
invalid entity types and should not be included in an REA diagram. A fundamental precept of
REA is the rejection of accounting artifacts, including journals, ledgers, and double-entry
bookkeeping. Capturing transaction data in sufficient detail adequately serves traditional
accounting requirements. For example, an account receivable is the difference between a sale
to a customer and cash received in payment of the sale. Therefore, analyzing data pertaining
to the Ship Product (sales) and Receive Cash events can satisfy the information needs related
to the accounts receivable and billing functions described in the Apex case previously
presented. Once the valid event entities are identified and classified as either economic or
support events, they are placed on the REA diagram. REA convention is to arrange these
entities in their sequence of occurrence from top to bottom on the diagram.
4.3.1.2) Step-2; Identify the Resource Entities;
The next step in creating the REA diagram is to identify the resources that are impacted by the events
selected to be modeled. Each economic event in an REA model must be linked to at least one resource
entity whose economic value will be either reduced or increased by the event. Support events are also
related to resources but do not effect a change in the resource value. One could make the theoretical
argument that all employee actions, including support events such as Verify Availability or Take Order,
consume a resource called Employee Service.
In fact, this resource is increased as employees render their services to the organization and is
simultaneously decreased as those services are employed in the performance of a task. In situations in
which employee services are tracked to specific projects or products, this entity would provide
meaningful data and should be included in the REA model. Because we can presume that this is not the
case for Apex Supply, Employee Services will not be modeled. In the Apex revenue cycle, economic
events change only two resources. The Ship Product event reduces the inventory resource and the Receive
Cash event increases the cash resource. The Verify Availability and the Take Order support events are
also associated with inventory, but they do not change it.
4.3.1.3) Step-3; Identify the Agent Entities;
Thus, each economic event entity in an REA diagram is associated with at least two agent entities.
One of these is an internal agent and the other is an external agent. The external agent associated with
all four events in the Apex case is Customer. In addition, four internal agents are associated with the
four events;
(1) The customer services clerk, who participates in the Verify Availability event.
(2) The sales representative, who participates in the Take Order event.
(3) The shipping clerk, who participates in the Ship Product event.

CH 4; Relational Database; Page 14

 Accounting Information Systems

(4) The cash receipts clerk, who participates in the Receive Cash event.
Note that, each of these internal agents is in fact an instance of the Employee entity type. For
illustration purposes on the REA diagram, we identify each instance of Employee, (for example, Sales
Representative or Shipping Clerk) as a separate entity. The database that ultimately emerges from this
model, however, will employ a single Employee table, and each instance shown in the model will be a
row in that table.
4.3.1.4) Step-4; Determine Associations and Cardinalities Between Entities;
Association is the nature of the relationship between two entities, as the labeled line connecting them
represents. Cardinality, (the degree of association between the entities) describes the number of possible
occurrences in one entity that are associated with a single occurrence in a related entity. The entities are
things about which the organization wishes to capture data. Thus, the four basic possible forms of
cardinality are; zero or one (0,1), one and only one (1,1), zero or many (0,M), and one or many (1,M).
 Cardinality describes the nature of the relationship between two entities.
 It indicates how many instances of one entity can be linked to a specific
instance of another entity.
 Cardinalities are often expressed as a pair of numbers.
 The first number is the minimum, and the second number is the maximum.
 Minimum cardinality;
 Indicates whether a specific an instance of the entity next to the cardinality
must be linked to at least one instance of the entity on the opposite side of
that relationship.
 Can be either 0 or 1.
 Maximum cardinality;
 Indicates whether one instance of that entity can be linked to more than one
instance of the other entity participating in that relationship
 Can be either 1 or M
 Using the crow‟s feet notation;
 The symbol for zero is a circle; O
 The symbol for one is a single stroke; |
 The symbol for many is the crow‟s foot;

 Three Types of Relationships;

 Relationships depend on the maximum cardinality on each side of a
relationship.
– A one-to-one relationship (1:1) exists when the maximum cardinality for
each entity in the relationship is 1.
– A one-to-many (1:M) relationship exists when the maximum cardinality
on one side is 1 and the maximum on the other side is many.
– A many-to-many (M:M) relationship exists when the maximum on both
sides is many.

CH 4; Relational Database; Page 15

 Accounting Information Systems

 Agent – event cardinalities;

 The cardinality between agent and event is typically, (0:M) on the agent side.
 Resource – event cardinalities;
 The minimum cardinality is typically one,
 The maximum could be one or many,
 Event – resource cardinalities;
 The minimum is typically zero.
 Cardinalities between events;
 When events occur in a sequence, the minimum cardinality between the first
event and the second event is always zero.
 The minimum cardinality between the second event and the first event is
typically one.
 An exception could occur if the first event is not required for the second
event to occur.
 The maximums in the cardinalities between events can be either one or
many.
4.4) The Database System and Future of Accounting;
Database systems have the potential to alter external reporting significantly. Considerable time and
effort are currently invested in defining how companies should summarize and report accounting
information to external users. In the future, companies may make a copy of a company's financial
database available to external users in lieu of traditional financial statements. Users would be free to
analyze raw data however they see fit.
A significant advantage of database systems is the ability to create ad hoc queries to provide the
information needed for decision-making. No longer is financial information available only in predefined
formats and at specified times. Instead, powerful and easy-to-use relational database query languages can
find and prepare the information management needs when they want it.
Relational DBMSs can also accommodate multiple views of the same underlying phenomenon. For
example, tables storing data about assets can include columns not only for historical costs 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.
Finally, relational DBMSs are capable of integrating financial and operational data. For example,
customer satisfaction data could be stored in a database, giving managers a richer set of data for decision-
making.
Relational DBMSs have the potential to increase the use and value of accounting information.
Accountants must understand database systems so they can help design and use the AISs of the future.
Such participation is important for ensuring that adequate controls arc included in those systems to
safeguard data and ensure the reliability of the information produced.

CH 4; Relational Database; Page 16