Implementing an REA Model in a Relational Database Chapter 18 Implementing an REA Model in a Relational Database

REA Diagram—Revenue Cycle Fred’s Train Shop

REA Diagram—Expenditure Cycle Fred’s Train Shop

REA Diagram—Payroll Cycle Fred’s Train Shop

REA Redundancies Difference between merging redundant events and merging redundant resources: Merging redundant resources does not affect any cardinalities. LINKAGE BETWEEN CYCLES Merging redundant events alters minimum cardinalities associated with the other events that are related to the merged event. May be linked to either an event that is part of one business cycle or to an event that is part of another cycle but cannot be linked to both events The minimum cardinality associated with the other events must be 0 in the integrated REA diagram

Intergraded REA Diagram

The revenue cycle This model assumes customers are the only source of cash receipts. Usually there will be also be cash receipts from other sources/cycles. This would change the indicated minimum cardinalities to 0

The Expenditure cycle This model assumes customers are the only source of cash receipts. Usually there will be also be cash receipts from other sources/cycles. This would change the indicated minimum cardinalities to 0

This model assumes customers are the only source of cash receipts. Usually there will be also be cash receipts from other sources/cycles. This would change the indicated minimum cardinalities to 0 The payroll cycle

This model assumes customers are the only source of cash receipts. Usually there will be also be cash receipts from other sources/cycles. This would change the indicated minimum cardinalities to 0 The integrated diagram merges multiple copies of resource and event entities but retains multiple copies of agent entities.

Cardinality Effect of Merging Resources Cardinalities between resource and entities remain the same.

Cardinality Effect of Merging Events The cardinality between Disburse Cash and Supplier and Employee (as payee) is now 0 to 1, that is, a disbursement can be made to the supplier or the employee but not both!

Rules for Creating Integrated REA Diagram Every event must be linked to at least one resource. Every event must be linked to two agents who participate in that event. Every event that involves the disposition of a resource must be linked to an event that involves the acquisition of a resource. Every resource must be linked to at least one event that increments that resource and to at least one event that decrements that resource. If event A can be linked to more than one other event, but cannot be linked simultaneously to all of those other events, then the REA diagram should show that event A is linked to a minimum of 0 of each of those other events.

Using REA Diagram to Create Relational Database Advantage: Creating a set of tables from an REA diagram automatically results in a well- structured relational database Ensures the elimination of anomalies: Update Insert Delete

REA to Database Steps Create a table for each distinct entity in the diagram and for each many-to-many relationship. Assign attributes to appropriate tables. Identify primary keys: Attributes that uniquely identifies each record. For M:N relationships the primary key consists of two attributes that represent the primary keys of each entity linked in that relationship. Identify remaining attributes for table. Use foreign keys to implement one-to-one and one-to-many relationships. An attribute of one entity that is itself the primary key of another entity.

Our integrated diagram has seven event entities. 5 1 6 2 3 7 4 Our integrated diagram has seven event entities.

Our integrated diagram has two resource entities. 1 2 Our integrated diagram has two resource entities.

2 1 3 3 1 2 3 3 There are three distinct agent entities. The first is the customer. The second agent entity is the supplier. 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. 3 3

IMPLEMENTING AN REA DIAGRAM IN A RELATIONAL DATABASE Total distinct entities to be represented in separate tables:

IMPLEMENTING AN REA DIAGRAM IN A RELATIONAL DATABASE Create a separate table to represent each many-to-many relationship in the conceptual model, I.e., for the following participation cardinality patterns (0,N)-(0,N) (0,N)-(1,N) (1,N)-(0,N) (1,N)-(1,N) You must create a separate table to represent the relationship The primary keys of the related entity tables are posted into the relationship table to form its primary key. This kind of primary key is called a composite or concatenated primary key There are no exceptions to this rule!!! If you post a foreign key in either direction, redundancy will be a problem for many-to-many relationships

