The chinwags have been running for a few weeks now, and we’ve discussed some interesting topics. So far, we’ve just talked about what’s on somebody’s mind at the time, there hasn’t been an agenda of any kind. I’d like at least some of the sessions to be more structured, and I’d like to involve people on the opposite side of the world to me (I’m in the UK), so I have two questions for you:
would you be interested in joining a chinwag at 20:00 or 21:00 GMT on Tuesdays?
what topics would you like to discuss with your fellow PowerDesigner users?
Topics can be anything you like, such as:
basic usage of the tool – the tool has a lot of features, not all of them very obvious to new users
support for SAP platforms or cloud databases
scripting and customisation
If you’re an expert on a topic and you’d like to volunteer to talk about it, don’t hold back :).
If we need an expert on any particular topic I’ll find one.
One of the key IT systems for any insurance broker will be the Quotations system, where they record details of all of the insurance companies they represent, the types of risk they might cover, all their customers, all the risks the customers would like to have covered, all the possible questions they could ask them to assess risk, all the answers they received, and the resulting quotes. In a commercial insurance broker, those quotations could be very large and complicated.
About 15 years ago, one such insurance broker’s quotations database had been designed to handle any product, any type of client, and any risk they might want to cover, without requiring any structural changes to the database or much change to the user interface. It was what we call a ‘metadata-driven’ database.
This was good for the business because they focused their attention on defining their requirements, and it was good for some of the developers because all they had to do was turn those requirements into data to store in tables – there were a lot of code tables, “question” tables, and “answer” tables. This knowledge was good for job retention.
However, the database design was not good for anybody who had to get data out of the database, perhaps to print out a quotation – to extract the right data you had to look up all sorts of code values to find the right words to use for labels, and the right data to extract.
So, they decided to extract the data from that database into another database that would make it easier for someone to look at or report on the data. Their data modelling tool was PowerDesigner (then owned by Sybase). For the nerds among you it was version 11 – SAP have recently issued version 16.7; under the numbering system Sybase used we’d probably be up to 26 or so.
Modelling and building the new database was not the biggest concern they had, their biggest headache was describing how to convert the quotations data into the new format in such a way that the developers could build it and the testers could test it. They also need to be able to migrate some of that data to their Policy Management system, and develop messages for their messaging infrastructure but I won’t talk about that, this tale is long enough already.
One day, the project team were surprised to see the head of the company’s Information Architecture team, who most of them knew at least by sight, come into their office and sit down at a PC in the corner. He sat there for two weeks beavering away on, well, something. Nobody would tell the project team what he was doing, so they assumed it was something hush-hush that needed to be done away from the rest of his team. All very mysterious 😊.
At the end of the two weeks, the outcome of his sweat and toil was revealed – it was an Access database. Please, don’t groan, especially if you can guess what’s coming next.
The Access database was, admittedly, an amazing thing – it was designed to hold the Physical Data Model of the Quotations database, as well as the Conceptual Data Model representing the business data, the Physical Data Model for the new database, and the links between those models. It could import the data models initially, but all modelling changes had to be entered manually. The database generated the specifications to tell the developers the rules for moving the data between the two databases.
Applying the changes was a bit tedious, as the team had to make the model changes in PowerDesigner first, then make them again in the Access database, and there was nothing visual about that database, no ERDs to look at, just lots of metadata. The modelling work was slowed down considerably.
I can hear your thoughts already, you’re wondering “What’s the point of this long ramble, is it another dig at Access databases?”.
I’ll leave you to figure that one for yourself, just let me tell you one interesting fact.
PowerDesigner version 11 already supported everything the Access database did – nobody had investigated the capabilities of their existing tool.
In these days of lockdown and working from home, the feeling of isolation from your peers can be considerable. Well, you’re not alone – join George McGeachie (@MetadataJunkie) for the new, regular, chinwag sessions.
The PowerDesigner chinwag sessions are your opportunity to discuss any topic related to SAP PowerDesigner. There are two one-hour sessions each week and you can participate as often as you want to. Join us for 10 minutes or stay for the full hour.
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.
One of the features that really differentiates SAP PowerDesigner from the competition is the “Generation Template Language” (GTL) which uses a series of templates to create textual content from the content of your models. I’ve used it in the past to generate JSON or CSV output from a model, and to create simple model documentation (which could be included in a standard PowerDesigner report).
Here are a couple of examples for you
In every other data modelling tool I’ve worked with, I would have to use whatever scripting language is supported (usually some form of Basic), and write a script to generate the output. This can be horrendous to figure out.
Frankly, using GTL in PowerDesigner is really straightforward. The image below shows everything needed to create the “Entity Statistics” shown in the first example.
The GTL is colour-coded
the black text is text to be output (some it is formatting instructions, like starting a new line or inserting a tab)
the purple/lilac text is processing logic – in this case it outputs certain information only if the model notation is “Barker”
the green text is a comment
the blue text is where the real work happens – it outputs information from the model; in this example it tells you how many things there are in a collection, such as the collection of relationships linked to an Entity
The logic is critical
Knowledge of the underlying metamodel is critical for creating effective GTL – this can be affected by factors such as the model notation in use, especially if the model is in Barker notation.
Please get in touch if you would like to talk about generating content from your PowerDesigner model.