Practical Guidelines for Supertype and Subtype Modeling - High-Performance Web Databases: Design, Development, and Deployment - page 325

seen by noting that the two schemas constrain completely different prop-
erties in the matrix. Unfortunately, not all independent schemas are as
obvious. For example, it is a mistake to perceive the INACTIVE EMPLOYEE
subtype as containing a single additional subtype schema that is repre-
sented by the RETIRED EMPLOYEE, DECEASED EMPLOYEE, and RESIGNED
EMPLOYEE subtypes. The properties constrained by the RETIRED
EMPLOYEE and RESIGNED EMPLOYEE subtypes are the same, while the
DECEASED EMPLOYEE subtype constrains other properties. There are two
different subtype schemas at work here and they must not be arbitrarily
combined because such a combination may contradict business informa-
tion that has not yet been discovered.
Metadata Tables
The list variability problem that cannot be addressed by the entity con-
straint matrix is one of inexhaustability. Many projects encounter business
areas that have subtype lists which are not fixed over time. A requirement
often exists to be able to add additional subtypes or remove existing sub-
types after the implementation of a system. For these projects, applica-
tions must be written that are table-driven. Other applications may be able
to list all valid subtypes, but the list and its associated entity constraint
matrix is so complicated that a table-driven approach is the only viable
application architecture.
Some of these situations arise within the set of subtype schemas and do
not require the entire application to be written in a table-driven format.
Examples of these situations are found through the nesting of exclusive
subtype schemas within the entity constraint matrix. In Exhibit 5, the
ACTIVE EMPLOYEE and INACTIVE EMPLOYEE schema is exclusive (e.g.,
the ASSIGNED DEPARTMENT properties are contradictory). Within the
INACTIVE EMPLOYEE schema, the exclusive schema for RETIRED
EMPLOYEE and RESIGNED EMPLOYEE exists. This exclusivity may remain
hidden if the DECEASED EMPLOYEE subtype is not isolated as a different
subtype schema. It is still not clear, however, whether the subtypes of
INACTIVE EMPLOYEE are exhaustive. If they are not and an exhaustive list
cannot be discovered during analysis, then this subtype schema should be
physically implemented using a logical table of reasons of inactivity. Rather
than implementing the RESIGNATION DATE and RETIREMENT DATES fields
(i.e., the exclusive subtype option), the physical application should imple-
ment INACTIVE DATE and INACTIVE REASON CODE fields. The reason code
domain might initially be resigned and retired, but may be expanded in the
future without substantive changes to the production application.
On some projects, the subtype schema's ambiguity exists at the highest
supertype level. Application models that do not exhaust the list of major
subtypes before implementation are prone to major enhancement activity