Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> comp.databases.theory -> Re: Order & meaning in a proposition

Re: Order & meaning in a proposition

From: Dawn M. Wolthuis <>
Date: Tue, 6 Apr 2004 14:55:46 -0500
Message-ID: <c4v20p$8tb$>

"Lemming" <> wrote in message
> On Tue, 6 Apr 2004 13:32:28 -0500, "Dawn M. Wolthuis"
> <> wrote:
> >"Lemming" <> wrote in message
> >
> >> I'm curious what modelling methods retain sufficient information that
> >> such nuances are captured in the final model. Do any such methods
> >> exist?
> >
> >I'll take that bait --
> I'm sory, I wasn't baiting anyone, it was a genuine question.

I figured as much, but it was more that I just had to take it as bait and do another little nix-1NF soapbox.

> >if one were to model data as if for an XML document,
> >for example, then you would not have to put the data in 1NF and could
> >"multivalues" in your model.
> An XML document isn't a method, it's an outcome; A particular
> implementation for the expression and presentation of aspects of a
> model.

Data modeling for data that will land in a structure such as XML can be done with a relational model where you put the data into 1NF (as well as further normalization). However, you can also model it with a tree of data where there can be more value for an attribute. Precise rules for modeling data for XML are not in a shape similar to those for the relational model, but it is not the same as relational modeling, with one notable exceptiong being that there is no need for 1NF.

> >First normal form is perhaps the most obvious
> >way thast the relational model loses such information (as ordering) when
> >modeling propositions by splitting them into so many propositions.
> 1NF does indeed remove ordering information, unless you put it back
> (if it's important) within the data itself. But I thought the
> discussion was about retaining information which may not be considered
> important at the time of modelling, but nevertheless may be inferred
> from the statements from which the model is constructed.

Yes, and ordering of nouns is one example of the type of information that might be retained in a model for potential implementation in XML documents, for example, and would not be retained in a relational model.

> >This is
> >the same way we modeled data in the 70's (we as a profession) when
> >it in indexed sequential files with tables permitted as fields in
> 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.

> >It is the same way data is modeled in PICK and pretty much every data
> >I suspect, other than relational. So, start by tossing out 1NF and that
> >will make a big difference in this area in my opinion. Cheers! --dawn
> I don't understand how "tossing out 1NF" offers any gains in capturing
> nuances of meaning which are not ultimately modelled.

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, while that would not be necessary (even though possible) in an XML document. 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.

> 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 Received on Tue Apr 06 2004 - 14:55:46 CDT

Original text of this message