Similarities Between Rea And Er Diagrams

Developing an REA Model

In the previous chapter we described the process of view modeling, in which the database designer identifies and models the set of data that individual users need to make a decision or perform a task. The result of this process is an ER diagram depicting the user's data model. The REA approach uses semantic modeling to construct an REA diagram, which in some ways is similar to an ER diagram, but in other respects is quite different. Before we describe REA view modeling, we need to examine these differences.

DIFFERENCES BETWEEN ER AND REA DIAGRAMS

ER and REA diagrams differ visually in a significant way. Entities in ER diagrams are of one class, and their proximity to other entities is determined by their cardinality and by what is visually pleasing to keep the diagrams readable. Entities in an REA diagram, however, are divided into three classes (resources, events, and agents) and organized into constellations by class on the diagram. This arrangement is illustrated in Figure 10-4. Note that during view integration (discussed later), when several individual REA diagrams are merged to form a single global model, the constellations of entities may necessarily be altered. As a design tool during the view modeling phase, however, the constellation convention is typically followed.

A second difference between ER and REA diagrams involves the sequencing of events. ER diagrams present a static picture of the underlying business phenomena. Relationships between data are shown through cardinality and associations, but the sequence of activities that determine the cardinality and associations is not clearly represented. REA diagrams, however, are typically organized from top to bottom within the constellations to focus on the sequence of events. An advantage of this is that during systems development, management and nontechnical users better understand REA diagrams.

The third difference between ER and REA diagrams pertains to naming conventions for entities. In ER diagrams, entity names are always represented in the singular noun form. REA modeling applies this rule when assigning names to resource and agent entities. Event entities, however, are given verb (action) names such as Sell Inventory, Take Order, or Receive Cash. The reader should, therefore, be careful to not confuse an event entity with a process. Event entities on an REA diagram represent and describe data- base tables that will store data about processes, but they are not representing or describing the processes themselves.

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:

Apex Supply Company is a downtown Philadelphia wholesaler of electrical products that sells to electri- cal retailers. It carries an inventory of approximately 10,000 items. Customers place orders by phone and buy on credit through a line-of-credit arrangement with Apex. A typical transaction involves the customer first contacting the customer services department to verify availability and check the price of the item or items being sought. If the customer decides to buy, he or she is transferred to a sales agent, who takes the order. The shipping clerk sends the products to the customer by a common carrier. The billing clerk records the sale in the sales journal, prepares an invoice, and sends it to the customer, who is given 30 days to make payment. The AR clerk also receives a copy of the invoice and records it in the AR ledger. Subsequently (within 30 days) the customer sends a check and the remittance advice to Apex. The cash receipts clerk receives the check, records it in the cash receipts journal, and updates the cash account. The remittance advice goes to the AR clerk, who updates (reduces) the customer's account receivable.

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 employ- ees 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 sup- port 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.

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 in- ventory 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, there- fore, that Verify Availability is a value-added activity that should be modeled in the REA diagram.

TAKE ORDER. Depending on the circumstances, Take Order could be either an economic or support event. 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 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 con- sequences derive directly from the Take Order event and it is, therefore, a support event.

SHIP PRODUCT. Ship Product is an economic event. This is the give half of an economic exchange and reduces the inventory resource directly.

RECEIVE CASH. Similarly, the Receive Cash event is an economic event. This is the receive half of the exchange that increases the cash resource.

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. Figure 10-5 presents the four events previously described in sequence of occurrence.

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 event reduces the inventory resource and the Receive Cash event increases the cash resource. The Verify Avail- ability and the Take Order support events are also associated with inventory, but they do not change it. The resource and associated event entities are presented in Figure 10-6.

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. Figure 10-6 illustrates the relationship between the events and associated external and internal agents in the Apex case.

Step 4. Determine Associations and Cardinalities between Entities

We discussed in detail in Chapter 9 the topics of entity association and cardinality. This section assumes familiarity with these topics, which are only briefly reviewed.

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

Figure 10-7 presents three alternative methods for presenting cardinalities in an REA diagram. Alter- native 1 presents the crow's foot notation method discussed in Chapter 9. The example illustrates that a single occurrence (record) in Entity A is associated with zero or many occurrences in Entity B. Thus, the lowest possible cardinality is zero and the highest is many. Looking in the other direction, the notation states that a single occurrence in Entity B is associated with one and only one occurrence in Entity A. Sometimes lower and upper cardinality are explicitly written on the association line between the entities, as shown in Alternative 2 in the figure. A shorthand version of this is presented as Alternative 3, which shows only the upper cardinality and presumes the lower cardinality to be zero. The upper cardinalities for each entity define the overall association. For example, the entities in Figure 10-7 are said to have a 1:M association. Other possible associations are 1:1 and M:M.

