DECISION SUPPORT SYSTEMS:DATABASE MANAGEMENT SYSTEMS

DATABASE MANAGEMENT SYSTEMS

As we have noted, a database management system is one of the three fundamental technological components in a decision support system. Figure 3 indicates the generic relationship among these components, or subsystems. We can consider a database management system as composed of a

database (DB) and a management system (MS). This sort of expansion holds for the model base management system also. Figure 4 indicates the resulting expanded view of a DSS. The DBMS block itself can be expanded considerably, as can the other two subsystems of a DSS. Figure 5 indicates one possible expansion to indicate many of the very useful components of a database management system that we will brieﬂy examine later in this section.

Three major objectives for a DBMS are data independence, data redundancy reduction, and data resource control, such that software to enable applications to use the DBMS and the data processed are independent. If this is not accomplished, then such simple changes to the data structure as adding four digits to the ZIP code number in an address might require rewriting many applications programs. The major advantage to data independence is that DSS developers do not need to be explicitly concerned with the details of data organization in the computer or how to access it explicitly for information processing purposes, such as query processing. Elimination or reduction of data redun- dancy will assist in lessening the effort required to make changes in the data in a database. It may also assist, generally greatly, in eliminating the inconsistent data problem that often results from updating data items in one part of a database but (unintentionally) not updating this same data that

exists elsewhere in the database because of data redundancy. With many people potentially using the same database, resource control is essential. The presence of these three features in a DBMS is the major factor that differentiates it from a ﬁle management system.

The management system for a database is composed of the software that is beneﬁcial to the creation, access, maintenance, and updating of a database. A database contains data that are of value to an individual or an organization and that an individual or an organization desires to maintain. Maintenance should be such that the data survive even when the DBMS system hardware and / or software fails. Maintenance of data is one of the important functions provided for in DBMS design.

There are many tasks that we desire to perform using a database. These ﬁve are especially important:

1. Capturing relevant data for use in the database

2. Selecting relevant data from the database

3. Aggregating data to form totals, averages, moments, and other items that support decision making

4. Estimating, forecasting, and predicting in order to obtain extrapolations of events into the future, and such other activities as

5. Optimizing in order to enable selection of a ‘‘best’’ alternative

We note that these database raise issues that are associated with the model base management system. In a similar way, the dialog generation and management system determines how data is viewed and is therefore also important for use of a DBMS.

DBMS Design, Selection, and Systems Integration

As with any information systems engineering-based activity, DBMS design should start with an identiﬁcation of the DBMS design situation and the user requirements. From this, identiﬁcation of the logical or conceptual data requirements follows speciﬁcation of a logical database structure in accordance with what is known as a data deﬁnition language (DDL). After this, the physical database structure is identiﬁed. This structure must be very concerned with speciﬁc computer hardware char- acteristics and efﬁciency considerations. Given these design speciﬁcations, an operational DBMS is constructed and DBMS operation and maintenance efforts begin. The logical database design and physical database design efforts can each be disaggregated into a number of related activities. The typical database management system lifecycle will generally follow one of the systems engineering development life cycles discussed in the literature (Sage 1992, 1995; Sage and Rouse 1999a).

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ﬁciently?

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 inte- gration 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.

Data Models and Database Architectures

We will now expand very brieﬂy on our introductory comments concerning data model representa- tions and associated architectures for database management systems. Some deﬁnitions are appropriate. A data model deﬁnes the types of data objects that may be manipulated or referenced within a DBMS. The concept of a logical record is a central one in all DBMS designs. Some DBMS designs are based on mathematical relations, and the associated physical database is a collection of consistent tables in which every row is a record of a given type. This is an informal description of a relational database management system, a DBMS type that is a clear outgrowth of the ﬁle management system philosophy. Other DBMS may be based on hierarchical or network structures, which resemble the appearance of the data in the user’s world and may contain extensive graphical and interactive support characteristics.

There are several approaches that we might take to describing data models. Date (1983, 1999), for example, discusses a three-level representation in which the three levels of data models are:

1. An external model, which represents a data model at the level of the user’s application and is the data model level closest and most familiar to users of a DBMS or DSS

2. A conceptual model, which is an aggregation model that envelopes several external models

3. An internal model, which is a technical-level model that describes how the conceptual model is actually represented in computer storage

