Re: By The Dawn's Normal Light

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Sat, 23 Oct 2004 09:18:19 -0500
Message-ID: <cldp7n$g9m$1_at_news.netins.net>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:pYqdnS3aq8Ic3-fcRVn-uQ_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:clc1jp$ebe$1_at_news.netins.net...
>
> > "A relation is in first normal form if ...none of its domains has
elements
> > that are themselves sets. An unnormalized relation is one that is not
in
> > first normal form."
>
> Does it say "if and only if"?
>
> If it does, then it's clear that, by that definition, not all relations
> need be in 1NF.
>
>
> >
> > So, I think we can get passed the flawed statement that a relation is
> > necessarily in first normal form.
>
> I'm not a mathematician, but it's crystal clear to me that not all
relations
> are in first normal form
> (called "normal form" in the 1970 paper).
>
> There is no useful purpose to be served by having one definition for
> "relation" in the discipline of mathematics, and having a different and
> inconsistent definition of "relation" in the discipline of IT.
>
> My real question to you is this:

I gather from the content that follows that I am the you

> If you have an objection to 1NF, as originally defined, and if Date
> altered the definition of 1NF, then
> do you still have the same objection to the Date definition of 1NF? Or do
> you have a different objection?

I just re-read Date's recent paper on 1NF and he now concludes that if something is a relation then it is in 1NF necessarily (just as others in this thread have stated). I think that I now have no problem with Date's specific definition of 1NF. It is not the same definition that most people accept nor the one required if you want to use JDBC or ODBC or any SQL-92 based SQL against your data. I think I now only have a problem with the redefinition of "relation" to mean something other than mathematical relation. We should pick a new word.

> And I am waiting, patiently, for you to present your conclusion as to the
> connection between data model and team productivity.

That is the search I have been on and I have gathered a lot of material, but have no p --> q in logic, only in experience. I also cannot claim that the gains in productivity are due exclusively to the data model. That does seem to me to be one significant component, however, which is why I investigated why the entire profession seems to think that we ought not have embedded lists in our logical data models.

Others attribute the productivity boost to an integrated environment, to the ease in getting good performance from the database, to the lack of strong typing, to the DataBASIC and multivalue query languages, and to the fact that it isn't a DBMS (at least by my def) and doesn't tie the hands of the developer in the ways a DBMS with strong typing would. These are considered bad things by those with a DBMS mindset, but they seem to translate into higher productivity, easier maintainability, and do not seem to translate into a loss in quality in most shops.

Cheers! --dawn Received on Sat Oct 23 2004 - 16:18:19 CEST

Original text of this message