17

Chapter – 4
Relational Database
4.1 Database System 4.2Detabase Design Process 4.3 The REA Data model 4.4 Database System and Future of
Accounting

4.1 DATABASE SYSTEMS

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.
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 (e.g., $, #, 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
(e.g., employee salary) or the name of an entity (e.g., person, place, or event).
17

3. Record:
A record is composed of a group of related fields. As another way of saying it, a record 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. Database
management systems will be discussed in greater detail in further topic .

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
17

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.

An Introduction to 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.

DBMS Fundamentals

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  Customer information

lists  Inventory information
 Accounting and bookkeeping information  Personal records
 The data obtained from scientific research  Library information

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
17

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.

The Advantages of a DBMS

Improved availability: One of the principle advantages of a DBMS is that the same information can be
made available to different users.
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.
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.
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.
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.
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
There are basically two major downsides to using DBMSs. One of these is cost, and the other the threat to
data security.
17

Cost: Implementing a DBMS system can be expensive and time-consuming, especially in large
organizations. Training requirements alone can be quite costly.
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.

Data base view Models:

There are two view models in Database systems 1) Logical view of data 2) Physical view of data

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.
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 & business transaction
inconsistency
17

 Facilitates data re-use and sharing

 Decreases development and maintenance time and cost

 Confirms a logical process model and helps impact analysis.

2).Physical view:
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; it may include specific storage allocation details for a given database system.
Data dictionary:
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. 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.

DBMS Languages
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);

17

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:
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): 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.
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)
WHERE (describes the condition for the query)

An 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 $100 or more, the following query might be used:

SELECT Name, Address

FROM Donor List
WHERE Donation Amt > 100
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
17

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.

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

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.

4.2 DATABASE DESIGN

Database design:

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 data
structures, but also the forms and queries used as part of the overall database application within the
database management system (DBMS).

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

 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

The following simple design process applying by the organizations like.,

4.3 RESOURCE, EVENTS AND AGENTS (REA) DATA MODEL

 THE REA 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
17

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

1) RESOURCES. 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. REA modeling embraces two classes of events: economic events and support events.
Economic events are phenomena that effect changes (increases or decreases) in resources as
represented by the stock flow relation in Figure 10-1. 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.
17

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…..
(1) Determining inventory availability for a customer prior to making a sale,
(2) Verifying supporting information (performing a three-way-match) prior to disbursing cash to a
vendor, and
(3) Checking customer credit before processing a sale.
3) AGENTS. 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. 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.
17

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. We demonstrate how this is done
later in the chapter.
Advantages of REA model
 helps managers identify non-value added activities that can be eliminated
• 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
• increased competitive advantage by providing more relevant, timely, and accurate
information to managers

 Developing an REA model

17

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:
1. Identify the event entities.
2. Identify the resource entities.
3. Identify the agent entities.
4. Determine associations and cardinalities 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 Following are its key features:
 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. 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
17

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.
5) INVALID ENTITY TYPES. 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.
 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
17

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.
 STEP 3. IDENTIFY THE AGENT ENTITIES
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.
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.
 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. Four basic
forms of cardinality are possible: zero or one (0,1), one and only one (1,1), zero or many (0,M), and
one or many (1,M).
 A 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 a 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
17

– 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.
 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. Data Base System and Future of Accounting

• Database systems may profoundly affect the fundamental nature of accounting:
 May lead to abandonment of double-entry accounting, because the redundancy of
the double entry is not necessary in computer data processing.
17

 May also alter the nature of external reporting.

• EXAMPLE: External users could have access to the company’s database and
manipulate the data to meet their own reporting needs.

• The use of accounting information in decision making will be enhanced by:

 Powerful querying capabilities that accompany database packages.
 The ability to accommodate multiple views of the same underlying phenomenon.
 The ability to integrate financial and operational data

• Accountants must become knowledgeable about databases so they can participate in developing the
AIS of the future.
• They must help ensure that adequate controls are included to safeguard the data and assure its
reliability