Re: 4 the FAQ: Are Commercial DBMS Truly Relational?

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Sun, 10 Oct 2004 13:29:58 -0400
Message-ID: <qirbkc.3c8.ln@mercury.downsfam.net>

Christopher Browne wrote:

>>> However, note that the result of an outer join is not necessarily a
>>> relation,  even if both of the operands are relations.
>>
>> You lost me. Do you mean something besides the part where
>> there are no rows on the right corresponding to rows on the
>> left, or do you mean something else?

>
> No, the problem is much simpler than that; it doesn't require a join
> to observe it.
>
> If you cut columns off of the result set, it is possible for the
> result set to, in fact, not be a "set", but rather a non-unique "bag"
> of tuples.
>
> Thus, if I have a transaction table, I might write the query:
>
> select customer_id from transactions where txn_date between
> 'one date' and 'another date';
>
> That is NOT going to be a "set" or a "relation" if some customer made
> multiple purchases between those dates.
>
> The problem that this expresses is that the relational algebra does
> not satisfy the property of closure.
>
> You normally hope/expect to have closure in a mathematical system. If
> you add two integers, you get an integer as a result. Likewise for
> subtraction, multiplication, and even division, assuming some
> rounding.
>

By your statements above, that relational algebra allows answers that are not always relations, so how can we hope to have a DBMS implementation that does so?

To get a TRDMS, (or a TRDMS query language), do we unconditionally do the equivalent of a SELECT DISTINCT... on every SELECT, and give the user no way to circumvent it? Do we also have the behind-the-scenes constraint that every table must be unique across all columns, again without giving the user a way to circumvent?

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me

Received on Sun Oct 10 2004 - 12:29:58 CDT