Re: Polymorphism sucks [Was: Paradigms which way to go?]

In article <4333f6a8@xxxxxxxxxxxxxxxxxxxxxxx>,
Dusty Bin <lixo@xxxxxxxx> wrote:
>Christian Brunschen wrote:
>> In article <43328e59$1@xxxxxxxxxxxxxxxxxxxxxxx>,
>> Dusty Bin <lixo@xxxxxxxx> 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
.