white paper
A Comprehensive Analysis of Sybase® PowerDesigner® 16.0 InformationArchitect vs. ER/Studio XE2
Version 2.0
www.sybase.com TABLE OF CONTENTS 1 Introduction 1 Product Overviews 1 ER/Studio XE2 3 Sybase PowerDesigner 16.0 4 Data Modeling Activities 4 Overview 6 Types of Data Model 7 Design Layers 8 Managing the SAM-LDM Relationship 10 Forward and Reverse Engineering 11 Round-trip Engineering 11 Integrating Data Models with Requirements and Processes 11 Generating Object-oriented Models 11 Dependency Analysis 17 Model Comparisons and Merges 18 Update Flows 18 Required Features for a Data Modeling Tool 18 Core Modeling 25 Collaboration 27 Interfaces & Integration 29 Usability 34 Managing Models as a Project 36 Dependency Matrices 37 Conclusions 37 Acknowledgements 37 Bibliography 37 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 Embarcadero ER/Studio compares to PowerDesigner InformationArchitect. In this review, I examine the capabilities provided by Embarcadero ER/Studio XE2, and by 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 ER/Studio repository and portal software is available for trial purposes, but I did not include it in this review, due to lack of access to a suitable DBMS.
Product Overviews Sybase PowerDesigner and Embarcadero ER/Studio XE2 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. They both provide essential collaborative features such as a repository, and make repository contents available via a web portal. However, when you look more deeply into how these features are delivered, you’ll see that ER/Studio does not match the breadth and depth of capability provided by PowerDesigner.
ER/Studio XE2 On their web site, Embarcadero describe ER/Studio XE2 as “the fastest, easiest and most collaborative way for data management professionals to build and maintain enterprise-scale databases and data warehouses. Built in facilities automate routine modeling tasks so users can analyze and optimize database and data warehouse designs faster than ever. With a server-side model management system and online portal, it is simply the most productive way to share, document and publish your models and metadata to distributed teams.”
1 The core of Embarcadero’s ER/Studio product line is: ER/Studio Data The core data modeling tool, providing logical and physical data modeling capabilities. Architect 9.0.1 Available with different levels of database support, listed here in ascending cost sequence: • Open source (MySQL and PostgreSQL) • Single-platform (Oracle, Sybase ASE, IBM DB2 for LUW, or MS SQL Server) • Multi-platform (all supported DBMSes) ER/Studio Viewer Provides a subset of the capabilities of ER/Studio Data Architect, including repository access. As the name suggest, the Viewer does not allow you to edit models, nor does it allow you to check models into or out of the repository. This is a paid product
ER/Studio XE2 extends the capabilities of ER/Studio Data Architect with additional components: Business Architect 1.7 A process and conceptual modeling tool Software Architect 1.0 An object-oriented UML modeling tool for application architects to visually analyze and design complex software applications Repository A server-side model management system that solves the day-to-day challenges of modeling in a team environment, where model collaboration, versioning, security and component reuse are vital Portal A web-based search and reporting tool used to access and query models extracted (ie: copied from) from the ER/Studio Repository MetaWizard An OEM facility built into ER/Studio Data Architect, to convert to and from the formats used by other tools, including most of their major competitors (including PowerDesigner) This can also be purchased separately, to enhance a standalone edition of Data Architect AppWave A software distribution facility that allows users to install software on demand
There is also an ‘Enterprise’ edition, which includes all the components of XE2, except for the MetaWizard and AppWave. To download ER/Studio XE2 from the Embarcadero web you have to register with the Embarcadero Developer Network. The downloaded file contains a separate installation for the three ‘Architect’ components. The product(s) install easily enough, though the experience is different for each component. My laptop had several expired ER/Studio licenses which complicated matters, so you may not have the same issues I did. I had to ask Embarcadero for a new license, and made sure I installed Data Architect before the other products. If you do need to request a new evaluation license, make sure it covers all of XE2, not just Data Architect. The evaluation license is valid for 15 days from the date of installation, and I know from past experience that Embarcadero can be persuaded to extend that deadline more than once for the right reasons. When I discuss ER/Studio with data modelers, the chances are that the Data Architect product is the only one they’re familiar with — Data Architect is the original ER/Studio product. Business Architect was developed several years ago (originally called EA/Studio), to support business process models and conceptual data models. Apart from the ability to import models produced by Data Architect, Business Architect has very little in common with Data Architect — they are completely different in architecture and user experience. ER/Studio Software Architect is another completely separate tool, which has no interaction with the other tools in ER/Studio XE2, other than the ability to import XMI models exported from Data Architect via the MetaWizard. This facility has not been examined during this review, so I cannot comment on how successful the transition from a LDM or PDM to a class model may be. During the review, version 9.1 of ER/Studio Data Architect was issued. The changes in this version are limited to enhancing the support provided for existing database platforms. For example, in SQL Server 2008 and later, the geometry and geography spatial data types are now supported. Once the evaluation license has expired, there is no access to any of the ER/Studio models you created. If you do need temporary read-only access to your models, I suggest you download the trial version of the ‘Viewer’ edition of Data Architect.
2 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 free 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. DataArchitect/DM The core data modeling tool, providing logical and physical data modeling capabilities. Core data modeling tool, providing logical and physical data modeling capabilities, and the dedicated XML Model. Includes support for every DBS listed in “Database Support” on page 18 DataArchitect/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 EnterpriseArchitect Extends the InformationArchitect edition to provide additional capabilities for Enterprise Architects
Figure 1. PowerDesigner editions
3 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. 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 <
4 Figure 2. Data modeling activities
ER/Studio 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.
5 Summary Matrix of the Data Modeling Activities depicted in Figure 1 Task/Product ER/Studio PowerDesigner Creation of a multi-level data Two tools required, with completely One tool is used to create all three architecture different interfaces: level of data model; each level is • Create the SAM in Business supported by a separate and distinct Architect purpose-designed type of data • Generate a Data Architect LDM model. from Business Architect The steps you would follow are: • Amend the LDM in Data • Create the SAM in the CDM Architect • Generate the LDM from the • Re-import the LDM into Business CDM Architect, and manually map to • Amend the LDM the CDM • Generate one or more PDMs • In Data Architect, generate the from the LDM LDM from the PDM See “Managing the SAM-LDM Relationship” on page 8 for more Impact analysis for a multi-level Impact Analysis is fragmented due Impact and Lineage Analysis data architecture to the use of two separate tools: provides a continuous trail, from • Business Architect maintains SAM to LDM to PDM(s), which can links between the SAM and a be interrogated from any point, copy of the LDM in any direction. The ‘where used’ • Data Architect maintains links information for a SAM entity, for between the LDM and PDM(s) example, will show the trail of dependencies through the LDM and Data Architect maintains links PDM(s), and any other associated between models within a single file, models. Additionally, PowerDesigner which can contain one LDM and provides a function to create an several PDMs updateable graphic (i.e. model) which depicts the Impact and Lineage Analysis. 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, and ER/Studio provides ‘business elements’ in ER/Studio Business Architect. 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, as is the CDM within ER/Studio Business Architect. I use the terms SAM and CDM interchangeably in this review.
6 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. 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 ER/Studio 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 use of a single tool, and also due to the loose coupling of logical and physical data models.
ER/Studio ER/Studio uses two separate products to manage the three layers — the SAM is supported by a Conceptual Data Model maintained in ER/Studio Business Architect, and the LDM and PDM are maintained in ER/Studio Data Architect. The linkages between the SAM and LDM are maintained in Business Architect, by generating a LDM from the SAM, or by importing a LDM from Data Architect and creating mappings. The linkages are not visible from within the LDM in ER/Studio Data Architect. In ER/Studio Data Architect you can generate a PDM from a LDM or vice versa, and this takes place within a single file. The file can contain a single LDM and/or multiple PDMs. The linkages between models are based on the object names; the table name is held as a property of the entity, and the entity name is held as a property of the table. The “where used” feature in Data Architect relies on this — see “Dependency Analysis” on page 11. For example, I renamed an entity in the LDM from ‘City’ to ‘Place’. When I compared the logical model to the physical model, it could no longer match up the ‘Place’ entity and the ‘City’ table; I had to manually match the two objects. In PowerDesigner, the link between objects does not depend on matching up object names.
PowerDesigner PowerDesigner extends the types of model provided by ER/Studio, to include a dedicated XML model. 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.
7 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 ER/Studio provides great support for tightly-coupled logical and physical data models, and merging models together (via the sync facility), but it cannot compete with PowerDesigner’s link and sync technology in being able to truly separate the logical view from the physical, allowing for greater expression without loss of fidelity on the physical data model side, and allowing for multiple physical models to be in sync with the same conceptual.
Managing the SAM-LDM Relationship I used a realistic scenario to examine the support for integration between a SAM and a LDM. I used an existing LDM to form the basis for a new SAM — working ‘bottom-up’.
ER/Studio Business Architect allows you to import a LDM from Data Architect, and convert it to a SAM. This worked fine, except that only two of my 14 domains were imported into Business Architect; I chose the option to create them as both domains and business elements. It may be coincidence, but the two domains that were successfully transferred were the only domains that did not have a ‘character’ data type. In Business Architect, the SAM can only be presented using Barker notation (see “Modeling Notation” on page 21), which is not available in Data Architect. Using different notations for the SAM and LDM does help you differentiate between them, but it also means that you have two different notations to explain to users of your models. Within Business Architect, I added some common reference objects, which can be linked to any SAM. The first two were the domains and business elements created by the import, the others were business rules and stewards. I also re-imported the original LDM, this time as ‘external data objects’. I was then able to include all of these objects on the diagram, and link them to objects in the SAM. The easiest way to do this was to draw the links on the diagram. The browser view and part of the SAM diagram are shown in Figure 4. The links between most types of object can be shown on the diagram. However, there is no categorization of links. One link is the same as any other. Precisely what meaning a given link has may or may not be obvious to the user of the model.
8 Figure 4. CDM in ER/Studio business architect
Linking the conceptual data model to a business process model is basically the same task in both tools — a data object can be linked to an entity in the Conceptual Data Model. In PowerDesigner, this will cause a dependency to be created between the models, which will be shown on the project diagram (see “Managing Models as a Project” on page 34). The disconnect between Business Architect and Data Architect really started to show when I wanted to update the copy of the LDM stored in Business Architect. In Business Architect I can right-click the browser entry that represents the LDM, and select the option to update the external data objects. Here’s the first catch: it doesn’t know where the model is, so I have to browse to find it. There’ll be problems if I select the wrong model, I’m sure. Here’s the next catch: when I find and select the model, it asks me which parts of the model I want to import. It doesn’t know which parts of the model were imported before. The easiest thing to do is to select everything. That’s fine: the whole LDM has been updated in Business Architect, but what has changed? I have no way of knowing, unless I have both versions of the LDM, and compare them in Data Architect. Which parts of the CDM are not mapped to the LDM, and vice versa? I have to examine every CDM object to find out, perhaps via a report, because Business Architect does not provide a model-wide view of links. The same issues arise if you want to update the CDM entities from a LDM.
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. 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.
9 Figure 5. PowerDesigner entity with two new properties
Figure 5 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 36). It is not possible to enhance models this way in ER/Studio XE2.
Summary ER/Studio Business Architect provides a dedicated Conceptual Data Model, ideal for a SAM, and allows you to generate a SAM from a LDM, but you have to re-import the LDM and manually map it to the SAM. The mappings are only visible in ER/Studio Business Architect, not in ER/Studio Data Architect, the product used to maintain the LDM. PowerDesigner also 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. Creating and mapping to a SAM is a much simpler operation in PowerDesigner, and the result has more integrity. If you need to map additional types of object to the Sam, then you can create your own links. Both products allow you to link other objects, such as business rules, to a SAM. Only PowerDesigner allows you to link the same types of objects to the LDM and PDM as well.
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.
ER/Studio ER/Studio Data Architect offers reverse engineering from either a live database or a script file. In either case, the tool will properly build out a physical data model from the source. The connection to a live database can be either through ODBC or a native connection. Greater capabilities are available with a native connection. ER/Studio Data Architect 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 an LDM is also required, this can be generated from the new PDM.
10 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.
ER/Studio In ER/Studio Business Architect, the subject area model can be associated to process models, and to a set of business rules, though only within a given modeling workspace. These links are only visible within that workspace; if you’re not careful organizing your workspaces, you may have to replicate business rules and requirements across workspaces.
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, reusable across all model types, 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.
11 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. 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.
ER/Studio ER/Studio Data Architect supports logical and physical data modeling. For the modeler to be able to perform conceptual data modeling, it is necessary to use ER/Studio Business Architect. Business Architect and Data Architect have different interfaces, making it difficult to become an expert in all areas of data modeling. There is a disconnect between the two tools: links between the SAM and LDM can only be maintained within Business Architect, using a copy of the LDM imported from Data Architect. These links are not visible from within Data Architect. This results in fragmented impact analysis, and there is a risk that the copy of the LDM (and therefore the model mappings) held in Business Architect is not kept up to date. ER/Studio Data Architect has a “where used” function that will show exactly where an entity or attribute in the LDM is used in the PDM, but only if the PDM is in the same file as the LDM. However, since the CDM and class models are in other tools, it is not possible to trace an object all the way through its life. In Figure 6, we can see that the LDM entity ‘City’ has links to two tables of the same name, one in each of the two PDMs in the same file. Notice that the information provided is minimal, limited to the names of the tables. The icons on the right allow you to edit the details of the mapping, to open the properties of the tables, or to view the table definitions.
12 Figure 6. ER/Studio entity editor — where used
The matching up of objects in the ‘Where Used’ tab is purely based on name matching. If you rename the entity to ‘Place’, it will no longer show the ‘City’ table under ‘Where Used’, unless you change the ‘entity name’ property in the table definition. In ER/Studio Data Architect, you can only see dependencies between and within logical and physical data models, and they are only visible in the model in which they are defined. If you import part of model B into model A to record data lineage, that information is not visible to anyone who views model B. In ER/Studio Business Architect, you can only see dependencies within the CDM, and between the CDM and imported objects. It does provide some extra information compared to Data Architect, and the results can be filtered, exported and printed. There is an option to save the results as a diagram, but the diagrams I created nearly all only contained. The only exception I found was where an entity and external data object were related, both symbols appeared on the impact analysis diagram.
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 8. 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. 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 7 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’.
13 Figure 7. 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 8 shows the impact and lineage analysis for the same ‘City’ entity shown in Figure 6. 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 8. 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. 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 8? 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.
14 Figure 9 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 9. PowerDesigner impact and lineage analysis diagram
Figure 10. PowerDesigner impact analysis model in browser
Look at Figure 10. 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, ER/Studio Data Architect’s “where used” capability is up to the job. For any other circumstances, PowerDesigner’s impact and lineage analysis capabilities extend to all model types in a single integrated framework, ensuring complete analysis to implementation traceability is always available.
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.
ER/Studio ER/Studio Data Architect provides a facility for documenting simple data lineage, the movement of data in the real world. The ‘Data Lineage’ tab in the browser allows you to import fragments of other Data Architect models, and link them to objects in your model via transformations, using “Visual Data Lineage” diagrams. Figure 11 shows the data flow between the two ‘City’ tables shown in the ‘Where Used’ analysis in Figure 6. The symbol in the middle represents a data transformation, and shows the input and output columns. There is no logic stored in the transformation, and there is no link made between the input and output columns.
15 Figure 11. ER/Studio visual data lineage
Strangely, the information created using Visual Data Lineage is not visible in the ‘Data Lineage’ tab for the tables and columns. Instead, you’ll find it the ‘Where Used’ tab. The ‘Data Lineage’ tab is reserved for information extracted from data movement rules.
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
Figure 12. PowerDesigner mapping editor
16 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 ER/Studio Data Architect can capture the context of an individual model. ER/Studio’s mappings are text-based, not graphical, and invisible from the perspective of the related model(s). In PowerDesigner, the Mapping Editor or Data Movement Model capture any mappings created. Mappings 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. Both of the 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.
ER/Studio ER/Studio Data Architect has a “Compare and Merge” utility. The wizard is intuitive. It allows the modeler to compare or merge different models, regardless of where they are. The utility has filters so that only the differences are viewed, instead of all objects. Data Architect does not allow you to compare logical or physical data models with conceptual data models, since the CDM functionality is performed in Business Architect. In this sense, the tool is limited, but it performs well and produces expected results when comparing LDM-LDM, PDM-PDM and LDM-PDM. The compare/merge is bidirectional, so it allows you to decide which differences are applied, and which model to apply them to. ER/Studio Business Architect does not provide a merge or compare facility; it is not possible to compare two CDMs, or to compare a CDM with a LDM.
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 ER/ Studio, 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. ER/Studio Data Architect has the edge in one respect, as the merge is bi-directional. PowerDesigner has the edge in its ability to generate and update more types of models, and in its ability to compare models via the web portal. ER/Studio Business Architect, has no merge or compare feature.
17 Update Flows The boxes in Figure 13 represent the major components in an enterprise-level data modeling environment — these are all supported by both products. Each dashed line 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. In both tools, a standalone edition is available that only supports the data model component, and therefore only supports update access by modelers. In ER/Studio, that support is limited to logical and physical data 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. ER/Studio XE2 includes conceptual modeling and the web portal. The PowerDesigner ‘repository’ editions allow access to the repository and web portal. ER/Studio XE2 includes the ER/Studio repository and web portal. The Portal allows users to provide comments on definitions, which can be acted upon by modelers. The PowerDesigner ‘RE’ editions allow access to the repository and web portal. The PowerDesigner 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 ER/Studio 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. ER/Studio 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 ER/Studio 9 Adabas D Yes No Allbase/SQL G.1 Yes No ANSI Level 2 Yes No Hitachi HiRDB No Yes HP Neoview R2.4 No IBM DB2 for AS/400 Yes 4.x, 5.x IBM DB2 for z/OS formerly OS/390) 6.x, 7.x, 8.x, 9.x, 10x 5.x, 6.x, 7.x, 8.x, 9.x IBM DB2 for Common Server (aka 6.x, 7.x, 8.x, 9.0, 9.5, 9.7 5.x, 6.x, 7.x, 8.x, 9.x LUW) Informix SQL 8.x, 9.x, 10.x, 11.x OnLine, SE, 9.x Ingres 3.0.1 No InterBase 5.x 5.x, 6.x 4 Microsoft Access 2000, 2007, 2010 2.0, 95, 97, 2000 Microsoft SQL Server 2000, 2005, 2008, 2008 R2 4.x, 6.x, 7.x, 2000, 2005, 2008 Microsoft Visual FoxPro No 2, 3, 5 MySQL 4.0, 5.0 3.x, 4.x, 5.x Netezza 4.5, 5.0 4.6, 5.0 NonStop SQL Yes No ODBC 3 Yes Oracle 8i2, 9i, 9i2, 10g, 10gR2, 11g 7.x, 8.x, 9i, 10g, 11g PostgreSQL 7.3, 8 8.x Red Brick Warehouse 6.2 No SAS No No Sybase SQL Anywhere (previously 9, 10, 11, 12 5, 6, 7, 8, 9, 10 Watcom SQL or Sybase ASA) Sybase AS Enterprise 12.0, 12.5, 12.5.1, 12.5.2, 12.5.3a, 15.0, 11.0,11.5,11.9, 12.0, 12.5, 15.0 15.0.2, 15.5 Sybase AS IQ 12.5, 12.6, 12.7, 15.0-15.1,15.2 12.5 Sybase Avaki® Yes No Teradata V2R5, V2R6 12.0, V2R4, V2R5, V2R6
PowerDesigner supports all the database platforms listed above, in every edition of the product. With ER/Studio Data Architect on the other hand, the cheapest edition provides support for two open source DBMSes; a more expensive edition supports just one DBMS, as long as it is Oracle, Sybase ASE, DB2, or SQL Server. You do have the option of support for all the platforms listed above, which costs more than twice as much. 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. ER/Studio Data Architect supports fewer than 30 of the Oracle data types.
19 Figure 14. Oracle data types in PowerDesigner
Figure 15. Oracle data types in ER/Studio
As another example of the support offered by PowerDesigner for Oracle 11g, see the following figure.
Figure 16. 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.
20 Figure 17. ER/Studio table editor
ER/Studio separates physical options from partitioning. Partitioning schemes supported are Composite, Range, Hash, and List. There is no support for reference or system partition types.
Summary There is no doubt that the database support provided by ER/Studio Data Architect meets the requirements of many data modelers. The product supports the majority of features for the majority of DBMS versions in use. If your requirements stretch beyond the ‘majority’ in either respect, PowerDesigner’s more complete and extensible RDBMS support makes it 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”. • Filtered IE – found only in ER/Studio Data Architect, this notation hides the foreign keys. While this may appear to make the diagram more readable, it could create 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 – 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.
21 Notation PowerDesigner ER/Studio Data Architect Information Engineering (IE) Yes Yes (called Entity/Relationship) (James Martin and Crows Feet) Filtered IE No Yes Barker Yes Not available in Data Architect. Barker is the only notation available in Business Architect 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 — ER/Studio uses solid and dashed 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 for more than just a conceptual data model, or your organization uses the Merise methodology, PowerDesigner is your only choice.
Business Glossary & Data Dictionary 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 ER/Studio, 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. ER/Studio Data Architect has a Data Dictionary that provides a central location for storing common attachments, security definitions, defaults, business rules, reference values, naming standard templates, user defined datatypes, domains and reusable logic segments for things like triggers and procedures. This facility does provide some really nice reuse and globalized standards definitions that allow an enterprise to gain some governance advantage, but it does not address the classic data dictionary concept: the ability to define a single set of standard business terms and align them to data element definitions. PowerDesigner addresses the common reusable element concept through the use of a global library model, managed through the repository, and allows for easy reuse, and synchronization of reused elements back to the library through the us of shortcuts and replicas. PowerDesigner also provides a true data dictionary by allowing for business terms to directly influence the names of data items, that in turn serve a global reusable data definitions that can participate as attributes on entities. By being at the CDM or SAM level, these data definitions will link and sync with the logical and physical models that represent the projects of the data systems in the enterprise, and this keeps everything aligned to a common data dictionary.
Summary ER/Studio does not support anything equivalent to the PowerDesigner Enterprise Glossary. PowerDesigner is the only mainstream data modeling tool to offer a shared, linked, glossary of terms.
22 Specialized XML Modeling 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. ER/ Studio 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 ER/Studio. 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 ER/Studio.
Summary While ER/Studio does provide XML modeling support from the data modeling facility, it does not provide an XML- specific model. PowerDesigner is the only mainstream data modeling tool to offer a dedicated XML model aligned with physical data models for true representation of XML document definitions independent of, and in relation to, the relational data models that will support them.
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.
ER/Studio Data Architect ER/Studio Data Architect supports, rollups, rolldowns, horizontal and vertical splits. You cannot rollup a subtype into supertype, because it’s a non-specific relationship. This is also the case for tables generated from a many-to-many relationship in the LDM. If you meet this issue, resolved the many-to-many in the LDM, merge the LDM into the PDM, then carry out the roll-up. Denormalizations used to be listed in the Data Architect browser, which made them easy to find. Now there is no single list of the transformations in a model; they are only shown on the table’s ‘where used’ tab. From here you can see the pre- and post- state, and edit or delete the mapping. The transformation cannot be rolled back.
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 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.
23 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, but they can be traced (via the attributes in a CDM) to the LDM and PDM.
ER/Studio Business Architect ER/Studio Business Architect provides common Business Elements. The implementation allows for inconsistencies not often desired by analysts — by default attributes are allowed to override the name, description, notes and domain or data type of the associated business element. This will result in an attribute that is not the same as the business element. Also, Business Elements reference domains, but do not have a ‘width’ property. The width of dependent attributes is set correctly originally, but any changes made to the ‘width’ of the domain are not passed through the business element to attributes, leaving attributes potentially out of step with domains. There is no traceability from Business Elements to LDM attributes, except in Business Architect.
Summary ER/Studio’s support for elementary data elements is limited and may not lead to desired results. If you only use the Data Architect product, support is non-existent — you would have to use domains instead. Only PowerDesigner allows you to control the definition of data elements and attributes using them, to trace the lineage from your elementary data elements through to logical data model attributes, columns in physical data models, attributes in class models, and elements and attributes in XML Models.
Other Core Features
Core Feature PowerDesigner 16.0 ER/Studio Check model (validation) Yes — can customize checks, and Yes — only in Data Architect determine criticality. Auto-fix available on some checks. Can access objects from results list without closing the list Can select checks and objects, and No Yes change criticality. Can't auto-fix or customize checks. Cannot access objects from results list. Results list has to be closed before accessing any objects. Customizable data type mapping Yes — defined within the properties Yes — for each platform, can amend of the DBMS mappings from logical to physical datatypes via a simple matrix editor — used when generating models. Can save multiple versions of data type mappings Managed re-use of modeling Yes — PowerDesigner Library No patterns and reference models pushes reference models to all within data models repository users Multiple diagrams within a model Yes Yes Naming standards (enforce/check) Yes — using the Glossary No Business name to implementation Yes Yes name translations Replicate attributes between Yes — see above No — can drag and drop, but this entities (ditto columns and tables) copies the attribute — no link between original and copy attributes Replicate objects between models Yes No
24 Core Feature PowerDesigner 16.0 ER/Studio Shortcuts to objects in other Models Yes Not in Data Architect. CDM diagrams in Business Architect can include entities from imported LDMs — this link is shown in impact analysis (only within Business Architect) Subject areas (subsets) in a model Yes Yes Compare a model with an existing Yes DBMS only, not XML artifact such as XML or database schema, update the model and/or the data artifact as a result Filter 'Dangling Relationships' from Yes Yes schema generation Multidimensional modeling PDM icons indicate the ‘Dimensional Distinct Notation in LDM and Type’ for a table. PDM — when generating a The ‘stereotype’ facility could be used Dimensional PDM, ER/Studio infers to create specific symbols one of 6 dimensional table types for each entity. After changing the dimensional type for a table, a wizard can be triggered, to re-examine the dimensional type for downstream tables XML-specific physical data model Yes No Configurable support for technology Yes No — can amend processing pre- objects (e.g. creating generation and post-generation of PDM, DDL, or capabilities for unsupported DBMS) schema, but cannot configure DBMS support directly
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. 25 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.
ER/Studio The ER/Studio repository is a key component of ER/Studio XE2. The ER/Studio repository 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 the full contents of models. 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 (i.e., Compare and Merge, Subprojects, …). Security is implemented in the repository; users would have roles and privileges. Branching and sub-branching is supported. Other than models, the repository allows you to share what Embarcadero call ‘Enterprise Data Dictionaries’, which can contain common domains, attachments (see “Extensibility and Customization” on page 31), reference values and data security categories. These can be linked with models, so the contents can be shared between modelers.
Summary For version management and access control, the two repositories are comparable. However, the PowerDesigner repository extends the repository concept further, pushing information out to modelers, and facilitating the sharing of common models and the glossary.
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).
ER/Studio XE2 The ER/Studio web portal allows users to browse and search models, generate reports, and to add comments to model objects. The portal does not have real-time access to the repository — models are extracted from the repository in batch jobs, generally scheduled to run overnight.
Summary The ER/Studio portal does not provide all the capabilities provided by PowerDesigner. The ability of PowerDesigner web portal users to compare models and carry out impact analysis is a key differentiator between the two products.
Other Collaboration Features
Collaboration Feature PowerDesigner 16.0 ER/Studio Compare versions of repository Can compare any version of any Partial — can only compare the based models model to any version of any model latest versions of models, or earlier of the same type versions that have been given a unique name across repository, via 'set named release' Provide subscription for anyone to Yes No know when models are checked-in Impact and lineage analysis via Yes No repository Projects and frameworks matrices Yes No Share and apply a ‘house style’ for User profiles help you to standardize No the appearance and content of data the look and feel of your models and models to support
26 Collaboration Feature PowerDesigner 16.0 ER/Studio Share reference models and Yes No common business rules via a repository Direct access to models and links Yes — real-time access to the live Yes — via extracts from the between models via a portal, repository repository designed for use by non-specialist users of data models Read-only access to models Viewer software is free Viewer software is chargeable Search and impact analysis Can search models, compare Can search and browse models, and capabilities via a portal, designed models, follow all traceability links run reports for use by non-specialist users of and dependencies, and carry out data models impact analysis Control access to subsets of a model, Yes — down to packages within Yes — down to the level of perhaps individual model objects models submodels Integrate with LDAP/Active Directory Yes Yes for user authentication Resolve potentially conflicting Yes Yes changes made by different analysts Role-based management of access Yes Yes to repository content
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.
ER/Studio ER/Studio Data Architect Data Architect includes an OEM Metadata Integration Wizard1, enabling users to export and import to and from many other formats. You can import from and export to Microsoft Excel files using macros, and some sample macros are supplied.
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 ER/Studio 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. PowerDesigner provides support for the import and export of model content, such as entity descriptions and comments, is easy and wizard-driven. Generally, if you want to extract information from ER/Studio or update a model based on information held outside the tool, you have to write a macro. 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.
27 Summary Using the OEM Metadata Integration Wizard, ER/Studio Data Architect 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, or using the bridges sold by Reischmann. To export to or import from external files in ER/Studio Data Architect, you need to write your own macros. Compare that to the flexibility of PowerDesigner’s Excel export capability, available from any list of objects or sub-objects, or dependency matrix, and to the Excel Import Wizard available within PowerDesigner.
Other Integration Features
Interface and Integration PowerDesigner 16.0 ER/Studio Feature Built-in support for object security Yes Yes and regulatory classifications Design-time change management Yes Yes Dedicated data movement/ETL Yes No Model Document data movements Via the Mapping Editor or the Data Visual data lineage within a model, Movement Model (DMM). A DMM which can reference objects can convert PDM-PDM mappings imported from other models — into a model this lineage is only visible in the one 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 — from any object in any model No links between data model objects and business requirement models Build cross-references or traceability Yes — from any object in any model Business Architect allows you to links between data model objects cross-reference business rules with and shared business rules a CDM Mapping tool (connections between Yes To connect a model to a 'source' the objects in different models) source model is imported into the target model — this action is not visible from the source model Persistent impact analysis model Yes No Export data models in a format that Partial Via Meta Integration bridges — can be imported into other tools requires MetaWizard license (chargeable) Import existing data models created Partial Via Meta Integration bridges — by other tools cannot import PowerDesigner LDM, only CDM and PDM) Preview, print, and save model Yes Yes comparison results Integration with popular Eclipse Eclipse development environments (e.g. Eclipse) Integration with process and ? ? portfolio management workflows, and with IT configuration management
28 Usability
Property Editors Both tools provide tabbed editors for editing object properties. 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 31.
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 of an entity, 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 18 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.
Figure 18. 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.
ER/Studio ER/Studio only provides a grid-based editor in Business Architect. This is a simple facility, allowing you to edit a few textual properties.
Summary ER/Studio is limited in mass editing and list-based attribute editing capabilities that make handling large metadata sets easier and more effective. 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.
29 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.
ER/Studio ER/Studio allows you to set default colors, line thicknesses and fonts for a model or submodel, and to vary those style components for individual symbols. You can also determine the content (i.e. the properties to be displayed) of symbols on a submodel, but not individual symbols. Figure 19 shows two entities with different colors, but the same content. Note that foreign key attributes are displayed in a different color.
Figure 19. Colors and fonts in ER/Studio
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 ER/Studio, each diagram has default styles and profiles, inherited from a user profile or the model. The real difference in PowerDesigner is that 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 hiding an attribute on an entity symbol), you can. Figure 20 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.
30 Figure 20. Colors, fonts and style in PowerDesigner
Summary Both products allow you to customize the style and content of your diagrams. Where PowerDesigner has an advantage over ER/Studio Data Architect is the control you have over exactly which sub-objects are displayed on a symbol, and the 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 ER/Studio. 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.
PowerDesigner PowerDesigner has vast 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. PowerDesigner supplies a comprehensive resource editor that is accessible through the user interface.
31 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 adherence 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. Essentially, PowerDesigner allows any modeler to create new objects or properties of objects to include in their models. Once created, these objects and properties are treated in exactly the same way as any other object in PowerDesigner. They can be included in reports and dependency matrices; new objects have their own property sheets, which the user is in control of; they can be imported from or exported to Excel; they can replace existing properties; if the same objects and properties are defined for two related types of model, they are automatically transferred during model generation. 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. PowerDesigner permits user profiles to be created. These profiles standardize the 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. In addition, role-based profiles can be created, allowing the user interface to vary between different types of user.
ER/Studio ER/Studio provides some customization but not extensibility. Users can make small modifications to their working environment. The database support that is provided with the solution is produced and maintained by Embarcadero. A new database version will require an upgrade to the tool since the database definitions are not stored in an external file, in contrast to the way PowerDesigner functions. User customization consists of modifying toolbars and the general user interface. ER/Studio does not support metaclass creation (there is some support for metaclasses in EA/Studio, but this is a different tool and beyond the scope of this document). There is a facility called ‘Attachments’ within the Data Dictionary tab in the browser, where you can define additional properties that can be attached or bound to selected types of objects. Once populated, they’re not treated as properties in the same way as they would be in PowerDesigner. Instead, they’re treated as second-class properties, notes almost, relegated to the attachments tab of an object’s property sheet, and the attachments box within diagram symbols. They cannot be accessed individually.
Summary Customization and extensibility is one of the key strengths of PowerDesigner. ER/Studio Data Architect forces you to work in a particular way. PowerDesigner, on the other hand, allows you to work in a way that suits you. If you want to manage new objects, properties or object links, you can. If you want different groups of users to experience PowerDesigner in different ways, you can.
32 Other Usability Features
Usability Feature PowerDesigner 16.0 ER/Studio Projects to hold related models and Yes No — repository refers to folders as other files, managed as a simple ‘projects’ entity in a repository Contextual help Yes Yes Excel Import and export of Built-in Macros required — some supplied object properties Explorer browser object navigation Yes Yes Find objects in current model — Yes Yes search names Find objects in current model — Yes Yes search other properties Find objects in selected models — Yes Yes search names Find objects in selected models — Yes Yes search other properties Find/replace text in names No Yes Global find/replace text in a single Via RTF editing (e.g. in MS Word) No property Global find/replace text in other No Yes properties Lasso multiple objects and access Yes Yes right mouse options N-level undo/redo Yes Yes Object counts in Explorer Tree No Yes Object placement controlled by user Yes Yes Product documentation available Yes Yes Sample models supplied Yes Yes Spell check — for a property Yes No Spell check — global Yes No Spreadsheet-like editing Yes No Tabbed property editor Interface Yes Yes Annotate diagrams with additional Yes Yes symbols to improve communication Auto layout diagrams Yes Yes Auto-include new objects on current Yes Yes diagram (when created via browser) Auto-include objects on a diagram No Yes — option available for any (from child sub-models/packages) diagram Diagram overview window No Yes Diagram zoom in/out Yes Yes Diagram zoom window No Yes Edit properties within diagram Yes — for most properties Names only. symbols Press
33 Save diagram image in graphics file Yes Yes Configure user interface according Yes No to user profile Customizable display preferences of Yes — completely customizable Partial. Can select to hide or display any attribute/user-defined attribute ‘attachments’; cannot show or hide individual attachments, must be all or none. Can configure format (not layout) of properties on individual symbols, diagrams or models Customizable property sheets Yes No Customize toolbars and menus Full customization capabilities for Toolbar style only toolbars and menus; can be made Can assign macros to menus dependent on the profile of the user Expandable property editors Yes Yes Automation of common modeling Yes — converting an entity to a No tasks (such as merging or splitting relationship an entity, or resolving a many-to- many relationship) Multiple model diagrams visible at Yes Only one diagram per model visible same time at any time Templates for model creation Yes No Wizard-driven task completion Yes Yes Workspaces to hold working sets of Yes No models and projects Edit multiple concurrent property Yes — can edit properties for Can only open properties for one sheets numerous objects concurrently object at a time Auto-routing of link symbols Yes — automatically re-routed as No symbols on the diagram are drawn, deleted or moved Bridging of overlapping link symbols Yes No
Managing Models as a Project PowerDesigner provides the concept of a project. A Project is a container to hold related models and other files, managed as a simple entity in a repository, as a single folder in a local workspace, and as a file folder in your Windows file system. Projects are treated as container objects by the repository; they can be checked in and out, versioned and compared, the same as an individual model. Projects provide a special kind of diagram, where the symbols represent models in the project, or related models or external files, either within or outside the project. Figure 25 shows a typical project diagram, in this case showing the models created during this tool review, including the ERwin and ER/Studio models that contain a CDM imported from PowerDesigner. I drew the dashed lines to the ERwin and ER/Studio models, all the other lines were drawn by PowerDesigner, reflecting the dependencies stored in the models. The display preferences for the diagram were amended to show a particular property on each dependency, to make the purpose of each one clear. Figure 21. Sample project diagram
34 Every single model on this diagram (including the ER/Studio and ERwin models) is held under version control in the PowerDesigner repository. Double-clicking any model icon will cause the model to be opened, in ER/Studio or ERwin if necessary. Figure 22 shows the same project, as viewed in the Browser. On the local workstation, all the files, except those with a shortcut icon in the symbol (the ER/Studio and ERwin models) are stored in the project ‘directory’, a nominated Windows folder. The folder structure shown here is replicated in the repository. Figure 22. Project in PowerDesigner browser
ER/Studio Data Architect does not support anything equivalent to the PowerDesigner Project. ER/Studio Business Architect uses the Eclipse Modeling Framework, which supports a similar concept in the client, but has no equivalent in the ER/Studio repository.
35 Dependency Matrices As we saw above, it is important to be able to trace the dependencies for a given object. We can refer to this as vertically tracing dependencies. It is equally important to be able to trace dependencies horizontally, to take a particular type of dependency between two models, and to examine the objects that take part in it. Indeed, the horizontal dependencies within a model are also important. For example, we may want to see the dependencies between entities or attributes in a SAM, and the entities or attributes in the LDM that was generated from the SAM. We may also want to see the dependencies between domains and attributes within a LDM. You can access this kind of information within ER/Studio using reports and macros, but the tool doesn’t provide a standard mechanism for viewing and editing these dependencies. PowerDesigner does provide such a mechanism, the Dependency Matrix. This allows you to represent any model dependencies in a matrix. Usually, the dependency you’re interested in will be direct, such as the link between LDM domains and attributes, illustrated in Figure 23.
Figure 23. Domain/attribute matrix
Matrices can also depict indirect dependencies, such as the link from data items to entities in a CDM. In a PowerDesigner CDM, data items are instantiated as attributes in entities, so the relationship between data items and entities is not direct. To create a matrix cross-referencing data items with entities, you must trace the links through the metamodel using a dependency path definition, shown in Figure 24. The path starts with the data item, follows the ‘attributes’ property to discover all linked attributes, then follows the ‘entity’ property for each attribute to discover the name of the entity. The resulting matrix is also shown in Figure 24, with entities in the columns, and data items in the rows.
Figure 24. Indirect path definition
ER/Studio does not support anything equivalent to the PowerDesigner Dependency Matrix.
36 Conclusions 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. Data modeling is more than just designing and creating databases, though. We need to build subject area models and logical data models to communicate with other areas of the organization, and to integrate with the models that they produce. Most data modeling tools can’t compete in that world. Choosing a data modeling tool is not a trivial task, even though it appears to be. Both of the tools reviewed in this white paper are competent enough at the bread-and-butter modeling of databases for the majority of organizations. Both will create a logical data model and 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. Based on my evaluation of these products, PowerDesigner is head and shoulders above the rest. As a modeling and metadata management professional, I would highly recommend PowerDesigner. Not only does PowerDesigner support all the facets necessary for basic database design 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 Model Extensions, User Profiles, Projects, Framework Matrices and Dependency Matrices and the result is a complete modeling tool for the enterprise: PowerDesigner.
Acknowledgements The author wishes to thank Sybase and Embarcadero for their help in checking the accuracy of his statements about the products under review. He must also thank the following other organizations for sharing their expertise: IPL Information Processing Ltd, United Kingdom www.ipl.com Sandhill Consultants Ltd, United Kingdom www.sandhill.co.uk The author also wishes to thank Steve Hoberman for permission to use images and models from ‘Data Modeling Made Simple with PowerDesigner’.
Bibliography Hoberman, S. (2009). Data Modeling Made Simple (2nd ed.). Bradley Beach, New Jersey: Technics Publications, LLC. Hoberman, S., & McGeachie, G. (2011). Data Modeling Made Simple with PowerDesigner.
About the Author George McGeachie has worked in the field of data modeling and metadata for many years, in a variety of industries. George has used, implemented and tailored various data modeling and metadata management tools in that time, and has always been regarded as a power user for whichever tool is in use, finding new ways of exploiting their capabilities. George has recently cooperated with Steve Hoberman to produce a PowerDesigner-specific edition of Steve’s best- selling book ‘Data Modeling Made Simple’, called “Data Modeling Made Simple with PowerDesigner”.
37 Sybase, Inc. Worldwide Headquarters One Sybase Drive Dublin, CA 94568-7902 U.S.A 1 800 8 sybase Copyright © 2012 Sybase, Inc. All rights reserved. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo, Avaki, DataArchitect, PowerDesigner, Replication Server and SQL Anywhere 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 AG in Germany and in several other countries. All other trademarks are the property of www.sybase.com their respective owners. L03123 1/12