PowerDesigner do’s and don’ts

Many people consider PowerDesigner to be the de facto standard datamodelling tool. Many people are right. However, that does not mean the tool is perfect. As many users can testify, the version 16 release has been quite buggy in the beginning, only stabilizing a bit more with 16.5. And this is not exceptional. The repository is still buggy, projects are a recipe for pain, and let’s not start a discussion on license prices – we’d still be here next year.

However, if you avoid some practices and adopt others, using PowerDesigner is a breeze. Here is my take on things.

Do Not:

  • Use the repository
    The repository is a major cause of bugs. It looks nice, like a venus flytrap, and then it sucks you in and eats you for breakfast. Avoid it like the plague. You are better off spending some money on creating an extension to generate a model export to your own repository. You can buy this from I-Refact or other parties. The other functionality can be done better, cheaper and with less frustration and bugs by just using standard version control software (TFS, git, etc.). If you must compare models, you can do that from within PowerDesigner with very little effort – without losing parts of your model on the check-in/check-out.
    There is only one part of the repository that is actually semi-useful, which is the indication whether your model is out of date versus the repository version. As this functionality does not cooperate with replication or extensions that use that, there is little point in it once you evolve beyond the basics. Also, it is much better to split up your models so as to avoid getting in a situation with 10 people working on the same model. Even potentially. If this is a risk, appoint a designated datamodeller for such a model. The rest can get a read-only version.

  • Hide attributes on entities by hiding them
    Unless you use an extension to automate setting/un-setting this and also indicate this visually, it can create no end of trouble when the model shows tables and columns but leaves out certain columns that then get deployed anyway. It takes ages to debug that. If you must do this, make sure it’s an all or nothing proposition: either hide all standard attributes, or none.

  • Create shortcuts to other models
    While PowerDesigner does this automatically once you start creating mappings, there is no need to refer to models outside the scope of the folder, as this will render the models almost impossible to deploy without heaps of pop-ups asking about other models that you have not yet stored in the right location (and don’t even know where they should be located). Only consider this if you have an agreed-upon folder structure and even then I recommend you don’t do this.

  • Create Projects
    Sure, they’re good for having a dependency graph view. But you can create those anyway. And projects are buggy, especially when interacting with the repository. Half the bugs I found in PowerDesigner went away when I stopped using projects and moved to workspaces. No more disappearing models, or graphics. No more models that are impossible to check out or check in.

  • Work for long periods without saving
    The PowerDesigner auto-save function is nonexistent. After you work with PowerDesigner for a while, you will learn to save often. It becomes a reflex. Because it hurts when you lose hours of work through a crash. It’s not as bad as it was when you were still using version 16.5.0, with repository and projects, but still.

  • Use auto-layout without a current back-up
    Your gorgeous, handcrafted model could use a minor improvement and you used auto-layout. And then you pressed “save” automatically, because by now it’s a reflex. And when the screams died down, you realized you didn’t have a current backup. Ouch. Backup often. If you use Git: commit often.

  • Model the entire Logical Data Model as a hierarchy of subtypes
    I have seen them, with their entity types derived from the Object supertype and each other, six hierarchical layers deep. I dare you to try it with a non-trivial model and then generate a working physical model out of it. Go ahead, make my day…

  • Create a unique data domain for each attribute
    This sort of misses the point of data domains. Because while they are rather limited in PowerDesigner (no entity types or attribute groups), they are most useful when they provide a single point to change definitions of common attributes. Use them freely, but let the data architect decide which ones are available for use. It’s best to create a single model for this, that you can use as a template for the other models you create.

But Do:

  • Add metadata to your models
    Especially metadata that describes the following items: Title, Subject Area, Author, Version, Data (Model) Owner, Modified Date, Modifications, Validation Status

  • Add domains
    Create a list of standard attribute domains, then create a template model containing them. People can either copy the model file directly and use it as a template (this creates havoc in a repository though, because the internal model ID will be the same as that of the template model), or copy the attribute definitions into your own model. The definitions should be controlled by the data architect(s).

  • Add attribute groups
    If you create attribute groups of commonly grouped attributes in keyless entities, you can then inherit from multiple of these entities in order to combine them. Most useful when you have things like “firstname/lastname” pairs of attributes that you do not want to separate out to their own entity, for some reason. Use with caution.

  • Tie models together with separate workspaces for each project
    Workspaces are small files with zero overhead that tie different models together. They have no impact on the repository check-in/check-out, they are files that can be under source control, and they are pretty much bug-free. You can even edit them when necessary. Much better than projects.

  • Store your models in version control systems
    Seriously, I should NOT have to say this, but I keep meeting people who don’t seem to realize that MODELS ARE CODE. And with a VCS I do not mean that abortion they call the repository. I mean TFS, Git or even Subversion. Anything that works, basically.

  • Save often
    If you don’t, you’ll regret it.

  • Store backups
    Having version control is not the same as having backups, unless you commit often.

  • Create a folder structure that is the same for everyone and make it mandatory
    If you don’t, you’ll create unending pop-ups whenever someone opens a model they did not create themselves. If they check it in, it’s your turn the next time you open it from the repository.

