High-Performance Web Databases

Design, Development, and Deployment

Sanjiv Purba

• Publisher: Auerbach Publications
• Year: 2000
• Print ISBN: 9780367455453
• eBook ISBN: 9781000654349
• Topic: Business
• Subtopic: E-Commerce
• Index: Business

As Web-based systems and e-commerce carry businesses into the 21st century, databases are becoming workhorses that shoulder each and every online transaction. For organizations to have effective 24/7 Web operations, they need powerhouse databases that deliver at peak performance-all the time. High Performance Web Databases: Design, Development, and

Section I

Database Planning and Getting Started

EFFECTIVE DATA-BASED SOLUTIONS IN AN ORGANIZATION MUST BE BUILT AROUND A SOLID STRATEGIC AND ORGANIZED FRAMEWORK. This must start with an organization’s executive team. From here, the solutions must sweep across the organization, touching all relevant departments, processes, procedures, and user interfaces (e.g., reports, Web pages). An organized planning phase offers an organization the opportunity to define data sources, data presentation, ownership, timelines, and conflict resolution mechanisms pertaining to corporate data. The data ownership list should also include resources who are knowledgeable about the information in the organization.

This section contains chapters that define how effective data solutions can be formalized and implemented across an organization. The cornerstone of this involves the selection and implementation of data development methodologies. Data development methodologies offer a powerful tool set to define the activities and the deliverables produced in data-related projects. In some cases, data development methodologies are a component of a larger, full-cycle development methodology. Because data is a corporatewide resource, it is also necessary to define standards for its capture and communication across the enterprise. This section contains three chapters that present approaches for satisfying both of these initiatives, as well as offering an approach for establishing an enterprise data management framework.

Chapter 1, “Database Development Methodology and Organization,” provides a framework for building databases from the logical to physical level at the enterprise level — with support for evolving technology architectures. The methodology is built around a generic system development lifecycle with a strong data-oriented approach. This chapter also discusses the roles and responsibilities required to support a database development methodology.

Chapter 2, “Establishing Enterprise Data Standards,” provides practical examples and categories for building a set of enterprise data standards. The contents of this chapter are assembled from actual project experiences to describe techniques that work, and as importantly, do not work, when trying to build and implement enterprise data standards. Suggestions for avoiding the common pitfalls experienced by organizations during this initiative are also provided in this chapter.

Chapter 3, “Enterprise Data Management,” describes an enterprise data management approach for identifying and establishing missions, objectives, strategies, and plans to align information management and business intelligence with enterprise objectives and requirements.

Chapter 1

Database Development Methodology and Organization

Sanjiv Purba

DATABASE DEVELOPMENT IS ONE OF THE FUNDAMENTAL OBJECTIVES of the data management function and certainly one of the end products of the process. In recent years, several trends have impacted the way that databases are built and the role they play in the overall organization. Some of these trends include data warehousing, object-oriented technology, E-commerce, and the emergence of very large databases (VLDBs). Other changes to the landscape include the popularity of complex data types (e.g., BLOBs, video), universal databases, and object databases. Despite these changes, the basis of many online transaction processing applications (OLTP) that run the business is still the relational database and the flat files. This fact is not going to change dramatically over the next few years. If anything, the relational database has proven its value as an enterprise enabler and, like the IBM mainframe, is here to stay for the foreseeable future.

This chapter defines a database development methodology and approach that has proven successful on a variety of projects, such as $100,000 to $15,000,000 budgets, mainframe, client/server, three-tier with OO, and package implementations. This approach promotes viewing methodologies as flexible frameworks that are customized for every specific instance. It allows data-oriented teams to use their personal insight and experience alongside the best practices embedded in the methodology. This chapter also defines organizational roles for a data-oriented environment.

BENEFITS

The complexity that is inherent in constructing relational database solutions can be reduced by using proven database development methodologies on projects. Methodologies are an excellent example of best practices and project lessons. Use of methodologies, therefore, reduces risk on development projects. Methodologies define activities and deliverables that are constructed in projects that were successful. Following these successful lessons can reduce project development time while increasing product quality. Furthermore, the use of methodologies simplifies the process of tracking project progress because there are clear benchmarks that can be reviewed by the project manager. Methodologies that offer templates/deliverables also allow a quickstart to the development process.

SELECTING A DATABASE DEVELOPMENT METHODOLOGY

