Re: relative complement?

On Apr 5, 8:06 pm, Erwin <e.sm..._at_myonline.be> wrote:
> On 5 apr, 10:04, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Apr 4, 11:45 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
> > > Do you think it is feasible, when faced with a view-update request, to
> > > interpret the applicable constraints so as to reduce the set of
> > > possible base relvar assignments that "satisfy" the view-update
> > > request ?
>
> > Yes
>
> I slightly misexpressed myself.
>
> I know it is possible, but the only way I see is the "naive", brute-
> force, "trial-and-error" method :
>
> A) Compute all possible base-relvar-assignments that "satisfy" the
> view-update-request. (E.g. if the view is a 'simple' binary JOIN,
> then there are three possible solutions for DELETE. If the view is a
> join between three base relvars, then there are 7.) (Note that this
> step might already cause a failure when the set of possible solutions
> becomes too big, e.g. with insert-through-projection where no default
> value is available for the projected-away attributes.)
> B) Order all possible solutions by "preferability" : e.g. the
> 'symmetric' option for delete-through-join is always to be preferred
> over the 'non-symmetric' ones, but the non-symmetric ones have equal
> preference.
> C) In descending order of preferability, and for each distinct "level
> of preferability" :
> C1) process all possible solutions that have that "level of
> preferability", computing whether the solution will pass all database
> constraints (plus whether the solution satisfies the assignment
> principle, at least on the targeted view.)
> C2) If there is a unique solution that will pass all constraints,
> accept it.
> C3) If there is more than one solution that will pass all constraints,
> reject the update.
> C4) If there are no solutions in this "level of preferability" that
> will pass all constraints, then go down to the next "level of
> preferability", and if there is none such, reject the update.
>
> All of this is possible. But imo, the amount of computation involved
> makes it infeasible. My question concerned the feasibility of
> interpreting the constraints in an "intelligent" way to find the
> applicable solution "more directly".

Perhaps treat your general approach as the fall back, and the DBMS statically analyses the view query and dbvar constraints for special cases that tend to occur in practice. It is noteworthy that once a constraint implies injectivity (and hence a well defined inverse view function), any additional constraints cannot change that.

Optimisations to your general solution are possible. E.g. if the potential solutions are a powerset over some set of base relvar updates and any of those individual updates can be shown to satisfy or not satisfy the constraints independently of the others (which can easily happen because of separability) then the problem can be reduced to a simpler one. In some cases this analysis could be done statically.

But is this a problem worth solving? Received on Wed Apr 06 2011 - 04:28:28 CEST