The three important DBMS requirements—data independence, redundancy reduction, and in- creased data resource control—are generally applicable both to logical data and to physical data. It is highly desirable, for example, to be able to change the structure of the physical database without affecting other portions of the DBMS. This is called physical data independence. In a similar way, logical data independence denotes the ability of software to function using a given applications- oriented perspective on the database even though changes in other parts of the logical structure have been made. The requirements speciﬁcation, conceptual design, logical design, and physical design phases of the DBMS development life cycle are speciﬁcally concerned with satisfaction of these requirements.
A number of questions need to be asked and answered successfully in order to design an effective DBMS. Among these are the following (Arden 1980):
1. Are there data models that are appropriate across a variety of applications?
2. What DBMS designs that enable data models to support logical data independence?
3. What DBMS designs enable data models to support logical data independence, and what are the associated physical data transformations and manipulations?
4. What features of a data description language will enable a DBMS designer to control inde- pendently both the logical and physical properties of data?
5. What features need to be incorporated into a data description language in order to enable errors to be detected at the earliest possible time such that users will not be affected by errors that occur at a time prior to their personal use of the DBMS?
6. What are the relationships between data models and database security?
7. What are the relationships between data models and errors that may possibly be caused by concurrent use of the database by many users?
8. What are design principles that will enable a DBMS to support a number of users having diverse and changing perspectives?
9. What are the appropriate design questions such that applications programmers, technical users, and DBMS operational users are each able to function effectively and efﬁcientl
The bottom line question that summarizes all of these is, How does one design a data model and data description language to enable efﬁcient and effective data acquisition, storage, and use? There are many related questions; one concerns the design of what are called standard query languages (SQLs) such that it is possible to design a speciﬁc DBMS for a given application.
It is very important that, whenever possible, a speciﬁc DBMS be selected prior to design of the rest of the DSS. There are a variety of reasons why this is quite desirable. The collection and maintenance of the data through the DSS are simpliﬁed if there is a speciﬁed single DBMS structure and architecture. The simplest situation of all occurs when all data collection (and maintenance) is accomplished prior to use of the DSS.
The DBMS is not then used in an interactive manner as part of DSS operation. The set of database functions that the DSS needs to support is controlled when we have the freedom to select a single DBMS structure and architecture prior to design of the rest of the DSS. The resulting design of the DSS is therefore simpliﬁed. Further, the opportunities for data sharing among potentially distributed databases are increased when the interoperability of da- tabases is guaranteed. Many difﬁculties result when this is not possible. Data in a DBMS may be classiﬁed as internal data, stored in an internal database, and external data, stored in an external database. Every individual and organization will necessarily have an internal database. While no problem may exist in ensuring DBMS structure and architecture compatibility for internal data, this may be very difﬁcult to do for external data. If both of these kinds of data can be collected and maintained prior to use of a DSS, then there will generally be no data integration needs. Often, however, this will not be possible. Because we will often be unable to control the data structure and architecture of data obtained externally, the difﬁculties we cite will often be real, especially in what are commonly called real-time, interactive environments. When we have DBMSs that are different in structure and architecture, data sharing across databases is generally difﬁcult, and it is often then necessary to maintain redundant data. This can lead to a number of difﬁculties in the systems integration that is undertaken to ensure compatibility across different databases.
In this chapter, as well as in much DSS and information system design in practice, we may generally assume that the DBMS is preselected prior to design of the rest of the DSS and that the same DBMS structure and architecture are used for multiple databases that may potentially be used in the DSS. This is often appropriate, for purposes of DSS design, since DBMS design technology (Rob and Coronel 1997; Kroenke 1998; Date 1999; Purba 1999; Atzeni et al. 2000) is now relatively mature in contrast to MBMS and DGMS design. This does not suggest that evolution and improve- ments to DBMS designs are not continuing. It is usually possible, and generally desirable, to select a DBMS, based on criteria we will soon discuss, and then design the MBMS and DGMS based on the existing DBMS. This will often, but surely not always, allow selection of commercial off-the- shelf (COTS) DBMS software. The alternate approach of designing a MBMS and DGMS ﬁrst and then specifying the requirements for a DBMS based on these is possible and may in some cases be needed. Given the comparatively developed state of DBMS software development as contrasted with MBMS and DGMS software, this approach will usually be less desirable from the point of view of design economy in engineering the DSS.