Databases and Systems

114
AI in the form of LISP association lists (20). Subsequently, they have been used for
applications as diverse as Clinical Data Repositories (21) and are the basis for the
structure of Web cookies (22) and the Microsoft Windows Registry, as well as
various tagged formats for data interchange, such as ASN.l (23). We have
implemented an EAV design in ACT/DB a production system for managing clinical
trials data (24).
Conceptually, in an EAV design, we have a table with three columns, Entity ID
(Object ID), Attribute (or Attribute ID) and the Value for the attribute. Thus, one
describes an object through several rows in a table, one row per Attribute-Value pair.
Thus, to record information about the enzyme "Cholinesterase" (object ID 250),
which destroys the neurotransmitter Acetylcholine by hydrolysis, one might have the
following rows:
...
Attributes are analogous to fields in a conventional table. In the examples, all
values are strings. In practice, relational databases are strongly typed. Rather than
have a single EAV table (with the Values coerced into string form) it is often
advantage to segregating values into separate EAV tables based on their intrinsic
datatype, for the following reasons.
One can improve retrieval performance by creating an index on a combination of
the attribute and value fields, to permit queries based on the values of the
attribute. (Indexes on numeric fields stored in string form are essentially useless
because of a different collating order.)
One can create EAV tables to hold values that are long text (e.g., sequences, or
PDF data) or BLOB data (such as vector graphics or photographic images). The
ACT/DB system uses six EAV tables for integer, float, string, date, long text and
BLOB data.
The success of an EAV system depends critically on the supporting metadata. We
describe our metaschema in Figure 2.