Re: relative complement?

On Apr 4, 11:45 pm, Erwin <e.sm..._at_myonline.be> wrote:
> On 4 apr, 16:50, David BL <davi..._at_iinet.net.au> wrote:
>
> > On Apr 4, 8:37 pm, Erwin <e.sm..._at_myonline.be> wrote:
>
> > > 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.
>
> But isn't "ambiguity of view updates" precisely expressing the fact
> that the view in question is/constitutes a non-injective function of
> its constituent arguments ?

Yes you could take non-injectivity as a definition of the term Ambiguity-Of-View-Updates. However that doesn't imply that update operators are ambiguous (because one can easily define operators that aren't).

> I think so, but if you think otherwise, I'd like to see it explained.
>
> Taking V, R1 and R2 as relvar names and v, r1 and r2 as those relvars'
> values,
>
> If V = R1 JOIN R2, then for almost all v exists >1 (r1,r2) : v = r1
> JOIN r2 . Except in special cases such as v being the empty
> relation.
> If V = R1 UNION R2, then for almost all v exists >1 (r1,r2) : v = r1
> UNION r2 . Except in special cases such as v being the empty
> relation.
> If V = TCLOSE(R1), then for almost all v exists >1 r1 : v =
> TCLOSE(r1) . Except ...
> If V = PROJECT(R1, ... ), then for almost all v exists >1 r1 : v =
> PROJECT(r1, ... ) . Except ...
> If V = RESTRICT(R1, ... ), then for almost all v exists >1 r1 : v =
> RESTRICT(r1, ... ) . Except ...

Indeed, none of these views are normally injective.

Practical examples of bijective transformations exist. E.g.

• splitting a relation with a boolean attribute into two relations according to whether the attribute is true or false.
• alternative possreps on domains such as polar versus cartesian coordinates

Maybe it's exactly these kinds of "arbitrary decisions" in the schema for which logical independence is a useful concept.

> > I think perhaps the only thing that matters is whether the mapping
> > from the relevant base relvars to the /updateable/ view is injective
>
> You seem to make the important distinction between views that are
> "updatable" and others that are "not updatable".

Yes. I would say that read only views can represent all manner of calculations (e.g. a sample covariance matrix, the roots of a polynomial, the Delaunay triangulation of a set of points). Requiring every view to be updateable makes little sense to me, particularly for "summary" derived variables like totals.

There are many other reasons to make this distinction. E.g. it can be an important security issue (to grant a user read access but not write access to some data).

> It also seems like
> you want to apply the "injective-or-not" criterion only once it is
> established that a view is indeed updatable. What are your criteria
> for deciding that a view is updatable (or not updatable) ?

I would tend to only make a view updateable if it's both desirable and possible. I'm not convinced that updateable views are particularly useful (since demanding injectivity greatly limits their applicability).

I'm wondering whether it's better to simply accept that the database schema is largely determined by how the data is /entered/ by the various applications. More specifically, I suggest that given an application that purportedly /edits/ information recorded in and only in variable V derived from the database variable D, then D must be "separable" with respect to V (meaning that the DBMS can support reads and writes on V independently of other information in D not recorded in V).

If it is claimed that a variable D is separable into derived variables V and W, then ideally both the following are true:

• updates on V do not cause "silent updates" on W (and vice versa)
• updates on V don't "mysteriously fail" because of an integrity constraint that also depends on the current value of W (and vice versa).

I would expect the set of possible values of D is essentially a cartesian product over the possible values of V and of W, I think this happens when all constraints on D are separable (which by definition means any constraint given as a boolean valued function on D can be expressed as the ANDing of a boolean function of V and a boolean function of W).

It seems constraints can sometimes decrease our options for view updatability by reducing separability and sometimes increase our options for view updateability by increasing injectivity.

Note that although applications can have complex requirements involving read only transactions, read only views and their materialisation, indexing, distributed calculations, cache eviction, dependency graphs, etc none of this should have any bearing on the schema design (which should instead only depend on how the data is entered and validated).

BTW I'm somewhat motivated by my area of research which is Operational Transformation (OT). This allows for data to be replicated and sites can generate and apply updates to their local copy without distributed transactions. These updates are exchanged asynchronously and end up being applied in different orders on different sites. The basic idea of OT is to transform a remotely generated operation so as to preserve its original intention even though it is applied in a different context. That imposes some heavy restrictions on update operators and constraint checking. Separability is important to OT because updates on independent variables commute.

> In
> "Database Explorations", Date argues that there are no views that are
> "inherently non-updatable" (though my guess is he attaches a very
> intricate meaning to the word 'inherently' in order to make that claim
> true ...).

I didn't know that.

> And if I understand you right, and if I understand "injectivity" as
> well, are you indeed saying that none of the five views I gave a few
> moments ago as an example can be "updatable" ? ("updatable, but only
> in suspect ways" ?)

Yes.

>
> > (noting that constraints can reduce the domain of this mapping and
> > help make it injective).
>
> 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. Received on Tue Apr 05 2011 - 10:04:57 CEST