evaluation of an object database for use in s.p.i.d.e.r ... · evaluation of an object database for...

Thesis for the Degree of Master of Science, 20p (76)Evaluation of An Object Database for use in S.P.I.D.E.R.

ABB Network Partner1MRK 3-088 rev 1

Thesis for the Degree of Master of Science, 20p

Evaluation of An Object Database for use inS.P.I.D.E.R.

Jonas Brännvall

Department of Computer ScienceMälardalens UniversityVästerås, June 2000



Abstract Object-oriented technology is a growing market. Object-orientedanalysis and design methods, programming languages and tools,new companies and products emerge in order to satisfy the need ofmore flexible and powerful data management.

The relational database products have been dominating the marketsince the 1980s. It has a strong formal background and fits manyapplications that require a powerful query language.

Relational database systems are based on two-dimensional tableswere items appears as a row. An object can model everything,ranging from numbers to a person to an aeroplane. For expressingobject structures in two-dimensional tables, complex interfaces areneeded, to handle data manipulation correctly. The semanticmismatch between object-oriented programming languages andthe relational data model has led to the development of an object-oriented database, which supports the object model.

This document describes the differences between relational andobject-oriented database models. It also includes an evaluation ofthe object-oriented database product Objectivity.



Table of Contents

1. INTRODUCTION............................................................................... 101.1 Evaluation model....................................................................................... 11

1.1.1 Functionality ............................................................................................................111.1.2 Common database features ......................................................................................121.1.3 Object-oriented features...........................................................................................141.1.4 Realtime features .....................................................................................................141.1.5 User-friendly............................................................................................................151.1.6 Performance.............................................................................................................15

2. COMPARATIVE EVALUATION OF THE OBJECT-ORIENTED DATAMODEL AND THE RELATIONAL DATA MODEL................................... 17

2.1 Introduction ............................................................................................... 172.2 The Relational Data Model ....................................................................... 18

2.2.1 Data Model ..............................................................................................................192.2.2 Query Language.......................................................................................................202.2.3 Benefits of the Relational Data Model.....................................................................202.2.4 Weaknesses of the Relational Data Model ..............................................................21

2.2.4.1 Poor representation of real world entities ...........................................................212.2.4.2 Semantic overloading..........................................................................................212.2.4.3 Poor support for integrity and enterprise constrains ...........................................222.2.4.4 Homogeneous data structure ...............................................................................222.2.4.5 Limited operations ..............................................................................................222.2.4.6 Difficult handling recursive queries....................................................................232.2.4.7 Impedance mismatch...........................................................................................23

2.2.5 The Relational Database Market..............................................................................232.3 The Object-Oriented Data Model.............................................................. 24

2.3.1 Data model...............................................................................................................252.3.1.1 Objects and Attributes.........................................................................................252.3.1.2 Classes and Inheritance.......................................................................................252.3.1.3 Object Identity ....................................................................................................262.3.1.4 Methods and Messages .......................................................................................262.3.1.5 Complex Objects.................................................................................................26

2.3.2 Benefits of the Object Data Model ..........................................................................272.3.2.1 Reduced Maintenance .........................................................................................272.3.2.2 Real world modeling...........................................................................................272.3.2.3 Extensibility ........................................................................................................282.3.2.4 Improved reliability and flexibility .....................................................................282.3.2.5 Removal of impedance mismatch .......................................................................282.3.2.6 More expressive query language.........................................................................282.3.2.7 Support for schema evolution .............................................................................282.3.2.8 High code reusability ..........................................................................................29



2.3.2.9 Improved performance........................................................................................292.3.3 Weaknesses of the Object Data Model ....................................................................29

2.3.3.1 OO development is not a panacea.......................................................................292.3.3.2 Lack of universal data model ..............................................................................292.3.3.3 OO development is not a technology ..................................................................292.3.3.4 Lack of experience ..............................................................................................302.3.3.5 Lack of standards ................................................................................................30

2.3.4 Object databases on today’s market.........................................................................30

3. A STANDARD OBJECT-ORIENTED DATA MODEL IS EMERGING363.1 Introduction ............................................................................................... 363.2 The Object Database Management Group (ODMG)................................. 37

3.2.1 Object Model ...........................................................................................................383.2.2 The Object Definition Language .............................................................................393.2.3 The Object Query Language....................................................................................39

4. OBJECTIVITY .................................................................................. 414.1 Introduction ............................................................................................... 414.2 Database Features...................................................................................... 41

4.2.1 Object Model ...........................................................................................................414.2.2 Object Identifiers .....................................................................................................414.2.3 Data Modeling .........................................................................................................424.2.4 Object Memory Management ..................................................................................44

4.2.4.1 Architecture.........................................................................................................444.2.4.2 Logical Storage ...................................................................................................464.2.4.3 Caching ...............................................................................................................474.2.4.4 Accessing Objects...............................................................................................48

4.2.5 Transaction Management.........................................................................................494.2.5.1 Transactions ........................................................................................................494.2.5.2 Locking ...............................................................................................................50

5. S.P.I.D.E.R. SIMULATOR ................................................................ 525.1 Introduction ............................................................................................... 525.2 Database Design ........................................................................................ 52

5.2.1 System size ..............................................................................................................575.2.2 Object Classes..........................................................................................................57

5.2.2.1 Network ..............................................................................................................575.2.2.2 Measurement.......................................................................................................585.2.2.3 Node....................................................................................................................585.2.2.4 Event Storage ......................................................................................................585.2.2.5 TTD Storage .......................................................................................................595.2.2.6 TransmissionLine................................................................................................595.2.2.7 Switch .................................................................................................................595.2.2.8 BusBar ................................................................................................................59

5.3 Application Design.................................................................................... 59

6. EVALUATION................................................................................... 64



6.1 Functionality.............................................................................................. 646.1.1 Common database features ......................................................................................646.1.2 Object-oriented features...........................................................................................656.1.3 Realtime features .....................................................................................................666.1.4 User friendly ............................................................................................................66

6.1.4.1 Documentation....................................................................................................666.1.4.2 Support................................................................................................................676.1.4.3 Tools ...................................................................................................................67

6.2 Performance............................................................................................... 696.2.1 Test Cases with Objectivity .....................................................................................696.2.2 Test Case with Objectivity cache.............................................................................706.2.3 Test Cases with C++................................................................................................71

7. CONCLUSION.................................................................................. 738. REFERENCES ................................................................................. 75



Preface

PurposeThis is a master thesis in computer science written by Jonas Brännvall, student atthe Department of Computer Science at Mälardalens University of Västerås,Sweden. It documents the work, which has been performed at ABB AutomationSystems under the supervision of Lars-Ola Österlund at ABB and Ivica Crnkovicof Mälardalens University.



Table of figures

Figure 2-1 Evolution of DBMS............................................................... 18Figure 4-1 Objectivity/C++ develompent process ............................... 43Figure 4-2 Distributed mixed-tier design.............................................. 45Figure 4-3 Objectivity/DB logic storage model.................................... 46Figure 5-1 Simple power station model................................................ 52Figure 5-2 Attribute design.................................................................... 53Figure 5-3 General database design..................................................... 54Figure 5-4 Database design presented UML........................................ 56Figure 5-5 Application data flow ........................................................... 60Figure 5-6 DAS and E&A Processing High Load................................. 61Figure 5-7 E&A Processing High Load................................................. 61Figure 5-8 TDD Processing High Load................................................. 62Figure 5-9 DNC Processing High Load................................................. 62Figure 5-10 NMB high load .................................................................... 63Figure 5-11 SE high load ....................................................................... 63Figure 6-1 Diagram over execution time with different caches.......... 71

List of tables

Table 2-1 Relational model terminology............................................... 19Table 2-2 Available OODBMS on the market ....................................... 31Table 2-3 Comparisons of three OODBMSs......................................... 33Table 2-4 Comparisons of three OODMBSs......................................... 35Table 6-1 Objectivity/DB concurrency mechanisms ........................... 64Table 6-2 Objectivity/DB Browser......................................................... 68Table 6-3 Program code......................................................................... 69Table 6-4 Execution times of different operations .............................. 70Table 6-5 Execution times with different cache sizes......................... 71Table 6-6 Program code......................................................................... 72Table 6-7 Execution times for C++ classes.......................................... 72



Conventions

Convention MeaningANSI American National Standards Institute

API Application Program Interface

CAD Computer Aided Design

CAM Computer Aided Manufacturing

CASE Computer Aided Software Engineering

DAS Data Acquisition System

DBMS Database Management System

DDL Data Definition Language

DML Data Manipulation Language

DNC Dynamic Network Coloring

E&A Event & Alarms

ISO International Standards Organization

LRU Least Recently Used

MROW Multiple Readers One Writer

NMB Network Module Builder

ODMG Object Data Management Group

OODBMS Object Oriented Database Management System

RDBMS Relational Database Management System



SE State Estimator

SQL Structured Query Language

TTD Time Tagged Data

TrademarksObjectivity and Objectivity/DB are trademarks of Objectivity Inc.; ObjectStore isa trademark of Object Design Inc.; VERSANT is a trademark of Versant ObjectTechnology Corporation;



1. IntroductionS.P.I.D.E.R. is a SCADA/EMS system for supervision and control of an electricalPower System, manufactured by ABB Network Partner. The S.P.I.D.E.R. systemis used for energy and distribution management all over the world. The system isbuilt around a database/middelware, Avanti, which is integrated in a distributedenvironment 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 constantlyevolving and new products hit the market, continuos evaluations of these productshas to be made. This master thesis is one such evaluation.

The database market has been divided into relational and object-orienteddatabases. The S.P.I.D.E.R. system is well suited for an object-orientedenvironment, both on the database and application side. Performance is the mostimportant 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 forreplacing the Avanti database is foremost a performance issue, but other importantfeatures are portability, connectivity, scalability, interoperability, and distribution.

The Avanti database is a hierarchical database, and is an ABB product. To nothave a commercial product gives lack of support, all support work has to bemanaged by ABB. To use commercial products give advantages like new supportfor new technology.

This master thesis is divided into two sections. The first compares the relationaland the object-oriented data models. The second evaluates an object-orienteddatabase product called Objectivity/DB.

The work has been divided into four parts:

• Studies in subject

• Definition and implementation of simulator

• Testing Objectivity/DB



• Writing a report

1.1 Evaluation modelAn evaluation model is setup to describe the necessary features of an ODBMS.The evaluation model is applied on Objectivity/DB, and the results are presentedin this report. The evaluation model is made in three perspectives:

• Functionality

• User-friendly

• Performance

1.1.1 FunctionalityA database has several database features that are important for differentapplications. A model for evaluating object-oriented database features can be seenfrom 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



• Encapsulation

• Classes and inheritance

• Overriding, overloading and dynamic binding

Realtime features

• Determinism

• Parallelism

• Event handling

1.1.2 Common database featuresPersistence

Objects shall be persistent, they shall survive a process whiteout any explicitoperation once they have been stored into the database.

Secondary Storage

The database shall have some form of secondary storage. The secondary storage issupported by several mechanisms, which is critical for the systems performance.They are indexing, data clustering, caching and query optimization. All thesemechanisms shall be transparent to the user.

