Re: Discovering new relationships
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 03 Mar 2007 16:27:25 GMT
Message-ID: <NlhGh.4997$PV3.48800_at_ursa-nb00s0.nbnet.nb.ca>
>>On Mar 2, 12:01 pm, "Walt" <wami..._at_verizon.net> wrote:
>>>I think the two examples where I used SQL notation would be clearer if
>>>were in mathematical notation, but I'm too timid to try. Can anybody
>>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
Date: Sat, 03 Mar 2007 16:27:25 GMT
Message-ID: <NlhGh.4997$PV3.48800_at_ursa-nb00s0.nbnet.nb.ca>
Walt wrote:
> "Marshall" <marshall.spight_at_gmail.com> wrote in message > news:1172869458.132871.258340_at_h3g2000cwc.googlegroups.com... >
>>On Mar 2, 12:01 pm, "Walt" <wami..._at_verizon.net> wrote:
> >
>>>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
> > Thanks for the translation. Once I looked at it in mathematical notation, > it reminded me that a function is just a special case of a relation. From > there, I realized that I could have presented the example I gave without > having to use SQL "functions" at all. > > Let's say that we have two relations S(a) and R(b) with no "natural join" > between them. > All we need to do to relate the data is discover a relation T(a,b). Now > there's a natural join between S and T, and one between T and R. In the > abstract, such a relation always exists. > > The question, in data management terms is this: Is such a relation > "meaningful" in our universe of discourse? Stated in another way, is the > proposition that T represents one that says anything useful in the U of D? > This brings it back to data analysis. > > So I'm glad to have learned something, at the cost of having launched an > unnecessary discussion.
I would rank it in the top three or four discussions in the past month. Received on Sat Mar 03 2007 - 17:27:25 CET