# Re: A different definition of MINUS, part 4

From: Bob Badour <bbadour_at_pei.sympatico.ca>

Date: Sun, 28 Dec 2008 12:37:38 -0400

Message-ID: <4957ab58$0$5477$9a566e8b_at_news.aliant.net>

> Beyond my interpretation (which you quote above!), I could say that I

> One might presume that two schemes that are equivalent are in a way

> Hardly. For starters, D&D don't talk of virtual relations. They

> I don't argue with that (assuming '=' here means equal, not

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}

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