Secondary storage can be provided in several ways. Files and file systems can beused. It is important that few references are required for retrieving an object. Howstorage is managed is also important, if log files are used and how often thedatabase is synchronized against them.

Concurrency Control

A multi-process environment requires locking, deadlock and starvationmechanisms.

The locking mechanism guarantees that only one process can update an object at atime.



The database shall check the applications for deadlock, if deadlock has occurredthe database must stop execution, rollback transactions and return an error codefor the deadlocked process or processes. Starvation is avoided by having queueson critical resources.

Recovery Facilities

The database shall be able to automatically or manually be restored to a consistentstate. This is very important, since the database must be able to be restored if anerror occurs in the execution. This is usually made with log files, were alltransactions and checkpoints are logged with a write-ahead log. If the system failsall commands from the last checkpoint is executed. It is important that allcommands are idempotent, so that they can be repeated whiteout changing thefinal result.

Interactive query language

A query language is used to access and manipulate stored data. Programmers shallbe able to access data that has been application created. Even encapsulated datashall 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 settingsfor communication, cache sizes, transaction optimization. The database shall beable to optimize queries and cache data to increase performance. It shall bepossible to trim the database to optimal setting for a specific application.

Objects shall be locked in, groups or one by one. Manual lock release forunlocking locks that is kept by terminated processes should be supported.



1.1.3 Object-oriented featuresComplex objects

The basic datatypes must be able to be increased with new types that shall havethe same extent of usage.

Object Identity

To keep object separate each object shall have an object identity. Two objects canbe identical, they are one and the same and two objects can be alike, they have thesame contents.

Encapsulation

Both method code and attributes shall be encapsulated within the objects.Attributes can only be manipulated from the defined object methods. Theattributes should be accessible for the interactive query language.

Classes and Inheritance

Objects shall be defined by classes. Classes behaviors shall be able to inherit toother classes.

Overriding, overloading and dynamic binding

Support for overriding, overload and dynamic binding.

1.1.4 Realtime featuresDeterminism

The demand on determinism is that a process can be blocked under a maximalperiod of time. If no answer is received during the period an error code isreturned.

For a totally deterministic database the maximum response time for all databasequeries must be known.

Parallelism



Multiple processes must be able to work on one database at the same time. Thedatabase shall have separate locks for objects in each process. The processes mustnot effect each other's transactions.

Event handling

The database sends a message to a process when an attribute in a specific object isupdated. Process communication is managed through the database.

1.1.5 User-friendlyDocumentation

The documentation shall correspond with the delivered product. All functions andtools shall be well documented. It shall contain examples for installation andconfiguration, tools and administration. The technical documentation is importantfor users to optimize the usage of the system.

Support

The supplier must offer support that guaranties help for users in an acceptableperiod of time. Agreed support offers must be kept and all questions must beconfirmed.

Tools

It is important to have CASE-tools for application development and databasedesign. Graphical representation of the database gives a better overview of thedatabase than only a text-based definition language. Definition language shall beindependent of supplier, so that all CASE-tools on the market can be chosen.

1.1.6 PerformanceDatabase performance

The database product must manage the demands of a S.P.I.D.E.R. database. Oneway to test this is to create a simulator that simulates the S.P.I.D.E.R. behaviorand another way is to calculate how much time a database access costs. For resultsthat corresponds against values of an actual implementation of a S.P.I.D.E.R.system a database model that resembles the Avanti structure.



When a database access is determined, the maximum database accesses for aperiod of time can be calculated, and viewing the results gives a direction of thedatabase performance.

Creating a S.P.I.D.E.R. simulator gives a database structure that models the realbehavior of the system. The simulator has to implement the different parts of theS.P.I.D.E.R. system like the message system, applications and event bursts.



2. Comparative Evaluation of the Object-Oriented Data Model and the Relational DataModel

2.1 IntroductionIn the late 1960s and the early 1970s [Con98], there were two mainstreamapproaches to constructing DBMSs. The first approach was based on thehierarchical data model and the second on the network data model. Together theseapproaches represented the first generation of DBMSs. However, they had somefundamental disadvantages:

• Complex programs had to be written to answer even simple queries based onnavigational 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 modelcalled 'A relational model of data for large shared data banks'. This paperaddressed the disadvantages of the former approaches and was very timely. Manyrelational DBMSs were implemented thereafter, with the first commercialproducts appearing in the late 1970s and early 1980s. Today there is over 100RDBMSs for both mainframe and PC environments, though many are stretchingthe definition of the relational model. Relational DBMSs are referred to assecond-generation DBMSs.

In 1976 [Con98], Chen presented the Entity-Relationship model and in 1979 Coddhimself attempted to address some of the failings in his original work with anextended version of the relational model called RM/T, and more recently RM/V2in 1990.

The attempts to provide a data model represent the real-world more closely hasbeen loosely classified as semantic data modeling. Some of the more famousmodels are:



• 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 modelsemerged. The Object-Oriented Data Model (OODM) and the Object-RelationalData Model (ORDM), also referred to as the Extended Relational Data Model(ERDM). Unlike the previous models, the actual compositions of these models arenot clear but they represent the third generations of DBMSs.

Object-Relational Data Model

Hierarchical Data Model

Semantic Data Model

ER Data Model

Relational Data Model

Network Data Model

Object-Oriented Data Model

First Generation DBMS

Second Generation DBMS

Third Generation DBMS

Figure 2-1 Evolution of DBMS

2.2 The Relational Data ModelIn 1970 [Bur98], Dr. Edgar Codd of IBM developed a Relational Model of Data.The specified objectives were:



• To allow a high degree of data independence. Application programs most notbe affected by modifications to the internal data representation, particularly bythe changes of file organizations, record ordering, and access paths.

• To provide substantial grounds for dealing with data semantics, consistencyand redundancy problems.

• To enable the expansion of set-oriented data manipulations languages.

2.2.1 Data ModelThe relational model is based on the mathematical concept of a relation, which isphysically represented as a table. A relation is represented as a two-dimensionaltable of rows and columns. A tuple is row of a relation. An attribute is a namedcolumn of a relation. Each attribute has a data type, the types of data that can bestored are limited to character, string, time, date, number (fixed and floatingpoint), and currency.

The terminology for the relational model can be confusing. Here are there set ofterms 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-orderpredicate logic. First-order logic or relational calculus is not a description of howto evaluate a query, a query specifies what is to be retrieved rather than how toretrieve it. This theory supported the development of a standard query languagecalled Structured Query Language (SQL), the standard declarative language thatdefines and manipulates relational databases. Other strengths of the relationalmodel are simplicity and support for data independence.



2.2.2 Query LanguageOver the last few years SQL has become the standard relational databaselanguage. In 1986 [Con98], a standard for SQL was defined by ANSI and wasadopted as an international standard by ISO in 1987. 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 requiredoutputs. 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 enteringstatements from a terminal. The second way is to embed SQL statements in aprocedural language.

2.2.3 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 SQLstandard.

• Wide availability:

RDBMSs have been widely deployed. Many corporations have site licenses andtrained support staffs for at least one relational product. Many vendor productsincorporate an RDBMS.

• Extensibility:



There is a broad possibility to change database schema without affecting existingapplication programs.

• Declarative data access:

In a relational database, the user controls the systems conditions for the retrievalof data. The system accesses data and meets the selected conditions in the SQLstatements. The database navigation is hidden from the user. SQL is verypowerful and users can write very efficient and complex quires with an easysyntax.

• 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 declarativeassertions.

2.2.4 Weaknesses of the Relational Data Model

2.2.4.1 Poor representation of real world entitiesThe process of normalization generally leads to the creation of relations that donot correspond to entities in the real world. The fragmentation of a real worldentity into many relations, with a physical representation that reflects thisstructure, is inefficient, leading to many joins during query processing.

2.2.4.2 Semantic overloadingThe relation in the relational model is the only construct for representing data andrelationships between data. For a M:N relation between to entities A and B, threerelations are created, one to represent each entity, and one to represent therelationship. There is no mechanism to distinguish between entities andrelationships, or to distinguish between different kinds of relationship that existsbetween 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 semanticsinto the operations. The relational model is semantically overloaded.



One way to overcome this problem is to use semantic data models, models thatrepresent more of the data meaning. The relational model is not completelywhiteout semantics, it has domains and keys, functional, multi-valued and joindependencies.

2.2.4.3 Limited support for integrity and enterprise constrainsIntegrity refers to the validity and consistency of stored data. Integrity is usuallyexpressed in terms of constraints, which consistency rules that the database is notpermitted to violate. Unfortunately, many commercial systems do not fullysupport 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, whichmeans that they also has to be built into the application.

2.2.4.4 Homogeneous data structureThe relational model assumes both horizontal and vertical homogeneity.Horizontal homogeneity means that each tuple of a relation must be composed ofthe same attributes. Vertical homogeneity means that values in a particularcolumn of a relation must all come from the same domain. Further, theintersection of row and column must be an atomic value. This fixed structure istoo restrictive for many real world objects that have a complex structure, and itleads to unnatural joins.

Many relational DBMSs now allow storage of Binary Large Objects (BLOB). ABLOB is a data value that contains binary information represented as an image, avideo or audio sequence, a procedure, or any unstructured object. The DBMS doesnot have knowledge about the content, or the internal structure of the BLOB. Thisprevents the use of queries and operations on these objects. A BLOB can notcontain another BLOB, which means that composite objects cannot be made andBLOBs generally ignore the behavioral aspects of objects.

2.2.4.5 Limited operationsThe relational model has only a fixed set of operations. No new operations can bespecified. This is too restrictive to model the behavior of many real world objects.



2.2.4.6 Difficult handling recursive queriesAtomicity of data means that repeating groups are not allowed. As a result, it isextremely difficult to handle recursive queries.

2.2.4.7 Impedance mismatchThe embedded SQL is used to develop more complex data models. This approachproduces an impedance mismatch because different programming paradigms aremixed. SQL is a declarative language that handles rows of data, but a high-levellanguage such as C is a procedural language that only can handle one row of dataat a time. SQL uses different models to represent data, this means that it isnecessary 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 toautomatically type check the application as a whole.

2.2.5 The Relational Database MarketThe first commercial relational database was released in 1979[Dat98]. It couldstore, retrieve, change and delete data in tables. There were no graphical tools,performance was low, no support for backups or security. With these systems noadvanced systems could be implemented. RDBMSs was used for simple registermanagement systems.

From the early primitive technology the development has gone very fast. Thetools has increased and become much better. Performance is increasing everyyear. The early product failures have gone away. The market has grownenormously. In the beginning a few thousand licenses were sold, today millionsare sold every year. With this the prices are lower and the relational market cangrow even further into new markets.

The vendors of RDBMS have continuously added functions to their products, liketriggers, flying backups, simple usage and automatic replication of data betweendatabases. The RDBMSs of today has very little in common with those ofyesterday.

Oracle was first on the market, soon after came Ingres and Informix. The marketwas dominated by hierarchical databases, and by IBM. IBM launched DB2 in the1980s [Dat98], but the sales were small probably because IBM wanted to test the



