ppt_16_rea in rb x xx

8/10/2019 Ppt_16_REA in RB x Xx

1/127

Chapter 18

Implementing an REA Model in aRelational Database


2/127

Learning Objectives

Integrate separate REA diagrams for individual businesscycles into a single, comprehensive organization-wideREA diagram.

Build a set of tables to implement an REA model of an AIS

in a relational database.

Explain how to write queries to retrieve information froman AIS relational database built according to the REAdata model.


3/127

Introduction

In the previous chapter, you learned how todevelop an REA diagram for an individualtransaction cycle.

This chapter demonstrates how to implement anREA diagram in a database.

We focus on relational databases because: They are commonly used to support transaction processing

systems.

They are familiar to most business students.

But REA modeling can also be used to designobject-oriented databases.


4/127

Learning Objective 1

Integrate separate REA diagrams forindividual business cycles into a single,comprehensive organization-wide REA

diagram.


5/127

IntegratingREA Diagrams Across Cycles

In Chapter 17, we looked at REA diagrams for therevenue and expenditure cycles (homework).


6/127

REA DiagramRevenue Cycle


7/127

REA DiagramExpenditure Cycle


8/127

IntegratingREA Diagrams Across Cycles

In Chapter 17, we looked at REA diagrams for therevenue and expenditure cycles (homework).

Before we integrate these diagrams with the payroll

cycle, lets take a look at the HR/payroll cycleactivities.


9/127

REA DiagramPayroll Cycle

Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash


10/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

The basic economic exchange:

Get employee time and skills

Give a paycheck


11/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

The time workedevent must be

linked to a particular employee andsupervisor for a (1,1) cardinality.


12/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

However, each agent can be linked to zero

or many time workedevents. The zero

minimum allows for inclusion of a new

employee or supervisor who has not yetbeen involved in a time recording.


13/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

A similar situation exists with the disburse

cashevent. (We regard each individual

paycheck as a separate cash

disbursement.)


14/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

The assumption is made that employees record time worked on a

daily basis.

Time workedis therefore linked to a maximum of one cash

disbursement, since employees arent paid for half a day on one

paycheck and the other half of the day on another check.


15/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

For each cash disbursement,

however, there are one-to-many

time workedevents.

In other words, a paycheck couldpay an employee for anywhere from

one days work to many.


16/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

The employee timeentity requires some explanation.

The resource being acquired by the time workedevent is the

use of an employees skills and knowledge for a particular period

of time.


17/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

Time is different from

inventory and other

assets in that it cannot

be stored.

There are only a few

relevant attributes about

employee time:

Hours worked

How the time was

used

Th ti k d d


18/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

The time workedand

disburse cashevents

capture all the

information about

employee time that it ispractical to collect and

monitor.

Consequently, the

employee timeresource

entity is almost neverimplemented in an

actual database, which

is why it is depicted with

dotted lines.


19/127


Employees

Employee

(Payroll Clerk)

Employee

(Supervisor)

Time Worked

Disburse Cash

Employee

Time

Cash

In the relationship between cash disbursementand the cash

resource:

This relationship is identical to the expenditure cycle.

Each check or EFT must be linked to at least one cash account

(and usually only one), leading to a (1:1) cardinality.

Each cash account can be linked to:

As few as zero cash disbursements (e.g., a new account).

And up to many.

Means a (0,N) cardinality.


20/127


Rules for Combining REA Diagrams


21/127

Rules For Combining REA Diagrams

Some entities appear in more than one transactioncycle diagram. Inventoryappears in the revenue and expenditure cycles.

Cash disbursementsappear in the expenditure and payroll

cycles. Employees(agent) and cash(resource) appear in all three

cycles.

These redundancies provide the basis for combiningthediagrams.


22/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

InventoryCustomerSuppliers

Employees

(Cashier)Receive Cash

Employees

(Cashier)Disburse Cash Cash

Employee

TimeTime WorkedEmployees (as

Payees)

In this integrated diagram, we see three

separate cycles.


23/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

The revenue cycle appears in yellow.


24/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

The expenditure cycle appears in blue.


