Databases Reference
In-Depth Information
good taxonomy. For one thing, it says that persons are not
customers. But many companies do sell their goods or services
to people; so for them, this is a bad taxonomy. Either the label
“customer” is being used in a specialized (and misleading) way,
or else the taxonomy is simply wrong.
A related mistake is that, for most companies, Supplier, Self
and Customer are not mutually exclusive. For example, many
companies sell their goods or services to other companies who
are also suppliers to them. If this is the case, then this hierarchy
is not a taxonomy, because an instance—a company that is both
a supplier and a customer—belongs to more than one leaf node.
As a data modeling subtype hierarchy, it is a non-exclusive hier-
archy, not an exclusive one.
This specific taxonomy has nothing to do with temporal data
management; but it does give us an opportunity to make an
important point that most data modelers will understand. That
point is that even very bad data models can be and often are,
put into production. And when that happens, the price that is paid
is confusion: confusion about what the entities of the model really
represent and thus where data about something of interest can be
found within the database, what sums and averages over a given
entity really mean, and so on.
In this case, for example, some organizations may be
represented by a row in only one of these three tables, but other
organizations may be represented by rows in two or even in all
three of them. Queries which extract statistics from this hierar-
chy must now be written very carefully, to avoid the possibility
of double- or triple-counting organizational metrics.
As well as all this, the company may quite reasonably want to
keep a row in the Customer table for every customer, whether it
be an organization or a person. This requires an even more con-
fusing use of the taxonomy, because while an organization might
be represented multiple times in this taxonomy, at least it is still
possible to find additional information about organizational
customers in the parent node. But this is not possible when
those customers are persons.
So the data modeler will want to modify the hierarchy so
that persons can be included as customers. There are various
ways to do this, but if the hierarchy is already populated and
in use, none of them are likely to be implemented. The cost is
just too high. Queries and code, and the result sets and reports
based on them, have already been written, and are already in
production. If the hierarchy is modified, all those queries and
all that code will have to be modified. The path of least resis-
tance is an unfortunate one. It is to leave the whole mess alone,
