Difference between revisions of "RIM Based Persistence"
Rene spronk (talk | contribs) |
Rene spronk (talk | contribs) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | This is (old) discussion item. | |
| − | |||
==Summary== | ==Summary== | ||
| Line 8: | Line 7: | ||
'''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. | '''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. | ||
==Introduction== | ==Introduction== | ||
| Line 18: | Line 26: | ||
[[Persisting concept codes]], [[Use of terminology servers in RIMBAA applications]] | [[Persisting concept codes]], [[Use of terminology servers in RIMBAA applications]] | ||
| + | |||
| + | 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=== | ===Physical Database Models=== | ||
| Line 23: | Line 35: | ||
Persisting data types. Either ORM or as UDTs. | Persisting data types. Either ORM or as UDTs. | ||
| − | Context conduction. [[Context SMIRFs for RIM based relational databases]], | + | Context conduction. [[Context SMIRFs for RIM based relational databases]], [[ Object nets versus object trees]] |
| + | |||
| + | 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 | ||
Latest revision as of 21:40, 17 September 2014
This is (old) discussion item.
Summary
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.
Introduction
Benefits of a RIM based persistence layer.
Persistence Models versus Interoperability Models
See Implementation aspects of RIM based database models: Why not use a DIM (or: a CDA R-MIM) as the basis for persistence?
Persisting concept codes, Use of terminology servers in RIMBAA applications
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.
Context conduction. Context SMIRFs for RIM based relational databases, Object nets versus object trees
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