25/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

The payroll cycle appears in pink.


26/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

The integrated diagram merges multiple

copies of resourceand evententities but

retains multiple copies of agent entities.


27/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

Lets look at how to combine redundant

resourceand evententities.


28/127


Merging Redundant Resource Entities

The REA diagrams for individual transaction cycles arebuilt around basic give-geteconomic exchanges.

Diagrams for individual cycles provide only partial

information. Example: The expenditure cycle tells you how the

company gets inventory, but doesnt tell you whatbecomes of the inventory.

To integrate the cycles, we redraw the REA diagram to

place common resources between the events thataffect them.

Reflects the economic duality that every resourcemust be connected to at least one event thatincreases the resource and at least one event that

decreases it.


29/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

Inventory has been shown in greenhere,

because it is increased by the expenditure

cycle and decreased by the revenue cycle.


30/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

Cashis increased by the revenue cycle and

decreased by both the expenditure and payroll

cycles.


31/127


Merging Redundant Event Entities

Some events (e.g., disburse cash)may appear in multiple transactioncycles.

Merging these multiple occurrencesimproves the legibility of the resultingdiagram.

Our integrated diagram shows the disbu rse cash


32/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

Our integrated diagram shows the disbu rse cash

event (shown in purple) is linked to both receive

inventory(in the expenditure cycle) and time worked

(from payroll cycle).


33/127


Difference between merging redundant events andmerging redundant resources:

Merging redundant resources does not affect anycardinalities.

Merging redundant events alters minimum cardinalitiesassociated with the other events that are related to themerged event.


34/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

Cardinalities between inventoryand each of the four

events to which it is related are the same as before.


35/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


Employee


Payees)

Cardinality between the cash disbursementevent

and other events with which it is linked are different.


36/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)

The cardinality between disburse cashand

receive inventoryis now (0,N) instead of (1,N)

as it was in the expenditure cycle.


37/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)


record hours workedis now (0,N) instead of

(1,N) as it was in the payroll cycle.


38/127


Reason lies in the semantics

A resource entity can and usually is linked to multipleevents.

Example: Inventoryis linked to areceive inventoryevent

in the expenditure cycle and asales(or deliverinventory) event in the sales cycle.

Because both links are possible, none of the cardinalitiesin the individual diagrams need to change when thediagrams are merged.


39/127


Reason lies in the semantics

An event that occurs in one cycle can be linkedto:

An event that is part of one transaction cycle; or

An event that is part of another transaction cycle;

But not both!

Example: A cash disbursementis to pay an employee(payroll) or buy inventory (expenditure), but not both.

The minimum cardinality associated with the other eventmustbe zero in the integrated diagram.


40/127


Remember:

A minimum of one means that each instance of that

entity has to be associated with at least one instance

of the other entity.

Each cash disbursement is linked to either a recordingof hours or a receipt of inventory, but not both.


41/127


Merging two transaction cycles on a commoneventmay also affect the minimum cardinalitiesbetween the merged event and the agentparticipating.

Same basic reasoning: A cash disbursementin the expenditure cycle is a payment

to a supplier, so every cash event is linked to at least onesupplier.

A cash disbursementin the payroll cycle is a payment to

an employee, so every cash event is linked to at least oneemployee.

A cash disbursementin the two cycles combined is linkedeither to a supplier or an employee, but not both.

Changes the minimum cardinality between event and

agent from one to zero.


42/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)


suppliersis now (0,N) instead of (1,N) as it

was in the expenditure cycle.


43/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)


employees (payees)is now (0,N) instead of

(1,N) as it was in the payroll cycle.


44/127


Validating the Accuracy of Integrated REA Diagrams

Chapter 17 presented three basic principles fordrawing REA diagrams for individual cycles.

The preceding discussion on combining diagramsadds two more rules.


45/127


An integrated REA diagram must satisfy thesefive rules:1. Every event must be linked to at least one resource.

2. Every event must be linked to at least two agents.

3. Every event that involves disposition of a resourcemust be linked to an event that involves acquiring aresource. (Reflects give-get economic duality).

