The next notation was originally developed by the British consulting company CACI. It was subsequently promoted by Richard Barker [Barker 1990] and adopted by the Oracle Corporation for it’s "CASE*Method" (subsequently renamed the "Custom Development Method"). Figure 4 shows our example, as represented in this notation. In the diagram, each purchase order must be issued to a party, and may be composed of one or more line items, each of which in turn must be for either one product or one service.

Entities in Barker’s notation are shown as round cornered rectangles. Attributes may be displayed inside the entity boxes.

Officially, attributes are shown with small open circles for optional attributes, solid circles for required attributes, and hash marks (#) for attributes which participate in unique identifiers. Often in practice, however, (and throughout this book), 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. Naming conventions allow the relationship at each end to be read as a concise, disciplined, but easy-to-understand sentence.

A unique identifier is defined to be any combination of attributes and relationships which uniquely identifies an occurrence of an entity. Attributes which are parts of the definition of a unique identifier are shown preceded by hash marks (#). Relationships which are part of the definition of a unique identifier are marked by a short line across the relationship near the entity being identified.

For example, in Figure 4, the unique identifier of line item is a combination of the attribute "line number" and the relationship "part of one and only one purchase order." Since the marked relationship represents the fact that each line item is partly identified by a particular purchase order, it implies that the purchase order’s unique identifier "PO number" participates in identification of the line item as well. When implemented, a column derived from "PO number" will be generated in the table derived from line item. It will serve as a foreign key to the table derived from purchase order, and will be part of the primary key of the table that is derived from line item.

Note that Mr. Barker’s notation distinguishes the unique identifier in the conceptual model from the "primary key" which identifies rows in a physical table. The unique identifier is shown, while the primary key is not. Similarly, since a foreign key is simply the implementation of a relationship, it is not shown explicitly here either.

Barker’s notation shows sub-types as boxes inside super-type boxes. 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.

In Barker’s notation, sub-types are mutually exclusive, meaning that overlapping sub-types are not allowed. Subtypes 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 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 may be (or must be) related to occurrences of one or more other entities, but not more than one. For example, Figure 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. Whether it is a role, an interaction, or another kind of association between two entities, 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 with 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. Other notations are, to varying degrees, more complicated than that.

Attributes may be shown with indicators of their optionality.

Second, sub-types are shown as entities inside other entities. 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.

Third, Barker’s notation permits "exclusive or" constraints between relationships, which show that an occurrence of one entity may be related to occurrences of either of two or more other entities. This is more than is available in some notations, and less than is available 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 are "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 significantly improves 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 endorse it.