December 2000        Issue: 17

Journal of Conceptual Modeling
www.inconcept.com/jcm

An ORM Metamodel of Barker ER
by Dr. Terry Halpin

 Abstract

This article provides a basic ORM metamodel for the Barker version of Entity-Relationship (ER) modeling, as discussed in Barker (1990). Traditionally used in CASE tools supported by Oracle Corporation, this notation is still one of the most widely used for ER. This article aims to clarify the Barker notation for those familiar with ORM, and also to contribute towards efforts to provide transformation between the notations. There are many ways to metamodel Barker ER, 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 term "Barker ER notation" is used here to denote the notation for Entity Relationship (ER) modeling discussed in the classic treatment by Richard Barker (Barker, 1990). Originating at CACI in the United Kingdom, the notation was later adopted by Oracle Corporation in its CASE design tools. Although Oracle now supports UML class diagrams as an alternative to the traditional ER notation, for database applications many modelers still prefer the Barker notation. Two previous articles for the Journal of Conceptual Modeling (Halpin 2000a, 2000b) discussed the Barker ER 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).

These publications argue that the best way to develop an ER model in Barker notation is to first develop the model in ORM, and then map it to a model in Barker notation, supplemented where necessary by a textual description of business rules expressed in the ORM model that cannot be captured graphically in the Barker notation. An ORM metamodel for the semantics underlying the Barker notation can assist with such a mapping, and also clarify Barker ER for those familiar with ORM. The metamodel presented here provides one of many possible ways to model Barker ER. Feedback and alternative suggestions are encouraged.

Entity types and attributes

Figure 1 summarizes the Barker notation for an entity type and its attributes. To avoid confusion, the term "entity type" is used instead of Barker's "entity".

Figure 1 Entity type and attributes

Figure 2 An ORM metamodel fragment of Barker ER based on Figure 1

One way of metamodeling this ER fragment is shown in Figure 2. An entity type is identified by its name. An attribute is identified by combining its (local) name with the name of its entity type. Each attribute has an optionality of Ma (Mandatory) or Op (Optional). The fact type Attribute has Optionality may also be modeled by the two unary fact types Attribute is mandatory, Attribute is optional, with an exclusive-or constraint between them. If an attribute is the primary identifier of an entity type, or a component of its primary identification scheme, this is captured by the unary fact type Attribute is a primary identifier component. I'll revise this part of the schema later. Although the Barker version of ER allows alternate identifiers to be specified, this cannot be shown in the ER diagram notation, and I've ignored it here. If you look at the ORM metamodel in my previous article (Halpin 2000c), it should be obvious how to cater for this.

Although the domains on which attributes are based can't be shown on the ER diagram, Barker includes them in his metamodel. He also allows a list of possible values to be declared for either a domain or an attribute. A basic metamodel for this is shown in Figure 3. This can be extended to cater for combinations of value sets and value ranges, as in my ORM metamodel (Halpin 2000c). Currently ORM supports value constraints on object types (domains) only. To cater for value constraints on attributes, ORM would need to be extended to allow value constraints on roles. We are currently considering this extension for ORM at Microsoft. If you have run into practical situations where you needed to specify role-based value constraints, and would like this constraint added to our ORM support, please let me know.

Figure 3 Value lists may be declared for both domains and attributes

Relationships

In Barker ER, the term "relationship" denotes a binary relationship type. To avoid confusion with other senses of relationship (e.g. foreign key dependencies), and to harmonize with UML, I'll use the term "Association" for an ORM or ER relationship type. Figure 4 summarizes the basic constructs.

Figure 4 Binary associations, mandatory role constraints and cardinality constraints

A binary association is shown as a straight line connecting its entity type(s). The line is conceptually divided into two halves, one for each role (in the ORM sense). I'll use the term "role" instead of "relationship end". Each role has predicate text to indicate how to read the association from that end. These forward and inverse readings are displayed beside their role, on opposite sides of the line. A mandatory role appears as a solid line, and an optional role as a dashed line. A cardinality constraint (also called "degree") appears on each role. The crow's foot symbol indicates "many" and the absence of the crow's foot indicates 1. In the example shown, each employee occupies exactly one room, and each room is occupied by zero or more employees. The notation also allows for a crow's foot to be annotated by a qualified cardinality, shown as a single positive number qualified by an operator (<, >, <=, >=). Instead of allowing an explicit "=" as an operator, I'll assume this is assumed by the absence of an operator. In the Figure 4 example, the left hand entity type is associated with at most five instances of the right-hand entity type, and the right-hand entity type is associated with exactly two instances of the left-hand entity type.

