Databases and Systems

115
In fig. 2, the Objects and Classes tables have been repeated from fig. 1. The
Classes table has an extra field, EAV_Flag, a Boolean that records whether the
implementation of this class is EAV (if true) or conventional (if false). EAV makes
sense only for heterogeneous data, and there is no reason why a homogenous class
with a large number of object instances should not be implemented conventionally.
For each class, a description of the applicable attributes is stored in the
Class_Attributes table. Each Attribute has a name, a caption (for display to endusers
as a label in a form) a data type, a serial number (that determines order of
presentation) and a description (documentation). For BLOB datatypes, the "Type
Details" field records the kind of data (e.g., mime-type) that an attribute represents,
to assist management by application software. The Class Attributes table not only
documents the class definition, but is actively consulted by the system for
construction of input screens and generation of formatted output..
The actual data for an object instance is stored in the EAV tables. (Only one of
these, a table for integers, is shown in the figure.) The table Class_Hierarchy
records the parent-child relationships between Class definitions (not class instances:
these are stored in an Object_Hierarchy table as described earlier). This table is
consulted when the user specifies a query based on a super-class that might
encompass sub-classes as well.
Limitations of the EAV model
The simplicity of EAV comes with a price, namely, a performance penalty. The
physical representation of a class is quite different from its logical view as seen by
the user. Assembling all the "columns" associated with a particular class object
involves consulting the Class Attributes table and then gathering data from the
appropriate EAV tables. More important, complex Boolean query of classes requires