Figure 6 is a generic diagram that indicates the mappings and data translations needed to accom- modate the different levels of data models and architectures. The relations between the various levels, called mappings. These specify and describe the transformations that are needed in order to obtain one model from another. The user supplies speciﬁcations for the source and target data structures in

a data description language (DDL) and also describes the mapping that is desired between source and target data. Figure 7 represents this general notion of data transformation. This could, for ex- ample, represent target data in the form of a table that is obtained from a source model composed of a set of lists.

Figure 7 is a very simple illustration of the more general problem of mapping between various schemas. Simply stated, a schema is an image used for comparison purposes. A schema can also be described as a data structure for representing generic concepts. Thus, schemas represent knowledge about concepts and are structurally organized around some theme. In terms appropriate here, the user of a database must interpret the real world that is outside of the database in terms of real-world objects, or entities and relationships between entities, and activities that exist and that involve these objects. The database user will interact with the database in order to obtain needed data for use or, alternatively, to store obtained data for possible later use. But a DBMS cannot function in terms of real objects and operations. Instead, a DBMS must use data objects, composed of data elements and relations between them, and operations on data objects. Thus, a DBMS user must perform some sort of mapping or transformation from perceived real objects and actions to those objects’ and actions’ representations that will be used in the physical database.

The single-level data model, which is conceptually illustrated in Figure 7, represents the nature of the data objects and operations that the user understands when receiving data from the database. In this fashion the DBMS user models the perceived real world. To model some action sequence, or the impact of an action sequence on the world, the user maps these actions to a sequence of operations that are allowed by the speciﬁc data model. It is the data manipulation language (DML) that provides the basis for the operations submitted to the DBMS as a sequence of queries or programs. The development of these schemas, which represent logical data, results in a DBMS architecture or DBMS framework, which describes the types of schemas that are allowable and the way in which these schemas are related through various mappings. We could, for example, have a two-schema framework or a three-schema framework, which appears to be the most popular representation at this time. Here

the external schemas deﬁne the logical subset of the database that may be presented to a speciﬁc DBMS user. The conceptual schemas deﬁne conceptual models as represented in the database. The internal schema describes physical data structures in the database. These data structures provide support to the conceptual models. The mappings used establish correspondence between various objects and operations at the three levels. If consistency of the conceptual models is to be ensured, we must be able to map the internal, or physical, and external, or logical, schemas to the conceptual schemas.

Useful documentation about the database structure and architecture is provided through the various schemas, which represent explicit data declarations. These declarations represent data about data. The central repository in which these declarations are kept is called a data dictionary or data directory, and is often represented by the symbol DD. The data directory is a central repository for the deﬁ- nitions of the schemas and the mappings between schemas. Generally, a data dictionary can be queried in the same manner as can the database, thereby enhancing the ability of the DBMS user to pose questions about the availability and structure of data. It is often possible to query a data directory with a high-level, or fourth-generation, query language.

A data dictionary is able to tell us what the records in the data dictionary consist of. It also contains information about the logical relationships that pertain to each of the particular elements in the database. The development of a data dictionary generally begins with formation of lists of desired data items or ﬁelds that have been grouped in accordance with the entities that they are to represent. A name is assigned for each of these lists, and a brief statement of the meaning of each is provided for later use. Next, the relationships between data elements should be described and any index keys or pointers should be determined. Finally, the data dictionary is implemented within the DBMS. In many ways, a data dictionary is the central portion of a DBMS. It performs the critical role of retaining high-level information relative to the various applications of the DBMS and thereby enables speciﬁcation, control, review, and management of the data of value for decision making relative to speciﬁc applications.

For very large system designs, it is necessary that the data dictionary development process be automated. A typical data dictionary for a large system may include several thousand entries. It is physically impossible to manually maintain a dictionary of this size or to retain consistent and unambiguous terms for each data element or composite of data elements. Therefore, automated tools are needed for efﬁcient and effective development and maintenance of a data dictionary. These are provided in contemporary DBMSs.

This ability to specify database structures, through use of schemas, enables efﬁcient and effective management of data resources. This is necessary for access control. The use of one or more sub- schemas generally simpliﬁes access to databases. It may also provide for database security and integrity for authorized users of the DBMS. Since complex physical (computer) structures for data may be speciﬁed, independent of the logical structure of the situation that is perceived by DBMS users, it is thereby possible to improve the performance of an existing and operational database without altering the user interface to the database. This provides for simplicity in use of the DBMS.

