PowerDesigner Dictionary Meta-Model

The meta-model on which PowerDesigner is based is highly object oriented and well normalized. This can be seen directly by inspecting the tables in an instance of the MetaWorks repository. Those tables are also reflected in the layouts of the PAM, CDM, and PDM model text files.

The resulting physical meta schema (below) is poorly understood by most users of PowerDesigner.



Many users who are not uneducated in formal modeling concepts do not understand the purpose, value, and pitfalls of the three levels of Domain, Data Item, and Attribute.

Issues:

Duncan Dwelle

• Should Powersoft publish the meta-model (PDM at least) of the PowerDesigner distionary? It is available from AIS as an unsupported reverse engineering excercise but Powersoft has not provided a meta-model. Other vendors do: CSA (Silverrun), Popkin (System Architect), LBMS (Systems Engineer), Bachman (Ground Works), Sterling (KEY: Enterprise - ADW).
  
• Should Powersoft publish the file layouts for the PAM, CDM, and PDM model text files? These layouts exist and have occassionaly been provided on an "as needed" basis.
  
• Unique object naming rules:

There has been extensive discussion about PowerDesigner's enforcement of methodology requiring that every data item CODE value be unique - without regard to its placement as an attribute of an entity. This becomes a problem in reverse engineering many legacy databases where the same column code has been used in different tables with different definitions and structures.

Jeff Weeks

• The tool should allow and enforce user defined object property standards (ex. Naming standards) for all objects across the site.

Powersoft DPD - Veronique Audino (for discussion only)

• Uniqueness of data item codes

This point is the first step in adding more flexibility to the product. It allows customers to parameterize PowerDesigner behavior in certain cases.

PowerDesigner today forces users to conform to some design rules in order to guarantee easy reading and maintenance of models. We want to give to customers more flexibility, particularly when re-engineering legacy databases. To suit this requirement, as an option, we will modify the identifier of a data item. In this mode the identifier of a data item is its code plus the code of the entity to which it belongs. So, several data items could have the same name and code. A data item will be linked to only one entity. The « Add » button from the attribute lists will copy any data item already existing in the entity. In all list views, the code entity will always be added to the data item code.

• Uniqueness of relationship names

PowerDesigner 4.2.1 already allows the same name for two different relationships. To increase our flexibility, as an option, the identifier of a relationship will become the relationship code plus the codes of both entities to which it is related.

In release 5.0, the relationship code will gain more importance. First, the relationship name and code will always be used as the reference name and code in the physical model. Second, the relationship code will be used as the default constraint name for the foreign key.

In the PDM, the reference identifier will be the reference code plus the codes of both tables to which it is related. The table generation will be modified in order to ensure the fact that two tables should not have the same code.The constraint generation names will be modified in order to ensure that default constraint names are still unique.

The relationship labels, whose contents are not controlled, should be used to complete the relationship definition.

Paul Ratkos

• There is a substantial paper on this subject which was written for Chrysler to address their requirements.

John Pederson

• Many calls I receive are because someone is trying to use NAME as a primary key on two entities. I understand the argument that each data element must be unique. Most developers however never see an attribute or column out of context of an entity or table and therefore have trouble with PowerDesigner. It doesn’t work the way they do. Allow an option to allow an attribute to be unique within entity. Many calls I receive are because someone is trying to use NAME as a primary key on two entities. I understand the argument that each data element must be unique. Most developers however never see an attribute or column out of context of an entity or table and therefore have trouble with PowerDesigner. It doesn’t work the way they do.

Eric Standring

• Marriage of the meta data tables to the sybase system tables (eg, sysobjects) via use of sybase system table keys in the meta data tables.
  
• User extensible object properties: e.g., Ability to mark objects as members of a group (eg, all these entities are part of sales and marketing) and then to autoformat so that the diagram looks right.

Powersoft DPD - Vernonique Audino

• One of the enterprise needs is to enforce naming convention. We are considering adding a to link the « = » button to any DLL. This DLL will be able to enforce any naming rules and automatically deduce codes from names or names from codes.

See also Hooking a lexicon into PowerDesigner

• Refreshing inherited descriptions in the PDM

Sharon Getha

• Some properties should extend to the attribute level, not just the entity level. We would like to see the last update date be at the attribute level. We would like to see the ability to color attributes differently. This would help in communicating changes made (and other things) at the attribute level.

Where to go from here:

• PowerDesigner strategic context
• PowerDesigner product page
• PowerDesigner Users' Group
• AIS Home
• Contact AIS at ddwelle@aisintl.com or feedback form

© © 1996 Applied Information Science International