One way of metamodeling this is shown in Figure 5. Here I've identified both roles and associations by numbers (whose display is normally suppressed). It is unclear whether the Barker notation allows both roles in the same association to have the same predicate text (e.g. for a symmetric association). If it doesn't allow this, we could also identify a role by combining its predicate text with its association (add the relevant external uniqueness constraint). Roles could also be identified by their position within a standard ordering of an association. If a role has no cardinality limit stored, then "many" is assumed. Some additional metaconstraints on cardinality are ignored here. This approach to cardinality is very limited in comparison with that of ORM, which allows frequency ranges over arbitrary sets of roles.

Figure 5 One way of metamodeling the constructs in Figure 4

One additional feature in the Barker ER notation that is not supported in ORM is the "non-transferable relationship", indicated by a diamond on the relevant role. For example, the diamond in Figure 6(a) indicates that once a person is recorded as being born in a given country, we cannot change their birth-country to another country. Since we usually wish to allow editing of mistaken entries, this constraint has limited practical application. If you have found this constraint useful in practice, and would like to see it added to our ORM support, please let me know.

Figure 6 Non-transferable roles (a) may be metamodeled as in (b)

The Barker notation includes an exclusive-arc to declare an exclusion constraint over a set of roles played by the same object type. If the roles have solid lines, this means the roles are also disjunctively mandatory (see Figure 7).

Figure 7 An exclusive-arc provides a limited form of the exclusion constraint

This may be metamodeled as shown in Figure 8. I've identified the exclusive-arc constraint by a number (as I did for constraints in ORM). Note the uniqueness constraint: each role is spanned by at most one exclusive-arc. ORM has no such restriction, since there are many practical cases where a role may be constrained by more than one exclusion constraint.

Figure 8 Metamodel for exclusive arcs

Subtyping

Subtyping in the Barker ER notation is summarized in Figure 9. Only single-inheritance is allowed (each subtype has only one supertype). Moreover, the union of the subtypes must equal the supertype, even if we have to introduce an artificial subtype such as "Other" to ensure this.

Figure 9 In Barker ER, subtyping always involves a partition (exclusive and exhaustive)

Figure 10 Metamodel for subtyping in Barker ER

Figure 10 depicts the relevant metamodel fragment for subtyping. The frequency constraint on the supertype role assumes that a complete subtype partition is specified.

Identification schemes for entity types

Now let's examine reference schemes in the Barker ER notation. An example based on a simplified version of a model from Barker (1990, p. J-1) is shown in Figure 11. Notice the stroke "|" across the three roles played by LineItem. This indicates that the roles are used in the identification scheme for LineItem. For any given instance of LineItem, the relationship to Order must be used as part of the reference scheme. Notice the exclusive arc across LineItem's roles to Product and Service. To complete the identification of the line item, the order relationship must be combined with a relationship to a product or service (but not both).

Figure 11 A line item is identified by an order number plus either a product code or a service code

An ORM model for the reference scheme of LineItem is shown in Figure 12. The external uniqueness constraint provides the identification. Notice that this is an example of a disjunctive reference.

Figure 12 An ORM model for the LineItem identification scheme in Figure 11

Barker ER goes further than some other ER versions in allowing such limited kinds of disjunctive reference. It allows an entity type to be identified by a combination of one or more attributes, roles or exclusive role-disjunctions. This may be metamodeled as shown in Figure 13.

Figure 13 Metamodel of reference schemes in Barker ER

Notice the use of ORM's inclusive-or constraint here (circled "·"). Barker ER has no such constraint, so must resort to introducing additional intermediate object types to achieve the same effect indirectly (Barker 1990, p. H-2). Also note that this notion of disjunctive reference is less flexible than ORM's, which also caters for cases where the disjunctions are not exclusive. Such cases arise in practical situations, such as naming schemes for botanical specimens (Halpin 2001, section 5.4). The tratment of attribute reference in this figure replaces the unary fact type in Figure 2.

The global metamodel

I leave it as an easy exercise to combine the various schema fragments into a global model of Barker ER. An alternative metamodel of Barker ER can be obtained by starting with an ORM metamodel, adding the two notions of role-based value constraints and non-transferable roles, and then applying lots of restrictions.

For those who prefer the Barker ER notation to ORM, Barker (1990, p. H-2) presents a basic ER metamodel for Barker ER. Although mostly correct, it is substantially incomplete (e.g. it ignores various features, constraints and identification schemes), and also contains errors (e.g. it allows alternate keys but not overlapping keys, and it forbids any value from belonging to both a domain and an attribute population). It also allows entity types that have no identification scheme: although this is reasonable for storing incomplete models, identification schemes are required for complete models, and play a vital role in ORM's analysis procedure which makes substantial use of fact populations. The ORM metamodel of Barker ER discussed in this article requires each entity type to have an identification scheme.

References

 

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

© Copyright, 1998-2004 InConcept (Information Conceptual Modeling, Inc.) All Rights Reserved. Privacy Statement.
ISSN: 1533-3825