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 |
|
|
| Naming conventions | Your databases may follow different naming conventions from one another, and likely do not follow common Java naming conventions. |
|
| Inadequate documentation | The documentation for your database is sparse, nonexistent, or out of date. |
|
| 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. |
|
| 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. |
|
Note: This tip was modified from the Mastering Enterprise JavaBeans 2/e, to be published in autumn of 2001.
- 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:
- Learn more about Agile Modeling at the Agile Modeling (AM) Home Page.
- For an introduction to object-oriented development, see The Object Primer, Second Edition (Cambridge University Press, 2001).
- Ed Roman, Tyler Jewell, Floyd Marinescu, and I co-wrote the forthcoming Mastering Enterprise Java
Beans, Second Edition (John Wiley & Sons, autumn 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.
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.