Skip to Content

How to handle Subject Areas and Data Classifications in PowerDesigner?

I have been using PowerDesigner for a while, but I am starting to work with a newly formed team where some of the members are use to using ERwin and ER/Studio for their models. As part of this coming together we have chosen to use PowerDesigner going forward and have the ability to sit back and decide on how to do things as a team.

As part of this we have been discussing how to capture "Subject Areas" and "Security Data Classifications" for these new models. We have tentatively chosen to leverage the Package Feature in PowerDesigner to represent the "Subject Areas", since the Packages in PD behave like "Subject Areas" in ERwin. We are also looking to use the Stereotype attribute to capture the Security Classification of the data on Entities/Tables and Attributes/Columns in the Logical/Physical data models.

We looked at adding additional attributes to capture these attributes, but I have ran into issues in the past with them.

Does this look like a sound way to handle capturing this information? Show less

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • May 31, 2018 at 12:41 PM

    Hello Shawn, I'll address your questions one at a time :)

    1. Subject Areas

    If you don't want to use model extensions, packages are a useful way of representing Subject Areas in PowerDesigner.

    • Entities can be owned by the package that represents the Subject Area
    • Diagrams are grouped by Subject Area, which can simplify the model object browser
    • You can set package-level permissions in the repository, allowing you to have more control over who can check-in model updates
    • The package name appears on entity symbols in diagrams

    However, there are some possible concerns, which are not really big issues:

    • Your modellers will need to know about shortcuts - this can affect things like selecting entities (in various dialogues), dependency matrices, list reports, and lists of objects on the model menu
    • In General Options, make sure you change "Shortcut Property Sheets" to open the target object, not the shortcut
    • Make sure relationships are owned by the same package as the parent entity

    Here's another way to manage subject areas, which will need a model extension:

    • Create a single package called "Subject Areas", which does NOT use the parent namespace
    • In this package, the entities represent Subject Areas. You can use icons to represent them, and draw traceability links or relationships between them, to give you a simple high-level subject area model. If you want to, give these entities the stereotype <<Subject Area>>. It would be useful (in a model extension) to declare the stereotype as a separate metaclass, so they appear in the Browser, and can be selected as such in matrices, etc. You'll also be able to do custom checks (such as checking thet every entity is linked to one Subject Area).
    • In a model extension, link entities to subject areas. This will be one of two ways, depending on where you want to do the updating:
    1. On the entity, add an extended attribute that links to a single entity object, with stereotype "Subject Area"
    2. On the Subject Area, add an extended collection that links to many entities
    • Add whatever custom checks you need to make sure the links are being used properly
    • Add a dependency matrix that allows you to visualise and possibly edit the links between the entities and subject areas

    2. Security Classifications

    I would always be very (very) careful when you decide to use Stereotypes, as you're basically limiting yourself in ways you might not appreciate later on. There are many ways in which you might want to classify entities and attributes:

    • Security Classification
    • GDPR and other regulatory requirements
    • Ownership
    • Transaction / Reference / Master data
    • Commercial Sensitivity
    • etc

    Whichever of these you base your stereotypes should be the one that has the most influence on how you want to handle them in PowerDesigner. One good way of looking at Stereotypes is that they allow you to create sub-types in your metamodel (you do have a metamodel, don't you? :)), and real subtypes need a reason to exist - they will probably have additional properties and/or links, and/or be managed differently. Remember that Stereotypes are passed on when you generate further models, so you have to think about how you're going to use them in those other models.

    The alternative is to use extended attributes instead of stereotypes. The allowable values can be defined in GTL templates, and you can even make the values for one extended attribute depend on the value chosen in another extended attribute. If you want to entities or attributes in specific ways depending on their security classification, you can define Criteria in the model extension.

    Add comment
    10|10000 characters needed characters exceeded