“Choosing the right OODB architecture can mean orders of magnitude difference in performance and scalability characteristics rather than a few percentage points as found in relational implementations.” To achieve maximum performance and scalability the most important thing is choosing the right application architecture. OODBs give applications much more direct access to the persistent data, so application architecture has much more impact on performance than is the case with an RDB. Or to put it another way, when using an OODB the application architect has much more power to optimize performance than when using an RDB. Consequently the application architecture has more effect on performance and scalability than the choice of OODB product. To effectively exploit an OODB a use-case driven approach is recommended, as this informs the entire design of the application. The process architecture design should consider which processes are responsible for which use-cases. Partitioning of the dataset should aim to identify which objects are accessed by which of these processes. Transactional analysis should analyse the transactional requirements of each use-case, and the objects that are accessed in each transaction. Object interaction diagrams are useful in this respect. The OO design phase should include the design of optimal access and index structures to support the navigation paths of the most important use cases, and the concurrency characteristics of the system should be explored with techniques such as CRUD charts. In short, using standard OO analysis and design techniques to produce the correct application architecture is essential when implementing large, high-performance, scalable and reliable OODB based applications. Without this effort, the choice of OODB product is unlikely to change the performance characteristics by orders of magnitude one way or the other.
The relational model is the basis of many commercial relational DBMS products (e.g., DB2, Informix, Oracle, Sybase) and the structured query language (SQL) is a widely accepted standard for both retrieving and updating data. The basic relational model is simple and mainly views data as tables of rows and columns. The types of data that can be stored in a table are basic types such as integer, string, and decimal.
Relational DBMSs have been extremely successful in the market. However, the traditional RDBMSs are not suitable for applications with complex data structures or new data types for large, unstructured objects, such as CAD/CAM, Geographic information systems, multimedia databases, imaging and graphics. The RDBMSs typically do not allow users to extend the type system by adding new data types. They also only support first-normal-form relations in which the type of every column must be atomic, i.e., no sets, lists, or tables are allowed inside a column. Due to the new needs in database systems, a number of researches for OODBMS have begun in the early 80.s.
Concept and Features
While a relational database system has a clear specification given by Codd, no such specification existed for object-oriented database systems even when there were already products in the market. A consideration of the features of both object-oriented systems and database management systems has led to a definition of an object-oriented database, which was presented at the First International Conference on Deductive, and Object-oriented Databases in the form of a manifesto in 1989. This ’manifesto’ distinguishes between the mandatory, optional and open features of an object-oriented database. The mandatory features, which must be present if the system is to be considered (in the opinion of the manifesto authors) to be an object-oriented database,
Figure 1 OODB features
are defined in the following two paragraphs. The first part describes features of...