ERwin r9 to ER/Studio v9.5! Comparison Guide!

Transcription

1 Enterprise Architecture. Modeling! ERwin r9 to v9.5! Comparison Guide! Dr. Nicholas Khabbaz! François Cartier! e-modelers, Inc.! 4900 Hopyard Road. Suite 100! Pleasanton. CA 94588! Tel ! !! ERwin r9 to v9.5 Comparison Guide! 1 Page!

2 ERwin r9.0 to v9.5 Comparison Guide 2

3 Introduction In this paper, we propose a guide for comparing the ERwin r9.0 and v9.5 modeling tools, based on both tool and project requirements. The comparison covers only a limited set of key features that are either frequently used, or of importance in different modeling projects such as enterprise data modeling, data governance and master data management. Both tools have a rich set of features. This guide may be used as a template that can be refined and expanded to create a comprehensive comparison of ERwin r9 and v9.5 based on a set of tool and project requirements. We propose the following process: Start by defining: The tool requirements, and The type of projects that the tool will be used for Identify and assess the key features that are necessary to meet the tool requirements: Start with the Key Feature Differences section in this report Add / delete key features to align them with the tool requirements Perform tests to add or enrich the content Identify and assess the key features that are necessary to meet the project requirements: Start with spreadsheets similar to the ones used in the Product Capabilities vs. Project Portfolio section in this report Add / delete key features to align them with the project requirements Perform tests to populate the spreadsheets Compile the results in a spreadsheet such as the one in the Product Capabilities vs. Project Portfolio section If no tool emerges as a clear choice, use a scoring method to make a decision: Provide a score and weight for each relevant feature that meets the tool requirements, and come up with a total score for each tool Provide a score and weight for each project, and come up with a total score for each tool Combine the scores with weights such as 30% for features and 70% for projects 3

4 Key Feature Differences Usability Underlying Tool Structure provides an underlying object-oriented like structure around model object types, model objects, object properties, and binding between objects that is reflected in the user interface to make it quite consistent and easy to use. ERwin provides an underlying structure around model object types, model objects, object properties, and links between objects that is internally consistent but not as well reflected in the user interface. The consistent user interface in and the consistency of the binding operations across the tool reduces the learning curve and enhances the productivity of the user. Colors & Fonts Data Architect has a flexible method for setting up model object type fonts and colors. These settings could be different for each model/submodel. In addition, it provides the capability to set fonts and colors for specific objects such as an attribute in an entity. However, the set of font and color specifications cannot be saved or reused as an independent set. ERwin supports themes which are a named set of displayable model object type font and color default specifications, for fill, line/outline and text. An ERwin diagram font and color default specifications can be started by first specifying a theme, and then customizing the diagram specifications. 4

5 ERwin The ERwin theme is a useful feature that provides consistency of colors and fonts across multiple models. Model Layout Data Architect provides a number of layout options. When partial layout is applied, entities/tables do not overlap. However, relationships do overlap with non-selected entities/tables, which would later need to be readjusted by the user. ERwin also provides a number of layout options. When partial layout is applied, entities/tables overlap with non-selected entities/tables and subtyping symbols. Core Modeling Submodel Nesting In Data Architect, a model may contain a hierarchy of nested submodels. There is no limitation to the number of submodels or the nesting level of submodels. All nested submodels are synchronized with the main model at all times. ERwin s Subject Areas are all independent of each other and not synchronized with each other, except with one exception: one subject area can be marked as auto populate, becoming the main subject area. Multi-level submodel nesting is a strong feature of Data Architect. Submodel nesting can be leveraged to provide multiple perspectives of the same model while ensuring that submodels are synchronized at all times with the main model. This feature becomes very useful when developing very large data models supporting, for example, an enterprise data warehousing project. Such models may actually be developed and managed from the lower level nested submodels while the main model is used for synchronizing all the nested submodels. 5

