Database Design Using the REA Data Model Chapter 17 Database Design Using the REA Data Model Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

Database Design Process System Analysis Conceptual Design Physical Design Implementation & Conversion Operation & Maintenance Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

The System Analysis Process Systems Analysis Initial planning to determine the need for and feasibility of developing a new system Judgments about the proposal’s technological and economic feasibility Identify user information needs Define the scope of the proposed new system Gather information about the expected number of users and transaction volumes to make preliminary decisions about hardware and software requirements Conceptual Design Developing the different schemas for the new system at the conceptual, external, and internal levels Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

Conceptual Design Copyright 2012 © Pearson Education, Inc. publishing as Prentice Hall

The System Analysis Process (cont’d) Physical Design Translating the internal-level schema into the actual database structures that will be implemented in the new system New applications are developed Implementation and Conversion Includes all the activities associated with transferring data from existing systems to the new database AIS Testing the new system Training employees Maintaining the New System Eventually, changes in business strategy and practices or new IT developments lead to the need for a new system and the process starts over.

Copyright 2012 © Pearson Education, Inc. publishing as Prentice Hall

Data Modeling Process of defining an information system so it represents an organizations requirements Occurs at two stages of the design process: System analysis Conceptual design Data models: Data flow diagrams (Chapter 3) Flow charts (Chapter 3) Entity-relationship diagrams (Chapter 17) Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

Entity-Relationship Diagrams Used to graphically represent a database schema Depicts entities Anything an organization wants to collect information about In a relational database, separate tables would be created to store information about each distinct entity. Relationships between entities Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

In an E-R diagram, entities are depicted as rectangles. But there are no industry standards for other aspects of these diagrams. Sales Inventory Copyright 2012 © Pearson Education, Inc. publishing as Prentice Hall

ENTITY-RELATIONSHIP DIAGRAMS Some data modelers, tools, and authors use diamonds to depict relationships. Sales Inventory Line Items Others do not use diamonds. Sales Inventory

E-R Diagram Variations Primary key Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

ENTITY-RELATIONSHIP DIAGRAMS Sometimes the attributes associated with each entity are depicted as named ovals connected to each rectangle. Example using an educational institution setting Primary key

Resources-Events-Agents Diagram Developed for designing AIS Categorizing entities into: Resources Things that have economic value Events Business activities Management wants to manage and control Agents People and organizations that participate in events Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

Copyright 2012 © Pearson Education, Inc. publishing as Prentice Hall

THE REA DATA MODEL resources on this REA diagram Inventory Sales Employee Customer Cash Accounts Receive Cash Employee

THE REA DATA MODEL events on this REA diagram Inventory Sales Employee Customer Cash Accounts Receive Cash Employee

THE REA DATA MODEL agents on this REA diagram Inventory Sales Employee Customer Cash Accounts Receive Cash Employee

REA Diagram Rules Each event is linked to at least one resource that it affects. Each event is linked to at least one other event. Types of links (relationships): Get events Give events Participation events Each event is linked to at least two participating agents. Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

Business Cycle Give–Get Relationships The revenue cycle involves interactions with your customers. You sell goods or services and get cash. Give Inventory Get Cash

Business Cycle Give–Get Relationships The expenditure cycle involves interactions with your suppliers. You buy goods or services and pay cash. Give Cash Get Inventory

Business Cycle Give–Get Relationships The payroll resources cycle involves interactions with your employees. Employees are hired, trained, paid, evaluated, promoted, and terminated. Give Cash Get Employee Time

Business Cycle Give–Get Relationships The financing cycle involves interactions with investors and creditors. You raise capital (through stock or debt), repay the capital, and pay a return on it (interest or dividends). Give Cash Get Cash

Business Cycle Give–Get Relationships In the production cycle, raw materials, labor, and machinery and equipment time are transformed into finished goods. Give (Use) Raw Materials Give (Use) Employee Time Get Finished Goods Inventory Give (Use) Machinery & Equipment

Revenue Cycle REA Diagram Batini notation Take Order Employee (1,N) (1,1) (0,N) (0,N ) (1,1) Inventory (0,1) (0,N) Customer (0,N) (0,1) (1,1) (0,N) (1,N) Sale (1,1) (0,N) Employee (0,N) (0,N) (1,N) or (0,N) ?? (1,1) Cash Receive Cash Customer (1,1) (0,N) (0,N) (1,1) or (0,1) ??

Developing an REA Diagram Identify the events about which management wants to collect information. Identify the resources affected by each event and the agents who participate in those events. What economic resource is reduced by the “Give” event? What economic resource is acquired by the “Get” event? What economic resource is affected by a commitment event? Determine the cardinalities of each relationship. Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

STEP ONE: IDENTIFY RELEVANT EVENTS Example: Typical activities in the revenue cycle include: Take customer order Fill customer order Bill customer Collect payment

STEP ONE: IDENTIFY RELEVANT EVENTS Take Order (Sale order) Sale Receive Cash

STEP TWO: IDENTIFY RESOURCES AND AGENTS Take Order (sale order) Sale the give event Receive Cash

STEP TWO: IDENTIFY RESOURCES AND AGENTS Take Order (sale order) Inventory Resource reduced by the give event Sale Receive Cash

STEP TWO: IDENTIFY RESOURCES AND AGENTS Take Order (Sale order) Inventory Sale the get event Receive Cash

STEP TWO: IDENTIFY RESOURCES AND AGENTS Take Order (sale order) Inventory Sale Resource increased by the get event Cash Receive Cash

STEP TWO: IDENTIFY RESOURCES AND AGENTS Agents involved in the sale Take Order (Sale order) Inventory Customer Sale Employee Cash Receive Cash

