Richard Barker s Notation (as Used by Oracle Corporation) | Requirements Analysis: From Business Views to Architecture


Team-Fly

	Requirements Analysis: From Business Views to Architecture By David C. Hay
	Table of Contents

	Appendix B. A Comparison of Data Modeling Techniques (Syntactic Conventions)

Richard Barker's Notation (as Used by Oracle Corporation)

The next notation was originally developed by the British consulting company CACI and is part of the European methodology, SSADM. It was subsequently promoted by Richard Barker [Barker, 1990] and adopted by the Oracle Corporation for its "CASE*Method" (subsequently renamed the "Custom Development Method" [Oracle, 1996]).

Figure B.4 shows our example as represented in this notation. In the diagram, each PURCHASE ORDER must be issued to one and only one 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 . Also, each EVENT may be in one and only one EVENT TYPE , while each EVENT TYPE must be a classification for one or more EVENTS.

Figure B.4. A CASE*Method Data Model.

graphics/bfig04.gif

Entity Types and Attributes

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

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 .

Cardinality/Optionality

Relationships are in two parts , one representing the relationship going in each direction. In a relationship half, different symbols address the upper and lower boundaries of the relationship: A dashed line near the first, subject, entity type shows that the relationship is optional and means "zero or more" (read as "may be"), and a solid line represents a mandatory relationship that means "at least one" (read as "must be"). A "crow's foot" next to the second entity type represents "up to many" (read as "one or more"), while no crow's foot represents "up to one" (read as "one and only one").

Names

The Barker notation is unique in the way it names relationships. Relationship names are prepositions or prepositional phrases, not verbs, so that normal and meaningful English sentences can be constructed from them. The sentences are of the structure:

 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>   .

For example, in Figure B.4, "Each party may be a vendor in one or more purchase orders," and "Each purchase order must be issued to one and only one party."

Unique Identifiers

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

For example, in Figure B.4, each occurrence of PARTY is identified by its "Party ID", and 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, this is not shown explicitly here either.

Sub-types

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 .

Constraints between Relationships

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 .

Comments

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.


Team-Fly

Top