Entity types are represented by square-cornered boxes, with their attributes hanging off them in circles. An entity type's name appears inside the rectangle, and an attribute's name appears inside the circle. There are no special marks to indicate whether attributes are mandatory or optional, or whether they participate in the entity type's unique identifier.

Names of entity types and attributes are common terms, and in multiword names, the words are separated by hyphens.

Mr. Chen's notation is unique among the techniques shown here in that a relationship is shown as a two-dimensional symbol—a rhombus on the line between two or more entity types.

Note that this relationship symbol makes it possible to maintain a “many-to-many” relationship without necessarily converting it into an associative or intersect entity type. In effect, the relationship itself is playing the role of an associative entity type. The relationship itself is permitted to have attributes. Note how “quantity”, “actual price”, and “line number” are attributes of the relationship Order-line in Figure B.1.

Note also that relationships do not have to be binary. As many entity types as necessary may be linked to a relationship rhombus.

A unique identifier is any combination of attributes and relationships that uniquely identify an occurrence of an entity type.

While Mr. Chen recognizes the importance of attributes as entity-type unique identifiers [Chen, 1977, p. 23], his notation makes no provision for showing this. If the unique identifier of an entity type includes a relationship to a second entity type, he replaces the relationship name with “E”, makes the line into the dependent entity type an arrow, and draws a second box around this dependent entity type. (Figure B.2 shows how this would look if the relationship to party were part of the unique identifier of PURCHASE ORDER). This still does not identify any attributes that are part of the identifier.

Figure B.2. Existence-Dependent Relationship.

A sub-type is a subset of the occurrences of another entity type, its super-type. That is, an occurrence of a sub-type entity type is also an occurrence of its super-type. An occurrence of the super-type is also an occurrence of exactly one or another of the sub-types.

Though not in Mr. Chen's original work, the technique was extended to include this by Mat Flavin [Flavin, 1981] and Robert Brown [Brown, 1993].

In this extension, sub-types are represented by separate entity-type boxes, each removed from its super-type and connected to it by an “isa” relationship. (Each occurrence of a sub-type “is a[n]” occurrence of the super-type.) The relationship lines are linked by a rhombus, and each relationship to a sub-type has a bar drawn across it. In Figure B.1, for example, PARTY is a super-type, with PERSON and ORGANIZATION as its sub-types. Similarly, a CATALOGUE ITEM must be either a PRODUCT or a SERVICE.

The most common case of constraints between relationships is the “exclusive or”, meaning that each occurrence of the base entity type must (or may) be related to occurrences of one other entity type, but not more than one. These will be seen in most of the techniques which follow below.

Mr. Chen does not deal with constraints directly at all. This must be done by defining an artificial entity type and making the constrained entity types into sub-types of that entity type. This is shown in Figure B.1 with the entity type CATALOGUE ITEM, which has mutually exclusive sub-types product and service. Each purchase order has an order-line relationship with one CATALOGUE ITEM, where each CATALOGUE ITEM must be either a PRODUCT or a SERVICE.

Mr. Chen was first, so it is not surprising that his technique does not express all the nuances that have been included in subsequent techniques. It does not annotate characteristics of attributes, and it does not show the identification of entity types without sacrificing the names of the relationships.

While it does permit showing multiple inheritance and multiple type hierarchies, the multibox approach to sub-types takes up a lot of room on the drawing, limiting the number of other entity types that can be placed on it. It also requires a great deal of space to give a separate symbol to each attribute and each relationship. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type.

Mr. Finkelstein defines entity type in the designer's sense of representing “data to be stored for later reference” [Finkelstein, 1992, 23]. Mr. Martin, however, adopts the analyst's definition that “an entity type is something (real or abstract) about which we store data” [Martin & McClure, 1985, 249].

Entity types are shown in square-cornered rectangles. An entity type's name is inside its rectangle. Attributes are not shown at all. Mr. Finkelstein shows them in a separate document, the “entity type list”. Mr. Martin has another modeling technique, called “bubble charts”, specifically for modeling attributes, keys, and other attribute characteristics.

Names of entity types are common terms, and the words in multiword names are separated by spaces.

Relationships are shown as solid lines between pairs of entity types, with symbols on each end to show cardinality and optionality.

Unique identifiers are not represented in an information-engineering data model. Mr. Martin shows them separately in “bubble diagrams”.

Mr. Martin represents sub-types as nested boxes inside the super-type box. This is shown in the figure. Mr. Finkelstein portrays them as separate boxes, with a linked with “isa” relationship lines, as used in the Chen notation described above.

