paul c wrote:

Projection is one quantifier. Equality (or containment) comparison is
the other.

On 5 nov, 20:09, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

The concept that a relational *operation* (projection) involving a
relation R1 would also serve as a quantifier for the same relation is
a concept I am having difficulties with.

I'd rather have quantifiers defined according to a domain subtyping
(knowing that each un-ary relation attribute is nothing else a domain
subtype associated with both a header and additional relation level
constraints). I found that such approach is more practical to
establish quantifiers through the use of domain intervals in
relationship to cardinality through combinatory analysis.

On Nov 5, 10:54 am, Cimode <cim... (AT) hotmail (DOT) com> wrote:
Please read Bob's recent postings and especially my posting of Oct 28
http://groups.google.ca/group/comp.d...c4b80087f296a2

A query evaluates the extension of (ie tuples that satisfy)
a predicate expression (the one corresponding to the query
relation expression) built from external (ie base relation variable)
predicates.
An internal predicate is just a necessary but not necessarily
sufficient constraint on the tuples that can appear in a variable
(evaluated to avoid (some) erroneous inputs).
It has nothing to do with querying.
(I don't even find the notion of internal predicates helpful.
It's the overall database constraint that's important.)

On Nov 5, 3:08 pm, Cimode <cim... (AT) hotmail (DOT) com> wrote:
Use of a relation operation in a relation expression corresponds
to use of a connective or quantifier in the corresponding predicate
expression.
Read my referenced message.
Try an example.
It's all so straightforward.

philip

On 6 nov, 01:19, com... (AT) hotmail (DOT) com wrote:
I thank you for your response and the effort you have put into
detailing what is an internal predicate or what is an external
predicate is to the the relational model but I believe you are
entirely missing the point I have raised to paul c. See my comments
below




relational algebric definition since it was prior to relational model
definition.

traditional algebra, valid quantifiers are values not operations. I
do not see why ra should have the privilege to define its own rules on
that perspective.

valid quantifier. There are other functions or intervals quantifiers
that can increase the expressive power of algebra but they do require
digging into domain analysis and combinatory analysis.

I do not see for instance how can such premice allow to develop a
computing model for effectively representing data independence in the
context of relation manipulation and operation.
I tend to think from current and past research that such premice leads
to confusion and limits the expressive ability and opportunity to
logically represent relational operations as a part of a turing
complete machine.

But of course that is just my opinion.
Regards...

