openEHR - Persistence of Data
** ** ** ** ** ** __ Information from ESET NOD32 Antivirus, version of virus signature database 6898 (20120220) __ ** ** The message was checked by ESET NOD32 Antivirus. ** ** http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 6898 (20120220) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120222/6d410fe0/attachment.html
openEHR - Persistence of Data
on the RM version you use, if the RM version change, the schema should change too, but the RM version you'll use will be very stable, nd I'm sure that only one version of the RM will be in use at a time. ORM generates the schema for the classes (source code), not the classes for the schema, so we don't have autogenerated code. This is my experience and the way I think this should be done, because the openEHR Reference Model is Object Oriented, so a programmer could easily program those classes and user an ORM tool to generate the database structure. DLLs? Kind regards, Pablo. Randy Neall Veriquant, L.L.C. On Thu, Feb 16, 2012 at 5:26 PM, pablo pazos pazospablo at hotmail.comwrote: Hi M?rcio, There is no standard persistence model, the persistence mechanism is not in the standard scope. There are many ways of storing openEHR RM instances (archetyped data), the only thing to take into account is that the information to store will be highly hierarchical. Said that, in EHRGen [1] we use a relational model with an Object-Relational Mapping [2] tool (GORM from Grails Framework[3]). The advantage of that is that you have a complete and validated RM instance persisted on the DB, and you can query for complete objects or single data ELEMENTS. I've written ORM tools myself [4] and the main problem is the amount of joins you need to load a complete structure, but in my experience you never load a complete structure for a real time interaction with the user, and you alway can cach? some data. This approach is straight forward, because all you need are the classes of the RM, and you delegate DB stuff to the ORM tool. Other models are viable too, like K/V [5] or EAV [6] approaches (mentioned by Bert). This approaches are fast for saving and loading data, the problem is that you need to have some complex logic above that for constructing a complete RM instance on memory, because K/V is a flat representation of a higly hierarchical tree structure. Other models I didn't try yet are Object Oriented DBs and Document Oriented DBs (XML, JSON, ...) [6]. I think DODBs are a good option, fast for store highly hierarchical structures, but you need to write some ugly queries if you want your data back :D Hope that helps. [1] http://code.google.com/p/open-ehr-gen-framework/ [2] http://grails.org/ [3] http://en.wikipedia.org/wiki/Object-relational_mapping [4] http://code.google.com/p/yupp/ [5] http://en.wikipedia.org/wiki/NoSQL [6] http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model -- Kind regards, Ing. Pablo Pazos Guti?rrez LinkedIn: http://uy.linkedin.com/in/pablopazosgutierrez Blog: http://informatica-medica.blogspot.com/ Twitter: http://twitter.com/ppazos http://twitter.com/ppazos -- From: mdckoury at gmail.com Date: Thu, 16 Feb 2012 16:53:19 -0300 Subject: openEHR - Persistence of Data To: openehr-technical at openehr.org Hello guys, i'm starting a research about the persistence model of Archetype data, that stores the information entered by the user of the system. I would like to know if there is a indication of the openEHR standard for what kind of model schema should be used in DataBase, and if there are researchs in this area. Thanks in advance, *M?rcio Costa* B.Sc. in Computer Science @ Cin/UFPE M.Sc. Candidate in Computer Science @ CIn/UFPE MSN: mdckoury at gmail.com ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120222/b5e5e65d/attachment.html
openEHR - Persistence of Data
associating classes with source code that ends up as compiled code, but maybe you mean something else by your OOP terminology, something more akin to metadata that never gets baked in to the machine code. But I don't think I've misunderstood your concept of a schema. I had all along thought that OpenEHR was intended to operate in precisely the way I have described, as a basis for expressing complex information with simple schema and source code, neither of which embody, in hard-wired form, particular medical information structures. Your description of ORM seems to me to mean something else. If I'm wrong, I certainly apologize. Thanks, Randy Neall -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120222/0cb98ad8/attachment.html
openEHR - Persistence of Data
, with all the things that can go wrong with that body, ultimately requires thousands, maybe tens of thousands, of classes to describe just what can go wrong with the nervous system, to say nothing of the rest. It seems to me that the better solution would be to develop a metadata-based system capable of describing all that must be expressed, allowing both schema and program code to remain unchanged while presenting to the user information of which the compiled code and schema are both essentially ignorant. In other words, neither the program code nor your schema has any awareness of particular structures of medical information. All of that is instead in the metadata, not schema, in the metadata, not classes. *That's exactly what we have done! :D* I'm sorry if I didn't explain it correctly. The design is based on this principle: none dependency to custom domain information on the system backend, that dependency is only on the GUI side (the only thing we need to generate). My mistake in all this may be that I am mentally associating classes with source code that ends up as compiled code, but maybe you mean something else by your OOP terminology, something more akin to metadata that never gets baked in to the machine code. But I don't think I've misunderstood your concept of a schema. I had all along thought that OpenEHR was intended to operate in precisely the way I have described, as a basis for expressing complex information with simple schema and source code, neither of which embody, in hard-wired form, particular medical information structures. Your description of ORM seems to me to mean something else. If I'm wrong, I certainly apologize. Thanks, Randy Neall ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120222/13ade20e/attachment.html
openEHR - Persistence of Data
, and no matter which process comes first (generating the classes or generating the schema), and no matter which process is dependent on the other, you still end up with both a schema and compiled code that will expand with each new class that you create. As I explained, that's not the case: no new code needed and no new schema generation needed to support new archetypes. Code and schemas are fixed. (don't take me wrong, I think you are attached to some technology or solution that is completely diferent of what we tried to implement). That's what I mean by hard-wired. You can do a lot of hard-wired stuff very fast via ORM code or schema generation automation. Your DLLs (or whatever your equivalent is) will expand in size and number. Your schema will grow in size and complexity in direct proportion to the number of classes it is trying to persist. You don't feel the pain, however, because the computer did it all (or a lot of it) for you. Nope, no expansion of code here, only explansion of the config file and the knowledge base (archetypes and templates). You can see the code here: http://code.google.com/p/open-ehr-gen-framework/source/browse/#svn%2Ftrunk%2Fopen-ehr-gen But you're still left with an end product (consisting of schema and compiled code) that will bloat with each new thing it is designed to express, manage, present and store. That process can go on for a very long time, yes, but it can't go on forever. And the human body, with all the things that can go wrong with that body, ultimately requires thousands, maybe tens of thousands, of classes to describe just what can go wrong with the nervous system, to say nothing of the rest. It seems to me that the better solution would be to develop a metadata-based system capable of describing all that must be expressed, allowing both schema and program code to remain unchanged while presenting to the user information of which the compiled code and schema are both essentially ignorant. In other words, neither the program code nor your schema has any awareness of particular structures of medical information. All of that is instead in the metadata, not schema, in the metadata, not classes. That's exactly what we have done! :D I'm sorry if I didn't explain it correctly. The design is based on this principle: none dependency to custom domain information on the system backend, that dependency is only on the GUI side (the only thing we need to generate). My mistake in all this may be that I am mentally associating classes with source code that ends up as compiled code, but maybe you mean something else by your OOP terminology, something more akin to metadata that never gets baked in to the machine code. But I don't think I've misunderstood your concept of a schema. I had all along thought that OpenEHR was intended to operate in precisely the way I have described, as a basis for expressing complex information with simple schema and source code, neither of which embody, in hard-wired form, particular medical information structures. Your description of ORM seems to me to mean something else. If I'm wrong, I certainly apologize. Thanks, Randy Neall ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical ___ openEHR-technical mailing list openEHR-technical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- next part -- An HTML attachment was scrubbed... URL: http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120222/ed849bf9/attachment.html
