Re: Guessing?
Date: Wed, 28 May 2008 13:19:31 GMT
Message-ID: <DZc%j.173589$Cj7.102316_at_pd7urf2no>
David BL wrote:
> On May 27, 4:46 am, paul c <toledoby..._at_ac.ooyah> wrote:
>> Brian Selzer wrote:
>>> "paul c" <toledoby..._at_ac.ooyah> wrote in message
>>> news:09p_j.294813$pM4.94170_at_pd7urf1no...
>> ...
>>>> It is becoming more and more apparent to me that the Assignment Principle
>>>> is a case of wanting to have your cake and eat it too.
>>> In my opinion the Assignment Principle is more important than being able to
>>> update views that shouldn't be updatable. If you issue an update, and are
>>> informed that it succeeded, then you should be able to expect that what you
>>> changed actually changed. For example, if I insert a row, and the insert
>>> succeeds, then when I re-read the row, I should be able to determine whether
>>> another user changed it by simply comparing the values I inserted to the
>>> ones read out: if they're different or nonexistent, then someone else
>>> changed or deleted it.
>>> ...
>> Sorry, slip of the keyboard, I didn't mean to mention the Assignment
>> Principle (which is okay by me) rather what I remember being called the
>> Principle of Interchangeability. The latter sounds wise, accepting and
>> maybe even politically correct in some circles but I do think it is
>> wishful thinking and suspect it is founded on quicksand.
>>
>> Regarding the Assignment Principle, I say that in this case it is not
>> violated, assuming we are talking about relational algebra that is closed.
> > Are you saying the Assignment Principle isn't violated assuming the > mutual exclusion integrity constraint causes the attempted update to > the virtual relvar to fail with an error? >
When Brian S says he expects to see the row he intended to insert in the result, I think he is expecting too much, at least too much from an algebra.
You have introduced an exclusion constraint, which wasn't part of my point, but for argument's sake, I'll go along with it. What I am saying is not very hard (otherwise I couldn't do it!) and one might say I am blindly distributing the operands but I say that is the advantage of an algebra:
say V(iew) = A <OR> B,
let A' stand for the result of the union of A and I,
let B' stand for the result of the union of B and I,
let I stand for the relation to be inserted and CA' stand for a relation
that constrains A' and CB' for a relation that constrains B',
then
V <OR> I = (A' <AND> CA') <OR> (B' <AND> CB')
Here, assuming the equation is well-formed, I am using a closed algebra, so there can be no 'error', only a relation result, also the <AND> of either constraint could result in an empty set. This might not give Brian S the rows he expects to see in V <OR> I but it is clear that the result of the union is equal to the value assigned to it, which is why I say the Assignment Principle isn't violated. (Same is true without the constraints. Also, I purposely wrote the above as an equation but you could add an assignment if you wanted to.)
I know some people say this choice of distributing the union is only one of three possible choices, and of which can be considered 'true' but it is my preferred choice and I don't see anything wrong with applying it in a dbms as long as it is consistently applied. In this case, any 'error' is also a matter of preference, but at the level of whatever programming language the dbms might support, not at the level of its algebra, strictly speaking, 'errors' are not part of a closed algebra's results. Received on Wed May 28 2008 - 15:19:31 CEST