The data model gives us the constructs that provide a foundation for the development and use of a database management system. It also provides the framework for such tools and techniques as user interface languages. The user of these languages is often called a database administrator (DBA). There are three types of user interface languages:

1. Data deﬁnition languages (DDLs) provide the basis for deﬁnition of schemas and subschemas.

2. Data manipulation languages (DMLs) are used to develop database applications.

3. Data query languages (DQLs) or simply query languages (QLs) are used to write queries and reports. Of course, it is possible to combine a DDL, DML, and DQL into a single database language.

In general, a data model is a paradigm for representation, storing, organizing, and otherwise managing data in a database. There are three component sets in most data models:

1. A set of data structures that deﬁne the ﬁelds and records that are allowed in the database.

Examples of data structures include lists, tables, hierarchies, and networks.

2. A set of operations that deﬁne the admissible manipulations that are applied to the ﬁelds and records that comprise the data structures. Examples of operations include retrieve, combine, subtract, add, and update.

3. A set of integrity rules that deﬁne or constrain allowable or legal states or changes of state for the data structures that must be protected by the operations.

There are three generically different types of data model representations and several variants within these three representations. Each of these is applicable as an internal, external, or conceptual model. We will be primarily concerned with these three modeling representations as they affect the external, or logical, data model. This model is the one with which the user of a speciﬁc decision support system interfaces. For use in a decision support system generator, the conceptual model is of importance because it is the model that inﬂuences the speciﬁc external model that various users of a DSS will interface with after an operational DSS is realized. This does not mean that the internal data model is unimportant. It is very important for the design of a DBMS. Through its data structures, operations, and integrity constraints, the data model controls the operation of the DBMS portion of the DSS.

The three fundamental data models for use in the external model portion of a DSS are record- based models, structurally based models, and expert system-based models. Each of these will now be brieﬂy described.

Record-Based Models

We are very accustomed to using forms and reports, often prepared in a standard fashion for a particular application. Record-based models are computer implementations of these spreadsheet-like forms. Two types can be identiﬁed. The ﬁrst of these, common in the early days of ﬁle processing systems (FPSs) or ﬁle management systems (FMSs), is the individual record model. This is little more than an electronic ﬁle drawer in which records are stored. It is useful for a great many appli- cations. More sophisticated, however, is the relational database data model, in which mathematical relations are used to electronically ‘‘cut and paste’’ reports from a variety of ﬁles. Relational database systems have been developed to a considerable degree of sophistication, and many commercial prod- ucts are available. Oracle and Informix are two leading providers.

The individual record model is surely the oldest data model representation. While the simple single-record tables characteristic of this model may appear quite appealing, the logic operations and integrity constraints that need to be associated with the data structure are often undeﬁned and are perhaps not easily deﬁned. Here, the data structure is simply a set of records, with each record consisting of a set of ﬁelds. When there is more than a single type of record, one ﬁeld contains a value that indicates what the other ﬁelds in the record are named.

The relational model is a modiﬁcation of the individual record model that limits its data structures and thereby provides a mathematical basis for operation on records. Data structures in a relational database may consist only of relations, or ﬁeld sets that are related. Every relation may be considered as a table. Each row in the table is a record or tuple. Every column in each table or row is a ﬁeld or attribute. Each ﬁeld or attribute has a domain that deﬁnes the admissible values for that ﬁeld.

Often there is only a modest difference in structure between this relational model and the indi- vidual record model. One difference is that ﬁelds in the various records of the individual record model represent relationships, whereas relationships among ﬁelds or attributes in a relational model are denoted by the name of the relation.

While the structural differences between the relational model and the individual record model are minimal, there are major differences in the way in which the integrity constraints and operations may affect the database. The operations in a relational database form a set of operations that are deﬁned mathematically. The operations in a relational model must operate on entire relations, or tuples, rather than only on individual records. The operations in a relational database are independent of the data structures, and therefore do not depend on the speciﬁc order of the records or the ﬁelds. There is often controversy about whether or not a DBMS is truly relational. While there are very formal deﬁnitions of a relational database, a rather informal one is sufﬁcient here. A relational database is one described by the following statements.

1. Data are presented in tabular fashion without the need for navigation links, or pointer structures, between various tables.

