Some months ago Bob B took me to task for language that might have been
too loose or even glib, referring to predicates and expressions. That
was fair enough. Though I could've made it clearer that by expressions
I meant relational algebra expressions, I still don't have clear answers
to all of his complaint.


One reason is that I still don't know how Codd's Information Principle
applies to compound propositions, eg., " 'C1' is a customer OR 'C1' is a
client". I can see that humans might imagine themselves capable of
interpreting a relation (or to put it redundantly a relation value) as
implitly mentioning that 'OR' connective (and dba's might so instruct
their users). But where is it recorded? (or 'manifested'?) Eg., is it
'recorded' only in the ephemeral form of an expectation that a program's
execution can't manifest given a single relation to operate on?


As far as I can tell, there is no way to record a logical connective in
a tuple, therefore not for a tuple and therefore not in a relational
value (other than in a disconnected text mode thath isn't amenable to
the algebra) which has always made me suspect that Codd's R-tables don't
store compound propositions. If so, that would be one difference
between internal and external predicates, which would make me suspect
that we can't always expect the same results when the same algebra is
applied to both.


(I realize that Codd and others - maybe Ullman, I forget - showed that
FOL and his relational algebra were equivalent, but I presume the
conditions of that were with reference to his R-tables and not that FOL
always gives the same results under all conditions.)

paul c wrote:

Where does one record any external predicate?


What is the predicate of Customer[id] join Client[id] where [] signifies
project? If the expression defined a view, what might you call it?

Bob Badour wrote:
....
If you mean what is the 'external' predicate, I can't say, not knowing
its purpose any more than a dbms designer can predict the exact purpose
some unknown db is used for, other than to say intersection and
quantification are involved. If you mean 'internal', that which an
algebra operates with, it is basically the expression 'Customer[id] join
Client[id]', standing for the intersection of the set of Customer id's
that match Client id's and vice-versa.

If the expression defined a view, what might you call it?
You might call it a predicate that's satisfied by certain compound
propositions. I think you might call it that even if it is 'satisfied'
by tuples of a 'base' 'relvar'. I don't see that an expression being a
view definition makes it stand for some different kind of predicate, if
that's what you're driving at. I didn't think that views needed to be
mentioned but since they were, views seem a programming convenience,
eg., a labour-saving device or a way to effect some security attitude or
a way to control physical storage, or a way to help an optimizer or even
all four at once, maybe other conveniences too that I can't think of
right now. Are they something more than that? Eg., do they have special
significance in relational algebra?

paul c wrote:
No, I meant the internal predicate but I screwed up in any case. I meant
to use union not join. Sadly, you removed all reference to the original
context.


Actually, for join it is "'id' is a customer and a client". For union,
it would be "'id' is a customer or a client".


The only difference is a view has a name. Otherwise, it is identical to
any other derived relation.

Unless, of course, one is looking at named relations in which case the
only difference is a view is derived. Otherwise, it is identical to any
other named relation.

Bob Badour wrote:
Thanks. The nuance I'm detecting here is that there is some useful
reason for phrasing an internal predicate in English rather than the
more formal algebra.

Am pondering the significance of the other comments.

paul c wrote:

No nuance at all. See Codd 1972: "Relational Completeness of Data Base
Sublanguages" on the equivalent expressiveness of set algebra and
predicate calculus.

You originally asked about a predicate expression using disjunction,
which is the same as a union.


Just remember: When you hear hooves, think horses.

Bob Badour wrote:

Wasn't trying to obscure any context, the predicate I started with was "
'C1' is a customer OR 'C1' is a client".

But are you saying there is a relevant difference between the recording
of a compound proposition that involves join and one with union? (given
that practical union values are so-called 'union-compatible')

I realize that it's unlikely both would be satisfied by the same value
but as far as whether either records the connective is concerned I can't
see any difference, sames goes for projection. (also realize, based on
people I've known, that some might consider my questions childish, but I
don't care! Maybe I've just been getting away with something for all
these years, thinking that relational closure means no compound
propositions.)

paul c wrote:

Which is equivalent to an instance of (Customer union Client)

On Tue, 16 Mar 2010 05:12:55 +1000, paul c <toledobythesea (AT) oohay (DOT) ac> wrote:
[...]
Hi Paul,

As far as I can tell:

'The algebra' is a method of querying a database for things that it does
or does not entail.

'The database' is a set of assertions (I'm considering only base
relations).



I think that your question is 'can we assert disjunctions in the database,
so that they can be operated on logically by the algebra?'

The answer is, I think, no. At least not while the CWA is present.

Cheers,
Joe

P.S. My understanding is that the equivalence between the algrbra and FOL
is about the proof-theory side of things, and that FOL has a strictly
richer expressiveness in terms of what the database (cf. theory) can
express.

On Mar 15, 9:12*pm, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:
I suspect you're assuming an entity point of view.

If Customer and Client are relations which represent the predicates in
your example, and the two are exclusive, then in theory one could
define referential constraints to exclude from each relation those
values which exist in the other. If you have a Person relation which
may only contain values which exist in either Customer or Client, then
that too could be defined as a referential constraint.