technology and make performance and security good enough. When IBM madethe go signal in 1987-1988 it became a raise for the whole market. The followingyears nearly every system engineer converted to the relational technology and thesales went up like a rocket, 30-50 percent a year until 1995 when the sales becameweaker. After 1995 the sales of database licenses do not increased much, insteadservice and support increases more and more. If this trend continues it could befateful for the vendors. They have to find new markets to survive.

The new markets today is Internet and eBusiness, the vendors provides theirdatabases with tools and functions like web-servers, Java-tools, and programmingtools for dynamic WebPages.

Today IBM, Oracle and Microsoft are the largest database vendors. Oracle is thedominating vendor and holds over half the market. The products of today are notthe simple and pure technical products they were a few years ago. They have somuch additional programs and are so very complex that it takes an expert to knowwhich parts that shall be used in a specific project.

2.3 The Object-Oriented Data ModelExisting relational DBMSs has been proven inadequate for applications whoseneeds are different from the traditional business database applications, such asorder processing, inventory control, banking, and airline reservations. The newapplications 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



• Optimum performance

• Maintaining complex relationships

• Rapid navigation between objects

Object databases combine the elements of object orientation and object-orientedprogramming languages with database capabilities. Persistence in an object-oriented database is managed through storage and retrieval of objects. Theapplication does not have to map object data on to disk, it does not need toperform any conversions of datamembers between memory format and diskformat. Persistence objects behave the same ways as transient objects; thedatabase offers integration between database and application.

2.3.1 Data model

2.3.1.1 Objects and AttributesAn object is a uniquely identifiable entity that contains both the attributes thatdescribe 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 complexattribute can contain collections and/or references. An object that contains one ormore complex attributes is called a complex object.

2.3.1.2 Classes and InheritanceA class is defined to an object database, like a relational table is to relationaldatabase, in that it describes a set of objects. A class defines attributes andassociated methods once than separately for each object. Class methods are usedto change or query the state of the attributes.

Some objects may have similar but not identical attributes and methods. If there isa 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, aso-called superclass. By default, a subclass inherits all the properties of itssuperclass or superclasses and, additionally, defines its own unique properties.



A class hierarchy offers a great deal of flexibility to change the structure of adatabase, or to evolve the database schema by adding a new element to a classhierarchy.

2.3.1.3 Object IdentityIn 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 correspondingobject is deleted.

• Constant, it cannot be altered during its lifetime. Independent of the values ofits attributes.

• Invisible to the user (ideally).

Objects can contain or refer to other objects using object identities. For eachreferenced OID in the system there should always be an object present thatcorresponds to the OID, so that there is no dangling references in the system.

2.3.1.4 Methods and MessagesIn object technology functions are usually called methods and are encapsulatedwith data into a self-contained package. Methods define the behavior of theobject. They can be used to change the object's state by modifying its attributevalues, or to query the values of selected attributes.

Messages are the means by which objects communicate. A message is simply arequest from one object asking another object to execute one of its methods.

2.3.1.5 Complex ObjectsA complex object is an item that is viewed as a single object in the real world, butcombines with other objects in a set of complex relationships. There are manysituations where an object consists of subobjects. In an object-oriented system, acontained object can be encapsulated within the complex object and be a part of itand can only be accessed through the complex objects methods. Another way is to



allow the contained object to be an independent part from the complex object. Inthis case the object is not stored directly in the parent object but only its OID. Thisis known as referential sharing. The contained object has its own structure andmethods, and can be owned by several parents.

These types of complex objects are sometimes referred to as structured complexobjects, since the system knows the composition. The term unstructured complexobjects is used to refer a complex object whose structure can be interpreted onlyby the application program. These objects are sometimes known as Binary LargeObjects (BLOBs).

2.3.2 Benefits of the Object Data Model

2.3.2.1 Reduced MaintenanceThe primary goal of object-oriented development is the assurance that the systemlifetime will be long while having small maintenance costs. Most of the processeswithin the system are encapsulated and reside inside the database engine, thebehaviors may be reused and incorporated into new behaviors in an ad hocfashion. The ability to extend existing class hierarchy means that the objectdatabase can be quickly extended to handle new classes of objects with theguarantee that these extensions will not effect any existing objects in the database.

2.3.2.2 Real world modelingThe Object-oriented systems tend to model the real world in a more complete waythan relational database methods do. Objects are organized into classes of objects,and objects are associated with behaviors. The model is based on objects, ratherthan on data and processing, and real-world objects can be directly representedwithout 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 realisticrepresentation of real-world objects. An object can store all the relationships it haswith other include in many-to-many relationships, and objects can be formed intocomplex object that the traditional data models cannot cope with easily.



2.3.2.3 ExtensibilityOODBMSs allow new abstract data types to be built from existing types. Theability to factor out common properties of several classes and form them into asuperclass that can be shared with subclasses can reduce redundancy withinsystems, 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 behandled easily, with minimal impact on the rest of the system.

2.3.2.4 Improved reliability and flexibilityObject-oriented systems are more reliable than traditional systems, primarybecause new behaviors can be created from existing objects. Because objects canbe dynamically called and accessed, new objects may be created at any time. Thenew objects may inherit data attributes from, one or many other objects.Behaviors may be inherited from superclasses, and novel behavior may be addedwithout effecting systems functions.

2.3.2.5 Removal of impedance mismatchA single interface between the Data Manipulation Language (DML) and theprogramming language overcomes the impedance mismatch. This eliminatesmany of the inefficiencies that occurs in mapping a declarative language like SQLto an imperative language such as C. Most OODBMSs provide a DML that iscomputationally complete compared with SQL.

2.3.2.6 More expressive query languageNavigational access from one object to another is the most common form of dataaccess in an OODBMS. This is in contrast to the associative access of SQL.Navigational access is for example more suitable for handling recursive queries.

2.3.2.7 Support for schema evolutionThe tight coupling between data and applications in an OODBMS makes schemaevolution more feasible. Generalization and inheritance allow the schema to bebetter structured, to be more intuitive, and capture more of the semantics of theapplication.



2.3.2.8 High code reusabilityObjects that are created can inherit data attributes and characteristics of existingclasses. New objects can also inherit data and behaviors from superclasses. Thereusability 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 object-oriented.

2.3.2.9 Improved performanceThe one-to-one mapping of object programming language objects to databaseobjects has two benefits over other storage approaches. It provides higherperformance management of objects and it enables better management of complexinterrelationships between objects.

2.3.3 Weaknesses of the Object Data Model

2.3.3.1 OO development is not a panaceaObject-oriented development is best suited for dynamic, interactive environments,as proven by its widespread acceptance in CAD/CAM and engineering designsystems. Wide-scale object-oriented corporate systems are still unproved, andmany simple information systems applications may not benefit from the object-oriented approach.

2.3.3.2 Lack of universal data modelThere is no universally agreed data model for an object-oriented DBMS, and mostmodels lack a theoretical foundation. This disadvantage is seen as a significantdrawback, and is equated to pre-relational systems. The ODMG has proposed anobject model, which has become the de facto standard for OODBMSs.

2.3.3.3 OO development is not a technologyAlthough many advocates are religious in their fervor for object-oriented systemsit is not any specific technology. Major vendors do not yet accept OOdevelopment. Is has gained some market respect, but still there are majorreservations as to whether OO development will become a major force, or fadeinto history. Some say that the OO method is only for graphical workstationsystems, and there is no need for OO systems within mainstream businesssystems.



2.3.3.4 Lack of experienceIn most of the commercial market, managers would like to see an objecttechnology approach, but there is no time to the staff in OO methods. Althoughcommercial OO programming languages have been on the market for severalyears, systems written with OO languages is less than 1% [Bur98] of systemstoday.

The use of OODBMSs is still limited. This means that we do not yet have thelevel of experience that we have with traditional systems. The systems are stillvery much directed to the programmer, rather than the end-user. The learningcurve for the design and management of OODBMSs is steep. This results inresistance to the acceptance of the technology. While the OODBMS is limited to asmall niche market, this problem will continue to exist.

2.3.3.5 Lack of standardsThere is a lack of standards for OODBMSs. There is no universally agreed datamodel. There is no standard object-oriented query language. The lack of standardsmay be the single most damaging factor for the adoption of OODBMSs.

Once a major vendor begins conforming to a standard, it can become impossibleto retrofit their standard to conform another standard. When the AmericanStandard 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 thirtyyears later, there has still been no resolution between ASCII and EBCDIC, andtransfers between ASCII and EBCDIC machines continue to present problems.

2.3.4 Object databases on today’s marketMost of the pure OODBMS is listed in Table 2-1.

Company Product Ver URLComputer Associates Jasmine ii Www.cai.comGemstone Gemstone Www.gemstone.comArdent Software, Inc. O2 5.02 Www.ardent.comExcelon Corporation ObjectStore Enterprise Edition 6.0 Www.exceloncorp.com/objectstore/Flowwworks Workflow Systems EVOLVE 1.0 Http://flowwworks.comIBEX Knowledge Systems S.A. ITASCA 2.4 Www.ibex.chInterSystems Corporation Caché 3.2 Www.intersys.comJYD Software Engineering Pty Ltd. JYD Object Database 1.3 Www.jyd.comMicro DataBase Systems, Inc. TITANIUM 8 Www.mdbs.com

http://www.cai.com/

http://www.gemstone.com/

http://www.ardent.com/

http://flowwworks.com/

http://www.ibex.ch/

http://www.intersys.com/

http://www.jyd.com/

http://www.mdbs.com/



Objectivity, Inc. Objectivity/DB 5.2 Www.objectivity.comOrient Technologies Orient Enterprise

Edition Orient Just Edition1.11.1

Http://orient.freeservers.com

The Ozone Database Project Ozone - Www.ozone-db.orgPOET Software Corporation POET Object Server Suite 6.1 Www.poet.comSysra Informatique EyeDB 2.5 Www.sysra.com/eyedb/TechKnowledge, Inc. TERSOL Object Database

TERSOL Persistent Library1.031.03

Www.t-know.com

Versant Corporation VERSANT 5.2 Www.versant.comBluestream StreamStore Www.bluestream.comA.D. Software OOFile Www.highway1.com.au/adsoftware/Answer Software MyBaseBasesoft Open Systems AB EasyDBMainstay PhylaNeoLogic Systems NeoAccess, NeoShare Www.neologic.comONTOS (formerly Ontologic) ONTOS VIA, DB, OISPersistent Data Systems IDB Object Database Www.persistent.comXcc Software Technology Transfer OBST+ Www.xcc-ka.de

Table 2-1 Available OODBMS on the market

During the work of gathering information of OODBMS, there were difficulties infinding new information about the O2 DBMS, a product that has been one of thedominating OODBMSs for several years. When attempts were made to getinformation from O2 support, the following statement were made by AndrewMenby of Ardent Software Inc.: "As you may have noticed from our web site, weare using O2 as the basis for exciting future products, but not as a widelydistributed, standalone ODBMS". O2, which were one of the first OODBMSs onthe 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 1994. This is the foundation of Table2-2 [Vah10] and Table 2-3 [Vah20]. Table 2-2 is an updated version made bystudents at the University of Mining and Metallurgy in Poland. They also createdTable 2-3.

