Re: Lucid statement of the MV vs RM position?

From: JOG <jog_at_cs.nott.ac.uk>
Date: 1 May 2006 19:52:03 -0700
Message-ID: <1146538323.477680.56290@v46g2000cwv.googlegroups.com>

dawn wrote:
> JOG wrote:
> > dawn wrote:
> > > Jan Hidders wrote:
> > > > dawn wrote:
> > > > > Jan Hidders wrote:
> > > > > > dawn wrote:
> > > > > > >
> > > > > > > Well, there's more than 30 years of production apps out there running
> > > > > > > flavors of MUMPS, PICK, and others from which the jury could gather
> > > > > > > data.
> > > > > >
> > > > > > They already have done so, and they already know why they work
> > > > > > efficiently under certain circumstances, and under which circumstances
> > > > > > they have problems.
> > > > >
> > > > > I've tried to find those "they" people to see what they have found out.
> > > > > Can you point to one study out there that compares Pick with SQL-based
> > > > > products? What is out there that compares any non-SQL (or SQL as a
> > > > > second language) databases with SQL DBMS's without using SQL against
> > > > > the non-SQL database? I'm apparently doing a lousy job of searching.
> > > > > I'm not looking for theory on this one, but actual studies of real
> > > > > software solutions. It does seem like there would be such, but I'm not
> > > > > finding 'em.
> > >
> > > > I don't know any, nor do I expect something like that to exist. Such
> > > > comparisons are difficult because of several reasons. The claims of the
> > > > RM are mainly wrt. the functioning of an IT department as a whole
> > > > within a certain type of context. That is hard to recreate in an
> > > > experiment.
> > >
> > > OK, so you told me the jury was out regarding modeling and implementing
> > > with non-1NF data (or something like that); then I told you that there
> > > are production systems out there, if the jury really wanted to know;
> > > then you said they have already gathered data; then I tried to ask
> > > "where is it?"; and you said "I don't know any, nor do I expect
> > > something like that to exist."
> > >
> > > So, I think we talked past each other on that one. If RVAs and other
> > > non-1NF structures are now accepted in theory and implemented in
> > > practice, then when should they be used?
> >
> > I'm confused by this statement Dawn. My understanding is as follows:
> >
> > 1NF is definitional in that it is simply a case of saying that
> > "everything must be stored as tuples", allowing sets of such to form
> > relations.

> There are many differing definitions of 1NF, but the traditional one is
> that it is equal to what Codd termed "normalized" which he discusses in
> the 1970 paper. That is the only definition I can find that has been
> popularized enough for most practitioners to have in mind when someone
> mentions 1NF. I know you read my "Is Codd Dead?" blog entry, Jim, but
> to clarify, it loosely means "no repeating groups" or what Cood called
> "nonsimple domains." I recognize this is not precise, but it is the
> thinking behind the origins of SQL, the ramifications of which are
> still with us big time.

> There are now some (Date, for example) who have redefined 1NF to have
> no real meaning. If something is a relation, it is in 1NF by this
> definition IIRC. That is not the 1NF to which I am referring.

This take on 1NF has no "meaning" as such, but it does have practical consequences. And it is pretty much the version of 1NF that I described. Ok, you're not happy with the original "non-simple" domain fluff, but I see this as an aspect that has been refined over the years in the theory (if not in the implementation).

>


> > By definition, mathematical relations may not have variable

> > cardinalities across tuples and hence (but only as a consequence)

> > applying 1NF means that each field must be guaranteed to occur but

> > once.

> >

> > However, an element in a tuple may happily be a set, a list, a RVA or
> > whatever user defined type one wishes to use and still be 1NF,

> This is only true if one has redefined 1NF to make it true. This is
> not the case with the original definitions, which is why SQL (which
> might be a flawed implementation, but was based on the RM as it was
> then defined) did not include RVAs (SQL '92 on which ODBC is based does
> not include them, for example).

True, not according to the original paper, but relational theory appears to me to have developed since then. However, if in some alternate world the definition of 1NF that I described was the universally accepted one, and it was implemented perfectly - would that satisfy your needs?

>


> > as one

> > can still form acceptable tuples with them. Currently one has to

> > manipulate these user defined types externally as the tools aren't

> > really there to do otherwise (apart from strings and date types).

> >
> > Is this not how you see it? All best, J.

> No, those are not the definitions that I am using. I'm not doing any
> fancy footwork with the original definitions. Since I work with what
> are called NF2 databases (or NF^2), which stands for Non-First Normal
> Form, I am using the definition of 1NF that prompts the NF2
> designation. If you have a better term for
> the-approach-formerly-known-as-1NF, let me know and I'll try to
> incorporate it where 1NF might otherwise be confusing.

This is important. I don't believe anyone would see Codd's original paper (including probably Codd himself) as the final word - after all, it was over three decades ago and refinements are to be expected. It sounds to me your beef is over the "non-simple" domains aspect - but with user defined types, which many RM proponents promote, I honestly think there is no disagreement to be had here.

So your remaining objections with the RM establishment (as I have read them) seem to distill to whether a statement such as:

"Barney is_colour green and is_colour purple"

translates best to which of the following propositions:

colour(Barney, green) && colour(Barney, purple)
colour(Barney, {green, purple} )

Would you not say that with bit of logical manipulation we could probably show that the first is preferable? J.

>
> Cheers! --dawn
Received on Mon May 01 2006 - 21:52:03 CDT