On 2 apr, 17:49, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

That might be a bit of a howler, given that :

if "procedural" and "functional" are the only options possible, then
"not-procedural" implies "functional",
and "functional" implies that no variables exist that outlive the
lifetime of the functional program,
and the most important target for which the concept of MA has been
invented, is a DBVAR,
which is a variable that outlives the lifetime of any executing
program by definition.

On Mar 19, 7:47 am, paul c <anonym... (AT) not-for-mail (DOT) invalid> wrote:

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. 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?

On 4 apr, 10:54, David BL <davi... (AT) iinet (DOT) net.au> 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 ?



(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.

On 02/04/2011 8:49 AM, Erwin wrote:
Yes, I'd say that's accurate, but I don't see why it should be
considered significant. It's 'outside the realm' of relational algebra
too. What I'd say should be significant is whether contradictions are
possible regardless of how the recording is accomplished.

On 02/04/2011 8:56 AM, Erwin wrote:
I don't know much about functional languages (which is why I try to not
mention the term), about all I've noticed in them is that statement
order does seem to matter. My guess at what is 'not procedural' is
closer to what people call 'declarative' but that's probably a
half-assed guess given that (I presume) even declarative languages must
deal with questions of precedence or associativity.

On Apr 4, 8:37 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
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.

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.

On 4 apr, 16:50, David BL <davi... (AT) iinet (DOT) net.au> wrote:
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 ?

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



You seem to make the important distinction between views that are
"updatable" and others that are "not updatable". 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) ? 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 ...).

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" ?)



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 ?

On Apr 4, 11:45 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
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).


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.


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).


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.


I didn't know that.


Yes.


Yes.

On 5 apr, 10:04, David BL <davi... (AT) iinet (DOT) net.au> wrote:
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".

On Apr 5, 8:06 pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:
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?