Design Layers Have Changed in erwin r8 and beyond

For those of you who already use design layers, you might want to take note. For those who have never needed to use them in the past, perhaps now is the time to start.

First of all, let me start by explaining what design layers are.

Design layers were introduced in version 4.0 of ERwin Data Modeler, to allow you to create separate logical, physical and combined (classic) models while also allowing you to keep them synchronised. As well as giving you the option of creating stand-alone logical-only and physical-only models, v4 introduced capabilities to split, link and derive models, creating a “map” between objects in the linked models and to be able to synchronise changes across layers using this map.

Another important part of the Design Layer approach was the facility to create Transforms. A wizard allowed you to perform certain common design transformations, such as many-to-many resolution, generalisation hierarchy implementation and column denormalisation, and keep a record of what the source and target objects were, in a new “Transform” object.

Version 7 introduced extra transform functionality, including the ability to see the source objects in the logical view and target objects in the physical view of a combined model.

The Transform object does not exist in r8 and beyond.

The transformation wizard still lets you transform the same set of structures, but the transform object with its mapping between source and target objects is not created. This means that the features that relied on this object, such as reversing the transform, or showing different states in the logical and physical views, are no longer available.

You need to decide what to do with your existing r7 models if they contain transforms. You will be faced with a decision when opening the model in r8 and beyond as to what state you want to see them in, either source or target, or whatever the current state happens to be.

For combined models, my recommendation is that you upgrade the model twice: once preserving the source state; and then again preserving the target state. I would then discard the physical side of the model in source state and use this as your stand-alone logical model (using split L/P). I would, however, retain both parts of the target-state model. You can then add the stand-alone logical model as a model source to the target model. Unfortunately, you will not be able to fully map transform source objects.

The reason for retaining both logical and physical sides of the target model (and this is something that those already using separate logical and physical models should take note of), is that you now get no choice in how you transform logical-only structures (i.e. those that cannot exist in the physical model, namely m:n relationships and generalisation hierarchies) when deriving a physical model from a logical one. The default transformation is applied, and there is no way of changing this in the physical model, as no source objects are visible to transform.

If you derive a combined logical/physical model from a logical model, you can decide how to transform these structures in the logical side of the model. This is still, however, a once-only change.

In short, then, if you currently rely on a single combined model to show both source and target objects of a transform, consider using separate models to do this at r8 and beyond. If you currently do this, but use physical-only models as your target, consider making your target models combined logical/physical.