EAV/CR Implementation

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 confront you:

• 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 your schema.
• 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 generation.
• 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 users here.