June 2000                   Issue: 14

Journal of Conceptual Modeling
www.inconcept.com/jcm

Entity Relationship Modeling from an ORM perspective: Part 4
By Dr. Terry Halpin

Introduction

In the 1970s, the US Air Force began work on a program for Integrated Computer Aided Manufacturing (ICAM). This was the genesis of a family of IDEF modeling languages. The acronym " IDEF" originally denoted "ICAM DEFinition", but now stands for "Integration DEFinition", reflecting its possible use for exchanging information between different modeling languages. Rather than specifying one universal modeling language, the ICAM project defined the following languages for different tasks:

• IDEF0 activity modeling

• IDEF1 conceptual data modeling

• IDEF2 simulation modeling

Later, other languages were added, including:

• IDEF1X logical data modeling

• IDEF3 process modeling

• IDEF4 object-oriented software design

• IDEF5 knowledge engineering of enterprise ontologies

• IDEF1X97 logical data modeling with object-oriented extensions

The name "IDEF1X" stands for "IDEF1 eXtended". Although based on the conceptual IDEF1 language, IDEF1X was changed to focus on logical data modeling. Though regretted by some, the introduction of IDEF1X effectively spelled the end of IDEF1. Over time, IDEF3 subsumed much of IDEF2, and more recently IDEF5. Nowadays, IDEF0 and IDEF1X are the most popular IDEF languages. Both are supported in a variety of CASE tools, and are widely used in US government sectors, especially defense. The IDEF3 language is also used, though to a lesser extent.

IDEF1X is a hybrid language, combining some conceptual notions (e.g. entity, relationship) with relational database constructs (e.g. foreign keys). It was accepted as a standard by the National Institute of Standards and Technology (NIST) in 1993 [4]. A proposed successor called IDEF1X97 was approved in June 1998 by the IEEE-SA Standards Board [2]. Also known as IDEFobject, this extended IDEF1X with object-oriented features to make it suitable for implementation in object-oriented databases and programming languages, while maintaining compatibility with IDEF1X for implementation in relational databases. This backward compatibility gives IDEF1X97 one advantage over UML for adoption in US government sectors.

Nevertheless the future of IDEF1X97 is uncertain, since its object-oriented extensions are less encompassing than those in UML. Although UML is yet to be widely used for database design, it is by far the most widely used language for designing object-oriented code, it is supported by many CASE tools, and is being considered for standardization by the International Standards Organization (ISO). At the time of writing, few practitioners or tool vendors have expressed interest in adopting IDEF1X97. In contrast, the original 1993 version of the IDEF1X language continues to be very widely used for database design and is supported by many modeling tools, including Microsoft Visio Enterprise. For these reasons, I'll restrict my attention to the original IDEF1X in the rest of this article.

Three views

To model facts, IDEF1X uses the three main constructs of ER: entities, attributes and relationships. Unfortunately, the IDEF1X standard uses the term "entity" to mean "entity type", not "entity instance". Even more unfortunately, this misusage has been adopted by some practitioners. So you may have to use the word "instance" more than you want to, simply to ensure you are not misunderstood. Each entity type has one or more attributes, that are based on domains. A domain is a named set of data values of the same data type. Relationships are restricted to binary associations between entity types.

IDEF1X allows models to be developed in phases using at least three kinds of "view level": ER view; key-based view; and fully-attributed view. The essential differences between these views are summarized in Table 1. The ER view may be used early in the analysis but is very inexpressive compared with true ER. No identification schemes are specified for entity types, and no attributes need be declared. If attributes are specified, no constraints (e.g. mandatory) are declared for them.

An ER view in IDEF1X can be thought of as an incomplete sketch of an ER model. In principle, it could be refined into a true ER model. Unfortunately, instead of carrying out the refinement at the conceptual level, IDEF1X drops down to the logical level to add the extra detail. Any ER view must be resolved into a key-based view and ultimately a fully-attributed view to complete the model. Key-based views and fully-attributed views are similar to a relational model in many respects. Most CASE tools that support IDEF1X do not support its ER view, so I'll ignore the ER view from this point on.

Table 1 Three different views in IDEF1X

Entity types and attributes

In key-based and fully attributed views, IDEF1X entity types are basically relational tables, and the "relationships" are all foreign key to primary key references. A foreign key is a set of one or more attributes whose values (possibly composite) must occur as a value of some primary key. The source or referencing entity (type) is called the child and the target or referenced entity (type) is called the parent. The relationships may be assigned forward and inverse readings as if they were conceptual associations or subtype links. However they ultimately represent subset constraints. The actual facts are all stored in attributes, as in the relational model.

An entity type is classified as identifier-independent or identifier-dependent. An entity type is identifier-independent if and only if its identifier does not depend on other entity types. In other words, its identification scheme does not include a conceptual relationship to another entity type. In terms of keys, this means that an entity type is identifier-independent if and only if its primary key has no component that is a (complete) foreign key-its primary key may however contain an attribute that is just part of a foreign key. Otherwise the entity type is identifier-dependent. The terms "identifier-independent" and "identifier-dependent" are often shortened to "independent" and "dependent". This notion of "independent" has nothing to do with the notion of independent object types in ORM.

In IDEF1X, an independent entity (type) is depicted as a hard rectangle (square corners), with its name written above, as shown in Figure 1(a). A dependent entity type is depicted as a soft rectangle (rounded corners), as shown in Figure 1(b).

