# Re: Relation subset operators

Date: Thu, 4 Jun 2009 13:59:30 -0700 (PDT)

Message-ID: <a59e326d-adba-42db-9b99-00802b24ea3b_at_l12g2000yqo.googlegroups.com>

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