Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!news.netins.net!not-for-mail From: "Dawn M. Wolthuis" Newsgroups: comp.databases.theory Subject: Re: Views for denomalizing Date: Fri, 4 Feb 2005 10:53:54 -0600 Organization: netINS InterNetNews site Lines: 50 Message-ID: References: <520701hrid6r7u9fi09ugnqnkgl9694hdd@4ax.com> NNTP-Posting-Host: 199.120.93.7 X-Trace: news.netins.net 1107536050 12207 199.120.93.7 (4 Feb 2005 16:54:10 GMT) X-Complaints-To: usenet@netins.net NNTP-Posting-Date: Fri, 4 Feb 2005 16:54:10 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Xref: dp-news.maxwell.syr.edu comp.databases.theory:29755 "Alfredo Novoa" wrote in message news:520701hrid6r7u9fi09ugnqnkgl9694hdd@4ax.com... > On Wed, 2 Feb 2005 22:34:40 -0600, "Dawn M. Wolthuis" > wrote: > >>1) SQL-DBMS's (at least those that conform to SQL92) provide no >>constraints >>on the user creating new tables to restrict base tables from being >>denormalized EXCEPT in the case of the first normal form. > > But SQL allows the definition of table variables that does not fulfill > the prerequisites for being in 1NF (nulls and duplicates). > >>1NF is the only normal form that is forced upon us by many common industry >>tools. > > So this is wrong. The theory-previously-known-as-1NF, the aspect that was most widely associated with the term, the aspect of 1NF that has no name on its own and to which I cannot seem to refer -- PLEASE, PLEASE GIVE IT A ONE OR TWO-WORD NAME AND I'LL USE IT! -- is what I'm referring to. So, what I meant and what you likely knew I intended, is accurate, right? >>Yet SQL-DBMS's and >>related tools consider it so much more important than the other normal >>forms >>that even in the views, where denormalization is common, acceptable, and >>clearly useful, non-1NF is still not (typically, as best I can tell) >>employed. > > And this is wrong too. > >> But >>we as a profession will need to attend to those who already graduated to >>eliminate the bias against lists within attributes, at least when it comes >>to views of the data, if not base relations. > > Lists within attributes break the Information Principle, the most > fundamental principle of the Relational Model. This is terminology, I think -- if my "list" (in English) is modeled as a relation, then it may be the type of an attribute, right? --dawn > Regards > >