Production is the point at which the database and application are made available to the end user. Real tasks are accomplished in the production environment that directly affect the way the business operates. Real users are working with real data, and interfacing with real cus-tomers. Now is not the time for the company to be embarrassed when it finds that the customer cannot be properly served. Now is the time to impress the customer with a system that works well and enhances the company’s relationship with the customer by making life easier for all parties during real-world business transactions.
Although the production environment is considered to be the finished product, it is still subject to changes and improvements. Few systems, if any, are ever implemented into perfection in round one. Few systems ever actually see perfection. There is a difference between a perfect system and making the customer think you have a perfect system. It is a great practice to routinely search for ways to improve the new system because room for improvement inevitably exists.
4
THEDATABASEDESIGNLIFECYCLE
The following production evaluation checklist might assist in the evaluation of a recent imple-mentation, as well as the decision to make modifications in attempt to improve the system:
• Were there any errors during implementation?
• Does the end user have any complaints?
• How does the system seem to perform?
• Was all live data loaded or converted successfully?
• What is the average number of concurrent users?
• Are any areas for immediate improvement in database functionality or performance rec-ognized?
• Are any areas for immediate improvement in application functionality or performance recognized?
Figure 4.7 depicts what might occur if changes are not tested, or not tested thoroughly. In this example, the base table CLASS is involved. Version 1 of the database involves the CLASS table, which apparently needs to be normalized. Version 2 has split the CLASS table into three different tables: CLASS, CLASS_TYPE, and CLASS_LEVEL. The purpose of this split is to eliminate the occurrence of the duplicate values for each level and type values. Suppose that this change was made directly to production without testing (which should not occur, but does occur more times than you might think). Notice that the view CLASS_VIEW is based on the CLASS table. In version 2, the CLASS_TYPE and CLASS_LEVEL do not exist in the CLASS table because normalization has occurred. The view should have been redefined to query all three tables, joining them together using the TYPE_ID and LEVEL_ID columns. Also, a user input form has been based on the CLASS table, which is now invalid as well. The table has been normalized, but the view is invalid, and the end user cannot use form. Now the view and form must be fixed, which might also affect other objects in the database, or forms in the appli-cation. The point is that all changes might not be so obvious; there might be ramifications to even the simplest change if not tested.
FIGURE4.7
Production implementation with incomplete testing.
Summary
The system development process is used to design a database from a set of business rules, processes, and data that have been defined. A design methodology should be chosen to ensure that aspects of database design are considered, yielding a product of high quality. The tradi-tional method has three simple phases: requirements analysis, logical modeling, and normal-ization. The Barker method, involving concepts and deliverables similar to those of the traditional method, has the following phases: strategy, analysis, design, build, documentation, transition, and production. An adapted design method is one that does not necessarily conform to the exact steps set forth by other selected methodologies. An adapted method might be used based on the exact requirements of the system, the development software being used, and the experience of the development team. Each method might have different phases (or different names for the phases), but all have the same goal.
Some of the most fundamental concepts of database design include the definition of data, rules, data structures, data relationships, and views. Business process re-engineering and data-base redesign might also be involved when designing a datadata-base. BPR involves the reworking of an existing system with the intent of improving existing processes and data storage methods.
4
THEDATABASEDESIGNLIFECYCLE
Version 1 Version 2
After a database has been designed, it resides in one of three database environments: develop-ment, test, or production. Ideally, all three environments should exist for each database system.
It is important to keep all three environments in sync with one another in order to properly manage system changes throughout a system’s life. Changes should never be made directly to production. Once you have a good understanding of different methodologies, it will be easy to select one and adapt it to meet your needs if necessary. Then comes the interesting part—to begin modeling the system.
IN THIS PART
Chapter 5, “Gathering Business and System Requirements,” covers the process of gathering all the requirements necessary to design a database for an organization.
Chapter 6, “Establishing a Business Model,” discusses the basic concept of interpreting the information gathered from interviews in order to begin to model the business.
Chapter 7, “Understanding Entities and Relationships,” discusses data elements, or entities, and the different relationships that might exist between data in an organization.
Chapter 8, “Normalization: Eliminating Redundant Data,” covers the concept of reducing or eliminating the amount of redundant data in the database. This chapter provides an overview of the nor-mal forms, which measure the level of database nornor-malization. This chapter also covers denormalization, which is the allowance of redundant data to improve performance.
Chapter 9, “Entity Relationship Modeling,” explains how Entity Relationship Diagrams (ERDs) can be created to illustrate an orga-nization’s data. This chapter includes common conventions for dia-gramming entities and their relationships to one another.
Chapter 10, “Modeling Business Processes,” explains how business processes can be modeled. This chapter also discusses how busi-ness processes can be used to validate completebusi-ness of entities that have been defined.