PRODUCT CRITERION OBJECTIVITY(v.5.0)

OBJECTSTORE(v.5.0)

VERSANT(v.5.0)

Supports user defined data types YES YES YESSupports IS_A relationships YES YES YESSupports PART_OF Relationships YES YES YESSupport for multiple inheritance YES YES YESSupport for the concept of version YES YES YESChecks for the cardinality between objects YES YES YES1

Supports long transactions YES YES YESSupports replication of data YES YES YESSupports data encryption NO NO NODefinition languages for attributes of objects C++, JAVA, C, C++, JAVA, C, C++, JAVA,

http://www.objectivity.com/

http://orient.freeservers.com/

http://www.ozone-db.org/

http://www.poet.com/

http://www.t-know.com/

http://www.versant.com/

http://www.bluestream.com/

http://www.neologic.com/

http://www.persistent.com/

http://www.xcc-ka.de/



SMALLTALK, SQL SMALLTALK ,ACTIVE X

SMALLTALK

Stores the methods of objects in the DBNO, METHODS

ARE STORED INTHECLIENT

NO, METHODS ARESTORED IN THE

CLIENTYES

Methods of objects has to be defined in the language... C++, JAVA,SMALLTALK, SQL

C, C++, JAVA,SMALLTALK,

ACTIVE X

C, C++, JAVA,SMALLTALK

Application programming in C++ YES YES YESApplication programming in JAVA YES YES YESApplication programming in Smalltalk YES YES YESSTANDARDSSupports the Object Definition Language ODL YES1 NO NOSupports the Object Query Language OQL YES2 NO NOSupports ODMG C++ binding YES3 YES, v1.2 YES, v1.2Supports ODMG Smalltalk binding YES, v1.2 YES, v1.2 NOSupports the standard SQL in interactive mode YES NO YESSupports the standard SQL in embedded mode YES YES YES, via ODBCSupports a database language based on SQL YES YES YESQUERIESSupports ad-hoc queries with a GUI YES YES YESSupports ad-hoc queries with a 4GL YES YES YESSupports ad-hoc queries with a knowledge-orientedlanguage (e.g. Lisp) YES NO NO

Supports ad-hoc queries with a object-oriented language(e.g. C++)

YES, as long as thosetools support ODBC YES YES

Supports embedded queries with a 4GL YES YES YESSCHEMA MODIFICATIONSupports ad-hoc updates of the DB-schema with a GUI YES YES YESSupports ad-hoc updates of the DB-schema with a 4GL NO YES NOSupports ad-hoc updates of the DB-schema with aobject-oriented language YES YES YES

CASE-TOOLSDBMS is supported by an integrated object-orientedCASE-tool NO RATIONAL ROSE NO

DBMS is supported by a 3rd party object-orientedCASE-tool

YES, CLASSIFY/DBFROM MICRAM

YES,OBJECTMARKER,

MARK V,PARADIGM+

YES, OEW, OMTOOL,RATIONAL ROSE

DBMS is supported by a non-object-oriented CASE-tool NO NO NOACCESS TO OTHER DBMSAn application running on the OODBMS can read datawhich reside on other OODBMS YES YES YES

An application running on the OODBMS can modifydata which reside on other OODBMS YES YES YES

An application running on the OODBMS can read dataon the relational DBMS ORACLE YES YES YES

An application running on the OODBMS can read dataon other DBMS YES YES YES

ARCHITECTUREDBMS supports a single-user single-tasking environment YES YES YESDBMS supports a single-user multi-tasking environment YES YES4 YESDBMS supports a multi-user environment YES YES YES

DBMS is based on the client-server principle YES, but thin serverand fat client (queries

YES, but thin serverand fat client (queries

YES (queries may beexecuted either in the

http://www.odi.com/products/blueprint/blueprint.html



are executed in theclient)

are executed in theclient)

client, or in the server)

The physical data can reside on the client part YES, anywhere onthe network YES YES

The applications can run autonomously on the client part YES YES YESIntegration with CORBA environment YES YES YESData transfer (pages/objects) Pages Pages ObjectsObject execution on server Passive Passive PassiveTRANSACTIONS

DBMS supports nested transactionsNO, but it supports

concurrenttransactions

YES YES

DBMS supports MROW YES YES NO DATADBMS supports long transactions YES YES YESOPERATING SYSTEMSDBMS supports MS_Windows YES, WINDOWS

NT and 95/98YES, WINDOWS NT

and 95/98YES, WINDOWS NT

and 95/98DBMS supports SUN OS YES YES YESDBMS supports SUN SOLARIS YES YES YESDBMS supports AIX YES YES YESDBMS supports data distribution over several servers YES YES YES

DBMS supports other OS Most of UNIXsystems

HP-UX, IRIX,DIGITAL UNIX, NEC

UNIX, SiemensNixdorff UNIX

Most of UNIX systems

Table 2-2 Comparisons of three OODBMSs1 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 typingthat differs from SQL-92.3 All basis capabilities (ref, relationships, etc.), but not collections4 Supports multiple threads within a transaction rather than transaction-per-thread.

PRODUCT CRITERION POET v.5.0 GEMSTONE JASMINESupports user defined data types YES YES YESSupports IS_A relationships YES YES YESSupports PART_OF relationships YES YES YES

Supports multiple inheritance YES Smalltalk - NOJava - YES YES

Supports the concept of version NO YES NOChecks the cardinality between objects YES NO YESSupports long transactions YES NO NOSupports replication of data YES YES NOSupports data encryption NO YES NODefinition languages for attributes of objects C++, JAVA JAVA, Smalltalk C, C++, ODQL, JAVAStores the methods of objects in the DB NO YES YESMethods of objects has to be defined in the language... C++, JAVA JAVA, Smalltalk C, C++, ODQL, JAVASupports application programming in C++ YES YES YESSupports application programming in JAVA YES YES YESSupports application programming in Smalltalk NO YES NOSTANDARDSSupports the Object Definition Language ODL YES YES NO



Supports the Object Query Language OQL YES NO YESSupports 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 - YESJava - NO

YESVia ODBC

Supports the standard SQL in embedded mode YES Smalltalk - YESJava - NO

YESVia ODBC

Supports a database language based on SQL YES Smalltalk - YESJava - NO YES

QUERIESSupports ad-hoc queries with GUI YES YES YESSupports ad-hoc queries with 4GL NO NO NOSupports ad-hoc queries with object-oriented language(e.g. C++) YES YES, Java, Smalltalk YES

Supports embedded queries with a 4GL NO NO NOSCHEMA MODIFICATIONSupports ad-hoc updates of the DB-schema with a GUI YES YES YESSupports ad-hoc updates of the DB-schema with a 4GL NO NO NOSupports ad-hoc updates of the DB-schema with aknowledge-oriented language NO NO NO

Supports ad-hoc updates of the DB-schema with aobject-oriented language YES YES, JAVA, Smalltalk YES

CASE-TOOLS

DBMS is supported by an integratedobject-oriented CASE-tool

YESRATIONAL

ROSE,OEW

NO YES

DBMS is supported by a 3rd party object-orientedCASE-tool

YESSee above NO NO

DBMS is supported by a knowledge-orientedCASE-tool NO NO NO

ACCESS TO OTHER DBMSAn application running on the OODBMS can read datawhich reside on other OODBMS NO2 NO NO

An application running on the OODBMS can modifydata which reside on other OODBMS NO2 NO NO

An application running on the OODBMS can read dataon the relational DBMS ORACLE YES YES YES

An application running on the OODBMS canread data on other DBMS

YESDB2

MS-SQL

YESSybase

Informix

YES, OpenIngres,Sybase, Informix, MS-

SQL,CA-IDMS,

CA-Datacom,DB2,VSAM,RMS

ARCHITECTURESupports a single-user single-tasking environment YES NO YESSupports single-user multi-tasking environment YES YES YESSupports 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 YES3 NO NOIntegration with CORBA environment YES YES YESData transfer (pages/objects) OBJECTS4 PAGES OBJECTS

http://www.tdiinc.com/

http://www.poet.com/980210poetrose.com

http://www.poet.com/980210poetrose.com

http://www.protocols.nl/



Object execution on server NO YES YESTRANSACTIONSupports nested transactions YES NO NOSupports MROW YES YES NO DATASupports long transactions YES NO NOOPERATING SYSTEMSSupports MS-Windows YES, NT, 95 YES, NT YES, NTSupports OS/2 YES NO NOSupports SUN OS NO NO YES5

Supports SUN SOLARIS YES YES YESSupports AIX YES YES NOSupports data distribution over several severs YES YES YES

Supports other OS

YESHP-UX

Novell NetwareIntra Netware

SCO

YESHP-UX NO

Table 2-3 Comparisons of three OODMBSs1 Only at the "0, 1 or many" level.2 It can be accessed through generic API.3 However, the database must be on a filesystem that is accessible from the client.4 Allows transfer of object groups.5 Through C API and CODQLIE but not GUI

The tables needs to be updated, this job is very demanding and would take severalweeks to complete for one person. This is not possible but some conclusions canbe made about the presented material.

All products support the basic database and object-oriented features. All vendorsare all members of the ODMG de facto standard, described in chapter 3, but notall supports the standard completely.

Objectivity/DB is a strong contender that supports a large number of the selectedcriteria.



3. A Standard Object-Oriented Data Model IsEmerging

3.1 IntroductionThe OODBS Manifesto was published by a group of researchers in 1989 [Lar95],in order to produce a consensus on the requirements that an OODBS should meet.

These features include the following:

1. Complex objects. Basic objects can be combined into complex objects.

2. Object identity. Each data object must have a unique identifier.

3. Encapsulation. The data and the implementation of its operations are hiddenfrom users.

4. Classes. The common features of a set of objects with the same characteristicsare specified.

5. Inheritance. A subclass will inherit attributes and methods from its superclass.

6. Polymorphism. The implementation of the operation depends on the object towhich it is applied.

7. Computationally complete. Any computational function can be expressed inthe data-manipulation language.

8. Extensibility. New classes can be added to the system-supplied classes.

9. Data persistence. Data must remain available after the application that createdthem has terminated.

10. Very large databases. Store data on secondary storage in such way that largedatabases can be supported.

11. Concurrency. Multiple users can use the database at the same time.



12. Recovery. Recovery mechanisms enable the database to be restored in theevent of software or hardware failures.

13. Ad hoc queries. Users may specify requests in a high-level, applicationindependent form.

The Object Management Group (OMG) is an international industrial consortiumfounded in 1989 [Bur98] to address the issues of object standards. The group hasmore than 700 member organizations including virtually all platform vendors andmajor software vendors such as IBM, Sun, DEC, Microsoft, Apple, AT&T/NRC.The aim for the OMG is to develop de facto standards that will eventually beacceptable to ISO/ANSI. In 1990, the OMG published its Object ManagementArchitecture (OMA) Guide document. This guide specified a single terminologyfor object-oriented languages, systems, databases, and applications. Four areas ofstandardization were identified: the Object Model (OM), the Object RequestBroker (ORB), the Object Services, and Common Facilities.