Development methodologies with well-defined database development phases are commonly available in the marketplace. Some are freely available with modeling or project management tools, although others are found on the World Wide Web. Many of the larger consulting firms have developed proprietary methodologies based on their corporate project experiences and proven best practices. These can be purchased separately or they can be bundled with consulting/mentoring services retained from the firm. The following list identifies some of the features that should be included in any database development methodology that is being considered for deployment in an organization.

• Linkage to a full lifecycle development methodology: A full lifecycle methodology supports more than database development. The database development methodology chosen should either be a component of a larger full lifecycle methodology, or link seamlessly with one. Failure to do this could result in mismatched techniques or the development of deliverables that are not used.

• Techniques: Many popular development methodologies support a combination of techniques to streamline development of deliverables. The traditional waterfall approach involves producing deliverables in a sequential fashion. Deliverable B is not started until Deliverable A is completed and signed off. This approach, however, historically has proven to be slow on many projects of all sizes. As a result of this experience, a rapid application development (RAD) approach has gained popularity in the past 10 years. RAD produces deliverables in a much smaller timeframe than the older waterfall approach. Iteration and prototyping are cornerstones of most RAD approaches, as are teams that combine technical resources and users during the analysis and design phases of the project lifecycle. RAD has proven to be successful on smaller projects, but has been problematic on the larger ones due to the complexity of the business requirements. A relatively new approach combines the best elements of both the waterfall and RAD approaches and has proven valuable on larger development projects.

• Support: A development methodology (or a database development methodology) is a product, whether an organization has paid for it or not. As such, it is important for the methodology to be supported by the vendor into the future. An unsupported methodology becomes obsolete in sort order. Some questions to ask the vendor include: “How much research is being conducted to improve the methodology?” “Is there a hotline for technical support?” and “When is the next release of the methodology being released?”

• Price: The price of the methodology should be considered in whole and in part and assessed against the value that is received. Consider the one-time cost, training costs, upgrade costs, yearly licence fees, costs per user, customization costs, hardware/software support costs, and costs for future releases.

• Vendor: Consider the stability and market share of the vendor providing the methodology. The vendor’s references also should be checked to ascertain their support for clients. Vendors that are more stable and have more market share are more likely to improve their methodology with new techniques in the future.

• Proven Success: One of the surest ways of selecting a suitable methodology is to check the references of similar organizations that have used it successfully on development projects.

• Electronic Availability: The methodology should be available electronically through Lotus Notes, the Internet, or CD-ROM. It also should be available on paper. This makes the methodology widely available to those using it across the organization.

• Templates/Deliverables: Reusable templates and deliverables are a good source of best practices that provide the means for quick starting development projects. Many methodologies are demonstrated with these, but the templates/deliverables are not provided to customers. In such cases, it is valuable to try to negotiate the inclusion of templates/deliverables as part of the transaction. If the templates/deliverables still are not offered by the vendor, but the rest of the methodology is acceptable, a pilot project should be used to create reusable templates and deliverables for future projects to use. Although this may slow the pilot project down in the short term, subsequent projects will run more efficiently. It is also desirable to select a methodology architecture that allows additional templates and deliverables to be added to the database on an ongoing basis.

• Linkages to newer architectures: The methodology also should support linkages with modules that support data warehousing, object technology, E-commerce, and Web architectures. Flexibility in expanding the methodology dir...

Table of contents

• Cover
• Half Title
• Title Page
• Copyright Page
• Contributors
• Table of Contents
• Introduction
• SECTION 1 DATABASE PLANNING AND GETTING STARTED
• SECTION II INFORMATION GATHERING AND ANALYSIS
• SECTION III MANAGING BUSINESS RULES
• SECTION IV PERFORMANCE MODELING METHODS
• SECTION V PERFORMANCE DESIGN AND DEVELOPMENT
• SECTION VI DATABASE INTEGRITY AND QUALITY
• SECTION VII DISTRIBUTED DATABASES, PORTABILITY, AND INTEROPERABILITY
• SECTION VIII DATABASE INTEGRATION WITH THE INTERNET AND THE WEB
• SECTION IX DATA MIGRATION, CONVERSION, AND LEGACY APPLICATIONS
• SECTION X PERFORMANCE TUNING
• SECTION XI DATA ADMINISTRATION AND OPERATIONS
• SECTION XII DATABASE SECURITY
• ABOUT THE CONSULTING EDITOR
• INDEX