Re: relative complement?

On Apr 4, 8:37 pm, Erwin <e.sm..._at_myonline.be> wrote:
> On 4 apr, 10:54, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Mar 19, 7:47 am, paul c <anonym..._at_not-for-mail.invalid> wrote:
>
> > > Given that preference, I think join deletes and union inserts become
> > > mechanical problems. For me, in the end it amounts simply to a user
> > > stating that the tuples of the literal B relation are (all) true and
> > > that B's predicate is immaterial. With those two assertions, the
> > > A-algebra is sufficient to describe what results a language should
> > > produce without ambiguity.
>
> > I accept the idea that update operators on views can be defined to be
> > unambiguous, dispelling a common argument against view updates such as
> > join deletes and union inserts.
>
> > However, I'm very suspicious of an application allowing users to
> > update a non-injective view of the data.
>
> Hmmmmmmmm. Are you saying here that it's OK to _define_ join delete
> and union insert in some certain way that "makes it unambiguous", but
> that the applications that _use_ such an update are then suspect ?

Typically, yes.

I'm suggesting a) ambiguity of view updates is a weak argument against their use because it's subjective; and b) there might be a much stronger argument against certain views which considers injectivity and ignores all discussion about the update operators.

I think perhaps the only thing that matters is whether the mapping from the relevant base relvars to the /updateable/ view is injective (noting that constraints can reduce the domain of this mapping and help make it injective). In that case updates on the view always map unambiguously to updates on the base relvars, so there is necessarily no view update problem. So by considering b) we end up not having to worry about a) anyway.

> > More specifically if users
> > of an application cannot in general distinguish distinct values of
> > some base relvar how can they reasonably be expected to have
> > permission to update that relvar?
>
> (1) If views are used as a means for achieving logical data
> independence, then this is a non-argument, because users will then not
> be aware of any base relvars, by definition of what logical data
> independence means, and it then follows necessarily that any
> consideration as to whether or not they "should have update authority
> on the base relvars", is itself merely a function on whether they do
> have update authority on the virtual relvars referring to such base
> relvars !

That doesn't invalidate my argument. Let me clarify: when I say the users have permission to update the base relvar, I only mean they are able to cause its value to change. I agree they may not even know that the base relvar exists.

Assuming the view mapping isn't injective, each possible view value gives an equivalence class over the corresponding values of the base relvars. This allows us to consider that the information in the base relvars is conceptually partitioned into a part that is visible to the users and a part that is not visible (and yet to some extent modifiable)!

I'm suggesting it is suspicious for users to be updating information from an application that doesn't even allow them to view that information. It's like having full or partial write access without read access - and that's bizarre. Received on Mon Apr 04 2011 - 16:50:30 CEST