PowerDesigner

SAP PowerDesigner has been around for several decades and used to be a quite popular data modeling.  Many companies have recognized the large breadth of targets supported by Hackolade Studio and its modernization of the data modeling processes and techniques.  

 

Hackolade Studio facilitates the migration of PowerDesigner models by letting you read directly PowerDesigner files instead of the more cumbersome previous method which required to first export into an XSD format before importing into Hackolade Studio.

 

Differences with PowerDesigner

There are many differences between Hackolade Studio and PowerDesigner.  We do not use or even have a copy of that software.  Hackolade's ambition is certainly not to copy PowerDesigner, ... to the contrary!  It should be expected, since Hackolade Studio is a different tool than PowerDesigner, that some things would work differently, that we would name some things differently, that features we have don’t exist in PowerDesigner, and vice versa. 

 

Here are some examples, but there are many, many more…

• PowerDesigner uses the term "subject area" to divide model diagrams into logical sections and “package” to act as containers for objects.  We have “Diagram Views”.  The purpose may be somewhat similar.  Terminology, and how they function may be different

 

• PowerDesigner uses the term "domain", a term interpreted differently by different people, for sure to describe something quite different than what we describe as a re-usable object definition or user-defined type

 

• When creating foreign key relationships in PowerDesigner, the convention is that you drag from the attribute PK in the parent entity towards the child entity.  The attribute is automatically created in the child entity and the FK relationship is also created.  Hackolade Studio also supports this approach, but it is not the default behavior.  To change the default to be like PowerDesigner, simply change the parameter "FK relationships drag-n-drop behavior" in Tools > Options > General to become "from parent to child".

 

• PowerDesigner has a complex model comparison approach.  With the architecture of Hackolade Studio, models are in JSON format and are stored in Git repositories where versioning is automatic, and each commit and push results in an immutable version of the model.  As a result, a compare and merge operation in Hackolade Studio always results in a "third" model, instead of an alteration of existing model versions.  Note also that it is possible to compare two arbitrary commits.  Whatever the way PowerDesigner compares models, for sure, Hackolade Studio's equivalent feature will work completely differently.

 

• PowerDesigner allows to open multiple models in the same application instance.  The architecture of Hackolade Studio being different, we allow to start multiple instances of the application, each with a single model.  This is actually quite handy, as it allows to alt-tab to toggle between different models.  As indicated in our Tips and Tricks, you may start multiple instances of Hackolade Studio on the same machine session, so as to work on multiple models simultaneously.  You may also merge 2 Hackolade models, or combine elements from another model with copy/paste from one model in one application instance, to the other model in the second application instance.  From within the application, this is easily done with the shortcut Ctrl+Shift+I (on Mac Cmd+Shift+I) or with the menu option File > Start New Application Instance.  Or from the operating system, on Windows, right-click on the Hackolade icon in the toolbar then choose Hackolade...

 

• PowerDesigner has a fairly rigid storage structure in its central repository structure.   The architecture of our solution is very different from PowerDesigner’s.  While PowerDesigner model files in XML format, they are stored in the repository in a structured database.  Our files are open in JSON format, and each file represents a single model.  Models can be stored in one or more Git repositories, possibly even across multiple repository providers.  Models can be organized in a more flexible modular approach, as described here.  With our modular architecture, it is possible for a physical model to be derived from 1 or more (subsets of) polyglot models.  It is also possible for any model to reference any part of any model, no matter the target on each side.
  
  Legacy tools have been using the traditional concept of “logical” models, which is too constraining for the needs of non-RDBMS targets supported by Hackolade Studio.   Hackolade had to invent the principles of Polyglot Data Modeling to support the needs of NoSQL, Avro, Parquet, REST APIs, etc…  We name it Polyglot, as opposed to logical, to avoid any semantic confusion or discussion.  But our Polyglot models are logical in the sense that they are technology-agnostic, and they can be fully normalized.   But they can be much more than strict logical models in the sense that they can optionally support nested objects, polymorphism, and denormalization. 
  
  Polyglot models can be purely "logical", in the traditional sense.  But they can also be more of a "common physical model", including technical names or views that would be common across different physical targets.  No dogma with Hackolade: you can be as rigorous in applying data modeling theory as you wish, or less rigorous in order to adhere to the reality of your organization.
  
  Physical data models can be derived from polyglot models.  It is also possible to start from a physical data model (either from scratch or created from the reverse-engineering of an instance) and convert it to a polyglot model.
  
  Once a target model is linked to one or more polyglot models, any change in the polyglot model can be reviewed through an Impact Analysis screen to decide whether to include the changes, globally or individually.
  
  Polyglot models can be derived from (subsets of) other polyglot model(s), as described here.  In the end, it is possible to create a graph of models.
   
