Research Note: Ontology-Based Structuring of Conceptual Data Modeling Patterns

Research Note: Ontology-Based Structuring of Conceptual Data Modeling Patterns

Wim Laurier, Geert Poels
Copyright: © 2012 |Pages: 15
DOI: 10.4018/jdm.2012070103
OnDemand:
(Individual Articles)
Available
$37.50
No Current Special Offers
TOTAL SAVINGS: $37.50

Abstract

This research note shows that the scope of conceptual data modeling patterns can be identified, clarified, and explicitly represented by positioning them into an ontology-based framework. A clear and explicit definition of scope could help deciding which patterns match which parts of the domain to be represented. The authors demonstrate their argument by positioning existing conceptual data modeling patterns into a two-dimensional structuring framework that is constructed using two ontology-derived ‘benchmark’ patterns: an enterprise pattern for representing transactions (derived from the REA domain ontology) and an abstraction pattern for representing reality at different levels of abstraction (derived from the UFO foundational ontology). By means of an application scenario dealing with the conceptual design of a transactional enterprise database, the authors illustrate how the framework can be used to evaluate the relevancy and completeness of candidate patterns with respect to the problem at hand.
Article Preview
Top

Introduction

Conceptual data modeling patterns are used to support the conceptual design of databases. A conceptual data modeling pattern describes a reproducible solution to a general conceptual database design problem, which can be applied to a specific context by customizing its classes, associations, and attributes (Batra, 2005; Reinhartz-Berger & Sturm, 2009).

Research has shown that the use of conceptual data modeling patterns increases the productivity of database designers, especially novice designers (Antony, Batra, & Santhanam, 2005). However, it has also been observed that the use of patterns stimulates the inclusion of superfluous concepts, which are copied from the selected pattern even if they are irrelevant for solving the problem (Batra & Wishart, 2004). This inclusion of irrelevant concepts is explained by the human tendency to anchor to an initial solution under uncertainty (e.g. lack of relevant modeling experiences for novices, unstable user requirements) (Tversky & Kahneman, 1974).

While the use of patterns might result in models with irrelevant elements, incompleteness is also frequently observed in conceptual data models (Moody & Shanks, 2003), meaning that the conceived model does not fully represent the domain concepts and relations that are deemed relevant for the database. To address this dual problem of irrelevancy and incompleteness in models requires being able to accurately assess the scope of the domain to be represented as well as that of the patterns that are used to guide the modeling process. Ideally, the scope of conceptual data modeling patterns is explicitly defined and represented when offering them to modelers, e.g., as part of a pattern catalogue or repository. An explicit indication of scope could help decide which patterns match which parts of the domain to be represented, and as such improve model relevancy and completeness.

As a solution to this problem, we propose an ontology-based framework to explicitly define the scope of conceptual data modeling patterns that are intended for a particular domain in terms of the generic domain knowledge that is captured by domain ontologies. Patterns can be positioned in this framework by ontologically classifying the elements they contain, which helps clarify their scope (i.e., what part of the domain they cover).

The structuring orientation (Dunn & McCarthy, 1997) capability of domain ontologies has already been shown to improve the understandability of models that are constructed using ontology-derived patterns (Poels, 2011). We believe ontologies can not only support the interpretation of patterns, but also the structuring of pattern catalogues and repositories, helping pattern developers organize their patterns and helping modelers find the patterns that are relevant to the problem at hand. The positioning of patterns in the framework is expected to mitigate relevancy and completeness errors as the framework then visualizes the parts of the domain for which a solution has been suggested (e.g., by a pattern from a catalogue) and the parts for which no solution has been presented yet.

Although many conceptual data modeling patterns have been proposed (Coad, North, & Mayfield, 1997; Fowler, 1997; Gamma, Helm, Johnson, & Vlissides, 1995; Hay, 1996), we have applied our ideas for an ontology-based structuring of conceptual data modeling patterns to Batra’s selection of patterns (Batra, 2005). Batra synthesizes earlier proposals of conceptual data modeling patterns, with a focus on patterns that can be used for the conceptual design of enterprise databases. He justifies his selection of patterns by showing that they occur frequently in three influential sources for conceptual data modeling: the enterprise reference models of Scheer (1998) and Silverston et al. (1997) and the casebook of Whitlock et al. (2003).

Complete Article List

Search this Journal:
Reset
Volume 35: 1 Issue (2024)
Volume 34: 3 Issues (2023)
Volume 33: 5 Issues (2022): 4 Released, 1 Forthcoming
Volume 32: 4 Issues (2021)
Volume 31: 4 Issues (2020)
Volume 30: 4 Issues (2019)
Volume 29: 4 Issues (2018)
Volume 28: 4 Issues (2017)
Volume 27: 4 Issues (2016)
Volume 26: 4 Issues (2015)
Volume 25: 4 Issues (2014)
Volume 24: 4 Issues (2013)
Volume 23: 4 Issues (2012)
Volume 22: 4 Issues (2011)
Volume 21: 4 Issues (2010)
Volume 20: 4 Issues (2009)
Volume 19: 4 Issues (2008)
Volume 18: 4 Issues (2007)
Volume 17: 4 Issues (2006)
Volume 16: 4 Issues (2005)
Volume 15: 4 Issues (2004)
Volume 14: 4 Issues (2003)
Volume 13: 4 Issues (2002)
Volume 12: 4 Issues (2001)
Volume 11: 4 Issues (2000)
Volume 10: 4 Issues (1999)
Volume 9: 4 Issues (1998)
Volume 8: 4 Issues (1997)
Volume 7: 4 Issues (1996)
Volume 6: 4 Issues (1995)
Volume 5: 4 Issues (1994)
Volume 4: 4 Issues (1993)
Volume 3: 4 Issues (1992)
Volume 2: 4 Issues (1991)
Volume 1: 2 Issues (1990)
View Complete Journal Contents Listing