Re: Order & meaning in a proposition

On Tue, 6 Apr 2004 14:55:46 -0500, "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote:

>"Lemming" <thiswillbounce_at_bumblbee.demon.co.uk> wrote in message
>news:1bu570ho991045ggi11t5fotv2klosm3ct_at_4ax.com...

>> I wasn't around in the 70's, so I don't remember this -- I recall that
>> much of what I was doing in the 80's in COBOL with hierarchical
>> databases using flat files was still by and large using normalised
>> data structures.
>
>2NF and 3NF were applied by those who had such training, but I'm guessing
>you saw a few OCCURS clauses in those COBOL programs, likely even in the FDs
>and not just WORKING STORAGE.

Yeah, plenty, but only in WORKING-STORAGE. I don't recall seeing many OCCURS in an FD or even in W-S records used to write to/from an FD.

I first met normalisation formally around 1990. Prior to that I'd been normalising data intuitively since the mid-80's, but hadn't a name for it.

>Take the "Pat" sentence and then perhaps one more where Pat seated the Queen
>of England. The first Pat statement would result in normalizing to at least
>two propositions and this last one would be a third. For the relational
>model all three people that were seated by Pat would now be on some equal
>footing in the relational model,

But that's not true at all. Sure, their relative ordering, importance, etc. are not modelled by the relationships between the tables, but if that information is pertinent, then it will be captured some other way -- for example by having a "seating_time" column on the table which links host to seating, or an "importance" column on the table representing the individual (or on the table representing the status of an individual in a particular context). Just because something isn't modelled by the relationships between tables doesn't mean it isn't modelled if it is considered important enough.

But I thought the point of this thread was to explore how a method could retain all the information from the statements used to derive the model, and not just those considered useful. From your original post which started the thread:

"Once we split apart a proposition in such a way that we cannot get the original proposition back, even if we THINK we are getting the important aspects of it back, we have lost some of the meaning we intended to capture."

and

"A data modeling process that respects the integrity of the stored propositions so that they can be retrieved again has something going for it that the relational model lacks, it seems."

Retaining information inherent in the statements from which the model is derived would seem to be "a good thing", and I'm keen to learn more. Obviously, retaining the original statements is a step towards it (and is what we should do anyway if we are doing our job properly) but your original post seems to hint that there is a better way.

>while that would not be necessary (even
>though possible) in an XML document.

Is an XML document a data model? I've only seen XML used for presentation of data, not for data storage, so forgive my ignorance.

>This isn't a great example, so I'll
>try in the future to have a better one, but it should show that if we don't
>send back the propositions that we took in, in particular by keeping
>compound subjects or nouns ordered together when that is how they are
>presented, then we do remove some meaning and, in some cases, might even add
>some subtle meaning that wasn't there at all.

I look forward to seeing and thinking about that example.

>> Not being familiar with PICK (although I do remember hearing about it
>> all those years ago) I have to ask how a PICK database is structured,
>> and what advantages that structure has over a relational structure.
>
>From a data modeling perspective, you can think of PICK as XML documents
>(but with exceptional performance). Cheers! --dawn

Yes, but that's not what I asked. I asked what is the advantage of the structure of a PICK database over a that of a relational database? Given that I think of XML documents as glorified web pages, saying that PICK is just XML with go-faster stripes isn't really going to convince me to make the switch :)

Lemming

-- 
Curiosity *may* have killed Schrodinger's cat.