Polymorphism sucks [Was: Paradigms which way to go?]
in [OOP]
|
From: Dusty Bin on 23 Sep 2005 08:32 Christian Brunschen wrote: > In article <43328e59$1(a)news.totallyobjects.com>, > Dusty Bin <lixo(a)argus.pt> wrote: > >>Christian Brunschen wrote: >><snip> >></snip> >> >>>So, without attempting to validate or invalidate anything else on any side >>>of any argument, according to what I have quoted above, it should be >>>fairly clear that the term 'Relational' in 'Relational Database' has >>>_nothing_ to do with relationships between different tables: >> >>true >>The term >> >>>'Relation' is instead a different, more precise term for the type of >>>tables used in Relational databases. So, even a database with only a >>>single table, is a relational database. >> >>The relationship is the relation between the columns of a table. > > > Um, no. > > As defined in Codd's paper, a 'Relationship' is the same as a 'Relation', > except for one thing. In a 'Relation', the order of the attributes > matters, whereas their 'headings' are less important: one can, in a > Relation, have multiple Attributes with the same Heading, as each > Attribute is uniquely identified by its position within each Tuple in the > Relation. In a Relationship, Attributes are unordered, but are identified > by their Heading, which must of course now be unique. > > So the difference, in Codd's paper, is that a Relation is an unordered Set > of Tuples, in which the ordering of the columns is significant but the > names are less so; whereas a Relationship is an unordered Set of Tuples > where each Column is uniquely identified by its Name 9rather than by its > position). > > Or, to quote from Codd's paper, > > "In mathematical terms, a relationship is an equivalence class of those > relations that are equivalent under the permutation of domains [ ... ] ." > > > Of course, the term 'relationship' is another one of those that has become > vastly overloaded over the years: For instance, it is used in > 'Entity-Relationship modeling', to represent a connection between > different entities, and since E-R modeling is often used when designing > database schemas for relational databases, well, there's one source of > confusion right there. > > But the term 'relationship' does not in fact as you are trying to state, > com from there being a 'relation' between the different columns of a > relation. > > >>hth... Dusty > > > Best wishes, > > // Christian Brunschen > Christian, First of all, sorry to have confused the issue by using the term 'relationship', just a semantic error on my part, of course I meant relation. Unfortunately, I cannot lay my hands on Ted Codds paper right now, I assume you mean "A Relational Model of Data for Large Shared Data Banks", I've had it for over 30 years, and it is somewhere in my filing system, and I'll re-append when I find it if it differs significantly from below. I do however have Chris Dates "Introduction to Database Systems", where Chris paraphrases Ted's definition, in section 11 references(p246 in the 4th edition). "Given sets D1, D2, ..., Dn(not necessarily distinct), R is a relation on those n sets if it is a set of n-tuples, each of which has it's first element from D1, it second element from D2, and so on. The set Dj is said to be the jth domain of R.) More concisely, R is a subset of the Cartesian product of D1 X D2 X ... X Dn." The only ordering I see in this definition is that the order of the attributes must be in the same order of the domains, which by the way are arbitrary. Simply said the attributes of the rows, must be in the same domain as the header. To quote Chris Sonnacks sample table 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 - Alice could not have a COLOR of 5-3-1948, and a DATE of blue. For me, this table is a relation. Best regards... Dusty
From: Christian Brunschen on 23 Sep 2005 09:22 In article <4333f6a8(a)news.totallyobjects.com>, Dusty Bin <lixo(a)argus.pt> wrote: >Christian Brunschen wrote: >> In article <43328e59$1(a)news.totallyobjects.com>, >> Dusty Bin <lixo(a)argus.pt> wrote: >> >>>The relationship is the relation between the columns of a table. >> >> Um, no. >> >> As defined in Codd's paper, a 'Relationship' is the same as a 'Relation', >> except for one thing. In a 'Relation', the order of the attributes >> matters, whereas their 'headings' are less important: one can, in a >> Relation, have multiple Attributes with the same Heading, as each >> Attribute is uniquely identified by its position within each Tuple in the >> Relation. In a Relationship, Attributes are unordered, but are identified >> by their Heading, which must of course now be unique. >> >> So the difference, in Codd's paper, is that a Relation is an unordered Set >> of Tuples, in which the ordering of the columns is significant but the >> names are less so; whereas a Relationship is an unordered Set of Tuples >> where each Column is uniquely identified by its Name 9rather than by its >> position). >> >> Or, to quote from Codd's paper, >> >> "In mathematical terms, a relationship is an equivalence class of those >> relations that are equivalent under the permutation of domains [ ... ] ." >> >> >> Of course, the term 'relationship' is another one of those that has become >> vastly overloaded over the years: For instance, it is used in >> 'Entity-Relationship modeling', to represent a connection between >> different entities, and since E-R modeling is often used when designing >> database schemas for relational databases, well, there's one source of >> confusion right there. >> >> But the term 'relationship' does not in fact as you are trying to state, >> com from there being a 'relation' between the different columns of a >> relation. >> >> >>>hth... Dusty >> >> >> Best wishes, >> >> // Christian Brunschen >> >Christian, >First of all, sorry to have confused the issue by using the term >'relationship', just a semantic error on my part, of course I meant >relation. The significant overloading of the term 'relationship' and its visible similarity with the term 'relation' cause lots of interesting problems. Of course, it was precisely to avoid such problems that Codd, rather than using the then-prevalent terminology for data storage (such as 'records' and 'files'), used mathematical terminology such as 'relation', 'tuple', and so on. >Unfortunately, I cannot lay my hands on Ted Codds paper right now, I >assume you mean "A Relational Model of Data for Large Shared Data >Banks", I've had it for over 30 years, and it is somewhere in my filing >system, and I'll re-append when I find it if it differs significantly >from below. The text of the paper can be found on the ACM web site, at <http://www.acm.org/classics/nov95/toc.html> >I do however have Chris Dates "Introduction to Database >Systems", where Chris paraphrases Ted's definition, in section 11 >references(p246 in the 4th edition). > >"Given sets D1, D2, ..., Dn(not necessarily distinct), R is a relation >on those n sets if it is a set of n-tuples, each of which has it's first >element from D1, it second element from D2, and so on. The set Dj is >said to be the jth domain of R.) More concisely, R is a subset of the >Cartesian product of D1 X D2 X ... X Dn." > >The only ordering I see in this definition is that the order of the >attributes must be in the same order of the domains, which by the way >are arbitrary. Simply said the attributes of the rows, must be in the >same domain as the header. Indeed. What I was describing above was Codd's description of a _relationship_, as distinct from a _relation_, as he describes in section 1.3 of his paper: <quote> [ ... ] [W]e propose that users deal, not with relations which are domain-ordered, but with relationships which are their domain-unordered counterparts. To accomplish this, domains must be uniquely identifiable at least within any given relation, without using position. Thus, where there are two or more identical domains, we require in each case that the domain name be qualified by a distinctive role name, which serves to identify the role played by that domain in the given relation. For example, in the relation component of Figure 2, the first domain part might be qualified by the role name sub, and the second by super, so that users could deal with the relationship component and its domains - sub.part super.part, quantity - without regardto any ordering between these domains. To sum up, it is proposed that most users should interact with a relational model of the data consisting of a collection of time-varying relationships (rather than relations). Each user need not know more about any relationship than its name together with the names of its domains (role qualified whenever necessary). </quote> >To quote Chris Sonnacks sample table > >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 - > >Alice could not have a COLOR of 5-3-1948, and a DATE of blue. > >For me, this table is a relation. I agree that the table that Chris Sonnack used as an example appears to fulfil the requirements for being a relation. >Best regards... Dusty Best wishes, // Christian Brunschen
From: Chris Sonnack on 23 Sep 2005 20:39 Antoon Pardon writes: >> 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. > > Then IMO you are wrong. It are the records (the tuples) that make > out the relation. Indeed. See my reply to Christian. > Then you are wrong. This table is a relation. Yeah, drat it! Shoulda made it violate one of the rules. ;-\ -- |_ CJSonnack <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: Chris Sonnack on 23 Sep 2005 20:38 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 <Chris(a)Sonnack.com> _____________| How's my programming? | |_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL | |_____________________________________________|_______________________|
From: topmind on 23 Sep 2005 22:14
Chris Sonnack wrote: > 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. > One could still do useful queries such as "show me all green products with a list price of less than 5.00" on a single table/view. In fact, often the goal is to produce a single table "view" from joined tables with all the columns needed to do simple predicate queries. In other words, one often spends the first half of the query effort producing the proper single-table view via joins, and then the 2nd half use those (some calculated) columns as if they were part of only one actual table. -T- |