In general I would say there is no such thing. What you usually find, in a mismatch scenario, is a data model (logical model to be more precise) that is incorrect.
If your logical model correctly structures functional dependencies the mapping is trivial. You simply work with creating objects that act as specific views to your data (then insert ORM framework of choice to simplify SQL calls).
This really isnt the same as direct table mapping, but its close. If DBMS vendors had better support for updateable views, you'd really map your objects to the views you intended your application to use.
The hard part is noticing when there is something wrong in your logical model and fixing those table declarations, prior to writing 1000's of lines of code trying to simulate a correct model.
In general I would say there is no such thing. What you usually find, in a mismatch scenario, is a data model (logical model to be more precise) that is incorrect.
If your logical model correctly structures functional dependencies the mapping is trivial. You simply work with creating objects that act as specific views to your data (then insert ORM framework of choice to simplify SQL calls).
This really isnt the same as direct table mapping, but its close. If DBMS vendors had better support for updateable views, you'd really map your objects to the views you intended your application to use.
The hard part is noticing when there is something wrong in your logical model and fixing those table declarations, prior to writing 1000's of lines of code trying to simulate a correct model.