Thesis for the Degree of Master of Science, 20p. Evaluation of An Object Database for use in S.P.I.D.E.R. Jonas Brännvall

Transcription

1 Thesis for the Degree of Master of Science, 20p Page 1 (76) Thesis for the Degree of Master of Science, 20p Evaluation of An Object Database for use in S.P.I.D.E.R. Jonas Brännvall Department of Computer Science Mälardalens University Västerås, June 2000

2 Thesis for the Degree of Master of Science, 20p Page 2 (76) Abstract Object-oriented technology is a growing market. Object-oriented analysis and design methods, programming languages and tools, new companies and products emerge in order to satisfy the need of more flexible and powerful data management. The relational database products have been dominating the market since the 1980s. It has a strong formal background and fits many applications that require a powerful query language. Relational database systems are based on two-dimensional tables were items appears as a row. An object can model everything, ranging from numbers to a person to an aeroplane. For expressing object structures in two-dimensional tables, complex interfaces are needed, to handle data manipulation correctly. The semantic mismatch between object-oriented programming languages and the relational data model has led to the development of an objectoriented database, which supports the object model. This document describes the differences between relational and object-oriented database models. It also includes an evaluation of the object-oriented database product Objectivity.

3 Thesis for the Degree of Master of Science, 20p Page 3 (76) Table of Contents 1. INTRODUCTION Evaluation model Functionality Common database features Object-oriented features Realtime features User-friendly Performance COMPARATIVE EVALUATION OF THE OBJECT-ORIENTED DATA MODEL AND THE RELATIONAL DATA MODEL Introduction The Relational Data Model Data Model Query Language Benefits of the Relational Data Model Weaknesses of the Relational Data Model Poor representation of real world entities Semantic overloading Poor support for integrity and enterprise constrains Homogeneous data structure Limited operations Difficult handling recursive queries Impedance mismatch The Relational Database Market The Object-Oriented Data Model Data model Objects and Attributes Classes and Inheritance Object Identity Methods and Messages Complex Objects Benefits of the Object Data Model Reduced Maintenance Real world modeling Extensibility Improved reliability and flexibility Removal of impedance mismatch More expressive query language Support for schema evolution High code reusability...29

4 Thesis for the Degree of Master of Science, 20p Page 4 (76) Improved performance Weaknesses of the Object Data Model OO development is not a panacea Lack of universal data model OO development is not a technology Lack of experience Lack of standards Object databases on today s market A STANDARD OBJECT-ORIENTED DATA MODEL IS EMERGING Introduction The Object Database Management Group (ODMG) Object Model The Object Definition Language The Object Query Language OBJECTIVITY Introduction Database Features Object Model Object Identifiers Data Modeling Object Memory Management Architecture Logical Storage Caching Accessing Objects Transaction Management Transactions Locking S.P.I.D.E.R. SIMULATOR Introduction Database Design System size Object Classes Network Measurement Node Event Storage TTD Storage TransmissionLine Switch BusBar Application Design EVALUATION... 64

5 Thesis for the Degree of Master of Science, 20p Page 5 (76) 6.1 Functionality Common database features Object-oriented features Realtime features User friendly Documentation Support Tools Performance Test Cases with Objectivity Test Case with Objectivity cache Test Cases with C CONCLUSION REFERENCES... 75

6 Thesis for the Degree of Master of Science, 20p Page 6 (76) Preface Purpose This is a master thesis in computer science written by Jonas Brännvall, student at the Department of Computer Science at Mälardalens University of Västerås, Sweden. It documents the work, which has been performed at ABB Automation Systems under the supervision of Lars-Ola Österlund at ABB and Ivica Crnkovic of Mälardalens University.

7 Thesis for the Degree of Master of Science, 20p Page 7 (76) Table of figures Figure 2-1 Evolution of DBMS Figure 4-1 Objectivity/C++ develompent process Figure 4-2 Distributed mixed-tier design Figure 4-3 Objectivity/DB logic storage model Figure 5-1 Simple power station model Figure 5-2 Attribute design Figure 5-3 General database design Figure 5-4 Database design presented UML Figure 5-5 Application data flow Figure 5-6 DAS and E&A Processing High Load Figure 5-7 E&A Processing High Load Figure 5-8 TDD Processing High Load Figure 5-9 DNC Processing High Load Figure 5-10 NMB high load Figure 5-11 SE high load Figure 6-1 Diagram over execution time with different caches List of tables Table 2-1 Relational model terminology Table 2-2 Available OODBMS on the market Table 2-3 Comparisons of three OODBMSs Table 2-4 Comparisons of three OODMBSs Table 6-1 Objectivity/DB concurrency mechanisms Table 6-2 Objectivity/DB Browser Table 6-3 Program code Table 6-4 Execution times of different operations Table 6-5 Execution times with different cache sizes Table 6-6 Program code Table 6-7 Execution times for C++ classes... 72

