# Re: A different definition of MINUS, part 4

Date: Sun, 28 Dec 2008 05:56:11 -0800

Message-ID: <QyL5l.20175$mE3.12030_at_newsfe14.iad>

Brian Selzer wrote:

> "paul c" <toledobythesea_at_oohay.ac> 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. ...
*

The concept is

> orthogonal to whether relations are virtual or not. ...

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:
**>
**> EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID}
**>
**> scheme 2:
**>
**> EMP1 {EMPID, LAST, FIRST, MIDDLE} KEY{EMPID} and
**> EMP2 {EMPID, SSAN} KEY{EMPID} such that
**> EMP1[EMPID] = EMP2[EMPID]
**> EMPLOYEE = EMP1 JOIN EMP2
**>
**> 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.
**>
*