The Database Design and Implementation Process: Phase 3: Choice of a DBMS

Phase 3: Choice of a DBMS

The choice of a DBMS is governed by a number of factors—some technical, others economic, and still others concerned with the politics of the organization. The technical factors focus on the suitability of the DBMS for the task at hand. Issues to consider are the type of DBMS (relational, object-relational, object, other), the storage structures and access paths that the DBMS supports, the user and programmer interfaces available, the types of high-level query languages, the availability of development tools, the ability to interface with other DBMSs via standard interfaces, the architectural options related to client-server operation, and so on. Nontechnical factors include the financial status and the support organization of the vendor. In this section we concentrate on discussing the economic and organizational factors that affect the choice of DBMS. The following costs must be considered:

        Software acquisition cost. This is the up-front cost of buying the software, including programming language options, different interface options (forms, menu, and Web-based graphic user interface (GUI) tools), recovery/backup options, special access methods, and documentation. The correct DBMS version for a specific operating system must be selected. Typically, the development tools, design tools, and additional language sup-port are not included in basic pricing.

        Maintenance cost. This is the recurring cost of receiving standard maintenance service from the vendor and for keeping the DBMS version up-to-date.

        Hardware acquisition cost. New hardware may be needed, such as additional memory, terminals, disk drives and controllers, or specialized DBMS storage and archival storage.

Database creation and conversion cost. This is the cost of either creating the database system from scratch or converting an existing system to the new DBMS software. In the latter case it is customary to operate the existing system in parallel with the new system until all the new applications are fully implemented and tested. This cost is hard to project and is often underestimated.

        Personnel cost. Acquisition of DBMS software for the first time by an organization is often accompanied by a reorganization of the data processing department. Positions of DBA and staff exist in most companies that have adopted DBMSs.

        Training cost. Because DBMSs are often complex systems, personnel must often be trained to use and program the DBMS. Training is required at all levels, including programming and application development, physical design, and database administration.

        Operating cost. The cost of continued operation of the database system is typically not worked into an evaluation of alternatives because it is incurred regardless of the DBMS selected.

The benefits of acquiring a DBMS are not so easy to measure and quantify. A DBMS has several intangible advantages over traditional file systems, such as ease of use, consolidation of company-wide information, wider availability of data, and faster access to information. With Web-based access, certain parts of the data can be made globally accessible to employees as well as external users. More tangible benefits include reduced application development cost, reduced redundancy of data, and better control and security. Although databases have been firmly entrenched in most organizations, the decision of whether to move an application from a file-based to a database-centered approach still comes up. This move is generally driven by the following factors:

        Data complexity. As data relationships become more complex, the need for a DBMS is greater.

        Sharing among applications. The need for a DBMS is greater when applications share common data stored redundantly in multiple files.

        Dynamically evolving or growing data. If the data changes constantly, it is easier to cope with these changes using a DBMS than using a file system.

        Frequency of ad hoc requests for data. File systems are not at all suitable for ad hoc retrieval of data.

        Data volume and need for control. The sheer volume of data and the need to control it sometimes demands a DBMS.

It is difficult to develop a generic set of guidelines for adopting a single approach to data management within an organization—whether relational, object-oriented, or object-relational. If the data to be stored in the database has a high level of complexity and deals with multiple data types, the typical approach may be to consider an object or object-relational DBMS. Also, the benefits of inheritance among classes and the corresponding advantage of reuse favor these approaches. Finally, several economic and organizational factors affect the choice of one DBMS over another:

        Organization-wide adoption of a certain philosophy. This is often a dominant factor affecting the acceptability of a certain data model (for example, relational versus object), a certain vendor, or a certain development methodology and tools (for example, use of an object-oriented analysis and design tool and methodology may be required of all new applications).

        Familiarity of personnel with the system. If the programming staff within the organization is familiar with a particular DBMS, it may be favored to reduce training cost and learning time.

        Availability of vendor services. The availability of vendor assistance in solving problems with the system is important, since moving from a non-DBMS to a DBMS environment is generally a major undertaking and requires much vendor assistance at the start.

Another factor to consider is the DBMS portability among different types of hard-ware. Many commercial DBMSs now have versions that run on many hardware/software configurations (or platforms). The need of applications for backup, recovery, performance, integrity, and security must also be considered. Many DBMSs are currently being designed as total solutions to the information-processing and information resource management needs within organizations. Most DBMS vendors are combining their products with the following options or built-in features:

        Text editors and browsers

        Report generators and listing utilities

        Communication software (often called teleprocessing monitors)

        Data entry and display features such as forms, screens, and menus with automatic editing features

        Inquiry and access tools that can be used on the World Wide Web (Web-enabling tools)

        Graphical database design tools

A large amount of third-party software is available that provides added functionality to a DBMS in each of the above areas. In rare cases it may be preferable to develop in-house software rather than use a DBMS—for example, if the applications are very well defined and are all known beforehand. Under such circumstances, an in-house custom-designed system may be appropriate to implement the known applications in the most efficient way. In most cases, however, new applications that were not foreseen at design time come up after system implementation. This is precisely why DBMSs have become very popular: They facilitate the incorporation of new applications with only incremental modifications to the existing design of a database. Such design evolution—or schema evolution—is a feature present to various degrees in commercial DBMSs.