A common assumption is that a relational database records the extensions of predicates about exactly one consistent, synchronous snapshot of a single world.
This assumption is implicit in the declared integrity constraints involving multiple relvars.
However a database system may be distributed, and have significant latency between nodes, updated independently by many users. Even when there is a single participating database, it is common for the users to be geographically separated.
The dbvar of one of the participating databases may ony record part of the overall information. So it's typically possible to reduce its scope to a smaller microworld.
If two databases can be updated independently and asynchronously, then they should be regarded as independent logical systems - i.e. describing independent microworlds. In other words, there is no sense in which they simultaneously record extensions of predicates about a single world.
Generally speaking users are not omniscient and they issue small updates on the basis of what they know. The assumption that the entire database system records a consistent snapshot of an all encompassing world situation is a fiction.
When integrity constraints are imposed across relvars, then users have to authoritative (i.e. able to be trusted as being accurate) across those relvars.
If this isn't the case then the integrity constraints are inappropriate because the users are unable to enter the information for which they are authoritative.
This is because the database may refuse to accept what they know because it conflicts with other information for which they are not authoritive, and which is updated independently and asynchronously by other users.
The solution is to avoid integrity constraints on the base relvars, and promote independent, asynchronous updates by users. This makes all the difference to the view update problem.
Even though the assumption that the database records a snapshot of an all encompassing self-consistent world situation is a fiction, it can be a useful approximation to the truth, and a useful read-only artifact for anyone who wants to issue queries on the distributed database to see the "big picture" or to be insulated from the vagaries of the update process, such as the temporary inconsistencies.
This collates the information from the base dbvars despite the fact that they are updated independently and asynchronously.
Fortunately it is straightforward to calculate a derived dbvar that represents a read-only global consistent snapshot of the world.
Being read-only means it can be a non-injective function of the base relvars (i.e. it can drop information). For example it can "fix" problems with the data, such as by removing duplicate tuples that violate a key constraint, or removing tuples that violate a foreign key constraint.
However, it's inappropriate for that fiction to be imposed on the users performing the data entry, where those temporary inconsistencies are expected and must be allowed to occur.