Re: Discovering new relationships

On Mar 2, 12:01 pm, "Walt" <wami..._at_verizon.net> wrote:
>
> Now we've got the following join.
>
> select R.*, S.*
> from R, S
> where f(R.a) = g(S.b)
>
> Again, my apologies for using SQL notation rather than mathematical
> notation.
>
> Now we've got a join that the designer(s) of R and S might not have
> contemplated.

Indeed, one of the strengths of the relational approach is its ability to accomodate queries (and other things) that were not anticipated in the original design.

> The question is, is such a join "natural" or not? Down the
> road, I expect this discussion to have a lot to do with the usefulness of
> the relational data model in data intergration efforts, but I can't quite
> put it into words yet.
>
> I think the two examples where I used SQL notation would be clearer if they
> were in mathematical notation, but I'm too timid to try. Can anybody help?

Ohhh! Ohhh! Pick me!

& is used here for natural join.

Consider your functions f and g. Let us imagine a "bind" operation, that gives names to both the parameter and return value of the procedural
code f. Here is the syntax:

   y = f(x)

So that expression (the whole thing: "y = f(x)") is interpreted as

  { (x, y) | y = f(x) }

"The set of all x and y values where y is equal to f applied to x."

Using this notation, let us rewrite your example. Assume j is a name that does not appear as an attribute of either R nor S.

  (R & (j = f(a))) & (S & (j = g(b)))

This has a bunch of parens to avoid any ambiguities; we could also just write

  R & j=f(a) & S & j=g(b)

Once you have bind and a complete set of relational operators, you can do anything SQL can do. (This also raises the question of what makes a good set of relational operators, which is an enormous topic on its own.)

Darwen (and others) have an argument about the superiority of an algebraic relational language over one like SQL, which argument I find quite compelling.

Marshall Received on Fri Mar 02 2007 - 22:04:18 CET