Page 173 -

158 NGUYEN AND DILLON
Validating by Traversing the Conceptual Schema Diagram

Once the conceptual schema diagram (CSD) has been constructed, it is useful to traverse it as
a validation check, in order to verify that the relevant fact types are represented. Once again,
the order of data entry comes in handy: we can traverse the CSD on the basis of this ordering.
Thus, given the ordering: (1) Add a club, (2) Enter a gymnast (3) . . . , we can inspect the CSD
and say to ourselves: “Obviously, I can enter facts about a club. Now I can enter facts about a
gymnast including the club to which he or she belongs. That fact type is here on the diagram.
And so on.”
As we go over the fact types in the CSD in this manner, we can also identify the constraints
among the facts. For example, when it comes to register a judge for an event, not only do we need
fact type Judge ( ) . . . is assigned to Event ( ) . . . , but we also have the constraint that a judge
can judge only those events for which he/she is qualified.
Note: Another validation technique, which is not time-consuming at all, is to derive a relational
schema from the ORM conceptual schema, and then subject it to an inspection. Again, this can
be done systematically by walking through the use cases in the order suggested above and seeing
how the relational schema can support the use cases. Experience has shown that by inspecting the
relational schema, a lot of sense can be made of the data model, and mistakes, if any, can often
be easily picked up.
Deriving a Domain Class Model for the Gymnastics System

Mapping attribute-free models to models with attributes has been an active area of research in ORM.
On a formal basis, Bollen (2002) describes an elaborate procedure to map an ORM conceptual
schema diagram to a UML class diagram. Alternatively, we can apply a schema abstraction based
on major object types, which are derived from the constraint patterns in the given ORM model.
A brief introduction to this technique is given in Halpin (2001), and a detailed treatment is given
in Campbell, Halpin, and Proper (1996).
For this chapter, we choose to use a simple intuitive, and yet quite effective, approach to convert
the ORM model for the Gymnastics System into a UML class model. The approach is based on
two simple heuristic rules:
• Heuristic Rule 1. There are groups of fact types with a simple key attached to a common
object type, which can be an entity type, a subtype, or an objectified relationship. Each of
these groups, in most cases, represents a class that we are trying to identify.
• Heuristic Rule 2. Each of the remaining fact types, in most cases, represents a relationship
type.

The heuristic rules work well in practice because, once we have constructed the ORM model,
we will have gained a very clear understanding of the “information structure” of the application
domain, that is, the kinds of things that we can say about it, and it is this clear understanding that
allows us to effectively apply the heuristic rules to reach our goal.
For the Gymnastics case study, most of the fact types fall into groups with simple keys attached
to a common object. Let us consider these groups.

1. Group attached to Club: “Club is at Address,” “Club has Phone.” Clearly, this group can
be represented by the class Club.