Bob Badour wrote:
Best I can do at the moment without a clue or two. If Bob B doesn't get
any part of it either there is little point embellishing or possibly I
have lapsed into mysticism, will reserve judgment for now. Oh well,
that's life.

paul c wrote:

I suspect you simply do not include enough context to decipher what you
are saying. If I have a relation variable, R, at any given time, its
extension is simply its value. Is it not? Since R can have different
values at different times, it can have more than one extension; albeit,
only one at a time.

Bob Badour wrote:
....
Thanks, I'll ponder that. The only comments I want to make right now
are i) that I prefer to avoid talking about relvars until some choice of
language is made, which choice seems premature, eg., I can imagine an
environment where the programmer's context doesn't include assignment,
and ii) I think expressions have a value and extensions have a value
(maybe you are more pertinent saying that they are values, not sure) and
those two values are equivalent in Codd's RM context - my attitude about
equality as far as machines are concerned is that it should be
determined only by typical machine-level comparison instructions which I
hope keeps various language notions of equality out of the picture as
far as interpreting values is concerned. This is perhaps narrower or
stricter than most people want, maybe it's an unnecessary distinction
too but I'd rather be careful about it.

paul c wrote:

In logic, a relation is the extension of a predicate, and a predicate is
the characteristic function of a relation. When talking about relational
databases, sometimes one has to be clear about the internal predicate
and the external predicate. At any given time, one will generally find
fewer tuples in any relation variable than the internal predicate would
allow because some parts of the predicate are not amenable to
calculating or to expressing algebraically.

If one has a relational expression, one may derive or calculate a
predicate for that expression, but it will always be the internal
predicate ignoring the external predicate. The dbms has no data about
the external predicate other than the actual tuples in relations. As far
as the dbms is concerned, the value of the relation itself is the
extension of the external predicate.

When you write about extensions of expressions, the phrase is
meaningless. Expressions do not have extensions--predicates do. If you
mean the extension of an expression's predicate, do you mean the
internal predicate? The external predicate? If you mean something else,
please define your terms.

Bob Badour wrote:
....
Do you mean certain negations and disjunctions aren't amenable, such as
the predicate "it is not the case that the temperature T in city C is T
degrees"?

(Thanks for the precision, still pondering the rest.)

paul c wrote:
No. First, you have T representing 2 different measures so I cannot
understand your example.

I mean the predicate for "Employee, EmpID, manages department, DeptNo"
is too complex to calculate or to represent algebraically. It has all
sorts of complex factors that generally never get recorded anywhere such
as someone had to apply for a job with the company and that person had
to perform well enough to get promoted to management (not necessarily at
this company) etc.

What one can calculate or represent algebraically is much simpler:
DeptNo refers to some Department in the database. EmpID refers to some
Employee in the database. The referenced Employee--as described in the
database--has to meet certain criteria like having a base salary and
exempt status. If the data does not meet those criteria, the dbms will
reject it.

In general, the database describes part of the predicate, called the
internal predicate. The actual predicate (external predicate) has
additional factors not described in the database except for the
extension of the predicate itself: the relation.

In other words, the database does not describe the full predicate from
which one could calculate a relation. How one goes from predicate to
extension is not fully recorded. What is recorded is the extension of
the predicate, as far as the dbms is concerned, and those parts of the
predicate amenable to calculation or to algebraic representation.

The extension is a relation. The internal predicate is the set of
constraints including data types, names, candidate keys, foreign keys
etc. The full predicate is the conjunction of the internal predicate and
some unknown or unrepresented factors.

When you derive a relation via some relational expression, the derived
relation is the extension of some predicate. If the dbms represented
entire predicates, it could calculate that predicate, but the dbms does
not represent entire predicates. The dbms represents internal
predicates, and it can derive an internal predicate for the expression.

The expression is an expression. The calculated value of the expression
is an extension of some predicate. The predicate or characteristic
function of that extension is partially unknown.

Bob Badour wrote:
And thank goodness for that!

On Nov 4, 4:41*am, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Personally I wouldn't talk about internal and external predicates. I'd
instead go with finite model theory terminology. There we have
theories, encoded in the RM as a finite set of explicit propositions
(the extension of the database) plus a bunch of first order predicate
logic which links together, constrains, and takes precedence to the
propositional extension (the so called intension of the database) in
case inconsistency in the encoded theory was about to arise somehow.
And second, we have real life models those theories try to capture.

In that framework it's easy to see that just about any realistic
database could have multiple real life models. And that including more
identifying features, being stricter with the semantic interpretation
of the theory wrt its models, and modelling constraints which are
actually valid because of physical, societal, etc. reasons within the
theory cause the theory to pick out fewer and fewer real life models.
Ideally, we'd like to make the theory strict enough to necessarily
pick out just one plausible model; that can actually happen when e.g.
every entity we handle has a natural key, and our constraints formally
encode that fact within our theory. This is essentially the reason why
natural keys hold such a prominent place in the theory of consistency
and normalization: they are perhaps the most important mechanism which
translates real world semantics into symbolically manipulable
constraints within our logical model, and so helps guarantee as close
to 1-1 correspondence between encoded propositions and real world
entities as possible.

At the same time, we can independently analyse the theory encapsulated
within the database as an entity separate from the real world models
it might have. This is then where normalization and like concepts come
in. They rely on the semantic correspondence encoded by e.g. natural
keys and the live facts which give rise to cardinality constraints,
inclusion dependencies, and whatnot. But once that source data is
formalized, the logical mechanism from there on in independent. That
then is mostly what we think about when we mention the Relational
Model.
--
Sampo

On 4 nov, 18:23, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

I would be glad to hear how we establish a valid quantifier in
relational algebra using only internal predicates. The lack of
clarification of the external predicate, while being symptomatic
limitation of traditional RM relational theorists gladly recognize,
does not bother them much when it comes to operate relations
algebrically using only the internal predicate. That's where domain
analysis becomes handy...

Regards...

Cimode wrote:
I thought projection is relational algebra's quantifier, are you talking
about something else?