A Structured Approach To Teaching Cardinalities In The AIS Class

Abstract

Cardinalities specify business rules as part of a conceptual schema. This paper presents a structured approach to teaching cardinalities in the accounting information systems (AIS) class. First, cardinalities are explained – why they are important, what they are and what notations exist to define them. Next, a three-step approach to teaching cardinalities is presented: syntactic, semantic and heuristic. Visual and syntactic representations help students understand the cardinality concept and cardinality notation. During the semantic phase, students learn to define business rules in terms of cardinalities. Heuristics help students recognize domain-specific stereotypical cardinality patterns. Such a generalization requires the existence of a semantic framework, and the REA model is used to define cardinality heuristics for enterprise systems. Finally, inter-relationship constraints, which represent participation dependencies across two or more relationships, are discussed. Introduction he data modeling approach to accounting information systems (AIS) has become increasingly popular among AIS educators (Hollander et al., 2000; Romney and Steinbart, 2003). Data models are used for the specification of conceptual schemas which represent a specific portion of reality. Conceptual schemas have a dual role (Taylor, 1990; Batini et al., 1992; Teorey, 1994; Jacobson et al., 1995; Eriksson and Penker, 2000). First, they provide a definition of the enterprise model; that is, the description of the phenomena to be captured in the information system such as the economic activities of a company. Second, they provide a starting point for the actual design of the information system. A data model provides a set of modeling constructs such as entity, relationship and cardinality to define conceptual schemas. Entities depict the basic things that need to be represented in the information system, and relationships depict associations among two or more entities. Cardinalities define participation constraints for relationships and have two specific roles: (1) they are used to primarily define business rules as part of the enterprise model specifications, and (2) they can be used as part of a top-down normalization process during the actual design of the information system (Nijssen and Halpin, 1989; Batini et al., 1992). The objective of this paper is to present a structured approach for teaching students how to use cardinalities to define business rules as part of the enterprise model. What are cardinalities? Romney and Steinbart (2003) define cardinalities as follows: “Cardinalities indicate how many instances of one entity can be linked to one specific instance of another entity” (p.123). Stated differently, cardinalities express constraints on the participation of instances of an entity in a relationship. There are two different types of constraints and thus two different types of cardinalities: the minimum cardinality and the maximum cardinality. A minimum cardinality defines whether an instance has to participate in a relationship. If “yes,” the participation is mandatory. If “no,” the participation is optional. Therefore, the minimum cardinality defines a dependency. Put another way, the following question arises: can an instance exist without participating in the relationship? “Yes” means that participation is optional while “no” means that participation is mandatory. The maximum cardinality defines the number of times an instance can participate in a relationship. A constraint exists if an instance can participate only once in a relationship. No constraint exists if an instance can participate many times in a relationship. Figure 1 illustrates the definition of cardinalities using the Batini et al. (1992) notation. Both a minimum and a maximum cardinality are defined for each entity that participates in the relationship. Binary relationships, like the one in Figure 1, connect two entities and thus have four cardinalities defined. Instances of entity A do not have to participate in the relationship (MIN: “O”), but if they do, they can participate only once T The Review of Business Information Systems Volume 8, Number 4