Subject Areas – an art form for data modellers and data governance? #PowerDesigner #datagovernance #ERStudio

(this article was originally published in 2011 – I’ve made a few minor amendments today, nothing to change the message)

Time spent using colours, font styles etc. can definitely increase both the clarity and usefulness of a model.  If that use of colours and styles can be automated, even better.  Previously, I’ve used macros in a data modelling tool to define styles for entity symbols that depend on the business owner, and font styles that vary according to when the data (master data in this case) is expected to be available.  I also colour-coded relationships to denote the business area responsible for managing them, which is not always obvious. This information was all held as properties on the entity and relationship, making the macro pretty straight forward.

You can also use colours and styles to highlight entities or tables affected by a given release or change request; again, this is possibly metadata that is available for a macro to query.

One great use of colour-coding and styles is to categorise entities on a diagram, using colours to denote the owning subject area.

I recently examined a data model where all the entities were categorised into a number of subject areas, and there was a separate ERD for each subject area.  Unfortunately, the model suffered from a complete lack of artwork.  There was no colour coding, so I couldn’t tell which subject area any of the entities belonged to (though of course I could guess some of them), so I couldn’t be sure which ERD I needed to look at to see the full context of a given entity.  I had to use the main model ERD to be sure that I was seeing the full picture for an entity; this showed all the attributes for every entity, and made no use of styles or colour whatsoever; it was a difficult diagram to work with.  Thankfully, it did fit onto a single sheet of A3 paper, as the model was quite small.  In this data model, the subject areas were virtually unusable and irrelevant, because they weren’t being communicated at all.

When creating subject areas, think carefully about why you need them, and how users of the model should interpret  them.  You could break the model down into data-related subject areas, functional areas, system of record, etc.  With a really large model, you may be able to justify having multiple sets of subject areas for different purposes.

Take the example of subject areas based upon a higher-level data model; let’s say that the higher-level model includes 60 concepts, including:

‘Abstract Geography’ includes 15 entities, including ‘Company Location’, ‘Country’, and ‘City’. ‘Exploration’ includes 20 entities, including ‘Well’ and ‘Field’.  Both ‘Well and ‘Field’ will have relationships to entities within ‘Abstract Geography’.  Here’s part of the complete LDM:

Note that the colours tell you which subject area ‘owns’ each entity, and also which subject area is responsible for populating relationships.  The diagrams were created in SAP PowerDesigner, which uses the triangle symbol on the relationship line to indicate a dependent entity. here’s the same diagram in Idera ER/Studio Data Architect

Subject Areas as art - ERStudio

Assume I have separate subject area ERDs for my concepts; where can I be sure of seeing all the relationships between the ‘Abstract Geography’ and ‘Exploration’ entities?  I would expect to see all of them on BOTH subject area ERDs.  It would even be possible to code a macro that tells you which entities should be on a given subject area ERD; again based on the metadata in the model.

Is any of this art?  No, but it is a combination of graphic design, common sense, and ergonomics, with a tasty dash of automation to make it more palatable.


“#PowerDesigner Fundamentals for Data Architects” at Data Modelling Zone EU 2018 #DMZone

Are you thinking of attending Data Modelling Zone in Düsseldorf in September 2018?

  • Are you an experienced data architect, new to SAP PowerDesigner?
  • Have you used SAP PowerDesigner in the past, and need bringing up to date?
  • Are you currently using SAP PowerDesigner, but never had any training?
  • Are you evaluating SAP PowerDesigner?

– then –

This session is for you!

Join the author of Data Modelling Made Simple with PowerDesigner, and learn the Fundamental techniques you need to get the best out of SAP PowerDesigner.

The program hasn’t been announced yet, so watch the conference web site for announcements.



#PowerDesigner adds support for Amazon #Redshift

Late last year, SAP issued Service Pack 5 for PowerDesigner 16.6. From the list of new features, it’s obvious that SAP are putting a lot of focus on the web-editing capabilities of the tool. In this service pack, there are changes that affect process modellers, enterprise architects, requirements modellers, and data architects. I shan’t list them all here – see the note below for details of how to access them yourself.

I’m going to focus on what matters to data architects – the new support for Amazon Redshift. SAP have done the usual excellent job of enhancing the underlying database support in the Physical Data Model (PDM) in order to handle this DBMS. For example, they’ve added a new type of object, “External Schema”, and extended the properties available for Tables, Columns, Views, and Users. The latter includes recognising Schemas as a Stereotype of User.

For example, here’s the new ‘general’ tab for a column – I’ve highlighted some of the new properties for you.

Redshift column

To find out more about these new features, follow these two simple steps:

·        Search for PowerDesigner stuff on –

·        click on the “New Features Summary” link


click here for more

Thanks to everybody who visited my blog in 2017 – you came from 108 different countries #PowerDesigner #datamodeling #datamodelling

Blog visitors 2017

#PowerDesigner and #ERStudio pages – all completely refressshhhed on my blog – details of all training courses now available, and more on the way

I’ve finally updated my blog with more information about the services provided for both SAP PowerDesigner and Idera ER/Studio – click here for more

Work smarter with #PowerDesigner – How to display a ‘Relationships’ tab for entities

Data modelling tools vary in the kinds of dependencies that you can create between objects. For example, they all recognise that entities in a Conceptual or Logical Data Model (CDM or LDM) can participate in Relationships – when you view or edit the properties of an entity most (perhaps all) tools will show you a list of relationships as part of the dialogue. They might also show you other dependencies, such as a list of diagrams the entity appears on, a list of related tables in Physical Data Models, or some Data Lineage or other mappings. With most tools, that’s the limit. PowerDesigner goes beyond these basic modelling and development connections, allowing you to create several other different types of dependencies:

  • shortcuts – the entity is used in another model, but cannot be amended
  • replications – the entity is used in another model, and can be amended, subject to limitations
  • traceability links – the entity can be connected to virtually anything else in any type of model, if it makes sense to you
  • related diagrams – the entity can be connected to a diagram in any type of model, if it makes sense to you
  • extended collections – using a model extension, you can create your own links between entities and other objects

One side-effect of this power and flexibility is the impact on the entity properties dialogue – most of these dependencies are all shown on the same tab. In the example below, the Contribution entity participates in four relationships, listed on a sub-tab; I can see that the entity also appears on at least one Diagram (indicated by the presence of the Diagrams sub-tab). There could be more tabs, if the entity has other types of dependencies.


If you’re used to other data modelling tools, you might prefer to see relationships listed in a tab of their own. Well, with a little work, you can add that tab for yourself; you just need a simple model extension.

You create or use Model Extensions to change the way that PowerDesigner works, usually by adding additional metadata, or additional features such as imports, exports, and new object properties. In this example, we’re not adding a new feature, merely exposing some metadata – the Relationships collection – that already exists.

You may already have one or more extensions attached to your model, such as the Excel Import extension, but I’ll assume that you don’t.

  • On the Model menu, select Extensions
  • Create a new entry in the list – just type the name – then click on OKadd extension
  • The new extension will appear in the Browser

extension in Browser

  • Double-click the extension to open it, then right-click Profile, and add the Entity metaclass to the extension


  • Add a new Form to the metaclass, call it Relationships

add form

  • Add the Relationships collection to the Form, then close the extension editor
  • Here’s the new tab

the new tab

It’s possible to add more than one collection to a Form, plus lots of other things; I’ll cover these in future tips.