6 Compare & Merge The Data Architect Compare and Merge utility is very useful and widely applicable. It includes comparing and merging data models with database schemas and generating the required DDL for schema changes. With Release 9.5, forced mappings between two entities/tables, two attributes/columns or two views can be saved and viewed in the Where Used tab of the corresponding model objects. In ERwin, a similar Complete Compare feature compares all selected model objects, their associations and their properties. However, the Complete Compare displays more than is needed, leading sometimes to confusion for the data modeler. Synchronizations (equivalent to s forced mappings) are possible between two model objects of the same type but cannot be saved and are lost upon exiting Complete Compare. The Data Architect Compare and Merge and ERwin Complete Compare share a number of similar capabilities; however: ERwin ERwin s Complete Compare covers additional types of model objects such as domains, validation rules and default values, which in some cases, may prove useful. The Data Architect Compare and Merge is substantially easier to use. In addition, forced mappings can be saved, enabling a number of useful applications within different types of projects such as enterprise data modeling and data governance Views Data Architect supports both logical and physical Views. However, the query used in Materialized Views does not use the same editor as the regular Views. ERwin does not support logical Views. ERwin s reverse engineering of Views lacks some basic rules. On the other hand, the display and handling of Materialized Views in ERwin is similar to those of regular Views. 6

7 ERwin supports logical Views which, in some cases, are necessary to describe and model data requirements. Reverse engineering of Views is handled relatively well, a useful capability in certain applications. ERwin s handling of Materialized Views provides consistency and a good alignment of a physical model with an operational database. Model Object History provides the option of maintaining a user-defined model change history each time a model is checked into the repository. ERwin keeps track of major history events for selectable model object types including the model itself, entity/table, attribute/column and view. These events include model object creation, linkage, transformation, split and import. The data modeler can add a comment to each event tracked. ERwin The ERwin model object event tracking is quite useful for certain applications such as data governance, data stewardship and audit Denormalization Mappings In Data Architect, denormalization mappings keep track of the mappings between model objects after a roll down / roll up, or a horizontal / vertical split. These mappings can be viewed in the Where Used tabs of the corresponding objects. ERwin has similar denormalization capabilities as, but does not preserve the mappings. 7

8 Data Architect s denormalization mappings is a very useful feature as it provides the means to document and maintain the traceability between a normalized logical model and a denormalized physical model. Such traceability is an essential link that supports business agility; i.e., quickly translating changes in business requirements to a logical model then mapping those changes to a denormalized physical model. Reporting Data Architect has a basic reporting tool that is easy to use and quite versatile. Reporting that is wider in scope covering multiple data and/or business process models is supported by Portal. ERwin uses SAP Crystal Reports. However, creating a report entails navigating a complex set of metamodel objects, which has typically become too complex to use for a logical data modeler who is not versed in SQL. reporting is relatively easy to use. The split between basic reporting used primarily by a data modeler in model development, and enterprise-wide reporting used by a wider set of roles for a variety of purposes around model analysis, is quite effective. Attachments enables different categories of attachments such as documents, URLs, and list of values to be associated with different model objects. In addition, attachments can be grouped into attachment types which could, in turn, be associated (restricted) to different model object types. ERwin has a similar capability, user defined properties, or UDP, albeit more restricted. For instance, a UDP can be associated to only one model object type, either logical of physical, but not both. Two value list UDP s for different object types can have the same name, but their list of values has to be kept in sync manually. 8

9 has a flexible attachment feature which is very useful and should be widely used. Attachments can be used to cross reference model objects with internal information and documents such as business requirements, use cases; and external documents such as market and regulatory information. Resulting benefits are many including improved traceability from business requirements to logical to physical models, alignment with industry standards, improved data administration, improved communication among the model stakeholders, to name a few. Rules and Constraints In Data Architect, a rule can be created and bound to entities, tables, attributes, columns and domains. In ERwin, there are no entity level rules or constraints in the logical model, but one can create table level validation rules (constraints) in the physical model. Validation rules include a list of reference values, a range defined by a minimum value and a maximum value, or a user defined expression. The ability to define rules in the logical model and associate them to different logical model objects, i.e., the capture of rules at an early stage in the data modeling process, enables a better alignment with the enterprise conceptual data model where enterprise level rules are defined. Reference Values In Data Architect, reference values are defined in the data dictionary. They can be bound to attributes/columns and domains. Reference values are not generated in the DDL, but are generated as enumerations in the XML. In ERwin, reference values and rules are merged into validation rules, enabling reference values to be always in sync with the generated validation 9

