Re: Foreign key problem

From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 16 Jun 2006 19:51:52 GMT
Message-ID: <sZDkg.46244$Mn5.40308_at_pd7tw3no>


paul c wrote:

> x wrote:

>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>> news:Szfkg.33274$IK3.15126_at_pd7tw1no...
>>
>>> If Codd used the word glue I imagine it might have been as a synonym for
>>> coherence, which I could buy if I knew his context.
>>
>> Here is the context you asked for:
>>
>> Chapter 3: Domains as Extended Data Types, page 44.
>> Section 3.2 Nine Practical Reasons for Supporting Domains:
>>
>> "_First_, full support of the domain concept is the single most important
>> concept in determining whether a given relational database is integrated.
>> Consider the consequences of alleging that a relational database
>> viewed as a
>> collection CD of domains and a collection CR of relations could be split
>> into two databases, without any loss of information or of retrieval
>> capability."
>>
>> "This first reason for supporting domains can be concisely stated as
>> follows: _domains are the glue that holds a relational database
>> together_.
>> Notice that I said _domains_, not primary keys and foreign keys. The
>> concept
>> of keys in the relational model provides an important additional and
>> specialized kind of glue."
>>
>> From what I've read so far, the importance of domains is emphasized in
>> several chapters.
>> ...
> 
> 
> Thanks very much for typing that in.  It does look to me as if Codd had 
> coherence in mind because he talks of holding a relational database 
> together even though his example may be too deep for me.  The test of 
> splitting the database eludes me because I don't see how domains and 
> relations could be separated.  I thought of a relation as being a set of 
> sets of mappings between individual values of domains, meaning to me 
> that loosely, relations result from "gluing" subsets of domains together 
> so I didn't see how one could 'subtract' domains and still be able to 
> 'see' a relation.
> 
> p
> 

On second thought, I can see a stronger connection assuming Codd had in mind how certain aspects of a domain are indivisible from the domain itself (which I would agree with). I.e., a notion of equality is part and parcel of the notion of a domain. For example, in a domain of people's names, I would prefer that "paul c" and "Paul C" would identify the same person. I'm not sure if this is exactly what D&D use the term "representation" to take care of. Anyway, if Codd meant that you can't have a domain without being able to say when two sets of symbols stand for the same element, I can certainly buy that. In other words his relations can't exist without domains, so I could think of them as metaphorical glue.

On the face of it, what I've just said isn't saying much. I imagine Codd was thinking a little outward, towards implementations as I am pretty sure that in nearly everything he wrote, he was implicitly disparaging data management practices used in the real world, such as using EBCDIC or ASCII bit arrangements to determine order, which even naive users find nonsensical, e.g., when they look at a table that places "x" before "Bob Badour" and places "X" after it at the same time as they wonder why the person named "x" shows up twice.

(This is sort of why I've said in the past that the rm has no idea what equality is which sounds stupid when it obviously can tell us when two relations are equal - maybe what I should have said is that it depends on domains to decide equality.)

p Received on Fri Jun 16 2006 - 21:51:52 CEST

Original text of this message