Today we continue reading the paper introducing DBPowder as we did in the previous post. We said that for complex correspondences, the developer needs to specify the complete correspondence among persistent classes and tables. which is not always possible because they are subject to change. With DBPowder, simple and complex correspondences are supported with a collaboration of a conceptual model and a navigational data usage description. During the initial rapid development, developers describe an Extended Entity Relationship model and DBPowder generates schema and classes for this model. During the latter spiral development, DBPowder introduces ObjectView, a graph based object description form over the EER model. The developers can refine their EER models and add ObjectView. and then DBPowder refines the existing relational schema and persistent classes and adds persistent classes for ObjectView.
In the discussion on related works, the authors mention ActiveRecord which is a one to one mapping between table and attributes - attributes of ActiveRecord are defined with those of the table. The advantage of this approach is that its simple but doesn;t work for complex correspondences.
Another example is the conceptual model eg. ER model as the basis such as WebML and Enterprise Objects Framework. Here schema and classes are generated from the conceptual model.
A third approach was introduced by Thiran et al which uses wrapper based ORM and applies the eight transformation operators one after the other to a target relational schema.  The descriptive power is limited within these operators.
#codingexercise


GetOddNumberRangePowerSeventhRootPowerTwenty (Double [] A)


{


if (A == null) return 0;


Return A.OddNumberPowerSeventhRootPowerTwenty();


}