Re: storing survey answers of different data types

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:EaIIl.24231$Db2.13194_at_edtnps83...
> Brian Selzer wrote:
> ...
>> It doesn't mean that Codd's model is broken: it means that your
>> interpretation of Date's Principle of Interchangability is just plain
>> wrong. The distinctions between base and derived relvars that limit the
>> kinds of updates that are permissible are neither arbitrary nor
>> unnecessary. An insert into a relvar that is the union of two base
>> relvars is inherently ambiguous, since it implies an insert into at least
>> one but possibly both of the base relvars. Disambiguation is possible,
>> but only through the use of multiple assignment--in fact, Date's
>> Assignment Principle demands the use of multiple assignment. In the same
>> way a delete from a relvar that is the join of two base relvars is
>> inherently ambiguous, since it implies a delete from at least one but
>> possibly both of the base relvars. Again, disambiguation is possible,
>> but only through the use of multiple assignment.
>>
>
> In the face of the actual situation, that is all just chatter. Quoting
> Date from a few years ago at:
> http://www.dbdebunk.com/page/page/1396086.htm
>
> (quote)
> In other words, the operation
> DELETE SSP WHERE S# = S#('S1') AND P# = P#('P1') ;
> is inherently unsafe, since we presumably don't know, in general, whether
> there are any other shipments for supplier S1.
> (end quote)
>
>
> In the exchange, Date said the Delete operation fails, so I presume SSP
> remains unchanged. Instead of that delete statement, imagine this:
>
>
> Select SSP where S# Not Equal S#('S1') OR P# Not Equal P#('P1') ;
>
>
> I presume the Select operation doesn't fail under Date's principles. So a
> user could select a relation that the dbms refuses to record. If the
> Delete is 'unsafe', so is the Select. So sometimes the relation's tuples
> are true and sometimes the same relation's tuples aren't true.. Looks
> broken to me.

I disagree: in this case the Delete is unsafe because it might violate a referential constraint (the one-to-many constraint Date refer's to); there is no danger of any Select violating a constraint.

I would also suggest that you apply simple logic: the Select extracts information from what has already been asserted to be the case, but the Delete asserts what is the case, superseding what had already been asserted to be the case.

Under the Closed World Assumption, every tuple that appears in a relvar maps to a positive assertion. The presence of a tuple that under an interpretation does not map to a positive assertion denies the validity of the entire relation, but since the state of affairs that is represented by the result of the Delete is different than the state of affairs that is represented by the source of the Select, it is possible for both relations to be valid /but only at different times/. It is not an indication of being broken for the contents of a relvar to be different at different times. Received on Sun Apr 26 2009 - 05:00:34 CEST