rais11_ch15_335

1

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart 1 of 138

C HAPTER 15

Database Design Using theREA Data Model


INTRODUCTION

• Questions to be addressed in this chapterinclude:– What steps are followed to design and

implement a database system?– How is the REA data model used to design an

AIS database?– How is an entity-relationship REA diagram of

an AIS database drawn?– How are REA diagrams read, and what do

they reveal about the business activities andpolicies of the organization being modeled?


INTRODUCTION

• Steps in database design include thefollowing:– Planning– Requirements analysis– Design– Coding– Implementation– Operation and maintenance

• Eventually, changes in business strategyand practices or new IT developmentslead to the need for a new system and theprocess starts over.


INTRODUCTION

• Accountants can and should participate in allstages of the database design process, althoughparticipation varies between stages.– Planning stage– Requirements analysis and design stages– Coding stage– Implementation stage– Operation and maintenance stage

• Accountants use the database system toprocess transactions.

• Sometimes help manage it.


INTRODUCTION

• Accountants may provide the greatest value bytaking responsibility for data modeling—theprocess of defining a database to faithfullyrepresent all aspects of the organization,including interactions with the externalenvironment.– Occurs during both requirements analysis and design

stage.– Two important tools to facilitate data modeling:

• Entity-relationship diagramming• REA data model


ENTITY-RELATIONSHIP DIAGRAMS

• An entity-relationship (E-R)diagram is a graphical technique forportraying a database schema.– Shows the various entities being

modeled and the important relationshipsamong them.

2


ENTITY-RELATIONSHIP DIAGRAMS

• In this book, we will create E-R diagrams with a largenumber of entities and relationships.

• To reduce clutter and improve readability, we omitdiamonds and list attributes in a separate table.

Enrollment Students

Student ID No., Student Name, Student AddressStudentEnrollment No., Enrollment Date, Enrollment TimeEnrollmentAttributesEntity Name


THE REA DATA MODEL

• The REA data model was developed specificallyfor use in designing accounting informationsystems.– Focuses on business semantics underlying an

organization’s value chain activities.– Provides guidance for:

• Identifying the entities to be included in a database.• Structuring the relationships among the entities.

• REA data models are usually depicted in theform of E-R diagrams.

• Therefore, we refer to E-R diagrams developedwith the REA model as REA diagrams.


THE REA DATA MODEL

• Three basic types of entities– The REA data model is so named because it

classifies entities into three distinct categories:• Resources that the organization acquires and

uses.• Events in which the organization engages• Agents participating in these events.

• Includes people and organizations whoparticipate in events and about whominformation is desired for planning,control, and evaluation purposes.


THE REA DATA MODEL

• Can you identify the resources in this diagram?

Employee

Customer

Employee

Sales

ReceiveCash

Inventory

CashAccounts


THE REA DATA MODEL

• Structuring relationships: The basicREA template– The REA data model prescribes a basic

pattern for how the three types of entities(resources, events, and agents) should relateto one another.

• Rule 1: Each event is linked to at least one resourcethat it affects.

• Rule 2: Each event is linked to at least one other event.• Rule 3: Each event is linked to at least two agents.


THE REA DATA MODEL

Agent A

Agent B

Agent C

Event A

Event B

Resource A

Resource B

3


• The revenue cycle involves interactionswith your customers.

• You sell goods or services and get cash.

THE REA DATA MODEL

GiveInventory

GetCash


• The expenditure cycle involvesinteractions with your suppliers.

• You buy goods or services and pay cash.

THE REA DATA MODEL

GiveCash

GetInventory


• In the production cycle, raw materials, labor, andmachinery and equipment time are transformedinto finished goods.

THE REA DATA MODEL

Give (Use)Raw

Materials

Give (Use)Employee

Time

Give (Use)Machinery &Equipment

Get FinishedGoods

Inventory


• The human resources cycle involvesinteractions with your employees.

• Employees are hired, trained, paid,evaluated, promoted, and terminated.

THE REA DATA MODEL

GiveCash

GetEmployee

Time


• The financing cycle involves interactions withinvestors and creditors.

• You raise capital (through stock or debt), repaythe capital, and pay a return on it (interest ordividends).

THE REA DATA MODEL

GiveCash

GetCash


THE REA DATA MODEL

• Not every relationship between two eventsrepresents a give-to-get economic duality.– Commitment events are linked to other events

to reflect sequential cause-effectrelationships.

– Example:• Take customer order (commitment), which leads

to:• Deliver inventory (give event) and receive cash

(get event).

4


DEVELOPING AN REA DIAGRAM

• Developing an REA diagram for a specifictransaction cycle consists of three steps:– STEP ONE: Identify the events about which

management wants to collect information.– STEP TWO: Identify the resources affected by

the events and the agents who participated.– STEP THREE: Determine the cardinalities

between the relationships.• Let’s walk through an example.


STEP ONE: IDENTIFY RELEVANTEVENTS

• Example: Typical activities in the revenuecycle include:– Take customer order– Fill customer order– Bill customer– Collect payment

• The give-to-get, then, is:– Fill customer order

(often referred to as“sale”);

– Collect cash (oftenreferred to as “cashreceipt”).



• Example: Typical activities in the revenuecycle include:– Take customer order– Fill customer order– Bill customer– Collect payment