8 Thesis for the Degree of Master of Science, 20p Page 8 (76) Conventions Convention ANSI API CAD CAM CASE DAS DBMS DDL DML DNC E&A ISO LRU MROW NMB ODMG OODBMS RDBMS Meaning American National Standards Institute Application Program Interface Computer Aided Design Computer Aided Manufacturing Computer Aided Software Engineering Data Acquisition System Database Management System Data Definition Language Data Manipulation Language Dynamic Network Coloring Event & Alarms International Standards Organization Least Recently Used Multiple Readers One Writer Network Module Builder Object Data Management Group Object Oriented Database Management System Relational Database Management System

9 Thesis for the Degree of Master of Science, 20p Page 9 (76) SE SQL TTD State Estimator Structured Query Language Time Tagged Data Trademarks Objectivity and Objectivity/DB are trademarks of Objectivity Inc.; ObjectStore is a trademark of Object Design Inc.; VERSANT is a trademark of Versant Object Technology Corporation;

10 Thesis for the Degree of Master of Science, 20p Page 10 (76) 1. Introduction S.P.I.D.E.R. is a SCADA/EMS system for supervision and control of an electrical Power System, manufactured by. The S.P.I.D.E.R. system is used for energy and distribution management all over the world. The system is built around a database/middelware, Avanti, which is integrated in a distributed environment as a central repository of power system data. The demands on SCADA systems have been too high, in terms of response times, for commercial database/middleware products. Since products is constantly evolving and new products hit the market, continuos evaluations of these products has to be made. This master thesis is one such evaluation. The database market has been divided into relational and object-oriented databases. The S.P.I.D.E.R. system is well suited for an object-oriented environment, both on the database and application side. Performance is the most important issue, the system has very high demands on response time for events. Whether an object-oriented database or a relational database is the best choice for replacing the Avanti database is foremost a performance issue, but other important features are portability, connectivity, scalability, interoperability, and distribution. The Avanti database is a hierarchical database, and is an ABB product. To not have a commercial product gives lack of support, all support work has to be managed by ABB. To use commercial products give advantages like new support for new technology. This master thesis is divided into two sections. The first compares the relational and the object-oriented data models. The second evaluates an object-oriented database product called Objectivity/DB. The work has been divided into four parts: Studies in subject Definition and implementation of simulator Testing Objectivity/DB

11 Thesis for the Degree of Master of Science, 20p Page 11 (76) Writing a report 1.1 Evaluation model An evaluation model is setup to describe the necessary features of an ODBMS. The evaluation model is applied on Objectivity/DB, and the results are presented in this report. The evaluation model is made in three perspectives: Functionality User-friendly Performance Functionality A database has several database features that are important for different applications. A model for evaluating object-oriented database features can be seen from three perspectives: Common database features Persistence Secondary storage Concurrency control Recovery facilities Query facilities Database administration, security and access control Object-oriented features Complex objects Object identity

12 Thesis for the Degree of Master of Science, 20p Page 12 (76) Encapsulation Classes and inheritance Overriding, overloading and dynamic binding Realtime features Determinism Parallelism Event handling Common database features Persistence Objects shall be persistent, they shall survive a process whiteout any explicit operation once they have been stored into the database. Secondary Storage The database shall have some form of secondary storage. The secondary storage is supported by several mechanisms, which is critical for the systems performance. They are indexing, data clustering, caching and query optimization. All these mechanisms shall be transparent to the user. Secondary storage can be provided in several ways. Files and file systems can be used. It is important that few references are required for retrieving an object. How storage is managed is also important, if log files are used and how often the database is synchronized against them. Concurrency Control A multi-process environment requires locking, deadlock and starvation mechanisms. The locking mechanism guarantees that only one process can update an object at a time.

13 Thesis for the Degree of Master of Science, 20p Page 13 (76) The database shall check the applications for deadlock, if deadlock has occurred the database must stop execution, rollback transactions and return an error code for the deadlocked process or processes. Starvation is avoided by having queues on critical resources. Recovery Facilities The database shall be able to automatically or manually be restored to a consistent state. This is very important, since the database must be able to be restored if an error occurs in the execution. This is usually made with log files, were all transactions and checkpoints are logged with a write-ahead log. If the system fails all commands from the last checkpoint is executed. It is important that all commands are idempotent, so that they can be repeated whiteout changing the final result. Interactive query language A query language is used to access and manipulate stored data. Programmers shall be able to access data that has been application created. Even encapsulated data shall be able to be accessed. Database administration, security and access control Database administration shall include: Create and deleting users Optimization of settings Manual locking control Different security levels for different users shall be supported. Optimization for different environments shall be supported. This includes settings for communication, cache sizes, transaction optimization. The database shall be able to optimize queries and cache data to increase performance. It shall be possible to trim the database to optimal setting for a specific application. Objects shall be locked in, groups or one by one. Manual lock release for unlocking locks that is kept by terminated processes should be supported.

