04 Mar 1996 updated
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.
V5.0 adds CDM List of Inheritances and
PDM List of Columns.
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:
Copyright ©
1996 Applied Information Science International
Creatures