Re: Codd provided appropriate mathematics ... (was Re: Relational and MV (response to "foundations of relational theory"))
From: Tom Hester <$$tom_at_metadata.com>
Date: Fri, 27 Feb 2004 09:53:23 -0800
Message-ID: <bac94$403f841e$45033832$27879_at_msgid.meganewsservers.com>
> <dwolt_at_tincat-group.com> wrote:
>
> >> The Relational Model permits relation typed attributes, so
> >> "multivalued" does not have any advantage. Collection typed attributes
> >> don't violate 1NF.
> >
> >Yes, so the theory in RDM is evolving to the point where it might become
> >more practical in its application.
>
> The understanding of The Relational Model is better now than in the
> 70's, but the model is always the same.
>
> But relation typed values in base relations seem to have little
> utility. The only good practical use I have found to the moment is to
> use them to implement a candidate keys relation variable of a catalog.
>
> > But while each RDBMS vendor seems to
> >have a means now of storing an array (or relation or other collections),
> >querying against this data is done differently by each vendor, it seems,
> >although SQL-99 has a means of doing this (and perhaps more db vendors are
> >employing that standard, but when I checked in 2002 there was no
> >consistency).
>
> As you heared hundreds of times, SQL is not relational. You will not
> find the term relational in the SQL specifications.
>
> >> Relations are in 1NF by definition. With a RDBMS you can not violate
> >> 1NF even if you want.
> >
> >You can violate any of the other normal forms, but not 1NF.
>
> Because you have no way. Relations are in 1NF by definition, otherwise
> they are not relations. If a DBMS does not use relations then it is
> not a RDBMS, so if you can violate 1NF then you are not using a RDBMS.
> A simple tautology.
>
>
> Regards
> Alfredo Received on Fri Feb 27 2004 - 18:53:23 CET
Date: Fri, 27 Feb 2004 09:53:23 -0800
Message-ID: <bac94$403f841e$45033832$27879_at_msgid.meganewsservers.com>
This is just plain false. There have been
many relational models proposed that are not 1NF. See for example,
ABITEBOUL, S.; BIDOIT, N. Non first normal form relations to represent
hierarchically organized data. In: PODS, 1984. Proceedings. . .Note the date:
1984. This is supposed to be a database theory board but it seems more
religious than theoretical!
"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message
news:403f7915.12870647_at_news.wanadoo.es...
> On Fri, 27 Feb 2004 08:01:43
-0600, "Dawn M. Wolthuis"> <dwolt_at_tincat-group.com> wrote:
>
> >> The Relational Model permits relation typed attributes, so
> >> "multivalued" does not have any advantage. Collection typed attributes
> >> don't violate 1NF.
> >
> >Yes, so the theory in RDM is evolving to the point where it might become
> >more practical in its application.
>
> The understanding of The Relational Model is better now than in the
> 70's, but the model is always the same.
>
> But relation typed values in base relations seem to have little
> utility. The only good practical use I have found to the moment is to
> use them to implement a candidate keys relation variable of a catalog.
>
> > But while each RDBMS vendor seems to
> >have a means now of storing an array (or relation or other collections),
> >querying against this data is done differently by each vendor, it seems,
> >although SQL-99 has a means of doing this (and perhaps more db vendors are
> >employing that standard, but when I checked in 2002 there was no
> >consistency).
>
> As you heared hundreds of times, SQL is not relational. You will not
> find the term relational in the SQL specifications.
>
> >> Relations are in 1NF by definition. With a RDBMS you can not violate
> >> 1NF even if you want.
> >
> >You can violate any of the other normal forms, but not 1NF.
>
> Because you have no way. Relations are in 1NF by definition, otherwise
> they are not relations. If a DBMS does not use relations then it is
> not a RDBMS, so if you can violate 1NF then you are not using a RDBMS.
> A simple tautology.
>
>
> Regards
> Alfredo Received on Fri Feb 27 2004 - 18:53:23 CET