14 Thesis for the Degree of Master of Science, 20p Page 14 (76) Object-oriented features Complex objects The basic datatypes must be able to be increased with new types that shall have the same extent of usage. Object Identity To keep object separate each object shall have an object identity. Two objects can be identical, they are one and the same and two objects can be alike, they have the same contents. Encapsulation Both method code and attributes shall be encapsulated within the objects. Attributes can only be manipulated from the defined object methods. The attributes should be accessible for the interactive query language. Classes and Inheritance Objects shall be defined by classes. Classes behaviors shall be able to inherit to other classes. Overriding, overloading and dynamic binding Support for overriding, overload and dynamic binding Realtime features Determinism The demand on determinism is that a process can be blocked under a maximal period of time. If no answer is received during the period an error code is returned. For a totally deterministic database the maximum response time for all database queries must be known. Parallelism

15 Thesis for the Degree of Master of Science, 20p Page 15 (76) Multiple processes must be able to work on one database at the same time. The database shall have separate locks for objects in each process. The processes must not effect each other's transactions. Event handling The database sends a message to a process when an attribute in a specific object is updated. Process communication is managed through the database User-friendly Documentation The documentation shall correspond with the delivered product. All functions and tools shall be well documented. It shall contain examples for installation and configuration, tools and administration. The technical documentation is important for users to optimize the usage of the system. Support The supplier must offer support that guaranties help for users in an acceptable period of time. Agreed support offers must be kept and all questions must be confirmed. Tools It is important to have CASE-tools for application development and database design. Graphical representation of the database gives a better overview of the database than only a text-based definition language. Definition language shall be independent of supplier, so that all CASE-tools on the market can be chosen Performance Database performance The database product must manage the demands of a S.P.I.D.E.R. database. One way to test this is to create a simulator that simulates the S.P.I.D.E.R. behavior and another way is to calculate how much time a database access costs. For results that corresponds against values of an actual implementation of a S.P.I.D.E.R. system a database model that resembles the Avanti structure.

16 Thesis for the Degree of Master of Science, 20p Page 16 (76) When a database access is determined, the maximum database accesses for a period of time can be calculated, and viewing the results gives a direction of the database performance. Creating a S.P.I.D.E.R. simulator gives a database structure that models the real behavior of the system. The simulator has to implement the different parts of the S.P.I.D.E.R. system like the message system, applications and event bursts.

17 Thesis for the Degree of Master of Science, 20p Page 17 (76) 2. Comparative Evaluation of the Object- Oriented Data Model and the Relational Data Model 2.1 Introduction In the late 1960s and the early 1970s [Con98], there were two mainstream approaches to constructing DBMSs. The first approach was based on the hierarchical data model and the second on the network data model. Together these approaches represented the first generation of DBMSs. However, they had some fundamental disadvantages: Complex programs had to be written to answer even simple queries based on navigational record-oriented access. There was minimal data independence. There was no widely accepted theoretical foundation. In 1970 [Con98], Codd produced his seminal paper on the relational data model called 'A relational model of data for large shared data banks'. This paper addressed the disadvantages of the former approaches and was very timely. Many relational DBMSs were implemented thereafter, with the first commercial products appearing in the late 1970s and early 1980s. Today there is over 100 RDBMSs for both mainframe and PC environments, though many are stretching the definition of the relational model. Relational DBMSs are referred to as second-generation DBMSs. In 1976 [Con98], Chen presented the Entity-Relationship model and in 1979 Codd himself attempted to address some of the failings in his original work with an extended version of the relational model called RM/T, and more recently RM/V2 in The attempts to provide a data model represent the real-world more closely has been loosely classified as semantic data modeling. Some of the more famous models are:

18 Thesis for the Degree of Master of Science, 20p Page 18 (76) The Semantic Data Model (Hammer and McLeod, 1981). The Functional Data Model (Shipman, 1981). The Semantic Association Model (Su, 1993). With the increasing complexity of database applications, two new models emerged. The Object-Oriented Data Model (OODM) and the Object-Relational Data Model (ORDM), also referred to as the Extended Relational Data Model (ERDM). Unlike the previous models, the actual compositions of these models are not clear but they represent the third generations of DBMSs. Hierarchical Data Model First Generation DBMS Network Data Model Second Generation DBMS Relational Data Model ER Data Model Third Generation DBMS Semantic Data Model Object-Relational Data Model Object-Oriented Data Model Figure 2-1 Evolution of DBMS 2.2 The Relational Data Model In 1970 [Bur98], Dr. Edgar Codd of IBM developed a Relational Model of Data. The specified objectives were:

19 Thesis for the Degree of Master of Science, 20p Page 19 (76) To allow a high degree of data independence. Application programs most not be affected by modifications to the internal data representation, particularly by the changes of file organizations, record ordering, and access paths. To provide substantial grounds for dealing with data semantics, consistency and redundancy problems. To enable the expansion of set-oriented data manipulations languages Data Model The relational model is based on the mathematical concept of a relation, which is physically represented as a table. A relation is represented as a two-dimensional table of rows and columns. A tuple is row of a relation. An attribute is a named column of a relation. Each attribute has a data type, the types of data that can be stored are limited to character, string, time, date, number (fixed and floating point), and currency. The terminology for the relational model can be confusing. Here are there set of terms for the same thing: Formal terms Alternative 1 Alternative 2 Relation Table File Tuple Row Record Attribute Column Field Table 2-1 Relational model terminology The Relational model has a strong theoretical foundation, based on first-order predicate logic. First-order logic or relational calculus is not a description of how to evaluate a query, a query specifies what is to be retrieved rather than how to retrieve it. This theory supported the development of a standard query language called Structured Query Language (SQL), the standard declarative language that defines and manipulates relational databases. Other strengths of the relational model are simplicity and support for data independence.

