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
symbol visibility
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
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.
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:
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.
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
Now I can double-click the matrix to show the content
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.
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:
Here’s the model:
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.
On Channel 4 in the UK last night, the Dispatches programme investigated some of the pricing practices of discount retailers and outlet stores. I’m not going to comment on the business ethics of those stores, but I do want to comment on their responses to the claims made by the programme. Some of the issues that arose could easily have been avoided.
Stores will often show the RRP (Recommended Retail Price) on a price ticket, to indicate to the customer the scale of the bargain they’re about to buy. For example, a product in TK Maxx was priced at £24.99, with a claimed RRP of £68.99; a significant saving, it appears. According to the programme, Government guidelines say “you should not use a recommended retail price if it differs significantly from the price at which the product is generally sold.” (Pricing Practices Guide, Department of Business Innovation & Skills, 1.6.1). The product in question, though it has what appears to be a fancy but unfamiliar brand name, is actually a TK Maxx brand, which is not sold by anyone else, so the RRP is actually meaningless and misleading. TK Maxx told the programme that it is their “policy not to put RRP on own brand products”; in the few instances where this hasn’t happened, it is “a product of human error.”
That’s the interesting part for me – how could they allow ‘human error’ to cause the RRP to be defined for own-brand products, and to be printed on tickets, in breach of their own stated policy? Where were the business rules that should have prevented this from happening? Where’s the data model that makes it obvious that own-brand products do not have a RRP? If they have a ‘target full retail price’ for own-brand products, that’s a different piece of data. Where’s the business process definition that describes how to print pricing tickets for own-brand products?
Perhaps the lack of all this is the ‘human error’ that TK Maxx referred to? If so, then they need to employ some humans to fix it, document their business rules, create their data models, and then implement them.
As the author of “Data Modeling Made Simple with PowerDesigner”, I am in a unique position to provide your organisation with the insights and knowledge you need to understand PowerDesigner, and how to make best use of it.
I can deliver off-the-shelf PowerDesigner training in the tool’s capabilities, as well as training geared towards data modellers and data architects, which can be tailored to suit your environment if you choose. If you need training geared towards other users of PowerDesigner, please contact me to discuss your needs.
Please click on “Tool Training/expertise” at the top of this page to find out more.
I followed a link on a Linked In discussion group today, to the home page of the Universal Data Element Framework (UDEF), which is “a framework for describing data to enable interoperability”. It’s a great place to work with if you want to kick-start data modelling efforts. See their list of definitions and properties at http://www.opengroup.org/udef/htm/en_defs.htm.
If you’re looking for a list of data classes for your attribute naming standards, their properties (amount, identifier, text, value etc.) probably cover everything you need.
