8.4. IDEF1X

In the 1970s, the U.S. 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:

• IDEFIX logical data modeling

• IDEF3 process modeling

• IDEF4 object-oriented software design

• IDEF5 knowledge engineering of enterprise ontologies

• IDEFIX₉₇ logical data modeling with object-oriented extensions

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

IDEFIX 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 (NIST 1993). A proposed successor called IDEFIX97 was approved in June 1998 by the IEEE-SA Standards Board (IEEE 1999). Also known as IDEF_object this extended IDEFIX with object-oriented features to facilitate implementation in object-oriented databases and programming languages, while maintaining compatibility with IDEFIX for relational database implementation. This backward compatibility gives IDEF1X ₉₇ one advantage over UML for adoption in US government sectors.

Nevertheless the future of IDEFIX97 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 it has been adopted as a standard by the International Standards Organization (ISO). At the time of writing, few practitioners or tool vendors have expressed interest in adopting IDEFIX97. In contrast, the original (1993) version of the IDEFIX language continues to be very widely used for database design and is supported by many modeling tools. For these reasons, we restrict our attention to the original IDEFIX in the rest of this section.

To model facts, IDEFIX uses the three main constructs of ER: entities, attributes, and relationships. Unfortunately, the IDEFIX 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 that 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.

IDEFIX allows models to be developed in phases using at least three views: ER view, key-based view, and fully attributed view. The essential differences among these views are summarized in Table 8.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 IDEFIX is basically 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, IDEFIX 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. Some CASE tools that support IDEFIX do not support its ER view, and we ignore the ER view from this point on.

In key-based and fully attributed views, IDEFIX entity types are basically relational tables, and the “relationships” are foreign key to primary key references. Recall that 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 8.26(a). A dependent entity type is depicted as a soft rectangle (rounded corners), as shown in Figure 8.26(b).

Attributes of an entity type are listed inside its rectangle. Primary key attributes appear in the top compartment. These provide the entity type’s primary identification scheme. Alternate keys are marked by appending “(AKn)”, where n > 0. These provide an alternate identification scheme. If an alternate key is composite, each of its components 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 8.27, empNr is the primary key of Employee. 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.

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 nonidentifying. In principle, an identifying relationship is 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 nonidentifying relationship, the child nonkey 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 8.28. Here a and b are attributes (possibly compound).

With an identifying connection, each child entity is associated with exactly one parent instance. This is because each child instance has a nonnull 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 it is made dependent by some other relationship.

IDEF1X allows both forward and inverse predicate readings for relationships. These may be written together, as shown in Figure 8.29(a), or on different sides of the relationship line, as shown later in Figure 8.30(a).

The forward reading of a specific connection relationship is always toward the child, and hence toward the dot “•”. This forward or “parent-perspective” reading must be supplied. The inverse or “child-perspective” reading, if supplied, is toward the parent (away from the dot). If both readings are supplied, a slash “/” is appended to the forward reading. In Figure 8.29(a) the forward reading is Building contains Room and the inverse reading is Room is in Building. Because the child here is on the left, the forward reading is right to left. For non-specific (m:n) relationships however, the forward reading is always read from left to right (or top to bottom if the relationship line is vertical). Recall that m:n relationships exist only at the ER view level.

The equivalent ORM diagram in Figure 8.29(b) makes it clear that the association Room is in Building is part of the composite reference scheme for Room. In the IDEF1X diagram, this association is actually depicted by including bldgNr as part of the key for Room, and the connection “relationship” shows the 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 8.30).

