Results - Model Content

01 Jun 1996 updated

See also Model content section of the meeting presentation

  1. Consider offering the French AMC product in the North American market so that we can benefit from its Chen-style modeling.
  2. Expand to three level modeling in order to preserve the conceptual and logical views separately
  3. Represent sub-models with a single symbol in the context of a larger model. A sub-model would be contracted into a new symbol representing its entire content.
  4. Move toward object modeling by adding a complex entity/data structure/business object to the CDM.
  5. Add a domain mapping feature to allow any CDM domain to be mapped to one or more PDM domains which might differ in data type and scale appropriate to their respective database flavors. This would enable standard domain sets, with associated PDM properties, to populate new models.
  6. Provide Candidate Key capability in the CDM. This might look a lot like the current Alternate Key support in the PDM; i.e., allow selection of any attributes for inclusion in any number of candidate keys. The feature would have to be aware of attributes inherited through relationships or inheritance links.
  7. Add a preference option to show inherited attributes in the CDM.
  8. Add a PDM object origin tree to show each column's derivation from its root attributes, including their inheritances and domains.
  9. Provide a wizard to help convert a Many-to-Many relationship into an associative entity without loosing CDM and PDM definitions and changes which might have been made to the Many-to-Many and its generated table.
  10. Give an option to show an associative entity as a Many-to-Many relationship, as long as the entity has no relationships other than those equivalent to the Many-to-Many.
  11. Decouple cardinality from dependency. Currently the dependent symbol overlays the child end cardinality and also forces that cardinality to Many, thus prohibiting a One-to-One dependent relationship.
  12. Implement One-to-One PDM references as standard foreign keys (see also One-to-One notes)
  13. Allow inheritence without forcing inheritance of the parent PK. This is the only behavior of the inheritance mechanisim in PowerDesigner which prevents its use for completely open class modeling.
  14. Provide Bachman style box-in-a-box sub-type representation as an optional alternate to the current form.
  15. Expand the Describe/Annotate feature to provide user definable note types with behavior preferences, so that each note type (e.g., Describe, Annotate, ToDo) can have configurable inheritence behavior, configurable visible clues (e.g., list check box), configurable report appearance, etc.
  16. Separate the inherited root object description from any local text added at the inherited level.

Where to go from here:

© © 1996 Applied Information Science International