Appendix B

Explanation of the IDEF1X Notation

IDEF1X is the successor notation to IDEF (Integrated Definition for Data Modeling). IDEF1X is a popular notation for modeling relational databases. The IDEF1X notation has been in use for two decades now and was effectively standardized through early adoption by the U.S. Air Force.

The major concepts in IDEF1X are entity types, relationships, and generalizations.

Entity Type

An entity is a concept, abstraction, or thing that can be individually identified and has meaning for an application. An entity type describes a group of entities with the same attributes, kinds of relationships, and intent. An entity type corresponds to a relational database table and an entity corresponds to a row in a table. The IDEF1X notation for an entity type is a box. IDEF1X differentiates between independent and dependent entity types.

Figure B1.1 shows three independent entity types. An independent entity type is an entity type that can exist on its own. Some authors call this a strong entity type. The IDEF1X symbol for an independent entity type is a square-corner box with the name of the entity type listed above the box. The top portion of the box contains primary key attributes and the lower portion contains the remaining attributes.

An attribute describes a value held by each entity of an entity type. Account has four attributes—the primary key attribute and three non-primary key attributes. Similarly, Actor has five attributes and PhysicalPart has two attributes.

A candidate key is a combination of one or more attributes that uniquely identifies each entity of an entity type. The attributes in a candidate key must be minimal; no attribute can be discarded without destroying uniqueness. No attribute in a candidate key can be null. A database index is often used to enforce uniqueness for a candidate key.

A primary key is a candidate key that is chosen for cross-table references (see the discussion of foreign keys in the next section). Normally, an entity type should have a primary key; an entity type can have at most one primary key. The IDEF1X notation for a primary key is to list the primary key attributes in the top portion of the entity type box. All three entity types in Figure B1.1 have a single attribute as the primary key.

An alternate key is a candidate key that is not chosen as a primary key. Thus all candidate keys are either a primary key or an alternate key. An entity type can have any number of alternate keys. The IDEF1X notation for an alternate key is to append "AKn.m" after each constituent attribute. The ‘n’ denotes the nth alternate key and the ‘m’ indicates the sequence of attributes within the nth alternate key. Figure B1.1 has one alternate key—accountNumber for an Account. This alternate key consists of a single attribute.

Figure B1.2 shows two independent entity types and one dependent entity type. A dependent entity type is an entity type that can exist only if one or more other entity types also exist. Accordingly, the primary key of a dependent entity type incorporates one or more foreign keys. Some authors call this a weak entity type. The IDEF1X symbol is a rounded box with the name of the entity type listed above the box. In Figure B1.2 AddressRole_Actor is a dependent entity type whose primary key refers to the Actor and AdressRole entity types.

Relationships

A relationship is a physical or conceptual connection among entities. A relationship type is a description of a group of relationships with similar structure and meaning. A relationship type describes a set of potential relationships in the same way that an entity type describes a set of potential entities. The IDEF1X notation for a relationship type is a line (possibly with multiple line segments) between entity types. Data modelers often blur the distinction between relationship and relationship type with the distinction being apparent from context. The remainder of this appendix refers to both as relationship. IDEF1X differentiates between identifying and non-identifying relationships.

Figure B1.3 shows five relationships, two of which are identifying. Both relationships to Contract_Actor are identifying. An identifying relationship is a relationship that contributes to the primary key of a dependent entity type. The IDEF1X symbol for an identifying relationship is a solid line.

The remaining three relationships in Figure B1.3 are non-identifying. A non-identifying relationship is a relationship that does not contribute to the primary key of an entity type. Consequently the foreign key appears in the lower portion of the entity type box. The IDEF1X symbol for a non-identifying relationship is a dotted line.

The suffix (FK) after an attribute name denotes a foreign key. Each foreign key corresponds to a relationship, either identifying or non-identifying. Thus IDEF1X shows relationships redundantly with both relationship lines and (FK) annotations. IDEF1X represents many-to-many relationships, such as Contract_Actor, with a dependent entity type and two identifying relationships.

Non-identifying relationships can involve both independent and dependent entity types as Figure B1.4 illustrates. PartitionBasis_childRegion has two identifying and one non-identifying relationships.

Although little used in this book, an IDEF1X relationship line can be labeled with a relationship name. Although IDEF1X does not show them on the diagram, relationship ends can also be named. Relationship end names are manifest via foreign keys. Thus in Figure B1.4 PartitionBasis_childRegion has an identifying relationship to Region with an end name of child. Furthermore, PartitionBasis_childRegion has a non-identifying relationship to Region with an end name of parent.

The ends of a binary relationship also have multiplicity. Multiplicity is the number of occurrences of one entity type that may connect to an occurrence of a related entity type. A small solid ball denotes “many” multiplicity (zero or more). A small diamond denotes "at most one" multiplicity (zero or one). The lack of a symbol indicates a multiplicity of exactly one.

The IDEF1X literature often uses the term “cardinality” incorrectly, instead of the proper term “multiplicity.” Multiplicity is a constraint on the size of a collection; cardinality is the count of elements that are actually in a collection. Therefore, multiplicity is a constraint on the cardinality.

IDEF1X only permits certain combinations of multiplicity as Figure B1.5 shows. (IDEF1X also supports a more precise specification of ‘many’ multiplicity with the ‘P’, ‘Z’, and ‘N’ annotations, but this book does not use them.)

Note that all the prior relationships in this appendix attach to the contours of entity type boxes. As Figure B1.6 shows, an IDEF1X relationship need not touch the contour.

Generalization

Generalization is the organization of entity types by their similarities and differences. The supertype holds common attributes and relationships. The subtypes add specific attributes and relationships. Each subtype inherits the attributes and relationships of its supertype.

The IDEF1X notation for generalization is a circle with a double line underneath. The double line indicates that the generalization is exhaustive; each occurrence of a supertype must correspond to a subtype. (IDEF1X also supports a single horizontal line indicating that a generalization is not exhaustive. As a matter of style all the generalizations in this book are exhaustive.) The attribute next to the circle is called a discriminator and indicates the subtype that elaborates each supertype record.

Figure B1.7 shows two generalizations. One generalization has a supertype of Actor and subtypes of Tangible Actor, ActorRole, and ActorRoleType. The other generalization has a supertype of TangibleActor and subtypes of Person, Application, and Organization. Note that as a matter of style we rename propagated keys for generalization so that the primary key name corresponds to the entity type name. Such a practice makes it easier to understand foreign keys for a large model where there are various relationships to different levels of a generalization.

Bibliographic Notes

The explanation of IDEF1X in this appendix is abridged and only covers the constructs used in this book. [Bruce-1992] has a more extensive discussion of IDEF1X. [Blaha-2001] compares IDEF1X to other notations.

References

[Blaha-2001] Michael Blaha. A Manager's Guide to Database Technology. Upper Saddle River, New Jersey: Prentice-Hall, 2001.

[Bruce-1992] Thomas A. Bruce. Designing Quality Databases with IDEF1X Information Models. New York: Dorset House, 1992.