Subj : Re: Polymorphism sucks [Was: Paradigms which way to go?] To : comp.programming,comp.object From : Chris Sonnack Date : Fri Sep 23 2005 08:38 pm Christian Brunschen writes: >>> 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.... > > Yes, a specific kind of table. Okay, let me just start by saying, "Okay, I see that a 'relation' is indeed a (specific kind of) 'table', and we can consider the issue closed." The rest of this is just in nitpicky programmer Friday afternoon fun.... I'm not entirely sure I agree (at this point) that a 'relational database' does not consist of relations that are, in fact, um, related. It seems that a single relation with no relationSHIPS isn't very useful, nor is it much of a database. (Not that that's very relevant to the definition of a relation. :-) However, will you agree that, while relations are tables, not all tables are relations. Can't a table--just a table--fail to follow the rules Codd laid down for tuples and therefore NOT be a relation? Thus is seems to me that--strictly speaking this is NOT true: table == relation Relations are, it seems to me, a subset of all tables. > Indeed, anything that uses SQL is basically forced by the SQL > standard(s) to implement something that in some respects departs > from the pure relational model. I've heard DB theorists say this...I'm curious, what is it about the SQL standard that forces this? And, ironically, this brings us back to the original point about whether SQL is a "relational language". > Yet we talk about 'relational databases' nonetheless, and we use > relational theory, and it all works. Indeed. (If I wanted to drag this out painfully, I might try to argue the case that 'relational' strongly implies more than a 'relation' and that a single 'relation' with no FKs would not, in fact, be 'relationAL', but would be just a lonely little 'relation'. But I don't want to drag this out, so I won't.) > Specifically, in response to the assertion > >>>>> 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. > > you replied > >>>> 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. > > In other words, you were asserting that the term 'relational' _does_ > have something to do with keys and their referencing stuff - which it > doesn't. Well,.... per my parenthetical thought above, I think one could at least try to argue the point. 'RelationAL' could certainly mean a database built on 'relationS' that are 'relatED'. (-: >>You know, maybe we should just go to the source: >> >> http://www.acm.org/classics/nov95/toc.html > > Maybe we should. Incidentally, why haven't you done just that prior to my > posting? Well, for one thing, I like debate. (-: And I just found that link after reading your post, but didn't have time to read the entire paper. I did print it for reading later--this stuff doesn't apply to the work I do currently, but I find it interesting enough to pursue when time permits. > Or indeed, prior to making your inaccurate assertion - then this > whole flamewar would have been avoided. I've never claimed to be a database expert. I got into this rather wretched thread speaking out *against* what I saw as silly overuse of them. It spiraled down from there, and I'm still not sure I wasn't trolled. (But it was amusing enough to be engaging even so.) >>> In Chapter 11, 'Relation Structure', the book introduces formal >>> definition for each term, which I will not quite here; >> >> Aw, why not? > > Because thay are *long*, and I only had a limited amount of time > available when composing my post. Exactly why I wasn't able to do more than skim Codd's paper. > [snip] > Look - nothing here about keys or references to anything, inside or > outside the relation itself. > > You'll eventually have to accept that the term 'relational' has > nothing to do with keys, or references, or similar; just with > each individual _relation_ itself. That's fine if we grant that 'relational' == 'consisting of relations'. And I will accept it as such....certainly if that's the convention. >> 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. > > The point that you missed is that even a single table is still a relation > in the 'relational database' sense. The fact that there is only one table, > or the fact that there are no foreign keys, does not make the database any > less 'relational'. Well.... I'm less convinced here, actually. Suppose you have a table that does not meet the requirements of a relation? And haven't you already suggested the SQL standard violates at least some aspects of the relational model? >> And turned into a mini-war from there. > > Fanned on by the fact that neither side apparently bothered to > properly research the issue. I don't generally do my opponent's work for him. (-: > A database with a single table that doesn't refer to anything else, is > *just as* relational as a database with lots of tables that refer to each > other using foreign keys. It's that simple. EVEN IF the table fails to meet the requirements of a relation? > Well, guess what, a 'flat table' can still be a 'relation'. [ It also may > not be, if it contains duplicate rows, or breaks one of the other > requirements (none of which are really particularly onerous); but the > above table doesn't, so the above table certainly looks like it would > qualify as being a 'relation'. ] And if I added a duplicate row or other violation of the rules? > In other words, there is no difference in how 'relational' a database is, > simply because of the number of tables in it, or the number of foreign > keys or other references between tables. Consider me slightly more educated about relational databases now! > You may not recignise the 'relational-ness' of the table you have > skeitched above, but it's there. Heh.. .just means I SHOULD have done the research and come up with a better--non relational--table! (But gimme a little slack--I'm putting in 12-hour days at the moment (and per a cothread in this group, loving every minute of it).) > Your table above, which you attempted to use as a counterexample, appears > to qualify as a relation. Of course, if you were to introduce multiple > identical rows, then you'd no longer have a relation - but then that's a > deliberate choice, and would be no different if this table was one of > several ones that were referencing each other. Understood. > The end result is that your original assertion remains incorrect, and that > the general statement 'relation == table' _is_ substantially correct, your > protestations to the contrary. Are you saying that because 'relation' comes first, so (to you) the statement reads, "all relations are tables"? By what you've written, it appears, perhaps, you would disagree that: table == relation ? To me, the statement reads that 'table and relation' are identical in all ways (regardless of the order of the terms). Anyway, thanks for stepping in and educating me. (-: -- |_ CJSonnack _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________| .