Hi Pablo, I'm sorry for being so slow responding to your questions. I may not be understanding you fully, nor have I made myself totally clear to you. First, a DLL is a file system file known as a Dynamic Link Library, a unit of compiled machine-executable code, typically invoked from a computer code file with a .EXE extension or from another DLL file, with a .DLL file name extension. These naming conventions are used by Microsoft Windows programs, but may not be used by other platforms, which which I am unfamiliar.
The ORM approach, as you describe it (correct me if I'm wrong), involves the creation of specific classes, expressed as compileable source code, and which therefore end up baked into the executable code files (EXE, DLL, or whatever the equivalent is called on your chosen platform). I am not sure how automated this process actually is in your OpenEHR context. Are you, for instance, able to download an archetype from the OpenEHR web site, press one button in your ORM, and thereby generate a class in your source code, which is then compiled into machine code (in something like a DLL)? And then, after that, with another push of a button, does a schema magically materialize, matching your auto-generated classes? If so, that's wonderful. But I have a concern that has nothing to do with automation, and which could actually be *aggravated* by automation. However automated the class or schema generation is or isn't, 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. 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. 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. 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 On Fri, Feb 17, 2012 at 2:49 PM, pablo pazos <pazospablo at hotmail.com> wrote: > Hi Randolph, > > The problem with ORM systems would ultimately be a rather bloated schema > and hard-wired classes to accommodate that schema. > > Yes and no, it depends on your configuration. One configuration could end > up using only on talbe with many columns, other configurations could break > up this table to normalize the schema. > > I don't understand the "hard-wired classes to accommodate that schema", > the openEHR RM is an Object Oriented model, a programmer should implement > the model on the ORM tool and the schema should be generated from those > classes, in fact is the schema what accommodates to the classes. So, for > new versions of the RM, a new schema could be generated, an mappings > between those schemas could be generated to (for data migration, if needed). > > Yes, ORM lets you automate the creation of DB data structures and classes, > but, once created, they become part of the schema and your DLLs, which is > fine until you have many hundreds of them (tables and classes defined in > autogenerated code, etc.). > > Yes, you'll end up with a schema, a fixed one, that depends 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.com>wrote: > > 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>
