Comprehensive Analysis of Sybase PowerDesigner vs. CA ERwin

white paper

A Comprehensive Analysis of
Sybase® PowerDesigner® 16.0
InformationArchitect
vs.
CA ERwin Data Modeler r8.1
Standard Edition

Version 2.1

www.sybase.com

Table of Contents
1 Product Overviews
1 CA ERwin r8.1 Data Modeler
2 Sybase PowerDesigner 16.0
3 Data Modeling Activities
3 Overview
5 Types of Data Model
6 Design Layers
7 Managing the SAM-LDM Relationship
10 Forward and Reverse Engineering
10 Summary
10 Integrating Data Models with Requirements and Processes
11 Generating Object-oriented Models
11 Dependency Analysis
16 Model Comparisons and Merges
17 Update Flows
18 Required Features for a Data Modeling Tool
18 Core Modeling
26 Collaboration
29 Interfaces & Integration
39 Adding Value to Data Modeling
39 Managing Models as a Project
40 Dependency Matrices
41 Conclusions
41 Acknowledgements
41 Bibliography
41 About the Author

Introduction
Data modeling is more than just database design, because data doesn’t just exist in databases. Data does not
exist in isolation, it is created, managed and consumed by business processes, and those business processes are
implemented using a variety of applications and technologies. To truly understand and manage our data, and
the impact of changes to that data, we need to manage more than just models of data in databases. We need
support for different types of data models, and for managing the relationships between data and the rest of the
organization. When you need to manage a data center across the enterprise, integrating with a wider set of business
and technology activities is critical to success. For this reason, this review will use the InformationArchitect version
of Sybase PowerDesigner rather than their DataArchitect version. If all you need to do is create data models for
an individual database, it is recommended you seek the cheapest tool or one that suits your specific technical
deployment needs. However, when you are connecting data models to components of the broader architecture, I
encourage you to read on to understand how CA ERwin compares to PowerDesigner InformationArchitect.
In this review, I examine the capabilities provided by CA ERwin Data Modeler r8.1 Standard Edition, and Sybase
PowerDesigner 16.0 InformationArchitect, using the evaluation editions available on each company’s web site.
The PowerDesigner evaluation software provides the full capabilities, including a repository. The CA ERwin Data
Modeler evaluation provides a limited set of capabilities — the Standard edition, which does not include the
repository capability.

Product Overviews
Sybase PowerDesigner and CA ERwin Data Modeler are two of the market-leading data modeling tools available.
Both enable you to create different types of data models, and link those data models to each other. Both enable you
to reverse-engineer databases, to persist the design in a model, and generate changes to the database. Both tools
provide a drawing canvas, and a variety of editing facilities for use in expanding the detail of the model. They also
provide standard usability features such as undo/redo, and the ability to customize the style of your diagrams. They
both allow you to share the information held in your models via reports, though only one provides a web portal. They
both provide essential collaborative features such as a repository.
However, when you look more deeply into how these features are delivered, you’ll see that ERwin does not come
close to matching the breadth and depth of capability provided by PowerDesigner.

CA ERwin r8.1 Data Modeler
On their web site, CA describes ERwin Data Modeler as “an industry-leading data modeling solution that provides
a simple, visual interface to manage your complex data environment”. Before the release of r7, the predecessor to
r8, ERwin focused completely on the development of tightly-coupled pairs of logical and physical data models. Each
ERwin file can contain one logical data model, one physical data model, or one of each. A file that appears to contain
two models actually contains a single model with two views, logical and physical. In r7, ERwin introduced the concept
of design layers, a simple mechanism that gives hope to those of us who believe that the world of the data modeler is
more complex than just matched pairs of logical and physical data models. Look at the next section to find out more
about design layers in ERwin.

1

ERwin has several editions and additional components:
Data Modeler Core data modeling tool, providing logical and physical data modeling capabilities
Standard Edition
Data Modeler This combines the Data Modeler Standard Edition with a repository to support workgroup
Workgroup Edition collaboration and governance.
Metadata Integration An OEM feature built into ERwin, to convert to and from the formats used by other tools,
Wizard including most of their major competitors (including PowerDesigner)
Data Modeler A read-only version of the Workgroup Edition
Navigator Edition Separately licensed component
Data Modeler A free version of ERwin. The tool features are restricted, and the largest model it can
Community Edition manage is one with 25 entities/tables.
Data Modeler Verifies the structural integrity of data models or SQL/DDL code.
Validator Separately licensed component

In addition, CA can bundle ERwin Data Modeler with OEM products for extracting ERP metadata and for data
profiling. Both products are also available on the open market, and can integrate with other data modeling tools,
including PowerDesigner. To trial ERwin, just complete a form on the CA web site and the file will be downloaded.
The downloaded file is called ‘ERwin.exe’, so be careful if you’ve downloaded previous versions. The Model Validator
requires another registration and a separate download.
The evaluation license is valid for 14 days from the date of installation. Once the evaluation license has expired,
the evaluation version reverts to the Data Modeler Community Edition. If you do need temporary read-only access to
models, I suggest you download the trial version of the Data Modeler Navigator Edition of ERwin, which will give you
access for 14 days.
When my evaluation license expired, a UK reseller provided me with a one month extension.

Sybase PowerDesigner 16.0
Sybase PowerDesigner is a single tool, combining several standard modeling techniques (full lifecycle data
modeling, data movement modeling, business process modeling, enterprise architecture, and UML). PowerDesigner
provides a single working environment, underpinned by a flexible architecture and their industry-renowned Link and
Sync capabilities, the key to the comprehensive impact analysis capabilities of PowerDesigner.
Downloading and installing the evaluation version of PowerDesigner was simple, and I only had to register once
for all available components. If you want to avoid involving DBAs in creating and managing a repository database for
your evaluation, you can host the repository database locally, using a specially licensed (free) version of Sybase SQL
Anywhere. You can also install the PowerDesigner Web Portal locally, allowing you to quickly create a complete test
environment. Some organizations choose to continue using Sybase SQL Anywhere to host their production repository.
Once the evaluation license has expired, you may contact the Sybase sales department for extensions. You may also
register and download the freely distributable PowerDesigner Viewer software, for read-only access to any of your
models on the file system and/or in the repository you built.
PowerDesigner is available in several editions, illustrated in Figure 1.
Data Architect/DM Core data modeling tool, providing logical and physical data modeling capabilities, and the
dedicated XML model
Data Architect/RE The core data modeling capabilities, plus the collaborative capabilities made possible by the
repository, the web portal, and web-based authoring
InformationArchitect Extends Data Architect/RE to provide additional capabilities for managing information
architecture
Enterprise Architect Extends the InformationArchitect edition to provide additional capabilities for enterprise
architects

2

Figure 1. PowerDesigner editions

Data Modeling Activities

Overview
This section examines the support provided by each tool for the key activities involved in the creation and
management of a chain of data models. In a later section, I examine some of the key features a data modeling tool
must provide in order to make these activities efficient, effective and productive.
The chain of data models is illustrated in Figure 2, using a PowerDesigner Business Process Model. Each box in
Figure 2 represents a fundamental data modeling activity. The other icons represent inputs and outputs to and from
those activities, most of which are data models.
The overall flow of activities represents a top-down modeling approach, though I expect all data modeling tools
to provide bi-directional support for each flow, and possibly support flows I haven’t shown, such as generating a
Relational PDM directly from a Business Subject Area Model.
There are three types of data models in Figure 2:
• Subject Area Model — Represents a business need. It is a very broad view, containing only the basic and critical
concepts for a given scope. The Business Subject Area Model (BSAM) is a subject area model of a defined portion
of the business (not an application). There are other possible types of subject area models, but the modeling
principles are the same, so examining support for the BSAM will be sufficient.
• Logical Data Model — Represents a detailed business solution, capturing the business requirements without
complicating the model with implementation concerns such as software and hardware.
• Physical Data Model — Represents a detailed technical solution. It loses some of the exactness of the LDM, but
this loss usually comes with gains in performance and usability within a given hardware and software set.

In Figure 2, the <<stereotype>> notation identifies the type of PowerDesigner data model that would be created in
each case:
<<CDM>> Conceptual Data Model
<<LDM>> Logical Data Model
<<PDM>> Physical Data Model

3

Figure 2. Data modeling activities

ERwin and PowerDesigner both provide support for all of the activities shown in Figure 2. However the effort
required, the user experience, and the resulting impact analysis capabilities are dramatically different.

4

