Re: A different definition of MINUS, part 4

Bob Badour wrote:
paul c wrote:

Brian Selzer wrote:
....
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.
....

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.

My question would be why is there any mention of 'KEY' and why the constraint equation in scheme 2? How do they change the presumably desired 'equivalence' of being able to update either through EMP1 and EMP2 or through EMPLOYEE?

(unless there is some difference between the braces and square brackets that eludes me).

I don't say there is anything 'wrong' here that results from including keys, I would like to know why that is presumably necessary. If that is necessary, does it mean that some other key than EMPID, say {EMPID, SSAN} is somehow wrong or unnecessary?

.

Relevant Pages

  • Re: A different definition of MINUS, part 4
    ... there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. ... EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY ... we have our base relation declarationand two equations: one constraint equation and one view equation. ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, part 4
    ... there has to be an equivalent database scheme in which the heading of a base relation matches the heading of the view. ... EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} KEY ... we have our base relation declarationand two equations: one constraint equation and one view equation. ...
    (comp.databases.theory)