20 Thesis for the Degree of Master of Science, 20p Page 20 (76) Query Language Over the last few years SQL has become the standard relational database language. In 1986 [Con98], a standard for SQL was defined by ANSI and was adopted as an international standard by ISO in SQL is the first, and so far, the only standard database language to gain wide acceptance. SQL is a language designed to use relations to transform inputs into required outputs. SQL has two major components: A Data Definition Language (DDL) for defining the database structure. A Data Manipulation Language (DML) for retrieving and updating data. SQL can be used in two ways. The first is to use SQL interactively by entering statements from a terminal. The second way is to embed SQL statements in a procedural language Benefits of the Relational Data Model Simplicity: The concept of tables with rows and columns is simple and easy to understand. End users have a simple datamodel. Theory and standards : RDBMSs benefit from a mathematically well defined theory and the SQL standard. Wide availability: RDBMSs have been widely deployed. Many corporations have site licenses and trained support staffs for at least one relational product. Many vendor products incorporate an RDBMS. Extensibility:

21 Thesis for the Degree of Master of Science, 20p Page 21 (76) There is a broad possibility to change database schema without affecting existing application programs. Declarative data access: In a relational database, the user controls the systems conditions for the retrieval of data. The system accesses data and meets the selected conditions in the SQL statements. The database navigation is hidden from the user. SQL is very powerful and users can write very efficient and complex quires with an easy syntax. Powerful security: The grant and view command can enforce security. Static specification of additional constrains: In a relational database, users can specify additional constraints via declarative assertions Weaknesses of the Relational Data Model Poor representation of real world entities The process of normalization generally leads to the creation of relations that do not correspond to entities in the real world. The fragmentation of a real world entity into many relations, with a physical representation that reflects this structure, is inefficient, leading to many joins during query processing Semantic overloading The relation in the relational model is the only construct for representing data and relationships between data. For a M:N relation between to entities A and B, three relations are created, one to represent each entity, and one to represent the relationship. There is no mechanism to distinguish between entities and relationships, or to distinguish between different kinds of relationship that exists between entities. A 1:M relationship might be for example has, owns or manages. If such distinctions could be made, then it might be possible to build the semantics into the operations. The relational model is semantically overloaded.

22 Thesis for the Degree of Master of Science, 20p Page 22 (76) One way to overcome this problem is to use semantic data models, models that represent more of the data meaning. The relational model is not completely whiteout semantics, it has domains and keys, functional, multi-valued and join dependencies Limited support for integrity and enterprise constrains Integrity refers to the validity and consistency of stored data. Integrity is usually expressed in terms of constraints, which consistency rules that the database is not permitted to violate. Unfortunately, many commercial systems do not fully support these constraints, and it is necessary to build them into the applications. This is dangerous and can lead to duplication of effort and inconsistencies. Furthermore there is no support for enterprise rules in the relational model, which means that they also has to be built into the application Homogeneous data structure The relational model assumes both horizontal and vertical homogeneity. Horizontal homogeneity means that each tuple of a relation must be composed of the same attributes. Vertical homogeneity means that values in a particular column of a relation must all come from the same domain. Further, the intersection of row and column must be an atomic value. This fixed structure is too restrictive for many real world objects that have a complex structure, and it leads to unnatural joins. Many relational DBMSs now allow storage of Binary Large Objects (BLOB). A BLOB is a data value that contains binary information represented as an image, a video or audio sequence, a procedure, or any unstructured object. The DBMS does not have knowledge about the content, or the internal structure of the BLOB. This prevents the use of queries and operations on these objects. A BLOB can not contain another BLOB, which means that composite objects cannot be made and BLOBs generally ignore the behavioral aspects of objects Limited operations The relational model has only a fixed set of operations. No new operations can be specified. This is too restrictive to model the behavior of many real world objects.

