Re: Functions and Relations
Date: Tue, 21 Nov 2006 01:33:31 +0100 (CET)
Message-ID: <Xns9881C6F735595asdgba_at_194.177.96.26>
"Aloha Kakuikanu" <aloha.kakuikanu_at_yahoo.com> wrote in
news:1164051960.913651.234880_at_m73g2000cwd.googlegroups.com:
>> "Aloha Kakuikanu" <aloha.kakuikanu_at_yahoo.com> wrote in
>> news:1163794792.364269.246040_at_m7g2000cwm.googlegroups.com:
>> > 1. Function invocation is a join:
>> >
>> > f(x) /\ x=1
>> >
>> > 2. Function composition is a join:
>> >
>> > g(f(x)) <==> g(z,y) /\ f(y,x)
>>
>> I am not in agreement: the function composition takes two binary
>> relations and gives one binary relation, it does not the arity. g o
>> f = Z <-g- Y <- f- X loses the information about Y. The natural
>> join increases the arity and onserves Y.
>
> Yes, in both cases it is a join, followed by projection. Also, not
> that if you have 2 functions
>
> f: x->y
> g: x->y
>
> which are represented as relations F and G, then you have to do
> renaming before joining:
>
> g o f:
>
> ({[(F /\ `y=z`) \/ `xz`] /\ `x=y` \/ `yz`} /\ G) \/ `xz`
>
> Therefore, the correct thesis would be that function composition can
> be represented via basic relational operators; they are not exactly
> the same. This also explains why composition is not commutative,
The composition of functions, it can be made commutative if one defines the function (domain, codomain) pairs, in a strange fashion, like the database relation tuples: (attribute, value). Then one can commute and compose on the common attribute.
>while
> join is commutative. But then, both composition and join are
> associative. Is it merely a coincidence?
There are relation compositions that are not associative:
3 -2 - 1: let const3 = 3; m2:x ->x-2; m1:x->x-1;
'const3 o m2 o m1' is not associative.
>
>> It is interesting like a theory but please show with an example when >> the function-like-relation is more practical. Is it that you want to >> utilize the function with the relational algebra operators ?
>
> SQL optimization. Consider
>
> select sal+100 from emp
>
> what exactly is "sal+100" and how to show it on the explain plan?
What is the problem ? I think but I can be wrong that the SQL Server shows the function call in the execution plan. If it does not, it must not be very complex to implement.
> If
> it is merely an expression, then what about corellated scalar
> subquery:
>
> select (select dname from dept d where d.deptno=e.deptno)
> from emp e
>
> How does one show scalar subquery on the expalin plan?
Why it can not be shown like a nested loop: 'for each row-> select ....'
>How about
> functon call
>
> select raise(sal) from emp
I think it is more efficient to compute a function in comparaison of insert a formula in the tuple and then interpret the partially evaluated formula: it is how you are going to implement a function join in theory, no ?
>
>
Received on Tue Nov 21 2006 - 01:33:31 CET