One thought on “PowerDesigner do’s and don’ts

  1. George McGeachie

    Thank you for the time you’ve taken to produce these notes, Ronald. You’ve obviously had some hard times using the repository, and some good times with the other features. I’m an independent consultant, and a real fan of PowerDesigner, which I don’t keep quiet about, and SAP don’t pay me to be nice about their product 😊.
    I don’t think PowerDesigner is any more buggy than other long-established tools I’ve used, like Erwin and ER/Studio, even though it’s a much more complex tool. I’ve found that SAP’s customer support process is pretty good, though their priorities when it comes to fixing bugs are definitely not the same as my priorities sometimes.
    I’ll address your comments on the repository at the end, after this lot:
    • Hiding Attributes
    The only way you can hide attributes is by preventing them from appearing on entity symbols (either all symbols or selected symbols). They will always appear in the browser, in the attributes tab of the entity properties, and in entity lists or in list reports, unless you’ve filtered them out. Hiding standard columns (like the 7 audit columns you want every table to have) can make diagrams more readable, so I would never advise anyone not to hide them. You could have a small script, implemented as a custom model check, that will warn you about the hidden columns. You could also write a small fixing script to ‘unhide’ those symbols, but that could really mess up your nice and tidy diagrams.
    • Create shortcuts to other models
    Shortcuts are extremely useful, and sometimes unavoidable. I agree, it does make life easier if you have an agreed folder structure, but the workspace is more important.
    If you follow a shortcut that refers to a target model that is in your workspace, you won’t need to browse to find the model. Having the linked models in one workspace is the key thing here.
    If you’re using the repository, make sure you select the option to check out the dependencies (linked models) as well.
    • Using Projects
    A PowerDesigner Project is a much different beast from a workspace – it’s meant to be a container for managing a set of related models that form a coherent ‘thing’ between them and will probably always be worked on as a set. There are repository bugs I’ve come across that occur only when models are in a project. My advice to people is to think very carefully before they use projects.
    • Working for long periods without saving
    This is something I never do, in any software, even if the software does ‘autosave’ for you. Even if you have saved the model after doing something foolish, the undo option will still work – as long as you haven’t closed the model, of course. Sometimes, the ability to undo changes just goes away, and I haven’t figured out how that happens.
    If you haven’t done it yet, you should select “save recovery backup file” in the General Options – it can be a lifesaver. With this enabled, PowerDesigner saves the current state of the model periodically, in a file with almost the same extension as the original. If you’ve made a mistake and saved the model, here’s what you do:
    – Close the model
    – Find the model in your local folders using Windows Explorer, right next to it will be the backup file. For example, the backup for “My LDM.ldm” is “My LDM.ldb”. You can drag that file into your workspace and then open it, or change the file type to “ldm” and then open it.
    • Have a deep hierarchy of subtypes
    What goes wrong here? Can you collapse the super-sub relationships a level at a time? Perhaps you could generate a PDM that has only some of these structures collapsed, then generate another PDM from that? Another approach would be to write a transformation that simplifies the LDM before generating the PDM?
    • Create a domain for each attribute
    Agreed, that is just daft, and a complete waste of time, as domains are optional in PowerDesigner, though they aren’t in some other tools.
    • Creating domains that can be shared and reused
    If you use the repository, keep your “standard domain” models in the Library folder, and they’ll be pushed out to users when they connect, ready for them to copy, link to, or replicate.
    • Use template models
    In the model creation section of General Options, enable the use of templates. When you create a new model, you’ll be able to clone a model from your template folder, and this won’t have the same object ids as the template model. With a User Profile, you can ensure everybody uses the same path for templates if you want to.
    • Store your models in version control systems
    If you want to, please still consider using the repository.
    • Have the same folder structure as everyone else
    That’s a very good idea. When you save a model, PowerDesigner examines the folder path you’ve stored it in; if the folder path matches one of the Named Paths listed in General Options, the reference to the model in the workplace (and the repository when you check it in) is relative to the named path, not absolute. E.g. URL=file:///%_MY_MODELS%/DMZ 2018/Graphical Synonyms.cdm.
    With a User profile, you can define this Named Path – if you check the User profile in to the Library, you can make sure this User profile is applied to all users when they connect.
    • Using the repository
    I know some users have experienced issues with the repository, and no doubt some of those are due to using projects. Before anybody decides not to use the Repository at all, consider the following reasons to use it:
    o The Glossary
    o Giving access to non-modellers via the web portal (including editing Enterprise Architecture and Business Process Models)
    o Sharing models and resources (DBMS, extensions, etc)
    o Managing access and editing permissions
    o Branching
    o Comparing model versions without checking them out
    o Creating Configurations of related model versions
    o Extending ‘find objects’ into models you don’t have open, or didn’t even know existed


Leave a Reply

Your email address will not be published. Required fields are marked *