4. Every resource must be linked to at least one eventthat increases the resource and one that decreases it.

5. If event A can be linked to more than one other

event, but cannot be linked simultaneously to all ofthose other events, then the REA diagram should showthat event A is linked to a minimum of zero of each ofthose other events.


46/127


The preceding five rules can be used todevelop an integrated REA diagram andcan also be used as check figures tovalidate the accuracy of a completed

diagram.

Our integrated diagram is not yet completebecause the fourth rule is not satisfied for the

employee timeresource. Rule 4: Every resource must be linked to at least

one event that increases it and one event thatdecreases it.


47/127


Build a set of tables to implement an REA

model of an AIS in a relational database.

I l ti REA Di i


48/127

Implementing an REA Diagram in a

Relational Database

Once an REA diagram has been developed, it canbe used to design a well-structured relationaldatabase.

Creating a set of tables from an REA diagramautomatically results in a well-structured relationaldatabase that is not subject to the update, insert,and delete anomalies.



49/127


Relational Database

The three steps to implementing an REAdiagram in a relational database are: Create a table for:

Each distinctentity in the diagram.

Each many-to-many relationship.

Assign attributes to appropriate tables.

Use foreign keys to implement one-to-one andone-to-many relationships.

As discussed previously, REA diagrams willdiffer across organizations because ofdifferences in business policies.



50/127


Relational Database








51/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)

Our integrated diagram has

seven event entities.


52/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)

There are three distinct agent entities.

The first is the customer.


53/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomers

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)

The second agent entity is

the suppliers.


54/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)

The third agent entity is the employee. We label

the types of employees to make the diagram more

understandable, but they all go in one table.



55/127


Relational Database

Total entities to be represented in separate

tables:

Events 7

Resources 2

Agents 3

12



56/127


Relational Database








57/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive

Inventory

CustomerSuppliers

Employees


Employees


Employee


Payees)

Lets count the many-to-many relationships.

4

5

1

2

3



58/127


Relational Database

Total number of tables in database:

Events 7

Resources 2

Agents 3

12

Plus: Many-to-Many Relationship 5

17



59/127


Relational Database

Table names for these 17 entities correspondto the names of the entities in the REAdiagram. The tables for M:N relationships are hyphenated

concatenations of the entities involved in therelationship.

Makes it easier:

To verify that all necessary tables have been

created. To use the REA diagram as a guide when

querying the database.



60/127


Relational Database

Table names for our integrated diagram:

Order Inventory

Receive Inventory

Disburse Cash

Take Customer Order

Sales

Receive Cash

Time Worked Inventory

Cash

Employees

Customers

Suppliers

Order Inventory-Inventory

Receive Inventory-Inventory

Take Customer Order-Inventory

Sales-Inventory Sales-Receive Cash



61/127


Relational Database









62/127


Relational Database

Step 2: Assign attributes to each table The next step is to determine which attributes

should be included in each table.

Primary keys attribute

Non-key (other) attributes The designer needs to interview users and

management to identify which facts need to beincluded in the database.

Should use the REA diagram to determine inwhich tables those facts should be placed.



63/127


Relational Database

Identify primary keys Every table in a relational database must have a

primary key. The primary key is an attribute or combination of

attributes that uniquely identifies each row in a table.

It is typically a numeric identifier.

The primary key is usually a single attribute.

However for M:N relationship tables, it consists oftwo attributes that represent the primary key ofeach linked entity.

Example: The primary key for a sales-inventorytable might be Invoice No-Item No.

These multiple-attribute primary keys arecalled concatenated keys.



64/127


Relational Database

Keys for the entity tables weve identified might bespecified as follows: ORDER INVENTORYPurchase Order No.

RECEIVE INVENTORYReceiving Report No.

DISBURSE CASHCheck No.

TAKE CUSTOMER ORDERSales Order No. SALESInvoice No.

RECEIVE CASHCash Receipt No.

TIME WORKEDTimecard No.

INVENTORYItem No.

CASHAccount No. EMPLOYEESEmployee No.

CUSTOMERSCustomer No.

