Re: Interesting article: In the Beginning: An RDBMS history

From: JOG <jog_at_cs.nott.ac.uk>
Date: 7 Apr 2006 04:13:06 -0700
Message-ID: <1144408386.087956.261510@z34g2000cwc.googlegroups.com>

dawn wrote:
> JOG wrote:
> > dawn wrote:
> > > David Cressey wrote:
> > > > "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> > > > news:1144354101.878068.281070_at_z34g2000cwc.googlegroups.com...
> > > > >
> > > > > David Cressey wrote:
> > > > > > "x" <x_at_not-exists.org> wrote in message
> > > > news:e12djb$ha2$1_at_emma.aioe.org...
> > > > > > > > I don't think so. I think he was making the distinction between
> > > > > > > attributes
> > > > > > > > specified by name and attributes specified by position.
> > > > > > >
> > > > > > > What is the difference between a "name" and a "position" from a
> > > > > > > mathematically point of view ?
> > > > > >
> > > > > > I can't speak for Codd on this, and I don't choose to speak for myself.
> > > > >
> > > > > The only difference is the domain for the function, whether it is a set
> > > > > of counting numbers or a set of attribute names. If counting numbers,
> > > > > then there is an obvious order (function), represented as the order of
> > > > > a tuple.
> > > >
> > > > This is not true.
> > > >
> > > > If the numbers were explictily used as if they were names, in every place
> > > > where a specific attribute is specified, your statement would be true.
> > >
> > > I don't see how a function being explicitly written or not makes any
> > > difference. In some systems you can refer to an attribute either by
> > > name or number. They serve as two different names for the attributes.
> > >
> >
> >
> > I think I agree with David here Dawn, that there is a subtle difference

>

> I don't dispute that there is a difference. I just don't see what is
> so problematic about it.

If one just looks at the maths of a simple example. Consider a relation(ship) of fruit:

fruit = {

 { (name, apple), (colour, green), (size, medium) }
 { (name, banana), (colour, yellow), (size, large) }
 { (name, date), (colour, brown), (size, small) }

}

There's no getting away from the fact that because each 'tuple' is just a set of attribute/value pairs the order we write them down in is necessarily unimportant. To refer to them positionally, now that this is an RM-relation and not a purely mathematical-relation, every single tuple must have a common ordering applied to it. So for the first 'tuple', if we say:

fruit_order = {
  ( (name, apple), (colour, green) ) ,
  ( (colour, green), (name, apple) )
}

and apply an equivalent ordering to this for all rows, only then can we (mathematically) refer to each attribute/value by its position.

There clearly exists no mechanism for implementing or extracting such orderings to an RM-relation (and if there was, how would it be affected by Joins? I imagine generating a partial ordering would be the simplest solution). Perhaps there should?

>


> > - given a mathematical relation is a list of elements (whose order is

> > specified by the order of its domains), when one refers to the 'first'
> > or 'second' element one is using knowledge external to the model

>

> unless you include it in the model, in which case it is part of the
> model. A reason why it might be an advantage in a model is if you did
> not want to fix the attribute name or want to have synonyms without
> designating one as most important. These are both viable for a data
> model, even if not part of the RM.

The only way I can see to include ordinal position within the model is as my last paragraph. Cardinal labels are of course no different from any other other field name, but as a pickie you'd prefer ordinality no?

>


> > in

> > order to ascertain which domain each element corresponds to. My

> > impression was that Codd believed the cognitive load of maintaining
> > this meta-knowledge to be deleterious,

>

> That could be. I would also agree it is easier to remember an
> attribute name than number.

>


> > and so added attribute naming.

> > Being aware of this subtle distinction he proposed a name change to
> > 'relationship' (which I learnt from yourself in fact).

>

> Yes, he writes that in the 1970 paper. In what Pascal calls "Dawn's
> Proof" or something like that, I made a joke about the fact that the MV
> model, which does have an ordering (which relates to a physical
> ordering, admittedly) actually models the data in relations (rather
> than relationships) so (I claimed, tongue in cheek) it is more
> relational than the RM. While Fabian claims that to be my proof that
> the MV is relational, I have always held that the Pick model clearly
> pre-dates and is different from the RM.

Aye, saying things tongue cheek seems to be a minefield if people have the urge to use it to club you with later on, because it can never maintain its original context.

>

> Outside of the issue of how coupled a logical model is to the physical
> model, I see no harm in numbering the attributes provided you also name
> them. I have seen statements about how the attributes must be
> unordered written by several RM authors. It just seems to be an
> unimportant and unnecessary point. Cheers! --dawn

I think i'm just emphasising the difference between ordinality and cardinality.

All best, J. Received on Fri Apr 07 2006 - 06:13:06 CDT