From erwin

Differences with Erwin

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

 

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

• Erwin uses the term “Subject Areas”.  We have “Diagram Views”.  The purpose may be somewhat similar.  Terminology, and how they function may be different

 

• Erwin 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

 

• Erwin seems to have a "complete compare" wizard.  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 Erwin compares models, for sure, Hackolade Studio's equivalent feature will work completely differently.

 

• Erwin 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...

 

• Erwin stores logical and physical in the same file.   The architecture of our solution is very different from Erwin’s.  Our model files are not binary in a proprietary format, but open in JSON format, and each file represents a single model.  We purposely avoid Erwin’s approach of logical/physical models in order to provide for 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.
  
  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.
  
  Note also that polyglot models can be derived from (subsets of) other polyglot model(s), as described here.

 

Given the above, it should be expected that there is a learning curve to our tool.  We suggest that you will avoid frustration if you don't assume, because you're a veteran user of Erwin DM, 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.

 

Export a data model from Erwin

Note: recently a customer migrating a large number of Erwin models to Hackolade reported that, in their opinion, an alternate approach lead to a better result than through XSD files: use Erwin to export the model to a PowerDesigner format, then import the resulting PDM file using these instructions .  We are not able here to judge ourselves, as each customer might use different features and store information differently.  We suggest to validate the imported model, as some customers reported that their Erwin models were not up-to-date with reality anyway...  This can be done for example by doing the reverse-engineering from the corresponding production database, then doing a compare & merge operation.

 

If you have data models in erwin and want to leverage them in Hackolade Studio, you need to fist export them to XSD, following the instructions below.  You should first consult this page for an overview of the import functionality in Hackolade Studio.

 

By default ERwin does not export primary key and foreign key constraints.  If the XSD does not contain this information, this reverse-engineering process cannot import them, but it is still possible to use the functionality to Infer PKs & FKs.

 

It is suggested to use the parameters below when exporting models to XSD, 

- if from a physical model:

 

- if from a logical model:

 

Import XSD into Hackolade Studio

After the successful export of your model to XSD, use the instructions in this page to import the XSD into a Hackolade Studio model for the target of your choice.

 

With logical models exported from erwin, spaces in object names are generally replaced with underscores.  When importing those models into a Hackolade Studio polyglot model, it might be desirable to restore object names to a regular business name.  To that effect, we provide the option to perform a case conversion upon import.  Proper Case or Title Case are likely candidates for this option.

 

If your erwin models contains Erwin "domains", it is preferable to "resolve references" so that the properties in the Hackolade Studio model remain editable (while being originally created with the properties of the Erwin domains.)

 

If you want to keep the Erwin domains as Hackolade Studio User-Defined Types/Model Definitions for future use, then you should do a double import:

1) first you reverse-engineer the XSD without resolving the references

2) then you reverse-engineer the XSD immediately again, this time with resolution of the references, and when presented with the conflict resolution screen, make sure to use the Replace option:

 

 

Export subject areas from erwin

For a given data model exported to XSD and imported into Hackolade Studio, you may also transfer the erwin subject areas to easily create the corresponding ERD Views (ERDVs) in the imported Hackolade Studio model.

 

The first step is to create in erwin a Subject Area report in CSV format, following the erwin Report Designer instructions.  For Subject Area Reports,  you should not include the <model> subject area which is the main ERD and was already imported via the XSD step.  

 

Important: since the model name is not included when you generate a Subject Area report, you must be careful and possibly use corresponding naming of the CSV file.

 

Import subject areas into Hackolade Studio

Like for all bulk operations in Hackolade Studio, this operation is performed via the Excel export and import capability.

 

The steps are as follows:

1) open in Hackolade Studio the data model previously imported from the XSD file

2) go to Tools > Forward-Engineer > Excel file... and choose the location for storing your Excel file

3) open in Excel the Subject Area Report.csv file.  It contains 2 columns and several rows, for example:

 

4) go to the ER Diagram Views tab of the Excel file for the model exported in step 2) and paste the 2 columns from the Subject Area report with the following mapping:

- "Subject Area Name" column of the Subject Area Report must copied and pasted into the "ERDV Name" column of the model Excel

- "Entity Name" column of the Subject Area Report must be copied and pasted into the "Entity Name" of the model Excel

 

5) save the Excel file

6) back in Hackolade Studio with the model file open, go to Tools > Reverse-Engineer > Excel Template... and select the model Excel saved in the previous step

 

Assuming that the Subject Area report matched the model file, the name matching of entities should work as expected and ERDVs will be created in the model:

 

 

 

Export User-Defined Properties

In Erwin, you can define custom properties and assign them to the different classes of model objects. These user-defined properties (UDPs) are properties that you create to document and notate the logical and physical object classes.  This is equivalent to our own Hackolade Studio custom properties.  When migrating your library of Erwin models to Hackolade Studio, it is of course critical to keep those UDP's accumulated with our models.

 

 

Unfortunately, the proprietary format of Erwin files complicates matters, plus the export to XSD does not include UDPs.  It is therefore necessary to proceed with some additional steps outlined below:

 

One-time setup in Hackolade Studio:

1) Create custom properties for the target or targets, following instructions in this how-to guide and video.  This should be done at the entity/table level and attribute/column/field level.  If you have many UDPs for each level, it may be useful to create a custom tab for your custom properties.

 

In Erwin: 

2) From the model file, generate the XSD according to the instructions above in this page.

3) Use the Report Designer to create a report including UDPs at the entity/table level and attribute/column level, then create the export for your model. 

 

In Hackolade Studio

4) Import the XSD into a Hackolade Studio data model.  Save it.

5) Generate the Excel export for your Hackolade data model, using these instructions.

 

In Excel:

6) The export will include empty Excel columns for each of the custom properties defined in step 1):

 

7) For each cell of the custom props columns that you wish to populate, you can create an XLOOKUP Excel function to find the appropriate cell value in the Excel generated from the Erwin model, for example:

 

=IF(XLOOKUP($B2,'[User Defined Property values.xlsx]Table Level UDP'!$C$3:$C$6,'[User Defined Property values.xlsx]Table Level UDP'!$K$3:$K$6)=0,"",XLOOKUP($B2,'[User Defined Property values.xlsx]Table Level UDP'!$C$3:$C$6,'[User Defined Property values.xlsx]Table Level UDP'!$K$3:$K$6))

 

Great care must be applied to ensure that the proper values are set in the right places.  The above can be customized and enhanced with additional logic.

 

8) Save the Excel file.

 

Back in Hackolade Studio:

9) Import the Excel file into the Hackolade Studio model, using these instructions.

10) Double-check that the result corresponds to your expectations.