3.2 The Object Database Management Group (ODMG)During the summer of 1991 were the ODMG (Object Database ManagementGroup) formed with several important vendors including GemStone Systems,Object Design, O2 Technology, Versant Object Technology, UniSQL, PoetSoftware and Objectivity. The participating ODBMS vendors represent over 80percent of the total marketplace. The ODMG has produced an object model thatspecifies a standard model for semantics of database objects. The modeldetermines the built-in semantics that OODBMS uses. The design of classlibraries and applications that use these semantics should be portable across thevarious OODBMSs that support the object model.

The major components of the ODMG architecture for an OODBMS are:• Object Model (OM).• Object Definition Language (ODL).• Object Query Language (OQL).• C++ language binding.• Smalltalk language binding.• Java language binding.



The initial version of the ODMG standard was released in 1993[Cat94] and inSeptember 1997 the ODMG 2.0 was released. The ODMG 2.0 has enhancementsthat included:• A new binding for Java programming language.• Fully revised version of the object mode, with a new metamodel supporting

object database semantics across many programming languages.• A standard external form for data and the data schema, allowing data

interchanges between databases.The latest version is the ODMG 3.0 [Cat00], which includes a number ofenhancements to the Java binding. It incorporates improvements to the objectmodel. It also includes various corrections and enhancements, including changesnecessary to broaden the standard for use by object-relational mapping systems aswell as for the original target of the standard, object DBMSs.

3.2.1 Object ModelODMG Object Model (ODMG/OM) [Cat00] is a superset of the OMG ObjectModel (OMG/OM).

The Object Model summarized:

• The basic modeling primitives are the object and the literal. Only objects havea unique identifier.

• Objects and literals can be categorized into types. All elements of a giventype have a common range of states and common behavior. A type is itself anobject.

• The state of an object is defined by the values it carries for a set of properties.These properties can be attributes of the object itself or relationships betweenthe object and one or more objects.

• The behavior of an object is defined by the set of operations that can beexecuted on or by the object.

• An ODMS stores objects, enabling them to be shared by multiple users andapplications. An ODMS is based on a schema that is defined in ODL andcontains instances of the types defined by its schema.



3.2.2 The Object Definition LanguageThe Object Definition Language (ODL) is a specification language for definingthe specifications of object types for ODMG-compliant systems. Its mainobjective is to provide portability of schemas between compliant systems whilehelping to establish interoperability between OODBMSs. ODL is not intended tobe a full programming language. DBMSs have traditionally provided facilitiesthat support data definition, using Data Definition Language (DDL), and datamanipulation, using Data Manipulation Language (DML). The DDL allows usersto define their data types and interfaces. DML allows programs to use instances ofthose datatypes by creating, deleting, reading, and changing them. The ODL isequivalent to the Data Definition Language of traditional DBMSs.

Several principles have guided the development of the ODL [Cat00], including:

• ODL should support all semantic constructs of the ODMG Object Model

• ODL should not be a full programming language, but rather a definitionlanguage for object specifications.

• ODL should be programming language independent.

• ODL should be compatible with the OMG's Interface Definition Language(IDL).

• ODL should be extensible, not only for future functionality, but also forphysical optimizations.

• ODL should be practical, proving value to application developers, while beingsupportable by the ODMG vendors within a relatively short time frame afterpublication of the specification.

3.2.3 The Object Query LanguageThe Object Query Language (OQL) provides declarative access to the objectdatabase using an SQL-like syntax. It does not provide explicit update operators,but leaves this to the operations defined on object types. OQL can be used asstandalone language and as a language embedded in other languages, for which anODMG binding is defined. The currently supported languages are Smalltalk, C++,



and Java. An OQL query is a function that delivers an object whose type may beinferred from the operator contributing to the query expression.

The design is based on the following principles and assumptions [Cat00]:

• OQL relies on the ODMG Object Model.

• OQL is very close to SQL-92. Extensions concern object-oriented notions likecomplex objects, object identity, path expression, polymorphism, operationinvocation, and late binding.

• OQL provides high-level primitives to deal with sets of objects but is notrestricted to this collection construct. It also provides primitives to deal withstructures, lists, and arrays and treats such constructs with the same efficiency.

• OQL is a functional language where operators can freely be composed, as longas the operands respect the type system. This is a consequence of the fact thatthe result of any query has a type that belongs to the ODMG type model andthus can be queried again.

• OQL is not computationally complete. It is a simple-to-use query language.

• Based on the same type system, OQL can be invoked from withinprogramming languages for which an ODMG binding is defined. Conversely,OQL can invoke operations programmed in these languages.

• OQL does not provide explicit update operators but invokes operationsdefined on objects for that purpose, and does not breach the semantics of anobject model.

• OQL provides declarative access to objects. Queries can be optimized byvirtue of this declarative nature.

• The formal semantics of OQL can easily be defined.



4. Objectivity

4.1 IntroductionObjectivity/DB is a distributed object database management system (ODBMS)developed by Objectivity Inc. located in Mountain View California [Obj96].Objectivity Inc. was founded as one of the startup companies of the secondgeneration of object database management systems in 1988. In 1990 they startedshipping their product Objectivity/DB. Objectivity/DB supports large number ofusers and provides high-performance access to large volumes of physicallydistributed data. It allows storage and management of objects through standardlanguage interfaces, including C++, Java, Smalltalk and SQL.

Objectivity customers include major corporations, such as BBN, Com21,Ericsson, Exxon, Fisher-Rosemount, Fuji Films, Motorola, NEC, Nortel,PageMart, Qualcomm, Siemens, Tokyo-Mitsubishi Bank and Toshiba InformationSystems.

4.2 Database Features

4.2.1 Object ModelObjectivity/DB in current version follows ODMG 2.0 [Obj96] data model withthe following exceptions:

• Static data members are allowed but cannot be made persistent.

• Inheritance is not allowed from more than one persistent class.

• Bit fields and unions cannot be made persistent.

4.2.2 Object IdentifiersAn OID in Objectivity/DB is 64 bits and contains information about the locationof the object. An OID is composed of four 16-bit fields in the format D-C-P-S(Database identifier, Container identifier, Logical page number, and Logical slotnumber on the page). Short OIDs are 32 bits long and identify an object relative ina container. Normally the OID is not visible to the application programmer. But



OIDs can be used directly to gain additional performance. It is also used byObjectivity to implement the associations to other objects.

4.2.3 Data ModelingEach Objectivity/DB federated database contains a schema that describes the datathat is stored persistently. A schema contains a type number for each persistent-capable class, along with shape information, which describes how persistentinstances of the class are to be laid out in storage. The type number in the schemais used to keep track of classes and associations between them. When evolving theschema, type numbers will change for the evolved classes and related classes typenumbers may also be changed, depending on the relationship.

The data model is defined using the Objectivity/C++ Data Definition Language(DDL). The data modeling process consists of creating DDL files, their syntax isvery similar to C++ header files syntax with some extension to expressbidirectional associations, propagation behavior and persistent links. In the DDLfiles objects which should be stored in the federated database schema areidentified. Objectivity/C++ defines persistence through inheritance. An object thatshall be made persistent inherits this behavior from a predefined base class.

Objectivity stores schema information in the federated database, the user can viewthe class descriptions using the ooToolMgr.

Objectivity provides a schema compiler called DDL. The DDL processor extractstype information from the DDL files and either creates or modifies a schema in afederated database. The DDL processor also generates C++ header files andimplementation files that are complied with a standard C or C++ compiler. Theautomatically generated source code includes methods and iterator classes for typesafe use of association of persistent classes.



DDL Processor

DDL Schema Code

C++ Compiler

Linker

SchemaSourceCode

Schema Header

Application Code

Schema

ObjectivityLibrary

ObjectivityFederated Database

ObjectivityApplication

Figure 4-1 Objectivity/C++ develompent process

Objectivity/DB allows the data model to be evolved through schema evolution.New classes can be added and existing classes can be updated, both their contentsand their inheritance. Objectivity/DB automatically converts existing objects thathave been changed by schema evolution. The timing of the conversion can bechosen to be made on-demand or immediate.

Objectivity/DB also supports class versioning, allowing multiple versions of aclass to coexist in the same data model. This makes it possible to maintain objects



of different class versions and access objects of different versions from the sameapplication, using the member functions defined for each class version.

4.2.4 Object Memory Management

4.2.4.1 ArchitectureObjectivity/DB is a fully distributed multiple client-multiple server system. Thearchitecture features Local Servers, Remote Servers and Lock Servers. The LocalServes is linked to the applications and provides access to the local disk. TheRemote Server provides access to disk on other nodes in the system and the LockServer manages concurrency among users. Caching is maintained in the LocalServer.

Objectivity/DB supports one-, two- as well as mixed tier design. One tier is thesimplest configuration, one single application on one machine. This design usesan Objectivity local database server that is linked with the application. In the two-tier configuration we also need a remote database server which enables access todata from remote machines. Mixed tier design are more complex configurations,which support multiple applications, linked with local servers. This design needs acentral lock server.



Network

ApplicationLocal Server

Remote Server

ApplicationLocal Server

Remote Server Remote Server

Lock Server

Figure 4-1 Distributed mixed-tier design

The Objectivity/DB Fault Tolerant Option supports data availability after networkfailures by distributing lock management and replicating the database schema andcatalog to multiple locations in the network. Database administrators can divide afederated database into autonomous partitions. Partitioning replicates metadata ineach partition so that each partition is self-sufficient and insulated from networkand other system failures. The Objectivity/DB Fault Tolerant Option istransparent to deployed applications.

The Objectivity/DB Data Replication Option improves data availability and readperformance by replicating a subset of data in multiple locations in the network.Replicating data can also eliminate the danger of a single point of failure to thedatabase. The Objectivity/DB Data Replication Option is transparent to deployedapplications.

Objectivity/DB uses page server architecture to provide optimal performance overa wide range of workloads. In the Page server approach the client performs mostof the database processing. The server is responsible for secondary storage and



providing pages at client requests. The architecture provides scalability andavailability with transparent distributed data across multiple machines, ondifferent workstations from multiple vendors, in a network. Multiple databaseservers can share the processing load for server operations and applications canlocate objects on any machine despite physical location whiteout any codechanges.

4.2.4.2 Logical StorageIn Objectivity/DB an object must be an instance of one of four storage classes:Basic object, container, database or federated database, as shown in Figure 4-1.

Federated database

Database

Schema

Container

Database

Container

Database

Container Container

Container

Figure 4-1 Objectivity/DB logic storage model

A basic object is the fundamental unit of storage in Objectivity/DB. Each basicobject is placed in a container.

A container is a collection of basic objects. Basic objects in a container arephysically clustered together in memory pages on disk. The size of a memorypage is defined when creating the federated database. When applications read



objects from the database, the whole memory page on which the requested objectis located is transferred into the application cache.

A database is a collection of containers. In a database there is always a defaultcontainer that is system created and there may be zero or more user-definedcontainers. The default container holds basic objects, which the programmer hasnot explicitly placed in a user-defined container. An application can open andmanipulate multiple databases, which maybe distributed on multiple networknodes. A database is maintained as a file in the host file system. Each databasebelongs to a single federated database.

