Re: delete cascade
Date: Sun, 22 Apr 2007 17:56:30 GMT
Message-ID: <ilNWh.115396$DE1.20183_at_pd7urf2no>
Bob Badour wrote:
> paul c wrote:
>> ... >> (Haven't thought of a reply to the rest of the post yet but regarding >> the above, I must bring up a sidetrack even though I don't understand >> it - I believe some people say that you shouldn't delete from such a >> view, assuming it is defined by using join. I gather their reason is >> that there isn't just one set of changes to the base tables that will >> falsify the tuples in the view, eg., it would be enough to delete just >> the base invoice items and not the base invoices to make the view >> empty and they would like a logical reason for that decision compared >> to deleting from both base tables or vice-versa.)
>
>
> I look at that and ask: Is the join theoretically updatable? And I
> answer with: "Yes, not only is it updatable but we have our choice of
> update strategies."
>
> Granted, absent any other information, one has no theoretical reason to
> favor one update strategy over another, which is why a dbms must provide
> some means to express whatever additional information is necessary to
> disambiguate the situation.
Contrary to D&D, I prefer to think of all base relations as projections of whatever relations <AND> and <OR> produce. That way, I can define delete and insert by distributing a "where" clause across the tables and take a projection before assigning to a result relvar. At least, so I think, for all I know there is a big logical hole in doing it that I haven't yet noticed.
D&D define "R1 MINUS R2" as (quote)
"(where R2 and R2 have the same heading) is semantically equivalent to the A expression R1 <AND> ( <NOT> R2)",
so if invoices have no colour, one couldn't say
"Invoices MINUS Colour='Red'" in Tutorial D.
But if A were implemented and there was a relvar Colours with one tuple {Colour 'red'} one could say "Invoices <AND> (<NOT> Colours)", even if Invoices had no Colour. Whether (<NOT> Colours) were empty would depend on the domain of Colour. If it were empty, the result would be empty, if not, the result projected on the attributes of Invoices would equal Invoices. When it comes to subsequent assignment to a defined relvar, I would be happy to project on the attributes of the defined relvar.
The result might seem unfamiliar but I think it is logical, once we have decided to enumerate the attributes a particular relvar is allowed to have. I would rather do this than remember to introduce restrictions such as "same heading" in several parts of a grammar, ie., do it once.
p Received on Sun Apr 22 2007 - 19:56:30 CEST