Re: XQuery question

Neo wrote:

>>As I understand it, the "relation" in relational theory concerns
>>the relationship between the values of attributes in the *same* row
>>(or tuple),
>>
>>
>
>It seems to me the above definition of a relation is slightly
>differently than most texts. Most texts seem to say a relation is a
>set of related information having the structure of a header and a set
>of tuples where the named attributes can have values from their
>underlying domains. Most texts do not define a relation in terms of a
>tuple alone. Which is correct (according to rdm)?
>

I was just speculating on why relations are called relations, not trying to define them.

My understanding is that the word RELATION referres (in this context) to the relationship between values in the same row. So (one more example) if you have the table PERSON with columns NAME and HAIR_COLOR and you have a row with the values 'JOHN' and 'BROWN' we have a relationship between the values 'JOHN' and 'BROWN'. This is what RELATION in the RELATIONal model referres to (I think).

>>Relationships between values in different tables are captured via
>>*integrity constraints*, of which referential integrity is just
>>a special (albeit important) case.
>>
>>
>
>So officially relationship is not a word defined by/in rdm. And
>relationship between values in different tables is captured via
>contraints. Thus in rdm-speak T_Car has a constraint with T_Color,
>which is good because otherwise people would get confused since the
>words relation and relationship are synonomous according to Roget's
>Thesaurus.
>
You are right that terminology is a bit confusing. However, I would not necessarily
use the term "has a constraint with". Depending on context I would talk about
referential integrity, or, well, relationships!

Come to think of it even primary and candidate keys (=unique keys) can be expressed
as constraints, so they are not part of the very basic model. Of course keys (candidate keys)
are important in normalisation theory, but that is not the same as the relational model.

>>What this means is that for example tables cannot have invisible
>>pointers to save relationship information between different rows.
>>All such references must be made via columns having the
>>same value.
>>
>>
>
>I think rdm says a tuple's attribute's value and the same value in the
>underlying domain have a contraint,
>
The rule is that the attribute should have a value that belongs to the corresponding domain.
So if a column is of type DATE, it should have a valid date-value.

>but it does not specify how that
>constraint should be implemented, whether via equal values, IDs or
>even pointers, although experience thus far has us favoring the
>implementation with IDs. Does rdm infact specify which implmentation
>is proper and which is not?
>
The relational model is not concerned of implementation in the least.  It just specifies how and
what the user sees. It's like a gas pedal in the car. All the user is interested in is that when
he kicks the pedal the car goes faster. How this is accomplished is just a (minor!) implementation
detail for the user. The car manufacturer is free to change the implementation, as long as the
function of the pedal remains the same.

regards,
Lauri Pietarinen Received on Thu Jun 05 2003 - 14:11:02 CEST