Page 168 -
P. 168

DOMAIN  MODELING  OF  OBJECT-ORIENTED  INFORMATION  SYSTEMS     153
                             The Women’s Senior team from club Flippers for event Beam in meet Town Invitational
                             receives the score of 41.5. (Sentence A)

                      This sentence forms a meaningful unit of information. Note that in order to talk about the score
                    of 41.5, we need to include the other four data items (italicized in sentence A). For example, it is
                    obvious that we cannot omit the club’s name from this sentence; if we do that, we get a meaning-
                    less sentence. To derive a fact type from sentence A, we note that 41.5 is the score that a team
                    receives for an event. That is, the fact type is of the form:

                             Team ( ) . . . receives Score ( ) . . . for Event ( ) . . . (Sentence B)

                      In the context provided by sentence A, we can see clearly what we mean by a “team”: a “team”
                    is “a team from a club for a competition type in a meet.” Therefore, it is identified by the combina-
                    tion of the club’s name, competition type’s name, and the meet’s name. And similarly, an event
                    is identified by a combination of the meet’s name, the competition type’s name, and event type’s
                    name. Adding the reference scheme to sentence B, we have the fact type (with informal notation
                    being used for reference schemes):


                             Team (club name + competition type name + meet name) . . . receives Score (number)
                             . . .
                             for Event (meet name + competition type name + event type name) . . . (Sentence C)


                      It is conceptually clearer to write the above fact type (sentence C) using the following “non-
                    standard” format in which square brackets are used to denote the reference schemes of the entity
                    types they enclose:


                             Team ([Club] + [Competition Type] + [Meet]) . . . receives Score (number) . . . for
                             Event ([Meet] + [Competition Type] + [Event Type]) . . . (Sentence D)

                      As a validity check, we note that sentence A can be rewritten in the format of sentence D as
                    the sentence E below, which contains precisely the same information:
                             Team identified by Club Name “Flippers” and Competition Type Name “Women’s
                             Senior Team” and Meet Name “Town Invitational” receives Score of 41.5 for Event
                             identified by Meet Name “Town Invitational” and Competition Type Name “Women’s
                             Senior Team” and Event Type Name “Beam.” (Sentence E)

                      (Note: In the above sentence, there is an important constraint regarding the Competition Type
                    Name and Meet Name. The same values for them should appear as part of the identification of
                    both the Team and the Event. This situation is sometimes known as “derived redundancy.” The
                    constraint can be formally expressed if desired. Perhaps more important, in implementing any use
                    case that involves the creation of facts of these fact types, we need to ensure that the constraints
                    are satisfied. As far as the single fact type D is concerned, we can eliminate the redundancy using
                    an objectified relationship. In doing so, however, concepts such as “team” may not be represented
                    explicitly, which generally is not a desirable outcome.)
                      The key to the above analysis is actually sentence A. It provides a “context” in which we can
   163   164   165   166   167   168   169   170   171   172   173