Figure 1 An independent entity type (a) and a dependent entity type (b)

Attributes of an entity type are listed inside its rectangle. Primary key attributes appear in the top compartment. These provide the primary identification scheme for the entity type. Alternate keys are marked by appending "(AKn)", where n > 0. These provide an alternate identification scheme. If an alternate key has two or more components, each component has the same value for n. Different alternate keys must have different values for n. Foreign keys are indicated by appending "(FK)". Attributes are mandatory by default. To show that an attribute is optional, "(O)" is appended. All attributes are single-valued.

In Figure 2, empNr is the primary key of Employee and the bldgNr, roomNr pair provides the composite primary key for Room. The social security number attribute (ssn) is an alternate key for Employee. In Employee, the pair bldgNr, roomNr is a foreign key (referencing the primary key of Room). In Room, bldgNr is a foreign key (referencing the primary key of a Building entity type not shown here). All attributes are mandatory except for fax and phoneNr, which are marked optional.

Figure 2 Attributes with key (primary, alternate and foreign) and optional indicators

"Relationships"

In all views, relationships are binary only. In the ER view, relationships are conceptual associations and may be "non-specific" (many-to-many). In key-based and fully-attributed views, each "relationship" is either a "connection" (foreign key to primary key reference) or a categorization (subtype link). Connections are "specific" (many to one) binary associations between a child entity type and parent entity type, where each child has at most one parent.

Connection relationships are either identifying or non-identifying. In principle, an identifying relationship corresponds to an association that is conceptually used in the identification scheme of the child. In actuality, it is simply a reference from a foreign key in the child's primary key to the parent's primary key. In a non-identifying relationship, the child non-key attributes include a foreign key that references the parent's primary key.

All connection relationships are denoted as a named line with a dot "·" at the child end. An identifying relationship is shown as named, solid line, as shown in Figure 3. Here a and b are attributes (possibly compound).

Figure 3 An identifying connection "relationship"

With an identifying connection, each child entity is associated with exactly one parent instance. This is because each child instance has a non-null value for the foreign key (in the child's primary key) that references the parent. By definition, the child must be identifier-dependent, as shown by the soft-rectangle. The parent is identifier-independent (as shown here) unless made dependent by some other relationship.

IDEF1X allows both forward and predicate readings to be supplied for relationships. These are normally written on different sides of the relationship line, as shown in Figure 4(a). A slash "/" is appended to the forward reading, which is read from left to right (or top to bottom if the relationship line is vertical). The equivalent ORM diagram in Figure 4(b) makes it clear that the association Room is in Building is part of the composite reference scheme for Room.

Figure 4 The IDEF1X schema (a) is equivalent to the ORM schema (b)

In IDEF1X, this association is actually depicted by including bldgNr as part of the key for Room, and the connection "relationship" is merely a foreign key reference. We can partially lift the IDEF1X discussion to a conceptual level by talking of the parent's primary key migrating to the child (see Figure 5).

Figure 5 The primary key of Building "migrates" to become a foreign key in Room

Although not a legal IDEF1X diagram, Figure 5(a) helps to portray Room as being partly identified by its room number and partly by its relationship to Building. At this level, the association Room is in Building is conceptual. Now imagine a copy of Building's primary key migrating to complete the primary key of Room, as shown in Figure 5(b). At this stage, we have dropped to the logical level. The conceptual relationship between Room and Building is now depicted by Room's bldgNr attribute. We still need to indicate that any value for this attribute must also occur as a primary key value of Building, and this foreign key reference is what the connection line now represents. I've removed the "relationship" name to stress this point. You can now think of the connection line as a foreign key arrow.

For identifying relationships, each child (instance) is associated with exactly one parent (instance), as shown by a solid line with no adornments. By default a parent is associated with zero or more children, as shown by an unadorned dot "·" at the line end. If you are familiar with UML, you can think of this as equivalent to "*". You can override this default child cardinality by adorning the dot with a cardinality constraint mark. The main cases are shown in Figure 6 along with their ORM counterpart. Here "P" indicates a positive number (at least 1), and "Z" indicates zero or 1 (at most 1). A single number (e.g. 3) indicates exactly that number. You can also indicate ranges. For example, "2-5" indicates at least 2 and at most 5. To make sense of these cardinality constraints, think of them as applying to the conceptual relationship that existed before the key was migrated to the child (cardinality constraints on a foreign key reference are rather pointless). The "Z" mark is unintuitive for "at most 1", and in IDEF1X97 an alternative notation for this constraint is to use a hollow dot "O".

Figure 6 The main child cardinality cases for identifying relationships

Next issue

The next article in this series completes the discussion of the IDEF1X notation, including non-identifying, intersection and categorization relationships.

References

1. Bruce, T. 1992, Designing quality databases: practical information management and IDEF1X, Dorset House, New York.

2. IEEE 1999, IEEE standard for conceptual modeling language syntax and semantics for IDEF1X97 (IDEFobject), IEEE Std 1320.2-1998, IEEE, New York.

3. Menzel, C. & Mayer, R.J. 1998, 'The IDEF family of languages', Handbook on Architectures of Information Systems, eds. P. Bernus, K. Mertins & G. Schmidt, Springer-Verlag, Berlin, Germany, pp. 209-41.

4. NIST 1993, Integration definition for information modeling (IDEF1X), FIPS Publication 184, National Institute of Standards and Technology, www.sdct.itl.nist.gov/~ftp/idef1x.trf.

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