Path: text.usenetserver.com!out04b.usenetserver.com!news.usenetserver.com!in02.usenetserver.com!news.usenetserver.com!postnews.google.com!d55g2000hsg.googlegroups.com!not-for-mail From: Cimode Newsgroups: comp.databases.theory Subject: Re: A simple notation, again Date: Thu, 19 Jul 2007 12:53:54 -0700 Organization: http://groups.google.com Lines: 138 Message-ID: <1184874834.578954.315070@d55g2000hsg.googlegroups.com> References: <1184785145.523735.182430@i38g2000prf.googlegroups.com> <3qzni.130501$NV3.628@pd7urf2no> NNTP-Posting-Host: 82.230.226.33 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1184874834 29292 127.0.0.1 (19 Jul 2007 19:53:54 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 19 Jul 2007 19:53:54 +0000 (UTC) In-Reply-To: <3qzni.130501$NV3.628@pd7urf2no> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.2; fr; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: d55g2000hsg.googlegroups.com; posting-host=82.230.226.33; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: usenetserver.com comp.databases.theory:165885 X-Received-Date: Thu, 19 Jul 2007 15:53:54 EDT (text.usenetserver.com) On 19 juil, 03:48, paul c wrote: > Cimode wrote: > > On 17 juil, 15:57, paul c wrote: > > >>Cimode wrote: > > >>>On Jul 16, 7:05 pm, "Brian Selzer" wrote: > > >>>>"David Cressey" 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 In this case R1 = R2 if and only if A = B. That condition *is* what bothers me(I agree row order is a minor point). The problem is more obvious using 2 attributes for R1 and R2 R1 A1 A2 1 PAULC 2 MARSHALL = R2 B2 B1 MARSHALL 2 PAULC 1 IF and only IF [(A1 = B1) AND (A2 = B2)] (OR [(A1 <> B2) AND (A2 <> B1)] expressed differently).... When considering p the position of the matching attribute in some other relation expression Such dissimetry can hardly be generalized to N as Degree 1 ......R1 = R2 .....IF and only IF A = B Degree 2.......R1 = R2 .....IF and only IF [(A1 = B1) AND (A2 = B2)] ..... ..... DegreeN.......R1 = R2 .....IF and only IF [for all degrees p from 1 to N (Ap = Bp)] I find that quite constraining...especially in intersect operations. I do believe that such order assumption, even explicit imposes a base of N logical operations (compare Ap to Bp) to simply express 1 inter relation equation (in this case R1 and R2)..A single unit permutation of attributes allows to reduce the number of logical operations to (N-1) to conclude that R1 = R2 > 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. This is where the frustration begins. To my knowledge, I did not find any trace of his writing refering specifically to the problem of fully adress *lack of order*. Asked as a question: how can a grammar reflect (or maybe use) the lack of order in columns for making operation simpler? > 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. Cimode is atomic. No debate here. > 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. I am not convinced that there is such thing as *proper ordering* except the one that reduces the number of logical operations necessary to complete an operation between 2 relations. > 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". Respectfully, I do not think we are refering to the same point. (probably my fault because of frustrating unmastery of English ;(...) > p