One can speak of L-values being created and deleted over time. L-value expressions sometimes denote a L-value and sometimes don't - i.e. whether an expression denotes a L-value can change over time.
E.g. in C++
std::vector<int> L;
L[3] = 7; // CRASH!!!, L[3] doesn't denote a L-value at this point in time
L.resize(10); // create 10 variables
L[3] = 7; // ok now L[3] denotes a L-value
It is useful to have a separation of concerns between
E.g. in C++ modulo assignment is available on int variables so one might use it on an element of L in a statement like this:
L[3] %= 10;
There is a separation of concerns between
We want the same separation of concerns for updating a relational database, so we’re after expressions that denote L-values that can be assigned any value of their type. E.g. maybe something like this appends to a string attribute within a tuple
append( S WHERE S# = S#('S1') {CITY}, "x")
Prime factorisation of possreps doesn't (on its own) capture the most general notion of separability that is sufficient for possrep components to be independently updateable without risk of constraint violations.
For example, consider an implementation of an update operator, which contains a lexical scope within which a reference to an L-value has been bound, perhaps to a component of a tuple within a relvar. Within that lexical scope the reference to the L-value can be passed to update operators that efficiently update the L-value in-place. There are many such cases where the L-value can be assigned any value of its type without risk of constraint violations.
The prime factor concept appears to be applicable to the special case where both the existence and uniqueness of a specified binding to a pseudovariable that supports infallible assignment is guaranteed. More generally a concept of conditional binding is needed (such as when you want to bind a pseudovariable to the eye colour of Fred Flintstone, but that is conditional on finding the relevant tuple in the database in the first place).
It appears this idea of conditional existence of pseudovariables supporting infallible assignment is related to updatable views. E.g. an updateable view on Fred Flintstone's attributes. A user can be presented with this view and update it as though it's a separate database - i.e. without surprises because of integrity constraints depending on information that isn't visible in that view. Also there are no update ambiguities. It's as though there's a "separable" database nested within a containing database. The existence of the inner database is conditional (and in fact the outer database is able to delete the inner one).