Example: Many-Many Relationships(from DCH) Student# Name Address 1 Tony Cleveland 2 Emily New York 3 Leigh Birmingham Course# * Acg4401, Acg3101 Course# Name Acg4401 AIS Acg3101 FAR 1 Student#* 1, 2, 3 Note: Each record field must be single valued(no repeating groups)

Example: Many-Many Relationship (from DCH) Student# Name Address 1 Tony Cleveland 2 Emily New York 3 Leigh Birmingham Student# Course# 1 Acg4401 Acg3101 2 3 Course# Name Acg4401 AIS Acg3101 FAR 1 Student-Course Relationship Table

the many-to-many relationships. 3 1 2 4 5 the many-to-many relationships.

IMPLEMENTING AN REA DIAGRAM IN A RELATIONAL DATABASE Total number of tables in database: Table Types # Events 8 Resources 2 Agents 3 Distinct Entities 12 Many to many Tables 5 Total Tables 17

IMPLEMENTING AN REA DIAGRAM IN A 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 of two attributes that represent the primary key of each linked entity. These multiple-attribute primary keys are called concatenated keys.

Attribute assignment

Use foreign keys to implement one-to- one and one-to-many relationships. Minimum cardinalities may suggest which choice is more efficient. When there are two sequential events, the primary key of the event that occurs first is usually the foreign key in the event that occurs second. The primary key of the entity that can linked to multiple instances of the other entity must become the foreign key in that other entity. Example: The primary key for customer (which can occur only once per sale) is a foreign key in the sales table (which can occur many times for a particular customer).

Example: (1,1)-(1,1) Cash Receipt Sale (1,1) yields SaleID Date Amount CR-ID Could do either one but because the entities represent sequential events, authors follow the practice of placing the primary key of the event that occurs first (sale) as a foreign key in the event that occurs second (cash receipt). SaleID Date Amount S1 6/12 $10 S2 $15 S3 6/13 $12 CR-ID * CR1 CR2 CR3 CR-ID Date Amount CR1 6/12 $10 CR2 $15 CR3 6/13 $12 S-ID * S1 S2 S3

Example 2: Posting into a (1,1)-(0,1) Sale Cash Receipt yields (1,1) (0,1) SaleID Date Amount CR-ID SaleID Date Amount S1 6/12 $10 S2 $15 S3 6/13 $12 CR-ID* CR1 CR2 CR3 This eliminates null values CR-ID Date Amount CR1 6/12 $10 CR2 $15 CR3 6/13 $12 CR4 $1,000 S-ID* S1 S2 S3

Example : Posting into a one to many Sale Customer Is-to (1,1) (0,N) SaleID Date Amount CustID Name City SaleID Date Amount S1 6/12 $10 S2 $15 S3 6/13 $12 Cust-ID* C1 C2 Cincinnati Steven C2 Walnut Creek Heather C1 Address Name Cust-ID S2 S1, S3 S-ID* C3 Dave Cincinnati

Use foreign keys to implement one-to-one and one-to-many relationships

Use foreign keys to implement one-to-one and one-to-many relationships

Foreign key (field property required or not required) If minimum cardinality for foreign key posting is 1(mandatory), field property attribute should be set to required The six circled foreign key attributes field property should be set to required in the database table to avoid possibility of null value

Foreign keys in bold red should have property attribute set to required to avoid null value.

Foreign key (required or not required) Cardinalities indicate that Customer participation in relationship is mandatory. Since it is mandatory, to avoid possible null value, make this attribute required in the sales table

There are 4 relationship attributes. If relationship becomes a separate table, then relationship attributes are placed in that table If relationship established via foreign key, attribute placed in table with foreign key

Relationship attributes

Retrieving Information from REA Database Journals Information contained in event tables Ledgers Information contained in resource tables Financial statements Information contained in resources and Information on imbalances Accounts receivable Sales transactions for which customer payments have not yet been received Accounts payable Purchases from suppliers that have not yet been paid for