Ok, I have a question, with a bit of a build up: RM is based on the
satisfaction of a given predicate. First Order Logic holds however that
if we have missing data then we simply have no satisfied predicate, and
it should not be encoded. There is a clear strain on RM here (observe
the huge debates on nulls) to attempt to provide a satisfactory
resolution for this situation, yet is a situation that is extremely
prevalent for three reasons:
- Incomplete Data at entry time.
- Incorrect Design.
- Static Design which no longer matches how the real world has
shifted.
In my eyes the fact that these 3 things happen so frequently indicates
that a system based on the satisfaction of a fixed predicate has poor
application to the real world and that the RM's solid mathematical
basis might be yet improved upon through integration of these issues.
Data is almost always incomplete, a designer cannot be omniscient and
will always make errors, but most importantly situations change.
Continually. It is preferable that we have a database model that
accomodates these factors: they are not orthogonal to data modelling
processes in the real world.
Hence my question is does Pick go anywhere to accomodating these
issues? If so, and given that it is clearly not the be all and end all
of data storage, what are the crucial mechanisms that allows it to do
so that might be of use in future systems?
Received on Wed Jan 18 2006 - 15:34:27 CET
