Databases and Systems

Managing the Object Class Hierarchy
113
The NS has many classes of data, and some of these classes form a natural hierarchy.
Consider, for example, molecules with a role in the NS. The smallest such molecules
are the neurotransmitters, odor molecules and "second messengers" such as cyclic
Adenosine Monophosphate. The neuromodulators such as the enkephalins
(composed of a small number of amino-acids) and neurohormones (e.g., endorphins)
are somewhat larger. At the macromolecular end, we have various protein molecules
such as enzymes, ion channels and receptor molecules, along with their
corresponding nucleotide sequence/s. All of these are sub-classes of the class
"molecule", and the nature of information to be recorded against each subclass
varies. Thus, simple structural formulas (as vector graphics) are useful for smaller
molecules, while the larger protein molecules need to have secondary or tertiary
structures recorded when available. For enzymes, one would like to know about the
reactions they catalyze.
Similarly, for anatomical structures, one can descend from gross anatomical
structures (e.g., the cerebellum), to sub-structures (such as nuclei), to individual
layers of cells and the neuronal cell types within a layer.
However, there are some practical problems in directly porting the object-oriented
inheritance paradigm to design of a schema for NS objects.
While the number of classes is large, many of them will have only a modest
number of actual object instances. (For example, even though different
information needs to be recorded on a neurotransmitter versus a neuromodulator,
the currently known neurotransmitters plus neuromodulators number less than a
hundred.) It may seem like overkill to create separate tables as part of a complex
hierarchy for such few instances, because the added design effort is not
sufficiently amortized in terms of the volume of the data that is better managed.
In the context of NS data, we are using the phrase "class" more loosely than,
say, Java programmers do. In programming parlance, a class refers to a
particular data structure as well as the permissible operations (member
functions, methods) that can be defined for that class. However, for most NS
"classes", one cannot really think of any applicable operations other than simple
input and output.
Simplifying Class Management through EAV Design
When the number of instances of a class is expected to be numerous enough in a
production schema, the standard Object Dictionary approach (with class-specific
tables holding object descriptions, as mentioned earlier) is adequate. When it is not,
we must consider alternative design approaches.
One approach that is popular for modeling highly heterogeneous data is the
Entity-Attribute-Value (EAV) approach. (Some authors substitute "Object" for
Entity.) Attribute-Value pairs as a means of describing an object were pioneered in