Summary Matrix of the Data Modeling Activities depicted in Figure 1
Task/Product ERwin PowerDesigner
Creation of a One tool is used to create three levels of One tool is used to create all three level of
multi-level data data models with ERwin’s Design Layer data model; each level is supported by a
architecture Architecture. Though they are not specifically separate and distinct purpose-designed type
clear, the steps you would take are: of data model.
• Create the SAM as a logical model, where The steps you would follow are:
you just ignore unwanted features, such as • Create the SAM in the CDM
keys and attributes (if you choose to) • Generate the LDM from the CDM
• Derive the logical model from the SAM, • Amend the LDM
in a new file
• Generate one or more PDMs from the LDM
• Amend the LDM
• Derive one or more PDMs from the LDM
See “Managing the SAM-LDM Relationship”
on page 7 for more.
Impact Analysis for Impact Analysis is fragmented. Each derived Impact and Lineage Analysis provides a
a multi-level data model has a reference to the model from continuous trail, from SAM to LDM to PDM(s),
architecture which it was derived, but this is the only which can be interrogated from any point, in
record of the derivation visible in ERwin. any direction. The ‘where used’ information
The ‘where used’ information for an entity for a SAM entity, for example, will show the
or table will not tell you anything about trail of dependencies through the LDM and
dependencies on other models. The real PDM(s), and any other associated models.
dependencies between model levels are Additionally, PowerDesigner provides a
invisible to the modeler, though they must function to create an updateable graphic
be recorded somewhere within the derived (i.e. model) which depicts the Impact and
model, as the synchronization process Lineage Analysis.
matches renamed objects. The dependencies between models can
be shown on a project diagram, an Impact
Analysis Diagram and/or via the Generation
Links function.

Types of Data Model
Based upon this overview of typical Data Modeling Activities, it is necessary to align and integrate business
analysis with technology implementations to fully model a complete system. Where data modeling is concerned, an
organization must create subject area models, logical data models and physical data models.
A Subject Area Model (SAM) is a “set of symbols and text representing the key concepts and rules binding these
key concepts for a specific business or application scope” (Hoberman, Data Modeling Made Simple, 2009). It is
commonly expressed in the form of an entity-relationship diagram; however it is purely data and relationships. It is
not relational — a SAM does not require foreign-key constraints.
A SAM helps us to capture, understand, and analyze the business needs of an organization, business area or
application from a data perspective. It is completely devoid of implementation details (data storage structures) or
software constraints. A key component of a SAM may be a set of elementary business data element definitions, which
may or may not have any eventual existence as modeled objects. PowerDesigner provides support for data elements
in the form of data items in the Conceptual Data Model (CDM). ERwin does not provide any support for data elements.
See “Support for Elementary Data Elements” on page 24 for more on this subject.
One or more SAMs may be created prior to developing the Logical Data Model (LDM) for a new application. A SAM
might also be created for an existing system where the technology needs to be verified with the business.
PowerDesigner’s CDM is designed for creating a SAM; ERwin can only support the SAM by ignoring capabilities in a
logical model, by pretending that a LDM is in fact a SAM.
A Logical Data Model (LDM) extends the concepts described in a SAM, describing a potential solution. The modeler
must be able to generate a LDM from the SAM. At first glance, the LDM is quite similar to the CDM in terms of the
objects it contains. However, a SAM is allowed to contain unanswered questions, such as those represented by many-
to-many relationships — these questions must be answered in a LDM. Entities must have primary and foreign keys,
and many-to-many relationships must be converted into entities.

5

The Physical Data Model (PDM) would typically be generated from the LDM. This model will be used to design the
schema of the database that will be used for the system. Entities become tables, attributes become table columns
and the relationships will be implemented in the database-specific structures (referential integrity, stored procedures).
When creating or generating a PDM, the specific database is chosen (Oracle 11i, Sybase ASE 15, Microsoft SQL Server
2008, PostgreSQL 8, etc). The PDM is frequently used to generate the data definition language (DDL) that will
allow for database creation or modification. It may also be used to create or update database schemas via a direct
database connection.
Again, the LDM and the PDM appear similar, but they meet different needs, and differ in terms of the detail
provided. The LDM is used to explore domain concepts with the business stakeholders; the PDM is used to create
and maintain the database. Multiple PDMs can be generated from a single LDM — this can be useful for database
migrations, the creation of production and development databases, or application migrations.
Both tools allow you to generate multiple PDMs from a single LDM, and maintain the links from LDM to PDM,
though there are limitations in ERwin that don’t affect users of PowerDesigner, which you can read about in
“Dependency Analysis” on page 11.

Design Layers
A modeling tool should provide the ability to model at any level, with generation to the other model levels or types.
All artifacts should be linked to their corresponding objects in the other models (for example, the entity “Customer” in
the SAM should be linked to the “Customer” entity in the LDM, which is linked to the “Customer” table in the PDM). All
linkages should be maintained in the modeling tool so that a proposed change in an object can be analyzed before it
is changed. It is essential that the linkages form a single unbroken chain.
The activities described so far have all been based on “top-down” analysis and design. In reality, data modelers
often use a hybrid approach, combining both “bottom-up” and “top-down”, so the tool must be able to support the
generation of a SAM or LDM from a PDM, and the generation of a SAM from a LDM. Both tools have this capability,
but the support provided by PowerDesigner is superior, due to the explicit support for all three types of data model,
and the loose coupling of data models.

ERwin
Historically, ERwin users have worked with tightly-coupled logical and physical data models. In this environment,
changes in the logical model are automatically reflected in the PDM (and there can only be one PDM). ERwin’s
Data Modeler r7 introduced the ‘design layers’ functionality, which allows you to derive one model from another,
maintaining linked models in separate files for the first time. So you can derive a LDM from a LDM, and a PDM from
a LDM, creating the chain of models shown in Figure 2. You can also work upwards, deriving a LDM from a PDM. You
do have to be careful when synchronizing a model with the model it was derived from — the default comparison
options don’t include all the properties you may need to compare, such as attribute and column data types.
I did have an issue with the design layers feature in ERwin. My LDM includes two many-to-many relationships
that I hadn’t resolved. When I created a new PDM, the many-to-many references were still present. ERwin allows
you to use a transformation to resolve many-to-many relationships, but only in the LDM. In my evaluation edition,
transformations weren’t available to me, though the help information indicated that they should be. To resolve the
relationship manually, I wanted to copy one of the existing entries, which I did by selecting the entity on the diagram,
and using standard copy & paste. The new entity was not allowed on the diagram, as it had the same name as the
original entity. A look at the browser confirmed this — I had two entities called ‘Phone’. When I renamed the new
entity to ‘Contact Phone’, it appeared on the diagram. No damage done, but I didn’t expect to be allowed to create
duplicate entities. If you don’t like this default behavior, you can change it via the model naming options.
My original model had been imported from a PowerDesigner CDM, and I was eventually able to carry out
transformations once I had added a new entity or relationship to the model. I raised this with the product team at CA,
who were able to import the PowerDesigner model without these restrictions.
The physical limitations of the storage structures would typically be included in the PDM, such as which tablespace,
the size of the tablespace, how many rows are anticipated, etc.

6

PowerDesigner
PowerDesigner extends the two types of model provided by ERwin, to include a dedicated CDM, Object-oriented
models, and XML models. In addition, you can generate almost any type of model from almost anything else. Figure 3
shows the generation links available for data models. You can see the flexibility this gives you, with a model designed
to manage a SAM, and three different types of model to support physical data modeling.

Figure 3. Generation, import and export options for data models

When generating a new model, you can be selective about which objects to generate from in the original model.
A detailed record is kept of the links between models, and between objects in those models. This information is
available for carrying out impact analysis, and is also used to ensure that models stay synchronized, where necessary.
Sybase refers to these capabilities as ‘Link and Sync’.

Summary
ERwin provides great support for tightly-coupled logical and physical data models, and merging models together
(via the sync facility), but it cannot compete with the additional model types provided by PowerDesigner, nor with
PowerDesigner’s link and sync technology.

Managing the SAM-LDM Relationship
I used a realistic scenario to examine the support for integration of the SAM and LDM in each product — using an
existing LDM to form the basis for a new SAM. The CDM was then amended, by hiding or removing the foreign key
attributes, and drawing a many-to-many relationship. I would then attempt to document business rules and stewards,
and link them to the entities in my SAM.
How well does each tool support the SAM and links from the SAM to the LDM?

ERwin
Creating the SAM was easy to achieve, by deriving a new LDM from the original LDM. The next task is to make the
new model look more like a real SAM. The many-to-many relationship was not a problem, ERwin allowed me to draw
it OK. Hiding foreign keys, though? Not possible. Removing foreign keys? OK, I can do that, but only by removing all
attributes from the primary keys, and creating unique alternate keys for any candidate key attributes I want to keep.
I can’t remove the primary keys or convert them to alternate keys, so I have to keep them.