A federated database logically contains user-defined databases and the schema,the data model, which describes all of the class definitions. The federated databasealso contains administrative information, like where Objectivity/DB files arephysically stored. Only one federated database may be opened at a time.

4.2.4.3 CachingAn object is brought intact directly from disk with the whole memory page it islocated on, the first time it is needed. The page is then stored in a cache inside theapplication process. Navigation between cached objects occurs in memory accesstime, this application-side caching of objects improves performance.

The cache size may be adjusted in page numbers, when the application is started.To use different caches and cache sizes, the application must create and usethreads.

When a cache is filled and more objects are opened, Objectivity/DB has to swapout a cached page. The algorithm used is Least Recently Used (LRU) to determinenext page swap. If an object in the swapped page is updated, marked dirty, thepage is written into the database. The updated data is not visible for otherapplication processes until the current transaction is committed, but when thecommit is made the swapped page does not need to be written into the database,this may increase performance.

Since there is no cache coherence in Objectivity/DB application caches cancontain dirty data, this occurs only in MROW mode. When not using MROW,data cannot be cached and used in multiple applications, Objectivity/DB preventsthis by not allowing shared data.



Objects may be manually pinned to the cache. Pinning indicates the object is inuse and prevents it from being swapped out from memory until the object is nolonger needed for the current transaction. Note that Objectivity/DB is onlypreserving the object and that the operating system can swap the cache to disk,because of the virtual memory management.

4.2.4.4 Accessing ObjectsObjectivity/DB provides an object reference called handles. A handle is atransparent object with information for access to multiple fields in objects. In C++the arrow operator (->) on the handle class is overloaded and is used to accesspersistent objects. Example:

ooHandle (Book) book; // A Book class handle

book.lookupObj(library, "Moby Dick"); // Set handle to reference// an Book object with// the name "Moby Dick"

book.open(oocUpdate); // Open object in update mode

book->setLoan(oocTrue); // setLoan is a method of the// Book class

Objectivity/DB uses two operators to invoke member functions from a handle, thearrow operator (->) or the dot operator (.). When accessing member functions of apersistent class, that the handle references, the arrow operator is used. Whenaccessing member functions defined on the handle itself the dot operator is used.

There are 5 methods to access objects in Objectivity/DB:

• Access by name through named objects.

• Access by key through keyed objects a kind of index.

• Access by persistent pointers.

• Access by handlers.

• Access by query.



4.2.5 Transaction Management

4.2.5.1 TransactionsTransactions allow a collection of operations to appear as a single atomicoperation to the database. When a transaction is applied to the database, thechanges are stored to disk.

Objectivity/DB allows one active transaction per process, and does not supportnested or overlapping transactions in current version.

During a transaction, checkpoints can be made. This stores changes to thedatabase, allowing other applications to access the changes. However, thetransaction remains active and all previously set locks are still held by theapplication. When making a checkpoint the transactions update locks can bedowngraded to read locks to improve concurrency, performance may be gained orlost depending on application program.

When a transaction are committed it cannot be undone. Transaction can beaborted any time until the commit occurs. When a transaction is aborted, it isrolled back to the last checkpoint or the beginning of the transaction and not savedto the database.

Transactions can be executed in Multiple Readers, One Writer (MROW) state.MROW operates on the transaction level and improves concurrency. MROWallows one process to update a container while other processes are reading itsoriginal contents. An MROW read operation would read the last committedversion of an object. If a process holds an update lock on an object, otherprocesses can read the object's state as it was at the time the update lock wasgranted.

For most applications, the overhead of performing open and close operations areoften completely masked by I/O costs of bringing the object into memory fromdisk. But, if the application is data intensive and accesses many objects, that all fitin memory, the cost of the open and close operations can be sometimessignificant. For these kinds of applications hot mode can be used for achievingperformance. Normally, an object is kept open if there are active handles thatrefer to it, and closed when its last active handle is deactivated. In hot mode theobject remains open after all handlers is deactivated, the object is closed at the lastpossible moment, just before removing the object's page from the cache. This can



give performance advantages if the application returns to an object that waspreviously opened. Hot mode affects the memory usage (48 bytes extra perobject), so depending on the application, an additional swap by the operatingsystem and the performance gain is lost.

4.2.5.2 LockingThe Objectivity/DB lock manager automatically obtains locks needed by theapplication by coordinating with the lock server. Objectivity/DB uses two-phaselocking to guarantees that all transactions leave the federated database in aconsistent state.

A process can obtain either a read lock, which allows other processes to read theobjects, or an update lock, which prevents all other processes from reading ormodifying the object. If an association to an object is changed the lock isautomatically upgraded to update mode. This behavior implies that applicationprogrammer does not have to care about locks. When a persistent object isopened, Objectivity/DB automatically determines what locks is necessary toensure data integrity and grants them to the requesting process, based on therequested access mode.

A process can obtain shared and exclusive locks that support propagation acrosscomposite objects. Shared locks can only be obtained if the process transactionsare in MROW mode.

Objectivity/DB also allows explicitly lock of persistent objects, this reserve accessto persistent objects in advance without bringing them into virtual memory.Explicit locks are held until the end of the transaction in which they wereobtained. If explicit locks are used, the programmer is responsible for leaving thedatabase in a consistent state, since two-phase locking is not used. Note thatexplicit locking is made on object level, meaning that each object needs to belocked separately from the application.

In case of a lock conflict Objectivity/DB can be configured to respond to thissituation in one of two ways:

• Immediately give up on the operation and return to the application with anerror condition.



• Wait for the resource that is locked. Wait for a period of time or wait foreveruntil the resource is unlocked. If the specified time is over, then give up on theoperation and return to the application with an error code.

The behavior of lock waiting can be specified at any time through a function call,for all transactions, or at the start transaction command, for the current transactiononly.

When infinitive lock waiting is requested, Objectivity/DB checks to see if therequest is queued and would result in a deadlock situation. If so, an error isreturned to the requesting application. When finite lock waiting is requested, nodeadlock checking is done. In this case, Objectivity/DB assumes that anydeadlock condition that occurs will be broken when lock waiting times out.

The whole locking mechanism may be turned off to improve performance in asituation where the application is guaranteed exclusive access. For mostapplications, the benefits (data integrity, concurrent access, and so on) of lockingfar outweigh the slight performance gain obtained by disabling locking.



5. S.P.I.D.E.R. Simulator

5.1 IntroductionIn the work of evaluating Objectivity/DB a simulator was created for testingusability and performance. The simulator is a simple model of how data isprocessed and stored in a S.P.I.D.E.R. system. The database and applicationdesigns were created to confirm if database performance is enough to run aS.P.I.D.E.R. system with efficient real time data access for the power systemmonitoring, analysis and control functions.

5.2 Database DesignA simple power station model shown in Figure 5-1. From the model the basicobjects for the database model is identified: TransmissionLines, Measurements,Switches, Busbars and Nodes.

2

3

1

4

5Switches

1234512345

1234512345

Measurements

TransmissionLine

Busbar A

Busbar B

12345

12345

Typical Busbar system 4 lines/transformers and 1 couplerTypical Station 3 Busbar systems

Figure 5-1 Simple power station model

Each station has 2 Busbars and 2 TransmissionLines. For each TransmissionLinethere are 6 Switches in each end, and with one coupler, each station has 6*5 = 30



Switches in total. A station has 10 Measurement points, one for each Busbar and 4for each TransmissionLine. There are 5 Nodes on each side of aTransmissionLine, and one node for each Busbar, the summary of Nodes in onestation is 22. The database model also includes a network, event lists, calculationdata and data for picture generation.

Objects in the Avanti database have a very large number of attributes, over 200.Having very large objects is not practical in an Objectivity/DB. To prevent thisthe objects must be built with a number of small objects.

There are two ways to build objects:

• Having small objects that points out each other

• Having a container-object that points out the small objects

Locking in Objectivity is made on container level in other words locking a basicobject also locks the container in which it is located. This can be a performancebottleneck when several applications access the database. To prevent this theobjects must be spread over several containers to achieve maximum performancesince locking can not be disabled in Objectivity/DB. The SPIDER system doesnot require locking, but to have a container for each object is impossible.

Considering the design issues described above a basic architecture can be createdas shown in Figure 5-2.

Container 2Container 1

Container Obj

Container Obj

Attribute 1

Attribute 1

Container M

Attribute N

Attribute N

Figure 5-2 Attribute design



The database design is made flexible so that new attribute classes can be addedwithout having to recompile the application code.

ApplContainerFactory

ApplContainer

InstallFactory

CreateApplCont

SetAttrib

GetAttrib

Factory

MeasurementFactory

Application

DAS WriteAppl

DAS ReadAppl

Figure 5-3 General database design

Database classes with attributes are simplified examples of those in the S.P.D.E.R.system. Each factory in the model creates a complete object with differentattribute-classes. In the simulator system there is an ApplicationContainerFactorywitch has methods for setting up the factory model and the database. AnApplContainer contains a list of OIDs to attribute objects; the factory objectcreates the ApplContainer.

ApplicationContainerFactory has a list of available factories in the system, whenthe database objects is installed, the ApplicationContainerFactory calls thefactories for ApplContainers that are created and put into the database. Eachfactory returns the ApplContainer OID and it is stored in theApplicationContainerFactory, when the database is accessed the applicationsretrieves the object address from this object.



A simple UML design was created for the database model, shown in Figure 5-4. Itcontains two virtual classes, the Factory and the Appl class. The factory class hasa virtually declared method for creating Appl objects. Each factory class builds anAppl object, which contains OIDs to the sub-objects of the object. The sub-objectscan be placed in different containers depending on the container setup. This is avery important parameter since Objectivity/DB is a page server. Objects in acontainer are clustered to memorypages and these are read into the applicationcache. The database performance depends on how the objects are stored incontainers and how they are accessed. To only have one container for all objects isvery inefficient, objects that are likely to be read after each other should be in thesame container for increased performance. By the optional container setup, thesystem performance can be tested with different setups and database behavior canbe reviewed.



DAS Readatt rib1 : ooBoo leanatt rib2 : ooBoo leanatt rib3 : ooBoo leanatt rib4 : ooBoo leanatt rib5 : char*att rib6 : int32att rib7 : int32att rib8 : f loat64att rib9 : f loat64att rib10 : f lo at64

DAS W riteat trib1 : ooBooleanat trib2 : ooBooleanat trib3 : ooBooleanat trib4 : ooBooleanat trib5 : char*at trib6 : int32at trib7 : int32at trib8 : float64at trib9 : float64at trib10 : float64

DNCNet Configdataatt rib Vector : ooVArrayobjectRef : ooVArray

DNCNet BusBranchat tribVector : ooVArray

SEMatrix Configdataob jec tRef : ooVArray

TTD Vectorat tribVector : ooVArray

Event Vectorattr ibVecto r : ooVArray

DNCStatusat trib1 : float64

SEMeasatt rib1 : o oBooleanatt rib2 : o oBooleanatt rib3 : int 32att rib4 : f loat64

NMBNet ConfigdataattribVector : ooVArray

NMBNet BusBranchatt ribVector : ooVArray

