Full-function tools trade off flexibility; the Holy Grail in modeling tools reads diagrams, builds database, is based on an open dictionary - Data Resource Management: Data Modeling Tools

Software Magazine, Jan, 1991 by Alan Winston

FULL-FUNCTION TOOLS TRADE OFF FLEXIBILITY

Data modeling is just one step in the application development cycle, but it is an important one. Briefly, a data model will emerge as diagrams, called Entity/Relationship Diagrams (ERDs), showing how data entities relate. Data entities exist even in completely manual systems. For example, a valid ERD can be drawn showing the relations of all your socks to all your shoes (a many-to-many relationship). ERDs get more useful as entities proliferate.

Data modeling differs from data-flow analysis. A data-flow diagram represents process, showing the path the data takes from one application to the next. A data-flow diagram, for example, could show timecard data going through input, passing on to a payroll-calculation program, passing on to update the year-to-date earnings, and eventually coming out of a payroll check-printing program.

An ERD could show a one-to-many relationship between the timecards and the cumulative year-to-date earnings record, and a one-to-one relationship from the year-to-date earnings to the W-2s. Many-to-many relationships are more scarce, but a good example is the connection of inventory information to warehouse pick lists. The pick list can refer to multiple items, and the same items can appear on multiple lists.

When these diagrams are complete, they show how data is connected: If we make a change here, what impact does it have over there? This can be a great help during the maintenance phase of the software life cycle. ERDs also show whether a database based on this diagram is fully normalized. Many-to-many relationships may signify something wrong with the design.

There are several different styles of ERDs. Most ERDs are conceptually similar but use different symbols and syntax. Two popular styles are the Chen ERD and the Bachman ERD.

ERDs are often produced manually with pencil and paper. This is problematical with real-world data, because there is too much of it to fit on one page. Also, any change or mistake requires redrawing the whole thing. There is also no way to enforce consistency among multiple diagrams.

Data modeling software products, which have become available in the last few years, generally assist in development or maintenance of large mainframe applications. Interestingly, these products typically run on MS-DOS or Unix platforms, rather than on the target machine itself.

Some of these products run standalone, taking input only from the keyboard and mouse, and producing only diagrams as output. Others are tied in with a data dictionary or repository. The Holy Grail for data modelers is a product that "understands" the diagrams (or diagram information from the dictionary), builds the database itself and uses an open standard for the dictionary. This enables products from other vendors to work with the information. The packages that approach this capability generally use a proprietary repository, which ties the user to a particular product set and sometimes a particular methodology.

Choosing a data modeling package is not easy. Users may need training in the methodology before they receive training for the tool. And because data modeling is complex, a user may not be able to determine if a product works well until he or she has worked with it for a few months.

"They all look good, they all advertise good, but when you really use them, there's a whole different story to tell," said Marvin Lerfald, a user from Woodbridge, Va., who is evaluating data modeling software.

Complicating analysis is the fact that the user is probably not the one who chose the tool as a corporate standard. Developers who feel that the methodology has been forced on them may not be as motivated.

VISIBLE ANALYST WORKBENCH

One user who did evaluate his modeling tool is Dale Hardy, a systems consultant at Hanover Insurance, Worcester, Mass. Hardy uses Visible Analyst Workbench from Visible Systems, Waltham, Mass., a Case tool that added data modeling with its recent 4.0 release. Workbench runs on PCs and PC local-area networks (LANs).

Hardy's group is charged with improving work flow from branch offices, and documenting Hanover's data model as a basis for new development. The intent is to make underwriting more automatic. Workbench "lends itself beautifully to this," he said.

Workbench can handle large, complex projects, Hardy said. "We have hundreds of entities and hundreds of relationships, too big to put down on paper--and who could read it?" Workbench allows the user to choose specific entities for a subset of the entire model, then automatically generates a diagram of just that subset.

"I also liked the way you could get into its repository," Hardy said. "We've adopted a project-management methodology and identified deliverables at several stages. This tool works nicely with that. You could set up a whole product using this tool. Since it works on a LAN, you could do the whole spec and other users can look at it. Sharing information makes things easy."