Figure 10-8 presents a revised data model for Apex. Notice that it has been simplified for better read- ability by eliminating redundant instances of the Customer and Inventory entities that were depicted in Figure 10-6. In addition, Figure 10-8 shows the association and cardinality between entities using the crow's foot notation method. Cardinality reflects the business rules that are in play for a particular organization. Sometimes the rules are obvious and are the same for all organizations. For example, the nor- mal cardinality between the Customer and Take Order entities are 1,1 and 0,M. This signifies that a particular customer may have placed zero or many orders during the sales period and that each order is for only one customer. The association between these entities is 1:M and would never be 1:1 as this would mean that the organization restricts each customer to an upper limit of only one order, which is illogical. The association between internal agents and event entities follows this same pattern. An orga- nization would expect its employees to participate in many events over time, not just one. Most of the cardinalities in Figure 10-8 reflect rules that are self-explanatory. A few points that need further explanation are presented next.

CARDINALITY BETWEEN THE VERIFY AVAILABILITY AND TAKE ORDER ENTITIES.

Each occurrence of the Verify Availability entity is the result of a customer inquiry. We know from the case description, however, that not all inquiries result in a customer order. On the other hand, we will make the simplifying assumption that each Take Order occurrence is the result of an inquiry. The cardinality on the Take Order side of the relation, therefore, is 0,1. On the Verify Availability side, it is 1,1.

CARDINALITY BETWEEN THE TAKE ORDER AND SHIP PRODUCT ENTITIES. The 0,1 cardinality on the Ship Product side of the relation reflects the timing difference between orders taken and shipped. Because sales are not processed instantly, we can assume that an order will exist (occurrence of Take Order) that has not yet been shipped (no occurrence of Ship Product). Furthermore, an order that is canceled before being shipped would also result in no Ship Product record being created.

CARDINALITY BETWEEN THE SHIP PRODUCT AND RECEIVE CASH ENTITIES. Business terms of trade and payment policies vary greatly. Companies that make credit sales to consumers often accept partial payments over time. This would result in many cash receipts occurrences for a single shipment occurrence. On the other hand, companies whose customers are other businesses typically expect payment in full when due. Business customers, however, may consolidate several invoices on a single cash payment to reduce check writing. Because the Apex company is a wholesaler that serves business customers, we will assume that debts are paid in full (no multiple partial payments) and that Apex customers may pay for multiple shipments with a single cash receipt. The cardinality in Figure 10-8 reflects this business rule.

CARDINALITY BETWEEN THE CASH AND RECEIVE CASH ENTITIES. The cash resource of an organization is composed of several different accounts, such as the general operating account, payroll imprest account, petty cash, and so on. These are consolidated for financial reporting into a single account, but are used and tracked separately. The cardinality depicted in this relationship implies that cash is received from many customers and is deposited into one account.

MANY-TO-MANY ASSOCIATIONS. The model in Figure 10-8 depicts three examples of M:M associations. The first of these is between the Verify Availability and Inventory entities. A 1,M cardinality exists at the Inventory end of the association and a 0,M cardinality lies at the Verify Availability end. This suggests that a particular customer query could involve one or many items of inventory, and each item may have been queried zero or many times in the period. The second M:M association exists between the Take Order and Inventory entities. A 1,M cardinality exists at the Inventory end of the association and a 0,M cardinality is at the Take Order end. This means that a particular order may con- tain one or many different items of inventory and that a particular item may have never been ordered (perhaps a new product) or may have been ordered many times during the period. A similar situation exists between the Ship Goods and Inventory entities. In each of these cases the upper cardinalities of M creates an M:M association, which we know from Chapter 9 must be reconciled. These situations are the result of repeating group data that need to be normalized before implementing the model in a relational database.2 The solution is to create three link tables that contain the primary keys of the associated tables. The link tables will also contain details pertaining to items queried, the orders taken, and the products shipped.

When modeling traditional ER diagrams, it is often convenient to include the link tables in the model (as in Chapter 9) so that it reflects closely the actual database. The inclusion of link tables in an REA dia- gram, however, creates a conflict with the rule that an event entity should be connected to at least one resource and at least two agent entities. Figure 10-9 shows how a portion of the Apex REA diagram would appear when link tables are inserted. Although link tables are a technical requirement for implementing an M:M association in a relational database, they are not a technical requirement for modeling the database. Including the link table in an REA diagram disrupts its visual integrity and adds little to one's understanding of the conceptual model. Ultimately, during implementation, the database designer will create the link tables. Indeed, the database cannot function without them. For REA diagramming purposes, however, the link tables need only be implied via the M:M associations.

