Re: XQuery question

neo55592_at_hotmail.com (Neo) wrote in message > Since the relational data model (rdm) defines a "relation" as being a
> set of tuples which is generally conceptualized as a table, the above
> sentence in rdm-speak would translate to "tables between tables" which
> is probably not what you meant. What word did rdm formally assign to
> the word "relation" as used in the above sentence? Surely rdm has a
> formal word for that very basic and fundamental concept.

As I understand it, the "relation" in relational theory concerns the relationship between the values of attributes in the *same* row (or tuple),
e.g. if we have the table

customer(cust_id, cust_name) and in the table a tuple with the values '5' and 'Acme' then '5' and 'Acme' have a relationship.

Relationships between values in different tables are captured via *integrity constraints*, of which referential integrity is just a special (albeit important) case.

Say we have the two tables
customer(cust_id, cust_name) and
person(person_id, person_name, cust_id).

Obviously we would want that every value of cust_id that is found in the 'person' table can be found in the cust_id column of the 'customer' table.

We could define the following integrity constraint to capture the relationship between the two tables (or between the values of the two attributes, actually):

NOT EXISTS
  ( SELECT *

      FROM PERSON P
      WHERE NOT EXISTS
        ( SELECT * FROM CUSTOMER C
            WHERE P.CUST_ID = C.CUST_ID )

Because referential constraints are so commonly needed we have shortcuts available, so that we don't have to express them so tediously.

So actually the relational model is quite neutral as to the types of constraints we impose on our databases. We (as humans) have just decided to emphasise the referential intergrity side, and it is of course important from the normalisation point of view.

The relational model adhers to the
"Information Principle" given by Codd:

"All information in the database must be cast explicitly in terms of values in tables and in no other way."

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.

Actually, strictly speaking, the 'cust_id' attribute in 'person' does not *refer* to 'cust_id' in customer, but just "happens" to have the same value. The database constraint enforces this but the semantic meaning is given by us (humans).

I hope this clarifies the concepts. It might not be immediately clear as to why the information principle is so important. It has to do with many issues, one of them being separating the logical model from it's implementation.

regards,
Lauri Pietarinen Received on Sun Jun 01 2003 - 23:40:13 CEST