To the extent that the base relvars are less constrained, they are more flexible in the information they can record. However users probably don't work directly with them. Instead they work with views which enforce the constraints. It's asynchronous updates on views which result in temporary offensive tuples in the base relvars. I'll illustrate this with an example:
Let B be a base relvar with attributes {X,Y} and no key constraint, even though users expect the FD {X} --> {Y} according to the predicate. Let the following views be defined which enforce the key constraint:
V1 = RemoveDuplicates(B WHERE c, {X})
V2 = RemoveDuplicates(B WHERE NOT(c), {X})
V3 = RemoveDuplicates(B, {X})
Let there be a requirement for users to be able to update V1, V2 independently (and asynchronously). So an assignment to V1 must not change the value of V2, nor can it fail depending on the value of V2.
Proposed solution: an assignment
V1 := NewV1
(where it is assumed all tuples in NewV1 satisfy condition c) updates B according to
B := (B WHERE NOT(c)) UNION NewV1
Note: this assignment can lead to duplicates appearing in B.
This approach supports other conditions for WHERE, giving a great variety of restriction views which are not always independent (i.e. they can overlap), and yet every view supports well defined, infallible assignment.
A temporary non-empty (B MINUS V3) is interpreted as a artifact of performing updates on different views independently and asynchronously.
If we assume every view is eventually assigned correctly according to the extension of its predicate for a stable world situation, then we expect duplicates in B eventually disappear.
If we assume the views are updated correctly then the database must record the world situation correctly.
Furthermore V3 provides a relvar which necessarily satisfies the expected constraint, so V3 can be regarded as the SSOT (Single Source Of Truth) - if an SSOT is needed at all times - even during periods of change.
The SSOT is accurate to the extent that the users updating the database are accurate.
During periods of change the SSOT is wrong for only as long as the users take to issue the required updates.
It doesn't make sense that whenever a user performs any update (no matter how small they would like it to be) they are supposed to ensure that all other outstanding updates to all relvars are applied as well, in one big synchronous multiple assignment that might represent thousands of smaller changes.
If a user assigns V2 and is ignorant of V1, then they are authoritative for V2 but not for V1 or V3.
That seems far more practical than the idea than any user has to correctly and synchronously update the entire database.
There is no problem with the fact that V1 and V3 are "stale" just after the assignment to V2.
For very big databases a requirement of global synchronous updates depends on the fallacy that users have access to synchronous snapshots of world situations.
The reality is normally that the information going into a database comes from asynchronous sources.
The pretense of a database recording a synchronous snapshot of a possible world situation is ok as long as it is realised that in practice it's just an artifact of what updates have been applied to the database so far.
If it's an artifact then why not promote efficient, convenient asynchronous updates, and use a calculation to generate the artifact of a self consistent world situation that appears to have been recorded in a snapshot - however impossible that might really be?