Re: By The Dawn's Normal Light

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Fri, 22 Oct 2004 17:12:08 -0500
Message-ID: <clc0k2$ed1$1_at_news.netins.net>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:5rudncnyjLwymeTcRVn-rA_at_comcast.com...
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:7IZdd.284714$MQ5.40339_at_attbi_s52...
> > "Laconic2" <laconic2_at_comcast.net> wrote in message
> news:J_OdnQb_GuO9h-XcRVn-2Q_at_comcast.com...
> > >
> > > A table represents a set if and only if there is a candidate key.
> >
> > Saying "at least one" instead of "a" would be less prone to
> misunderstanding.
> >
>
> Agreed. But I'm about to agree with Paul's objection as well, so this
makes
> it a moot point.
>
> >
> > > A Relation is in first normal form if and only if none of the domains
of
> its
> > > attributes permit compound or multivalued values.
> >
> > This definition is a problem, because it includes two other terms that
> > may themselves be subject to confusion: "compound" and "multivalued."
> >
> > What do those terms mean to you?
>
> I'd rather retreat to the commonly accepted standard, if there is one. I
> know that TTM modified the definition of 1NF from what it had been
> previously. What is the "official" definition of 1NF per Date & Darwen?
> And, does this definition address the issues Dawn raises about what's
wrong
> with 1NF?

I didn't find a clear def in Date's most recent edition of his database bible when I was in my office. I don't have the book here right now to search some more. It definitely takes care of one of the things that I think went wrong with RDBMS's to permit nested relations. Without the operators to insert values in order in a list (since nested relations are still unordered) that just means that the applications, rather than the databsae engine have to handle ordering attributes, including functions to add to the end, insert, and delete from an ordered list.

> I'm hoping to hear from Dawn on this one.

I'm sitting with a ton of collected data but no time to pull it together right now. The problem with trying to find an agreed upon definition of 1NF is that most definitions refer to atomic values and there is no agreement on what that means. All definitions of 1NF relate whether data is in 1st normal form to functions on types (I might not be saying that right) but once there are user defined types, what do these defintions mean? So, I think you are on the right track to try to figure out what 1NF really is. I do have a paper from Date that I'll review and see if I can get his def of it from that.

>
> > Distinguishing between ordered and unordered data is *essential.* Data
> > has meaning; calling unordered data order means imputing meaning to
> > noise; calling ordered data unordered is throwing meaning away.
>
>
> This is the principal problem I have with the Nelson-Pick model as
explained
> by Dawn in this forum.
> "Collections" of like objects are stored in lists in a Pick file. That's
> the only collecting mechanism there is.

No. There are two types of collections -- "files" and "nested lists". The nested lists may have one or more attribute types and zero to many attribute values. Whether the user cares about the ordering or not, the database orders these, while the files are keyed, and therefore logically ordered. So, both top level structures (files) and their substructures are logically ordered.

> A linked list imposes an order on the collection, whether the order is
> meaningful or not.
>
> I agree that the question of linked lists is physical, while the question
> of meaningful ordering is logical. I just haven't figured out a way of
> disentangling the physical layer from the logical layer in the Nelson-Pick
> model. And all Dawn will tell us is that Data/Basic is such a cool
language
> that these issues don't matter to the teams that use it.

I don't actually know DataBASIC myself. I code in Java and write reports using the standard multivalue query language.

> That's where I get off the bandwagon.

Me too. --dawn Received on Sat Oct 23 2004 - 00:12:08 CEST

Original text of this message