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

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? Received on Sun Dec 28 2008 - 18:30:53 CET