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

From: Christopher Browne <cbbrowne_at_acm.org>
Date: 10 Oct 2004 02:54:58 GMT
Message-ID: <2srmk1F1njk29U1_at_uni-berlin.de>


Centuries ago, Nostradamus foresaw when "Marshall Spight" <mspight_at_dnai.com> would write:
> "Laconic2" <laconic2_at_comcast.net> wrote in message news:tOKdnUpZC8NPtvXcRVn-sg_at_comcast.com...
>>
>> "Marshall Spight" <mspight_at_dnai.com> wrote in message
>> news:bVT9d.361333$Fg5.257522_at_attbi_s53...
>>
>> > NULLs certainly suck in a lot of ways. In the context of the
>> > semi-mainstream definition of 1NF (what Alfredo would call
>> > the broken definition) NULLs are hard to get away from, because
>> > you need some operation like LEFT OUTER JOIN. If you
>> > have Relation Valued Attributes (RVAs) and some GROUP BY
>> > operator, though, you don't need NULLs even for OUTER
>> > JOINs.
>>
>> 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.

The problem with relational algebra is that you can start with relations, manipulate them using relational operations, and get a result that is _not_ a relation.

>> One of Codd's 12 rules was that a relational DBMS should have a
>> systematic treatment of NULLS.
>>
>> That, by itself, seems to me to be an admission that the relational
>> data model is not as abstract as the relational calculus is. Not
>> that I object, mind you.
>
> Hrmn, uh, dunno. I guess I'm not sure I believe in the "relational
> data model" as a fixed entity, although that notion is certainly
> popular is some quarters. I myself am working on "a" relational
> model that doesn't have NULLs of any kind, although it does have a
> "systematic treatment of" optional data.

I rather think that there need to be _some_ common properties...

-- 
output = ("cbbrowne" "_at_" "linuxfinances.info")
http://www.ntlug.org/~cbbrowne/rdbms.html
What do you get when you multiply six by nine?
Received on Sun Oct 10 2004 - 04:54:58 CEST

Original text of this message