• In PowerDesigner when creating a physical model from a logical model, the physical model is "generated" (or "derived") from the logical model in a "push" process.  In Hackolade Studio, the process is different, partly due to the fact that Hackolade Studio supports so many targets that are different than RDBMS.  And also because in Hackolade Studio, it is possible to build an N-to-N graph of data models, where for example a model draws from more than one polyglot model.  As a result in Hackolade Studio, the process follows a "pull" mechanism: you would first create a physical model for the target of our choice, then "derive" from the selected polyglot model or models.

 

Given the above, it should be expected that there is some learning curve to our tool.  You will most likely avoid frustration if you don't assume, because you're a veteran user of PowerDesigner, that you can use Hackolade Studio without learning about it.  This learning curve can be greatly reduced by investing a little bit of time in reading or searching inside our online documentation, going through tutorials and how-to guides, and by watching some of the videos on our eLearning platform.

 

 

PowerDesigner conceptual models stored in .cdm files

Starting with v8.1.1

 

Depending on the language used with PowerDesigner, the file extension could also be .cdb, .mcd, mcb, etc.  The extension is not really important as long as the content is a PowerDesigner-generated XML file including

- tags starting with "o:" refer to an "object"

- tags starting with "a:" refer to an attribute/properties of the object "o:"

- tags starting with "c:" refer to a list of "objects" linked to the object "o:"

 

It is natural to reverse-engineer or import a PowerDesigner logical model into a Hackolade Studio polyglot model, Hackolade Studio's equivalent of traditional conceptual (with graph view) logical models, only more flexible and powerful. 

 

Inside PowerDesigner files, the different objects are mapped to equivalent objects in a Hackolade Studio models, mainly: 

- entities; 

- attributes and their data types (with length, precision, and scale where applicable), business and technical names, comments and descriptions; 

- constraints: required or not null, unique keys, (composite) primary keys, and relationships with their cardinality.

 

Some transformations occur, and extraneous information is ignored.  We also import: 

- ArchitectureAreas, and map them to containers, 

- Inheritance, and map them to our supertypes and subtypes; 

- ConceptualDiagrams, and map them to our Diagram Views;  

- Shortcuts, and map them to references to their respective entities,

- Packages, and map them to our Diagram Views,

- ExtendedAttributes, and map them to our custom properties,

- and DataItems mapped to attributes.

 

To import a PowerDesigner logical model from the GUI application, you must first create a Polyglot data model.  Ideally the polyglot model should be empty.  But it does not have to be if, for example, you are merging 2 or more PowerDesigner files into a single Hackolade Studio model.

 

Then go to Tools > Reverse-Engineer > PowerDesigner, and select the PowserDesigner file you wish to import:

 

 

PowerDesigner logical data models stored in .ldm files

Depending on the language used with PowerDesigner, the file extension could also be .ldb, .mld, mlb, etc.  The extension is not really important as long as the content is a PowerDesigner-generated XML file including

- tags starting with "o:" refer to an "object"

- tags starting with "a:" refer to an attribute/properties of the object "o:"

- tags starting with "c:" refer to a list of "objects" linked to the object "o:"

 

