Re: Relation subset operators

On 4 juin, 22:03, Tegiri Nenashi <TegiriNena..._at_gmail.com> wrote:
> On Jun 4, 2:09 am, cim..._at_hotmail.com wrote:
>
> > <<In a way this is a dual requirement to having two argument of the
> > same type! >>
> > I do not recall reading this but I have hard time understanding the
> > need for such limitation.  What prevents performing an agrregate or
> > set operation between a relation type and a relation subtype (the
> > subtype using the type as a domain of possible values) ?.
>
> Why do you bring in relation subtype (and what is it, actually)?
A relation R1 de facto contitutes a type. A relation R2 using R1 as a domain of possible values (each relation value being a possible value for R2) and before applying R2 specific constraints makes R2 a subtype of R1. One could view a subtype as a declaratively constrained subset of tuples or alternatively as specialized subset of tuples. Since all tuples in R2 necessarily belong to R2, performing aggregation between R1 and R2 does make sense. For instance consider INT as a relation whose body includes all integers and ODD_NUMBERS as a relation that derives from INT. Nothing prevents to my knowledge performing set operations between INT and ODD_NUMBERS even though they are not strictly speaking of the same type.

> To clarify my original statement, TClose is applied to a relation with
> two arguments x and y such that equality is a meaningful operation on
> x and y values. For example, for a relation Flight(from,to), one has
> to be able to do equality comparison of the attribute "from" with
> "to". An obvious generalization would extend this definition onto
> relations having the two sets of "matching" arguments.
No offense, but even though I do not disagree with that argument, I only see its relevance under the premise that TCLOSE would be the same operator than the one proposed (/=, />, /<, /<>) which have been developped for practical purposes. I do believe that paul only noted similarities which does not force it to share the same definition. Or maybe I missed something.

> An aggregate operation is different: as it is applied to two relations
> having the same attribute. For example, aggregating Emp(deptno, ename,
> sal) over Dept(deptno, dname) would produce a relation Budget
> (deptno,expense). Therefore, I fail to see the similarity that Paul
> mentioned.
If I understand right, you are bothered by paul comparison of the operator to TCLOSE. I let paul clarify further why he sees a similarity. As far as I am concerned, I was simply hoping to get some feedback on the *usefulness* of such operator into simplifying groupped queries as well as specialization by constraint formulation.

Regards... Received on Thu Jun 04 2009 - 22:59:30 CEST