Export erwin to xml - caveats

Question

We're using Erwin 7.x to model our database. The process becomes very painful when we need to work on multiple versions of it - erwin format is binary and not automatically mergeable.

So, what I did is I exported the model to an XML file, cleaned it using XSLT. It all looked good till I found a problem with relationships - historically, we do not name our relationships and leave that to erwin, so the names are R_1, R_2, and so on. After opening an XML erwin starts producing duplicate relationship names.

The solution is to assign names ourselves which is fine and should have been done in the first place. The problem now is that we don't have any trust that there won't be more caveats later.

Now to the question: has anybody tried working with erwin through XML exclusively for a considerable amount of time?

Answer 1

I have done extensive erwin to XML work and I don't recommend trying to tweak the XML export for the following reasons:

• Doing so requires that you be extremely familiar with the ERwin Meta-model.
• The Meta-model changes from one release to the next. So when you move off of version 7 you will have to redo your work.
• The XML produced by the export is not an XSD and therefore not an XML equivalent. Rather then being a description of the data it is an XML description of the ERwin model.

I could fill pages with addition reasons, the up shot is that tweaking exported xml is not a good idea. If you must produce an XML representation of either the data or the ERwin model, use the ERwin API to move information in and out of the ERwin model.

The original issue seems to be one of version management of models. How to track changes between different versions of the same model and how to identify the differences.

There are a number of different ways this can be done:

• Use ModelMart (I guess they call it model manager now). This is a repository toll offered by CA. It provides the ability to track versions of a model, take snapshots and compare differences, rollback to a different version, see who make what changes to the model and provides repository wide reporting capability. It is fully integrated with ERwin. However the license is not cheap.
• Use one of the excellent open source management tools out there (SubVersion or Git for example) to maintain version of the physical ERwin file. One can track versions, use the complete compare function of ERwin (check out 2 different versions to two different files). These tools are not Integrated with ERwin so commits have to be done manually leading to a possibility of error (uncommitted changes).
• Manually maintain versions. This provides the same type of capability as above but is even more prone to error then the above as is is awful easy to forget to do a 'save as' instead of a save.

I hope this helps and good luck

Answer 2

I have not tried editing/cleansing the Erwin generated XML. But, this is how we do it in our organisation : If there is a Erwin (Logical/Physical) model (v1) and it's corresponding physical database is out of sync then we create another copy of Erwin model (v2) by reverse engineering the physical database then we leverage "Complete Compare" option in Erwin tool to compare and sync-up the v2 changes over to v1. Hope this helps.

Answer 3

I have been using XML approach for a year now and found no issues. I just need to give unique names to new relationships.

We are not going to upgrade ERWIN for that project so there is no a time bomb here.