Databases Reference
In-Depth Information
the root node only, every node has at least one child node. Each
node except the root node has as ancestors all the nodes from its
direct parent node, in linear ascent from child to parent, up to
and including the root node. No node can be a parent to any
of its ancestors.
Partitioned
. The set of child nodes under a given parent node
are jointly exhaustive and mutually exclusive. Being jointly
exhaustive means that every instance of a parent node is also
an instance of one of its child nodes. Being mutually exclusive
means that no instance of a parent node is an instance of more
than one of its child nodes. A corollary is that every instance of
the root node is also an instance of one and only one leaf node.
Semantic
. The relationships between nodes are often called
links. The links between nodes, and between instances and
nodes, are based on the meaning of those nodes. Conventionally,
node-to-node relationships are called KIND-OF links, because
each child node can be said to be a kind of its parent node.
In our illustrative taxonomy, shown in
Figure 2.1
, for example,
Supplier is a kind of Organization.
A leaf node, and only a leaf node, can be the direct parent of
an instance. Instances are individual things of the type indicated
by that node. The relationship between individuals and the (leaf
and non-leaf ) nodes they are instances of is called an IS-A rela-
tionship, because each instance is an instance of its node. Our
company may have a supplier, let us suppose, called the Acme
Company. In our illustrative taxonomy shown in
Figure 2.1
,
therefore, Acme is a direct instance of a Supplier, and indirectly
an instance of an Organization and of a Party. In ordinary con-
versation, we usually drop the “instance of” phrase, and would
say simply that Acme is a supplier, an organization and a party.
Among IT professionals, taxonomies have been used in data
models for many years. They are the exclusive subtype hierarchies
defined in logical data models, and in the (single-inheritance)
class hierarchies defined in object-oriented models. An example
familiar to most data modelers is the entity Party. Under it are
the two entities Person and Organization. The business rule for
this two-level hierarchy is: every party is either a person or an
organization (but not both). This hierarchy could be extended
for as many levels as are useful for a specific modeling require-
ment. For example, Organization might be partitioned into
Supplier, Self and Customer. This particular taxonomy is shown
in
Figure 2.1
.
We note that most data modelers, on the assumption that this
taxonomy would be implemented as a subtype hierarchy in a
logical data model, will recognize right away that it is not a very