In information-engineering notation, a constraint between relationships is shown by the relationship halves of the three (or more) entity types involved meeting at a small circle. If the circle is solid, the relationship between the relationships is “exclusive or”, meaning that each occurrence of the base entity type must (or may) be related to occurrences of one other entity type, but not more than one. This is shown in the figure, where each LINE ITEM is for either one PRODUCT or is for one SERVICE, but not both. If the circle is open, it is an “inclusive or” relationship, meaning that an occurrence of the base entity type must (or may) be related to occurrences of one, some, or all of the other entity types.

Information engineering is widely practiced. It is reasonably concise and attractive, consistent, and has a minimum of clutter. It is, however, missing important notations for attributes and unique identifiers, although some CASE tools have added these. Mr. Martin's approach to sub-types is compact and therefore desirable if models are to be presented to the nontechnical community, while Mr. Finkelstein's is not. Mr. Finkelstein's notation for “initially may be but eventually must be” is a very ingenious solution to a common modeling situation, not found in any other notation.

Entity types in Barker's notation are shown as round-cornered rectangles. Attributes may be displayed inside the entity-type boxes.

Officially, attributes are shown with small open circles for optional attributes, solid circles for required attributes, and octothorps (#) for attributes which participate in unique identifiers. Often in practice, however (and throughout this Appendix), dots are used for all required and optional attributes not in a unique identifier.

Relationships are shown as lines, with each half solid or dashed, depending on whether that part of the relationship is mandatory or not. The presence or absence of a crow's foot on each end shows that end as referring to, respectively, up to many or no more than one occurrence of that entity type. Naming conventions allow the relationship at each end to be read as a concise, disciplined, but easy-to-understand sentence.

Each
<entity type 1>
{must be | may be}(If the line is solid or dashed)
<relationship>
{one or more | one and only one}(If there is or is not a crow's foot)
<entity type 2>
  .

Barker's notation shows sub-types as boxes inside super-type boxes, according to the approach to set theory laid out by Leonhard Euler in the 18th Century. This has the advantage of taking up much less room on the diagram, and it emphasizes the fact that an occurrence of a sub-type is an occurrence of the super-type. The super- and sub-types are not simply related to each other. This does mean, however, that multiple inheritance (multiple super-types for one sub-types) and multiple type hierarchies (multiple ways of dividing a super-type into sub-types) cannot be represented by a Barker model.

In Barker's notation, sub-types are exclusive, meaning that overlapping sub-types are not allowed. Sub-types are also complete, meaning that sub-types are supposed to account for all occurrences of a super-type, although in practice this latter rule is often bent by adding the sub-type OTHER. In Figure B.4, PERSON and ORGANIZATION are sub-types of PARTY.

The only constraint between relationships available in Mr. Barker's notation is the exclusive or. An arc across two relationships represents the fact that each occurrence of an entity type must be (or may be) related to occurrences of one or more other entity types, but not more than one. For example, Figure B.4 shows that each LINE ITEM must be either for one PRODUCT or for one SERVICE.

Several things distinguish this notation from those described elsewhere. These are factors that make the Barker technique the most desirable to use in a requirements analysis project. The technique results in models that are much better for presenting to the public at large than those produced by any other.

First, this notation uses relatively few distinct symbols. There is only one kind of entity type. Whether it is a role, an intersection, or another kind of association between two entity types, it is represented by the same round-cornered rectangle. The full range of relationship types is shown by line halves, which may be solid or dashed, and by the presence or absence of a crow's foot on each end. Unique identifiers, where it is important to show them, are shown by either the hash marks next to an attribute, or a small mark across a relationship line, and dependency is implied by the use of a relationship in a unique identifier. Attributes may be shown with indicators of their optionality.

Other notations are, to varying degrees, more complicated than that.

Second, sub-types are shown as entity types inside other entity types. Most other notations place sub-types outside the super-type, connected to it with “isa” relationship lines. This takes up much more space on a diagram and does not convey as emphatically the fact that an occurrence of a sub-type is an occurrence of the super-type. Moreover, it is not easy to see that an attribute of or a relationship to a super-type is also an attribute of or a relationship to every sub-type of that super-type.

Third, Barker's notation permits “exclusive or” constraints between relationships, which show that an occurrence of one entity type may be related to occurrences of either of two or more other entity types. This is more than is available in some notations, and less than in others.

The last, and perhaps the most important thing to distinguish this technique from the others is a rigorous naming standard for relationships. Relationship names are prepositions, not verbs. A little reflection should reveal why this is appropriate, since it is the preposition in English grammar, not the verb, that denotes a relationship. (Verbs suggest functions, which are featured in other kinds of models.) The implied verb in every relationship sentence is “to be”, expressed as either “must be” or “may be”.

Note that in the examples of notations without this discipline, the verbs often include “is” anyway.

This use of prepositions makes it possible to use common English sentences to represent relationships completely. It is not always easy to come up with just the right word, but the exercise of trying to do so improves significantly your understanding of the true nature of the relationship.

This discipline could certainly be followed with the other techniques, but none of the books your author has found to describe these techniques endorses it.

Entity types in IDEF1X are shown by round-cornered or square-cornered rectangles. Round-cornered rectangles represent “dependent” entity types—those whose unique identifier includes at least one relationship to another entity type. “Independent” entity types, whose identifiers are not derived from other entity types, are shown with square corners.

The name of the entity type appears outside the box. The box is divided, with identifying attributes (here referred to as the “primary key”) above the division and nonidentifying attributes below.

In multiword entity type names, the words may be separated by hyphens, underscores, or blanks.

In IDEF1X, relationships are asymmetrical: Different symbols for optionality are used, depending on the relationship's cardinality. Unlike the other notations, symbols cannot be parsed in terms of optionality and cardinality independently. Each set of symbols describes a combination of the optionality and cardinality of the entity type next to it.

In addition to a relationship line from an entity type, the foreign key that would implement the line in a relational database design is shown as an attribute of that entity type.

If a relationship is part of an entity type's unique identifier, it is shown as a solid line; if not, it is shown as a dashed line.

Table B.1 shows, for IDEF1X and the Barker notation, all the possible combinations of cardinality and optionality on both ends of the relationship.

As stated above, a unique identifier is represented in IDEF1X by the primary key which will implement it in a relational database. Since all relationships are shown by foreign-key attributes, the primary key may consist of any combination of foreign-key and non-foreign-key attributes. If a foreign key is present in the unique identifier primary key, then the otherwise dashed relationship line becomes solid, and the entity-type box acquires round corners.

IDEF1X shows sub-types as separate entity-type boxes, each removed from its super-type and connected to it by an “isa” relationship. (Each occurrence of a sub-type “is a[n]” occurrence of the super-type.)

There are two kinds of sub-types. In Figure B.5, the circle with two horizontal lines under it is a complete subtyping arrangement: All occurrences of the parent must be occurrences of one or the other sub-type. A circle with only one horizontal line below it is an incomplete subtyping arrangement: The sub-types do not represent all possible occurrences of the super-type.

All sub-types extending from a single sub-type symbol are mutually exclusive. Sub-types may be shown to be overlapping by being descended from different sub-type symbols attached to the same super-type entity type.

In IDEF1X, the unique identifier of the sub-type must always be identical to the identifier of the super-type. This point is reinforced by including the foreign key (“(FK)”) designator next to the unique identifier of the sub-type, referring to the unique identifier of the super-type. Optionally, a “role name” may be appended to the front of the foreign-key name in the sub-type. In Figure B.5, the role names “product-code” and “service-id” are roles, appended to “item number” for the primary keys of product and service. Note that, since the keys themselves remain identical to the key of the super-type, appending role names does not change their format in any way.

An attribute used to discriminate between the sub-types is placed next to the sub-type symbol. For example, “person-organization-type” is shown in Figure B.5 to distinguish between occurrences of person and organization. If the sub-types were implemented in a single table for the super-type, this would become a separate column for discriminating between occurrences of the different sub-types.

IDEF1X does not have an explicit way to represent constraints between relationships. Instead of saying “A” is related to “B” or to “C”, it is necessary to define an entity type, “D”, and then use the sub-type notation. Thus you would say “A” is related to “D”, which must be either a “B” or a “C”.

The ability to express exhaustiveness and exclusivity in sub-types does carry over to this situation.

This is shown in Figure B.5 with the creation of CATALOGUE ITEM as a super-type of PRODUCT and SERVICE.

IDEF1X symbols do not map cleanly to the concepts they are supposed to model. A concept that should be represented by a single symbol requires several together, and it requires different symbols under different circumstances. That is, particular situations can be represented by more than one set of symbols, while the same symbol can mean different things, depending on context. Which symbol is used to describe a particular situation is heavily dependent on the context of that situation and on how the relationship will be implemented, not just on the situation itself.

For example, the symbol to be used for optionality depends on the cardinality of the relationship. The solid circle symbol can mean anything, depending on its setting. Similarly, a cardinality/optionality combination may be represented in different ways. This is because what is being represented is not a conceptual structure, but an implementation method.

The effect of all this is that it is prohibitively difficult to teach a nontechnical viewer to read an IDEF1X diagram.

A dominant graphic feature of any relationship line is its being solid or dashed. Barker's notation uses this feature to distinguish between relationships that are required and those that are not. Among those relationships that are, those participating in a unique identifier may be simply marked with an extra line across them, but this level of detail is often not required.

In IDEF1X, however, the solidity of a line describes the participation of one entity type in the unique identifier (primary key) of the other. This requires the analyst to begin the efforts by analyzing dependency—before addressing the optionality or cardinality of the model's relationships.

In a real modeling situation, however, an analyst in fact normally starts by examining which entity types are required for which other entity types, and how many occurrences are involved. The details of keys or identifiers are typically not addressed until much later.

And corrections to the model are unnecessarily difficult: If you make a single error in cardinality or optionality (say, the one-to-one mandatory relationship should really be optional), then several symbols must be changed.

While it does permit showing multiple inheritance and multiple type hierarchies, the multibox approach to sub-types takes up a lot of room on the drawing, limiting the number of other entity types that can be placed on it. It also requires a great deal of space to give a separate symbol to each attribute and each relationship. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type.

IDEF1X may be a good modeling tool to use as the basis for database design, but it does not follow the rules of good graphic design (as described at the beginning of this appendix), making it unnecessarily difficult to learn and difficult to use as a tool for analyzing business requirements jointly with users.

As shown in Figure B.6, an entity type is portrayed by an ellipse containing its name. An ellipse may also represent a value type, which is similar to a domain. A value type's playing a role in a relationship with an entity type is equivalent to an “attribute” in an entity/relationship diagram.

Entity-type labels play roles as identifiers, and these may be shown as dashed ellipses, although as a shorthand, identifying value types may also be shown within the entity-type ellipse in parentheses, below the entity-type name. Nonidentifying attributes always are portrayed as roles played by value types—ellipses outside the entity-type ellipse.

Thus, relationships not only connect entity types to each other but also value types to entity types as attributes. ORM is unique in being able to raise the question: What is the exact relationship of an attribute to its entity type? In particular, it can describe the optionality and cardinality of attributes.

Attributes can be combined if they have the same domain or unit-based reference mode. For example, in Figure B.6, the list price of Product, the rate for a service, and the cost of a Line Item are all taken from the domain “Monetary amount”. Similarly, this figure asserts that product names and service names are taken from the same set of names.

ORM presents relationships between two entity types as “roles” that entity types and domains play in the organization's structure. Relationships are assembled from one or more adjacent boxes containing role names and connected to the entity types by solid lines. Relationships are not limited to being binary. Tertiary and higher-order relationships are permitted.

Where most methods portray entity types in terms that allow them to be translated into relational tables, ORM portrays the relationships to be converted to tables. That is, the two parts (or more) of the relationship become columns in a “relation” (table). In effect, these are the foreign keys to the two entity types. Attributes of one or more of the related entity types also then become part of a generated table.

A relationship may be “objectified”, when it takes on characteristics of an entity type. This is most common in the case of many to many relationships. Note in Figure B.7 that the many-to-many relationship between purchase order and product has been circled. Instead of creating a formal entity type, as is done in many other systems of notation (and as was done above), the relationship simply becomes a “nested fact type” or “objectified relationship”. This nested fact type may then be treated as an entity type having other entity types or attributes related to it. In Figure B.7, for example, the nested fact type Line Item is bought in a quantity.

Figure B.7. Objectified Relationships.

This is an alternative to simply defining line item as an entity type, as was done in Figure B.6. That was done in that figure because of the exclusive relationship between it and product and service. (See the discussion of constraints between relationships, below.)

As described above, labels may be shown as dashed ellipses, although as a shorthand, they also may be shown within the entity-type ellipse in parentheses, below the entity-type name. If nothing else is shown, these are the unique identifiers of the entity type. Where both a label and some other identifier are involved (such as a system-generated unique identifier), the unique identifier is shown under the name, and the label is shown as another attribute, (albeit with the dashed circle). For example, in Figure B.6, party is shown as identified by “ID,” but it also is named with the label party name.

If two or more attributes or relationships are required to establish uniqueness for an entity type, a special symbol is used. In Figure B.6, the combination of “number” being line number for a Line Item and Purchase Order being composed of a Line Item are required to identify uniquely an occurrence of the Line Item entity type. This is shown by the uniqueness constraint, represented with a circled “u” between the line number of and the composed of roles. This implies that a given number (such as “2”), while it is a line number for only one line item, could apply to more than one purchase order, and a given purchase order could be related to more than one line number. The combination of “Line Number of” and purchase order must be unique, however.

A sub-type is represented as a separate entity type, with a thick arrow pointing from it to its super-type. In Figure B.6, organization and person are each sub-types of party, as shown by the arrows. In addition, a “type” attribute is defined as the flag which distinguishes between occurrences of the sub-types (“party type” in Figure B.6). If the sub-types are exhaustive (covering all occurrences of the super-type), a constraint is shown next to the “type” attribute. If they are exclusive (non-overlapping), a double-headed line is shown over half of the relationship between the entity type and its “Type”.

In Figure B.6, the sub-types of party are exclusive, because the double-headed arrow over is an example of party type, meaning that a party is an example of one and only one party type. It is exhaustive because only the options “P” (person) and “O” (organization) are available for Party Type.

In the ORM system of notation, constraints between relationships are shown as circles linked to the relationships involved. An “exclusion constraint” (shown in the figure between the Product and Service relationships from line item) says that one or the other relationship may apply, but not both. The “X” in the symbol means that a Line Item may not be for both a Product and a Service. The dot over the middle of the “X” () means that a Line Item must be for a Product or a Service, but not both. If there were a dot by itself, it would mean that one or the other must apply, but both could apply as well. With no constraint, one or the other, both, or neither could apply.

(See the discussion of ORM constraints in Chapter 8 on pages 311–332.)

In many ways, ORM is the most versatile and most descriptive of the modeling techniques presented here. It has an extensive capability for describing constraints that apply to sets of entity types and attributes. It is not oriented just toward entity types and relationships, but toward objects and the roles they play—where an “object” may be an entity type or a value type (domain). It is constructed to make it easy to describe diagrams in English, although it lacks a discipline for constructing the English sentences.

Cardinality is shown via uniqueness constraints, and optionality is shown by making a relationship mandatory or not. Interestingly enough, this approach means the optionality and cardinality of attributes can be treated in exactly the same way. Must there be a value for an attribute? Can there be more than one?

Unlike all the flavors of entity/relationship modeling described here, ORM makes domains explicit.

All this expressiveness, however, is achieved at some aesthetic cost. A ORM model is necessarily much more detailed than an equivalent data model, and as a consequence, it is often difficult to grasp the shape or purpose of a particular drawing. Also, because all entity types, attributes, and relationships carry equal visual weight, it is hard to see which elements are the most important.

While it does permit showing multiple inheritance and multiple type hierarchies, the multibox approach to sub-types takes up a lot of room on the drawing, limiting the number of other entity types that can be placed on it. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type. ORM also requires a great deal of space to give a separate symbol to each value type and relationship to it.

All of this could be mitigated by a CASE tool that permitted a model to be drawn in one form and then converted automatically to the other. The entity/relationship version could be used to convey the overall shape of the model and the important relationships, while the ORM version could portray the relationships in more detail.

As stated above, in object models, entity types are called classes. A class in the UML static model is a square-cornered rectangle with three divisions. The top part contains the class name. The middle section contains a list of attributes. The bottom, if included, contains descriptions of behavior. Since the UML is used mostly for design, these behavior descriptions are usually in the form of pseudo-code, C++, or simply program names, or simply references to programs.

An attribute can be referred to by one or more of the following elements:

There are no spaces between the words in names. The class is called PurchaseOrder instead of Purchase Order.

The UML introduces the concept of stereotype, which is an additional annotation that can be used to enhance the standard UML notation. If you don't like something about UML, you can change it! A stereotype is identified by being surrounded by guillimets (« »), and can be used to extend entity type, attribute, and association definitions. In Figure B.8, the stereotype «ident» extends the model to denote unique identifiers. (See “Unique Identifiers” on page 375, below.)

A relationship is called an “association” in the object-oriented world. Rather than using graphic symbols, all the information on a UML association is conveyed by characters.

<lower limit>
..
<upper limit>

Unique identifiers are rarely referred to in the object-oriented world. When the behavior of objects in a class requires locating a particular occurrence of another class, however, the attribute used for locating that occurrence is shown in a box next to the entity type needing it. For example, in Figure B.8, “PO number” is required from the point of view of Party to locate a particular Purchase Order. This reflects the programming that will be required to navigate from Party to Purchase Order when the classes are implemented, but it is not meaningful in an analysis model.

Alternatively, stereotypes can be used to designate attributes and relationships that constitute unique identifiers, in a structure very similar to that of the Barker notation. These are shown as «ident» in Figure B.8.

The UML shows sub-types as separate entity-type boxes, each removed from its super-type and connected to it by an “isa” relationship. (Each occurrence of a sub-type “is a[n]” occurrence of the super-type.)

Note in Figure B.8 that the sub-type structure is labeled {disjoint, complete}. This is equivalent to the rule in other notations that each occurrence of the super-type must be a member of one of the sub-types (complete), and an occurrence may not be a member of more than one sub-type (disjoint). In UML, this constraint is not required. The sub-type structure could be {overlapping, incomplete} or any other permutations of the two.

Constraints between relationships are shown as dashed lines between pairs of associations. Such a line is called a constraint. If it is annotated {xor} or simply {or}, it is an exclusive or. In Figure B.8, a constraint says that each occurrence of LineItem must be (or may be) either for an occurrence of Product or for an occurrence of Service, but not both. If it were {ior}, however, it would be an inclusive or. (Each occurrence of the base entity type must be (or may be) related to either an occurrence of one entity type, or to an occurrence of the other, or both.) Indeed, the dashed line can represent any relationship desired between two associations.

UML has a number of advantages over its predecessors:

These are valuable concepts. The first three could easily be added to other notations, with good effect. The fourth cannot, but it is rare that such a construct is needed, so its omission in other notations is not a serious practical problem. Such specific upper limits tend to be derived from business rules that might change, so it is not a good idea to include them in a conceptual data model. In the fifth case, the requirement that sub-types be complete and disjoint turns out to be a very useful discipline that produces much more rigorous models than if the restriction were relaxed. The final case describes a point which is controversial even in the object-oriented world. In your author's experience, nearly all examples that appear to require multiple-inheritance or multiple-type hierarchies can be solved by attacking the model from a different direction.

All of these may be valuable, however, if the model is being used to support design.

Other aspects of UML, however, are problematic if the models are to be presented to the public for requirements analysis.

First of all, in UML, cardinality and optionality are represented by numbers instead of graphic symbols. Yes, this has the advantage of permitting any kind of cardinality, such as 1, 4–6, 7, but requirements for such a statement are rare. It has the disadvantage, however, of making it an intellectual exercise to decode the symbols—instead of a visual processing one. You no longer “see” the relationship. You must “understand” it. The left side of the brain is used instead of the right. With information engineering or with Mr. Barker's notation, the entire process of decoding how many participants there are in a relationship is a visual one—and this makes the models much easier to read for those untutored in the notation.

The shorthand of using an asterisk for “may be one or more” and a one for “must be one and only one” in one sense simplifies the UML model, since these are the most common cardinalities and optionalities. On the other hand, it destroys the systematic semantic structure in which you automatically know both the upper and lower limits.

Second, the UML has added unnecessary symbols for specific kinds of relationships. The concepts of composition and aggregation are handled in entity-type/relationship diagrams by simply labeling a relationship part of and composed of. Having special symbols for two of the many possible kinds of relationships unnecessarily complicates the model.

More significantly, these additional symbols are incomplete. They represent the cascade delete and nullify delete rules for “composed of/part of” relationships, but what about the restricted delete rule? (You may not delete the parent at all if children exist.) And what about showing these rules for other relationships? Adding “C”, “R”, or “N” to an e/r diagram uniformly describes whether deletion of the parent is permitted and whether it calls for deletion of the children—regardless of the relationship. In addition, Entity-Type Life Histories more completely describe how entity-type occurrences may be created and under what circumstances they can be deleted (see Chapter 7, pages 262–282).

The justification for these symbols turns out to be that there are physical design implications for the aggregation and composition concepts. In an object-oriented implementation, it is possible for one object to be physically inside another object. Showing the diamonds on a UML design model provides information to the programmers. This is, however, both distracting and unnecessary in the conceptual model used for requirements analysis.

As stated previously, while it does permit showing multiple-inheritance and multiple-type hierarchies, the multi-box approach to sub-types takes up a lot of room on the drawing, limiting the number of other entity types that can be placed on it. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type.

There are two other shortcomings of the UML, but these can be addressed, either through the use of stereotypes or by imposing discipline on the way the UML is used.

In the first case, the UML could be significantly improved by increased discipline in the use of relationship names. Most commonly a relationship name in the UML is a single verb that describes it in one direction. Were this the only option, it would be unacceptable. It is, however, possible to add “roles” to each end of the relationship. This provides the ability to portray how an entity type is viewed from the perspective of another entity type. Given this structure, it would be valuable if these role names were constrained to follow the Barker naming convention.

Second, the UML deals only partially with unique identifiers. The philosophy behind object orientation is that it isn't necessary explicitly to show unique identifiers. But then it turns out that, from the point of view of a parent entity type, it is often necessary to identify occurrences of a child entity type. So “qualified associations” allow this to be expressed. But you are allowed to identify an occurrence only to a parent entity type. You are not allowed to identify it to the world at large.

This means that, instead of a simple symbol attached to a relationship or attribute to indicate a unique identifier universally, you have to add a whole new box whose meaning is constrained and confusing at best.^[3]

Note that this can be addressed using stereotypes as described above. In Figure B.8, “«ident»” was added to several attributes and a relationship to show their participation in unique identifiers.

This doesn't mean that the UML shouldn't be used for the physical design model. To the contrary, the additional expressiveness described here makes it eminently suitable for that purpose. (And designers are not the least bit bothered by the aesthetic objections raised above.) But the UML is fundamentally that—a design tool.

Figure B.9 shows an example of XML used to describe a data record that might be presented in a document.

<?XML version="1.0"?>
<!-- **** Purchasing **** -->
<PURCHASE_ORDER>
  <ISSUED_TO_PARTY>
       <party_id>234553</party_id>
       <name>Acme Sporting Goods</name>
       <party_type>Organization</party_type>
       <surname></surname>
       <corporate_mission>Get America
       moving</corporate_mission>
  </ISSUED_TO_PARTY>
  <po_number>743453</po_number>
  <order_date>12 November, 1999</order_date>
  <LINE_ITEM>
       <line_number>1</line_number>
       <quantity>12</quantity>
       <price>64.75</price>
       <product_service_indicator>
          product
       </product_service_indicator>
       <PRODUCT>
          <product_code>X-23</product_code>
          <description>Nike sneakers</description>
          <unit price>75.00</unit_price>
       </PRODUCT>
   </LINE_ITEM>
 <LINE_ITEM>
      <line_number>2</line_number>
      <quantity>12</quantity>
      <price>64.75</price>
      <product_service_indicator>
        service
      </product_service_indicator>
      <SERVICE>
          <service_id>x-87</product_code>
          <description>Walking the dog</description>
          <rate_per_hour>12.00</rate_per_hour>
      </SERVICE>
   </LINE_ITEM>
   <LINE_ITEM/>
</PURCHASE_ORDER>

Note a few interesting things about this example.

First, as with HTML, each tag is surrounded by less-than and greater-than brackets (<>) and is usually followed by text. The text is in turn followed by an end tag, in the form </...>. A tag may have no content, in which case either the end tag follows immediately upon the tag (as in <surname></surname>), or the tag itself ends with a forward slash (as in <LINE_ITEM/>). Unlike with HTML, however, the end tag is always required in one of those two forms.

A second thing to note is that, in this case, following the tag for <PURCHASE_ORDER>, a set of related tags follow, describing characteristics (columns and relationships from data models, in this case) of <PURCHASE_ORDER>. In this particular case, the tag <PURCHASE_ORDER> has been defined such that it must be followed by exactly one tag for <ISSUED_TO_PARTY>, one for <po_number>, and so forth. You can't see this from the example, but the tag <corporate_mission> is optional. In addition, the tag for line_item is also optional, and there may be one or more occurrences of it.

Although it is optional, all XML documents should begin with <?XML version="1.0"?> (or whatever version number is appropriate.)

Note that the structure is hierarchical, so that an element can be under only one other element, and there can be only one hierarchy in a document. In the example, therefore, party was only defined as <ISSUED_TO_PARTY> under <PURCHASE ORDER>. If it were related to something else in the model, the description would have to be repeated.

Comments are in the form <!-- . . . --> Note that the double hyphens must be part of the comment. Note also that, unlike HTML, XML lets you use a comment to surround lines of code that you want to disable.

The meaning of a tag is defined in a document type declaration (DTD). This is a body of code that defines tags through a set of elements. It is the DTD that allows you to specify a data structure. While an XML document contains data, the DTD contains the model of those data.

It is the DTD that is the analogy to the modeling techniques we have seen in this appendix.

The DTD for the above example is shown in Figure B.10.

<!DOCTYPE PURCHASE_ORDER [
   <!ELEMENT PURCHASE_ORDER (ISSUED_TO_PARTY, po_number,
   order_date, LINE_ITEM*)>
          <!ELEMENT ISSUED_TO_PARTY (party_id, name,
          party_type, surname?, corporate_mission?)>
                 <!ELEMENT party_id (#PCDATA)>
                 <!ELEMENT name (#PCDATA)>
                 <!ELEMENT party_type (#PCDATA)>
                 <!ELEMENT surname (#PCDATA)>
                 <!ELEMENT corporate_mission (#PCDATA)>
          <!ELEMENT po_number (#PCDATA)>
          <!ELEMENT order_date (#PCDATA)>
          <!ELEMENT LINE_ITEM (line_number, quantity, price,
                 product_service_indicator, PRODUCT?,
                 SERVICE?)>
             <!ELEMENT line_number (#PCDATA)>
             <!ELEMENT quantity (#PCDATA)>
             <!ELEMENT price (#PCDATA)>
             <!ELEMENT product_service_indicator (#PCDATA)>
             <!ELEMENT PRODUCT (product_code,
             description,
                    unit_price)>
                    <!ELEMENT product_code (#PCDATA)>
                    <!ELEMENT description (#PCDATA)>
             <!ELEMENT unit_price (#PCDATA)>
             <!ELEMENT SERVICE (service_id, description,
             rate_per_hour)>
                    <!ELEMENT service_id (#PCDATA)>
                    <!ELEMENT description (#PCDATA)>
                    <!ELEMENT rate_per_hour (#PCDATA)>
]

The DTD for an XML document can be either part of the document or in an external file. If it is external, the DOCTYPE statement still occurs in the document, with the argument “SYSTEM -filename-”, where “-filename-” is the name of the file containing the DTD. For example, if the above DTD were in an external file called “xxx.dtd”, the DOCTYPE statement would read:

<!DOCTYPE PURCHASE_ORDER SYSTEM xxx.dtd>

The same line would then also appear as the first line in the file xxx.dtd.

Note that the name specified in the DOCTYPE statement must be the same as the name of the highest-level ELEMENT.

Each element in the specification refers to a piece of information. An XML element is defined in terms of one or more predicates, where a predicate is simply a piece of information about an element. This may be either an attribute or an entity type in your data model. In the example above, <PURCHASE_ORDER> has as predicates <ISSUED_TO_PARTY>, <po_number>, <order_date>, and <LINE_ITEM>. <ISSUED_TO_PARTY> and <LINE ITEM> are relationships to the parent entity type in the data model that this was based on. <Po_number>, and <order_date> are attributes from that model.

XML has no way to recognize unique identifiers.

XML has no way to recognize sub-types and super-types. Note, in the example above, that the attributes of <ISSUED_TO_PARTY> had to include both attributes of person and attributes of organization from our other models. The attribute <product-service-indicator> was included in <LINE_ITEM> to determine which case was involved. Similarly, <Party_type> determined which kind of <ISSUED_TO_PARTY> a record referred to. Software would be required to enforce this.

XML has no way to describe constraints between relationships.

As noted above, XML isn't really a data-modeling language. It is not very sophisticated in its ability to represent the finer points of data structure. It shares the limitations of a relational database, for example, with no ability to recognize sub-types or constraints. It is being recognized, however, as a very powerful way to describe the essence of data structures for use as a template for transmitting data from one place to another.

While the tag structure does seem to be a good vehicle for describing and communicating database structure, the requirement for discipline in the way we organize data is more present than ever. XML doesn't care if we have repeating groups, monstrous data structures, or whatever. If we are to use XML to express a data structure, it is incumbent upon us to do as good a job with the tool as we can. (This is, of course, true of any modeling technique.)

In recognizing that XML is a good vehicle for describing database structure, the most obvious issue is that this will put greater responsibility on data administrators to define data correctly. XML will not do that. XML will only record whatever data design (good or bad) human beings come up with.

As Clive Finkelstein has said, the advent of XML is going to make data modelers and designers even more important than they are now. “After fifteen years of obscurity, data modelers can finally become overnight successes” [Finkelstein, 1999].

There are several arguments in favor of Mr. Barker's data-modeling syntax for use in requirements analysis:

While Mr. Barker's notation is preferred as a requirements analysis tool, UML is more complete and detailed and therefore the most suited to support design—particularly object-oriented design.

The method for annotating optionality and cardinality is much more expressive of different circumstances than any of the other techniques. It can specifically say that an occurrence of an entity type is related to 1, 7–9, or 10 occurrences of another entity type.

The UML can describe many more constraints between relationships than can other notations. With proper annotation, it can describe both exclusive and inclusive or relationships, or any other that can be named.

For business rules that are not simple relationships between two associations, UML introduces a small flag that can include text describing any business rule.

Attributes can be described in more detail than in other notations.

Overlapping and incomplete configurations of sub-types are allowed.

“Multiple inheritance”, where a sub-type may be one of more than one super-types, is permitted, as are multiple type hierarchies. While these may not be desirable in analysis models, they could be useful as solutions to particular design problems.

In an object-oriented environment, the extra symbols address specific object-oriented situations.

For the reasons described above, it is not advisable to use IDEF1X in an analysis project, since the notation is far too complex to present to a non-technical audience. This complexity, however, is exactly what makes it a good tool for representing relational database design. Its notation highlights the existence of foreign keys, and these are documented explicitly. The differences in annotating optionality and cardinality reflect the different way these could be implemented.

The ideal CASE tool, then, will be one which supports Mr. Barker's techniques for doing requirements analysis, then has the facilities for converting entity-type definitions into either (1) table definitions or (2) class definitions that can be used by C++ or a similar language. It would then have the ability to represent these design artifacts in IDEF1X or the UML for further refinement.