[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] clarification of multiplicity of links

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] clarification of multiplicity of links
Date: Thu, 5 Aug 2004 16:32:12 +0200
User-agent: Mutt/

> >>/ clin_narrative    has only one  lnk_code2narrative /
> >No. Many rows in lnk_code2narr can point to the same
> >clin_narrative row. But they must be fulfill
> >   unique(fk_narrative, code, coding_system)
> >eg. it doesn't make sense to attach one and the same code
> >from a given coding system to one particular narrative row.
> unique within a clin_encounter grouping , but might repeat for another 
> clin_narrative in a  different clin_encounter?
You said it. *Another* clin_narrative row. However, no matter
which encounter. Any number of rows can have any number of
codes from any number of coding systems. However, no single
row can have the same code from the same coding system more
than once. Simple as that.

> >>/ clin_root_item has only one lnk_type2item/
> >No. Many item types can be linked to a particular item row. But
> >only once per item row. It doesn't make sense to say "this
> >narrative is Hx" twice for the same narrative (row).
> I'm not sure what "item row" is.
a row in clin_root_item

> Is the item_type only relevant to 
> some clin_root_items
> e.g. clin_narrative , but not to others e.g. the other clin_root_item 
> subtypes.
No arbitrary descendant rows of clin_root_item can be typed
(by linking types to their clin_root_item part of the row) -
we are getting on thin ice here re reliable inheritance with
respect to foreign keys but in my understanding it should work
as expected.

> Thanks for the reply:
Sure, welcome.

> I'm trying to use this info for a  programming 
> tool for gnumed, for serialization and form skeleton generation. 
> Richard says it won't work, but I'm still giving it a go, because it's 
> interesting in a woodwork-class sort of way.
Sure. Sounds interesting. The testschema* thingies you wrote
are actually useful in being yet another way to visualize the
schema thus making detection of inconsistencies easier (think
Stanford checker/sparse and the Linux kernel for those in the

> The idea is to include any many-to-one links within the same form, and 
> recurse for contained many-to-one links,
Hm, what is the business logic idea behind that ? I have to
admit I don't understand the value.

> if anyone can show the snippet ( please don't say it all doesn't make 
> sense, because Richard already has!)
I dare speculate it didn't make immediate obvious sense to him
as to what this tells us rather than not making sense based on
technical merits alone.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]