23 Thesis for the Degree of Master of Science, 20p Page 23 (76) Difficult handling recursive queries Atomicity of data means that repeating groups are not allowed. As a result, it is extremely difficult to handle recursive queries Impedance mismatch The embedded SQL is used to develop more complex data models. This approach produces an impedance mismatch because different programming paradigms are mixed. SQL is a declarative language that handles rows of data, but a high-level language such as C is a procedural language that only can handle one row of data at a time. SQL uses different models to represent data, this means that it is necessary for the application program to convert between the two representations, which is inefficient, both in programming effort and in runtime resources. Furthermore, since two different type systems is used, it is impossible to automatically type check the application as a whole The Relational Database Market The first commercial relational database was released in 1979[Dat98]. It could store, retrieve, change and delete data in tables. There were no graphical tools, performance was low, no support for backups or security. With these systems no advanced systems could be implemented. RDBMSs was used for simple register management systems. From the early primitive technology the development has gone very fast. The tools has increased and become much better. Performance is increasing every year. The early product failures have gone away. The market has grown enormously. In the beginning a few thousand licenses were sold, today millions are sold every year. With this the prices are lower and the relational market can grow even further into new markets. The vendors of RDBMS have continuously added functions to their products, like triggers, flying backups, simple usage and automatic replication of data between databases. The RDBMSs of today has very little in common with those of yesterday. Oracle was first on the market, soon after came Ingres and Informix. The market was dominated by hierarchical databases, and by IBM. IBM launched DB2 in the 1980s [Dat98], but the sales were small probably because IBM wanted to test the

24 Thesis for the Degree of Master of Science, 20p Page 24 (76) technology and make performance and security good enough. When IBM made the go signal in it became a raise for the whole market. The following years nearly every system engineer converted to the relational technology and the sales went up like a rocket, percent a year until 1995 when the sales became weaker. After 1995 the sales of database licenses do not increased much, instead service and support increases more and more. If this trend continues it could be fateful for the vendors. They have to find new markets to survive. The new markets today is Internet and ebusiness, the vendors provides their databases with tools and functions like web-servers, Java-tools, and programming tools for dynamic WebPages. Today IBM, Oracle and Microsoft are the largest database vendors. Oracle is the dominating vendor and holds over half the market. The products of today are not the simple and pure technical products they were a few years ago. They have so much additional programs and are so very complex that it takes an expert to know which parts that shall be used in a specific project. 2.3 The Object-Oriented Data Model Existing relational DBMSs has been proven inadequate for applications whose needs are different from the traditional business database applications, such as order processing, inventory control, banking, and airline reservations. The new applications include: Computer-aided design (CAD). Computer-aided manufacturing (CAM). Computer-aided software engineering (CASE). Office information systems (OIS) and multimedia systems. Digital publishing. Geographic information systems (GIS). Some of the needs of these applications are: Large number of data types

25 Thesis for the Degree of Master of Science, 20p Page 25 (76) Optimum performance Maintaining complex relationships Rapid navigation between objects Object databases combine the elements of object orientation and object-oriented programming languages with database capabilities. Persistence in an objectoriented database is managed through storage and retrieval of objects. The application does not have to map object data on to disk, it does not need to perform any conversions of datamembers between memory format and disk format. Persistence objects behave the same ways as transient objects; the database offers integration between database and application Data model Objects and Attributes An object is a uniquely identifiable entity that contains both the attributes that describe the state of a real world object and the actions that are associated with it [Con98]. The current state of an object is described by one or more attributes. A complex attribute can contain collections and/or references. An object that contains one or more complex attributes is called a complex object Classes and Inheritance A class is defined to an object database, like a relational table is to relational database, in that it describes a set of objects. A class defines attributes and associated methods once than separately for each object. Class methods are used to change or query the state of the attributes. Some objects may have similar but not identical attributes and methods. If there is a large degree of similarity, it would be useful to share the common properties. Inheritance allows one class to be defined as a subclass of a more general class, a so-called superclass. By default, a subclass inherits all the properties of its superclass or superclasses and, additionally, defines its own unique properties.

26 Thesis for the Degree of Master of Science, 20p Page 26 (76) A class hierarchy offers a great deal of flexibility to change the structure of a database, or to evolve the database schema by adding a new element to a class hierarchy Object Identity In an object-oriented system, each object is assigned an Object Identifier (OID) when it is created. An OID is: System generated. Unique to that object. An OID cannot be reused even if the corresponding object is deleted. Constant, it cannot be altered during its lifetime. Independent of the values of its attributes. Invisible to the user (ideally). Objects can contain or refer to other objects using object identities. For each referenced OID in the system there should always be an object present that corresponds to the OID, so that there is no dangling references in the system Methods and Messages In object technology functions are usually called methods and are encapsulated with data into a self-contained package. Methods define the behavior of the object. They can be used to change the object's state by modifying its attribute values, or to query the values of selected attributes. Messages are the means by which objects communicate. A message is simply a request from one object asking another object to execute one of its methods Complex Objects A complex object is an item that is viewed as a single object in the real world, but combines with other objects in a set of complex relationships. There are many situations where an object consists of subobjects. In an object-oriented system, a contained object can be encapsulated within the complex object and be a part of it and can only be accessed through the complex objects methods. Another way is to