10 rule. In addition, validation rules can be generated as look-up tables in the DDL. ERwin The generation of look-up tables in the DDL is quite useful and enables an effective mapping between the physical model and a corresponding database. Domains Data Architect domains are templates for attributes. supports domain folders that are key in organizing large numbers of domains that could emerge in a large data model. Attachments, rules, defaults and other object types could be bound to domains. In addition, supports sub-domains along with a flexible way to synchronize these sub-domains with their parent domains. ERwin supports a similar domain capability. One can define an attribute definition template in a domain which may include macro variables that insert entity or relationship metadata in the target attribute definition. On the other hand, domain folders are not supported. Domains are an important feature that substantially enhances the quality of a data model, if properly used and managed. provides a domain folder capability that is easy to use and most effective even when managing a small set of domains. Naming Standard Templates has a Naming Standard Template feature that enables the definition and application of naming standards in logical models, physical models or the transformation from logical to physical models. It also incorporates a primary/secondary property of an abbreviation that helps map physical abbreviations to a logical equivalent. ERwin has a similar capability: Naming Standard Metafile. It incorporates a glossary that applies to transforming names from Logical to Physical. In 10

11 addition, ERwin has a naming standards compliance checker that can report on naming irregularities such as a classword not found in the glossary. ERwin In, the Naming Standard Template can apply within a logical model or a physical model, in addition to enforcing naming standards going from a logical to a physical model. This is useful since in some cases, to ensure that the naming standards are enforced within the logical model as the model is changed. In addition, the primary/secondary property of an abbreviation may sometimes be useful in reverse engineering, in order to make the right decision regarding the name of a logical entity or attribute. On the other hand, the incorporation of a glossary in ERwin, if properly managed, and a corresponding naming standards compliance checker, could be used to improve the quality and consistency of the naming standards. Macros and Scripts Macro and Script languages incorporates a macro language called SAX Basic. The language is similar to Visual Basic. It uses a library built on the Microsoft COM interface language. ERwin incorporates different proprietary languages, distinguished by a special character in front of the command/function name. One such language is used for script and trigger templates. 11

12 The macro language is substantially easier to use than writing proprietary scripts. Furthermore, the language is very well documented. Finally, the COM interface enables easy integration with Microsoft products such as Excel, which is used in many applications for import/export into the data model. Sample Macros Data Architect provides a set of macros that ship with the product. Macros include a variety of import/export model objects to Excel, as well as productivity-related macros that perform repetitive functions on model objects. ERwin provides referential integrity trigger template scripts. Other macro scripts can be obtained through user community discussion groups. ERwin can also export/import metadata to Excel through the MetaIntegration bridge. sample macros are quite useful across the different stages of model development. They can, and should be used to deliver a substantial modeling productivity improvement whenever an opportunity to do so arises. These macros can be changed relatively easily to meet specific data modeling requirements. Repositories Model Versioning Repository supports model change history encompassing descriptive text entered by a user when checking in a model. On the other hand, the Named Releases feature enables a user to save a snapshot of a model, providing a user-driven versioning mechanism. Model Mart automatically increments the version number of a model when that model is saved or checked in, thus providing a system-driven versioning 12