On Nov 6, 10:54*am, Cimode <cim... (AT) hotmail (DOT) com> wrote:
I don't think there is universally agreed concept of quantifier for
algebra. Carrying over quantifiers from logic, one may suggest that
summation (http://en.wikipedia.org/wiki/Summation), product, infimum,
and supremum are quantifiers (they are essentially generalizations of
binary operations: addition, multiplication, meet, and join,
correspondingly). It is common in algebra to represent qunatified
operation in terms of binary ones; example:

1 + 2 + 3 + 4 + ... + n = n/(1-n)

Likewise, relational calculus quantified expression

exists y : R(x,y)

is essentially a disjunction

R(x,1) <OR> R(x,2) <OR> R(x,3) <OR> ...

(assuming positive integers domain {1,2,3,...} for y). This repeated
application of binary operation evaluates to binary operation: set
intersection join:

D(y) set_intersect R(x,y)

where D(y) is domain of y (which we assumed earlier to be
{1,2,3,...}). The last expression evaluates to projection which is
well known fact, but misses the big idea that universal and
existential quantifiers are dual quantifiers. Logical quantifiers in
algebraic form are set joins (which in some cases evaluate to
projection and relational division).

*function* instead of values. But there is a *significant* difference
between functions and operations since the first can be used as a
variable while the other not: an operation is an operation and a
variable is a variable. I do not see the clarity is an algebra that
uses a similar tool both for operating and quantifying variables.
And that applies to Summation as well. If we'd view Summation as an
algebric expression it is easy to dispute the fact that the variable
sigma is *not* the operation.

algebra.

effective quantifiers than set joins (while keeping set joins as
operations).

Since combinatory analysis allows to establish that it is impossible
to build a Turing complete machine using such toolset, I particularily
doubt the soundness of goiing such path in the current state of
relational theory need for clarification. These are the kind of
conclusions one reaches when trying to build a computing model for RM.

Regards...

<<I do not see the clarity is an algebra that
uses a similar tool both for operating and quantifying variables. >>
Sorry I meant "I do not see the clarity in an algebra that
uses a similar tool both for operating and quantifying variables. "

Tegiri Nenashi wrote:
....
In the spirit of the recent precision, it doesn't look to me like
'R(x,1)' et cetera are sets of tuples, which I believe '<OR>' requires.
Shouldn't that '<OR>' be logical 'OR'? Also the result doesn't look
'truth-valued', shouldn't it?

On Nov 6, 10:54 am, Cimode <cim... (AT) hotmail (DOT) com> wrote:

I'm not sure if I can help you if my last post didn't.

Appreciate that.

I don't understand this sentence.
There aren't any quantifiers in the relational algebra.
The quantifiers are in the corresponding predicate expression.
(If you use relational domain or tuple calculus then the calculus
expression looks just like the predicate expression.)
That's why I wrote the quote that follows.

Well I'm sorry, but that's the whole point of the relational algebra.

Following my referenced message, an example.
relation R{X} with predicate PR "blah blah...X..."
relation S{X, Y} iwth predicate PS "foo bah..X...Y..."
Consider relation query expression
RE=((R JOIN S) PROJECT X) UNION RELATION{Y 5}.
As a query this has associated predicate expression
PE=(EXISTS X (PR AND PS)) OR Y=5
Evaluation of RE gives the set of tuples that make PE true,
ie relation RE has predicate PE.
As a constraint you can think of PE as a statement
that must be equivalent to TRUE given the world as
described by the user's new variable values.
So if the corresponding relation result is not
RELATION{}{TUPLE{}}
(corresponding to predicate expression TRUE)
then PE is not equivalent to TRUE and the update is rejected.
(This characterization of constraints involves external predicates,
pace my last post.)

I don't understand this.
Maybe you mean quantifier in the sense of
SUM(relation, expression) or or COUNT(relation)
(or that matter (relation WHERE expression)).
These actually involve relational calculus
(pace Date and Darwen).
(But special case EXISTS(relation, attribute) corresponds
to PROJECT OUT in the relational algebra.)
As explained in Tegiri's reply to your post this requires
some extension to the predicate
(and hence domain and tuple) calculus.
To use this notation we don't need to extend the
relational algebra because you can define the meaning
of such quantifier expressions in terms of iterated standard
expressions.
No one is saying the relational algebra can handle this.
But no one is saying you
have to limit yourself to the relational algebra, either.
It's just some math that can do some stuff.
Like predicate calculus or series notations.

I don't understand this.
Maybe you mean generic quantifiers as addressed above.

I don't understand.
We can define an algebra, ie a collection of values and
operators on them, to act any way we want.
Anyway, the quantifiers are not in the relational algebra,
they are in the corresponding predicate expression.

I don't understand this.

I don't know what domain constraint analysis is,
please give a reference.
I suppose you mean domain in the sense of problem domain,
ie the world modelled by the database.
The relational model has nothing to say
about how you establish your predicates.
It's just a way to automatically with a certain complexity
calculate the tuples satisfying a predicate expression
given the tuples satisfying some given predicates.
No one's saying that's all the functionality we'd ever want.

I don't understand this.
Having data independence means that changing
the structure but not meaning of data should be easy.
If you express yourself structurally relationally
then new (relational) structure can be described
simply by relational expressions.

The relational algebra was specifically designed so that
1. you could use predicate calculus as a
(non-imperative) programming language and
2. it has a certain reasonable evaluation complexity.
Ie it was designed to have limited expressive ability.
(That's why there are no exact equivalents to NOT and OR
in a relational dbms.)
No one is saying it should do any more.
(To use relational algebra as a non-evaluated notation,
or if your system checks that your queries are "safe",
you can introduce those equivalents.)

If you allow recursion then you leave this complexity.
But people seem to be happy to still consider the dbms relational.
If you allow a certain higher evaluation complexity (resolution)
and a certain restricted notation (Horn clauses)
you get logic programming.
For higher complexity yet you get constraint programming.
Nevertheless relational algebra is still useful for giving
non-imperative semantics for these other systems.

So I guess a lot of your intuitions are right,
but I'd say you don't understand the basic
properties and limitations of the relational model.
(Also, I don't understand most of your post in detail.)

philip

On Nov 6, 5:08*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
'R(x,1)' is a result of substituting y=1 into R(x,y). This is
literally the same trick as substituting n=1 in the term x^(-n) which
is a part of summation

sigma( n={1...inf} , x^(-n) )

We simply substituted sigma with "exists", bind variable n with y, and
left x as free variable in both cases. Moreover, many math books use
the big disjunction symbol "\/" for "exists" in order to emphasize the
idea that existential quantification is merely repeated application of
binary disjunction.