Although not a legal IDEF1X diagram, Figure 8.30(a) helps portray Room as being partly identified by its room number and partly by its relationship to Building. Compare this with the Barker notation depiction in Figure 8.9. 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 in Figure 8.30(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. We 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 8.31 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 IDEF1X₉₇ an alternative notation for this constraint is to use a hollow dot “O”.

A nonidentifying relationship is shown as a named, dashed line. Child and parent are independent unless made dependent by some other relationship. If the dashed line is unadorned, each child (instance) is associated with exactly one parent (instance), as in Figure 8.32(a). If a diamond is added at the parent end, each child is associated with at most one parent, as in Figure 8.32(b). The corresponding ORM diagrams are also shown.

In a nonidentifying relationship, the child nonkey attributes (those not in the primary key) include a foreign key that references the parent’s primary key. If the foreign key is mandatory (each component is nonnuU) then each child instance is associated with exactly one parent instance. This is referred to as a mandatory relationship, but actually means that the child role of the conceptual relationship that (before migration) gave rise to the foreign key reference is mandatory.

Figure 8.33(a) depicts this situation in more detail. Here a and b are simple or composite attributes. If the foreign key is optional (its components may all be null) then each child instance is associated with at most one parent instance. Figure 8.33(b) depicts this situation. In IDEF1X this is referred to as an optional relationship.

In both mandatory and optional cases, each instance of the child’s foreign key that has no null components must occur as an instance of the parent’s primary key. This is the default meaning of a foreign key constraint in SQL. For the mandatory case of course, there can be no null components.

An example of a mandatory, nonidentifying connection relationship is shown in Figure 8.34(a). Here each employee is identified by an employee number, must have a name, and must work for a department. Each department is identified by its code and must have a unique name.

The fact (conceptual relationship) that a given employee works for a given department is stored by instantiating the empNr and deptCode attributes of Employee (e.g., empNr = 101, deptCode = ‘HR’). The connection “relationship” is simply a foreign key reference indicating that each department code of an employee must be a department code of a department.

The same example is shown in IE notation in Figure 8.34(b) and in ORM notation in Figure 8.34(d). Here the association Employee works for Department is depicted conceptually, rather than by including deptCode as an attribute of Employee. This would also be the case for the Barker notation. Figure 8.34(c) depicts the situation in a relational notation. Here facts about who works for what department are stored in the Employee table, which includes a deptCode attribute referencing the Department table. If you compare this with the IDEFIX notation in Figure 8.34(a), it should be clear that they are just two notational variations of the same structure. In key-based and fully-attributed views, the IDEFIX notation is essentially a logical notation rather than a conceptual one.

As another example of non-identifying relationships, the room scheduling example considered in Sections 1.2 and 8.2 is modeled in IDEFIX in Figure 8.35(a). The ORM model for this situation is reproduced in Figure 8.35(b), without the fact populations. The primary key and alternate key constraints in the IDEFIX model correspond to the uniqueness constraints in the ORM model. Although the IDEFIX schema does capture all of the constraints, it is a logical rather than a conceptual representation, and unlike ORM it does not facilitate validation by verbalization and population.

Figure 8.36 shows a more complex IDEFIX example involving a compound foreign key relationship corresponding to a pair-subset constraint in the ORM schema.

A simple example of the optional, nonidentifying “relationship” pattern in Figure 8.33(b) is shown in Figure 8.37. Here an employee optionally has an office. Each office is a room with a composite identification scheme. Room’s relationship with Building is omitted here.

A more complex example is shown in Figure 8.38. This is similar to the example in Figure 8.36, except that it is now optional for one to like a movie or to have a favorite movie.

In an ER view or “entity level diagram” all entity types are depicted by hard rectangles, and non-specific (m:n) relationships are permitted. Each non-specific relationship line must end in a dot, possibly adorned by a cardinality mark. If unadorned, a cardinality of exactly one is assumed. In moving to a key-based or fully attributed view, each m:n relationship must be resolved into an “intersection entity type” with two n: relationships. Figure 8.39 shows an example in both IDEF1X and ORM.

An intersection entity type is sometimes called an “associative entity type”. Although conceptually this corresponds to a coreferenced object type in ORM, in IDEF1X the identifying attributes must be “migrated” to become foreign keys inside the primary key of the intersection entity type, which therefore must be identifier dependent, appearing as a soft rectangle. This foreign key depiction effectively lowers the representation to the relational level.

Although this resolution is often unnatural, it does allow attributes to be added to what was once a relationship. For example, we might wish to record a skill level for Play. In ORM and UML, this objective can also be achieved by simply permitting a relationship to be objectified (as an objectified association or association class), but this conceptual alternative is not allowed in IDEF1X.

If the m:n relationship is a ring association, role names may be prepended to the names of the migrated foreign keys to distinguish them. For example, in Figure 8.40(a), the role names “subPartNr” and “superPartNr” are prepended to “partNr” to disambiguate the primary key attributes of Containment.

Although the IDEF1X standard uses a dot after the role name, this dot notation is not supported in some CASE tools. However the distinction can be easily achieved without the dot by using just a role name (e.g., “subPartNr” can be used instead of “subPartNr.partNr”).

In either case, the role name should be shown as a noun phrase that identifies the attribute even without appending the name of the referenced primary key. In ORM, a more natural way to model this situation is to objectify the containment association, as shown in Figure 8.40(b).

In IDEF1X, an entity type may be classified into one or more clusters of mutually exclusive categories (subtypes). The supertype is called the generic entity (type). Each subtype inherits the primary key of its supertype, and hence is identifier dependent. The subtype linkage is called a “categorization relationship”.

This version of subtyping is very restricted compared with ORM subtyping, which allows overlapping types within a “cluster” as well as context-dependent reference. In effect, the subtyping approach of IDEF1X treats entity types as tables, and the “categorization relationships” are simply foreign key references. In sharp contrast, ORM subtyping is purely conceptual, and different mapping strategies may be chosen at implementation time (see Chapter 11).

However, there are two aspects of the subtyping approach in IDEF1X that express more than simple foreign key references. These are the completeness and discriminator declarations. A subtype link is shown as a line with an underlined circle at the supertype end. A single underline means that the cluster is incomplete (i.e., the supertype is more than the union of its subtypes). This means that the population of the supertype may contain instances not present in any of its subtypes.

For example, in Figure 8.41(a), the subtypes TallPerson and ShortPerson are mutually exclusive, but not collectively exhaustive. A person may be of medium height without being classified as either tall or short. In contrast to IDEFIX, ORM often uses derived subtypes, which must be defined in terms of roles played by their super-type(s). Figure 8.41(b) shows one way of modeling this situation in ORM.

Here a person’s height is used to determine whether he or she is a member of Tall-Person or ShortPerson. The subtype definitions and the lack of a value constraint on Height indicate that these subtypes are exclusive but not exhaustive. This can also be depicted explicitly by an implied exclusion constraint as shown. As an alternative to using height, you could attach the optional and exclusive unaries “is tall” and “is short” to Person and supply the obvious definitions.

In IDEFIX, a double underline at the supertype end means that the cluster is complete. This means that the supertype is the union of its subtypes. Since members of an IDEFIX cluster are also exclusive, this means that we have a partition. In Figure 8.42(a), for example, Person is partitioned into MalePerson and FemalePerson.

A mandatory attribute of a supertype may be used as a discriminator and written next to the circle to indicate the basis for the subtyping. In Figure 8.42(a) for example, gender is used as a discriminator to classify Person into MalePerson and FemalePerson. The corresponding ORM schema is shown in Figure 8.42(b). The partition constraint shown explicitly here is implied by the subtype definitions and other constraints.

Well that pretty much covers the IDEFIX notation. Although it is a widely used standard, especially in the defense industry, we find it less suitable than the Barker or IE notations for conceptual modeling. To capture any detail or even basic constraints in IDEFIX, you have to resolve the model into what is essentially a relational model. Moreover, the IDEFIX set of concepts and its notation are unnecessarily complex and forgettable. For conceptual analysis and validation, it also suffers from the weaknesses of an attribute-based approach.

Despite such drawbacks, IDEFIX can be used effectively by experienced modelers, who often associate connection relationships with the conceptual relationships from which they are migrated. Even for such experienced modelers, however, the best way to model in IDEFIX is to first do an ORM model and then map it to IDEFIX, expressing any additional ORM constraints as supplementary text or implementation code. Some ORM modeling tools can perform this mapping automatically.