13 mechanism. The user can enter descriptive text related to changes in a version. Past versions of a model can be hardened to prevent accidental deletion. The user can also determine how much history a model version will contain and be saved in Model Mart. ERwin Model Mart provides an automated and frequent versioning of a model. Keeping version history could be helpful, but it has to be balanced against the repository performance degradation as a result of an excessive number of model versions. Object Mappings and Links Repository supports a one-to-many mapping between Repository model objects of the same type such as entity/table to entity/table, and attribute/column to attribute/column. The mappings are displayed under the Where Used tabs of the respective entities/tables. ERwin supports a one-to-one link between attributes/columns when data movement is enabled. An attribute/column can be linked to another attribute/column, based on selected properties, like the datatype. The link can be unidirectional, from a source attribute/column to a target attribute/column, in which case a selected property change from the source attribute/column modifies automatically the target s same property. It can also be bi-directional, in which case both attributes/columns selected properties are kept synchronized. The resulting links will show under the Where Used tabs. ERwin Entity level mappings are quite useful for projects such as enterprise data modeling or master data management, where an entity in an enterprise model can be mapped to multiple entities in other models, including reverse-engineered models. One-to-one links are also useful in certain implementations. They allow, for example, synchronizations between the columns of a master table and the columns of various other tables populated from the columns of the master table. 13

14 Enterprise-Level Objects In, all data dictionary object types can be promoted to the enterprise level through an enterprise data dictionary. Therefore data dictionary objects of different types (attachments, naming standards, domains, rules, defaults, etc.) may be bound to data model objects enterprise-wide across all data models in the repository that are bound to the enterprise data dictionary. ERwin maintains model templates that contain enterprise definitions for shared entities, domains, validation rules, default rules, a naming standards metafile, datatype standards, themes, user defined properties, macro scripts, user defined trigger templates, and color legends. Synchronization of a model with a template ensures that the model has all enterprise model objects associated with it. The user has control of when and what models are synchronized but not how they are synchronized. ERwin provides a flexible approach by maintaining a clear delineation between local and enterprise data dictionaries. Model objects can be bound to either a local or an enterprise data dictionary. In addition, macros can be leveraged to change the binding of data model objects between the two data dictionaries. An example is the change domain bindings macro. ERwin provides a wider selection of enterprise model object types including shared entities and re-useable color schemes. Support for shared entities can be very useful for certain projects such as enterprise data modeling where an entity may be propagated from an enterprise data model to multiple project-level logical models. 14

15 Portal Browsing, Searching and Reporting The Portal provides browsing of models, keyword searches, object drill down, and versatile advanced search and custom reporting. With the latest version of the Portal, the range of object types that are used for browsing, searching and reporting has been extended to include data dictionary type objects. ERwin Web Portal provides browsing, keyword searches, object drill down, and limited reporting. The Portal advanced search and custom reporting enable a rich set of valuable applications including standards compliance reporting and model consistency and quality reporting. Data Lineage Data Architect supports a visual data lineage within a diagram. The data lineage consists of the mapping between multiple source and target models and submodels along with specifications of the business and high level code documentation between sources and targets. In addition, data movement rules could be specified along with the source to target transformations. The resulting data lineage can be exported to Excel and imported into an ETL tool. ERwin visualization of data lineage is not in the data modeling tool but in the ERwin Web Portal. It is currently limited to the mapping of tables and columns between source and target models, and does not show transformations. In addition, data movement rules are not made visible on the Portal s visual mapping. 15

