All notes in blue are enhancements as of Version
5.0.
According to Dwelle's
dictionary of nonstandard acronyms, a CREATURE is a CREAtive
feaTURE Suggestion. What follows is an annotated list of feature
enhancements to PowerDesigner which have been offered by various users.
A model viewer which could display an PowerDesigner CDM
or PDM without the ability to edit it would enable more widespread access
to models (for developers, users, query writers) while limiting both exposure
to unauthorized modifications and the cost of additional licenses.
CDM List of Relationships, CDM List of Inheritances, and PDM List
of Columns. These should have all the same features (e.g., "Find",
"Reference") as the existing lists of Data Items, Entities, Indexes,
etc.
Mass change capability on all Dictionary/List forms and the
attribute and column edit forms.
"Spread-sheet" format should contain all propertiesof
a listed object rather than an arbitrary subset (name, code, data type)
with a horizontal scroll bar to access those columns out of sight. The
user should be able to drag columns to change display sequence. This would
prepare the interface for eventually adding user defined properties or
"extended atrributes" to any object.
Make all CDM design features available and visible. Each property
selectable on the CDM Relationship Definition panel needs to also be visible
on the CDM diagram and available via a tool box icon. In addition, several
conceptual referential properties are currently accessible only
on the PDM.
There are several design issues which the designer must currently express
in the PDM: merging multiple inherited references to the same foreign key;
renaming multiple references to the same foreign key which refer to different
concepts; referential integrity degree (update and delete options); and
the option to allow a change of foreign key parent (known as "transferability"
in classic data modeling literature). All of these issues should be captured
in the CDM without resort to the PDM, both because they are conceptual
and because large organizations want to draw a clear line between data
analysts using the CDM versus database administrators using the PDM.
To capture all relationship properties graphically in the CDM, add several
icons to the CDM tool box: triangle for dependent; bar for mandatory relationship;
square for non-transferable reference; one icon each for RI degrees of
cascade and nullify (see below). Any of these can be dragged from the tool
box and dropped onto a relationship line in order to apply its property
to the relationship. Conversely, the symbol can be "deleted"
or dragged off the relationship line and dropped onto the tool box to remove
it.
Make all PDM Integrity Definition panel items visible on the
PDM and available via a tool box icon:
Masking of PDM functions which might contradict the CDM. The
PDM allows many functions (e.g., delete table, add column, change data
type, change reference expression, change mandatory parent) which overwrite
properties modeled in the CDM. This is dangerous and undesirable in an
enterprise setting where there is usually a strict separation between conceptual
and logical design versus physical implementation. Workers in the latter
area should be shut out of possibly corrupting the model by changing properties
inherited from the CDM. Such protection would require offering the site
adminstrator an ability to configure PowerDesigner to turn off, individually
or collectively, those PDM functions and options which should not be available.
Default new attributes to a "null" or "not yet
defined" data type rather than providing an arbitrary A10. This would
force the designor to consider each attribute before generating the PDM
and allow searching for attributes whose data type had not yet been specified.
Enable adding domains directly from the attribute (or data item)
edit window by accessing the domain edit window (perhaps with an "..."
button). This would provide a consistent, object-oriented interface and
remove an impediment to the use of domains.
V5.0 provides this function with an elipsis [...]
button to the right of the Domain field on the Data items of an entity
window.
Mark candidate keys in the CDM. Alternate keys should be supported
in the CDM as a function of candidate keys, with the subsequent ability
to designate one of the candidates as primary. Conversely, only candidate
keys should be eligible to mark as primary keys. Thus alternate keys would
be subtractive; i.e., Candidate Key(s) - Primary Key(s) = alternate Key(s).
Provide a program "hook" on the CODE "=" button
to allow calling a user-supplied function which could implement site specific
attribute/column naming conventions. This could be via DDE, OLE, or simply
a call to an empty (dummy) DLL which the user site could customize.
Attach business rules to a PDM reference or index. For example,
a business rule may require uniqueness in a column or column set. This
is implemented in the PDM with a unique index yet there is no way to indicate
this by attaching a rule to the index.
Show all generated attributes (i.e., foreign keys and inherited
attributes) within the CDM, rather than forcing the generation of the PDM
to preview the resulting column, to assist in visualizing the conceptual
flow of propagated attributes. These attributes, being functions of either
relationships and identity or inheritance, would be read-only and should
be visually distinguished (perhaps by italics).
Generalize and expand the Find capability: make it more visible
(perhaps on the Edit menu); make it available for all objects (e.g. inheritance,
relationship, data item); find across sub-models (e.g., locate an entity
in all submodels); find and highlight multiple objects of one type in one
request.
Direct drill down from any list of references to access the
referenced object without going back up the navigation path to select another
option.
Hide/show/select submodel objects within submodels as well as
on the global model.
More internal consistency checks in the Dictionary/Check Model
command . For example: the specified legal values must match the data type
of the domain/data item for check parameters; the uppercase/lowercase check
parameters may only be used with character data types. Check should flag
unused domains as well as unused data items and warn about data items with
unrecognized data types.
Inherit a supertype identifier as FK only, rather than PK.
Specify which identifying attribute(s) are referenced in a relationship
instead of assuming the primary key. This is consistent with the fact that
the relational model allows relationships between any columns. Per {Codd90}
(page 36-37), "However, the DBMS must not, through its design,
constrain the target to be just one primary key for a given foreign key,
even though the most frequently occurring case may be just one."
Views referencing other views. This is standard SQL and the
foundation of many security systems.
Dynamically updated views rather than static SQL text objects
which do not change when their base tables are modified.
MS Word paragraph styles on reports exported in RTF for convenient
reformatting of the output. Lacking these, users frequently spend hours
in manual reformatting.
Granular priting configuration. Perhaps the printer setup options
(e.g. landscape) should be stored in the model or submodel, rather than
the .INI file, so that a user can configure the printer setup for a particular
logical presentation.
Auto-save option to save the current file to disk periodically.
Since PowerDesigner works with a memory image of the CDM or PDM, no
work is preserved until the user explicitly saves (just as in most text
editors). This can lead to a serious exposure of loss of work and design
thought if the user forgets to save frequently enough.
Central reference to the generated DDL or trigger effect of each
declarative modeling option which has any. E.g., Check/Cannot Modify,
Integrity/Change Parent Allowed (or not allowed), Integrity/Delete Cascade.
Bubble help or status line text on tool box and tool bar icons
to explain them as the cursor touches each one.
Increase to 80 characters the maximum length for object name.
Too short a name results in abbreviations, thus defeating to some degree
the purpose of having a natural name versus a coded name.
Separate "Name/Code" preferences for each object type
so that, for example, one can set a different code length for a table name
than a column name.
Published formats and documentation for INI, CDM, PDM, DEF, and
CDF files plus the repository tables.
Access DEF file meta objects such as "DEFINEIF" to
understand and perhaps modify their behaviors. These control critical DDL
behavior yet seem not to be included in the trigger template items library.
Move the "Options-Preferences-Confirm Delete" check box
to a more prominent place on the menu tree separate from the graphic symbol
preferences. This check box is critical to users' understanding of the
"delete" function. When the check is off and the delete dialog
does not occur, then the implicit delete behavior is different from the
global model (where it is a true delete) to a sub-model (where it only
detaches). This leads to puzzled users who thought they deleted something
from sub-model and then see it still present elsewhere in their model.
In V5.0 the Options menu is removed. All of its
items are now on a new, well organized File/Preferences window.
Improve the text in the dialog box for "Dictionary-Submodel-Update
graphics".
Separate the "Line Style" sub-menu into more distinct
panels: general line style (e.g., dashed, dotted, solid, ...); free-form
graphic arrow style (which does not pertain to modeled relationships);
relationship elbow type. The last needs to be much better explained to
make clear that if nothing is selected it sets the default elbow style.
Furthermore, the implicit option of a straight line (i.e. no elbows) should
be made an explicit option.
Capture multi-page PowerDesigner graphics into a Word file and
paginate appropriately. This would greatly assist in publishing diagrams
as part of a MS Word document.
Display option to reverse subtype arrowheads (i.e., pointing
at children). This is more consistent with common practice.
Shortcut to select all sub-type lines via the tool box (as there
is for all entities, relationships, or sub-type symbols).
Add subtype "completeness" (i.e., whether the subtypes
completely include the population of the supertype) to the inheritance
dialog, to complement the check box which indicatse that children are mutually
exclusive.
Generic trigger logic at the logical, rather than physical,
modeling level (e.g.: execute this trigger always vs. Default; RI degree),
generated into appropriate syntax based on the target DBMS.
Refresh "Description" when the PDM is generated. Currently,
if you enter CDM entity or attribute descriptions, generate the PDM, and
then modify the descriptions in the CDM, those modifications are not generated
into the PDM. That is, the inheritance of descriptions is purely static.
This is inconsistent with other inheritance modes (e.g., data properties,
domain changes).
"Option/Display" feature to show PK and FK columns only
with no non-key columns.
Protect the "Rebuild References" option with a more
explanatory confirmation dialog and remove it from the first level menu.
This option is only suitable for reverse engineering and is potentially
very damaging if executed in an existing, modified PDM since it discards
all modifications to references (e.g., naming, where clause order, integrity
elections).
Model DBMS permissions the PDM
Support multiple concurrent database targets from one CDM without
loosing customized trigger code. Currently changing target databases in
the PDM discards all user defined triggers.
Enhance the PDM "Indexes" dialog box to prohibit definition
of multiple indexes marked as PK or clustered. When such specifications
exports into DDL they will crash most databases or at least lead to unpredictible
behavior.
Add a rule icon and view icon to the tool box.
Include DDL changes in the "Modify database" delta script.
These might include table space and storage parameters which have been
modified in the PDM
Add multiple selections capability to all of the scrolling lists
in the various dialog windows.
Make "Dictionary/List of Data Items..." , "Dictionary/List
of Domains..." and "Dictionary/List of Entities..." windows
non-modal (i.e. all can be open at the same time and used simultaneously)
instead of modal (only one can be used at a time).
Add support for the aggregation relationship to complement the
inheritance link and better support object oriented approaches to data
modeling. Aggregation and inheritance are bare minimums. Support for characterization
would be nice but can be done using relationships.
Support multiple ranges of legal values in check parameters.
Associate an increment value with a range of check values.
Offer an PowerDesigner on-line tutorial.
Import or cut-and-paste legal values into the check parameters
window to support external sources of constraints.
Print ER diagrams and the model cards for all of the sub-models
together from the "File/Edit Report...quot; dialog window instead
of forcing the user to do one at a time.
Add a report option for listing sub-models with the "..."
button next to the graphics check box in the "File/Edit Report..."
dialog window the way that entities, data elements, etc. can be selected
in those reports.
Print all fields and sections in a report. Otherwise it is difficult
to determine whether a report was generated correctly with the right options
or if the subject (domain, data item, entity, etc.) of the report happens
to not have that option. For example, when printing a domain card all of
the check parameter fields should appear even if they are blank when the
checks option is chosen for that report.
Provde domain descriptions and annotations in the same fashion
as relationships, inheritances, entities, and data items.
Domains now have discription, annotation, and
label in V5.0.
Compare a CDM with a specified PDM to identify changes, show
how the PDM will be changed by the "Generate PDM" function, and
also show the physical modeling changes that have been made to the PDM
that will be preserved during generation
We have confirmed experimentally that adding trigger templates or
trigger template items to a .DEF file does not make them available
in PowerDesigner. Apparently the lists of expected templates and items are
coded. It would be highly desirable to allow users to extend at least the
list of template items.
Where to go from here:
© ©
1996 Applied Information Science International
Creatures