Re: relative complement?

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 ?

> 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 !

(2) But views are also often proposed as a means for achieving data security, which is a quite different goal than the goal of logical data independence. E.g. it is often suggested that a security rule such as "users such-and-so can query an employee's name, but not his salary", can be addressed by defining the proper view (projecting away the salary attribute), and giving the user read authority on that view, but not on the underlying base relvar. Thus generating an actual contradiction/conflict, because an authority to read a view, inherently involves/requires authority to read the underlying base relvars.

And that issue of whether and how the definition of security rules defined in terms of virtual relvars should "match" with the same set of security rules defined in terms of the corresponding base relvars, is, to my knowledge, a largely unexplored one. I have the impression that people discussing virtual relvars often "hop over" from (1) to (2) and vice-versa, depending on whether 'security' is part of the discussion or not. Not realising that it might be the case that (1) and (2) are, in a sense, a mutually exclusive choice. Received on Mon Apr 04 2011 - 14:37:35 CEST