SUPPLIERSSupplier No.

The M:N relationshiptables would have keys

that are combinations

of the keys for the two

related tables.



65/127


Relational Database

Keys for the entity tables weve identified might bespecified as follows: ORDER INVENTORYINVENTORY: Purchase Order No.,

Product No.

RECEIVE INVENTORYINVENTORY: Receiving Report No.,

Product No. TAKE CUSTOMER ORDERINVENTORY: Sales Order No.,

Product No.

SALESINVENTORY: Invoice No., Product No.

SALESRECEIVE CASH: Invoice No., Remittance No.

Example: The primarykey for the sales-

receivecashtable

would be invoice no.-

cash receipt no.



66/127


Relational Database

Assign other attributes to appropriate tables

Attributes other than the primary key are alsoincluded in tables:

To provide for accurate transaction processing and the

production of financial statements; or

To facilitate effective management of the entitysresources, events, and agents.

Any attribute in a table must be a fact about the

object represented by the primary key. Example: Information about the customer, such

as his address or phone number, should beincluded in the customer table, not the sales

table.



67/127


Relational Database

Assign other attributes to appropriate tables Some non-key attributes even need to be stored in

M:N tables.

Example: The inventory-sales table may include aquantity sold attribute. The quantity sold cant be placed in the inventorytable,

because there can be many sales of any particularinventory item, and each sale produces a differentquantity ordered.

The quantity sold cant be placed in thesalestable,because an individual sale can include several

inventory items. The quantity sold is placed in thesales-inventorytable so

that you can determine how much of EACH inventoryitem was ordered with EACH sale.



68/127


Relational Database


Price and cost data

Information about prices and costs are stored

as attributes in several different tables. Theinventorytable stores the suggested list

price, which is generally constant for the fiscalperiod.

Thesales-inventorytable stores the actualsales price, which can vary during the year.



69/127


Relational Database


Price and cost data

Just like sales prices, the standard and actual purchasecosts of each item are stored in different tables.

General rule:

Time-independent data (such as standard costs or listprices) should be stored as an attribute of a resourceoragent.

Data that vary across time (such as actual costs andprices) should be stored with event entities orin M:Nrelationshipsthat involve at least one event.



70/127


Relational Database

Assign other attributes to appropriate tables Cumulative Data

Attributes like quantity on hand or accountbalance are cumulative data.

Quantity on hand is calculated as: Sum of quantities purchased from the table

linking inventoryto thereceive inventoryevent.

LESS: Sum of quantity sold from thesales-

inventorytable. Customer balance:

Sum of all sales to the customer.

LESS: Sum of all cash receipts from customer.



71/127

p e e g a ag a a

Relational Database

Assign other attributes to appropriate tables Cumulative Data

The preceding types of items do not have to be

stored and can be calculated.

However, explicitly storing them may improve

response time to queries.

Should be done if the DBMS has the capability toautomatically update these summary values as eachnew event occurs.

Otherwise they will be incorrect.



72/127

p g g

Relational Database









73/127

p g g

Relational Database

Step 3: Use foreign keys to implement 1:1and 1:N relationships. Many-to-many relationships have been

implemented by the creation of separate tables.

One-to-one and one-to-many relationships stillneed to be implemented in the database.

But it is usually more efficient to implement themby the creation of foreign keys.

A foreign key is an attribute of one entity that is

the primary key of another entity. Customer numbermight appear in the customer

table as a primary key and in thesalestable as aforeign key.



74/127

p g g

Relational Database

Using foreign keys to implement one-to-onerelationships Can be implemented by including the primary

key of one entity as a foreign key in the other.

Minimum cardinalities may suggest which choiceis more efficient. Usually, best to insert the primary key of the entity that

can occur a minimum of one time as a foreign key in theentity that can occur a minimum of zero times.

When there are two sequential events, the primary key of

the event that occurs first is usually the foreign key in theevent that occurs second.

Provides better control, as the employee who updatesthe table for the second event does not have to accessthe table for the event that occurred first.


75/127

Employees

(Supervisor)

Order