7

This task took much longer than I expected it to, due to one of the idiosyncrasies of ERwin. If I double-click on an
entity symbol, it opens the entity properties, which doesn’t provide access to the details of identifiers or attributes.
I have to close that dialogue (can’t have more than one property editor open at a time), right-click the entity symbol,
and select ‘key groups’ to amend the primary key and create the alternate key.
In ERwin, I was able to remove attributes from all the primary keys, but there was one inherited attribute that
would not go away, in the ‘Person’ entity shown in Figure 4. To remove it, I had to detach the ‘Person’ entity from the
subtype symbol, and then re-attach it.

Figure 4. An unwanted PK attribute in ERwin

I would like to document business rules and stewards, and link them to the entities in my SAM, but I can’t do that in
ERwin, except by creating a User-defined property to hold the name of a business rule or steward, which would have
to be defined elsewhere.
The ERwin Design Layers options allowed me to synchronize the two models. The links between the models were
not visible from the SAM I created.

PowerDesigner
In PowerDesigner, I created the CDM by generating it from the LDM, making sure that generation dependencies
were created. These links can be viewed from both ends, within individual objects and at model level.
CDM doesn’t migrate attributes along relationships, so there are no foreign keys to remove. All the primary
identifiers can be removed very easily. If for some reason I decided to use the PowerDesigner LDM as a SAM, removing
foreign keys would involve two quick steps. In step 1, open a list of identifiers, select them all, click on the ‘primary
identifier’ property, and then click on <OK>. Figure 5 shows this dialogue in PowerDesigner, after the ‘primary identifier’
properties have been unchecked. All the primary identifiers have been converted into alternate identifiers.

Figure 5. PowerDesigner list of identifiers
8

In step 2, create a list report containing relationship joins, making sure to include the ‘child attribute’ properties in
the content. Again, select all the entries, and amend the value of ‘child attribute’ to ‘None’, as shown in Figure 6. All
your migrated attributes will be removed from the model.

Figure 6. PowerDesigner Relationship Joins

In PowerDesigner, business rules can be defined in any model, or shared via the glossary which is held in the
repository. You can then link them to any object you want to.
In PowerDesigner, most dependencies between objects are pre-defined and named. Any additional links you create
are called Traceability Links, and you can assign a user-defined link type to each link. These link types can be presented
separately in an object’s properties, filtered in lists of dependencies, and also displayed in dependency matrices.
In PowerDesigner, a steward would be represented by an organization unit in the business process model. There is
not a direct link from an organization unit to an entity, but creating one is a trivial task.

Figure 7. PowerDesigner entity with two new properties

Figure 7 shows an entity symbol, displaying two new properties that I added to the entity. One property is called
‘Steward’, and links the entity to the organization unit called ‘CRM Department’ in a process model. Populating this
property automatically creates a dependency between the two models, which can be shown on a project diagram, and
interrogated via impact and lineage analysis. The ‘Steward’ property can also be displayed in dependency matrices (see
“Dependency Matrices” on page 55).
It is not possible to enhance models this way in ERwin.

Summary
ERwin allows you to create a SAM based on a LDM, but the new SAM is still a LDM at heart, ‘pretending’ to be a
SAM. This pretense relies on ignoring standard LDM features, some of which (such as primary identifiers) cannot be
removed. The linkages between the SAM and LDM can be maintained via the Design Layers options, but full visibility
of those linkages is not available.
PowerDesigner provides a dedicated Conceptual Data Model, perfect for a SAM. When this model is generated from
a SAM, individual LDM objects are linked to their corresponding objects in the CDM. These links are visible from within
both models. The models can be synchronized in either direction using the standard model generation feature.
See also “Dependency Analysis” on page 11.

9

Forward and Reverse Engineering
The PDM can be used to generate a database creation script or can be used to directly create the database through
an ODBC, JDBC and/or direct connection to the database server. This is known as forward engineering. Generating
a PDM from the structure of a database schema or DDL file is called reverse engineering; this may also be used to
describe the generation of a SAM or LDM from a PDM.
Every data modeling tool needs to provide reverse and forward engineering. Many organizations find it useful to
reverse engineer an existing system, generating a LDM and SAM from the PDM, so they gain a better understanding of
the database and the applications that use it.
Both tools examined here support forward engineering, see “Database Support” on page 18.

ERwin
ERwin supports reverse engineering from either a database or a script file. When reverse engineering, the newly
created model can be either a physical model or a logical/physical model (in accordance with ERwin terminology —
the logical/physical model is actually a single saved file that has diagrams for both logical and physical models).
Template selection is provided and the process is wizard-driven. ERwin can attempt to infer keys (primary and foreign)
based on the schema of the incoming database.

PowerDesigner
PowerDesigner supports reverse engineering from either a database or a script file. Live database connection is
through an ODBC/JDBC connection with all objects supported. Script file reverse engineering is fully supported as
well. Object inference is supported if chosen through the reverse engineering options. As with all data model creation
modes, templates are supported for the reverse engineering. When reverse engineering from a live database, the
database statistics can also be included (i.e., number of distinct values in a column, average length of a character
field). Additionally, the statistics can be reverse engineered into a model without changing any of the objects. Reverse
engineering is wizard driven.
If a LDM is also required, this can be generated from the new PDM.

Summary
There is little to choose between the products here; your choice of tool may be driven by the DBMS versions you
need to support — see “Database Support” on page 18.

Round-trip Engineering
The tool must also allow the modeler to reverse-engineer a database schema into a PDM, amend the PDM, and
then update the database from the PDM. This is known as round-trip engineering.
A data modeling tool MUST support both round-trip engineering and the hybrid approach described earlier.
Whether a modeler is starting from a conceptual model or reverse engineering a database into a physical model, a tool
is useless unless it can support all aspects. Other features might be “nice to have” but this is baseline functionality.

Summary
Of the tools considered for this paper, only PowerDesigner provides full support for round-trip engineering as well
as giving the modeler the ability to work forwards or backwards (e.g., start from LDM, create CDM and PDM from the
LDM), and provide comprehensive analysis of the dependencies between all the models in the chain. PowerDesigner
has conceptual, logical and physical data modeling all in one tool. With all data modeling aspects in one tool, coupled
with PowerDesigner’s link and sync technology, the organization has the utmost flexibility in building, analyzing, and
maintaining data-oriented systems.

Integrating Data Models with Requirements and Processes
When a data modeler receives requirements or specifications from a business unit, the first step is to create
a subject area model (SAM). In many cases, there are also defined business rules, requirements documents, and
business process models. Ideally, the SAM should be tied to the process model so that the stakeholders within the
organization would have an understanding of the data and its use to support the processes. This also ensures that
data elements used in a system are necessary. There are many existing systems and applications that carry data that
is never used. The entities in the SAM can also be linked to the associated business rules, and requirements imported
from documentation.
10

ERwin
ERwin Data Modeler does not support process modeling or business rules. There used to be a separate tool called
ERwin Process Modeler, which was capable of synchronizing subject areas, entities and attributes with ERwin data
models, but that product has been discontinued.

PowerDesigner
In PowerDesigner, the modeler is able to associate the subject area model with any process model that they have
access to. They can also link to any business rule in any model (not just data or process models) that they have access
to. Via the glossary feature, they can also associate the subject area model with globally-shared business rules.
Finally, requirements can be imported into a Requirements model from standard office documentation, and these
requirements can be associated with any modeling artifact.

Summary
PowerDesigner is the clear winner here; the definition of requirements and business rules allows the modeler to
document far more than just what goes in a database.

Generating Object-oriented Models
After the SAM has been created, the next step would be to generate an appropriate model to begin development.
Within the scope of this paper, that model would be a logical data model (relational). It may be useful to create an
object-oriented model from the SAM (PowerDesigner Enterprise Architect does this) but that is beyond the scope of
this paper.

Dependency Analysis
The very act of creating a data model creates dependencies between objects in that model, most of which will
be supported by the standard data modeling techniques, such as placing related attributes in the same entity,
and creating relationships. When a new data model is generated or reverse-engineered from an existing data
model, further dependencies are created. In addition, a data modeler may wish to create their own dependencies,
such as linking data modeling objects to requirements, business rules or business processes, or even to other data
model objects.
It is essential for a data modeling tool to allow the modeler (and others) to interrogate these dependencies — this
may be called ‘impact analysis’, ‘where used’, or ‘impact and lineage analysis’. In the section below, I refer to this as
‘Model Lineage’.
In addition, there are dependencies between real-world applications, representing the movement of data between
those applications. In the section below, I refer to this as ‘Data Lineage’.