27 Thesis for the Degree of Master of Science, 20p Page 27 (76) allow the contained object to be an independent part from the complex object. In this case the object is not stored directly in the parent object but only its OID. This is known as referential sharing. The contained object has its own structure and methods, and can be owned by several parents. These types of complex objects are sometimes referred to as structured complex objects, since the system knows the composition. The term unstructured complex objects is used to refer a complex object whose structure can be interpreted only by the application program. These objects are sometimes known as Binary Large Objects (BLOBs) Benefits of the Object Data Model Reduced Maintenance The primary goal of object-oriented development is the assurance that the system lifetime will be long while having small maintenance costs. Most of the processes within the system are encapsulated and reside inside the database engine, the behaviors may be reused and incorporated into new behaviors in an ad hoc fashion. The ability to extend existing class hierarchy means that the object database can be quickly extended to handle new classes of objects with the guarantee that these extensions will not effect any existing objects in the database Real world modeling The Object-oriented systems tend to model the real world in a more complete way than relational database methods do. Objects are organized into classes of objects, and objects are associated with behaviors. The model is based on objects, rather than on data and processing, and real-world objects can be directly represented without having to create a relational view. The object-oriented data model allows the real world to be modeled more closely. The object encapsulates both state and behavior, is a more natural and realistic representation of real-world objects. An object can store all the relationships it has with other include in many-to-many relationships, and objects can be formed into complex object that the traditional data models cannot cope with easily.

28 Thesis for the Degree of Master of Science, 20p Page 28 (76) Extensibility OODBMSs allow new abstract data types to be built from existing types. The ability to factor out common properties of several classes and form them into a superclass that can be shared with subclasses can reduce redundancy within systems, and is regarded as one of the main advantages of object-orientation. Overriding is an important feature of inheritance, as it allows special cases to be handled easily, with minimal impact on the rest of the system Improved reliability and flexibility Object-oriented systems are more reliable than traditional systems, primary because new behaviors can be created from existing objects. Because objects can be dynamically called and accessed, new objects may be created at any time. The new objects may inherit data attributes from, one or many other objects. Behaviors may be inherited from superclasses, and novel behavior may be added without effecting systems functions Removal of impedance mismatch A single interface between the Data Manipulation Language (DML) and the programming language overcomes the impedance mismatch. This eliminates many of the inefficiencies that occurs in mapping a declarative language like SQL to an imperative language such as C. Most OODBMSs provide a DML that is computationally complete compared with SQL More expressive query language Navigational access from one object to another is the most common form of data access in an OODBMS. This is in contrast to the associative access of SQL. Navigational access is for example more suitable for handling recursive queries Support for schema evolution The tight coupling between data and applications in an OODBMS makes schema evolution more feasible. Generalization and inheritance allow the schema to be better structured, to be more intuitive, and capture more of the semantics of the application.

29 Thesis for the Degree of Master of Science, 20p Page 29 (76) High code reusability Objects that are created can inherit data attributes and characteristics of existing classes. New objects can also inherit data and behaviors from superclasses. The reusability may be subjective thing, and depends on how the system is defined. Some say that the reusability of code is as good in traditional systems as in objectoriented Improved performance The one-to-one mapping of object programming language objects to database objects has two benefits over other storage approaches. It provides higher performance management of objects and it enables better management of complex interrelationships between objects Weaknesses of the Object Data Model OO development is not a panacea Object-oriented development is best suited for dynamic, interactive environments, as proven by its widespread acceptance in CAD/CAM and engineering design systems. Wide-scale object-oriented corporate systems are still unproved, and many simple information systems applications may not benefit from the objectoriented approach Lack of universal data model There is no universally agreed data model for an object-oriented DBMS, and most models lack a theoretical foundation. This disadvantage is seen as a significant drawback, and is equated to pre-relational systems. The ODMG has proposed an object model, which has become the de facto standard for OODBMSs OO development is not a technology Although many advocates are religious in their fervor for object-oriented systems it is not any specific technology. Major vendors do not yet accept OO development. Is has gained some market respect, but still there are major reservations as to whether OO development will become a major force, or fade into history. Some say that the OO method is only for graphical workstation systems, and there is no need for OO systems within mainstream business systems.

30 Thesis for the Degree of Master of Science, 20p Page 30 (76) Lack of experience In most of the commercial market, managers would like to see an object technology approach, but there is no time to the staff in OO methods. Although commercial OO programming languages have been on the market for several years, systems written with OO languages is less than 1% [Bur98] of systems today. The use of OODBMSs is still limited. This means that we do not yet have the level of experience that we have with traditional systems. The systems are still very much directed to the programmer, rather than the end-user. The learning curve for the design and management of OODBMSs is steep. This results in resistance to the acceptance of the technology. While the OODBMS is limited to a small niche market, this problem will continue to exist Lack of standards There is a lack of standards for OODBMSs. There is no universally agreed data model. There is no standard object-oriented query language. The lack of standards may be the single most damaging factor for the adoption of OODBMSs. Once a major vendor begins conforming to a standard, it can become impossible to retrofit their standard to conform another standard. When the American Standard Committee came out with a standard character set for computers (ASCII), IBM disagreed the standard and proceeded with their own character set, called Extended Binary Character Data Interchange Code (EBCDIC). Even thirty years later, there has still been no resolution between ASCII and EBCDIC, and transfers between ASCII and EBCDIC machines continue to present problems Object databases on today s market Most of the pure OODBMS is listed in Table 2-1. Company Product Ver URL Computer Associates Jasmine ii Gemstone Gemstone Ardent Software, Inc. O Excelon Corporation ObjectStore Enterprise Edition Flowwworks Workflow Systems EVOLVE IBEX Knowledge Systems S.A. ITASCA InterSystems Corporation Caché JYD Software Engineering Pty Ltd. JYD Object Database Micro DataBase Systems, Inc. TITANIUM 8

