On Sep 28, 12:34*pm, Cimode <cim... (AT) hotmail (DOT) com> wrote:
Having written many triggers and debugged many more, I can say that it
is a lot more complicated to implement transition constraints
procedurally. Morons will write triggers under the assumption that
updates affect only one row at a time, and since the application
they're writing doesn't issue updates that affect more than one row at
a time, they think everything is fine. Later on, someone else's app
issues a set based update and either the trigger bombs, or worse yet,
it fails to enforce the constraint it was supposed to implement.

On Sep 28, 2:17 pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
CPU loops happen:-) I just fixed one this morning. To build up some
confidence I suggest to start with queries, not assertions. For
example, evaluate simple things like

[r s] a 1 b 1 <AND> [s t] 1 1 2 2;

Whenever QBQL checks an assertion, it iterates through all free
relvals in the assertion statement. Consider, for example, join
commutativity

x <AND> y = y <AND> x.

It has two variables x and y, which are assigned all the relations
defined in the database file. Specifically, Figure1.db starts with

A=[p]
1
;
B=[p]
1
2
;
C=[q]
a
;
D=[q]
a
b
;
....

Therefore, it would try x=A, y=A, check the assertion, then try x=A,
y=B, then x=A, y=C, and so on. For two variables it iterates nested
loops two level deep. If we want to check associativity, then there
would be three free variables, and the iteration would be three level
deep; more formally O(n^3) where n is the number of relations in the
database (~20 for Figure1.db). Now you can see why evaluating
assertion takes more time than a query.

The bug was misidentification of free variables so that QBQL thought
that NOT,AND,OR were variables as well. It iterated nested loops 5
levels deep.

On 28 sep, 18:52, Vadim Tropashko <vadim... (AT) gmail (DOT) com> wrote:

Why not ?

It has not been sufficiently demonstrated that SUMMARIZE can be
expressed in terms of the 'classical' primitives JOIN,PROJECT,EXTEND ?

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

On Sep 29, 6:33Â*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
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

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-
to-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 coursethat
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.

On 29/09/2010 7:40 AM, Vadim Tropashko wrote:
Just a side comment, not to detract from the more important question
about summarize: it could be that I have a mental block about this but
regarding restrict, it's defined on the <AND> and <NOT> operators which
return relations, not truth values per se. The symbol for set
membership is used in the definitions of those ops which I'd say gives a
truth value but I don't think it's right to let the terms in the
definitions percolate to the result of the operators being defined (if
that's what D&D mean here). (and assuming that the 'operators' talked
about are just the A-algebra ops, the ones that are 'executed' by a
machine, if only a theoretical one.)

On 29 sep, 16:40, Vadim Tropashko <vadim... (AT) gmail (DOT) com> wrote:
I think PLUS is of no use to you in this situation.

The function/relation you need to come to the aggregate results is a
function that maps a relation {1 2 3} (deliberately using sloppy
shorthand here) onto, e.g. if the aggregation operation is addition,
the number 6. The relation that represents the invoked aggregate
operator (SUM, COUNT, ...) in question, that is.

Or is that not the problem ?

On Sep 29, 10:22*am, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
Oh, that route I've explored at sufficient depth:
http://vadimtropashko.wordpress.com/...and-set-joins/