• Printing and mailinginvoices does not directlyaffect an economicresource.

• It does not represent acommitment on the part ofthe company to a futureexchange.

• It is an informationretrieval event and shouldnot alter the contents ofthe database.

• Does not need to beincluded in the model.



• Although accounts receivable is an assetin financial reporting, it is not representedas a resource in an REA model.– It represents the difference between total

sales to a customer and total cash collectionsfrom the customer.

– The information to calculate an accountsreceivable balance is already there becausethe sales and cash receipt information iscaptured.



• Events that pertain to “entering” data or“re-packaging” data in some way do notappear on the REA model.– They are not primarily value-chain activities.– What is modeled is the business event and

the facts management wants to collect aboutthe event, not the data entry process.



Sale

ReceiveCash

Take Order

5


STEP TWO: IDENTIFY RESOURCES ANDAGENTS

Sale

ReceiveCash

Take Order

• What is thegive event?



Sale

ReceiveCash

Take Order

• What resourceis reduced bythe give event?

Inventory



Sale

ReceiveCash

Take Order

• What is the getevent?Inventory



Sale

ReceiveCash

Take Order

• What resourceis increased bythe get event?

Inventory

Cash



Sale

ReceiveCash

Take Order

• What resourceis affected bythecommitmentevent?

Inventory

Cash



• The agents who participate in each eventshould also be identified.– There will always be at least one internal

agent (employee).– In most cases, there will also be an external

agent (e.g., customer or supplier) whoparticipates.

6



Sale

ReceiveCash

Take Order

• What agentsare involved inthe sale?

Inventory

Cash

Customer

Employee



Sale

ReceiveCash

Take Order

• What agentsare involved inthe receipt ofcash?

Inventory

Cash

Customer

Employee

Customer



Sale

ReceiveCash

Take Order

• What agentsare involved intaking theorder?

Inventory

Cash

Customer

Employee

Customer

Employee


STEP THREE: DETERMINECARDINALITIES OF RELATIONSHIPS

• The final step in an REA diagram for atransaction cycle is to add information about therelationship cardinalities.

• A cardinality describes the nature of therelationship between two entities.– It indicates how many instances of one entity can be

linked to a specific instance of another entity.– For example, the cardinality between the event Sales

and the agent Customer answers the question:• For each sale a company makes, how many customers are

associated with that sale?



Sale Customer

• There is typically a minimum andmaximum cardinality for each entityparticipating in a relationship.



• Three types of relationships– Three types of relationships are possible between

entities.– 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 one.• A one-to-many (1:N) relationship exists when the maximum

cardinality on one side is one and the maximum on the otherside is many.

• A many-to-many (M:N) relationship exists when themaximum on both sides is many.

7



Inventory Sale

• The maximum number of inventory items that can besold in one sale is many.

• The maximum number of sales that can occur for aparticular inventory item is many.

• This is a many-to-many (M:N) relationship.



• For each agent the cardinality between agentand event is typically (0:N).– Example: For a particular salesperson:

• There is typically a minimum of zero sales (allows forinclusion of a new salesperson who has not yet made anysales).

• A salesperson can have a maximum of many sales.

– Or: For a particular customer:• There is typically a minimum of zero sales (to allow for the

inclusion of prospective customers who haven’t boughtanything yet) and a maximum of many sales.



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee



• Let’s now look at the relationship betweenevents and resources.– In the cardinality between event and resource,

the minimum cardinality is typically one,because an event can’t occur without affectingat least one resource.



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee



• The maximum could be one or zero.– In this particular story, each sale can involve

many items of inventory, so the maximum ismany.

– However, every receipt of cash is deposited toone and only one cash account, so themaximum there is one.

8



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee



• In the cardinality between event andresource, the minimum is typically zero.– A company can have an inventory item for

which there has never been a sale.– When the company’s cash account is new,

there has never been a cash receiptdeposited in it.



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee



• In the cardinality between event andresource, the maximum is typically many.– Most inventory items can be sold many times.

(An exception might occur if each inventoryitem is one unique item, such as a piece ofreal estate.)

– The company’s cash account can have manycash receipts.



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee



• Finally, let’s look at the relationships between events.• When events occur in a sequence, the minimum

cardinality between the first event and the second eventis always zero, because there is a span of time (althoughpossibly quite short) when the first event has occurredbut there are zero occurrences of the second event.

• Examples:– When an order is first taken, there have been no deliveries of

goods (sale event) to the customer.– When goods are delivered to the customer, there is a span of

time, however brief, in which there is no cash receipt from thecustomer.

9



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee



• The minimum cardinality between thesecond event and the first event istypically one, because the second eventcan’t occur without the first event havingoccurred.



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee



• An exception could occur if the first eventis not required for the second event tooccur.

• Example: If a sale can be made withoutfirst taking an order, then the minimumcardinality between sale and take ordercould be zero.



• The maximums in the cardinalities betweenevents can be either one or many, and thesemaximums vary based on business practices.

• We saw this when we looked at the four differentpossibilities for the relationships between salesand cash receipts previously.

• On the following slides, see if you can explainthe maximums between the three events.



Sale

ReceiveCash

Take Order

Inventory

Cash

Customer

Employee

Customer

Employee

rais11_ch15_335

Documents