InventoryEmployees

Suppliers

Inventory

Take Cust.

OrderCustomer

Employees

(Salesperson)

SalesReceive


Employees


Employees


EmployeeTime

Time WorkedEmployees (as

Payees)

This relationship is a 1:1 relationship, but the

minimum on both sides is zero.

Because the entities represent sequential events,

we will follow the practice of placing the primary

key of the event that occurs first (take customer

order) as a foreign key in the event that occurs

second (sales).

Take Customer

Order

Sales



76/127

Take Customer Order Order No. Call No. Date, Time, Total Amount

Sales Invoice No. Order No. Date, Time, Total Amount,

Invoice Sent (Y/N)

p g g

Relational Database

Table Name

Primary

Key

Foreign

Key Other Attributes



77/127

Using foreign keys to implement one-to-manyrelationships

Place the primary key of the entity that can occuronly once as a foreign key in the entity that canoccur many times.

Example: The primary key forsalesperson(whichcan occur only once per sale) is a foreign key inthesalestable (which can occur many times for

a particular salesperson).

If you tried to do the opposite, you would nothave flat tables.

p g g

Relational Database



78/127

p g g

Relational Database

It would be useful to step through a completeprocess of converting an REA diagram into adatabase model.

The integrated diagram is too extensive to providea good, short example.

Therefore, lets use a simple, individual transactioncycle for purposes of this example only.

Example


79/127

Example

Below is a sample REA diagram for a very simplerevenue cycle.

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

Example


80/127

Example

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

Our first step is to create a table for each event,resource, agent, and many-to-many relationship.

Example


81/127

Example

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

There are two events.

Example


82/127

Example

Table Name Primary Key Foreign Key Other Attributes

Sale

Receive Cash

Example


83/127

Example

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

There are two resources.

Example


84/127

Example


Sale

Receive Cash

InventoryCash

Example


85/127

Example

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

There are two types of agents: customers andemployees.

Example


86/127

Example


Sale

Receive Cash

InventoryCash

Customer

Employee

Example


87/127

Example

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

There is one many-to-many relationship.

Example


88/127

Example


Sale

Receive Cash

InventoryCash

Customer

Employee

Sales-Inventory

Example


89/127

Example

The next step is to assign attributesto each table.

These attributes include the assignment of primarykeys.


90/127

Example


91/127

Example

The other attributes include facts the companywishes to collect that describe each entity.

Example


92/127

Example

Table Name Primary Key Foreign Key Other AttributesSale Sale No. Date of Sale, Time of Sale,

Total Amount of Sale

Receive Cash Cash Rect. No. Receipt Date, Receipt

Time, Total Amount of

Recei tInventory Item No. Description, List Price

Cash Account No. Bank, Type of Account

Customer Customer No. Customer Name, Customer

Address, Customer Phone

Employee Employee No. Employee Name, Employee

Address, Employee Phone,Job Title

Sales-Inventory Sale No.-Item

No.

Quantity Sold, Actual Price

Example


93/127

Example

The final step involves using foreign keys toimplement the 1:1 and 1:N relationships.

The relationship between customer and


94/127

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

sales is a 1:N relationship. We make the

primary key for the entity that occurs only

once (customer) serve as a foreign key inthe entity that can occur many times (sale).

Example


95/127

Example


Sale Sale No. Customer No. Date of Sale, Time of Sale,


Receive Cash Cash Rect. No. Receipt Date, Receipt Time,

Total Amount of Receipt

Inventory Item No. Description, List PriceCash Account No. Bank, Type of Account




Address, Employee Phone,

Job Title

Sales-Inventory Sale No.-ItemNo.


Example


96/127

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

Likewise, the primary key for employeeshould be aforeign key in thesalestable.

Example

Example


97/127

Table Name Primary Key Foreign Key Other AttributesSale Sale No. Customer No., Employee No. Date of Sale, Time of Sale,


Receive Cash Cash Rect. No. Receipt Date, Receipt Time,


Inventory Item No. Description, List Price

Cash Account No. Bank, Type of AccountCustomer Customer No. Customer Name, Customer




