|
There is often a great deal of confusion in determining whether an object database management system (ODBMS) is right for you. Most of this confusion can be resolved by focusing on your application's requirements. In those situations where the application requires the very clear advantages of an ODBMS, choosing which ODBMS becomes a continuation of the excercise of analyzing those application requirements.
We begin by recognizing that not all applications are ideally suited to ODBMS technology. We strongly recommend against using an ODBMS in those applications that are handled perfectly well with relational database management systems (RDBMS). Applications that are well suited to the tabular representation of data, with a low level of relationship complexity are best served through relational technology, since at the very highest level, RDBMS all manipulate rows and columns of data, using multiple-indexing and joins to associate tables. The selection criteria that distinguish between any two RDBMSs are then fairly well-defined; the ACID properties of databases are assumed, and product differentiators are identified in areas such as performance, scalability, dependability, and integration.
The same criteria apply in selecting an ODBMS. However, additional criteria also need to be considered when selecting an object database, since data is no longer "rows and columns".
The very root of ODBMS technology is to store complex objects and the complex relationships between them. People familiar with relational technology sometimes suggest that objects are simply rows in tables, and the data members in an object are like the columns that make up a row. While this model appears to hold up at first glance, further examination shows that objects have many other characteristics that distinguish them from being represented as rows of data members. Specifically, objects have methods and direct relationships to other objects. And, quite importantly, objects can exist independently, in both a logical and physical sense, from any object of the same class. Clearly, this is a departure from the tabular storage of information found in RDBMS, which group all items of the same type in a single location.
So how do you determine whether you need an ODBMS? We strongly recommend that you look at the selection of an ODBMS from the perspective of your application's requirements. Then prioritize those requirements and conduct a detailed investigation of how different ODBMSs meet the high priority ones. To help you in this process, we have developed a list of requirements and organized them into the following six categories:
- Reliability and Integrity
- Data Model Complexity
- Transaction Profile
- Distribution
- Performance
- Environment
We suggest you go through these categories and assign a priority to each requirement, then evaluate different products on how well they meet these needs. As examples, we have performed this exercise for four applications well suited to ODBMSs:
- Network management
- Financial trading
- Product information management (PIM)
- Process control
The next section of this guide discusses the general requirements of these applications. The final section contains our prioritization of requirements for these applications and a discussion of how well different database features meet their high priority requirements.
Application Areas
Network Management
The term "network management" really describes all mission critical applications that coordinate the delivery of communication services across a computer network. These applications perform such tasks as device configuration, network path management, problem management, and network planning. These tasks require both real time performance and continuous operation, making high integrity, fast access to data, and high availability important requirements. In addition to these environmental requirements, network management applications require efficient handling of complex data. These applications typically involve three kinds of complex data structures:
- Managed component configuration. These objects are the hardware, software, and virtual components of the network. They form a composition hierarchy whose underlying structure is fairly standardized. Here is an example of such a generic structure (arrows indicate a composition relationship from the structural parent to the structural child):
Network-> Subnetwork-> Switch-> Board-> Port-> Channel-> Bandwidth
When the network encompasses multiple types of hardware, uses complex switching algorithms such as Asynchronous Transfer Mode (ATM), or uses sophisticated industry standards, this hierarchy may be asymmetric and of indeterminate depth.
|
