6.7. Summary

A set is determined by its members, so order and repetition don’t matter, e.g., {3, 6} = {6, 3, 6}. A bag or multiset makes repetition significant, e.g., [3, 6] = [6, 3] but [3, 6] ≠ [3, 6, 6]. A sequence is an ordered bag, e.g., (3, 6) ≠ (6, 3). A set A is a subset of B (written A ⊆ B) iff each member of A belongs to B; in this case B is a superset of A. A is a proper subset of B iff A ⊆ B and A ≠ B. A and B are mutually exclusive or disjoint iff they have no common members, i.e., their intersection, A ∩ B = { }. If sets have common members they overlap; if each also has extra members, we have a case of proper overlap.

CSDP step 6 adds any value, set-comparison (subset, equality, exclusion), and subtype constraints. A value constraint specifies the possible values for a value type or role. It may provide a full listing or enumeration of all the values, e.g., {‘M’, ‘F’}, a subrange definition, e.g., {1..7}, {‘A’..’E’}, or a combination of lists and ranges.

A value constraint may also indicate a syntactic data type (e.g., variable length text of at most 20 Unicode characters). If the underlying data type is real number (e.g., float or decimal), a square bracket/parenthesis signifies inclusion/exclusion of the end value. For example, “(0..100]” denotes the positive real numbers up to and including 100.

An independent object type is a primitive object type whose instances may exist independently of playing any fact roles (the fact roles are collectively optional). Independent object types have “!” appended to their name. For example, we may populate a reference table for “Country!” with the names of all existing countries, even if some of these countries do not play in any elementary facts. In principle, the values that reference members of an independent object type could instead be declared in a value constraint; however, this is awkward if the values may change or there are many values that cannot be specified as a range.

Set-comparison constraints restrict the way the population of a role, or role sequence, relates to the population of another. Let rs1 and rs2 be role sequences (of one or more roles) played by compatible object types. A subset constraint from rs1 to rs2 is denoted by an arrow in that direction, including a circled “⊆” symbol. This indicates pop(rs1) ⊆ pop(rs2).

An equality constraint is equivalent to subset constraints in both directions. It is shown by a dotted line with a circled “=” symbol, demanding that pop(rs1) = pop(rs2).

An exclusion constraint among two or more role sequences is shown by connecting them to “⊗” with dotted lines: this means their populations must be disjoint (mutually exclusive).

If a set of roles is disjunctively mandatory and mutually exclusive, this may be shown by the lifebuoy symbol . This exclusive-or constraint symbol is simply the inclusive-or constraint symbol ⊙ overlaid on the exclusion constraint ⊗.

If each role sequence contains two roles, we talk of pa/r-subset, pair-equality, and pair-exclusion constraints. A tuple-subset constraint implies simple subset constraints. A simple exclusion constraint implies tuple exclusion. Theorem NXS states that no exclusion constraint can have exactly the same arguments as a subset constraint.

An object type A is a (proper) subtype of B iff (A ≠ B and) for each database state, pop(A) ⊆ pop(5). We show this by an arrow from A to B. If A is a subtype of B, and B is a subtype of C, then it is transitively implied that A is a subtype of C; such indirect subtype links should not normally be displayed.

An object type may have many subtypes and many supertypes. Subtype connections among a family of compatible object types are displayed in a directed, acyclic subtype graph. This graph has exactly one root node (or top), which must be a primitive object type (or, in rare cases, an objectified association).

In ORM, subtypes are typically introduced to declare that one or more roles are played only by that subtype. The process of introducing subtypes is called specialization. Subtypes inherit all the roles of their supertype(s) and normally have at least one specific role. By default, a subtype inherits the preferred reference scheme of a direct supertype; in this case the reference scheme is not displayed on the subtype. With subtypes (and objectified associations), any mandatory roles must be explicitly shown.

A subtype may be derived, asserted, or semiderived. Each derived subtype must be formally defined in an equivalence derivation rule using one or more roles of its super-type(s). For example, Each FemalePerson is a Person who is of Gender ‘F’. Derived subtypes are marked “*”. With derived subtypes, all relevant constraints on defining predicates must be declared; this ensures that any subtype exclusion “⊗” or totality “⊙” constraints that do exist are implied. Exclusive object types (e.g., Man, Woman) cannot have a common subtype. Asserted subtypes are simply asserted without any derivation rule. Semiderived subtypes may have both derived and asserted instances; these rare subtypes are marked “+” and have conditional derivation rules.

Output reports often have missing values or nulls. Subtyping is indicated if a missing value means “not to be recorded” (i.e., inapplicable because of other recorded data). This book uses a minus sign “–” for this purpose. If an output report is significant with respect to the subtype graph, we can determine the graph by examining the pattern of “–” marks. However, background knowledge is required to determine the subtype definitions, and hence meaningful subtype names. Input forms often provide a set of conditional instructions that indicate the conditions under which particular entries on the form are needed. Such instructions can be used to deduce the subtyping constraints. Sometimes reports are already separated on the basis of subtyping and their report titles give clues as to the subtyping scheme.

Without a full set of output reports, we might wrongly declare object types to be primitive. We then need to introduce supertypes; this process is called object type generalization, the reverse of specialization. We introduce a supertype if object types overlap, and we want to know this. A supertype is also introduced if the object types are exclusive, but have common roles, and we want to list them together for this common information. If the original object types have specific roles, they must be retained as subtypes.

In some cases there is a need for subtypes to have a preferred reference scheme different from that of their supertype(s). Such a context-dependent reference is indicated by displaying the preferred reference scheme on the relevant subtypes. A subtyping arrow appears as a solid arrow if it provides a path to the subtype’s preferred identifier, otherwise it is shown as a dashed arrow.