Database Design Using the REA Data Model

Learning Objectives

This section introduces the foundational concepts for designing and implementing database systems in accounting, with a focus on the REA (Resources-Events-Agents) data model. Students will learn to interpret entity-relationship diagrams and understand their application in accounting information systems (AIS).

• Design and Implementation Steps: Overview of the process for creating a database system tailored to organizational needs.

• Entity-Relationship (E-R) Diagrams: Explanation of graphical tools for modeling relationships between entities.

• REA Data Model: Introduction to the structure and purpose of the REA model in accounting.

• REA Diagram Interpretation: Guidance on reading REA diagrams to understand business activities and policies.

Database Design Process

Phases of Database Design

The database design process consists of several key phases, each contributing to the development of a robust accounting information system.

• Systems Analysis: Identifying organizational requirements and processes.

• Conceptual Design: Creating high-level models of data and relationships (data modeling occurs here).

• Physical Design: Translating conceptual models into actual database structures.

• Implementation and Conversion: Building and deploying the database system.

• Operation and Maintenance: Ongoing use and refinement of the database.

Data Modeling

Purpose and Methods

Data modeling is the process of defining a database so that it accurately represents all aspects of the organization, including its interactions with the external environment.

• Entity-Relationship (E-R) Diagrams: Visual representations of entities and their relationships.

• REA Data Model: A specialized E-R model for accounting information systems.

Entity-Relationship Diagrams

Definition and Application

Entity-Relationship (E-R) diagrams are graphical tools used to illustrate the relationships between entities within a database. They are essential for understanding and designing AIS databases.

• Entity: Anything the organization wants to collect and store information about (e.g., customers, inventory).

• Relationship: The way entities interact or are associated with each other.

• REA Diagrams: E-R diagrams specifically designed for accounting information systems, focusing on resources, events, and agents.

REA Modeling

Components of the REA Model

The REA data model is a framework for designing accounting databases by categorizing information into three main components: resources, events, and agents.

• Resources: Items of economic value to the organization, such as inventory or cash.

• Events: Business activities that management wants to track (e.g., sales, purchases).

• Agents: Individuals or organizations participating in events, both internal (employees) and external (customers, vendors).

REA Basic Template

Structure of REA Relationships

The basic REA template illustrates the flow of resources and participation of agents in business events, emphasizing the concept of economic duality (give-get exchange).

Additional info: The economic duality concept ensures that every transaction involves both a sacrifice and an acquisition of resources.

Creating an REA Model

Steps in REA Modeling

Developing an REA model involves identifying key events, resources, and agents, and determining the nature of their relationships.

• Identify Relevant Events: Focus on give-get exchanges that represent economic duality.

• Identify Resources and Agents: Determine which resources are affected and which agents participate in each event.

• Determine Cardinalities: Specify the nature of relationships between entities, such as one-to-one, one-to-many, or many-to-many.

Cardinality Notation Methods

Representing Relationships

Cardinality defines the numerical relationships between entities in a database. Several notation methods are used to represent cardinalities in diagrams.

• Graphical Symbols: Visual indicators of minimum and maximum cardinalities.

• (Min, Max) Notation: Pairs indicating the minimum and maximum number of times an entity can participate in a relationship.

• UML Notation: Unified Modeling Language pairs for cardinality.

• Maximums Only (Microsoft Access): Only the maximum cardinality is shown.

Example: In a sales transaction, one customer (agent) can place many orders (events), but each order is placed by only one customer. This is a one-to-many (1:N) relationship.

Key Terms

Glossary of Concepts

Understanding the following key terms is essential for mastering database design in accounting information systems.

• Data Modeling: The process of creating a data structure that represents organizational information.

• Entity-Relationship (E-R) Diagram: A graphical representation of entities and their relationships.

• REA Data Model: A framework for modeling accounting databases using resources, events, and agents.

• Resources: Economic assets tracked by the organization.

• Events: Business activities or transactions.

• Agents: Individuals or organizations involved in events.

• Cardinalities: Numerical relationships between entities.

• Minimum Cardinality: The least number of times an entity can participate in a relationship.

• Maximum Cardinality: The greatest number of times an entity can participate in a relationship.

• One-to-One (1:1) Relationship: Each entity in the relationship is associated with only one entity of the other type.

• One-to-Many (1:N) Relationship: One entity is associated with multiple entities of the other type.

• Many-to-Many (M:N) Relationship: Multiple entities are associated with multiple entities of the other type.

Formulas and Notation

Cardinality Representation

• Minimum-Maximum Notation:

• Example: A customer can place between 1 and many orders: