#: Suggested alternative formulation: “Whether a given view can be updated-through or not must be determined solely from the declared database constraints, the given view's definition, and the requested update to be performed to the view (and thus update through it).”

# ''Essential'' tuple means that it is ''necessary'' for those tuples to be deleted/inserted to comply with 1., 2 for all valid states of the database.

I've never been happy likening update-through-view to update-to-array. Because there's only one way to update an array, and if two different expressions are targetting the same cell, that's referentially transparent. It's a little more like being able to target a slice/slab/sub-cube of an array (which some languages support), in that you're updating multiple cells with one statement. (For comparison, there's a quote alleged from Dijkstra that all array updates should be seen as assigning to the whole structure, even if they're targetting a single cell. Similarly for targetting components of data structures in general.) But I'm still not happy with the analogy.

An array you can't change the size/shape merely by assigning a new value; you can't at run time insert/delete cells (indexes) in the middle; you can't add an extra dimension. (Changing shape would be something like renumbering the indexes in an array with rationals between the integers, and leaving 'gaps'.)

You could also target by content an update to doubly-linked list: insert before the leftmost cell value 'XYZ'; delete 3 cells to the right of the rightmost cell value 'ABC'.

The rewrites for updates given in this approach take it that a target for update can be any relational expression, with a view name (virtual relvar) merely standing for its defining expression in a target context.