Chapter 10 Elemental REA Model

The REA Approach to Business Process Modeling

Objectives for Chapter 10

 Economic foundations of the REA model
 Key differences between traditional ER modeling and REA
modeling
 The structure of an REA diagram
 Create an REA diagram by applying the view modeling steps to
a business case
 Create an entity-wide REA diagram by applying the view Resources, Events, and Agents Model
integration steps to a business case  Another key feature of the REA model is economic duality.
 Events occur in pairs
Traditional Approaches:User-View Orientation  Represent the give event and receive event of an
 When data-modeling and IS design is too oriented toward the economic exchange
user’s views, problems arise:
 multiple information systems
 duplication of data
 restricted user-view leads to poor decision-making
 inability to support change

Resources, Events, and Agents Model

 REA is an approach to database design meant to overcome
problems with traditional approaches:
 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

Resources, Events, and Agents Model

 REA models consists of three entity types and the associations
linking them.
 Resources
 Events ER Diagrams (ERD’s) versus REA Diagrams (READ’s)
 Agents  Classes of entities
 ERD’s – one class
Resources in the REA Model  READ’s – three classes (resources, events, and agents)
 Resources – the ‘assets’ of the company  Arrangement of entities
 things of economic value  ERD’s – determined by cardinality and readability
 objects of economic exchanges able to generate revenue  READ’s – organized into constellations by class
 objects that are scarce and under the control of the  Sequencing of events
organization  ERD’s – static
 can be tangible or intangible  READ’s – chronological sequence of business processes
 Does not include some traditional accounting assets:  Naming conventions
 artifacts that can be generated from other primary data  ERD’s – all nouns
 for example, accounts receivables  READ’s – nouns (R’s and A’s) and verbs (E’s)

Events in the REA Model View Modeling: Creating an Individual REA Diagram
 Events are phenomena that effect changes in resources.  View modeling is a multistep process for creating an
 a source of detailed data in the REA approach to individual REA model.
databases  The result is a single view of the entire database.
 Events fall into two groups:  The four steps involved are:
 Economic – increases or decreases resources 1. identify the event entities to be modeled
 Support – control, planning, and other management 2. identify the resource entities changed by events
activities; but do not directly affect resources 3. identify the agent entities participating in events
4. determine associations and cardinalities between entities
Agents in the REA Model
 Agents can be individuals or departments. Step 1: Identify the Event Entities
 Participate in events  Identify the events that are to be included in the model
 Affect resources  Include at least two economic events (duality)
 Have discretionary power to use or dispose of resources  May include support events
 Can be inside or outside the organization  Arrange events in chronological sequence
 Clerks  Focus on value chain events
 Production workers  Do not such invalid events such as:
 Customers  bookkeeping tasks
 Suppliers, vendors  accounting artifacts, e.g., accounts receivable
 Departments, teams
Arrangement of Events Entities in Order of Occurrence are tracked individually or as quantity on hand.

Step 2. Identify the Resource Entities

 Identify the resources impacted 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 Many-to-Many Associations

 Each economic event entity in an REA diagram is associated  Many-to-many (M:M) associations cannot be directly
with at least two agent entities. implemented into relational databases.
 One internal agent  They require the creation of a new linking table.
 One external agent  This process splits the M:M association into two 1:M
 It is possible to have only an internal agent when no associations.
exchange occurs, as with certain ‘internal’ manufacturing  The linking table requires a ‘composite primary key’.
processes.

View Integration: Creating an Enterprise-Wide REA Model

 View integration – combining several individual REA
Step 4. Determine Associations and Cardinalities between diagrams into a single enterprise-wide model
Entities  The three steps involved in view integration are:
 Association – reflects the nature of the relationship between 1. consolidate the individual models
two entities 2. define primary keys, foreign keys, and attributes
 Represented by the labeled line connecting the entities 3. construct physical database and produce user views
 Cardinality – the degree of association between the entities
 Describes the number of possible occurrences in one Step 1. Consolidate the Individual Models
entity that are associated with a single occurrence in a  Merging multiple REA models requires first a thorough
related entity understanding of the business processes and entities involved
 Cardinality reflects the business rules that are in play for a in the models.
particular organization.  Individual models are consolidated or linked together based
 Sometimes the rules are obvious and are the same for all on shared entities.
organizations.  For example, procurement (expenditures) and sales
 Sometimes the rules differ, e.g., whether inventory items (revenue) both use inventory and cash resource entities.
 relational tables using software.
 Once the tables have been constructed, some of them must
be populated with data.
 Resource and Agent tables
 Event tables must wait for business transactions to occur
before data can be entered.
 The resulting database should support the information needs
of all users.
 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 distinguishes between 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; eliminate
or outsource support activities.

Step 2. Define Primary Keys, Foreign Keys, and Attributes

 Implementation into a working relational database requires
primary keys, foreign keys and attributes in tables.
 Primary key – uniquely identifies an instance of an entity
(i.e., each row in the table)
 Foreign key – the primary key embedded in the related
table so that the two tables can be linked
 Attribute – a characteristic of the entity to be recorded in
the table

Rules for Foreign Keys

 Primary key toForeign key: Relations are formed by an
attribute that is common to both tables in the relation.
 Assignment of foreign keys:
 if 1 to 1 (1:1) association, either of the table’s primary key
may be the foreign key Competitive Advantages of the REA Model
 if 1 to many (1:m) association, the primary key on one of  Using REA can lead to more efficient operations.
the sides is embedded as the foreign key on the other side  Helps managers identify non-value added activities that
 if many to many (m:m) association, create a separate can be eliminated
linking table with a composite primary key  Increasing productivity via elimination of non-value added
Attributes 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 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.
 leading to better customer service, higher-quality products,
and flexible production processes

Step 3. Construct Physical Database and Produce User Views

 The database designer is now ready to create the physical