 | Level: Introductory Scott W. Ambler, Prectice Leader, Agile Development, Rational Methods Group, IBM
01 Jul 2001 The need to work with questionable legacy data designs is a fact of life. With an understanding of the common design problems that Scott W. Ambler illustrates and analyzes in this tip, you can arm yourself in the inevitable struggle against imperfect data designs.
Existing data designs, and even new data designs, are rarely perfect and are often significantly flawed. The reality is that most developers must tolerate an existing legacy design, one that is often difficult, if not impossible, to change because changes in the existing legacy design would necessitate corresponding changes to the legacy applications that access it. In my last tip, Challenges with legacy data, I explored some of the common problems that you'll run into with the data itself. In this tip I examine common data design problems that you are likely to experience: They're summarized in Table 1. In the next and final tip in this three-tip series, I'll explore potential solutions and tools to address these problems. Table 1. Database design problems
| Problem | Example(s) | Implications | | Database encapsulation scheme exists |
- Access to the database provided only through stored procedures. For example, to create a new customer you must invoke a specified stored procedure.
- Access to views on the database is permitted, direct table access is denied.
- The database must be accessed via an API implemented by a C or COBOL wrapper that in turn accesses the database directly.
- The database must be accessed via predefined data classes/objects.
|
- To enable container-managed persistence (CMP) in an EJB environment, the encapsulation scheme must be made to look like a data source that your persistence container recognizes. Otherwise you'll be forced to take a session-bean managed persistence (SMP) or bean-managed persistence (BMP) approach.
- The encapsulation scheme will likely increase the response time of database access.
- The individual components of the encapsulation scheme may not be able to be included as a step in a transaction.
| | Naming conventions | Your databases may follow different naming conventions from one another, and likely do not follow common Java naming conventions. | - The deployer(s) will need to understand all relevant naming conventions.
- Political pressure may be put on your team to follow inappropriate corporate data naming conventions for use with your objects.
| | Inadequate documentation | The documentation for your database is sparse, nonexistent, or out of date. | - A significant legacy data analysis effort will be required to determine the proper usage of each table, column, and stored procedure within your database.
| | Original design goals at odds with current project needs | The legacy database was built for internal use by data entry clerks to capture customer orders in batch mode, whereas you are building an 24/7 order-entry application to be deployed over the Internet. | - Good luck, you'll need it.
| | Inconsistent key strategy | Your database uses natural keys for some tables, surrogate keys in others, and different strategies for surrogates keys when they are used. | - Developers must understand and then appropriately code support for the various key strategies for their objects.
- Key-generation code increases in complexity to support the various strategies.
- Additional source code to validate that natural keys are unique will be required.
- Relationship-management code increases in complexity because you can't code and then reuse a single approach.
|
Note: This tip was modified from the Mastering Enterprise JavaBeans 2/e, to be published in autumn of 2001.
Resources - Object technology is the most common environment for the development of new software systems, while relational databases are still the preferred approach for storage of persistent information. This article by Scott W. Ambler shows how to map objects to RDBs.
- Read about the object-data divide and how to overcome it in your EJB projects in two of Scott Ambler's tips from April 2001:
- Find all the nuts and bolts you need for using Java to develop DB2 Universal Database applications at the Java Enablement with DB2 page.
- With DB2 Data Joiner middleware, a single SQL statement can access and join tables located across multiple data sources (including databases from vendors other than IBM) without needing to know the source location. With only one API to deal with, application development is easier: You tell your application how to talk to DataJoiner, and DataJoiner talks to all the different databases in your organization.
About the author | | | Scott W. Ambler is a Practice Leader for Agile Development within the IBM Methods group. He develops process materials, speaks at conferences, and works with IBM clients worldwide to help improve their software processes. Scott is author of several books, listed on his Web site at www.ambysoft.com. Scott is also a recognized Ratonal Thought Leader, whose homepage may be viewed here. |
Rate this page
| |