2. A relational algebra exists and can be used to prepare joins of logical record ﬁles automatically.

3. New ﬁelds can be added to the database without the necessity of rewriting any programs that used previous versions of the database.

If a DBMS does not satisfy these three criteria, then it is almost surely NOT a relational database.

Structural Models

In many instances, data are intended to be associated with a natural structural representation. A typical hierarchical structure is that of a classic organization. A more general representation than a hierarchy, or tree, is known as a network. It is often possible to represent a logical data model with a hierarchical data structure. In a hierarchical model, we have a number of nodes that are connected by links. All links are directed to point from ‘‘child’’ to ‘‘parent,’’ and the basic operation in a hierarchy is that of searching a tree to ﬁnd items of value. When a query is posed with a hierarchical database, all branches of the hierarchy are searched and those nodes that meet the conditions posed in the query are noted and then returned to the DBMS system user in the form of a report.

Some comparisons of a hierarchical data model with a relational data model are of interest here. The structures in the hierarchical model represent the information that is contained in the ﬁelds of the relational model. In a hierarchical model, certain records must exist before other records can exist. The hierarchical model is generally required to have only one key ﬁeld. In a hierarchical data model, it is necessary to repeat some data in a descendant record that need be stored only once in a relational database regardless of the number of relations. This is so because it is not possible for one record to be a descendant of more than one parent record. There are some unfortunate consequences of the mathematics involved in creating a hierarchical tree, as contrasted with relations among records. Descendants cannot be added without a root leading to them, for example. This leads to a number of undesirable characteristic properties of hierarchical models that may affect our ability to easily add, delete, and update or edit records.

A network model is quite similar to but more general than the hierarchical model. In a hierarchy, data have to be arranged such that one child has only one parent, and in many instances this is unrealistic. If we force the use of a hierarchical representation in such cases, data will have to be repeated at more than one location in the hierarchical model. This redundancy can create a number of problems. A record in a network model can participate in several relationships. This leads to two primary structural differences between hierarchical and network models. Some ﬁelds in the hierar- chical model will become relationships in a network model. Further, the relationships in a network model are explicit and may be bidirectional. The navigation problem in a network data model can become severe. Because search of the database can start at several places in the network, there is added complexity in searching, as well.

While spreadsheet type relational records are very useful for many purposes, it has been observed (Kent 1979) that not all views of a situation, or human cognitive maps, can be represented by relational data models. This has led to interest in entity and object-oriented data models and to data models based on artiﬁcial intelligence techniques. The basic notion in the use of an ER model is to accomplish database design at the conceptual level, rather than at the logical and / or physical levels. ER models (Chen 1976) are relatively simple and easy to understand and use, in large part because of the easy graphical visualization of the database model structure. Also, ER modeling capability is provided by many computer aided software engineering (CASE) tools. While such limitations as lack of a very useful query language are present (Atzeni and Chen 1983), much interest in ER data models, especially at the conceptual level, exists at this time. Figure 8 illustrates the conceptual orientation of the ER modeling approach.

ER models are based on two premises: (a) information concerning entities and relationships exists as a cognitive reality, and (b) this information may be structured using entities and relationships among them as data. An entity relationship data model is a generalization of the hierarchical and network data models. It is based on well-established graph theoretic developments and is a form of structured modeling. The major advantage of the ER approach is that it provides a realistic view of the structure and form for the DBMS design and development effort. This should naturally support the subsequent development of appropriate software. In addition, the approach readily leads to the

development of the data dictionary. The primary difﬁculties that may impede easy use of the ER method are in the need for selection of appropriate verbs for use as contextual relationships, elimi- nation of redundancy of entities, and assurances that all of the needed ER have been determined and properly used. Often a considerable amount of time may be needed to identify an appropriate set of entities and relations and obtain an appropriate structural model in the form of an ER diagram.

Expert and Object-Oriented Database Models

An expert database model, as a specialized expert database system, involves the use of artiﬁcial intelligence technology. The goal in this is to provide for database functionality in more complex environments that require at least some limited form of intelligent capability. To allow this may require adaptive identiﬁcation of system characteristics, or learning over time as experience with an issue and the environment into which it is embedded increases. The principal approach that has been developed to date is made up of an object-oriented database (OODB) design with any of the several knowledge representation approaches useful in expert system development. The ﬁeld is relatively new compared to other database efforts and is described much more fully in Kerschberg (1987, 1989), Myloupoulos and Brodie (1989), Parsaye et al. (1989), Debenham (1998), Poe et al. (1998), and Darwen and Date (1998).