Model Lineage
At each step of the process, it is paramount for the data modeling tool to be able to show the lineage of the objects
in models. When examining the properties of a column in a table (in the PDM), the modeler should be able to see
what attribute of what entity was used for its creation. The modeler should also be able to trace back to the reason
the attribute was created, which may be to support a business rule, to meet a given requirement, or to implement a
given data element.
This visibility and traceability helps to ensure that the organization uses only the data elements necessary for the
implementation of a project or system. Furthermore, the understanding of where objects originate contributes to the
proper business process implementation. The corollary to this full traceability is impact analysis.

Impact Analysis
Impact analysis, or the ability to understand the consequences of a model change, needs to be a function of the
modeling tool. As part of the impact analysis, a modeler needs to be able to understand the object’s model lineage).
Impact analysis includes more than just understanding where an object is used. It is also important to understand
what happened to an object after it was generated. Was an attribute in a SAM generated into the LDM? Was it then
generated into a PDM? Was the data type changed by the DBA when working on that PDM? Did a modeler generate
a set of classes from the LDM so that the developers would be able to start building applications? It is useful to be
able to store these analyses for later review as well as create version documentation. It is a better use of resources to
intelligently discuss the proposed change with the stakeholders rather than make a change in the LDM, propagate it
to the PDM and database only to find that the application now fails.
11

The concept of impact analysis goes further when considering stored procedures or triggers that might have been
created. If a modeler needs to change a data type or entity in the LDM, for example, an impact analysis would show if
the object is being used in a stored procedure. With a proper modeling solution and discipline, the modeler would be
able to have a discussion with the DBA prior to making the change.

ERwin
ERwin supports logical and physical data modeling, and allows you to pretend that a logical data model is a
conceptual data model, or SAM. Assuming you use the Design Layers model derivation process, the impact analysis
available is minimal, limited to saving the results of synchronizing two models. It is not possible to trace the lineage of
an object back from the PDM to the SAM, for example. You can use the standard “complete compare” feature to assess
the links between models related by derivation, but you will not meet with much success due to the fact that you
expect the SAM and LDM to be different. Merely renaming an entity in one of the models will fool “complete compare”
into concluding that they are different entities.
ERwin has a “where used” function that will show exactly where an entity or attribute in the LDM is used in the
PDM, if the PDM is in the same file as the LDM. Figure 8 shows the ‘where used’ tab for the LDM entity in ERwin; this
tells you that the entity is linked to one relationship in the LDM, and that it appears on one diagram in the LDM. There
is no information about the SAM from which this was derived, or the PDM that was derived from the LDM. One of the
buttons on the toolbar under ‘where used’ allows you to edit the selected related object.

Figure 8. ERwin Entity Editor — where used

In ERwin, you can only see dependencies within and between logical and physical data models, and they are only
visible in the model in which they are defined.

PowerDesigner
In PowerDesigner, one tool provides support for all types of model. Any user can read any model (subject to
repository permissions/licensed package), and carry out full impact analysis in the tool, directly against the repository
and/or via the PowerDesigner Portal.
PowerDesigner has true and extensive impact analysis. An object’s lineage is stored with the object. When models
and documents are stored in the repository, the impact analysis becomes more extensive. While viewing an object’s
properties, clicking the “Impact and Lineage Analysis” button will bring up a window similar to the one in Figure
10. The analysis results depend on the analysis rule sets you use. Rules sets allow you to tailor the impact analysis,
determining the types of objects that are traversed in the impact analysis, and the properties that are displayed.
There are several rule sets supplied, and you can create your own if you need them, and share them via the repository.
Not only is the impact analysis available for the data modeling functionality, but it is core to the tool, and is
available throughout all modeling modules.

12

PowerDesigner separates the concepts of ‘lineage’ and ‘impact’ to refer to the predecessors and successors of an
object. Putting it simply, ‘Lineage’ refers to where the object came from, how it is defined, and ‘Impact’ refers to where
it is used, those objects that will be affected if the object was changed or deleted.
For example, Figure 9 shows a chain of three data models. If we were to run Impact and Lineage analysis for
the ‘Sample LDM’, links to the BSAM would be regarded as ‘Lineage’, and links to ‘Sample PDM’ would be regarded
as ‘Impact’.

Figure 9. Lineage vs. impact

By default, impact and lineage analysis only examines local models that are open, which could limit the scope of the
analysis more than you would like. Just select the ‘Use Repository’ option, and PowerDesigner will extend the analysis
into the repository. Figure 10 shows the impact and lineage analysis for the same ‘City’ entity shown in Figure 8. Note
the wealth of additional information shown, and the inclusion of links to requirements, business rules, and classes.
Entries with the small database symbol on their icon were retrieved from the repository.

Figure 10. PowerDesigner impact and lineage analysis

Each of the entries provides a shortcut to the actual definition in a local model, and to a summary of the
information held in the repository.

13

PowerDesigner stores lineage and impact analysis information at both ‘ends’ of the relationship, which enables you
to see dependencies from your model to other models that you’ve never seen before. For example, the LDM stores
details of generated tables, and the PDM stores details of the entities that tables were generated from.

Impact Analysis Model
The best way to fully appreciate the depth and breadth of the impact analysis capabilities of PowerDesigner is to
generate an impact analysis diagram. Did you notice the ‘Generate Diagram’ button in Figure 10? If you click on that
button, PowerDesigner will generate a diagram illustrating the results of the analysis. The diagram can be saved,
providing point-in-time snapshots through the development life cycle. Remember, you can choose between different
analysis rule sets, which will produce different results and therefore different diagrams.
Figure 11 shows such a diagram, generated using the ‘conceptual impact analysis’ rule set and no lineage rules —
this results in a smaller set of affected objects. The left-hand entry is the ‘City’ entity. The style of a symbol indicates
the type of model that it comes from. Double-clicking a symbol will open the properties of that object.

Figure 11. PowerDesigner impact and lineage analysis diagram

Figure 12. PowerDesigner impact analysis model in browser

Look at Figure 12. It shows the entries in the browser for the Impact Analysis shown in Figure 3. This information can
be saved as a model. If you have more than one Impact Analysis Model, you can compare them to see how the impact
has changed over time.

Summary
Where you have tightly-coupled logical and physical data models in a single file, ERwin’s “where used” capability is
up to the job. For any other circumstances, PowerDesigner’s impact and lineage analysis capabilities are far superior.

14

Data Lineage
Managing the real-world movement of data between applications is an essential part of information management
in any organization. Knowledge of these data movements is probably documented in a variety of locations, such as
ETL tools, web services registries, JCL jobs, and spreadsheets. In data modeling tools, this Data Lineage can be linked to
physical data models, enabling anyone to trace the path taken by data through the organization.

ERwin
ERwin provides a facility for documenting simple data movements. You can create a data source in your PDM,
and populate it with tables imported from another model or SQL file. The columns in the imported tables can be
linked to columns in your PDM, and you can add comments to describe the data movement, perhaps describing the
selection logic.
There is no visual representation of the data source in ERwin; the link from the source tables to the PDM columns is
only visible in the PDM column ‘data source’ tab, shown in Figure 13.

Figure 13. ERwin data source

PowerDesigner
In PowerDesigner, this mapping process is much simpler. Just fire up the mapping editor, specify a name for the
data source, choose a model to map to, make sure that the option to create default mappings is selected, and then
click on <OK>. Default mappings are created by matching object names and codes in the two models.
In Figure 14, I chose to map from my sample PDM to a PDM that I created by reverse-engineering the MS Access
Northwind database. I have added some mappings between columns by dragging from left to right. The ‘Mappings’
window in Figure 14 shows the details of the mapping from the Person table to the Customers table; using the tabs,
I can edit information about the mapping, such as the join criteria. All of the information shown in Figure 14 will be
available through impact and lineage analysis and dependency matrices.

15

Figure 14. PowerDesigner mapping editor

In addition, PowerDesigner provides a dedicated model for data movements, which can import simple PDM-PDM
mappings. The Data Movement Model is designed to manage data replication using Sybase Replication Server®, but it
can be used to document other data movements as well.

Summary
ERwin is great for capturing the context of an individual model, but it cannot compare with PowerDesigner’s
Mapping Editor or Data Movement Model. ERwin’s mappings are text-based, not graphical, and invisible from the
perspective of the related model(s). In PowerDesigner, any mappings created can be viewed in the mapping editor,
impact and lineage analysis, and via dependency matrices. They are treated in the same way as any other dependency
between objects — they are visible and navigable.

