Re: A simple notation, again

From: David Cressey <cressey73_at_verizon.net>
Date: Thu, 19 Jul 2007 11:39:06 GMT
Message-ID: <u3Ini.6712$Wh4.1446@trndny06>

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:3qzni.130501$NV3.628_at_pd7urf2no...
> Cimode wrote:
> > On 17 juil, 15:57, paul c <toledobythe..._at_oohay.ac> wrote:
> >
> >>Cimode wrote:
> >>
> >>>On Jul 16, 7:05 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >>
> >>>>"David Cressey" <cresse..._at_verizon.net> wrote in message
> >>
> >>...
> >>
> >>
> >>>>How about something like this
> >>>>{(Last, First, Num) :
> >>>>("David", "Cressey", 1),
> >>>>("Marshall", "Spight", 2),
> >>>>("Bob", "Badour", 3),
> >>>>("Jan", "Hidders", 4)}
> >>
> >>>You imply order (adjacency) when relation attributes should not be
> >>>subjected to any....
> >>
> >>When Codd wrote of eliminating order dependency, he wasn't talking about
> >>language notations or grammars, in fact he used ordering to describe his
> >>idea!
> >
> > Thank you for pointing that out. I was ranting on something I never
> > totally felt comfortable with. To remain coherent with the unordered
> > nature of sets, I always felt frustrated that representing *grammar*
> > of a relation would be otherwise than by *not* assuming order. I
> > thrust it becomes imperative when representing relation as tables and/
> > or because we include the header as part of relation definition. In
> > other words why
> >
> > R1 = {("David", "Cressey", 1), ("Jan", "Hidders", 4)}
> > <>
> > R2 = {("David", "Cressey", 1), ("Hidders", "Jan", 4)}
> >
> > --> because if an ordered header H1 = {("FirstName", "Last",
> > "Number")} is associated to the definition of R1 AND because H1 is
> > necessarily ordered...
> > ...

>

> I think the ordering dependence Codd had in mind doesn't have to do with
> the nature of sets, rather the internal organization and the external
> presentation of relations, or even tables and the operations a system
> supports. Date said something like users shouldn't be forced to use a
> single pre-defined ordering and that's what I think Codd was after. I
> think he simply wanted

>

> R1:
> A
> 1
> 2

>

> and

>

> R2:
> B
> 2
> 1

>

> to be equal as far as his calculus and algebra were concerned.

>

> And (I think) he wanted to make sure that any representation of a
> relation, such as "tables" wouldn't depend on column ordering, which is
> why he wanted to take names of "columns" out of programs and put them in
> the db.

>

> For myself, being a sloppy typist (and writer, ha, ha) I usually want a
> system to treat Magoo, magoo and MAGOO as equal and I'm usually quite
> happy if *I* can pre-define all domains to treat those as the same,
> tables to not show them as different. So I might see "Cimode" in my
> table and if I then try to insert "CIMODE", the system might fold the
> value into upper case and just to please me, show "CIMODE". But that's
> only because I told the system in advance to do things that way, not
> because its algebra depends on that arrangement.

>

> So, I can be certain that my single-user system pleases me and doesn't
> base its decisions on somebody else's idea of what is proper ordering.

>

> Actually, I think it is a fairly minor point of Codd's, he just wanted
> to make sure that ordering could not change the information in an
> answer, which I would have thought would be a natural consideration for
> any thoughtful developer. As much as I criticize SQL (which I think is
> easy even if I don't know it much!), I don't see anything wrong with
> "ORDER BY".

>

I'm with you on this right up to the point where you say you think that this is a fairly minor point of Codd's.

List processing systems were quite well developed in 1970, both in terms of processing, and in terms of storage and retrieval. The Pick system that sometimes gets touted in here is basically a list processing system. List processing systems are fundamentally different from systems based on the relational model precisely because the list (1, 2) is not recognized as equal to the list (2, 1). Whether this is a convenience to the user-programmers, or represents an additional burden on them, in terms of the semantics of the data, is a very major point, indeed.

The above says, somewhat more formally, what I was driving at a few years back, when I asked whether a pizza with onions and pepperoni was or was not the same thing as a pizza with pepperoni and onions. Unfortunately most of the discussion ignored the point behind the question. Received on Thu Jul 19 2007 - 06:39:06 CDT