Peter Chen | 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)

Peter Chen

Peter Chen invented entity/relationship modeling in the mid-1970s [Chen, 1977], and his approach remains widely used today. It is unique in its representation of relationships and attributes. Relationships are shown with a separate diamond-shaped symbol on the relationship line, and attributes are shown in separate circles, instead of as annotations on each entity type.

A sample model, representing Chen's method, is shown in Figure B.1. This same example will be used to demonstrate all the techniques that follow. The model shows entity types, attributes, and relationships. It also has examples of both a super-type/sub-type combination and a constraint between relationships.

Figure B.1. A Chen Model.

graphics/bfig01.gif

In the diagram, each PURCHASE ORDER is related to a single PARTY and to one or more examples of either one PRODUCT or one SERVICE .

The diagram also includes two entity types ( EVENT and EVENT CATEGORY ) in an unusual relationship. In most "one-to-many" relationships, the "one" side is mandatory ("... must be exactly one"), while the "many" side is optional ("... may be one or more"). In this example, the reverse is true: Each EVENT may be in one and only one EVENT CATEGORY (zero or one), and each EVENT CATEGORY must be a classification for one or more EVENTS (one or more). That is, an EVENT may exist without being classified , or it may be in one and only one EVENT CATEGORY . An EVENT CATEGORY can come into existence, however, only if there is at least one event to put into it.

Entity Types and Attributes

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.

Relationships

Mr. Chen's notation is unique among the techniques shown here in that a relationship is shown as a two-dimensional symbola 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.

Cardinality/Optionality

In Mr. Chen's original work, only one number appeared at each end, showing the maximum cardinality. That is, a relationship might be "one-to-many", with a "1" at one end and an "n" at the other. This would not indicate whether or not an occurrence of an entity type had to have at least one occurrence of the other entity type.

In most cases, an occurrence of an entity type that is related to one occurrence of another must be related to one, and an occurrence of an entity type that is related to more than one may be related to none, so most of the time the lower bounds can be assumed. The event/event category model, however, is unusual. Having just a "1" next to event, showing that an event is related to one event category, would not show that it might be related to none. The "n" which shows that each event category is related to more than one event would not show that it must be related to at least one.

For this reason, the technique can be extended to use two numbers at each end to show the minimum and maximum cardinalities. For example, the relationship party-order between PURCHASE ORDER and PARTY shows 1,1 at the PURCHASE ORDER end, showing that each PURCHASE ORDER must be with no less than one PARTY and no more than one PARTY . At the other end, "0,n" shows that a PARTY may or may not be involved with any PURCHASE ORDER and could be involved with several. The EVENT / EVENT CATEGORY model has "0,1" at the EVENT end and "1,n" at the EVENT CATEGORY end.

In an alternative notation, relationship names may be replaced with "E" if the existence of occurrences of the second entity type requires the existence of a related occurrence of the first entity type. See "Unique identifiers" below for more about this.

Names

Because relationships are clearly considered objects in their own right, their names tend to be nouns.

The relationship between purchase-order and person or organization, for example, is called order-line . Sometimes a relationship name is simply a concatenation of the two entity type names. For example party-order relates party and purchase order.

Entity type and relationship names may be abbreviated.

Unique Identifiers

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.

graphics/bfig02.gif

Sub-types

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 .

Constraints between Relationships

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 .

Comments

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.


Team-Fly

Top