The efforts to date in the object oriented area concern what might be more appropriately named object-oriented database management systems design (OODBMS). The objective in OODBMS design is to cope with database complexity, potentially for large distributed databases, through a combination of object-oriented programming and expert systems technology. Object-oriented design approaches generally involve notions of separating internal computer representations of elements from the ex- ternal realities that lead to the elements. A primary reason for using object-oriented language is that it naturally enables semantic representations of knowledge through use of 10 very useful character- istics of object-oriented approaches (Parsaye et al. 1989): information hiding, data abstraction, dy- namic binding and object identity, inheritance, message handling, object oriented graphical interfaces, transaction management, reusability, partitioning or dividing or disaggregating an issue into parts, and projecting or describing a system from multiple perspectives or viewpoints. These could include, for example, social, political, legal, and technoeconomic perspectives (Sage 1992).

There are at least two approaches that we might use in modeling a complex large-scale system:

(1) functional decomposition and structuring and (2) purposeful or object decomposition and struc-

turing. Both approaches are appropriate and may potentially result in useful models. Most models of real-world phenomena tend to be purposeful. Most conventional high-level programming languages are functionally, or procedurally, oriented. To use them, we must write statements that correspond to the functions that we wish to provide in order to solve the problem that has been posed. An advantage of object decomposition and structuring is that it enables us to relate more easily the structure of a database model to the structure of the real system. This is the case if we accomplish our decompo sition and structuring such that each module in the system or issue model represents an object or a class of objects in the real issue or problem space. Objects in object-oriented methodology are not unlike elements or nodes in graph theory and structural modeling. It is possible to use one or more contextual relations to relate elements together in a structural model. An object may be deﬁned as a collection of information and those operations that can be performed upon it. We request an object to perform one of its allowable operations by instructing it with a message.

Figure 9 illustrates the major conceptual difference between using a conventional programming approach and using an object-oriented approach for construction of a DBMS. In the conventional approach, procedures are at the nexus and procedures update and otherwise manipulate data and return values. In the object-oriented approach, the collection of independent objects are at the nexus and communicate with each other through messages or procedures. Objects investigate requests and behave according to these messages. Object-oriented design often provides a clear and concise in- terface to the problem domain in that the only way to interact with an object is through the operations or messages to the object. These messages call for operations that may result in a change of state in the object in question. This message will affect the particular object called and only that one, as no other object is affected. This provides a high degree of modularity and increased ability to verify and validate outcomes and thus provides an increased sense of reliability in the resulting DBMS design. Object-oriented languages are, for the most part, very high-level languages used to accomplish precisely the same results as high-level languages. By focusing upon the entities of objects and the relationships between objects, they often provide a simpler way to describe precisely those elements needed in detailed design procedures.

Object-oriented DBMS design is based on appropriate linking of objects, or data items or entities, and the operations on these, such that the information and processing is concentrated on the object classes, attributes, and messages that transfer between them. The features that set object-oriented approaches from other approaches are the capability of object-oriented languages to support abstraction, information hiding, and modularity. The items used in object-oriented DBMS design are objects,

abstracts or physical entities that pertain to the domain of the system; attributes, or characteristics of objects; operations, or dynamic entities that may change with time; and messages, or requests to an object to perform an operation. Objects represent such real-world entities as machines, ﬁles, products, signals, persons, things, and places. They may be either physical entities or abstract representations. The attributes are characteristics that describe the properties ascribed to objects. Each attribute may be dynamically associated with a numerical value, and the combination of these values together with the description of the object in the problem domain presents the state of the object. Thus, the attributes are related to the object as subobjects. Attributes include such things as the name of the object, the number of speciﬁc objects in a ﬁle, or the name for the place, and the like. The basic attribute, one that may not be further decomposed, is the primitive type of object or subobject. Attributes may also be nonnumeric. Operations consist of processes and data structures that apply to the object to which it is directed. These are generally dynamic entities whose value may change over time. Each object may be subjected to a number of operations that provide information relative to control and procedural constructs that are applied to the object. Deﬁning an object such as to have a private part and then assigning a message to address the appropriate processing operation enables us to achieve information hiding. Messages are passed between objects in order to change the state of the object, address the potentially hidden data parts of an object, or otherwise modify an object.