31 Thesis for the Degree of Master of Science, 20p Page 31 (76) Objectivity, Inc. Objectivity/DB Orient Technologies Orient Enterprise Edition Orient Just Edition 1.1 The Ozone Database Project Ozone - POET Software Corporation POET Object Server Suite Sysra Informatique EyeDB TechKnowledge, Inc. TERSOL Object Database TERSOL Persistent Library 1.03 Versant Corporation VERSANT Bluestream StreamStore A.D. Software OOFile Answer Software MyBase Basesoft Open Systems AB EasyDB Mainstay Phyla NeoLogic Systems NeoAccess, NeoShare ONTOS (formerly Ontologic) ONTOS VIA, DB, OIS Persistent Data Systems IDB Object Database Xcc Software Technology Transfer OBST+ Table 2-1 Available OODBMS on the market During the work of gathering information of OODBMS, there were difficulties in finding new information about the O2 DBMS, a product that has been one of the dominating OODBMSs for several years. When attempts were made to get information from O2 support, the following statement were made by Andrew Menby of Ardent Software Inc.: "As you may have noticed from our web site, we are using O2 as the basis for exciting future products, but not as a widely distributed, standalone ODBMS". O2, which were one of the first OODBMSs on the market, is no longer available for purchase. Peter Kuengs published a comparison of OODBMSs on the market in the article: Comparison of ten oodbms[kue94] from This is the foundation of Table 2-2 [Vah10] and Table 2-3 [Vah20]. Table 2-2 is an updated version made by students at the University of Mining and Metallurgy in Poland. They also created Table 2-3. PRODUCT CRITERION OBJECTIVITY OBJECTSTORE VERSANT (v.5.0) (v.5.0) (v.5.0) Supports user defined data types YES YES YES Supports IS_A relationships YES YES YES Supports PART_OF Relationships YES YES YES Support for multiple inheritance YES YES YES Support for the concept of version YES YES YES Checks for the cardinality between objects YES YES YES 1 Supports long transactions YES YES YES Supports replication of data YES YES YES Supports data encryption NO NO NO Definition languages for attributes of objects C++, JAVA, C, C++, JAVA, C, C++, JAVA,

