# Re: A different definition of MINUS, part 4

Date: Sun, 28 Dec 2008 12:37:38 -0400
Message-ID: <4957ab58\$0\$5477\$9a566e8b_at_news.aliant.net>

```>> "paul c" <toledobythesea_at_oohay.ac> wrote in message
>>
>>> 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:
>>
>> EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID}

```

scheme 1:

```EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY {EMPID}
EMP1 = EMPLOYEE[EMPID, LAST, FIRST, MIDDLE]
EMP2 = EMPLOYEE[EMPID, SSAN]

>> 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.
```

>
> 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