04 Sep 1997

Physical Model

According to PowerDesigner dogma, you add, define, and delete all basic objects (entities with their attributes and relationships) only in the CDM and then generate (or regenerate) the PDM with those changes. For this reason, DataArchitect will remember and preserve PDM refinements when a fresh PDM is generated on top of the old from new CDM work. This is an elegant approach, traceable to James Martin's Information Engineering work and the ISO three schema architecture.

However PowerDesigner's implementation is less than perfect. First, it presumes - requires - that you always model from the top - i.e., the CDM - and generate changes downward into the PDM and then the database instance. PowerDesigner has no capability to resynchronize a PDM to hot fixes in the database, nor any way to resync a CDM to objects added or deleted in the PDM. Our clients tell us that real life is seldom that disciplined. Hot fixes do happen.

Second, DataArchitect's control dialog for generating a PDM from a CDM is inadequate to manage all likely conditions to preserve prior physical specifications. It has gotten better over time - much better in V6.0 than V5.1 - but the underlying technique is weak.

A third and serious deficiency in PowerDesigner's CDM/PDM split is the improper locus of some functions. As noted above, foreign keys are generated into the PDM where you must go to rename them to reflect site standards or business meaning. DataArchitect makes no attempt to carry forward elements of relationship definition as default foreign key column names. Also noted above, there is no CDM facility for declaring uniqueness other than the primary identifier. You must visit the PDM to do that. In the opposite direction, denormalization decisions about sub-types are made in the CDM when denormalization should be a purely physical issue. There are plenty more examples of the weak isolation of logical and physical models but you get the idea.

On the bright side, DataArchitect's PDM handles the creation of views quite well. You can lasso tables and create a complete joined view with three clicks. Double click on that view object and you can edit it through a form based query builder with nearly full control over contents of the Select, From, Where, Having, Group by, and Order by clauses. Conspicuously missing are views on views and nested queries, both of which are essential to series view management. But even without those in the interactive view builder you get a quick way to construct base views derived consistently from the model.

DDL

Reverse Engineering

Back to

See also

© © 1997 Applied Information Science