Job Title


No.


Example

Example


98/127

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

The primary key for employeeshould also be aforeign key in thereceive cashtable.

Example

Example


99/127



Receive Cash Cash Rect. No. Employee No. Receipt Date, Receipt Time,







Job Title


No.


Example

Example


100/127

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

The primary key for customershould also be aforeign key in thereceive cashtable.

Example

Example


101/127



Receive Cash Cash Rect. No. Employee No., Customer No. Receipt Date, Receipt Time,







Job Title


No.


p

The relationship betweensalesandreceive cashis1:1 Two guidelines will produce the same result


102/127

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

1:1. Two guidelines will produce the same result. Put the primary key of the event with the minimum of one

(sales) as a foreign key in the event with the minimum of

zero (receive cash); or Put the primary key of the event that occurs first (sales) as a

foreign key in the event that occurs second (receive cash).

Example


103/127


Sale Sale No. Customer No., Employee No. Date of Sale, Time of Sale,


Receive Cash Cash Rect. No. Employee No., Customer No.,

Sale No.

Receipt Date, Receipt Time,








Job Title


No.


p

Example


104/127

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

The relationship betweensalesand inventoryis amany-to-many relationship and was alreadyimplemented by the creation of a separate table.

p

Example


105/127

Sale

Receive

Cash

Inventory

Cash

Customer

Employee

Customer

In the relationship between cashandreceive cash, theprimary key for the event that occurs once (cash) should be aforeign key in the event that occurs many times (receivecash).

p

Example


106/127


Sale Sale No. Customer No., Employee No. Date of Sale, Time of Sale,


Receive Cash Cash Rect. No. Employee No., Customer No.,

Sale No., Account No.

Receipt Date, Receipt Time,








Job Title


No.


p


Relational Database


107/127

Relational Database

Completeness check The list of attributes that users and management

want included in the database provide a meansto check and validate the implementation

process. Each of those attributes should appear in at least

one table as a primary key or an other attribute.

Checking this list may reveal that a particular

attribute has not been assigned or may evenindicate the need to modify the REA diagramitself.


Relational Database


108/127

Relational Database

The need to modify the REA diagram as a result ofthis completeness check is not unusual.

In fact, it is often helpful to create tables and assignattributes before completion of the REA diagram

helps clarify what each entity represents.

When all attributes have been assigned, the basicrequirements for a well-structured relationaldatabase can be used as a final accuracy check:

Every table has a primary key. Other attributes in the table are either a fact that describes

the entity or a foreign key used to link tables.

Every attribute in every table is single-valued.


109/127


Explain how to write queries to retrieve

information from an AIS relational

database built according to the REA data

model.

Using REA Diagrams to Retrieve Information

from a Database


110/127

from a Database

We have shown how to use the REA data model to guidedesign of an AIS that will efficiently store information about anorganizations business activities.

Lets now discuss how to use our completed diagrams andtables to retrieve information for performance evaluation.

It may appear that a number of traditional AIS elements aremissing, e.g.:

Journals

Ledgers

Accounts receivable balances

The information is simply present in a different format.


from a Database


111/127

from a Database

Creating Journals and Ledgers Although journals and ledgers do not appear explicitly in

an REA diagram, they can be created through appropriatequeries.


from a Database


112/127

from a Database

Deriving journals from queries In a traditional AIS, journals provide a chronological listing

of transactions.

In a relational database designed via an REA model, evententities store information about transactions.

The information found in a journal is contained in thetables used to record data about events.

Each row in the sales journal, for example, containsinformation about a particular sales transaction.


from a Database


113/127

from a Database

Consequently: A sales journal can be produced by writing a query that

displays the appropriate entries in thesalesandsales-inventorytables for a given period.

But doing so would not necessarily create the traditionaljournal.

The simplest query would display every entry in the eventtable (both credit and cash sales).


from a Database


114/127

from a Database

To create a traditional sales journal from thesalesandsales-inventorytables, you would: Create a query that prints only sales transactions

for which there is not a matching transaction inthereceive cashandsales-receive cashtables

