Re: Any new thoughts on OTLT (One True Lookup Table)

Maybe a lot depends on the area you are working in. I work in the healthcare area and the example I'll use is old. (30 years).
Most professionals in healthcare (nursus and doctors) are very interrested in there patients and the data related to their patients but a lot of them are not interrested in the data as such.
(This is different from bankemployees where the core of there work is shifting electronic money). The core of the healthcare professional is healing patients and in principle even today he/she does not need a computer for that.

One of the first things to get automated and get recognision for it's usefullness in the hospital was the automation of lab results.
Some of the constraints that were 'build' into the system were. Labresults should be stored with the patients data. (The database was hierarchical so that did work very nice, somewhere under the patient there was a space / room / type /object tot store the labresults).

The problem that was getting the most attention during development was the types of labresults there where and although this was though, this was realised. (Some groups of hospital used 18 different labtechniques to measure one single aspect and offcourse everybody wanted to keep their method.)

By the time everything was up and running the lab could not put the results of non-human related labresults into the system. At that time it was very rear that a swap of a toilet or washing bowl was taken, but even in those days that did happen. But it was completely missed by the medical personal and also missed by the 'designers' of the system. So for some time there were patients in the system called 'washing bowl'. Later on the lab rats also became patients because of the same reason.

Offcourse this has now all been solved a long time ago. But it is still very difficult to get grip on the way data is seen and handled by medical personal. First this group is very diverse and data is not their 'concern'. Getting the very bad handwriting of a doctor formatted and described in such a way that it fits in a computer is still very problematic. And I am not talking about the character recognition but about the way a doctor and a colleage can read and understand what is written, but a 'normal' person including a designer can not always understand that.

Progress is made all the time, but some of the progress comes from better understanding some things after a solution has been roled out.

The health care is different from example banks where by now most core processes are completely automated or mostly automated. In health care the core busines has still nothing to do with computers, this is then reflected in the amount of resources dedicated to automation. (Being time, money, etc. etc.).

The example of the number of books was a 'translation' of the number of beds, which can have totaly different meanings in a hospital situation. In some situations they are almost the same, but not exactly. Medical personal using the word bed, almost always use the term so that others do exactly know what is ment by it, but when asked about it, they have problems describing what they did mean by it.
(Examples: A room can have 4 beds, (bedpositions) a free bed in a room means that at least one bed is not occupied. The bed itself does not have to be in the room. Bed as in furniture, to get a patient in a bed in a room, you actualy need the bed as furniture, any clean bed will do. A bed that has to be sterialised is a specific bed and is also furniture.)
As you can see that with a simple 'concept' as bed there are different 'descriptions' you can imagine that with less 'simple' concepts this can get more complex and confusing.

Then is a hospital there is always an enormous amount of flexibility, they have to handle emergencies which alters the rest of the 'processes'. So in a hospital they are 'used' to very flexibel ways of planning and working. Outside of the computer they have always used all kinds of systems for handling 'logistics', could be a white board which is the planning board, could be slips of paper. When automating this type of work, you are lucky if the first try is acceptable for the 'department'.
Sometimes something very simple does work, but it doesn't evolve to that at the first go. Sometimes the workmethod is actually altered and in reallity does make a huge improvement for the situation.

The above is the situation were I do realise that analysing can not solve the problem completely.

The situation with a webshop is designing a system with build in flexibility, where you end up with a 'generic' model to satisfy the requirements. In a 'generic' model there is often room for 'thingies' which are not know at design time. This comes with a penalty though, for example using a generic system for storing codes, does not (realy) allow for implementing the constraints in the database in a simple way.

For example for the lab system, most general used things were fixed so they were not done generaly. But there was a general model for all the lab-results which were not general or still had to be invented at that time. So that all labresults could be handled by the system. (Only if they could be represented in ascii in those days).

ben brugman

"Laconic2" <laconic2_at_comcast.net> wrote in message news:IZ6dnVmV5-OdjfHdRVn-sA_at_comcast.com...
> Ben,
>
> Another good response. I enjoy discussing this with you, even though our
> two perspectives are quite divergent.
>
>
> "ben brugman" <ben_at_niethier.nl> wrote in message
> news:406bcb0a$0$5071$4d4ebb8e_at_read.news.nl.uu.net...
> > The database can not be designed to hold the codes
> > needed for the ecdf in a modelled way. So we have
> > to revert to a 'generic' way of holding the codes.
> .
> .
> .
> > About your words, I think they are often true.
> > Specifications are often drawn up during
> > communication between 'specialists' and the
> > 'users' of a product. Users are not used to
> > 'exactly' define the way they are working.
>
> Thanks for the clarification. It helps, but there's still a gap between
> what you are writing and what I'm understanding. I'm not going to try to
> say whose fault that is. I think it's inherent.
>
> Let me try again.
>
> So, what you store in the database schema is not a data model of the user
> data, but a sort of "meta model" that can be used to model a wide variety
> of data, so that you can postpone till later the actual binding of a
data
> model to the data. Is this a fair summary?
>
> And this meta model is not understandable to a subject matter expert,
it's
> only understandable to another data modeler. Is this a fair inference
from
> your comments?
>
> My experience is that subject matter experts are far less hazy about their
> own data than they are about their own process. Their process is largely
> unconscious, and becoming self conscious of process is as much fun for
them
> as "sensitivity training". But they've been working with data for a
long,
> long time, and they are good at it.
>
> As far as constraints go, you have to work to get the constraints out of
> them. Often, they have only a hazy idea of what the constraints are.
But
> show them an example of data that violates a constraint, and they'll
> immediate verbalize what's wrong with it. To the user, bad data is like
> pornography to one of the court justices: "I can't define it, but I know
it
> when I see it!"
>
>
Received on Thu Apr 01 2004 - 17:44:51 CEST