Re: A different definition of MINUS, part 4

From: Bob Badour <>
Date: Sun, 28 Dec 2008 12:37:38 -0400
Message-ID: <4957ab58$0$5477$>

paul c wrote:

> Brian Selzer wrote:

>> "paul c" <> wrote in message 
>> news:Zma5l.8523$fc3.1985_at_newsfe02.iad...
>>> Parts one, two and three have various mis-steps and confusions.  Let me
>>> start again emphasizing what I think was McGoveran's paramount point -
>>> the desire for logical data independence.  I interpret the meaning of
>>> this in an algebra to be that substituting some non-logical aspect of an
>>> implementation for another will not require any logical aspects to be
>>> removed, ie., any true statements to be falsified.  Base and virtual
>>> relvars are non-logical aspects in that there is no notion of them in
>>> the algebra or calculus.  In Codd's logic, ie. his algebra and calculus,
>>> they are no different than colours, for example it does not matter in
>>> the D&D A-algebra whether a relation is 'red' or 'green'.  This does not
>>> mean that an implementation cannot be logical, only that if its results
>>> are to be validated logically, it must define all the concepts involved
>>> in those results in logical, eg., algebraic, terms.
>> Can you be more specific in what you mean by logical data 
>> independence? ...

> Beyond my interpretation (which you quote above!), I could say that I
> think I can say the algebraic significance is: Logical independence
> means that multiple algebraic expressions that are algebraically equal
> signify the same extension. I'm not sure that this is anything really
> different from saying that we want logical consistency to be
> demonstrable in a dbms implementation. Part of my point is that I
> suspect Date, as far as I've read, has not started by asking what
> logical consistency requires of a relvar assignment result. I'm
> guessing this is part of McGoveran's point too.
> I
>> understood it to be a property of equivalent database 
>> schemes--characterized with respect to the Relational Model by the 
>> ability to house exactly the same information using differing sets of 
>> relations.  ...

> One might presume that two schemes that are equivalent are in a way
> "independent" if two monkeys defined them (but they might not be
> equivalent for long). Logically (algebraically in my preference) if one
> wants them to be equivalent, one must use a formal logic to state that.
> This is not the same as some human viewer of the two db's merely
> understanding or stating that they are equivalent. The difference is in
> whether one wants the machine to make the guaranntee, in which case we
> humans must agree on a machine definition of equivalence.
> The concept is
>> orthogonal to whether relations are virtual or not.  ...

> Hardly. For starters, D&D don't talk of virtual relations. They
> distinguish relvars (variables) this way which is their means of
> deciding what variables need to change in an imperative language that
> implements their 'update' notion. Their 'assignment' goes hand in hand
> with that. From a pure (logical) model point of view, what is happening
> is they are permitting certain relations (values) to replace others,
> then implying that algebraic relation symbol names that are operands of
> some expression, say a join expression, can be substituted for relvar
> names. Effectively, they have involved our interpretation of algebraic
> symbols in the implementation notion of 'updating' (and vice versa)
> which removes any orthogonality one might have pre-conceived.
> If D&D had chosen to distinguish such relvars by calling them green
> instead of base, that involvement would still lurk for us to deal with.
> What is important is
>> that being able to transform the set of relations that conforms to one 
>> database scheme into the set of relations that conforms to another 
>> database scheme is a prerequisite for the schemes to be equivalent.  
>> What that means is that for a view to be uncontingently updatable, 
>> there has to be an equivalent database scheme in which the heading of 
>> a base relation matches the heading of the view.  For example, suppose 
>> you have two database schemes
>> scheme 1:

Scheme 1 is incomplete.

scheme 1:


>> scheme 2:
>> EMP2 {EMPID, SSAN} KEY{EMPID} such that
>> Here the circular inclusion dependency guarantees that any update 
>> through the EMPLOYEE view can be transformed into a legal set of 
>> updates against EMP1 and EMP2.
>> I don't see how anything short of schema equivalence could be 
>> permitted--for instance, relaxing the circular inclusion 
>> dependency--without changing the information content of the database.

> I don't argue with that (assuming '=' here means equal, not
> assignment). If this is meant to be a counter-example, I don't know
> what it is a counter-example of. 'Schema equivalence', depending on how
> it is defined, might be a result of what I'm arguing, but my purpose is
> making sure logical consistency prevails, so I don't (yet) need to talk
> about that. So far, I've not found it necessary to involve circular
> dependences, for example.

In scheme 1 above, we have our base relation declaration(s) and two view equations. In scheme 2 above, we have our base relation declaration(s) and two equations: one constraint equation and one view equation.

I agree logical independence demands we be able to use either scheme equally without having any concern for which sheme we actually have. Received on Sun Dec 28 2008 - 17:37:38 CET

Original text of this message