Re: The Theoretical Foundations of the Relational Model

From: Paul G. Brown <paul_geoffrey_brown_at_yahoo.com>
Date: 24 Jun 2002 18:07:22 -0700
Message-ID: <57da7b56.0206241707.19e86f22_at_posting.google.com>


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.

   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.

    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.

    Hope this helps. (Sorry, JR).
    KR

            Pb Received on Tue Jun 25 2002 - 03:07:22 CEST

Original text of this message