16 ERwin Data Architect has a strong visual data lineage capability that can be effectively used to plan the ETL development in a data warehouse, database migration, or other applications. Load strategies can be documented, data movement rules can be specified, and attachments can be used to provide a clear picture of the data lineage. ERwin s data lineage, being in the Web portal (as opposed to within a model) creates mappings directly on models in the Portal as opposed to imported copies of models. This avoids handling manually the occasional updates of imported source models. Supported DBMS Configurations DBMS supported ERwin version 9.0 DA version 9.5 Generic ODBC 2.x, 3.x supported, unspecified version Greenplum 4.x Hitatchi HiRDB IBM DB2 supported, unspecified version for I (5.x to 6.x), for LUW (9.1, 9.5, 9.7), for z/os (8.1, 9.1) Informix 9.x to 11.x ONLINE, 9.x, SE Interbase AS/400 (4.x, 5.x), for UDB (5.x to 9.x), for z/os (5.x to 10.x), for Common Server 2007, 2009, generic MS Access (use Generic ODBC) 2.0, 95, 97, 2000 MS SQL Server 2000, 2005, 2008, x, 6.x, 7.x, 2000, 2005, 2008, 2012 MS Visual FoxPro 2.x, 3.x, 5.x MySQL 5.x only 3.x to 5.x Netezza 4.6, 5.0, 6.0 Oracle 10g, 11g 7.x to 11g.x PostgreSQL 8.0, 9.x Progress 9.x, 10.x SAS supported, unspecified version Sybase Server ASA 12.5, 15 System 10, ASA 11 to 15 Sybase SQL Anywhere SybaseIQ 12.x Watcom, 5, ASA 6.0 to 10.0, Adaptive Server IQ 12.5 Teradata 2.6, 12, 13 NCR 2.4 to 2.6, 12.0, 13.x 16

17 Product Capabilities vs. Projects Enterprise Data Modeling Feature Importanc e ERwin Usability Model Display Options Medium More options for displaying model object types such as attachments Does not display User Defined Properties Submodeling Medium Supports multiple levels of submodels Supports only 2 levels of submodels Core Modeling Compare & Merge High Easier to use Highly complex Views Low Occasional use of logical views to represent high level requirements No logical views Data Dictionary Macros Repository Attachments Data Security Defaults, Rules and Constraints Reference Values and Domains Enterprise Data Dictionary High High Medium High Medium High Portal Reporting High An attachment type can be bound to multiple model object types Displayed separately from attachments; includes data classification; displayable in the model Rules can be generic and be associated with entities The rule associated to reference values can get out of synch when reference values are modified Cross-model search & modify through VB applications Cleaner and more effective approach More versatility in advanced search and reporting A User Defined Property can be bound to only one object type No Data Security feature separate from User Defined Property Rules are only for validation; not available for entities The validation rule and the reference values are always synchronized Query SQL tool is used to search across models; modifying through SQL is not recommended Wider selection of enterprise object types including shared entities and re-useable color schemes Basic reporting on all model objects 17

18 Data Governance Feature Importance ERwin Core Modeling Dictionary Visual Data Lineage Macros Repository Repository Model Templates High No model templates Views Attachments Data Security Naming Standard Templates Versioning and Named Releases Universal Mapping Low High Medium Medium Low High High High Portal Reporting High Logical views enable expression of data requirements and validation Covers a governance topic through one attachment type for all relevant model object types Compliance policies can displayed in the model. A Naming Standards Template can be used when reverse engineering a physical model into a logical model Visualization of data lineage is supported in the modeling tool; data lineage can also be exported Macros may be written to double check metadata level compliance and consistency across multiple models; macros can also update data dictionaries across models to enforce consistency (example: Reference Values) Prior versions of diagrams are not kept in the Repository unless saved explicitly as a Named Release Applies to entities and related model objects; synchronizations during Compare and Merge are retained. More versatility than ERwin in advanced search and reporting Consistency between data models can be controlled through model templates ERwin does not support logical views Covers a governance topic through multiple User Defined Properties; one per model object creating redundancy issues User Defined Properties cannot be displayed A Naming Standards Metafile can be used only for forward engineering Visualization of data lineage is supported in the Web Portal tool only; data lineage is not graphically represented in the modeling tool ERwin can only report on the consistency or compliance of one model object type at a time, because reports are SQL bound Prior versions of models are automatically kept in Model Mart unless manually deleted; prior model versions can be marked "hardened" Applies only to attributes and columns; synchronizations during Complete Compare are not retained Basic reporting on all model objects; inclusion of model and data lineage diagrams 18