Coad and Yourdon (1990) identify ﬁve steps associated with implementing an object-oriented approach:

1. Identify objects, typically by examining the objects in the real world.

2. Identify structures, generally through various abstracting and partitioning approaches that result in a classiﬁcation structure, an assembly structure, or a combination of these.

3. Identify subjects through examining objects and their structures to obtain this more complex abstract view of the issue. Each classiﬁcation structure and each assembly structure will com- prise one subject.

4. Identify attributes that impart important aspects of the objects that need to be retained for all instances of an object.

5. Identify services such that we are aware of occurrence services, creation or modiﬁcation of instances of an object, calculation services, or monitoring of other processes for critical events or conditions.

Steps such as these should generally be accomplished in an iterative manner because there is no unique way to accomplish speciﬁcation of a set of objects, or structural relations between objects.

A major result from using object-oriented approaches is that we obtain the sort of knowledge representation structures that are commonly found in many expert systems. Thus, object-oriented design techniques provide a natural interface to expert system-based techniques for DBMS design. This is so because objects, in object-oriented design, are provided with the ability to store information such that learning over time can occur; process information by initiating actions in response to messages; compute and communicate by sending messages between objects; and generate new in- formation as a result of communications and computations. Object-oriented design also lends itself to parallel processing and distributed environments. Object-oriented design and analysis is a major subject in contemporary computer and information system subject areas and in many application domains as well (Firesmith 1993; Sullo 1994; Jacobson et al. 1995; Zeigler 1997).

Distributed and Cooperative Databases

We have identiﬁed the three major objectives for a DBMS as data independence, data redundancy reduction, and data resource control. These objectives are important for a single database. When there are multiple databases potentially located in a distributed geographic fashion, and potentially many users of one or more databases, additional objectives arise, including:

1. Location independence or transparency to enable DBMS users to access applications across distributed information bases without the need to be explicitly concerned with where speciﬁc data is located

2. Advanced data models, to enable DBMS users to access potentially nonconventional forms of data such as multidimensional data, graphic data, spatial data, and imprecise data

3. Extensible data models, which will allow new data types to be added to the DBMS, perhaps in an interactive real-time manner, as required by speciﬁc applications.

An important feature of a distributed database management systems (DDBMSs) is that provisions for database management are distributed. Only then can we obtain the needed ‘‘fail-safe’’ reliability and ‘‘availability’’ even when a portion of the system breaks down. There are a number of reasons why distributed databases may be desirable. These include and are primarily related to distributed users and cost savings. Some additional costs are also involved, and these must be justiﬁed.

A distributed database management system will generally look much like replicated versions of a more conventional single-location database management system. We can thus imagine replicated versions of Figure 7. For simplicity, we show only the physical database, the database access interface mechanism, and the data dictionary for each database. Figure 10 indicates one possible conceptual

architecture of a distributed database in which there are two requests for data being simultaneously submitted. Through use of protocols, all requests for data are entered as if those data were stored in the database of the requesting user. The data dictionaries of the distributed system are responsible for ﬁnding the requested data elements and delivering them to the requesting user. All of these auxiliary requests are accomplished in a manner that is transparent to the requesting database user. Data transmission rate concerns must be resolved in order for this to be done satisfactorily. Potentially, however, real-time access to all of the data in the entire distributed system can be provided to any local user.

It is important to note that completion of the above steps does not transfer the requested data into the database of the requesting user, except perhaps in some temporary storage fashion. The very good reason why this is not done is that it would result in database redundancy and also increase database security difﬁculties.

An alternate approach to this distributing of data is to use what is often called cooperative proc- essing or cooperative database management. This involves central database and distributed database concepts, blended to produce better results than can be had with either approach. Central to this are various approaches for the distributing and coordinating of data. We could use function, geography, or organizational level as the basis for distributing and cooperating, and possible system conﬁgura- tions may be based upon background communications, microcomputer-based front-end processing for host applications, and peer-to-peer cooperative processing.

The database component of a DSS provides the knowledge repository that is needed for decision support. Some sort of management system must be associated with a database in order to provide the intelligent access to data that is needed. In this section we have examined a number of existing constructs for database management systems. We now turn to the model-based portion of a DSS.

Search This Blog

Operation Research course