It is natural to reverse-engineer or import a PowerDesigner logical model into a Hackolade Studio polyglot model, Hackolade Studio's equivalent of traditional logical models, only more flexible and powerful. 

 

Inside PowerDesigner files, the different objects are mapped to equivalent objects in a Hackolade Studio models, mainly: 

- entities; 

- attributes and their data types (with length, precision, and scale where applicable), business and technical names, comments and descriptions; 

- constraints: required or not null, unique keys, (composite) primary keys, foreign key relationships and their cardinality;

- views.

 

Some transformations occur, and extraneous information is ignored.  We also import: 

- ArchitectureAreas, and map them to containers, 

- Inheritance, and map them to our supertypes and subtypes; 

- LogicalDiagrams, and map them to our Diagram Views;  

- Shortcuts, and map them to references to their respective entities,

- Packages, and map them to our Diagram Views,

- and most importantly we also import ExtendedAttributes, and map them to our custom properties.

 

To import a PowerDesigner logical model from the GUI application, you must first create a Polyglot data model.  Ideally the polyglot model should be empty.  But it does not have to be if, for example, you are merging 2 or more PowerDesigner files into a single Hackolade Studio model.

 

Then go to Tools > Reverse-Engineer > PowerDesigner, and select the PowserDesigner file you wish to import:

 

PowerDesigner physical data models stored in .pdm files

Starting with v7.9.10 for import into a polyglot model.  Starting from v8.0.0 for import into a target model

 

Depending on the language used with PowerDesigner, the file extension could also be .pdb, .mpd, mpb, etc.  The extension is not really important as long as the content is a PowerDesigner-generated XML file including

- tags starting with "o:" refer to an "object"

- tags starting with "a:" refer to an attribute/properties of the object "o:"

- tags starting with "c:" refer to a list of "objects" linked to the object "o:"

 

PowerDesigner physical models typically should be imported in into a Hackolade Studio of the corresponding target.  However, Hackolade Studio is also able to convert to another target while converting data types, on a best effort basis, provided that the targets are fairly compatible. If the process encounters an unrecognized data type, it is mapped to the default data type, and a list of concerned attributes is made available in the log.  If you think that we are not handling those correctly, please report it to support@hackolade.com so we can enhance the standard application, for the benefit of all users.

 

Inside PowerDesigner files, the different objects are mapped to equivalent objects in a Hackolade Studio models, mainly: 

- containers (corresponding to the concept of the target: databases, schemas, namespaces, buckets, keyspace, etc...);

- entities (tables, collections, etc...); 

- attributes (columns of fields) and their data types (with length, precision, and scale where applicable), business and technical names, comments and descriptions; 

- constraints: required or not null, unique keys, (composite) primary keys, foreign key relationships and their cardinality;

- views.

 

Some transformations occur, and extraneous information is ignored.  We also import: 

- ArchitectureAreas, and map them to containers, 

- Inheritance, and map them to our supertypes and subtypes; 

- LogicalDiagrams, and map them to our Diagram Views;  

- Shortcuts, and map them to references to their respective entities,

- Packages, and map them to our Diagram Views,

- Indexes, as long as there is a match between the source technology and the Hackolade Studio target model,

- database views,

- domains and Abstract Data Types,

- ExtendedAttributes, mapped them to our custom properties.

 

To import a PowerDesigner physical model from the GUI application, you must first create a data model for the target of your choice.  Ideally the target model should be empty.  But it does not have to be if, for example, you are merging 2 or more PowerDesigner files into a single Hackolade Studio model.

 

Then go to Tools > Reverse-Engineer > PowerDesigner, and select the PowserDesigner file you wish to import:

 

 

 

 

Known limitations

Currently, the following PowerDesigner features are not supported:

- XEM extension files

- links between models

- business rules

- support for BPMN, UML, export of XML, etc...

 

Bulk import

Using the Command-Line Interface, it is easy to orchestrate a batch import of selected PowerDesigner files into Hackolade Studio models, using the command revEngDiagram with its required and options arguments.  If you need to import multiple PowerDesigner files, you must repeat the command.