Re: A different definition of MINUS, part 4
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Wed, 31 Dec 2008 17:09:01 -0400
Message-ID: <495bdf70$0$5503$9a566e8b_at_news.aliant.net>
>> 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.
>>>
>>>
>>> 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?
>>
>>
>> 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.
Date: Wed, 31 Dec 2008 17:09:01 -0400
Message-ID: <495bdf70$0$5503$9a566e8b_at_news.aliant.net>
paul c wrote:
> Bob Badour wrote: >
>> 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.
>>>
>>>
>>> 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?
>>
>>
>> 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.
>
>
> Okay, let's take a step back. Start with EMPLOYEE {EMPID, LAST, FIRST,
> MIDDLE, SSAN}. Tell the dbms it's 'base' (or 'green' for all I care,
> ha, ha). Right off the bat, we know that:
>
> EMPLOYEE {EMPID} = EMPLOYEE {EMPID, LAST, FIRST, MIDDLE, SSAN} JOIN
> EMPLOYEE {EMPID}
>
> We don't need to assert this, the algebraic rules imply it. It is about
> as fundamental a constraint as they come. The dbms should obey it.
> We don't need keys to make this point: now tell the dbms that the
> projection, EMPLOYEE {EMPID}, is 'base'. Give a prize to the dbms
> designer whose product doesn't discard the constraint when it hasn't
> been 'told' to.
I'd give a prize to any product that distinguishes base versus stored. Received on Wed Dec 31 2008 - 22:09:01 CET