TABLE OF CONTENTS So far you ve learned how to proceed from familiar information examples to a conceptual schema diagram in which the elementary fact types are clearly set out, with the relevant uniqueness constraints marked on each. You also learned to perform some checks on the quality of the schemas. In practice, other kinds of constraints and checks need to be considered also. Next in importance to uniqueness constraints are mandatory role constraints. Basically these indicate which roles must be played by the population of an object type and which are optional. Once mandatory role constraints are specified, a check is made to see if some fact types may be logically derived from others. This constitutes the next step in the design procedure.
The next two sections cover this step in detail. The rest of this section discusses some basic concepts used in our treatment of mandatory roles and later constraints. Once mandatory roles are understood, we are in a good position to examine reference schemes in depth, especially composite reference we do this later in the chapter.
Recall that a type may be equated with the set of all its possible instances. This is true for both object types and relationship types. For a given schema, types are fixed or unchanging. For a given state of the database and a given type T, we define pop(T), the population of
