Databases and Systems

108
Associations table is needed because the class of any object referenced in the first
two columns can always be looked up in the Objects table. For retrieval efficiency in
circumstances where a relationship description can have an inverse, the row may be
duplicated with the values in the first two columns reversed. To cite a common
example in genomic data, a row asserting that object 123 is a sub-clone of object 65
() will have a row making the reciprocal assertion ().
The Problem of N-ary Associations
With neuronal data, however, associations between objects are typically not binary
but N-ary (where N is greater than 1). For example, consider the following
information on the neurons of the nigrostriatal pathway (whose function is impaired
in Parkinsonism):
The information in the example above may be regarded as multi-axial, where
receptor, anatomical site, neuronal type etc. comprise the axes, and we must now
consider how to represent it within a database schema. First, note that it is not
advisable to represent the axes as attributes of a "Neuron" class. Such an approach
might have been permissible in a database with the primary focus on neurons.
However, in a database that stores information on a variety of objects, this approach
introduces an asymmetry by implicitly making neurons first-class entities and others
second-class. Each axis mentioned above refers to objects which, depending on the
perspective of particular users, may be as or more important than neuronal types.
Thus, some queries may not be directed at the Neuron class at all: e.g., a user may
wish to retrieve a list of anatomical locations where D2 receptors are found. Such