Date: Mon, 26 May 2008 11:01:22 -0400
>> "paul c" <toledobysea_at_ac.ooyah> wrote in message >> news:xuk_j.165843$Cj7.9496_at_pd7urf2no... >>> Brian Selzer wrote: >>> ... >>>> Well, that's just it. It has no consistent method for doing so. ... >>> >>> It does, I gave one, ie., apply, ie., distribute algebraically, the >>> union to the base relations in the view expression, then apply whatever >>> constraints the definition has. Works just as consistently for deletes >>> to joins. >>> >> >> And then since the insert doesn't violate any constraints on the base >> relations, two rows would be inserted, one in each base relation, but >> these don't show up in the view because the view is a disjoint union. >> Now, if you were to allow the insert, wouldn't that violate the >> assignment principle? >> ... > > >
> Codd said: "The view S is actually the disjoint union..." but what the
> heck does he mean by "actually"? From the DBMS' point of view, he is
> lapsing into mysticism. As I said, it can't know this. All the dbms
> knows is that the two base names are different and it has been given no
> order to the effect that they must be disjoint. So, given what he wrote,
> the tuple(s) would show up in the view.
Isn't there a disjoint union operator? Codd didn't define one in his book, but there's one defined in TTM.
> For argument's sake, suppose the dbms is aware of a declared mutual
> constraint that makes the two base relations disjoint. In my elementary
> approach, that would have the effect of 'emptying' both base relations and
> nothing at all would show up in the view. Personally I have no problem
> with this but I recognize that people who prefer certain niceties over a
> consistent logic do. I say that they can satisfy their whims at the
> programming language level, eg., by supporting certain exceptions or by
> other techniques.
If a view is formed using a disjoint union operator, then there needn't be a constraint that makes the two relations disjoint. The rows that appear in both base relations simply wouldn't appear in the disjoint union.
> 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.
In the case of a union that is not disjoint, an insert would succeed and that insert wouldn't violate the Assignment Principle, but it still shouldn't be allowed because (assuming a union of only two relations) there would be at least three different possible database values that would yield the same resulting value for the view. The same result would be obtained by inserting a row into either underlying relation or into both. If you choose to 'apply,' as you suggested, then in Codd's example, instead of inserting just one supplier, you would be inserting two.
>>> If it just >>>> guesses at the intent, 50% of the time it will guess wrong, and you'll >>>> end up with garbage in the database. As a consequence, queries like, >>>> "How many suppliers are west of the Mississippi?" will return the wrong >>>> answer. >>>> ... >>> >>> My whole point is that the dbms has no business guessing, just following >>> orders. Why anybody would imagine a dumb pre-programmed logical machine >>> can know human intentions can only be pathological mysticism. As they >>> say, "don't believe everything you think". >>> >> >> I agree with you that the dbms has no business guessing, but if you order >> the dbms to do the impossible, you have to expect it to complain. >> ... > >
> I could have put what you quote better by saying that if the dbms follows
> a consistent logic, no question of guessing comes up.
> > >>>> But again, it should not allow the update if it has to guess, because >>>> inevitably, it will guess wrong at least some of the time and the >>>> database will end up corrupt. That it has to guess is not a guess. >>>> ... >>> >>> It is mysticism to think that a dbms that follows its own consistent >>> rules is somehow guessing. >> >> Well, that's just the point I was trying to make. If you're not specific >> enough, you're asking the dbms to pick one of many possible courses of >> action. While the dbms should be able to determine whether a course of >> action is possible, it should not be asked to choose between possible >> courses of action, and it should complain equally as loud since neither >> should be possible. >> >> The bottom line: manipulative operations should be deterministic. If >> there is more than one possible set of updates to the underlying >> relations that yields the same value for a view, then updates to such a >> view should be prohibited. > >
> I say it is willful to say "should be deterministic", it sort-of sounds
> good but from what I know it is contradictory with other goals people like
> Date talk about, such as making views behave the same way as base
> relations. If a dbms' logic admits boolean 'or', then traditional
> programming notions of determinism can't be satisfied. ...
The Closed World Assumption makes it possible for determinism to be satisfied, even though database values can be thought of as sentences in disjunctive normal form.
> ...I'll take a consistent logic over niceties any day, even if that puts
> me in a minority - I'm already a member of many other minorities, in fact
> I'm a member of more minorities than the number of majorities most people
> I've met who were in majorities were in, even though many of them think
> I'm not even in a minority!
Welcome to the club. I think it's better to question the status quo and risk being wrong than to be just a mindless lemming headed for the drop off. Received on Mon May 26 2008 - 17:01:22 CEST