19 Master Data Management Feature Importance Erwin Core Modeling Data Dictionary Visual Data Lineage Repository Conceptual Modeling Logical / Physical Synchronization Medium Low A Conceptual MDM submodel incorporating many-to-many relationships cannot exist along with a logical model where these relationships have been resolved makes it easier to reverse engineer legacy table/column names into proper entity/attribute names Object Naming High Legacy names cannot be hardened Compare & Merge Denormalization Mappings Reference Values and Domains Universal Mapping Enterprise Data Dictionary Low High Low Medium High Medium Comparing MDM with legacy models in is easier than in ERwin Denormalizations are more flexible, and mappings are retained in the "Where Used" tabs Generating INSERT statements from Reference Values cannot be done The Master Data model is imported in Other Sources in the Visual Data Lineage of Legacy diagrams; no hierarchy of data lineage transformations; related lineages have to be kept in independent transformations Effective support of mappings between Master Data model and legacy model entities/tables and columns/attributes No capability to share MDM entities A Conceptual MDM Model can exist as a diagram along with a logical model within the same Subject Area; only relevant Subject Area model objects can be displayed Legacy models cannot be reversed engineered into a logical model Name hardening prevents the alteration of existing operational database table, column, index and constraint names Resynch of Legacy models with MDM model requires going through Complete Compare which is difficult to master Transformations are not model objects and do not appear in the "Where Used" tabs INSERT statements can be automated from the value list validation rules to do initial loads of lookup and reference tables for the Master Data using a script The Master Data model serves as the source model for all legacy models that are transitioning to incorporate the MDM service; Diagrams can be used to show the step-by-step phased implementation of MDM in a legacy model, including database object adjustments for synchronization performance using a subject area with tables with duplicate names No entity level mappings Shared entity is an advantage, since the enterprise wide model template can be updated from the MDM model 19

20 Product Capabilities vs. Project Portfolio EDM Data Governance MDM Feature ERwin ERwin ERwin Usability Core Modeling Data Dictionary Visual Data Lineage Macros Repository Portal Model Display Options Compare & Merge Conceptual Modeling Denormalized Mappings Logical / Physical Synchronization Model Templates Object Naming Submodeling Views Attachments Data Security Defaults, Rules and Constraints Naming Standard Templates Reference Values and Domains Enterprise Data Dictionary Universal Mapping Versioning and Named Releases Reporting HIGH MEDIUM OR LOW 20

21 Conclusion Both CA ERwin r9 and Embarcadero s v9.5 are well developed, enterprisegrade data modeling products. In our comparison, we covered only a limited set of key features that are either frequently used, or of importance to different modeling projects. In addition, we looked at three specific types of projects: Enterprise Data Modeling Data Governance Master Data Management Whereas ERwin is an older product, has a significant user base, and many years of development effort, is consistently ahead when it comes to ease of use, as communicated to us by our clients. In addition, tends to be ahead when specific types of modeling projects are compared. This could at least be partly explained by Embarcadero s emphasis on regular interactions with its user communities, as well as their efforts to understand the challenges around different client projects, thus enabling to evolve focusing on meeting those challenges. CA ERwin and Embarcadero s product features and the resulting benefits will continue to evolve over time. We will continue to monitor the progress of the ERwin and tools in terms of meeting the demands of the data professional. This whitepaper was updated in May 2013, and compares ERwin r9.0 with v9.5. Any updates after May 2013 are beyond the scope of this whitepaper. 21

22 Authors This white paper was developed by Dr. Nicholas Khabbaz and Francois Cartier of e- Modelers, Inc. Dr. Nicholas Khabbaz is a senior enterprise architecture consultant who has delivered training and consulting for more than 10 years. Francois Cartier is a Senior Data Modeling Consultant who has been an ERwin consultant for over 15 years. Some of our opinions are drawn from our collective experience in developing numerous data models in both tools, as well as input we received from many clients. e-modelers, Inc. is a professional services company specializing in enterprise architecture and modeling. We are located in Pleasanton, California. Please send us your comments to info@emodelers.com. 22