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 >> 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:
>>
>> EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY{EMPID}
Scheme 1 is incomplete.
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
> 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.