Model Comparisons and Merges
Whether a model is in a repository, the current workspace or saved in the file system, it will be necessary to
compare models and merge differences from one model to another. The modeler might be working on a particular
entity in the LDM while another modeler would be working on the same model. Merge and compare functions help to
contribute to the ability for an organization to perform collaborative modeling. All tools examined for this white paper
contain merge and compare functions. The comparison operation is simply a visual representation of the difference
between models. The merge function should allow a modeler to accept or reject any or all changes.

16

ERwin
ERwin has a “Complete Compare” function. It will work with open models in the tool, script files and models, or
databases and models. Complete Compare is wizard-driven and allows the modeler to choose the “left” and “right”
models. I like to be able to decide which model goes where, rather than leaving it up to the tool to decide. I would
always have the ‘higher level’ model on the left; for example, a SAM on the left, and a LDM on the right. Once all
selections are made in the wizard, the “resolve differences” dialog box is displayed, allowing you to decide which
changes to apply, and in which direction. The merge is bi-directional.
You can mark ‘known differences’ to be ignored, save them for later, and apply them to future comparisons.
The design layers feature also allows you to merge models in a limited fashion. You can add one or more model
sources, and choose the objects you want to copy across from those source models. Later, you can sync the target
model with any of the source models; differences between the two models are presented in the same dialogue as
used in “Complete Compare”. You do have to remember to save your sync options in a settings file, so you can use the
same criteria each time you sync the models.

PowerDesigner
There are two techniques you can use to merge content between two models in PowerDesigner. You can use
the ‘merge model’ feature, which allows you to merge two model of the same type. Alternatively, you can choose
to generate from the source to the target model in update mode, which gives the option of saving dependencies
between the two models. Both of these features use comparison and merging functionality. It is part of the core
function set of PowerDesigner and not specific to data modeling. This model merge function is invoked automatically
(or can be invoked manually) when a model is saved to the repository, copied into the workspace where a model is
already open, and when model generation is used to update an existing model.
PowerDesigner’s model merge provides fine levels of granularity and control as to what can be changed. Like ERwin,
PowerDesigner allows you to manually match source and target objects in the comparison. In PowerDesigner, you
can only merge models in one direction, from source to target. Uniquely, the PowerDesigner Portal provides the same
comparison features as the client.
A feature unique to PowerDesigner is the ability to copy objects from one model, and paste them into another
model as shortcuts to the original objects, or as managed replicas of those objects.

Summary
As you would expect in two long-established products, the comparing and merging facilities are comprehensive.
Both tools have a single merge-compare operation, which can be invoked in several ways. They both allow you to
choose the comparison criteria, filter the results, and save your selections for future use. Both tools allow you to
document the comparison by generating a report.
ERwin has the edge in two respects, as they allow you to mark and save known differences, and the merge is
bi-directional. PowerDesigner has the edge in its ability to generate and update more types of data model.

Update Flows
The boxes in Figure 15 represent the major components in an enterprise-level data modeling environment — these
are all supported by both products. Each dashed line in Figure 29 represents a possible flow of updates to models,
either from modelers (experts in data modeling) or from Reviewers (who aren’t experts in data modeling). Again, all
these update flows are supported by both products.

Figure 15. Update flows
17

In both tools, a standalone edition is available that only supports the data model component, and therefore only
supports update access by modelers. In ERwin, that support is limited to logical and physical data models, and
‘pretend’ subject area models. PowerDesigner is available in several standalone editions, the most basic of which
supports logical and physical data models, XML models, requirements models, impact analysis models, and ‘free
models’, which provide a simple means of creating non-specific drawings and models. Conceptual and data movement
models are available in the InformationArchitect edition.
The standalone editions may be sufficient for small organizations, but the majority would require an enterprise
or repository edition. ERwin workgroup edition includes the repository. The PowerDesigner ‘RE’ editions allow access
to the repository and web portal. The PowerDesigner web portal allows nominated users to input updates to text
properties, such as entity definitions. These updates will be reviewed later by the model owners.

Required Features for a Data Modeling Tool
This section examines some of the key features a data modeling tool must provide in order to perform the activities
described earlier, in an efficient, effective and productive manner. The features are grouped into the following
categories: Core Modeling, Collaboration, Interfaces & Integration, and Usability.

Core Modeling

Database Support
Since one of the goals of using a modeling tool is to create, modify, understand and analyze databases, it is
necessary that the tool support a variety of DBMSes. Even more important is the ability for the user community to add
additional database support without waiting for the vendor to provide an upgrade. This might be necessary when a
system needs to be migrated from an older database to a more current solution, so the user can reverse-engineer the
old database, generate and modify LDMs and SAMs, modify models, then create a new database. Consider a modeling
tool that provides database definition files in an XML format so that additional database definition files can be
created by the user.
To make this degree of customization possible, an intelligently designed modeling tool will be engineered so that
the core executable reads definition files. The executable file is extensible, not only for different modeling modules
(CDM, LDM, PDM, XML) but for database definition files. With a tool designed thusly, supported database updates can
be released as soon as the database vendor makes the specifications available. The entire modeling tool does not have
to be upgraded. Furthermore, with separate core and external definition files, it is possible for the customer to add
support for a database not supported by the tool vendor.
PowerDesigner supports this paradigm while ERwin does not. PowerDesigner uses a single executable that
is extended through DLLs for modules and XML definition files for all databases. Because of PowerDesigner’s
architecture, it is possible to add support for a specific database system even if Sybase does not upgrade
PowerDesigner to support it. The database definition files are stored in the file system as XML files and can be
modified. ERwin does not provide this ability.
The following table summarizes the DBMS support provided by each tool. A “,” between version numbers indicates
that different database definitions are used for the DBMS versions. If the separator is “-”, that indicates that a group
of versions is managed by the same database definition. The “-” means that version-specific database support is not
provided: a common set of attributes is supported.

18

Database PowerDesigner 16 ERwin r8.1
Adabas D Yes No
Allbase/SQL G.1 Yes No
ANSI Level 2 Yes No
Hitachi HiRDB No No
HP Neoview R2.4 No
IBM DB2 for AS/400 Yes No
IBM DB2 for z/OS formerly OS/390) 6.x, 7.x, 8.x, 9.x, 10x 8.1, 9.1
IBM DB2 for Common Server (aka LUW) 6.x, 7.x, 8.x, 9.0, 9.5, 9.7 9.1, 9.5, 9.7
IBM DB2 for i No 5.x/6.x
Informix SQL 8.x, 9.x, 10.x, 11.x 9.x/10.x/11.x
Ingres 3.0.1 2.5, 2.6, 2006
InterBase 5.x 5.x, 6.x 5.x
Microsoft Access 2000, 2007, 2010 2000, 2002, 2003
Microsoft SQL Server 2000, 2005, 2008, 2008 R2 2000, 2005, 2008
Microsoft Visual FoxPro No Yes
MySQL 4.0, 5.0 5.x
Netezza 4.5, 5.0 No
NonStop SQL Yes No
ODBC 3 2.0, 3.0
Oracle 8i2, 9i, 9i2, 10g, 10gR2, 11 10.x/11.x
PostgreSQL 7.3, 8 No
Progress No 9.x/10.x
Red Brick Warehouse 6.2 5.x
SAS No Yes
Sybase SQL Anywhere® (previously 9, 10, 11, 12 No
Watcom SQL or Sybase ASA)
Sybase AS Enterprise 12.0, 12.5, 12.5.1, 12.5.2, 12.5.3a, 15.0, 15.0.2, 15.5 12.5/15
Sybase AS IQ 12.5, 12.6, 12.7, 15.0-15.1,15.2 12.x
Sybase Avaki® Yes No
Teradata V2R5, V2R6 2.6, 12, 13

Both PowerDesigner and ERwin include support for all the database platforms listed above in every edition of
the product.
When considering the database support that a tool offers, it is not enough to say that a particular database system
is supported. For example, PowerDesigner supports all of the Oracle data types and nuances (storage, partitions) that
are in Oracle 11g, including over 80 data types. ERwin supports fewer than 30 of the Oracle data types. If this is the
level of support for a popular database (i.e., Oracle 11g), what might the support be for a less popular database?

19

Figure 16. Oracle data types in PowerDesigner

Figure 17. Oracle data types in ERwin

As another example of the support offered by PowerDesigner for Oracle 11g, see the following figure.

20

Figure 18. Oracle physical options in PowerDesigner

PowerDesigner has all physical options on one tab. All Oracle 11g partition options are supported, as well as column
properties, physical properties and all other options.
ERwin doesn’t present all the properties of an object in one dialogue. For example, Figure 19 shows the seven
different dialogues available for tables. If the properties you need to read are not in the dialogue you have open, you
must close it and open another (you can only have one open at a time).

21

Figure 19. ERwin Table menu

ERwin separates physical options from partitioning. There is no support for reference or system partition types.

Figure 20. Oracle partitioning schemes in ERwin

Summary
There is no doubt that the database support provided by ERwin meets the requirements of many data modelers.
The product probably supports the majority of features for the majority of DBMS versions in use. If your requirements
stretch beyond the ‘majority’ in either respect, PowerDesigner is the product for you.

Modeling Notation
There are several different modeling notations commonly in use. A modeling tool should support more than
one notation.
• Information Engineering — a standard notation in use in many tools, though there are several variations.
Generally, the entities and tables are represented by rectangles and the relationships are represented by lines with
different endpoints, usually the popular “crow’s feet”.
• Barker — created by Richard Barker and popularized by Oracle’s CASE tools, Barker notation displays inheritances
inside the parent entity symbol, has its own multiplicity notation and attribute ornaments. Relationships are
drawn in two parts with each reflecting the multiplicity of the associated entity role.
• IDEF1X — in this notation, each set of relationship symbols describes a combination of the optionality and
cardinality of the entity next to it.
• Entity/Relationship — Sybase specific, Entity/Relationship is an implementation of IE notation.
• Merise — developed as part of the Merise methodology, it uses complex multi-entity associations instead of
relationships.
• E/R + Merise — both entity/relationship and Merise are used in the same model.

22

Notation PowerDesigner ERwin
Yes
Information Engineering (IE) (called Entity/Relationship) Yes
Barker Yes No
IDEF1X Yes Yes
Merise Yes No
IE + Merise Yes No

Summary
Both products support two of the most commonly used notations, IE and IDEF1X, though there are differences in
the IE notation — ERwin uses dashed and solid lines to indicate whether or not a relationship is identifying, whereas
PowerDesigner uses a triangular dependency symbol. If you want to use the Barker notation, or your organization uses
the Merise methodology, PowerDesigner is your only choice.

Business Glossary
Many development projects and business re-engineering programs develop a glossary of terms, usually as a
spreadsheet. These terms may even form part of the naming standards for data models, but the majority of tools, such
as ERwin, provide no support for this activity beyond the ability to record pairs of words to be used when translating
between logical and physical names for data.
PowerDesigner provides support for a taxonomy of business terms via the repository-based Glossary. In
environments with a repository, administrators can deploy a glossary of Terms: a Term is a word or phrase that forms
part of a controlled vocabulary. In the ‘Naming Conventions’ section of Model Options, you can enable the use of
the Glossary for auto-completion of names in any model. This also enables you to check the names of objects for
compliance with the Terms in the glossary as part of the standard ‘check model’ feature.
If you enable the Glossary in a model, Terms are suggested from the Glossary as you type the name of an Object.
If you type a recognized synonym for a Term, then PowerDesigner suggests you use the Term instead.
When you reference a term in the name of an object, PowerDesigner automatically adds that object to the list of
objects that reference the term. This cross-reference is available in dependency matrices and impact analysis.

Summary
ERwin does not support anything equivalent to the PowerDesigner Glossary. PowerDesigner is the only mainstream
data modeling tool to offer a shared, linked, glossary of terms.

XML is Special
A physical data model describes data persisted in a database. In many cases, that data was transmitted to the
application that populated the database as an XML document or message. The structure and content of that
document or message is a key component of the organization’s data integration, and must be included in impact
analysis and data lineage capabilities. An enterprise data modeling tool should be able to create an XML-specific
physical data model, in which the modeler can design the structure of one or more XML Schemas, and then generate
XML schema files. The tool should also be able to import an existing XML Schema into a dedicated XML model, from
which future versions of the schema can be generated. Only PowerDesigner has all this XML capability. ERwin can
generate and reverse-engineer XML Schema, but it relies on a relational model to do so. The translation between a
relational PDM and the essentially hierarchical nature of XML makes it difficult to effectively manage the development
of XML Schemas in ERwin. The lack of a model dedicated to XML, with XML-specific objects, means that it is impossible
to provide full, accurate impact analysis for XML schemas in ERwin.

Summary
ERwin does not provide an XML-specific data model. PowerDesigner is the only mainstream data modeling tool to
offer a dedicated XML model.

Denormalization of physical data models
It is vital for any data modeling tool to provide automated support for denormalization of physical data models,
including rollback capabilities.

23

ERwin
ERwin supports rollups, rolldowns, horizontal and vertical splits, and column denormalization. Rolling up subtypes
into the supertype, and rolling down supertypes into subtypes, are supported by specific transformations.
The Transforms toolbar provides access to the different types of transformations available, and also allows you
to display the objects before or after transformation. You can also reverse or resolve all transforms — resolving a
transformation deletes the original objects.

PowerDesigner
PowerDesigner supports table collapsing (rollup and rolldown), horizontal and vertical partitioning, and column
denormalization. You have the option to retain or delete the original tables. All transformations (except column
denormalization) are recorded as transformation objects, linked to the newly-created objects. Via the model menu, you
have access to a list of transformations.
Rollup and rolldown are supported by collapsing tables into a new table — you have the option to keep or remove
the original tables. Rolling up and down super and sub types is best carried out in the LDM, using the options that
govern the generation of supertype and subtype tables.
A transformation can be rolled back if the original tables were generated from another model — this does not
re-instate the original tables, so you would need to re-generate them if you didn’t keep them when you carried out
the transformation. If you think you will need to rollback a transformation, I suggest you keep the original tables and
references, and uncheck the ‘Generate’ property to prevent them being generated into a database.
Column denormalization works by utilizing the standard replication feature — it replicates columns across tables.
When the original column is updated, the replicas are also updated. The modeler has control over how strictly the
copies mimic the original column.

Summary
The tools both provide adequate support for denormalization. They take different approaches with respect to
managing the pre- and post- denormalization views of the model; if you are used to one approach, you need to be
aware of the differences if you change tools.

Support for Elementary Data Elements
Previously I introduced the concept of elementary business data elements, which may or may not have any eventual
existence as modeled objects.

PowerDesigner
PowerDesigner supports this via the concept of Data Items in the CDM. A Data Item is a ‘conceptual’ data element
that exists independently of any model objects, such as Entities or Tables. Data Items are integral to the CDM, where
every attribute automatically references an underlying Data Item. They are not present in the Logical Data Model or
Physical Data Model.

ERwin
ERwin does not support elementary data elements.

24

Other Core Features
Core Feature PowerDesigner 16.0 ERwin r8.1
Enforce naming standards based on Yes — using terms in the No
business vocabulary glossary
Record the vocabulary of the business Yes No
as Terms
Persist XML schemas as a model for Dedicated XML Model, or XSD import not supported by evaluation
traceability and normalization UML class model edition — uses the same metadata bridge
as ER/Studio, so it will produce the same
result, a relational model
Check Model (validation) Yes — can customize Separate product (Data Model Validator)
checks, and determine that appears to be comprehensive. It can
criticality. Auto-fix read and validate DDL and ERwin models
available on some checks.
Can access objects from
results list without closing
the list
I was unable to launch the validator
from ERwin — I was informed that
the DBMS in the model (Oracle 11g) is
invalid. I was also unable to open the
supplied sample eMovies ERwin model
Customizable Data Type mapping Yes — defined within the Datatype Standards Editor — allows you to
properties of the DBMS edit logical-physical and physical-physical
data type mappings. Can save multiple
versions, and attach to models. I haven’t
seen any reference to DBMS-specific
mappings, but I’m sure they must be
managed somehow
Inter-Model Generation & Yes LDM-PDM
Synchronization
PDM-PDM via model sources
Managed re-use of modeling patterns PowerDesigner library Partial — via model templates at the time of
and reference models within data pushes reference models model creation
models to all repository users
Multiple diagrams within a model Yes Yes
Naming standards (enforce/check) Yes — using the glossary Partial
Provide business name to Yes Yes
implementation name translations
Real-time updates of metadata Yes Yes
Replicate attributes between entities Yes — see above No
(ditto columns and tables)
Replicate objects between models Yes No
Shortcuts to objects in other models Yes No
Subject areas (subsets) in a model Yes Only 1 level
Support for elementary data elements Data Items in the CDM No
Automated support for Yes Yes
denormalization of physical data
models, including rollback capabilities
Compare a data model with an Yes Yes — databases only
existing data artifact such as an XML
or database schema, update the model
and/or the data artifact as a result
Direct support for all model objects Yes No
specific to a technology e.g. a specific
RDBMS version

25

Core Feature PowerDesigner 16.0 ERwin r8.1
Filter ‘Dangling Relationships’ from Yes Yes
schema generation
Generate data definition language Yes Yes
(DDL) files
Multidimensional modeling Yes — No distinct notation Yes
Reverse engineer physical data models Yes Yes — some via Meta Wizard
from data definition language (DDL)
files or database connections
XML schema generation Yes Yes
XML-specific physical data model Yes No
Configurable support for technology Yes No
objects (e.g. creating generation
capabilities for unsupported DBMS)
Impact and lineage analysis between Yes Partial
models
Impact and lineage analysis Yes Partial
within a model
Visual editing and display of Yes No
data lineage
Compare two data models, of the same One-way update Yes
or different types, and update one or
both models as a result

Collaboration

Repository
If there is going to be more than one person who will need access to a model, then a repository is necessary. The
repository provides a common location to store documents, models, and other files. It should be able to store different
versions of models as well. From an administrative perspective, the repository provides the organization with a single
storehouse for backup purposes. With proper use, the repository would hold the most current version of a model so
that when a change needs to be enacted, there is no question as to where the proper model resides. Additionally, the
repository would eliminate the necessity to locate the individual who might have a model locked or who might have
implemented some changes.
A repository is necessary to support collaborative modeling, by managing versions of models. A database
administrator may need to implement a change in a physical model, but, at the same time, a modeler needs to
implement a change in the same model. Both people would be able to extract a copy of the model from the repository,
make changes, and then put the model back into the repository. Upon storing the model back into the repository, the
differences should be presented to the modeler consolidating the changes.
Both products are available with a repository.

PowerDesigner
PowerDesigner implements full impact analysis through the repository, allowing you to trace dependencies through
models that you don’t have available locally. With all the models in the repository, it is much easier for the tool to track
all the objects and be able to report to the modeler.
The “Model Merge” functionality discussed above is presented each time a model is consolidated into the repository.
The changes between the version in the repository and the model being checked in are highlighted with the option to
accept or reject any or all changes.
The repository presents in the tool browser as a folder-based structure. Security is implemented in the repository —
users will have various permissions, based on roles. These permissions are defined by the repository administrator and
are typically different from the database user permissions. Branching and sub-branching, versions, locks, freezes are
all supported.

26

The repository can be installed on a local Sybase SQL Anywhere database initially, avoiding the need to purchase
disc space and involve DBAs until you’ve proved what you need. It can then be migrated to one of several supported
database platforms.

ERwin
The repository for ERwin is the Model Manager, which provides the model management functionality for ERwin
Data Modeler Workgroup Edition.
Model Manager provides library management, allowing for folder creation and better organization within the
repository. Sub-models are supported, not only through ERwin but also in Model Manager. ERwin Model Manager is
more of a ‘model store’ than PowerDesigner’s repository; it does not push any information out to users, unlike the
library feature in PowerDesigner; nor does it allow you to browse content using the client software or a web portal. CA
supports version management in the Model Manager, including locked versions, difference reports, and model rollback
to previous states. The Model Manager allows you to rollback to any point in the life of a model.
The repository is a database wherein the models are stored and managed. Users must check out models and check
them in again, as in a standard version control system. Archiving and versioning are performed within the repository
and the tools that are available to modelers are also available to work with models in the repository (e.g., Compare
and Merge, Subject Areas, …). Security is implemented in the repository; users would have roles and privileges.
Branching and sub-branching is supported.

CA suggests that you use the Model Manager in one of the following ways:
Model-Driven Changes to the schema are made to the model first and then forward-engineered
Development
System-Driven Changes are made directly to the schema and the schema is reverse-engineered into the model
Models to reflect the changes
Informational Contains logical-only models, enterprise-wide models, or standards and sample models
Models

The choice you make will influence the way you set up the repository database and the supporting policies. I
haven’t had access to the Model Manager during this evaluation so I can’t be sure of the implications of this choice. In
reality, you would probably want to use a repository in a hybrid fashion, combining all three approaches.

Summary
ERwin’s repository offering is essential for multi-user environments. It is useful as a way of managing access to
models, and versions of models. However, it does not provide any direct access to repository content for modelers or
non-modelers, unlike PowerDesigner, which allows modelers to browse the contents of models in the repository, and
incorporate the repository in searches. Via the Web Portal, non-modelers can browse and search the PowerDesigner
repository contents in the same way; and selected non-modelers can also (using the new ‘Composer’ license) update
text properties directly in the repository.

27

Web Portal
A repository is essential for effective collaboration between modelers, and a web portal is essential for effective
collaboration with non-modelers.

PowerDesigner
The PowerDesigner web portal allows non-modelers to browse, search and compare models in a similar way to
users of the desktop software. The search facilities are actually better than those available on the desktop, and the
impact analysis capabilities are comparable. Portal users have real-time access to the repository, so they know they’re
viewing the latest checked-in models. The new ‘Composer’ license allows selected users to edit textual definitions via
the portal (assuming you’ve granted them access to the models, of course).

ERwin
ERwin does not provide a web portal.

Other Collaboration Features
Collaboration Feature PowerDesigner 16.0 ERwin r8.1
Compare versions of repository based models Can compare any version of any No
model to any version of any model
of the same type
Manage configuration of different models that Yes No
contribute to release
Provide subscription for anyone to know when Yes No
models are checked-in
Impact and lineage analysis via repository Yes No
Projects and frameworks matrices Yes No
Share and apply a ‘house style’ for the User profiles help you to standardize Themes
appearance and content of data models the look and feel of your models and
to support standards
Share reference models and common business Yes No
rules via a repository
Direct access to models and links between Yes No
models via a portal, designed for use by
non-specialist users of data models
Read-only access to models Viewer software is free Navigator edition —
list price c. $1,000
Search and impact analysis capabilities via a Can search models, compare models, No
portal, designed for use by non-specialist users follow all traceability links and
of data models dependencies (impact analysis)
Web-based functionality at no additional cost Yes No
to the repository
A shared location for the storage of and Repository — Enterprise license Repository — workgroup
control of access to data models required license required
Control access to subsets of a model, perhaps Yes — down to packages within Yes — down to submodels
individual model objects models
Integrate with LDAP/Active Directory for user Yes Yes
authentication
Resolve potentially conflicting changes made Yes Yes
by different analysts
Role-based management of access to Yes Yes
repository content

28

Interfaces & Integration

Import and Export
A modeling tool must allow the modeler to import and export content in various types of models and related
external files. Both import and export allow the tool to work with other tools or provide information to other people,
organizations, or solutions. It is useful for the tool to be able to work with metadata in a generic fashion, but specific
importing will provide greater overall support.
Both tools offer several import and export features.

ERwin
ERwin Data Architect includes an OEM Metadata Integration Wizard1, enabling users to export and import to and
from many other formats.
The ERwin Bulk Editor is a single window that allows you to edit a small set of properties over a large number of
objects. It also allows you to export to and import from CSV files.

PowerDesigner
PowerDesigner does not include the Metadata Integration Wizard, choosing instead to rely on several built-in
import engines. If you need additional metadata conversions, you can purchase additional metadata bridges from
companies such as Reischmann2. They supply standard bridges, and can configure them quickly for you, if necessary.
The inclusion of the Metadata Integration Wizard means that ERwin appears to have the more capable model
import capabilities of the two tools here. In reality though, the majority of data modeling tools can save models in
ERwin XML format, which PowerDesigner can import. In fact, it can import and several ERwin files at the same time,
and create any combination of conceptual, logical and physical data models from each ERwin file.
The support provided by PowerDesigner for the import and export of model content, such as entity descriptions
and comments, is far superior to anything in ERwin. PowerDesigner provides powerful, configurable facilities to export
to and import from Microsoft Excel, capable of creating complete models in one pass, including dependencies. No
programming is required, though an understanding of the underlying metamodel will help you import some of the
more complex metadata, such as dependencies.
Once defined, an Excel import can be re-run whenever you need to — the import definition is an object in its own
right, accessible via the browser.

Summary
Using the OEM Metadata Integration Wizard, ERwin can transfer metadata to and from more tools and formats
than PowerDesigner. Realistically, this apparent advantage is not as great as it seems: the take-on of models in
different formats is often a one-off exercise, which can be facilitated by generating ERwin models from your existing
tool, and importing them into PowerDesigner. Longer-term import and export requirements can be managed by the
excellent bridges supplied by Reischmann.
The ERwin bulk editor allows you to do simple CSV-based import and export; this just cannot be compared to the
flexibility of PowerDesigner’s Excel export capability, available from any list of objects or sub-objects, or dependency
matrix. Nor is it comparable to the Excel Import Wizard available within PowerDesigner.

1See www.metaintegration.net/ for details of supported formats
2See www.reischmann.com/ to find out more

29

Other Integration Features
Interfaces & Integration Feature PowerDesigner 16.0 ERwin r8.1
Design-time change management Yes Yes
Dedicated data movement/ Yes No
ETL Model
Document data movements Via the Mapping Editor or Partial
the Data Movement Model
(DMM). A DMM can convert
PDM-PDM mappings into
a model
Generate scripts to manage the Yes No
movement of data through the
archiving cycle, or data movements
Generate test data Yes No
Build cross-references or traceability Yes No
links between data model objects
and business requirement models
Build cross-references or traceability Yes No
links between data model objects
and shared business rules
Mapping Tool (connections between Yes No
objects in different models)
Persistent Impact Analysis Model Yes No
Export data models in a format that Partial Yes — via Meta Wizard
can be imported into other tools
Import existing data models created Partial Yes — via Meta Wizard. Cannot import
by other tools PowerDesigner LDM. May need to switch
off consistency check to import from
ER/Studio v9.
Preview, print, and save model Yes Yes
comparison results

Usability

Property Editors
Both tools provide tabbed editors for editing object properties. As we’ve already seen, ERwin divides an object’s
properties across several different sheets, whereas PowerDesigner supports all properties on a single sheet.
Furthermore, the PowerDesigner property sheets can be tailored.
One useful feature of the ERwin property sheet is the ability to choose another object of the same type to edit
without closing the sheet. That’s necessary though, as you can’t edit more than one object at a time in ERwin. In
PowerDesigner, you have as many object property sheets open as you can handle.
I find the PowerDesigner editors to be clearer than those in ERwin. For example, contrast the PowerDesigner entity
and attribute editors shown in Figure 21, with the equivalent from ERwin in Figure 22.

30

Figure 21. PowerDesigner entity and attribute editors

31

Figure 22. ERwin attribute editor

Using the model extensions facility (see “Extensibility and Customization” on page 35), we can change the way in
which properties are presented in PowerDesigner; you could completely replace the standard tabs with your own.

Summary
The property editors in PowerDesigner are simpler and more flexible than those in ERwin, and you can open more
than one at a time. If you don’t like them, you can change them. Only PowerDesigner allows you to change the way
in which properties are presented in the editors; you could completely replace the standard tabs with your own. See
“Extensibility and Customization” on page 35.

Grid-based Editing
Grid-based editing allows you to view and edit more than one object at a time, with each object occupying a row in
the grid.

PowerDesigner
PowerDesigner provides a grid-like editing mechanism, within the properties of a single object, such as the list
of attributes shown in Figure 21, and also within a list of objects or a List Report. You can customize the properties
displayed in the grid, and filter the objects or sub-objects listed. For example, Figure 23 shows a list of relationships
that has been customized to show information about the two entities that participate in the relationship. This grid
can be used to edit or create relationships, and the content can be exported to Excel. Once outside PowerDesigner, the
spreadsheet can be edited in Excel, and the results can be re-imported into PowerDesigner to update the model.

32

Figure 23. List of relationships in PowerDesigner

The same capabilities are available when editing the attributes of an entity, or even all the attributes in the model.
In addition, PowerDesigner allows you to create permanent lists of objects, known as list reports. List reports are
stored in the model, and are always accessible from the browser. You can create many list reports for a type of object,
and can even save snapshots of the content. Using the snapshots, you can view the properties that used to have in the
past. You can open multiple concurrent object lists and object property sheets.
PowerDesigner object lists and list reports provide simple validation capabilities. For example, you can create a list
report that contains attributes, and only displays attributes that do not have a domain specified.

ERwin
ERwin provides a simple grid-based editor, called the “Bulk Editor”, which opens in a separate window. The bulk
editor only allows you to open one grid at a time. Each time you open the bulk editor, you need to run the bulk editor
wizard to choose the objects and properties to edit; to make life easier, you can save settings in external files.

Summary
ERwin’s Bulk Editor is a pale imitation of PowerDesigner’s grid-based editing capabilities. You can only edit one set
of objects at a time, whereas PowerDesigner allows you to open as many concurrent grids as you can handle; it also
remembers your customizations, so you don’t have to save in a file and load them each time.

Diagram Style
Data model diagrams are designed to communicate information to an audience. For one audience, you may want to
highlight the entities relating to a given business area. For another audience, you may need to highlight entities that
have changed recently. Don’t underestimate the part that diagram style can play in successful communication. We’re
not playing with content and color just because it’s fun.

ERwin
ERwin allows you to create and apply themes, covering default colors, line options and fonts for different object
types. It’s a simple operation to apply a theme to a model, submodel or diagram, and to vary those style components
for individual symbols. You can also determine the content of symbols on a submodel, and also for individual symbols,
using pre-defined sets of options, which can be tailored for individual diagrams. Figure 24 shows two tables with
different colors and content.

33

Figure 24. Themes in ERwin

Applying a theme to one or more objects is really simple, using previews of the available themes to help you make
your choice. The theme is applied immediately.

PowerDesigner
In PowerDesigner, you have more control over the style and content of symbols. Defaults can be set, and shared
via user profiles. As in ERwin, each diagram has default styles and profiles, inherited from a user profile or another
diagram. Unlike ERwin, you can’t pick from a list of available themes and have them applied immediately. However,
you can ‘get’ the style of one symbol and apply it to other symbols, even symbols of a different type.
The real difference in PowerDesigner is that format and content can be varied from the defaults for each symbol,
and the font can be varied for each sub-object. The layout of properties in symbols is also more flexible; the symbols
can be laid out with horizontal and vertical property groups, rather than just a single vertical list of properties. You can
also specify icons to display on object symbols in place of extended attribute values by creating an attribute icon set
with an icon for each possible value. If you want to hide a sub-object on a symbol (such as a hiding an attribute on an
entity symbol), you can.
Figure 25 shows a sample PowerDesigner diagram. Every entity is showing three new properties, Plural name,
Steward and Review Status. The value of Review Status is shown by the icon at the top of each entity symbol. The style
and content symbol for the Contact entity has been customized: fewer properties are shown for attributes, the entity
line and fill have been altered, and the font for one of the attributes (Web Address) has been altered to accentuate it.

34

Figure 25. Colors, fonts and style in PowerDesigner

Summary
The Themes in ERwin make it easy to apply a custom style to symbols. Unfortunately, the style options end there.
You can adjust the content of symbols, but only by model or sub-model. PowerDesigner does lack the ease of use of
ERwin’s themes; instead you can apply a user profile that changes the default symbol style. You can apply it to existing
objects if you want to, though it’s not as straightforward to do.
Where PowerDesigner really beats ERwin is the control you have over exactly which sub-objects are displayed on a
symbol, and the style and content of individual symbols.

Extensibility and Customization
Working with a data modeling tool will require some adjustment of the modeler to the tool and some tool
modifications for the enterprise and the modeler. Extensibility and customization needs will vary with the type of
work being done as well as the needs of the organization. This section is concerned with the ability of the tool to
adjust to the needs of the environment.
Greater extensibility in a tool is not going to be a concern if simple databases are going to be created and the
maintenance will be minimal. Both tools provide adequate features for this activity, though some users may find
problems with incomplete DBMS support in ERwin.
To create a model-driven environment, however, more customization is needed. Extensibility exists in a variety of
perspectives. Support for DBMSes can be added or their definition files can be modified. The user interface can be
adjusted or user profiles can be created. Model creation can be based on a template and naming standards can be
employed. User securities can be invoked, at the model or repository level. Reports can be defaulted or customized.
Adding scripts is another method of extending the functionality of the data modeling tool. Modifying model checking
criteria is useful as well. Perhaps one of the more important levels of extension or customization is the ability to
extend model definitions through the use of metaclass, stereotype and object creation.

35

Comprehensive Analysis of Sybase PowerDesigner vs. CA ERwin

Comprehensive Analysis of Sybase PowerDesigner vs. CA ERwin

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Comprehensive Analysis of Sybase PowerDesigner vs. CA ERwin

Similaire à Comprehensive Analysis of Sybase PowerDesigner vs. CA ERwin (20)

Plus de Sybase Türkiye

Plus de Sybase Türkiye (20)

Dernier

Dernier (20)

Comprehensive Analysis of Sybase PowerDesigner vs. CA ERwin