SAP PowerDesigner is a great data modelling tool with features that differentiate it from the rest of the market, increasing the productivity of data modellers.
The CDM LDM Productivitymodel extension from Metadata Matters improves the productivity of data modellers still further, helping them to visualise, manage and validate their models, concentrating on making modelling decisions, and spending less time on routine tasks.
Attach the CDM LDM Productivitymodel extension to any Conceptual or Logical Data Model and start using the new features right away. Better still, deploy the extension via the PowerDesigner Repository and have it attach itself to every new Conceptual or Logical Data Model automatically—updates to the extension will automatically be made available to every model that it’s attached to.
The CDM LDM Productivity model extension extends model validation and adds extra options to contextual menus. For example, here are the new options in the contextual menu for an Entity:
Metadata Matters will work with you to customise the extension to meet your own unique requirements – the cost of the extension includes a day of customisation effort.
Here’s a summary of the capabilities provided:
Completeness of Diagrams
How much time do you spend examining a diagram only to discover that something vital is missing? Eliminate the doubt – – for a given Entity, select from lists of linked objects to add to your diagram – add all child Entities for an Inheritance
Which Entity (or Entities – there may be more than one) is the ‘Ultimate Parent’ of a sub-type in a deep Inheritance hierarchy? The answer may surprise you, and we know that modellers do not like surprises.
Entity Hierarchy Diagrams
Create and refresh a diagram that guarantees to show you the full structure of all the Inheritance hierarchies that an Entity participates in. Here’s a simple example:
Here’s a much bigger example, for an Entity that participates in two hierarchies:
Entity Proximity Diagrams
Create and refresh a diagram that guarantees to show you everything linked to an Entity.
Save thinking and working time by automatically moving ‘Primary Identifier’ Attributes to the top of the list and moving the Primary Identifier of an Entity to the top of the list of Identifiers. Ensure that Entity Attributes or Data Items with the <undefined> data type are linked to the default domain.
Applying Naming Standards
Construct meaningful and useful names for Relationships, Identifiers and Inheritances.
Extend the built-in model validation with new custom model checks, helping you to: * apply your modelling and naming standards * check for double-spaces in object names * check Relationship role names * be aware of multiple parent Entities or alternate Identifiers
Hiding and Showing Migrated Attributes
If you chose to work with the Logical Data Model but you would like your diagrams to look more like diagrams in the Conceptual Data Model you can – by hiding selected classes of Attributes. Changed your mind? You can always show them again.
Specify the required type of layout and orientation for every diagram and apply it when you want to.
Hiding and Showing Diagram Content
Show or Hide Link Symbols. Remove graphical synonyms or shortcut symbols from a diagram.
Straighten a link symbol by removing all the corners. A simplified way of changing page size and orientation.
If you’re using Packages in your models, you’ll be aware of the potential pitfalls and how much work there can be if you change your mind about the Package structure. The extension provides two useful features: * Safely remove a Package from the hierarchy without losing content * Check if a Relationship and the child Entity have the same owner
Managing Text Properties
Replace an object Comment with the Description or vice versa.
Output the Display Preferences to the Output window.
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, Replications, Traceability Links, Related Diagrams, Extended Collections (extensions to the out-of-the-box capabilities)
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 sub-tabs, if the entity has other types of dependencies.
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 that already exists – the Relationships collection.
Here’s what you need to do:
On the Model menu, select Extensions
Create a new entry in the list – just type the name – then click on OK
The new extension will appear in the 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 the Relationships collection to the Form, then close the extension editor
Here’s the new tab
I’ve used this technique in other places as well, such as adding a Sub-Requirements tab to Requirements in a Requirements Model.
If you want to improve your productivity even more (and who doesn’t want to do that?), a more comprehensive model extension will be available soon for the CDM and LDM. This will include the “Ultimate Parents” capabilities, plus features to help you with
diagram content and page layout, including
set page size and orientation
add all possible objects
add things linked to an entity
add all inheritance links for an inheritance
removing Packages cleanly
showing and hiding foreign key or inherited attributes
In my first post and second post on the topic of Entity Inheritance hierarchies I showed ways in which the customisation features of PowerDesigner are useful when dealing with them.
If managing complex hierarchies is one of your modelling concerns (for example, if you’re using the FIBO CDM or LDM), help is at hand. A model extension is available from Metadata Matters that provides a set of useful new properties (known in PowerDesigner as Extended Attributes) to help you manage your hierarchies, as well as the menu options to ensure that they stay up to date.
Here’s part of an inheritance hierarchy in the FIBO Conceptual Data Model (thanks to Jurgen Ziemer for allowing me to use the model for illustration). Let’s focus on the entity Deposit Account:
The Deposit Account entity in context
The model extension provides a new Parentage tab that provides information about how an entity fits into inheritance hierarchies. Deposit Account has two parents and two grandparents – notice that one of the parents (and the hierarchy above it) are not visible on my diagram:
Presenting information about the parentage of Deposit Account in a custom form
Most of the information on this form is up-to-date and reliable, because it’s computed every time it’s viewed; only the Ultimate Parents property has to be manually refreshed (because of the potential processing overhead from automatically refreshing it every time it is displayed, which could be noticeable in a model with many entities and many inheritance levels).
Everything on this form (apart from the list of parent entities) is available in a List Report. Here’s a fragment of a List Report that has been filtered to only include entities whose name ends with “Account”:
The extension provides menu options to:
refresh a single entity
refresh an entity and all its dependent entities
refresh every parent and child entity in the model
in the FIBO CDM it takes about 30 seconds to update this information for over 1000 entities and 406 inheritances
For example, the contextual menu for the model now includes an option to refresh the list of Ultimate Parent entities for every parent and child entity in the model
You can access this menu by right-clicking the model in the Browser or right-clicking a diagram background.
In last week’s post I discussed Entity Inheritance hierarchies, and showed two ways in which the customisation features of PowerDesigner are useful when dealing with them.
I did get some feedback on the sample model I used, and was also challenged to actually list the multiple “Ultimate Parents”. I rose to the challenge, and this posting is the result.
Remember that PowerDesigner allows an entity in Conceptual and Logical Data Models to be a child of more than one hierarchy. As I said last time, I’m not a database specialist so I take advice from other people, and I’ve been told that this multiple inheritance needs to be avoided when designing a relational database, so please don’t shout at me.
This time I’m avoiding a quasi-real-world model, and using a simple set of multiple hierarchies. They’re shown left-to-right here to help me illustrate what’s happening.
Complex multiple inheritance
It has three levels, and multiple inheritance – the entity Child has three parents, and 3 GrandParents. Parent 2 also has three parents. This situation could be intentional or unintentional (perhaps several modellers are working on their own parts of the model, or models have been merged together).
My model extension provides information about how an entity fits into inheritance hierarchies. I’ve amended the form since last week – this is the entity that has three parents and three grandparents (notice that Parent 3 is also an Ultimate Parent):
Presenting information about an entity’s parentage in a custom form
All of the information on this form is up-to-date and reliable, because it’s computed every time it’s viewed. The script to create the list of parent entities is simple – PowerDesigner already provides me with a collection of “SuperEntities”, so I don’t need to derive it from the inheritances. Just 12 lines of code are needed to create the list of parent names (if I wanted to sort them, that would take a few more).
Building a list of Parent Entities is simple
The script to create a list of Ultimate Parents is not quite as simple – I have to examine every Parent entity all the way to the top of all the hierarchies to create my list, then make sure I don’t have any duplicate entries. Remember that multiple inheritance could be introduced anywhere in the chain of entities, so I can’t make any assumptions. The total script is about 60 lines of VBScript; here’s the section that handles the simple situation where an entity has one parent entity that does not have a parent (and is therefore also the ‘Ultimate’ parent):
Notice the recursion here – we have to getUltimateParent for every parent entity we encounter
In a large model with a lot of inheritances (the FIBO LDM I downloaded yesterday has 406 of them, some of them 12 levels deep), the processing overhead of working out the list of ultimate parents every time you look at an entity is too much.
Here’s a different approach – it uses the same script to create the list of Ultimate Parents, but it’s run on-demand, by clicking the ‘Refresh’ button to the left of the list:
There we have it, two different ways of running the same script, both of them through the standard user interface.
Okay, it’s time to add a third way of running that script, via a menu. If I right-click an entity in the object browser, I can refresh the list of ultimate parents without even opening the entity properties:
Entity Inheritance hierarchies are an essential tool for anyone working on Logical Data Models. In this post I’m going to show two ways in which the customisation features of PowerDesigner are useful when dealing with Inheritance Hierarchies.
1. With a complex inheritance hierarchy (I’ve seen them go 5 or 6 levels deep) it can sometimes be tricky to keep track of the entity that is the “Ultimate Parent”, the entity at the top of the inheritance tree.
2. In Conceptual and Logical Data Models, PowerDesigner allows an entity to be a child of more than one hierarchy. I’m not a database specialist so I take advice from other people, and I’ve been told that this multiple inheritance needs to be avoided when designing a relational database, so I may want to make it obvious to modellers when they create something we can’t implement.
For example, here’s an inheritance hierarchy for the Country entity.
It has three levels, and multiple inheritance – the entity Country with 1 Border has two parents, Landlocked Country and Whole-Island Country. My modelling standards don’t allow me to create multiple inheritance in the LDM, but the tool doesn’t stop me from doing so; I probably wouldn’t want to stop modellers from doing this, but I would like to flag it when it does happen, so we can fix the model for them.
I’ve built a model extension for the PowerDesigner LDM that provides information to the modeller about how an entity fits into inheritance hierarchies. Here’s an example for an entity that has a single parent:
The entity is at level three in the hierarchy, and the ultimate parent is the entity at the top of the tree (Country is at level 1). The form shows three new properties that have been added in the extension:
The level within the inheritance hierarchy
A Boolean property, set to TRUE if the entity has more than one parent
The name of the ultimate parent entity
The inheritance link that links the entity to its parent
The form also shows the list of parent entities, which is available as standard but not normally displayed on a form.
Here’s the same form for the entity that has more than one parent:
We cannot determine the Ultimate Parent, so that has been set to << Multiple >>.
It’s fine presenting this information to the modeller in this form, but what if the model is large and complicated, and you don’t want to rely on just your eyeballs to detect issues? The model extension also includes a couple of custom model checks for Entities; it reports an error if an entity has multiple parents, or if it has multiple child inheritances.
Here are the results for our simple model of countries:
The model extension required to provide these features is not large or complex and contains around 40 lines of VBScript (most of that is used to discover the Ultimate Parent entity).
Here’s an outline of the extension:
This shows the script used to set the level number – the value is set to “1” if the entity does not have a parent, or to the level number of the parent, plus 1.