On 11/8/07, Randolph Neall <randy.neall at veriquant.com> wrote:
>
> Thomas, thanks for your extended remarks. Your point is one you've made
> for a long time, that relational db schemas cannot keep up with the real
> world. I'm just wondering if moving the problem out of the relational DB and
> into blobs (persisted objects, I take it) solves the problem you so
> eloquently depict. Yes, it solves the schema problem. I grant you that. But
> you're still left with imperfect and changing models even with blobs. I've
> read the openEHR specs enough to know that when an archetype version
> changes, one is obliged to convert all existing records (blobs) to conform
> to the new version, and that, it
>
That is not true. When an archetype version changes, new data are
created/validated by new version of the archetype while old data (blobs or
whatever) are still processed by old archetypes. In the root node of the
data, there is always information about the archetype (and its version) used
to create the data (LOCATABLE.archetype_details). So there is really no need
to convert existing data when archetype changes. Hope this clarifies the
matter.
Cheers,
Rong
seems, would not be trivial. That task would worry me. Every affected blob
> would have to be rewritten. Maybe the only real problem you're even trying
> to solve is that of the relational schema. You allow that there are many
> ways other than the path-blob approach, but you've made it clear that your
> preference is definitely that, another indication of how intractable the
> root problem actually is.
>
> Thanks again.
>
> Randolph
>
>
>
> On 11/8/07, Thomas Beale <thomas.beale at oceaninformatics.com> wrote:
> >
> > Randolph Neall wrote:
> > >
> > >
> > > Can I assume that what Thomas here advocates, ("relational databases
> > can be
> > used very effectively as a low-level store of blobs keyed by path") is
> > what
> > how the ocean persistence layer actually works? Beyond this, Thomas
> > apparently
> > has little use for the capacities of Sql-type RDBMS systems to handle
> > clinical
> > information. Does the Ocean system ultimately amount to blobs keyed by
> > paths
> > (presumably string paths)? If so, what kind of blobs, XML blobs, or some
> > other
> > structured text system?
> > >
> > to clarify: yes, more or less. If you lock the relational schema, or
> > even an
> > object schema (i.e. an object model expressed as classes and/or as an
> > ODB
> > schema, say in ODL) directly to a model of the real world phenomena your
> > system deals with (e.g. patient visits, path results, GP notes, physical
> >
> > examinations, referrals etc) then there will be permanent problems of
> > maintainability. This has been borne out for as long as I have known
> > anything
> > about computers (let's say 20 years working + 5 years university, when
> > Edition
> > 2 of Somerville was our idea of 'software engineering').
> >
> > I have kept wondering why software engineering talks about the problem
> > of
> > maintenance and having to continually throw away and rebuild systems,
> > the
> > problems of drifting away from requirements and so on, as if they were
> > being
> > solved. But they are mostly not being solved. The technical book shelves
> > are
> > full of books teaching the same old thing (count the number of
> > information
> > system books using airline booking or hotel or conference booking case
> > studies), implying that it works. But in real life it doesn't. We don't
> > seem
> > to have any sustainable information systems - we have to keep fiddling
> > with
> > them. (Note: I am talking about 'information' systems here - there are
> > many
> > other computational systems whose information is more or less static and
> > which
> > mostly do number crunching or visualisation or some other job).
> >
> > The root problem in my view is that if you build an information system
> > in such
> > a way that its business logic and database encode the facts of the
> > domain (as
> > gathered last week, by you and a few colleagues, perhaps following 'use
> > case'
> > analysis or some such idea), the database and logic of the system are
> > connected to the reality being modelled. However, since reality keeps
> > changing, along with our idea of it (and hence our modelling of it), the
> >
> > system is never correct; we have to kee modifying it. This might be easy
> > with
> > a small system, but with large distributed systems and billions of
> > records,
> > and numerous changing requirements, it doesn't perform well at all
> > (altough we
> > often delude oursevles that it is ok by restricting our work practices
> > to
> > those that fit the software).
> >
> > In other words, directly modelling the aspects of reality we are
> > concerned
> > with as first-order concepts in the software and database is a recipe
> > for
> > costly and permanent maintenance. I believe we have to instead model the
> > reality as a second order concept, with first order concepts in the
> > system
> > being stable models of the classes of things found in the reality of the
> >
> > domain. Hence in openEHR we model only things like Composition
> > ('recording'),
> > Section ('heading'), Party, various kinds of Entry like Observation and
> > so on.
> > We don't model any medical or clinical thing directly. Everything
> > modelled as
> > a first order concept is domain-invariant - it has the same meaning
> > right
> > across teh entire domain of application. Of course we can debate whether
> > we
> > have gotten it right or not, but this is the intention.
> >
> > We are not the first to do something like this of course - there are
> > hundreds
> > of solutions in a similar vein, various kinds of business rule modelling
> > languages and so on. What we do in openEHR is just one (fairly
> > comprehensive,
> > we think) approach to solving the problem of unmaintainable software
> > systems.
> > It also happens to help solve the problem of getting the requirements
> > from the
> > domain experts - far better than 'use case analysis a la Jacobson' does.
> >
> >
> > It now seems quite clear to me that building any real world concepts
> > directly
> > into the software infrastructure of an information system is a mistake.
> > We can
> > do far better than that, and we always should aim to do so.
> >
> > Having said all this, then there is the obvious question: well what do
> > we use
> > the database for? My view on that (and there are far better experts than
> > I) is
> > this: once you clear your head of any idea of trying to model patients,
> > visits, pathology results, prescriptions, medications, etc etc etc in
> > the
> > database, you have an incredible freedom to use the power of these
> > systems -
> > and most modern databases are extremely powerful. We just use them in
> > the
> > wrong way a lot of the time. Using a relational database for medicine in
> > my
> > view makes sense as long as you build a schema that has no first-order
> > domain
> > concepts in it, and instead encodes information in a generic way. That
> > could
> > be blobs, paths, indexable columns, or some other method. There are many
> > variations available, and I doubt if we have really started to
> > understand them.
> >
> > All these comments also apply to object models - encode the real
> > phenomena
> > your system processes directly into the software classes of your system,
> > and
> > you will have a never-ending game of catchup on your hands.
> >
> > - thomas beale
> >
> > _______________________________________________
> > 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/20071108/459056de/attachment.html>
