Re: A different definition of MINUS, part 4

paul c wrote:

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

I assumed the square brackets are project and the braces are set notation for the set of attributes in each tuple. Obviously, the notation is ill-defined and incomplete so one has to make all sorts of suppositions to pretend to see anything meaningful in the example. See Date's _Principle of Incoherence_.

The key constraints are just additional constraints. If something else were used as the key, one would have different example schemas.

The constraint equation in scheme 2 is a necessary constraint for equivalence between the two schemas. Without that constraint, the two schemas are logically different schemas. And: "Logical differences are ___ differences." Come on, everyone! Join in!

Are you familiar with Fabian's observations regarding 'denormalization for performance' ? He observes that such 'denormalized' schemas are slower if one actually declares the constraints; thereby suggesting any performance difference comes at the cost of integrity.

By the same token, without the constraint equation in scheme 2, the two schemas are logically different, and I doubt anyone is silly enough to suggest logical data independence requires logically different things to be the same in any way. Received on Sun Dec 28 2008 - 19:19:24 CET