True Relational To Pseudo Relational Impedance Mismatch

The TrueRelationalToPseudoRelationalImpedanceMismatch is a label that could be used for the set of problems that could be encountered when using a PseudoRelationalDatabase (BagAtational?), as the mechanism for storing the data for a TrueRelationalToPseudoRelationalMapper.

Does it really exist? Does it.. for example, force you to allow nulls in your otherwise perfectly complaint TrueRelationalToPseudoRelationalMapper? or those are just problems with particular implementations ?

Some of the possible mismatches could be:

True Relational to PseudoRelational costs time and money
- It is not such a big problem, SQL and BagAtational are GoodEnough. SqlFlaws are not such a big deal, and RealProgrammer's can easily deal with them.
True Relational to PseudoRelational forces you to add SurrogateKeys to eliminate duplicates (or to add a column with a "count" of the duplicates)
- The root cause of the impedance mismatch... some think it is trivial to solve, others, that it is not. See BagNeedScenarios for a discussion.
True Relational to PseudoRelational forces you to use nulls
- see NullVersusNone
True Relational to PseudoRelational needs triggers for constraints
- is not possible to define constraints using Bag Algebra? or is it just not efficient?
True Relational to PseudoRelational needs support of user defined types in the PseudoRelational database
- how to translate them if there there is no support in the PseudoRelational database?
True Relational Operation/Constraint to Pseudo Relational PersistentStorageModule/Trigger
- What features are required in PersistentStoredModules so that the a D language (such as TutorialDee) can be compiled in to PersistentStoredModules? (Compilation is necessary so that the underlying PseudoRelationalDatabase protects its own integrity even if not accessed using the TrueRelationalMapper. One example would be the very powerful constraints available in TutorialDee, and the fact that there is not even one Sql database that implements CREATE ASSERTION, so the D constraints would have to be compiled into triggers/materialized views with checks)
True Relational to PseudoRelational needs Relvars
- most (all?) PseudoRelational database have no support for relvars, it is going to be too hard implement them in an efficient way

Are this real problems/mismatches? or perhaps TrueRelationalToPseudoRelationalImpedanceMismatchDoesNotExist and one can perfectly wrap PseudoRelationalDatabase under a TrueRelationalMapper? or perhaps that wrapping is only possible as long as the PseudoRelationalDatabase has TuringComplete PersistentStoredModules?

Discussion on what is PseudoRelational (and its differences with TrueRelational) moved to PseudoRelationalDefinitionDiscussion