Chapter 5

Item Description Template

There are two templates that involve items and their description.

• Item description. Arises when the same model relates data and metadata. The item description template frequently occurs, but is visually less striking than other templates in this book—the template involves only two entity types and one relationship. You must exercise judgment in deciding when one entity type is metadata with regard to another.
• Homomorphism. Maps between two Item Description templates and expresses an analogy. The description of item 1 is to item 1 as the description of item 2 is to item 2. The relationship between items connects occurrences. The relationship between descriptions constrains occurrences.

5.1 Item Description Template

5.1.1 UML Template

Figure 5.1 shows the UML template for item description. The template involves data (Item) and metadata (ItemDescription) and typically appears when a model concerns both an item and its description. It is important to keep the two planes (data and metadata) separate or the model will be deeply flawed. A color coding or shading convention can be helpful; Figure 5.1 uses a white background for data and a light gray for metadata.

The item description template is useful if you cannot fully describe data as software is being developed. The template lets you enter data and its description at run time, as opposed to the more typical approach of defining data structure at compile time. Table 5.1 compares Item and ItemDescription.

5.1.2 IDEF1X Template

Figure 5.2 restates Figure 5.1 with the IDEF1X notation. The following is a foreign key: itemDescriptionID references ItemDescription.

5.1.3 SQL Queries

Figure 5.3 and Figure 5.4 show representative SQL queries for the template. The colon prefix denotes variable values that must be provided.

5.1.4 Sample Populated Tables

Figure 5.5 shows item description tables populated with data. The values of the IDs are arbitrary, but internally consistent.

5.1.5 Examples

The item description template occurs frequently. Of all the templates, it is the one you will find most often.

Figure 5.6 shows the nucleus of a model for motor vehicles. VehicleModel corresponds to ItemDescription and PhysicalVehicle corresponds to Item. Physical vehicles are items with individual identification numbers. In contrast, vehicle models refer to the year and make, such as 1986 Ford Escort and 1989 Mazda 626. Customer repair records refer to physical vehicles, while design documents describe vehicle models.

The library loan model in Figure 5.7 further demonstrates the template. A LibraryItem is something that a library offers for borrowing. A LibraryItemCopy is a physical copy of a LibraryItem. For example, a library may list The Grapes of Wrath in its card catalog (a Library Item) and have five copies of the book available (LibraryItemCopies).

Each category of LibraryItem (LibraryItemType) has a standard checkout period and number of renewals. For example, children's books may be checked out for a month, while adult books may be checked out for only two weeks.

A LibraryItem may have multiple PendingRequests to borrow the next available copy. In contrast, a LibraryItemCopy can have at most one Checkout at a time.

Figure 5.7 illustrates that there can be multiple levels of item description. LibraryItemType is metadata with regard to LibraryItem. And LibraryItem is metadata with regard to LibraryItemCopy. Thus Figure 5.7 applies the template twice. I omitted color coding from this diagram since there are three levels instead of two.

In addition, some types cannot be classified as data or metadata. For example, Person relates both to Checkout and PendingRequest. It is not entirely clear if Person should be treated as data or metadata.

Figure 5.8 shows another example, relating report definition to report execution.

5.2 Homomorphism Template

5.2.1 UML Template

Figure 5.9 shows the UML template for homomorphism. An analogy relates the item description template on the left to the item description template on the right. As with the previous section, a shading convention differentiates metadata from data. Light gray indicates metadata and white indicates data.

5.2.2 IDEF1X Template

Figure 5.10 restates Figure 5.9 with the IDEF1X notation. The following are foreign keys: itemDescription1ID, itemDescription2ID, item1ID, and item2ID.

5.2.3 SQL Queries

The homomorphism template has the same queries as the item description template — find the description given an item and find the items for a description. In addition a homomorphism is important for constraining data as Figure 5.11 illustrates.

Note that Figure 5.11 finds any data that violates the homomorphism constraint and could execute slowly due to the nested SQL inside the EXISTS clause. In practice data would probably be checked as it is entered, either with SQL or programming code, and the checking would be more efficient.

5.2.4 Sample Populated Tables

Figure 5.12 shows homomorphism tables populated with data. The example is entirely contrived and abstract, but it does indicate the mechanics of populating homomorphism tables. The values of the IDs are arbitrary, but internally consistent.

5.2.5 Examples

The homomorphism template is not as esoteric as it might seem. Analogies between item description templates do occasionally occur in practice. You will construct better data models if you recognize homomorphisms and show their symmetry in your model layout. The flight model in Figure 5.13 has one homomorphism.

An Airline offers PublishedFlights on a recurring basis. The flightNumber uniquely identifies each PublishedFlight for an Airline. Each PublishedFlight has one or more PublishedFlightLegs, each from some origin Airport to a destination Airport.

An Airport has an IATA code and a name. For example, some Airport names would be Chicago O'Hare and Houston Hobby with IATA codes of ORD and HOU.

An ActualFlightLeg is the flying of an Aircraft on a particular date corresponding to a PublishedFlightLeg. A PublishedFlightLeg denotes the intent to provide service on a regular basis. In contrast, an ActualFlightLeg is the actual provision of service on a particular date.

Normally there is one ActualFlightLeg for a PublishedFlightLeg and departureDate, but flight problems can lead to multiple ActualFlightLegs.

An AircraftModel is a standard kind of aircraft, such as a Boeing 727. An Aircraft is a physical specimen of an AircraftModel and is uniquely identified with its tail number.

Figure 5.13 has three occurrences of the item description template.

• PublishedFlightLeg to ActualFlightLeg
• AircraftModel to Aircraft
• SeatDescription to Seat

The example has one homomorphism.

• AircraftModel to Aircraft corresponds to SeatDescription to Seat.

Figure 5.14 extends the model of Figure 5.8 and shows another homomorphism. ReportDefinition relates to ReportExecution. ReportDefinitions have Variables; each Variable is assigned a Value for a ReportExecution.

Figure 5.15 extends the model of Figure 5.6 resulting in two homomorphisms, one with vehicle and event and the other with event and task. A tune-up is an example of a RepairEventType. The replacement of spark plugs, replacing points, and setting the timing are examples of RepairTaskType.

5.3 Chapter Summary

The item description template arises when a model relates data and metadata. There is one template for item description and the template frequently occurs.

The homomorphism template maps between two Item Description templates and expresses an analogy. The description of item 1 is to item 1 as the description of item 2 is to item 2. The relationship between items connects occurrences. The relationship between descriptions constrains occurrences. There is one template for homomorphism that occasionally occurs.

Table 5.2 summarizes the item description and homomorphism templates.

Note: Consider these templates when a model has both data and metadata.

Bibliographic Notes

[Coad-1992] also associates an item with its description.

[Rumbaugh-1991] discusses homomorphisms as part of advanced modeling. Section 2.5 of [Fowler-1997] does not mention the term homomorphism, but Fowler also distinguishes between metadata and data layers. He structures his model in a manner that shows the symmetry.

References

[Coad-1992] Peter Coad. Object-oriented patterns. Communications ACM 35, 9 (September 1992), 152-159.

[Fowler-1997] Martin Fowler. Analysis Patterns: Reusable Object Models. Boston, Massachusetts: Addison-Wesley, 1997.

[Rumbaugh-1991] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Englewood Cliffs, New Jersey: Prentice Hall, 1991.