Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Thu Sep 22 2005 09:06 pm Ah, at last, an intelligent answer from someone who appears to know what they're talking about! Cool!! Christian Brunschen writes: >>> The term "relational" has nothing to do with keys and their >>> referencing stuff. I used to think it did, but like you now, >>> I was wrong. You lost this one. >> >> EVERY resource I checked agrees. You have yet to produce anything >> other than arm waving to support your point. If you are right and >> I'm wrong, where's the proof? Should be easy enough to find. > > Let me quote from "An Introduction to Database Systems, Volume 1, Fifth > Edition" by C. J. Date (Addison-Wesley, 1990) - > > > At this point, the reader may be wondering why relational databases are > called "relational" anyway. The answer is simple: "Relation" is just a > mathematical term for a table (to be precise, a table of a cedrtain > specific kind - details to follow in Chapter 11). Ah ha. A certain specific KIND of table. Okay, let's skip to Ch.11.... (Given what you say far below, it appears the next bit isn't from the vaulted Chapter 11, so I'm trimming without mercy here....) > The principles of the relational model were originally laid down by one > man, Dr. E. F. Codd, at the time a member of the IBM San Jose Research > Laboratory [ ... ] . it was late in 1968 that Codd, a mathematiccian > by training, first realized that the discipline of mathematics could be > used to inject some solid principles and rigor into a field - database > management - [...]. Codd's ideas were first published in a now classic > paper, "A Relational Model of Data for Large Shared Data Banks") [ ... ] You know, maybe we should just go to the source: http://www.acm.org/classics/nov95/toc.html > The formal theory therefore does not use the term "record"at all; > instead, it uses the term "tuple" (short for "n-tuple"), which was > given a precise definition by Codd when he first introduced it. [...] > it is sufficient to say that the term "tuple" corresponds approximately > to the notion of a flat record instance (just > as the term "relation" corresponds approximately to the notion of > a table). You notice the use of "approximately" twice? > In Chapter 11, 'Relation Structure', the book introduces formal definition > for each term, which I will not quite here; Aw, why not? > but I will quote form the introduction to the chapter, on page 249: Hey, better'n nothing! > > [ ... ] > * A _relation_ corresponds to what so far in this book we have generally > been calling a table. Ahem, "have GENERALLY been calling a table." > * A _tuple_ corresponds to a row of such a table [...] > And the meat of this lies in the definition of a tuple. And, after reading Codd's paper (link above), I'll agree that his definition of a "relation" does show a single table that--from his example in section 1.3--containing records not **obviously** linked. However, I suspect this is similar to a code fragment and only shows a partial picture of the whole. After all, I don't know any suppliers named "1", "2" or "4". (A few paragraphs later he talks about "relationships", so I think there's still some wiggle room here! :-) > So, [...] it should be fairly clear that the term 'Relational' in > 'Relational Database' has _nothing_ to do with relationships between > different tables: Which I never claimed it was. I had to go read the back thread to recall how this started, but it began over a disagreement whether SQL was a "relational language". I suggested it would work perfectly well in a non-relational database containing a single (non-related) flat table. And turned into a mini-war from there. I stand by the original seed: SQL is not a "relational language". I also stand by the idea that "relational", in "Relational Database" is about *relationships* between records. I claim that if there are no relationships, there's no Relational. > The term 'Relation' is instead a different, more precise term for > the type of tables used in Relational databases. Exactly. Pay attention to the words: "...the TYPE of tables." Not just you plain old tables, but (as quoted above), " table of a cedrtain [sic] specific kind". VERY important distinction. Here's what I wrote over a month ago: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Here's a table (first row headers): NAME UID COLOR DATE TYPE Alice - Blue 5-3-1948 BG45 Bob - Red 5-3-1948 XL220 Carol 3345 Red 12-7-1955 E30F Dave 7709 Green 9-14-2000 - I dispute your "relational==table" definition, so I see not one thing that makes this table "relational". It's just a (what I'd call) "flat table". Given something containing this table that also supported SQL, you could write: Select NAME,COLOR from TABLE order by NAME ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > So, even a database with only a single table, is a relational > database. Only if it's a certain *specific* *type* of table. (-: -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .