WHITE PAPER

PowerDesigner® 15.3 vs. Computer Associates ERwin 7.3

www.sybase.com TABLE OF CONTENTS 1 Introduction 10 Support 1 Product Overviews 12 Repository (Collaborative Modeling) 1 ERwin Data Modeler 7.3 12 CA ERwin Model Navigator 1 PowerDesigner 15.3 12 Sybase PowerDesigner Viewer 2 User Interface Differences 13 Sybase PowerDesigner Portal 3 Modeling Features 13 Extensibility and Customization 4 Required Features for a Solution 14 Business Process Modeling 4 Model Types 15 Object Oriented Modeling 5 Conceptual > Logical > Physical > 15 Enterprise Architecture Modeling Logical > Conceptual 15 Dependency Matrices 6 Model Comparisons and Merges 16 Projects 7 Impact Analysis 16 Framework Matrices 9 Reverse / Forward Engineering 17 Summary 9 Modeling Notation 17 About the Author 10 Import / Export

TABLE OF FIGURES 4 Figure 1 PowerDesigner Orthogonal Layout 11 Figure 9 PowerDesigner Oracle 6 Figure 3 PowerDesigner LDMTools Datatype Examples 8 Figure 4 ERwin Impact Analysis 14 Figure 12 PowerDesigner Allows Data to be 8 Figure 5 PowerDesigner Impact Analysis Assigned to Business Processes 11 Figure 6 PowerDesigner Oracle Physical Options INTRODUCTION When a project requires data modeling, there is a choice of several different products. Two market-leading products are ERwin (from CA) and PowerDesigner (from Sybase). Both will allow a modeler to create data models, reverse engineer , document database systems, create basic reports and create/modify diagrams in a Windows- standard manner. If an organization needs to create a database one time, generate the script to build it and never modify it again, then the best choice would be the product with the least acquisition cost. However, it is rare that an organization needs to create one database and leave it alone. As a business’ needs get more complex, the products reviewed in this paper quickly diverge. There is one clear winner: PowerDesigner.

PRODUCT OVERVIEWS With the tools reviewed, there were similarities. Both modeling tools reviewed provide a drawing canvas and a navigator or explorer and a log window. Toolbars can be turned on or off, but only PowerDesigner allows for toolbar customization. Both tools have undo/redo capabilities. These are Windows applications and, as such, are intuitive from a user-experience perspective. Please see the table for differences in user-experience features following the vendors’ descriptions.

ERwin Data Modeler 7.3 CA states “CA ERwin Data Modeler is a data modeling solution that enables you to create and maintain databases, data warehouses and enterprise data resource models. These models help you visualize data structures so that you can effectively organize, manage and moderate data complexities, database technologies and the deployment environment.”

When I made an attempt to download ERwin, I found that the link on the website was broken. I called CA to request an evaluation copy of ERwin. After gathering my information, I was told that a salesperson would call me back. I never received a phone call from a salesperson. Two days later, I tried the link again and was able to successfully obtain an evaluation copy—good for 25 entities and 15 days.

Installing Data Modeler seemed to work correctly. However, it did not create a Program Group in Windows, nor did it create a desktop link for starting the product. In order to use the modeling tool, I needed to navigate through the Windows folder hierarchy to find the program.

PowerDesigner 15.3 Sybase “PowerDesigner uniquely combines several standard modeling techniques (UML, Business Process Modeling and market-leading data modeling) together with leading development environments, such as .NET, Workspace, PowerBuilder, Java, and Eclipse, to bring business analysis and formal design solutions to the traditional software development lifecycle. And it works with more than 60 RDBMS.”

The ability to download the fully functional evaluation version of PowerDesigner 15 was provided from Sybase’s website. Installation was flawless.

1 User Interface Differences

FEATURE POWERDESIGNER ERWIN Model Organization Yes, a full workspace that can be No. The model explorer within the saved independently from the tool only allows visibility into one models. Multiple models and model model at a time, regardless the types can be open simultaneously. number of open models. Workspace Yes—this can be saved independently No. from the models. Full flexibility and organization is provided. Multiple Diagrams within a Model Yes. Yes. Subject Areas in a Model Yes, via UML standard packages— Yes, but only one level. allows nesting. Object Placement Standard windows controls Standard windows controls Model Layouts Auto layouts include Basic, Under Format->Preferences, there is a Hierarchical, Organic, Orthogonal, “layout entire diagram” button but it Circular, Tree with scope of selected did not work, even when tables were symbols or all symbols. stacked on each other. Freeform Text Yes. No. Customize Toolbars Yes. No. Edit Text Directly on Graphic Yes. Yes. Page Grid Yes. Yes. Find Objects Yes. Yes. Product Documentation Yes, there are PDF versions of the Yes. documentation as well as full documentation online at http://sybooks.sybase.com. Undo/Redo Yes, unlimited. Yes and when using the repository, the undo/redo is maintained across modeling sessions. Zoom in/out Yes. Yes.

2 Modeling Features

FEATURE POWERDESIGNER ERWIN Conceptual, Logical and Yes No Physical Models Naming Standards Yes Yes through templates Shortcuts to Objects in Other Models Yes No Templates for Model Creation Yes Yes Check Model (Validation) Yes—customizable to include user- Yes defined constraints such as tables must have three columns. Multidimensional Modeling Yes, extensive Yes Generate Test Data Yes No Impact and Lineage Analysis Yes No Object Oriented Model Yes No Business Process Model Yes No Enterprise Architecture Model Yes No Projects and Framework Matrices Yes No User Profiles Yes No Mapping Tool (Connections between Yes No objects in different models) Inter-Model Generation & Extensive, CDM-LDM-PDM, including Yes, only with LDM-PDM Synchronization other model types

3 Figure 1: PowerDesigner Orthogonal Layout

REQUIRED FEATURES FOR A DATA MODELING SOLUTION

Model Types To fully model a system, it is necessary to combine business analysis with technology implementations. Where data modeling is concerned, an organization must create conceptual data models, logical data models and physical data models.

A conceptual (CDM) is usually in the form of an entity-relationship diagram, however it is purely data and relationships. A CDM is not relational. It is developed in order to understand, capture, and analyze the business needs from a data perspective. These models will be devoid of implementation details (data storage structures) or software constraints. Entities, attributes and identifiers are found in a CDM. Additionally, the relationships and inheritances that connect the objects, or artifacts, exist in the CDM. The CDM is a higher-level business model. Some of the relationships might be one-to-many yet some might be many-to-many. The CDM will typically be created prior to an LDM for a new system. The CDM might also be used for an existing system where the technology needs to be verified with the business.

Once a CDM has been created, a modeler should be able to generate a logical data model (LDM) from it. The LDM is quite similar to the CDM in terms of the objects that are contained therein. However, the beginning of physical data storage is modeled in the LDM. Many-to-many relationships are not permitted in an LDM so they become intermediate entities. One-to-many relationships become primary key-foreign key identifiers. LDMs illustrate the logical entity types, the data attributes describing the entities and the relationships between the entities.

A CDM does not have foreign-key constraints—these are created when a CDM is used to generate an LDM. Additionally, while a CDM supports a many-to-many relationship, the LDM does not permit many-to-many. Since the LDM is relational, many-to-many relationships cannot exist as many-to-many violates relational storage concepts. The LDM is relational but the CDM can transform to different types of logical models (hierarchical, object-oriented, and relational) so the CDM is better to represent the use of the data by the business.

4 The physical data model (PDM) would typically be created after 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 data 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 are several choices). The PDM is frequently used to generate the data description language (DDL) that will allow for database creation or modification.

The LDM and the PDM are similar but vastly different in terms of the level of detail each supports. 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, creation of production and development databases or application migrations.

A modeling tool should provide the ability to model at any level, with generation to the other model types. All artifacts should be linked to their corresponding objects in the other models (for example, the entity “Customer” in the CDM should be linked to the “Customer” entity in the LDM as well as 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.

Conceptual > Logical > Physical > Logical > Conceptual A data modeling tool MUST support round-trip engineering. 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. This is baseline functionality. Other aspects of the tools, discussed herein, might be “nice to have” but the ability for a tool to support complete traceability and round-trip engineering must be present.

When a modeler receives requirements or specifications from a business unit, the first step is to create a conceptual data model. In many cases, it would be useful to have a business process model as well. The CDM would be tied to the business 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.

After the CDM 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 would be useful to have the ability to create an object-oriented model from the CDM (PowerDesigner does this) but that is beyond the scope of a pure data modeling environment. The LDM would be created directly from (or generated from) the CDM. Many- to-many relationships would be converted to intermediate entities; foreign keys would be created and relational structures would be created.

From the LDM, a PDM could be a next step. When generating the PDM, a database choice must be made for implementation. The physical limitations of the storage structures would typically be included in the PDM (which tablespace? How big? How many rows are anticipated?).

The PDM can be used to generate a database creation script or can be used to directly create the database through an ODBC or direct connection to the database server. This is known as forward-engineering.

At each step of the process, it is paramount for the data modeling tool to be able to show a lineage of the objects. 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. 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 (discussed in a following section).

5 Of the tools considered for this paper, only PowerDesigner supports full round-trip engineering as well as giving the modeler the ability to work forwards or backwards (i.e., start from LDM, create CDM and PDM from the LDM). PowerDesigner has conceptual, logical and physical data modeling all in one tool. With all data modeling aspects in one tool, the organization has the utmost flexibility in building, analyzing, and maintaining data-oriented systems. The illustration below shows the tools menu from within the LDM workspace. Note that generation from LDM to CDM, LDM and PDM are all supported.

Figure 3: PowerDesigner LDM Tools

ERwin supports logical and physical data modeling. When creating a new model, one has the choice of a new LDM, a new PDM, or a combined LDM/PDM. There is no option for a CDM, even in a different tool. CDM concepts are implemented in the LDM using ERwin (many-to-many relationships, which should be described in the conceptual data model, are permitted in the ERwin LDM).Models are created from a template, which can help to speed up model creation. The ERwin documentation discusses that the use of the LDM is to provide a “broad view of business information requirements sufficient to plan for development of the business information system.”This is precisely the purpose of the conceptual data model: tying business requirements to data elements.

Model Comparisons and Merges Whether a model is in a repository, the current workspace or saved in the file system, it is going to 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, based on permissions.

6 ERwin Data Modeler 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 happen to like this approach of left and right. From a visual perspective, left and right make sense. Once all selections are made in the wizard, the “resolve differences” dialog box is displayed. Data Modeler has a good solution for the merge and compare functionality. Since conceptual data modeling is not part of the Data Modeler solution, it is impossible to compare CDMs and LDMs.

PowerDesigner has a “Model Merge” functionality that is common across all types of comparisons that need to be made. 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. The icons used in PowerDesigner are confusing until a modeler gets used to seeing them. PowerDesigner’s model merge provides fine levels of granularity and control as to what can be changed. It will allow a modeler to perform bidirectional merges with one pass.

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 lineage (objects that form the basis for a particular object). Impact analysis includes more than just understanding where an object is used. It is also a requirement for proper impact analysis to be able to understand what has happened to an object once it has been generated. Was an entity’s attribute in a CDM attribute generated into the LDM? Was it then generated into a PDM? Was the datatype 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.

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, for example, in the LDM, 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 does not have cross-model impact analysis functionality. Going through their documentation does provide reference to “impact analysis”. In practicality, though, the tool provides some manner of affecting changes in databases. The “impact analysis” function in ERwin is a toolbar that is used during a Complete Compare. When two physical models are compared, the differences will be displayed in a dialog box. If the modeler chooses to copy changes from the left side to the right side (or vice versa), then the “impact analysis” toolbar will provide buttons to create alter scripts to be applied to the database. This toolbar is illustrated in the below illustration (the second toolbar from the top, the icon on the extreme right is the button to generate the script after the change had been applied from the left side to the right side.

7 Figure 4: ERwin Impact Analysis

Only PowerDesigner has true and extensive impact analysis. An object’s lineage is stored with the object. As models and documents are stored with the repository, the impact analysis becomes more extensive. While viewing an object, depressing the “Impact and Lineage Analysis” button will bring up a diagram similar to the one below. Not only is the impact analysis available for the data modeling functionality; it is core to the tool, and provides impact analysis throughout all modeling modules. Impact analysis is also available as a model so that diagrams can be generated and saved. This can provide point-in-time snapshots through the development life cycle. In addition to the vendor-supplied rule sets, PowerDesigner allows for the creation of user-defined rule sets to further expand the benefits of impact and lineage analysis.

Figure 5: PowerDesigner Impact Analysis

8 Reverse / Forward Engineering A modeling tool needs to provide reverse and forward engineering. Reverse engineering is the process by which a data modeler can generate a PDM from a live database or a script file. Many organizations find it useful to reverse engineer an existing system, generate an LDM and CDM from the PDM and better understand the database. Forward engineering is the ability to create a database (or modify a database) from the PDM. This can be done live or through script files.

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.

PowerDesigner supports reverse engineering from either a database or a script file. Live database connection is through an ODBC 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.

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 method in use in many toolsets. There are several different variations. Generally, the entities and tables are represented by rectangles and the relationships are represented by lines with different endpoints. Crow’s feet is a popular version. • Filtered IE – found only in Embarcadero, this notation hides the foreign keys. While this may appear to make the diagram more readable, it actually creates confusion in the mind of the modeler. An LDM viewed in Filtered IE might appear to be a CDM but, in fact, has a relational structure enforced. A true LDM with the foreign keys hidden might be considered to be an incomplete model. • 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 – a standard data modeling notation for relationships and entities. 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 – uses associations instead of relationships. • E/R + Merise – both entity/relationship and Merise are used in the same model.

NOTATION POWERDESIGNER ERWIN Information Engineering (IE) Yes (called Entity / Relationship) Yes Filtered IE No No Merise Yes No IE + Merise Yes No IDEF1X Yes Yes Barker Yes No

9 Import / Export A modeling tool needs to allow the modeler to import and export various types of 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. All tools reviewed offer various levels of import and export. In the event that a modeling tool does not offer support for a specific type of file or database, there is a more generic metadata export and import supplied. There are also third-party companies that will help to provide the “bridges” from a metadata file into a needed specifically formatted file.

Database Support Since one of the goals of using a modeling tool is to work with a database (create, modify, understand and analyze), it is necessary that the tool support a variety of databases. Even more importantly 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. In order to best migrate a database, use the modeling tool to reverse engineer the older system, generate LDMs and CDMs, as necessary, 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 take this concept further, 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 a core and external definition files, it is possible for the customer to add support for a database that might not be supported from the 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 though Sybase does not upgrade the product. The database definition files are stored in the file system as XML files and can be modified. ERwin does not support this ability.

PowerDesigner and ERwin support a large number of databases, however, PowerDesigner supports the latest version of over 60 RDBMs with updates to this support structure occurring every 6-9 months.

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 datatypes and nuances (storage, partitions) that are in Oracle 11g. The other tools evaluated do not support all Oracle 11g idiosyncrasies.

10 As an example of the support offered by PowerDesigner for Oracle 11g, see the below illustrations:

Figure 6: PowerDesigner Oracle Physical Options

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.

Figure 9: PowerDesigner Oracle Datatype Examples 11 Repository (Collaborative Modeling) 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 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 would allow for collaborative modeling. In this fashion, the repository keeps the most current version of a model. 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. Each time a model is put into the repository, the changes should be presented.

PowerDesigner is available with a repository. It is available as a separate module but a repository with a modeling tool is necessary. PowerDesigner implements full impact analysis through the repository—this is the only way that PowerDesigner is able to provide all the functionality for impact analysis. 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. There are several supported databases that may be used for the repository, include Sybase ASA, Sybase ASE, and Oracle. 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 placed in are highlighted with the option to accept or reject any or all changes.

The repository presents in the tool 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.

The repository for ERwin is Model Mart. It is a separate tool and provides model management functionality for Data Modeler (the tool reviewed here) and Process Manager (the process modeling tool available from CA). CA supports version management in the Model Manager, including locked versions, difference reports, and model rollback to previous states. CA also provides undo and redo functionality over the life of a model. While CA touts this as a benefit, undo functionality from one modeling session to the next can present problems. Versioning would be a better way to ensure changes can be rolled back.

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.

CA ERwin Model Navigator The ERwin Model Navigator is a product for sale from CA that gives a read-only ability to open and review ERwin Data Modeler and ERwin Process Modeler files. The tool also allows for the creation of reports in HTML and PDF formats.

Sybase PowerDesigner Viewer The PowerDesigner Viewer is a free download from the Sybase website that provides a rich-client viewer to read any PowerDesigner model, backwards compatible from the latest version. The tool allows for reading files as well as checking out models from the repository. The tool also allows for creation of reports in List, HTML and RTF Formats.

12 Sybase PowerDesigner Portal Additionally, there is the Sybase PowerDesigner Portal, included with all Enterprise versions of the product. This server compliments the repository server, and allows you to view the contents of your PowerDesigner repository dynamically from any web browser. Role-based security ensures metadata is protected. CA ERwin does not have a Web portal technology available at this time.

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 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. To create a model-driven environment, however, more customization is needed. Extensibility exists in a variety of perspectives. Databases 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.

PowerDesigner has vast amounts of customization capabilities. To start, look at the architecture of PowerDesigner. It has a core program file that reads “resource files” in order to perform various functions and support different databases. PowerDesigner uses these files to define the objects for each model and the methods for generating and reverse-engineering them. The resource files are XML files that can be viewed, edited, copied by experienced users.

Specifically for databases, there is a resource file, or XML file, for each database supported. There is a file for Oracle 11g as well as a file for Oracle 10gR2. The resource files can be modified through any text editor but PowerDesigner supplies a resource editor that is accessible through the user interface.

PowerDesigner takes the extension and customization concept considerably further than its competitors. At any point in the modeling process, regardless of the type of model, metaclasses can be added. (A metaclass is a special kind of class that has, as its instances, classes. A class would normally have an object when instantiated. This is a concept that has its origins in object-oriented programming but extends to modeling. The instantiation of a metaclass, is a class, which, when instantiated, would produce an object.) A PowerDesigner modeler or administrator can create a metaclass, which would serve as the parent of a set of classes/objects to be created later. This can enforce standards and specifics to the organization’s modeling rules. The benefit is that all classes from that metaclass would have the same characteristics and can enforce standardization throughout the organization.

Stereotypes, in modeling, are created from classes or metaclasses. Stereotypes are typically used for an instance of a class or object. They are typically used for sub-classification purposes. PowerDesigner supports full stereotyping as well.

PowerDesigner permits user profiles to be created. These profiles standardize look-and-feel of the modeling environment. Display preferences, model options, check model and other PowerDesigner attributes can be stored and deployed to users as needed.

ERwin has customization for toolbars and the general modeling environment. Beyond that, though, the tool falls short in terms of extensibility and customization. ERwin is reasonably effective as a “vanilla”modeling tool, but should not be considered for complex environments that require adapting the tool to the environment.

13 Business Process Modeling While business process modeling can be its own discipline, it should be in a tool that is being used for data modeling. To ensure that business rules are met, data can be associated with the processes directly in the model. The data elements that are added to the business process model (BPM) would be tied to an object-oriented model or a CDM. This further reinforces the need for a conceptual data model—the BPM and CDM linkages would ensure that, properly developed, the data elements that are used are actually needed.

Of the tools reviewed, only PowerDesigner has a business processing module.

Figure 12: PowerDesigner Allows Data to be Assigned to Business Processes

CA has a different tool for BPM—ERwin Process Modeler.

14 Object Oriented Modeling Object Oriented Modeling, a graphical analysis and display of a system, is not necessarily a “must-have” feature for a data modeling tool. However, it is quite important if an organization is going to truly follow a model-driven paradigm for building business applications. The Object Oriented Model (OOM) is able to provide the organization with a graphical depiction and analysis of a system. One use of OO modeling is the use-case diagram. Here, a modeler is able to work with the interactions between people and systems, associating data elements from various data models.

Object oriented modeling allows generation of code (C++, Java, C#, VM.NET), generation of conceptual data models, physical data models, XML models and other object-oriented models from a single object oriented model. Additionally, an object oriented-model can be generated from a CDM, PDM, XML model or other OOM. By adding object-oriented modeling into the model-driven disciplines in an organization, the mapping and analysis of people, systems and data become second nature.

ERwin does not offer object oriented modeling.

PowerDesigner has a complete object-oriented modeling module as part of the solution. It meets the needs specified above but is otherwise beyond the scope of this document. PowerDesigner provides many different diagrams, including use case, class, object, sequence, activity, component and others.

Enterprise Architecture Modeling Enterprise Architecture Modeling (EAM) is not a necessity for data modeling. However, it is an important part of building and maintaining data-centric systems. EAM is used to gain a better understanding of the architecture of the organization. It permits the analysis and documentation of the systems that are in use within an organization. With greater emphasis on corporate governance as well as compliance efforts, it is becoming more important to fully document systems. Change management requires an understanding of the systems in enough detail to be able to understand whether efficiency can be gained by modifying the systems. Through mergers and acquisitions, two completely different systems might need to be merged. EAM will help to understand where the merge points are in the systems, allowing the fastest and most accurate combination possible.

Only Sybase PowerDesigner contains an Enterprise Architecture Modeling function. PowerDesigner provides several different model types for EAM. There are business layer models (organization charts, communication diagrams), application and technology models. Using EAM in PowerDesigner allows the business to link elements and objects from the enterprise architecture models to data models, web services, object oriented models and so on. Having worked with organizations that were building complex models, I have seen, first-hand, the benefits of EAM. It is the necessary “glue” to tie together the models throughout the organization, ensuring business needs are met by the technology.

Dependency Matrices A dependency matrix is a tool that allows creation and review of links between objects. The objects can be in any kind of model—for example, a link can be created between a table in a PDM and an attribute in CDM. PDM tables and classes created from them (in an object-oriented model) can also be created. Dependency matrices provide a visual table that will show what objects are dependent on other objects.

A dependency matrix is not necessary for data modeling, per se, but becomes an important part of an organization that is creating or building a model-driven environment. Of the tools reviewed, only Sybase PowerDesigner provides a dependency matrix tool and it works across all modules (in other words, it is part of the core functionality of PowerDesigner).

15 Projects In a modeling sense, a project allows for a set of models or documents to be grouped together. The project functions as a single, convenient unit for multiple interconnected models. The project can be stored in a repository as a unit, ensuring all models are stored together. Dependencies and other links between models are automatically calculated and maintained when new project diagrams are created.

Sybase PowerDesigner supports projects as well as project templates. The templates can contain pre-defined models, content, rules and formatting. Templates would typically be used for enterprise architecture frameworks that require certain combinations of models. By combining projects and templates, the organization has a quick-start approach for standards-based and model-driven development. Furthermore, by adding framework matrices, the organization is essentially assured of following best practices.

ERwin does not support projects, project templates, frameworks or framework matrices. Since ERwin is a tool that only provides data modeling from the LDM and PDM perspectives, frameworks are not applicable. As with all tools, when properly created, the naming standards template will ensure proper naming while saving time for the modelers.

Framework Matrices A framework matrix is a visual grid in which boxes are completed based on various requirements in the organization. The framework matrix supports model development and documentation in a project and helps the organization to build out the project according to a set of pre-defined rules. The Zachman framework is a solid example of this.

Of the tools reviewed, only PowerDesigner supports Framework Matrices.

16 SUMMARY Creating a database is a simple task. Creating a database so that it properly supports business requirements makes it a more difficult task. Developers need to build applications that utilize the databases and database designers must create the databases efficiently. Modelers need to be able to communicate effectively with business stakeholders and developers throughout database and application development processes.

Choosing a data modeling tool is not a trivial task, even though it appears to be. Of the tools reviewed, both will create a logical data model, physical data model, propagate changes from one to another and create database scripts. Both will reverse engineer databases. But they are not at all equal.

Only one data modeling tool should be considered and chosen: Sybase PowerDesigner. Not only does PowerDesigner support all the facets necessary for basic and development, but it goes “above and beyond” in delivering the functionality to support a model-driven architecture. PowerDesigner allows conceptual data modeling to be performed in the same tool as logical and physical data modeling. Data elements can be tied to business requirements and classes can be created to jump start development through Business Process Modeling and Object Oriented Modeling (respectively). Add in the functionality provided by User Profiles, Projects, Framework Matrices and Dependency Matrices and the result is a complete modeling tool for the enterprise: PowerDesigner.

ABOUT THE AUTHOR Joe Pearl has over 21 years experience in the software industry including six years experience with data modeling tools and the Zachman Framework. Joe has contributed to data modeling certification programs, and delivered a number of data modeling training courses in his career. He is a proficient user of Computer Associate’s ERwin, Embarcadero’s ER/Studio, EA/Studio and Sybase PowerDesigner. Joe holds a B.S. from Tulane University in New Orleans. Currently, Joe is applying his knowledge and skills to the adoption of Enterprise 2.0 technologies. He can be reached at [email protected].

17 Sybase, Inc. Worldwide Headquarters One Sybase Drive Dublin, CA 94568-7902 U.S.A 1 800 8 sybase

Copyright © 2010 Sybase, an SAP Company. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo, PowerBuilder and PowerDesigner are trademarks of Sybase, Inc. or its subsidiaries. ® indicates registration in the United States of America. SAP and the SAP logo are the trademarks or registered trademarks of SAP www.sybase.com AG in Germany and in several other countries. All other trademarks are the property of their respective owners. 11/10