Re: The Theoretical Foundations of the Relational Model

On 24 Jun 2002 18:07:22 -0700, paul_geoffrey_brown_at_yahoo.com (Paul G. Brown) wrote:
>JXSternChangeX2R_at_gte.net (JRStern) wrote in message
>> Since order doesn't matter to the
>> predicate logic, this could be allowed without loss. Of course, order
>> is allowed in result sets. Why should a result set be able to have
>> some property (order, nonuniqueness of members) that base tables and
>> relations do not?
>
> I'm not so sure.
>
> Making it necessary for data to be ordered makes it difficult to
> use a data model in certain problem domains.

"If it hurts, don't do it."

We allow simple mathematical relations between fields where type allows, just as we would allow ordering where either the specification is clear, or where the user could (heavens!) be allowed to specify the comparison operator.

> For many domains, order and value-equivalence (equality) are obvious. This
> is true for the simple numbers and strings of the SQL (and quel) languages,
> but order is not a property of all number domains, nor even of all interesting
> business objects.
>
> Complex numbers, spatial objects, linear algebra values (matrix for
> operations research problems) and graphs (alternative dependency graphs in
> manufacturing) have value-equivalence but not ordering (how do you arrange a
> list of complex numbers?). It's certainly possible to play tricks with the
> binary representation of these domains in order to make merge-joins on
> equi-predicates efficient, but because it is not meaningful to ask the
> question "all elements of C between (5.i + 3) and (-6.i + 2 )" order
> is not part of the logical model.

Sure, there are issues, which is why traditional relational databases didn't allow anything but simple datatypes. These days we put complex things into BLOBs, or some vendors support fancy types as native.

> Even value-equivalence is hard. For graphs, one of several kinds of
> 'value-equivalence' might be selected: isomorphism, homomorphism, same
> spanning sub-graph. For some interesting domains there is neither
> uniqueness, nor order (retina scans, fingerprints) and only a contingent
> (probabilistic) notions of value-equivalence (we say that this retina scan
> and that retina scan are random samples of the same population with a
> probability of 0.99999). Were you to define 'equivalence' as 'pixel-for-pixel
> equivalence' then you would stuff your chances of including in the database
> a host of truly useful rules.
>
> Never-the-less we can still reason about these objects (show me all people
> who are male, 5' 11" tall, dark haired and have a finger-print matching this
> one), so whatever underlying model we elect to use for our repository needs
> to be able to cope with them.

Exactly. If we can cope with the datatypes, then there's no problem. And if we can't cope with the datatype for ordering, we have so many problems, ordering is the least of them. Happens all the time with BLOBs. Allowing user-defined operators would often do the trick, don't see why vendors have been so slow to address. Dogmatism, mostly.

> Hope this helps. (Sorry, JR).

You made lots of fine statements, none of which I took negatively.

J. Received on Tue Jun 25 2002 - 04:27:33 CEST