Node Factory

CreateApplObject ()

TTD Storage Factory

CreateApplObject()

Sw itch Factory

CreateApplObject ()

T ransmissionLine Factory

Creat eApplObjec t()

BusBar Factory

CreateApplObject()

Measurement Factory

CreateApp lObject()

Event Storage Factory

CreateApplObject()

Net wo rk Fac tory

CreateApplObject()

Appl

Factory

CreateAppObject()

ApplContainer

AddAppl()GetAppl()

0 ..*

1

0 ..*

1

Applicat ionContainerFactory

InstallFactory()CreateApplContainer()

0..*

1

0..*

1

0..*

1

0..*

1

Figure 5-4 Database design presented in UML

The decisions to not have the attributes concealed in objects were taken afterreviewing the time to create a general API towards the applications. A simplesolution is to use union, so that different datatypes can be used as in and outarguments to the methods, creating an API. Since there is no support for unions in



Objectivity/DB this behavior has to be implemented. However, this is not a mainpurpose of the assignment. So instead of putting in a lot of effort into animplementation of a general API, all attributes are declared as public.

5.2.1 System sizeThe systems size can be scaled from a default size. The default system size is 200power stations and that is approximately one tenth of a large S.P.I.D.E.R. system.The default system size is calculated from the power station model shown inFigure 5-1. When scaling the system it is the number of stations that is altered.

The Network, TTD Storage and Event Storage is not effected by the scaling inamount, since there is only one object each of these types in a system.

The system default size contains:

1 Network

1 TTD Storage

1 Event Storage

30*200 Stations = 6000 Switches

2*200 Stations = 400 BusBars

2*200 Stations = 400 TransmissionLines

22*200 Stations = 4400 Nodes

10*200 Stations = 2000 Measurements

5.2.2 Object Classes

5.2.2.1 NetworkThere is only one Network object in a simulator system, and it contains five sub-objects. The DNCNet Configdata contains the OIDs of all Node objects in thesimulator system and the SEMatrix Configdata contains the Measurement OIDs.The length of the arrays is determined by the system size, the calculated arraylength in the table below is for a default system size.



DNCNet Configdata 1 array with 6400 floats and 1 with 4400 OID:s

DNCNet BusBranch 1 array with 200 floats

NMBNet Configdata 1 array with 6400 floats and 1 with 4400 floats

NMBNet BusBranch 1 array with 200 floats

SEMatrix Configdata 1 array with 2000 OID:s

5.2.2.2 MeasurementThe measurement objects have three sub-objects.

DAS Read 4 boolean, 1 char string, 2 int, 3 floats

DAS Write 4 boolean, 1 char string, 2 int, 3 floats

SEMeas 2 boolean, 1 int , 1 float

5.2.2.3 Node

DNCStatus 1 float

5.2.2.4 Event StorageEvent Storage contains an event list. In an S.P.I.D.E.R. system the event list isdynamic, but in the simulator the event list is implemented as wraparound. Sincethere is no need to save old events and reviewing them. There is only one EventStorage object in a simulator system.

Event vector 1 array with 100 entries, each entry containing,one 200 char string, 2 int, 7 boolean



5.2.2.5 TTD StorageThere is only one TTD Storage object in a simulator system. The elements of thearray contain a struct of 4 floats.

TTD vector 1 array with 350 entries, each entry containing 4floats

5.2.2.6 TransmissionLine

DNCStatus 1 float

5.2.2.7 Switch

DAS Read 4 boolean, 1 char string, 2 int, 3 floats

DAS Write 4 boolean, 1 char string, 2 int, 3 floats

5.2.2.8 BusBar

DNCStatus 1 float

5.3 Application DesignThe applications in the S.P.I.D.E.R. system have an incoming data flow fromevents in the power stations. The data is processed, calculated and stored into thedatabase. The applications receive and send data through a message system buildon queues. Events occur and are send to the applications, where they are queued.In figure 4.8 a simplified application model is shown, it contains the basicapplications of a S.P.I.D.E.R. system.



DAS andE&A

processing

E&AStorage

Schematicdisplay

presentation

TTDStorage

DNC

NMB SE

High load data rates per second350 changed analogs100 limit violations & indication changes - 100 indication changes - 1 DNC determining - 1 topology determining per 10 minutes

DNC configuration6000 indications

NMB configuration6000 indications

SE configuration2000 analogsrun each 30 seconds

TTD configuration350 analogs/second

Network model2000 analogs (2+4*2)*Busses6000 indications (6*5)*Busses

Figure 5-1 Application data flow

The high load rates of data, shown in figure 5.1, have been calculated for onetenth of a large S.P.I.D.E.R. system. If the database size is scaled from its defaultsize, the high load rates must also be scaled. Which objects that should beaccessed are generally selected with a random operator. If all attributes of a typeare read, the objects are read sequentially.

In the initial specification of the simulator there should be a multi-process versionand a message system between the applications. When problems encountered withthe database products, these features were never implemented, but the simulatordesign provides support for such features.

The DAS and E&A Processing application accesses 450 Measurement objects persecond, the DAS Write attributes are read and updated. The random generatordetermines which objects that are read.



Read 450 objects times 20 attributes / second Write 450 objects times 10 attributes / second

DAS andE&A

processing

Measurement

DAS Read10 attributes

DAS Write10 attributes

2000 Measurement objects

Figure 5-2 DAS and E&A Processing High Load


E&A Storage

Measurement




Event Storage

Event Vector

1 Event Storage object

Figure 5-3 E&A Processing High Load




TTDStorage

Measurement



TTD Storage

TTD Vector

1 TTD Storage object

Figure 5-4 TDD Processing High Load

Write 200 attributes/second

Read 6400 + 4400 attributes / second

DNC

Network

DNCNetConfigdata

Node

DNCStatus

4400 Node objects1 Network object

DNCNetBusBranch

Write 10 objects times 1 attributes /second

Figure 5-5 DNC Processing High Load



NMB


Read 6400 + 4400 attributes / second

Network

NMBNetConfigdata

1 Network object

NMBNetBusBranch

Read / Write 200 attributes/ second

Figure 5-6 NMB high load

Write 2000 times 4 attributes

Network

1 Network object

SE


Measurement

SEMeas


SEMatrixConfigdata

Read 2000 attributes Write 2000 attributes

Figure 5-7 SE high load



6. Evaluation

6.1 Functionality

6.1.1 Common database features• Persistence

Objectivity/DB supports persistence through inheritance.

• Secondary storage

Database servers can be implemented as Advanced Multithreaded Servers (AMS)or as Network File Servers NFS. Objectivity/DB has mechanisms for indexing,clustering and caching. No query optimization mechanism is available, this is leftfor the application programmer.

• Concurrency control

Objectivity/DB supports locking mechanisms, deadlock detection and avoidstarvation with queues to critical resources.

Feature Description Flexible transaction model Supports transactions of any duration, including long transactions

through checkout/checkin feature.

Multiple readers, one writer Improves concurrency by allowing multiple readers to read the mostrecent state of an object that is locked for update by anothertransaction.

Object-level versioning Allows an application to selectively operate on specific versions ofobjects.

Hierarchical locking Two-phase hierarchical locking controls read and update accesses toobjects.

Lock waiting Allows transactions to wait for a user-defined period for access tolocked objects.

Active deadlock detection across databases Warns against potential deadlock situations.

Table 6-1 Objectivity/DB concurrency mechanisms

• Recovery facilities

Objectivity/DB recovers transactions automatically when an applications processis interrupted or crashes. Automatic recovery application and network failures



including: application failures, local and remote server failures, lockserver hostand process failures.

• Query facilities

Objectivity/SQL++ provides full support of ANSI SQL 1989 and entry level SQL1992, and includes partial support of intermediate level SQL 1992.

• Database administration, security and access control

Objectivity/DB has no database administration of users.

The applications cache size can be set in sizes of memory pages. There is nosupport for transaction optimizations. Objectivity/DB supports hash indexing ofcontainers.

There is no manual lock release in Objectivity/DB. If a lockserver is running andhas a lock on the federal database, it cannot be released. The lockserver must firstbe terminated. In a UNIX system this is not a problem since started processesfrom a user can be killed. In Windows NT this is cannot be done as user or asadministrator. The problem leads to that the system has to be rebooted. Thelockserver can be stopped from NT but this does not help, and of course usesObjectivity safety first here, if the lockserver is down and data still can beaccessed, the database can enter an inconsistent state.

6.1.2 Object-oriented features• Complex objects

Objects are created using the facilities of C and C++, Objectivity/DB also offersuni- and bi-directional associations between objects.

• Object identity

Objectivity/DB uses a 64 bits OID that contains information about the location ofthe object.

• Encapsulation



Attributes and methods are encapsulated through the class architecture of thedifferent program languages that has an Objectivity/DB binding.

• Classes and inheritance

Objectivity/DB supports class architecture and inheritance through the bindings toobject-oriented programming languages.

• Overriding, overloading and dynamic binding

Objectivity/DB supports overriding, overloading and dynamic binding through thebindings to object-oriented programming languages.

6.1.3 Realtime features• Determinism

Objectivity/DB has support for blocking processes for a specified period of time.If no answer is received during the period an error code is returned.

• Parallelism

In Objectivity/DB transactions are managed by a lockserver that grants or rejectsaccess to database objects.

• Event handling

Event Notification Services in Objectivity/DB support event handling.

Objectivity/DB is developed for UNIX and is ported to the tested NT version. Theproduct is row based, and thereby not integrated into the Windows environment.

6.1.4 User friendly

6.1.4.1 DocumentationObjectivity supplies documentation for delivered products.

In the documentation, is the fundamental rows of easy examples often left out,even if the source is only one row it is usually removed and replaced with acomment that says: Here the code should be, or here we set these variables. If you



want to know how these variables are set it is only shown once and is described intext, for example with handlers. Simple examples are an easy way to learn theproduct fast, by creating own simple examples and viewing the result. If thefundamental rows are not described in all chapters is acceptable but they shouldbe written out in the first chapters, were inexperienced users that struggles withtheir first programs try to find answers.

Some important material, that effects design and implementation, can only befound in the supplement book. For example the non-support for unions is notmentioned in "user manual".

6.1.4.2 SupportDuring the work Objectivity has provided free support through their Swedishdistributor Norsys Technology. Most of the support is managed through email, butalso through telephone. A short introduction was also given from Norsys duringinstallation of the product.

6.1.4.3 ToolsObjectivity/DB provides three browsing facilities:

• Type Browser

• Data Browser

• Query Browser

The oobrowser is an application program for viewing the database.



Table 6-1 Objectivity/DB Browser

When using oobrowse on large objects, there is a program needs to use a lot of thecomputers system resource, resulting in that the computer performance is thelimiting cause for using the oobrowse tool. When viewing large objects on acomputer that cannot provide the application with enough virtual memory andCPU power, the application will stall and has to be killed from the NT taskmanager, when doing this the locks in the lockserver is not released. Resulting indeadlocked lockserver.