32 Thesis for the Degree of Master of Science, 20p Page 32 (76) Stores the methods of objects in the DB Methods of objects has to be defined in the language... SMALLTALK, SQL SMALLTALK, ACTIVE X NO, METHODS NO, METHODS ARE ARE STORED IN STORED IN THE THECLIENT CLIENT C++, JAVA, SMALLTALK, SQL C, C++, JAVA, SMALLTALK, ACTIVE X SMALLTALK YES C, C++, JAVA, SMALLTALK Application programming in C++ YES YES YES Application programming in JAVA YES YES YES Application programming in Smalltalk YES YES YES STANDARDS Supports the Object Definition Language ODL YES 1 NO NO Supports the Object Query Language OQL YES 2 NO NO Supports ODMG C++ binding YES 3 YES, v1.2 YES, v1.2 Supports ODMG Smalltalk binding YES, v1.2 YES, v1.2 NO Supports the standard SQL in interactive mode YES NO YES Supports the standard SQL in embedded mode YES YES YES, via ODBC Supports a database language based on SQL YES YES YES QUERIES Supports ad-hoc queries with a GUI YES YES YES Supports ad-hoc queries with a 4GL YES YES YES Supports ad-hoc queries with a knowledge-oriented language (e.g. Lisp) YES NO NO Supports ad-hoc queries with a object-oriented language YES, as long as those (e.g. C++) tools support ODBC YES YES Supports embedded queries with a 4GL YES YES YES SCHEMA MODIFICATION Supports ad-hoc updates of the DB-schema with a GUI YES YES YES Supports ad-hoc updates of the DB-schema with a 4GL NO YES NO Supports ad-hoc updates of the DB-schema with a object-oriented language CASE-TOOLS DBMS is supported by an integrated object-oriented CASE-tool DBMS is supported by a 3rd party object-oriented CASE-tool YES YES YES NO RATIONAL ROSE NO YES, CLASSIFY/DB FROM MICRAM YES, OBJECTMARKER, MARK V, PARADIGM+ YES, OEW, OMTOOL, RATIONAL ROSE DBMS is supported by a non-object-oriented CASE-tool NO NO NO ACCESS TO OTHER DBMS An application running on the OODBMS can read data which reside on other OODBMS An application running on the OODBMS can modify data which reside on other OODBMS An application running on the OODBMS can read data on the relational DBMS ORACLE An application running on the OODBMS can read data on other DBMS YES YES YES YES YES YES YES YES YES YES YES YES ARCHITECTURE DBMS supports a single-user single-tasking environment YES YES YES DBMS supports a single-user multi-tasking environment YES YES 4 YES DBMS supports a multi-user environment YES YES YES DBMS is based on the client-server principle YES, but thin server and fat client (queries YES, but thin server and fat client (queries YES (queries may be executed either in the

33 Thesis for the Degree of Master of Science, 20p Page 33 (76) are executed in the are executed in the client, or in the server) client) client) The physical data can reside on the client part YES, anywhere on the network YES YES The applications can run autonomously on the client part YES YES YES Integration with CORBA environment YES YES YES Data transfer (pages/objects) Pages Pages Objects Object execution on server Passive Passive Passive TRANSACTIONS DBMS supports nested transactions NO, but it supports concurrent YES YES transactions DBMS supports MROW YES YES NO DATA DBMS supports long transactions YES YES YES OPERATING SYSTEMS DBMS supports MS_Windows YES, WINDOWS YES, WINDOWS NT NT and 95/98 and 95/98 DBMS supports SUN OS YES YES YES DBMS supports SUN SOLARIS YES YES YES DBMS supports AIX YES YES YES DBMS supports data distribution over several servers YES YES YES DBMS supports other OS Most of UNIX systems HP-UX, IRIX, DIGITAL UNIX, NEC UNIX, Siemens Nixdorff UNIX Table 2-2 Comparisons of three OODBMSs YES, WINDOWS NT and 95/98 Most of UNIX systems 1 Trough a 3rd party product from their German distributor (MICRAM). 2 Supports all of SQL-92 which includes SQL select with method execution, but not OQL typing that differs from SQL All basis capabilities (ref, relationships, etc.), but not collections 4 Supports multiple threads within a transaction rather than transaction-per-thread. PRODUCT CRITERION POET v.5.0 GEMSTONE JASMINE Supports user defined data types YES YES YES Supports IS_A relationships YES YES YES Supports PART_OF relationships YES YES YES Supports multiple inheritance YES Smalltalk - NO Java - YES YES Supports the concept of version NO YES NO Checks the cardinality between objects YES NO YES Supports long transactions YES NO NO Supports replication of data YES YES NO Supports data encryption NO YES NO Definition languages for attributes of objects C++, JAVA JAVA, Smalltalk C, C++, ODQL, JAVA Stores the methods of objects in the DB NO YES YES Methods of objects has to be defined in the language... C++, JAVA JAVA, Smalltalk C, C++, ODQL, JAVA Supports application programming in C++ YES YES YES Supports application programming in JAVA YES YES YES Supports application programming in Smalltalk NO YES NO STANDARDS Supports the Object Definition Language ODL YES YES NO

34 Thesis for the Degree of Master of Science, 20p Page 34 (76) Supports the Object Query Language OQL YES NO YES Supports ODMG C++ binding YES NO YES, via TDI Inc. Supports ODMG Smalltalk binding NO NO NO Supports the standard SQL in interactive mode YES Smalltalk - YES YES Supports the standard SQL in embedded mode Supports a database language based on SQL YES YES Java - NO Smalltalk - YES Java - NO Smalltalk - YES Java - NO Via ODBC YES Via ODBC QUERIES Supports ad-hoc queries with GUI YES YES YES Supports ad-hoc queries with 4GL NO NO NO Supports ad-hoc queries with object-oriented language YES YES YES, Java, Smalltalk YES (e.g. C++) Supports embedded queries with a 4GL NO NO NO SCHEMA MODIFICATION Supports ad-hoc updates of the DB-schema with a GUI YES YES YES Supports ad-hoc updates of the DB-schema with a 4GL NO NO NO Supports ad-hoc updates of the DB-schema with a knowledge-oriented language Supports ad-hoc updates of the DB-schema with a object-oriented language CASE-TOOLS DBMS is supported by an integrated object-oriented CASE-tool DBMS is supported by a 3 rd party object-oriented CASE-tool DBMS is supported by a knowledge-oriented CASE-tool ACCESS TO OTHER DBMS An application running on the OODBMS can read data which reside on other OODBMS An application running on the OODBMS can modify data which reside on other OODBMS An application running on the OODBMS can read data on the relational DBMS ORACLE An application running on the OODBMS can read data on other DBMS NO NO NO YES YES, JAVA, Smalltalk YES YES RATIONAL ROSE, OEW YES See above NO NO YES NO NO NO NO NO 2 NO NO NO 2 NO NO YES YES YES YES DB2 MS-SQL YES Sybase Informix YES, OpenIngres, Sybase, Informix, MS- SQL, CA-IDMS, CA-Datacom, DB2,VSAM,RMS ARCHITECTURE Supports a single-user single-tasking environment YES NO YES Supports single-user multi-tasking environment YES YES YES Supports a multi-user environment YES YES YES DBMS is based on the client-server principle YES YES YES The physical data can reside on the client part YES YES NO The applications can run autonomously on the client part YES 3 NO NO Integration with CORBA environment YES YES YES Data transfer (pages/objects) OBJECTS 4 PAGES OBJECTS