CHAPTER 8

Why do we need a data modeling tool?

A connected world

Integrated modeling

Needs specialized tools

From time to time, great debates arise in discussion forums about the pros and cons of various data modeling tools; inevitably, one or more people say that their favorite tools are the whiteboard and sticky notes. The whiteboard and sticky notes are great tools for workshop use, enabling rapid development of a model by a group of people without technical data modeling skills. Once a data model has been fleshed out on a whiteboard or a wall, it usually needs to be recorded in a more permanent fashion. Very often, the first choice is the old favorite analysis tool, the spreadsheet. Like the whiteboard and sticky notes, the spreadsheet is a great way of capturing information during and after a workshop, and doesn’t require expensive software licenses or special skills. By itself, however, it only provides a fraction of the capabilities required to construct, validate, communicate and use a data model effectively.

Why not use a drawing tool for data modeling?

You may be tempted to use a drawing tool, such as Microsoft® PowerPoint® or Visio®, or Smart Draw®. These products allow you to draw lines and boxes, and add text to diagrams; they can create diagrams that communicate ideas visually, and maybe even capture some additional information about some of the symbols. However, each diagram stands alone: if an entity appears on five diagrams, there is no connection between those five entity symbols. There is no way to ensure that those five diagrams are consistent in how they depict that entity, nor is there a way of knowing whether or not the entity also appears on a sixth diagram that you haven’t been told about. There is also no link from that entity to any database tables that were generated from it, and no link to the business processes that manage that entity. In short, the entities appear to live in a disconnected world. When it comes to managing change, that disconnected world gets very uncomfortable. As the models change, you have to manually change all the relevant diagrams and documents. Knowing which documents need to be changed and ensuring they remain consistent is a daunting task.

In Section III, you will see the different levels and types of data models, each with their own purposes and usage. There are dependencies between these different types of data models, between data models and other artifacts or models that represent other aspects of business and requirements, the enterprise and solutions architecture, and application design. The activities required to produce and manage data models are only part of a wider set of business and technology activities; integration with associated activities is key to the success of data modeling.

Without a tool that provides specialized support for data modeling, the data modeler cannot hope to work effectively in this environment.

Organizations take a variety of approaches to the enablement of data modeling, depending on the money available, and the perceived role of data models in their organization.

Key Features Needed in a Data Modeling Tool

With data modeling tools, you generally get what you pay for. The more you pay, the more features are provided by the product. The wider your use of data models within the organization, the more features you tend to need. If you’re a data modeling novice, you should really read Sections I and II before reading this section.

In this section, we list some of the key features that we should expect a data modeling tool to provide. There is no hidden meaning in the order of the lists, other than to ensure that related features are close to each other. The features are grouped into five categories – Core Modeling, Usability, Interfaces and Integration, Tool Management and Communication, and Collaboration. Chapter 9 uses the same categories to analyze the features provided by PowerDesigner.

Core Modeling

·         Construct different levels and types of data models, including any distinct notation and content required for each level

o        See section IV for details of the six types of data models

·         Generate a new data model from selected content in an existing data model

o        create and maintain links between the original model and the generated model

o        includes transforming a logical data model into a physical data model, and vice versa

·         Provide support for multiple data modeling notations, such as IDEF1X and Information Engineering

o        see Chapter 9 for more information about data modeling notation

·         Create subsets of a data model using selected entities or tables

·         Define validation and design rules, and use these to validate models

·         Automatically correct validation errors, where appropriate

·         Automatically enforce naming standards as model objects are created or modified

·         View and edit multiple model objects in a single operation, similar to editing within a spreadsheet

·         For physical data models, provide direct support for model objects specific to a technology, such as a given RDBMS or XML Schema Language

·         Configurable support for technology objects (e.g. Creating generation capabilities for unsupported DBMS)

·         Automated support for denormalization of physical data models, including rollback capabilities