Month Year Issue

February 2001 Issue: 18

Journal of Conceptual Modeling
www.inconcept.com/jcm

An ORM metamodel of Information Engineering
by Dr. Terry Halpin

Abstract

This article provides a basic ORM metamodel for the Information Engineering (IE) notation, one of the most popular notations in use for Entity-Relationship (ER) modeling. This article aims to clarify the IE notation for those familiar with ORM, and also to contribute towards efforts to provide transformation between the notations. There are many ways to metamodel IE, and the model discussed here is simply one suggestion. If you have any suggestions for improvement, please email me at TerryHa@Microsoft.com, express your opinions to the JCM discussion group, or consider submitting your own metamodel to the JCM.

Introduction

The Information Engineering (IE) approach to information modeling began with the work of Clive Finkelstein in Australia, and CACI in the United Kingdom. Finkelstein developed a modeling procedure for the notation and extended IE to Enterprise Engineering (EE). See Finkelstein (1989) for the basic concepts and history of IE, Finkelstein (1992) for practical advice on IE and entity dependency, and Finkelstein (1998) for an overview of IE. You can access Finkelstein's website at www.ies.aust.com/~ieinfo/.

The IE notation was later adapted by James Martin (Martin 1993). Although Martin's recent books favor the UML notation, IE is still used far more extensively for database design than UML, which is mostly used for object-oriented code design. Different versions of IE exist, with no single standard. In one form or other, IE has long been supported by many data modeling tools, and remains one of the most popular notations used in industry for database design.

A previous article for the Journal of Conceptual Modeling (Halpin 2000a) discussed the IE notation from the perspective of Object Role Modeling (ORM), and a more thorough treatment of this topic will appear in my next book (Halpin 2001). The best way to develop an IE model is to first develop the model in ORM, and then map it to an IE model, supplemented as needed by a textual description of business rules from the ORM model that cannot be captured graphically in IE. An ORM metamodel for the semantics underlying the IE notation can inform such a mapping, and clarify IE for those familiar with ORM. The metamodel presented here provides one of many possible ways to model the IE notation. Feedback and alternative suggestions are welcome.

Entity types and attributes

The IE approach depicts entity types as named rectangles. Attributes are often displayed in a compartment below the entity type name, as in Figure 1, but are sometimes displayed separately (e.g. bubble charts). Some versions support basic constraints on attributes. For example, an attribute that is part of its entity type's primary identifier might be underlined, and whether an attribute is mandatory might be recorded off the diagram. Although no standard notation exists for these constraints, I'll include them in the metamodel.

Figure 1 Entity type and attributes

Assuming that it is recorded whether an attribute is mandatory, and that primary identifier attributes must be mandatory, one way of metamodeling this IE fragment in ORM is shown in Figure 2. This assumes a closed world approach to the unary predicate "is mandatory" (i.e. if the attribute is not recorded to be mandatory, then it is known to be optional). The external uniqueness constraint (circled "u") indicates that an attribute may be identified by combining its unqualified name with its entity type. The subset constraint (circled "Í") indicates that the population of the lower role must be a subset of the upper role (i.e. if an attribute is a primary identifier component then it must be mandatory). The subset constraint may also be displayed simply as a dotted arrow.

Figure 2 An ORM metamodel fragment of IE based on Figure 1

Relationships (associations)

Relationships are typically restricted to binary associations only, which are shown as named lines connecting the entity types. I'll use the term "role" instead of "relationship end". Relationship names are read left-to-right and top-to-bottom. To avoid confusion with other kinds of relationship, I'll use the term "association" for an elementary, binary relationship type. A half-line or line-end corresponds to a role in ORM. To indicate that a role is optional, a circle "O" is placed at the other end of the line, signifying a minimum participation frequency of 0. To indicate that a role is mandatory, a stroke "|" is placed at the other end of the line, signifying a minimum participation frequency of 1. A crows-foot is used for a cardinality of "many".

In conjunction with a minimum frequency of 0 or 1, a stroke "|" is often used to indicate a maximum frequency of 1. With this arrangement, the combination "O|" indicates "at most one" and the combination "| |" indicates "exactly one". This is the convention that I use here (see Figure 3). Some IE notations assume a maximum cardinality of 1 if no crows foot is used, and hence use just a single "|" for "exactly one". Finkelstein uses the combination "O|" to mean "optional but will become mandatory", which is really a dynamic rather than static constraint-this is excluded from our metamodel.

Figure 3 Binary associations, with minimum and maximum participation frequencies

One way of metamodeling this is shown in Figure 4. Here I've identified both roles and associations by numbers (whose display is normally suppressed). Roles could also be identified by their position within a standard ordering of an association.

Figure 4 One way of metamodeling binary associations and their participation frequencies

IE typically allows only one reading per association, which must be read left-to-right or top-to-bottom. This restriction complicates cases where the association direction is changed in the diagram layout. In the metamodel fragment shown, association names are catered for by attaching the predicate text to the role from which the association is read. The equality constraint shown here as a circled "=" may also be depicted by a dotted line with arrow-tips at both ends.

In Figure 4, "Frequency" means participation frequency. Here, the "<<" indicates that the predicate is read in that direction (here right-to-left). The use of "<<" allows the display of a centered, single reading for a binary association, where the default reading direction is left-to-right or top-to-bottom. So the frequency fact types are read: Role has minimum- Frequency; Role has maximum- Frequency. The hyphen binds the adjective to the object type term for constraint verbalization. So the uniqueness and mandatory constraints collectively verbalize as: each Role has exactly one minimum Frequency; each Role has exactly one maximum Frequency.