STEP TWO: IDENTIFY RESOURCES AND AGENTS Agents involved in the receipt of cash Take Order (Sale order) Inventory Customer Sale Employee Cash Receive Cash Customer

STEP TWO: IDENTIFY RESOURCES AND AGENTS Agents involved in taking the order Take Order (Sale order) Employee Inventory Customer Sale Employee Cash Receive Cash Customer

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS The final step in an REA diagram for a transaction cycle is to add information about the relationship cardinalities. A cardinality describes the nature of the relationship 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?

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Unfortunately, there is no universal standard for diagramming cardinalities. 2 common Alternative formats are shown on the next slide Batini style notation(my preference) Assignments will use Batini notation Book uses Crow’s feet

Crow’s Feet notation Batini notation Copyright 2012 © Pearson Education, Inc. publishing as Prentice Hall

Cardinalities Describe the nature of relationships between entities How many instances of one entity can be linked to each specific instance of another entity Minimum can be: 0 or 1 Maximum can be: 1 or Many Relationship type is based on maximum cardinality: Three types of relationships Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS It is not a “one size fits all” world for relationships and cardinalities. The cardinalities between two entities can vary based on how the particular company does business.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS In relationships between events and agents: For each event that occurs, the cardinality between event and agent is typically (1:1). This is a general rule of thumb Example: When a sale occurs: There is usually one and only one customer. There is usually one and only one salesperson. This practice makes it more feasible for the organization to establish employee accountability for the event.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Batini notation Take Order Employee (1,1) (1,1) Inventory Customer (1,1) Sale (1,1) Employee (1,1) Cash Receive Cash Customer (1,1) or (0,1) ??

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS For each agent the cardinality between agent and event is typically (0:N). (This is a general rule of thumb) Example: For a particular salesperson: There is typically a minimum of zero sales (allows for inclusion of a new salesperson who has not yet made any sales). 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 bought anything yet) and a maximum of many sales.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Batini notation Take Order Employee (1,1) (0,N) (1,1) Inventory (0,N) Customer (1,1) (0,N) Sale (1,1) (0,N) Employee (0,N) (1,1) Cash Receive Cash Customer (0,N) (1,1) or (0,1) ??

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Let’s now look at the relationship between events and resources. In the cardinality between event and resource, the minimum cardinality is typically one, because an event can’t occur without affecting at least one resource. This is a general rule of thumb

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Batini notation Take Order Employee (1, ) (1,1) (0,N) (1,1) Inventory (0,N) Customer (1,1) (0,N) (1, ) Sale (1,1) (0,N) Employee (0,N) (1,1) Cash Receive Cash Customer (1, ) (0,N) (1,1) or (0,1) ??

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS The maximum could be one or many. In this particular story, each sale can involve many items of inventory, so the maximum is many. (This is a general rule of thumb) However, every receipt of cash is deposited to one and only one cash account, so the maximum there is one. (This is a good business practice

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Batini notation Take Order Employee (1,N) (1,1) (0,N) (1,1) Inventory (0,N) Customer (1,1) (0,N) (1,N) Sale (1,1) (0,N) Employee (0,N) (1,1) Cash Receive Cash Customer (1,1) (0,N) (1,1) or (0,1) ??

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS In the cardinality between resource and event, the minimum is typically zero. (This is a general rule of thumb) 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 receipt deposited in it.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Batini notation Take Order Employee (1,N) (1,1) (0,N) (0 , ) (1,1) Inventory (0,N) Customer (0 , ) (1,1) (0,N) (1,N) Sale (1,1) (0,N) Employee (0,N) (1,1) Cash Receive Cash Customer (1,1) (0,N) (0 , ) (1,1) or (0,1) ??

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS In the cardinality between resource and event, the maximum is typically many. (This is a general rule of thumb) Most inventory items can be sold many times. (An exception might occur if each inventory item is one unique item, such as a piece of real estate.) The company’s cash account can have many cash receipts.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Batini notation Take Order Employee (1,N) (1,1) (0,N) (0,N ) (1,1) Inventory (0,N) Customer (0,N) (1,1) (0,N) (1,N) Sale (1,1) (0,N) Employee (0,N) (1,1) Cash Receive Cash Customer (1,1) (0,N) (0,N) (1,1) or (0,1) ??

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Relationships between events. When events occur in a sequence, the minimum cardinality between the first event and the second event is (always or usually) zero, because there is a span of time (although possibly quite short) when the first event has occurred but 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 the customer.(see note below) Note: REA model diagram is supposed to represent your business process. For a cash sale environment, many modelers would set minimum cardinality between sale and receipt as one

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS The minimum cardinality between the second event and the first event is typically one, because the second event can’t occur without the first event having occurred. An exception could occur if the first event is not required for the second event to occur. Example: If a sale can be made without first taking an order, then the minimum cardinality between sale and take order could be zero.

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS The maximums in the cardinalities between events can be either one or many, and these maximums vary based on business practices

STEP THREE: DETERMINE CARDINALITIES OF RELATIONSHIPS Batini notation Take Order Employee (1,N) (1,1) (0,N) (0,N ) (1,1) Inventory (0,1) (0,N) Customer (0,N) (0,1) (1,1) (0,N) (1,N) Sale (1,1) (0,N) Employee (0,N) (0,N) (1,N) or (0,N) ?? (1,1) Cash Receive Cash Customer (1,1) (0,N) (0,N) (1,1) or (0,1) ??

Core REA Pattern

Core REA Pattern (No table for external agent)

REA Sales/Collection

THE Extended REA DATA MODEL (Revenue Cycle)

REA Acquisition/Payment

THE Extended REA DATA MODEL (Expenditure Cycle)