for: The same customer

The same date

In another words, if a cash receipt was notobtained from that customer on the same date in

the exact amount of the sale, the assumption ismade that the transaction was a credit sale.

Similar processes can be followed to writequeries to produce other special journals.


from a Database


115/127

from a Database

Ledgers Ledgers are master files that contain cumulative

information about specific accounts.

In a relational database designed with the REA

model, resource and agent entities containpermanent information carried from one year tothe next.

Much information about assets that is traditionallyrecorded in ledgers would be stored in the

resource tables.


from a Database


116/127

from a Database

Example: Each row in the equipmenttable would contain information

about a specific piece or class of machinery, includingcost, useful life, depreciation method, and estimatedsalvage value.

Each row in the cashtable contains information about aspecific account for cash or cash equivalents.

Each row in the inventorytable contains information abouta specific inventory item.


from a Database


117/127

from a Database

Each resource account is affected byincrement and decrement events:

Equipment is bought and used.

Cash is received and paid out.

Inventory is bought and sold.

Queries to display the current cumulative

balances for these accounts must reference:

The appropriate table for that resource entity; and

The event tables that affect it.


from a Database


118/127

from a Database

Example: A query to display the current balance ina specific bank account would reference: The cashresource table to identify the account number

and beginning balance for the period.

The cash receiptstable to identify inflows to the account.

The cash disbursementstables to identify outflows duringthe period.


from a Database


119/127

from a Database

Many financial statement accounts are representedas resources in the REA model.

Claims are an important exception.

There is not an entity for accounts receivable (claims we

have against our customers) or accounts payable (claimsour suppliers have against us).


from a Database


120/127

o a a abase

Accounts receivable represents salestransactions for which customer paymentshave not yet been paid.

Can be calculated as: Total sales (from thesalestable) Less: Total cash receipts (from the cash receipts

table)

If there is a foreign key for cash receiptsin

thesalestable, a shortcut would be to addup all sales in thesalestable where theforeign key for cash receiptsis null (i.e., thecash has not been received).


from a Database


121/127

Accounts payable represents purchase transactionsfor which cash disbursements have not yet beenmade.

Can be calculated as:

Total receipts of inventory from thereceive inventorytable

Less: Total cash disbursements from the cash disbursementstable


from a Database


122/127

To derive account receivable balances foreach customer, the query logic must beexpanded to reference the customertableand include a group by command toperform the calculation separately for each

customer. Result would be a table with a row for each

customer and a column showing the customersoutstanding balance.

Another query could sum the balances in thistable to determine total accounts receivable.

A similar procedure can be followed todetermine individual supplier balances inaccounts payable.


from a Database


123/127

Generating Financial Statements Weve established that queries can be written to

generate journals and ledgers, which produceinformation to be included in financial

statements. To produce the desired outputs, it is necessary to

have both:

Knowledge about the structure of financial statements

and the meanings of individual accounts; and An understanding of the REA data model, especially the

meaning of various cardinalities.


from a Database


124/127

Creating Managerial Reports A major advantage of the REA model is its integration of

non-financial and financial data to make both types ofdata easily accessible to management.

For example, if the sales table includes the time of sale, this

information could be used to plan staffing needs. Other non-financial data from internal and external sources

can be included in the system.


from a Database


125/127

The general ledger in traditionally designed AISscontains data only about the financial aspects oftransactions, and non-financial data has to bestored in a separate database or informationsystem. The existence of separate systems makes it more difficult for

management to easily and quickly access the neededinformation.

Also creates opportunities for more data entry errors andinconsistencies, reducing the utility of the reports.

REA model advantage is the ability to easilyintegrate information that traditionally appears infinancial statements with other, nonfinancialinformation.

SUMMARY


126/127

In this chapter, youve learned: How REA diagrams for individual transaction cycles are integrated

into a single comprehensive organization-wide REA diagram.

How tables are constructed from the REA model of an AIS in arelational database.

How queries can be written to retrieve information from an AISrelational database built according to the REA data model.


127/127

End of Chapter 18

ppt_16_rea in rb x xx

Documents