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.



Work smarter with #PowerDesigner – use a Dependency Matrix to assign Domains to Attributes

PowerDesigner’s dependency matrices are really powerful, and I don’t ever remember seeing anything similar in a data modelling tool. They allow me to visualise and even edit links between objects.

In a Conceptual, Logical, or Physical Data Model, or in a UML Object Model, Domains are a useful object, allowing you to manage the ways in which your data is represented. Take this simple data model, for instance.

1. initial model

I’ve reached the point where I need to assign a Domain to each attribute. I can edit each attribute one at a time, and select a Domain from the drop-down list, like this:

3, Assigning a Domain

In a large model, that could take some time. There are a couple of ways we could speed up the process:

  • edit multiple attributes at once using a list of attributes
  • use a Dependency Matrix

In this blog post, I’ll cover the second option. A Dependency Matrix is a model object, so  like any other model object there are several ways of creating one. The simplest way is to right-click the model name in the Browser, then select “New”, and “Dependency Matrix”. The first thing we have to do is choose the types of objects to display in the rows and columns.

4. Create matrix

I want to use this matrix for editing attributes, so I have to make sure that the rows contain Entity Attributes, and the columns contain Domains. The matrix cell will show the “Domain” property of the Entity Attribute. When I click on <OK>, the matrix is created, and appears in the Browser

4a. browser

Now I can double-click the matrix to show the content

5. Matrix Content - initial

Three attributes already have the domain assigned – two of those are foreign keys for Building.Building Name, so I only had to set one of them, PowerDesigner set the other two automatically. Now, if I click inside one of the cells, such as the intersection of Elephant.Elephant Name and Animal Name, I can assign the domain to the attribute with one press of the keyboard – I use the Spacebar.

6. instructions

Now all I have to do is use the cursor keys to move around the matrix, and press the Spacebar every time I want to assign a Domain. It doesn’t take long to finish them all. Here’s the final matrix:

7. Matrix Content - final

Here’s the model:

8. final

The toolbar allows me to use the matrix in flexible ways, such as choosing which attributes or domains to include, hiding ’empty’ or populated rows, and exporting to Excel. Press <F1> to find out more.

9. Toolbar