Re: a union is always a join!


"Brian Selzer" <brian@xxxxxxxxxxxxxxxxxxx> wrote in message
news:_zBql.17414$YU2.17201@xxxxxxxxxxxxxxxxxxxxxxx

"paul c" <toledobythesea@xxxxxxxx> wrote in message
news:Evlql.14337$Db2.10147@xxxxxxxxxxx
rpost wrote:
...
As I already said in my previous message, I see the elegance,
but at the same time I find elegance in Codd's use of two kinds
of operations. Obviously if you rewrite to Codd's algebra (or do
something equivalent to that) you're not going to lose efficiency
on the cases where this is possible. But just rejecting the rest
is only going to confuse the user. Why not be honest and admit
that we really expect, in our implementations, relational queries
to work on finite, typically small relations, that WORKS_IN is one
and PLUS is not, and that NOT doesn't do so?
...

In the interest of keeping the pot stirred, here are some other
provocations (basically one of my same old tired recurring themes) .


As Fabian P and others have pointed out, a table (or should that be
R-table?) that involves nulls obviously involves more than one of Codd's
original relations. Given a smart enough implementation a relation that
is defined using <OR> could be replaced by two or more relations (I seem
to remember McGoveran stating similar somewhere or other. I'm guessing
that Codd wouldn't have agreed but my hunch is that his objection would
have been on practical, not theoretical grounds, so perhaps he would not
have objected if somebody had made a practical implementation). As long
as the closed-world-assumption is followed, a relation that is produced
using the <NOT> operator doesn't generally need to be materialized
because queries against it can be transformed as queries against its own
negation. I'd say the importance of <NOT> has nothing to do with
finiteness, rather that it parallels boolean algebra's NOT and thus
allows a algebra to define retraction, aka 'deletion'.


<OR> is more interesting (to me) than <NOT>. Without <OR>, RT has no way
to 'add' a tuple to a relation variable. When one uses a language's
"INSERT" verb, it must effect the logical equivalent of <OR>.

Paul,

I think you're on the right track if you can just separate what <OR> is
from what is an application of <OR>. Of course, this particular
application of <OR> is not limited to just INSERT, but also UPDATE and
DELETE.

Relational Calculus, and therefore equivalent mechanisms such as Codd's or
D&D's algebras, is closely related to if not based upon first order
predicate logic. But while first order logic is fine for querying the
picture of the world that is represented by a given database value, it is
not sufficient for either the series of pictures represented by a
succession of database values, or the series of events that describe not
just what is changing between pairs of successive pictures, but exactly
how what is changing is different.

This is the way I see it: That which states what is the case is the
disjunction of all and only true propositions. Divide that into two
parts: one that states what has been the case (not necessarily what had
been the case--just that which obtained since the last change), and one
that states what is happening. Whenever nothing is happening, what has
been the case /is/ the case. For example, if Joe has been second in line
at the bank and nothing is happening, then Joe is still second in line.
On the other hand, if the person who has been first in line is now being
served, then Joe is no longer second in line but is instead first in line.
The disjunction of the two statements: "Joe has been second in line" and
"Joe is no longer second in line but is instead first in line" yields "Joe
is first in line." In symbols,

from p \/ (~p \/ q), derive (p \/ ~p) \/ q
since (p \/ ~p) is vacuously true, eliminate it and what is left is just q

Technically, (p \/ ~p) is not /vacuously/ true, it just conveys no
information. Still, such expressions must not appear as disjuncts in the
statement of what is the case.


Now let's apply that to relational theory: the database states what has
been the case; a transition states what is happening. The logical sum of
these two statements asserts what is the case, and is therefore what is
becoming the database: though there may be many databases that could be
the database, only one of them can actually be the database at a time.

So the application of <OR> to combine the statement of what has been the
case with the statement of what is happening is a fair description of a
database update, but it is not limited to just "INSERT." The disjunction,
p \/ ~p, when it appears in the logical sum of what has been the case and
what is happening can be thought of as the equivalent of a "DELETE," and
the disjunction, (p /\ q) \/ (p /\ ~q) \/ (p /\ r), the equivalent of an
"UPDATE;" only the disjunction, False \/ p, would be the equivalent of an
"INSERT."

Codd's unadorned relation is a conjunction of simple propositions (by
simple I mean each proposition contains no logical connectors). If a
relation variable has the 'quality' of being a 'view' (or 'green' as I
like to joke), some people say to the effect that the view is a
conjunction of disjunctions (propositions involving the logical connector
'OR'). Whereas if the relation variable is 'base', they say it is just a
conjunction of simple propositions. For years, I've been trying to
understand how they can say this at the same time as they say that users
should preferably see no difference between base and virtual/view
relation variables (which I agree with, just as I would agree that there
should be no appreciable difference between 'red' and 'green' relvars.
Their argument then proceeds to claim that 'inserts' to some union views
are indeterminate while 'inserts' to an equal 'base' view aren't. I'd say
that if they are right, then we shouldn't be able to 'insert' to any
variable unless it points to an empty relation which would mean that no
relation could have more than one tuple - that bizarre situation would
have exactly one advantage - no questions about finiteness!




.

Relevant Pages

  • Re: a union is always a join!
    ... of database values, or the series of events that describe not just what is ... disjunction of all and only true propositions. ... then Joe is still second in line. ... The logical sum of these ...
    (comp.databases.theory)
  • Re: Considering using Access
    ... Joe Fallon ... sounds like database you're proposing will be "mission-critical". ... > seems to be alot of work, but alot of work in not my problem... ... I am thinking each customer will be assigned a number, ...
    (microsoft.public.access.tablesdbdesign)
  • RE: Events to "Trap" Incomplete Record Creation?
    ... validation checks and issue a message if anything is missing. ... Joe CluelessUser is adding a new record to a database through a form. ... because of the missing required data. ...
    (microsoft.public.access.formscoding)
  • Re: a union is always a join!
    ... if Joe has been second ... transaction, except for the actions of that transaction. ... database as if "nothing is happening". ... or because Joe just put on a blue hat. ...
    (comp.databases.theory)
  • Re: Help with WildCards
    ... "Joe" wrote in message ... I have an enormous database to convert ... >> To get info on Access database wildcard characters just type 'wildcard' ...
    (microsoft.public.vb.database.ado)