Database Reference
In-Depth Information
examines the
usability
of various conceptual data modeling approaches, that is, research
that investigates human factors issues in conceptual data modeling. We review and analyze
this literature and suggest several new directions for further research.
BACKGROUND
The concept of
data modeling
has been used with a variety of different meanings
data modeling
within various areas of study and practice. However, within the organizational context the
core idea underlying all the defi nitions is the same: A data model is used for describing
entities
1
and their relationships within a real world domain. For example, McFadden, Hof-
fer, and Prescott (1999) defi ne a data model as “an abstract representation of the data about
entities, events, activities, and their associations within an organization”. A data model is
an abstraction and a simplifi cation of the domain it describes and thus, it always represents
a limited part of reality.
The main focus of this chapter,
conceptual
data modeling, requires further clarifi ca-
conceptual
tion. Based on the ANSI/SPARC defi nition, a conceptual data model is any model that is
independent of the underlying hardware and software. This means that using this defi nition,
models created using formalisms ranging from the relational model to the semantically rich
variants (Teorey, Yang & Fry, 1986) of Entity-Relationship modeling (Chen, 1976; Hull &
King, 1987) can be considered to be at the conceptual level. A more restrictive defi nition
of a conceptual model can be found in Batra and Davis (1992). They defi ne a conceptual
model as one that is capable of capturing the structure of the database along with the se-
mantic constraints into a model that is easy to understand, does not contain implementation
details, and can be used to communicate with users. A key criterion in the above defi nition
is
the independence of modeling from the implementation technology
. This means that in
order to be categorized as a conceptual model the representation must not be dependent on
the characteristics of the database technologies available (e.g., relational, object-oriented,
object-relational, network, or hierarchical).
We believe that both of the defi nitions presented above are, however, somewhat mis-
leading because a true conceptual data model should capture the essential data characteristics
of the
domain of interest
, and not necessarily the structure of the database. Thus, we defi ne
a conceptual data model as a set of constructs that can be used to create an abstraction of
reality, that is, a representation capable of capturing the data-oriented (as opposed to pro-
cess-oriented) aspects of a domain of interest in a manner that is unambiguous and easy to
understand for analysts, designers, and users alike. Note that this defi nition does not have any
references to a database structure. This is because we believe that not everything captured
in a representation created using a conceptual data model will (or needs to) be refl ected in
a database or the eventual system being developed.
Based on the above defi nition of conceptual data modeling, one can synthesize at least
fi ve different uses for conceptual data models (Batra, Hoffer & Bostrom, 1990; Cambell,
1992; Juhn & Naumann, 1985; Kung & Solvberg, 1986): 1) a communication tool between
analysts and users for the discovery (elicitation and representation) and validation stages
of the systems analysis process, 2) a mechanism that helps analysts understand the domain
of interest, 3) a formal conceptual foundation for organizational information systems at
various levels (a common accepted model of reality and a communication tool between IS
professionals, e.g., analysts and developers), 4) a foundation for applications developed by
conceptual
data modeling, requires further clarifi ca-