In our metamodel, each association role must be annotated by one of the four frequency patterns shown at the right of Figure 3. The minimum frequency must be 0 or 1, and the maximum frequency must be 1 or many (denoted here by "n"). These constraints are depicted here as role-based value constraints {'0', '1'} and {'1', 'n'} attached by dotted lines to the relevant roles. Although current ORM tools restrict value constraints to object types (e.g. {'0', '1', 'n'} for Frequency), we might extend our tool support for ORM to include role-based value constraints like those shown here. Alternatively, this situation can be modeled with object value constraints by using the fact types: Role has MinimumFrequency {'0', '1'}; Role has MaximumFrequency {'1','n'}. But this alternative makes it awkward to compare minimum and maximum frequencies, since this must now be done at the lexical level. There are other ways to model participation frequencies, but Figure 4's approach is probably closest to the way IE modelers actually think about them.

Some versions of IE support an exclusive-or constraint, shown as a black dot connected to the alternatives. The example in Figure 5 depicts the situations where each employee is allocated a bus pass or a parking bay, but not both.

Figure 5 Exclusive-or constraint

Underlying this example, there are two associations: Employee is allocated BusPass; Employee is allocated ParkingBay. The exclusive-or constraint may now be viewed as applying to the first roles of these two associations. If the predicate reading must be displayed before the dot, the xor constraint can apply only to roles from associations with the same predicate text. So we can't express an xor constraint such as: each Employee drives a Car or catches a Bus but not both. This restriction does not apply to Barker ER, UML or ORM. In IE (and Barker ER) the same association role can be spanned by at most one exclusive-or constraint. This restriction does not apply to ORM or to UML.

Figure 6 Metamodel for exclusive-or constraints in IE

One way of metamodeling IE exclusive-or constraints is shown in Figure 6. Here each xor constraint is identified by a constraint number. The subtype OptionalRole restricts Role to roles that are optional (i.e. it is possible some instances of their object type do not play the role)-this is the same as an optional role in ORM. If relevant, further restrictions on the constrained roles (e.g. that they must belong to associations with the same predicate text) can be specified textually in ConQuer.

Subtyping

Subtyping schemes for IE vary (see Figure 7). Sometimes Euler diagrams are used, adding a blank compartment for "Other". Sometimes directed acyclic graphs are used, possibly including subtype relationship names and participation frequency constraints. There is no formal support for subtype definitions. Multiple inheritance may or may not be supported, depending on the version.

Figure 7 Some different IE notations for partitioning A into the subtypes B and C

A basic metamodel for IE subtyping is shown in Figure 8. This allows for multiple inheritance as well as incomplete sets of subtypes. Single inheritance can be enforced by strengthening the uniqueness constraint to apply to just the first role (so the association becomes n:1). If more than one subtype must be introduced, this can be enforced by adding the frequency constraint "³ 2" to the second role.

Figure 8 Basic metamodel for subtyping Conclusion

A global metamodel for IE can be obtained by combining the various metamodel fragments given earlier. In terms of graphical constraints for data modeling, IE is weaker than Barker ER or UML, which are both far weaker than ORM in this regard. Nevertheless, IE does a good job of expressing basic constraints, and its simplicity has helped it to remain popular as a notation for database design.

References

Finkelstein, C. 1989, Introduction to Information Engineering, Addison-Wesley, Reading MA.

Finkelstein, C. 1992, Information Engineering: Strategic Systems Development, Addison-Wesley, Reading MA.

Finkelstein, C. 1998, 'Information engineering methodology', Handbook on Architectures of Information Systems, eds. P. Bernus, K. Mertins & G. Schmidt, Springer-Verlag, Berlin, Germany, pp. 405-427.

Halpin, T.A. 2000a, 'Entity Relationship modeling from an ORM perspective: Part 3', Journal of Conceptual Modeling, no. 13, InConcept, online at www.inconcept.com.

Halpin, T.A. 2000b, 'An ORM metamodel', Journal of Conceptual Modeling, no. 16, InConcept, online at www.inconcept.com.

Halpin, T.A. 2001, Information Modeling and Relational Databases, Morgan Kaufmann, San Francisco (available March, 2001).

Martin, J. 1993, Principles of Object Oriented Analysis and Design, Prentice Hall, Englewood Cliffs, NJ.

Dr Terry Halpin, BSc, DipEd, BA, MLitStud, PhD, is a Program Manager in Database Modeling for the Enterprise Frameworks and Tools Unit, Microsoft Corporation, USA., Seattle WA, USA. During a lengthy career as an academic in computer science, he also worked in industry on database modeling technology and as a data modeling consultant. His recent positions include head of database research at Asymetrix Corporation, and research director of InfoModelers Inc., which was acquired by Visio Corporation. For several years, his research has focused on conceptual modeling and conceptual query technology for information systems, using a business rules approach. Dr Halpin has presented papers and tutorials at many international conferences. His doctoral thesis provided the first full formalization of Object-Role Modeling (ORM/NIAM), and his publications include over ninety technical papers, as well as four books, including Information Modeling and Relational Databases (Morgan Kaufmann, 2001).

Contact Information:

Dr Terry Halpin
Program Manager, Database Modeling
Enterprise Framework & Tools Unit, Microsoft Corporation
One Microsoft Way
Redmond WA 98052-6399 (USA)
terryha@microsoft.com
(425) 705 9190
fax: (425) 936 7329
http://www.orm.net