The DDL-precompiler is not integrated into Visual Studio, so this has to be mademanually through the command prompt. Makefiles may be used. But no scriptsare provided by Objectivity, for example if the project contains a large number ofsource code files, it will take a long time to compile all source files. When updatesare made to some files only these needs to be recompiled. If there is no support forupdate check, the user has to make sure that all changed files get recompiled. Towrite scripts for this is not very demanding and could easily be supplied byObjectivity.



Since Objectivity is not integrated in Visual Studio, this can be a problem for newVisual Studio users. There are project settings that needs to be set in the right wayfor running Objectivity thorough Visual Studio, like compiler options etc. Nosoftware support for this is available from Objectivity, only samples of projects allready created, but if a new workspace and project are created new problems occur.

6.2 Performance

6.2.1 Test Cases with ObjectivityThe executing program is a basic read program from the simulator database. Thetest is to determine how much each operation costs in time. The tests wereperformed on 166Mhz computer with 114 MB internal memory. The databasesize was set to default. The code that was executed is shown in Table 6-1.

12

34.04.1

5

Meas = spiderH->GetMeas(rand()%(int)(2000*scale));Meas.open(oocRead);

DasWrite = oo_dynamic_cast<DASWrite>(meas->GetAppl(1));DasWrite.open(oocRead);DasWrite.open(oocUpdate);

ReadVar.attrib1 = dasWrite->attrib1;ReadVar.attrib2 = dasWrite->attrib2;ReadVar.attrib3 = dasWrite->attrib4;ReadVar.attrib4 = dasWrite->attrib4;ReadVar.attrib6 = dasWrite->attrib6;ReadVar.attrib7 = dasWrite->attrib7;ReadVar.attrib8 = dasWrite->attrib8;ReadVar.attrib9 = dasWrite->attrib9;ReadVar.attrib10 = dasWrite->attrib10;

Table 6-1 Program code

The program code was executed with different setups and time was measured sothat the cost of each operation could be calculated. Especially in memoryreferences. Table 6-2 shows the test results for each test:

Code Cache Total Time Iterations Time5 50 9.934 1000000 9.934E-6



5,4.0 50 8.362 1000000 8.362E-65,4.1 50 8.292 1000000 8.292E-65,4.0,3 50 112.332 1000000 1.12332E-45,4.0,3,2 50 116.358 1000000 1.16358E-45,4.0,3,2,1 50 226.176 1000000 2.26176E-4

Table 6-2 Execution times of different operations

As shown in Table 6-2 the execution time for the second and third tests are shorterthan the first test. This seems incorrect since more code has to be executed andtherefore the execution time would be longer. In the first test the object is openbut it is not made inside the loop, the rows 1, 2, 3, 4.0 is executed outside theloop, before the time measurement has started. Which means that the object isbrought from the database into the application cache for further use, the sameobject is then used during the loop and time measurement. Objectivity support hasnot been able to give an answer to why the execution time is shorter with greaternumber of operations.

6.2.2 Test Case with Objectivity cacheDuring the test the database size were set to default. The same code is executedseveral times but with different cache sizes, ranging from 10 to 500 pages. Theresults are displayed in Table 6-1.

Code Cache Total Time Iterations Time5,4.0,3,2,1 10 722.719 1000000 7.22719E-45,4.0,3,2,1 20 530.953 1000000 5.30953E-45,4.0,3,2,1 30 327.161 1000000 3.27161E-45,4.0,3,2,1 40 219.615 1000000 2.19615E-45,4.0,3,2,1 50 226.176 1000000 2.26176E-45,4.0,3,2,1 60 222.259 1000000 2.22259E-45,4.0,3,2,1 70 223.041 1000000 2.23041E-45,4.0,3,2,1 80 223.872 1000000 2.23871E-45,4.0,3,2,1 90 221.408 1000000 2.21408E-45,4.0,3,2,1 100 223.632 1000000 2.23632E-45,4.0,3,2,1 150 219.646 1000000 2.19646E-45,4.0,3,2,1 200 225.023 1000000 2.25023E-45,4.0,3,2,1 250 225.855 1000000 2.25855E-45,4.0,3,2,1 300 223.922 1000000 2.23922E-45,4.0,3,2,1 350 223.662 1000000 2.23662E-45,4.0,3,2,1 400 224.432 1000000 2.24432E-45,4.0,3,2,1 450 222.029 1000000 2.22029E-4



5,4.0,3,2,1 500 226.726 1000000 2.26726E-4

Table 6-1 Execution times with different cache sizes

The diagram in Figure 6-1 shows that a too small cache gives bad execution times.When reaching the point, were all data could be fitted into the cache the executiontimes stabilizes around 220 seconds. Since the execution times is so long the setuptime for a larger cache is masked.

Figure 6-1 Diagram over execution time with different caches

6.2.3 Test Cases with C++For comparing the results given in the test with Objectivity, fragments of thedatabase structure were created in C++. The tests were executed in the samemanner, with the same conditions and equipment.

Time to execute test loop with 1000000 iterations

0

100

200

300

400

500

600

700

800

0 100 200 300 400 500 600

Cache size

Tim

e

Series1



1.2.

3.

Meas = &spider[rand()%(int)(2000*scale)];DasRead = (TestDASRead *)meas->GetAppl(0);

ReadVar.attrib1 = dasRead->attrib1;ReadVar.attrib2 = dasRead->attrib2;ReadVar.attrib3 = dasRead->attrib4;ReadVar.attrib4 = dasRead->attrib4;ReadVar.attrib6 = dasRead->attrib6;ReadVar.attrib7 = dasRead->attrib7;ReadVar.attrib8 = dasRead->attrib8;ReadVar.attrib9 = dasRead->attrib9;ReadVar.attrib10 = dasRead->attrib10;

Table 6-1 Program code

The results from the tests are shown in Table 6-2.

Code Total Time Iterations TimeTest Meas Case 0 38.004 100000000 3.8004E-7Test Meas Case 1 157.287 100000000 1.57287E-6Test Meas Case 2 310.146 100000000 3.10146E-6

Table 6-2 Execution times for C++ classes

The result shows the in memory reference time for the used equipment. It is more20 times faster (~26) than with the Objectivity/DB application cache.



7. ConclusionObject-oriented approach models the real world more completely than a relationalapproach. Complex objects are inefficient to model in a RDBMS. Whenapplication behavior is separated from database behavior, mapping between therelational and the object world has to be made.

For simple data models there are no need to use an ODBMS, there is noperformance advantage, searching for requested data and optimizations of queriesare supported by the products.

RDBMS has a dominating position on the market, their products have maturedand contains all necessary tools. All major vendors use the SQL standard, whichincreases portability between different products. As long as no standard has beenchosen for object-oriented database systems, they have a great disadvantageagainst the relational databases.

ODBMS and RDBMS will coexist and hold different niches of the market, sincecommercial relational database systems have collected more than a decade ofbusiness experience, are well established and do much better cope with the simplestructured data they are designed for.

The thesis does not include a performance test for a relational database, time forthese tests were not given. An object-oriented design is well suited for theS.P.I.D.E.R. database architecture and Objectivity/DB is a strong contenderamong the leading ODBMSs.

The access pattern of a S.P.I.D.E.R. system is with a large number of shorttransactions. Objectivity/DB is more suited for long transactions. To useObjectivity/DB with the S.P.I.D.E.R. access pattern a commit device has to beimplemented, that gathers several short transactions before committing. This hasnot been implemented.

Objectivity/DB is best suited for distributed solutions. When usingObjectivity/DB as a S.P.I.D.E.R. database, it has lack of support of S.P.I.D.E.R.features. The most important missing feature is shared memory. The S.P.I.D.E.R.system uses a shared memory approach for retrieving a high performance system.With no shared memory each application has to have its own application cache,



since there is no cache coherence between Objectivity/DB application caches allupdates has to go through the database to be visible to other applications. Thisleads to very high rates of disk I/O, which results in very poor performance. Asperformance is the most important issue for the database in a S.P.I.D.E.R. system,Objectivity/DB is not very well suited for this task.

Objectivity/DB is well suited for a distributed and replicated environment. Forachieving the best performance of an Objectivity/DB the database design shouldbe adjusted to a distributed system. It is possible for a distributed system wouldoutperform a shared memory approach, since it can add more nodes. Sharedmemory approach has a supported architecture by the parallel databases and amultiprocessor system is probably the most suited solution for S.P.I.D.E.R.databases for example Oracle 8 has an object approach and supports paralleldatabase architecture.



8. References[Obj96] Objectivity Documentation

[Dar98] C.J. Date and Hugh Darwen, Foundation for Object/RelationalDatabases The Third Manifesto, ISBN 0-201-30978-5, 1998

[Bur98] Douglas K. Burleson, Inside the Database Object Model, ISBN 0-8493-1807-6, 1998

[Lar95] James A. Larson, Database Directions, ISBN 0-13-290867-0, 1995

[Con98] Thomas Connolly, Carolyn Begg and Anne Strachan, DatabaseSystems A Practical Approach to Design, Implementation, andManagement, ISBN 0-201-34287-1,1998

[Cat00] R.G.G. Cattell, Douglas Barry, The Object Data Standard: ODMG 3.0,ISBN 1-55860-647-5, 2000

[Cat94] R.G.G. Cattell, The Object Database Standard: ODMG –93, ISBN 1-55860-302-6, 1994

[Kue94] Peter Kueng, Comparison of ten ooDBMS, 1994

[Vah10] Http://galaxy.uci.agh.edu.pl/~vahe/products.html

[Vah20] Http://galaxy.uci.agh.edu.pl/~vahe/oodb3.html

[Dat98] White Paper Relationsdatabaser, Datateknik, 1998

Http://www.et.se/datateknik/whitepaper/WP_relationsdatabaser.pdf

Http://flowwworks.com

Http://icslab.agh.edu.pl/~jasper/oodb/

http://galaxy.uci.agh.edu.pl/~vahe/oodb3.html

http://galaxy.uci.agh.edu.pl/~vahe/oodb3.html

http://www.et.se/datateknik/whitepaper/WP_relationsdatabaser.pdf

http://flowwworks.com/

http://icslab.agh.edu.pl/~jasper/oodb/



Http://orient.freeservers.com

Www.ardent.com

Www.bluestream.com

Www.cai.com

Www.exceloncorp.com/objectstore/

Www.gemstone.com

Www.highway1.com.au/adsoftware/

Www.ibex.ch

Www.intersys.com

Www.jyd.com

Www.mdbs.com

Www.neologic.com

Www.objectivity.com

Www.odmg.org

Www.ozone-db.org

Www.persistent.com

Www.poet.com

Www.sysra.com/eyedb/

Www.t-know.com

Www.versant.com

http://orient.freeservers.com/

http://www.ardent.com/

http://www.bluestream.com/

http://www.cai.com/

http://www.gemstone.com/

http://www.ibex.ch/

http://www.intersys.com/

http://www.jyd.com/

http://www.mdbs.com/

http://www.neologic.com/

http://www.objectivity.com/

http://www.odmg.org/

http://www.ozone-db.org/

http://www.persistent.com/

http://www.poet.com/

http://www.t-know.com/

http://www.versant.com/

evaluation of an object database for use in s.p.i.d.e.r ... · evaluation of an object database for...

Documents