Chapter 10 The The REA REA Approa proac ch to Busin usine ess Process Modeling Traditional Traditional Approaches: User-View Orientation Orientation
When data-modeling data-modeling and IS design design is too oriented oriented toward the user’s views, problems arise:
multiple information systems
duplication of data
restricted user-view leads to poor decisionmaking inability to support change
Resources, Events, and Agents Model
is an approach to database design meant to REA is overcome problems with traditional approaches:
formalized formalized data modeling and design of IS
use of centralized database
use of relational database structure
collects detailed financial and non-financial data supports accounting and non-accounting analysis
supports multiple user views
supports enterprise-wide planning
REA models consists of three entity types and the associations linking them.
Resources
Events
Agents
Resources in the REA Model
the ‘assets’ of the company c ompany Resources – Resources – the
things of economic value objects of economic exchanges able to generate revenue objects that are scarce and under the control c ontrol of the organization organization can be tangible or intangible
Does not include some traditional accounting assets:
artifacts that can be generated from other primary primary data for example, accounts receivables
Events in the REA Model
Events are phenomena that effect changes in resources.
a source of detailed data in the REA approach to databases
Events fall into two groups:
Economic – increases or decreases resources – increases
control, planning, and other – control, Support – management management activities; but do not directly affect resources
Agents in the the REA Model Model
Agents can be individuals individuals or departments. departments. Participate in events Affect resources
Have discretionary power to use or dispose of resources
Can be inside or outside the organization
Clerks
Production workers
Customers
Suppliers, vendors
Departments, teams
Basic REA Model
Another key feature of the the REA model is economic duality.
Events occur in pairs Represent the give event and receive event of an economic exchange
REA Model showing Duality of a Give and Receive Exchange
ER Diagrams (ERD’s) versus REA Diagrams (READ’s)
Classes of entities
three classes (resources, events, READ’s – three and agents)
Arrangement Arrangement of entities
one class ERD’s – one
determined by cardinality and ERD’s – determined readability organized into constellations c onstellations by READ’s – organized class
Sequencing of events
static ERD’s – static chronological sequence of READ’s – chronological business processes
Naming Naming conventions
all nouns ERD’s – all READ’s – nouns – nouns (R’s and A’s) and verbs (E’s)
View Modeling: Modeling: Creating an an Individual REA Diagram Diagram
View modeling is a multistep process for creating an individual REA model.
The result is a single single view of the entire database.
The four steps involved involved are:
Identify the event entities to be modeled. Identify the resource entities changed by events. Identify the agent entities participating in events. Determine associations and cardinalities between entities.
Step 1: Identify the Event Entities
Identify the events that are to be included in the model.
Include at least two economic events (duality) May include support events Arrange events in chronological chronological sequence
Focus on value chain events.
Do not include invalid events such as:
bookkeeping tasks
accounting artifacts, e.g., accounts receivable
Arrangement Arrangement of Events Entities Entities in Order of Occurrence
Step 2. Identify the Resource Entities
Identify the resources impacted i mpacted by events identified in step 1. Each event must be linked to at least one resource.
Economic events directly affect resources.
Support events indirectly affect them.
Step 3. Identify the Agent Entities Entities
Each economic event entity in an REA diagram is associated with at least two agent entities.
One internal agent
One external agent
It is possible to have only an internal agent when no exchange occurs, as with certain ‘internal’ manufacturing manufacturing processes.
REA Model Showing Events and Related Resources and Agents
Step 4. Determine Associations Associations and a nd Cardinalities between Entities
reflects the nature of the relationship relationship – reflects Association – between two entities
the degree of association between the the – the Cardinality – entities
Represented by the labeled line connecting the entities
Describes the number of possible occurrences in one entity that are associated with a single occurrence in a related entity
Cardinality reflects the business rules that are in play for a particular organization.
Sometimes Sometimes the rules are obvious and are the same for all organizations. organizations. Sometimes Sometimes the rules differ, e.g., whether inventory items are tracked individual i ndividually ly or as quantity on hand.
Associations Associations and Cardinality Cardinality in REA Diagram
Many-to-Many Many-to-Many Associations
Many-to-many Many-to-many (M:M) associations cannot be directly implemented into relational databases. They require the creation of a new linking table.
This process splits the M:M association into two 1:M associations. The linking table requires requires a ‘composite primary primary key’.
Link Tables in an REA Diagram
View Integration: Integration: Creating Creating an Enterprise-W Enterprise-Wide ide REA Model
combining several individual REA View integration – combining diagrams into a single enterprise-wide model The three steps involved in view integration are: are: 1.
Consolidate the individual models.
2.
Define primary keys, foreign keys, and attributes.
3.
Construct physical database and produce user views.
Step 1. Consolidate the Individual Models
Merging multiple REA models requires first a thorough understanding of the business processes and entities involved in the models. Individual models are consolidated or linked together based on shared entities.
For example, procurement (expenditures) and sales (revenue) both use inventory and cash resource entities.
Integrated REA Diagram
Step 2. Define Primary Keys, Foreign Keys, and Attributes
Implementation Implementation into a working relational database database requires primary keys, foreign keys and attributes in tables.
uniquely identifies an instance Primary key – uniquely of an entity (i.e., each row in the table) Foreign key – the the primary key embedded in the related table so that the two tables can be linked Attribute – a a characteristic of the entity to be recorded in the table
Rules for Foreign Keys Primary key Foreign key: Relations are formed by an attribute that is common to both tables in the relation.
Assignment of foreign foreign keys:
if 1 to 1 (1:1) association , either of the table’s primary primary key may be the foreign key if 1 to many (1:m) association , the primary key on one of the sides is embedded as the foreign key on the other side if many to many (m:m) association , create a separate linking table with a composite primary primary key
Attributes
Using the customer as an example, these data include: Financial
Nonfinancial Nonfinancial
Customer name Customer address
Customer credit rating
Customer telephone number
Damaged Damaged goods record On-time payment record Customer volume record
Amount owed by customer
EDI access
Value of total sales sales to date
Internet access
Terms of trade trade offered
Step 3. Construct Physical Database and Produce User Views
The database designer is now ready to create the the physical relational tables using software. Once the tables have been constructed, some some of them must be populated with data.
Resource and Agent tables
Event tables must wait for business transactions transactions to occur before data can be entered. The resulting database database should support the information needs of all users.
User-Views
SQL is used to generate reports, computer screens, and documents for users.
Value Chain Analysis
Competitive advantages from the REA approach can be see via value chain analysis.
Value chain analysis analysis distinguishes between primary primary activities (create value) and support activities (assist performing primary activities).
REA provides a model for identifying and differentiating between these activities. Prioritizing Strategy: Focus on primary activities; activities; eliminate or outsource support activities.
Competitive Competitive Advantages of the REA Model
Using REA can lead to more efficient operations.
Helps managers identify non-value added activities that can be eliminated •
Increasing productivity via 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.
Using REA can lead to more efficient operations.
Detailed financial and nonfinancial nonfinancial business data supports a wider range of management decisions •
supporting multiple user views (e.g., different perspectives on a problem)
Provides managers with more relevant, timely, and accurate information. information. •
leading to better customer service, higher-quality products, and flexible production processes
