Re: <OR> predicate?

On Sep 29, 6:33 am, Erwin <e.sm..._at_myonline.be> wrote:
> On 28 sep, 18:52, Vadim Tropashko <vadim..._at_gmail.com> wrote:
>
> > I'm not sure I follow their idea that SUMMARIZE is expressed via AND,
> > OR, NOT, REMOVE, RENAME. Emailed to Hugh once, but didn't get a
> > responce
>
> > - Tekst uit oorspronkelijk bericht weergeven -
>
> Why not ?
>
> It has not been sufficiently demonstrated that SUMMARIZE can be
> expressed in terms of the 'classical' primitives JOIN,PROJECT,EXTEND ?

It depends what EXTEND is. I see that query like this

(EXTEND P [CITY]) ADD COUNT((MATCHING P)) WHERE COLOR = 'Red') AS N) WHERE N < 2) [CITY]

is definitely has expressiveness of SUMMARIZE

> It has not been sufficiently demonstrated that those 'classical'
> primitives can be expressed using the A operators ?

I fail to see this. Appendix A says:

"We are able to dispense with restrict (WHERE), EXTEND, and SUMMARIZE, since these operators all become further special cases of <AND> . Note: EXTEND and SUMMARIZE were not included in Codd's original algebra but were added subsequently [132]."

This argument is not convincing. Later on there is more detailed treatment:

"Dispensing with restrict (WHERE), EXTEND, and SUMMARIZE Restrict (WHERE), EXTEND, and SUMMARIZE all require certain operators to be invoked as part of their execution. In the case of restrict, the operators in question return values (truth values, to be precise) that are used to disqualify certain tuples from appearing in the result relation; in the case of EXTEND and SUMMARIZE, they return values that are used as the basis for defining certain attributes in the result relation. It occurred to us that it made sense, and could possibly be useful, to treat such operators as relations. Consider an operator Op that is in fact a scalar function (a scalar function is an operator for which every valid invocation returns exactly one result and that result is a scalar value). Suppose Op has n parameters. Then Op can be treated as a relation with n+1 attributes, one for each parameter and one for the result. The attributes corresponding to the parameters clearly form a key for this relation; however, that key is not necessarily the only one. For example, let PLUS be a relation with attributes X, Y, and Z, each of type INTEGER, corresponding to the scalar function "+" of integer arithmetic and to the predicate "X + Y = Z." Then each of {X,Y}, {Y,Z}, and {Z,X} is a key for relation PLUS; further, that relation contains exactly one 3-tuple <x,y,z> for every possible combination of values x, y, and z that satisfies the predicate (i.e., such that x + y = z).
Note, incidentally, that the relation PLUS can be regarded as an example of what in Chapters 5 and 6 we referred to as a "relcon" or relation constant: It is named, like a relvar, but unlike a relvar it has a value that does not change over time. analgous remarks apply to the relational representation of any function; the keys discussed in the previous paragraph are thus keys for a "relcon," not a relvar.
Let us take a closer look at what is going on here. A scalar function is a special case of a relation, of course, as the PLUS example illustrates. In fact, any relation can always be regarded as an operator that maps from some subset of its attributes to the rest; and, if the mapping in question is a functional (i.e., many- -one) mapping specifically, then the relation can be regarded as a function. In fact, since a set of n elements has 2ⁿsubsets, a relation of degree n can be regarded as representing 2ⁿdifferent operators, some of which will be functions and some not (in general). For example, PLUS can be regarded, among other things, as an operator that maps from Z to X and Y─ ─ but of course that particular mapping is not a functional one (the functional dependencies Z  X and Z  Y do not hold), and the corresponding operator is thus not a function.
We now claim that, given the fact that operators can be treated as relations, and given also the availability of the A operators  AND ,  REMOVE , and  RENAME(the latter two still to be discussed), it is indeed the case that we can dispense with restrict, EXTEND, and SUMMARIZE. We will justify this claim in the next section but one."

A bulk of discussion is devoted to introduction of PLUS predicate, but then, I fail to see how given the two relations EMP and PLUS one can express the query "give employee departement numbers wit salary totals" in relational algebra, and, therefore in A-algebra. Received on Wed Sep 29 2010 - 16:40:46 CEST