RIM Based Persistence
This is (old) discussion item.
This paper addresses the architecture of a solution which uses the HL7 RIM as a persistence model.
Safe querying of a RIM-based data model is out of scope of this version of the paper.
Note: this paper assumes that the details of RIM attributes are exposed at the persistence layer, i.e. either a RDMBS, an EAV or a mixture of those. Most of its content won't apply as-is to XML databases.
finally the basic problems are always the same and their solutions idem.
You have 2 main approaches: the XML-DB like Amnon very well described and the O-R approach with a physical DB model based on a mix of EAV and E-R structures.
Both of them are excellent for the sw-2-sw interfaces, but are also complicated enough to hit against the refusals of most people, which means that you have to develop tools and sw layers to simplify human-2-sw interfaces and direct data access bringing it back to "standard SQL E-R tables" or "MS Access-like queries".
- if you are in the "enterprise" market, developing "enterprise software", you need to expose your data via views or object views that give a standard E-R representation of your XML / O-R data structures - if you are instead in a vertical niche, developing a vertical single product, than you must provide your product with built-in tools for "MS Access-like" data access capabilities, hiding to human beings the internal complexity.
Benefits of a RIM based persistence layer.
See Implementation aspects of RIM based database models: Why not use a DIM (or: a CDA R-MIM) as the basis for persistence?
ACTION: Rene: add XML-based (+hybrid approaches) persistence as an agenda item to the May2011 WGM. Mark: Data -> OLTP -> OLAP. This way of building both databases is confirmed by multiple attendees. Or: one single database, multiple indexes based on ones requirement to do particular types of queries.
Physical Database Models
See ORM best practices. Persisting data types. Either ORM or as UDTs.
Peter: when it comes to preservation of context there seem to be 2 options: 1.dereference context prior to persistence 2.pointer to a separate model which contains the context