Incoming search terms:

• REA diagram (18)
• Developing an REA diagram for a specific transaction cycle consists of three steps Explain the three steps? (8)
• Which of the following best describes an event during step 2 in the simplified model above? (7)
• rea data model (5)
• rea[er (5)
• what is rea (5)
• 11 What do the initials "REA" stand for? What does REA modeling allow us to determine in database design? (4)
• Assume that you are looking at a REA diagram that depicts only one event Which of the following must be on the REA diagram? (4)
• cardinality of rea diagram (4)
• DATABASE DESIGN USING THE REA DATA MODEL (4)
• discuss resource planning and steps of developing REA DIAGRAM (4)
• explain rea model with expamples (4)
• how many junction tables are indicated in the rea model (4)
• In an REA diagram resource entities (4)
• interpreting cardinality in er diagram (4)
• model rea (4)
• prepare an er diagram that illustrates a normalized data model for a general ledger update process (4)
• REA (Resources Events Agents) (4)
• REA cardinality (4)
• REA diagram in a database quizlet (4)
• rea diagram payroll function (4)
• rea diagrams quizlet (4)
• rea is best discrebed as (4)
• rea model business chron (4)
• rea model with cardinality (4)
• reaassociation agent (4)
• relationships rea modeling (4)
• resources agents and events to form cardinalities (4)
• resources events and agents REA in revenue cycle in AIS (4)
• steps of a area model (4)
• table for rea (4)
• The balance of Accounts Receivable would be depicted in an REA model using ONE of which type of entity? (4)
• why is the REA diagram not appropriate? free pdf 2017 (4)
• cash only rea model (3)
• Develop the REA model for the entities (3)
• developing rea model (3)
• discuss steps in development REA diagram with definitions (3)
• five steps of REA Model (3)
• list the 3 steps in creating a rea value chain level diagram (3)
• rea usda spec rule (3)
• 5 steps in developing REA (2)
• amber rea model (2)
• association in rea approach (2)
• describe three difference between REA diagram and ER model (2)
• Expline REA Modeling and how it works (2)
• How Develop of REA model (2)
• how to read appraoch diagram (2)
• I\ans place Planning a database using REA and E-R diagrams (2)
• Prepare a hand drawn REA model with cardinalities for the operating events resources and agents in PPE Supply's Sales/Collection Cycle (2)
• REA and Entity difference (2)
• REA approach in data modelling (2)
• REA model (2)
• Step In Developing An Rea (2)
• steps in developing a REA model (2)
• the rea approach in database modeling (2)
• The REA approach to business process modeling (2)
• what does the agent do in an REA diagram (2)
• what is an rea (2)
• what is the rea (2)
• write and discuss the steps of developing REA diagram (2)
• write&discuss steps developing REA diagram (2)
• 1 a customer can place many orders 2 each order is placed by only one customer look at those rules and determine the entities and relationship then draw the conceptual model (ERD) (1)
• 1 which one of the following is not one of the processes that need to be done Before developing an ER diagram? (1)
• 10 Define the key elements of the REA model (1)
• 10 steps of the REA process (1)
• 3 entity types under rea approach (1)
• 5 Develop the REA model for the entities (1)
• 5 steps involved in thedevelopment of the rea model (1)
• a brief understanding of REA model (1)
• A Revenue Cycle Process Approach 7th pdf (1)
• a "Choose AIS software" would be included as an event in a REA model (1)
• Apex Supply Company is a downtown Philadelphia wholesaler of electrical products that sells to electrical retailers It carries an inventory of approximately 10 000 items Customers place orders by phone and buy on credit through a line-of-credit arrangemen (1)
• article on rea model relational database (1)
• business rules' that should exist between "Customer" and "Sales Order" in er diagram (1)
• Chapter 15 Database Design Using the REA Data Model (1)
• Define the three basic type rea entities (1)
• Definition of REA diagram (1)
• Describe the E-R diagram and REA data model in designing a database system for use in any one value-chain (sales accounting HR purchasing etc ) activity of an organization (1)
• Describe the symbols used to make an REA Model (1)
• develooing an rea diagram and steps (1)
• developing a model (1)
• developing a rea model (1)
• developing REA diagram (1)
• developing Rea diagram example transaction (1)
• Development of REA model (1)
• Diagram: Cardinalities (1)
• difference between REA and ER diagram (1)
• disadvantages of using a REA diagram (1)
• discrib the diference between REA diagram and ER diagram (1)
• discuss in steps in developing an REA diagram (1)
• discuss the steps in value cycle (1)
• Entities are physical resources events and agents about which the organization wishes to capture data (1)
• ER diagram vs REA (1)
• example REA (1)
• EXPLAIN REA MODELING how it work (1)
• explain the REA steps (1)
• explanation in rea approach (1)
• explin rea modeling how it work (1)
• five steps in developing a rea model (1)
• five steps in the development of rea model in their sequence in accounting information systems (1)
• five steps involved in the development of the rea model (1)
• four steps developing REA Diagram (1)
• four steps for developmg a maximum contamination level (1)
• garageykb (1)
• greg rea form & build (1)
• How are REA diagrams read (1)
• how do I know the REA model is perfect (1)
• how to add multicipalities in the REA diagram (1)
• How to develop rea data model (1)
• How to develop REA model (1)
• how to make a rea diagram (1)
• how to make a table showing relationships in a REA model (1)
• how to read a rea diagram (1)
• how to read an rea diagram (1)
• importance of REA approach apply to database modelling (1)
• in the rea model what is query availability (1)
• list and discuss four steps in developing an rea diagram for aspecific transaction cycle (1)
• list and discuss the three key elements in the rea data model (1)
• make a rea (1)
• order of steps in the preparation of an REA model (1)
• rea and er diagrams (1)
• REA and REAL modelling (1)
• REA approch model example (1)
• rea data modeling (1)
• rea developement (1)
• rea diagram and an er diagram (1)
• rea diagram and ea diagram (1)
• REA diagram cardinalities explained (1)
• rea diagram examples (1)
• REA Diagram explain (1)
• rea diagram how to make it (1)
• rea diagram model for sales and cardinalities (1)
• REA diagram of product (1)
• rea diagram shipping billing (1)
• REA diagrams are read in the following steps (1)
• REA diagrams level 4 (1)
• rea e-r model with maximum cardinalities examples (1)
• rea employee meaning (1)
• rea information (1)
• REA model be used to help in the audit process (1)
• REA Model classes (1)
• REA model diagram of selling (1)
• rea model examples (1)
• REA model steps in accounting information systems pdf (1)
• REA model with cardinalities (1)
• rea modeling (1)
• rea models (1)
• rea relationship (1)
• REA to be developped (1)
• rules for REA diagram creation (1)
• sample company rea model example (1)
• State the three basic rules (patterns) that apply to the REA data modelling? (1)
• step of developing REA diagram (1)
• steps are required when designing a database accounting REA (1)
• steps in developing a REA (1)
• steps involved in REA Modeling (1)
• steps involved in the development of rea model (1)
• steps involved in the development of the rea model in their sequence (1)
• steps taken when making a rea model (1)
• the difference and similarities between er and rea database (1)
• The difference between REA diagram and ER diagram (1)
• the difference between REA diagram ER diagram (1)
• the rea approach to database modeling (1)
• three difference between ER and REA diagram simple (1)
• three differences REA and ER diagrams (1)
• typical % for preparing rea (1)
• USAREC Rules REA (1)
• view modelling: creating an individual rea diagram (1)
• what are steps involved in the development of the rea model in accounting information systems pdf (1)
• What are the agent involment in a REA (1)
• What are the basic principles and design considerations for a REA model (1)
• what are the rules to prepare REA model (1)
• what are the step in developing REA diagram (1)
• what are time cards in a REA model (1)
• What does C R C approach stand for and briefly describe the approach (1)
• what is a rea (1)
• what is a REA case analysis? (1)
• what is REA model (1)
• what is the similarities between Flowcharting Data Flow Diagramming and REA Modeling (1)
• When developing an REA model: (1)
• which of the following best describes an event during step 2 in the simplified model above (1)
• write the 3 key Element in the REA data model (1)
• write the steps of developing REA diagram (1)
• write&discussthestepsofdevelopingreamodel (1)
• __________ is the detailed planning and engineering of products services or processes Grupo de opciones de respuesta (1)

Related posts:

Source: http://www.engineering-bachelors-degree.com/business-information-management/uncategorized/the-rea-approach-to-database-modelingdeveloping-an-rea-model/

Posted by: minhackerse0193597.blogspot.com

Share :