EAV/CR has traditionally meant entity-attribute-value
with classes and relationships. Application of that label to our own implementation
is intended more to provide a rough approximation with a known moniker than it is
to claim all that this might imply to theorists.
EAV/CR is a data modeling method that,
with rich metadata, runs a logical database schema atop a very different physical
database schema. Logical tables are often assembled from one or many more physical
tables that generally (but not always) contain only one column of actual payload data of a specific
data type such as string, integer or date-time. And all logical tables (what we really
mean by “classes”) are related to each other by a uniform physical relation system
defined and managed by metadata.
Another set of terms that could be
used to describe our implementation of EAV/CR includes nodes, vertices, and undirected
edges arranged in a structure mathematically known as a graph. Every data point
in our implementation is a node, a kind of hook on which is hung one or more object
type instances (a single row of each of one or more logical tables). Like atoms
in a molecule, each node binds to one or more other (or identical) node types in
accordance with metadata rules.
The Framework does not obligate use
of its EAV/CR component. But if your job is to develop an application involving
domains as complicated or diffuse as medical records or any other domain with rapidly
evolving boundaries or without a prevailing or fixed consensus on content detail,
a number of questions, each addressed by our implementation of EAV/CR, will immediately
- How does one design a database schema
(the underlying structure of a database) that captures all the necessary information
now, tomorrow and a year from now? Database schemas, like foundations of buildings,
once formed, are difficult to change, re-arrange or expand. But the more complicated
the domain, such as medical records, the more likely you will not think of everything
at the beginning and the more likely you will need to change, expand and re-arrange
- How does one design a database schema
where tables could potentially have hundreds of little-used, frequently null values?
- How does one design a user interface
to support a complex and expanding database schema? Each new table and each new
column in a table, each with its own relationships to others, could potentially
require its own hardwired program user interface code, code not easily modified
or maintained in a changing context. The problem increases exponentially with the
increase in the number and of tables in the database and with the increase in the
complexity of relations between them.
- How does one hand-generate and maintain
thousands of SQL (Structured Query Language) queries in a changing and expanding
context? SQL queries can be laborious to write, test and debug—and easy to invalidate
through changes in the data structure or by changing requirements against a fixed
structure. They, along with the DB schema and user interface, are part of the cement
that sets soon after they are deployed. The Framework’s EAV/CR automates all query
- How does one allow the user to generate,
at run time, unpredictable queries against any parts of the database while maintaining
access rules? Users don’t write SQL. Yet the queries they need could require whole
pages of tortuous SQL. Again, this is automated by the Framework’s EAV/CR.
- How does one enable the user to navigate
easily from one entity to adjacent entities without hand-crafting code to facilitate
each and every step from this entity to the next? Or how does one grant the user
direct access to all entities without navigation from a limited number of fixed
starting points—with or without custom program code?
- How does one develop a unified rights-assignment
system (to view, edit, delete or insert) for potentially thousands of entity types?
- How does one avoid the expedient (resorted
to by many medical records vendors) of having to store complex chunks of data in
bulky and difficult-to-query structured text formats such as XML, which require
expensive parsing before their content can be queried, filtered or read?
As these questions indicate, we implemented
EAV/CR for far more reasons than averting wickedly difficult database designs. What a good EAV/CR system also achieves
is standardization of how all entities are created, edited, related, stored, accessed, navigated and displayed. Such standardization
reduces by a hundred-fold what the developer would otherwise have to design, build,
debug and maintain and what users would need to learn. It’s just plain simpler.
Further detail is available to logged-in