Object-Orientedness in Databases - Motivation and the State-of-the-Art

by Kazimierz Subieta (June 2006)

The field of object-oriented databases (object bases) has emerged as the convergence of several research and development threads, including new tendencies in object-oriented programming languages, software engineering, multimedia, distributed systems, Web, as well as the traditional relational database technologies. Actually, however, there is a high degree of confusion concerning what “object-oriented” means in general and “object-oriented database” in particular. For many people the term “object-oriented” is a commercial buzzword overloaded by a lot of meanings. Many professionals are trying to assign strong, technical criteria to this buzzword, trying to distinguish “object-oriented” systems from others.

What does make up object-orientation in databases? The most popular view is that the databases consist of objects rather than relations, tables or other data structures. The concept of “object” is a kind of idiom or metaphor addressing the human psychology and the way that humans perceive the real world, think and reason. James Martin wrote [Mart93]: “my cat is object-oriented”, as he observed that his cat distinguishes objects and predicts their behavior. This is of course a nice metaphor to make the evidence that millions years of the evolution have created in our minds mechanisms enabling us to isolate objects in our environment, to name them, and to assign to them some properties and behavior. The object-orientedness in computer technologies, from the psychological point of view, is founded on inborn mechanisms of our minds, just as the idea of a computer keyboard is based on the anatomic fact that humans have hands and fingers.

Why is object-orientedness important for computer technologies? For many years the professionals have observed the growing complexity of software and software manufacturing methods. At the same time the software becomes more and more responsible for vital branches of the society life. Fighting with the complexity has became the major task of software engineering. The complexity of software has became the main factor disturbing the development of more and more sophisticated features that are challenged in the human civilization processes.

Coping with the software complexity requires a systematic approach. It is commonly believed that complexity can be reduced by the following basic software engineering principles:

Higher abstraction level of software design and manufacturing, isolating the application programmers and users from physical details of data and service access, data independence, i.e. the design and management of data independently from application programs.
Decomposition of the software processes and software itself into a hierarchy of isolated pieces that share well defined interfaces only.
Reuse and standardization. Reusable software parts can be considered as encapsulated units that can be used in many places without the necessity of understanding their complex interior. Standardization is the basis for software development culture allowing for easier communication between various groups of developers and for physical connection of software units that are manufactured independently.
Following natural human psychology and mentality. The psychology and mentality include a lot of factors that increase or decrease the software development potential, such as perception of the real world in terms of objects and their behavior, natural tendency to err and to act improperly, limited capacity of human memories, following previously acquired habits and customs, etc.

Object-oriented tools, languages, methodologies and systems in many ways contribute to the above principles. Object and class encapsulation supports the refinement of abstraction levels, thus allow the designer and programmer to reason on the high abstraction level and then subsequently refine details. Object-orientedness supports decomposing a project and corresponding software into small conceptual units, in particular, objects and classes. Inheritance and polymorphism are the main factors of the reuse of previously developed artifacts. The object-oriented paradigm follows the natural human psychology, thus reduces the distance between the human perception of the problem (business) domain, an abstract conceptual model of the problem domain (expressed, e.g., as a class diagram), and the programmer’s view of data structures and operations. Minimizing the distance between the three views of designers’ and programmers’ thinking (referred to as “conceptual modeling”) is considered the major factor reducing the complexity of the analysis, design, construction and maintenance of the software. This is illustrated in Fig.44.

Fig.44. Object-oriented databases minimize the distance between the human perception of real objects and objects understood as data structures

Object-oriented models offer notions that enable the analyst and designer to map the business problem to the abstract conceptual schema better. These notions include: complex objects, classes, inheritance, typing, methods associated to classes, encapsulation and polymorphism. There are several semi-formal notations and methodologies (notably Unified Modeling Notation, UML) that make it possible to map efficiently a business problem onto an object-oriented conceptual model. On the other hand, object database systems offer similar notions from the side of data structures, hence the mapping between the conceptual model and data structures is much simpler than in the case of the traditional relational systems.

Object database systems combine classical capabilities of relational database management systems (RDBMS) with new functionalities assumed by the object-orientedness. The traditional capabilities include:

Secondary storage management,
Schema management,
Concurrency control,
Transaction management, recovery,
Query processing,
Access authorization and control, safety, security,

New capabilities of object databases include:

Complex objects, perhaps with no limitations on the hierarchy levels of attributes and sub-attributes,
Object identities,
User-defined types,
Encapsulation and abstraction through information hiding,
Type/class hierarchy with inheritance; strong type checking of queries and programs acting on a database,
Associations among objects implemented as pointer links,
Overloading, overriding, late binding, polymorphism,
Computational and pragmatic completeness of programmers’ interfaces.

The wave of pure object-oriented DBMS, which abandons assumptions of the relational database model, started in 1983, when D.Maier and G.Copeland presented a database management system with the data model of Smalltalk. From that time many research prototypes and commercial systems have been developed, among them Gemstone, ObjectStore, Versant, O2, Objectivity/DB, Poet, Loqis, ODRA, and others.

This shift of the database paradigms has caused a hot debate between advocates of relational systems, having already a strong position on the market, and proponents of pure object-oriented database management systems (OODBMS). To some extent, this debate was the continuation of the old debate (early 70-ties) between the camp of DBTG CODASYL systems based on the network model and proponents of the relational database model. At that time the relational model eventually won, but some of its promises have never been accomplished. The Codd’s 12 rules of relational systems have notoriously been violated by vendors of commercial systems, which have attached the buzzword “relational” to offered database products, sometimes with little technical justification. Nevertheless, despite a lot of trade-offs and commercial confusion, the relational model has been successful as the conceptual and technical basis of many commercial relational systems. This especially concerns SQL-based systems.

The current paradigm of researchers and vendors from the relational world is conservative, if one concerns the root idea of relational systems, but innovative concerning particular capabilities that were built into new versions of relational systems. These include the support for multimedia, Web, temporal and spatial data, data warehouses and others. The extensions concern also some features of object-orientedness, although in this respect the development is modest.

Unfortunately, the relational model and the object model are fundamentally different, and integrating the two is not straightforward. Current object-relational databases are commonly perceived as eclectic and decadent, with a lot of ad-hoc, random solutions, with no unified conceptual basis. As suggested by David Maier in his famous interview, novel object-oriented features of object-relational systems are rarely or never used. Standards within object-relational databases (notably SQL-99), although rich with a lot of technical details, are considered loose recommendations rather than strong technical specifications. Relational databases can be considered as a particular case of object-oriented databases (with no classes and with objects reduced to tuples), hence the term "object-relational database" remains poorly defined or denotes almost everything that has happened in the domain. The adjective "relational" within the term "object-relational database" looses its original meaning and has nothing in common with its mathematical roots. Object-relational databases are not supported by any reasonable mathematical theory and there are no serious attempts to develop it.

Actually it is difficult to discuss which idea will be the winner and if there can ever be a winner. Few people realize that relational databases store still ca. 12% of the total data stored in all databases. There is a lot of information stored in files or in proprietary databases that are not along any theoretical or ideological lines. Hence, there is enough room for the coexistence of many ideas, including relational, object-relational, object-oriented and XML-oriented models..

Overview of Object-Oriented Concepts

Object-oriented database models adopt the concepts of object-oriented programming languages. Actually, there is no agreement concerning their precise definition. The definitions presented below are typical.

Complex objects, object identity. The database should consist of objects having arbitrary complexity and an arbitrary number of hierarchy levels. Objects can be aggregates of (sub-) objects. Each database object has identity, i.e. a unique internal identifier (OID) generated automatically (usually, with no meaning in the problem domain). Each object has one or more external names that can be used to identify the object by the programmer.
Collections of objects. Objects having the same general properties and the same format can be grupped within collections. Collections can be processed by iterators in the one-object-at-the-time mode, or by query languages in the many-objects-at-the-time mode. Collections can be nested, i.e. an object being a member of a collection can have sub-objects or attributes being collections too.
Relationships, associations, links. Objects are connected by conceptual links. For instance, the Employee and Department objects can be connected by a link worksFor. In the data structure links are implemented as logical pointers (bi-directional or uni-directional).
Encapsulation and information hiding. The internal properties of an object are subdivided into two parts: public (visible from the outside) and private (invisible from the outside). The user of an object can refer to public properties only. Private properties can be used only by methods associated with an object.
Classes, types, interfaces. Each object is an instance of one or more classes. A class has a twofold meaning: as a blueprint for objects (i.e. objects are instantiated according to information presented in the class) and as a container storing invariant properties of objects (for instance, their type, their name, the methods that can be applied to them, etc.). Each object is assigned a type, which is used for checking of the object's structure and for strong type checking of queries or programs that use the object. Objects are accessible through their interfaces, which specify all the information that is necessary for using objects by application programmers. Abstract data types (ADTs) are essentially classes, which assume that an object state is not directly visible and any access to an object is limited to the predefined collection of operations.
Operations, methods and messages. An object is associated with a set of operations (called methods). The object performs the operation after receiving a message with the name of operation to be performed (and parameters of this operation). Messages are essentially method calls similar to procedure calls.
Inheritance. Classes are organized in a hierarchy reflecting the hierarchy of real world concepts. For instance, the class Person is a superclass of the classes Employee and Student. Properties of more abstract classes are inherited by more specific classes. Multi-inheritance means that a specific class inherits from several independent classes. Inheritance can be subdivided into static (seen from the program source code) and dynamic (not seen in the code, available during run-time only). The most important case of dynamic inheritance concerns dynamic object roles.
Polymorphism, late binding, overriding. The operation to be executed on an object is chosen dynamically, after the object receives the message with the operation name. The same message sent to different objects can invoke different operations.
Persistence. Database objects are persistent, i.e., they live as long as necessary. They can outlive programs, which created these objects.
Database schema and metamodel. A database schema is necessary for the programmer of object-oriented database applications for understanding what the database contains and how the objects within the database are organized. A metamodel is internal structural representation of the database schema. It is mainly used by system programmers of the corresponding DBMS, but can also be used by application programmers for developing generic applications based on reflection.

Technical details assumed by designers in particular models, languages and products make concepts with the same name (class, type, ADT, etc.) technically and practically very different. Lack of commonly accepted definitions concerning the object model is considered a weakness of object-orientation in databases. The standardization effort made by the Object Data Management Group (ODMG) explained and unified many topics, leaving however a lot them unexplained or making them even more obscure (e.g. a metamodel).

Manifestos

The history of database manifestos started in mid 80-ties, when E.F.Codd, the father of the relational model, published 12 rules of a true relational system. According to them, up to now, no commercial RDBMS has been "truly relational". Current post-relational concepts are going even farther and farther from the "ideals". Fortunately for the relational systems and newer concepts, the "ideals" are idealistic, unrealistic, Utopian.

The essential role in the development of object DBMS was fulfilled by "The Object-Oriented Database System Manifesto" by Atkinson et al, 1989. One strong argument used by the relational camp was that there was no reasonable definition of the object-database concept ("you guys don’t even know what you’re talking about", object-orientation presents "silly exercises in surface syntax"). The object database manifesto has determined basic rules of object database systems, which abandon the relational model. The characteristics of an object DBMS were separated into three groups:

Mandatory: complex objects, object identity, encapsulation, types or classes, inheritance, overriding combined with late binding, extensibility, computational completeness, persistence, secondary storage management, concurrency, recovery and ad hoc query facilities.
Optional: multiple inheritance, type checking and inferring, distribution, design transactions and versions.
Open (to decide by designers): the programming paradigm, the representation system, the type system and uniformity.

The object database manifesto was unacceptable for the conservative wing of the relational camp. The competitive "The Third Generation Database Systems Manifesto" by Stonebraker et al, 1990, postulates retaining all practically proven features of relational database systems (notably SQL, as an “intergalactic dataspeak”) and augmenting them modestly by new features, among them with some object-oriented concepts. The manifesto is a random extract of primary and quite secondary database features, expressed by a bit demagogic rhetoric. In particular, the tenet that SQL is to be "intergalactic dataspeak" concerns future SQL that will address much extended data model. Hence the manifesto postulates to retain something what does not exist yet, and this is simply a nonsense.

"The Third Manifesto" by Darwen and Date, 1995, postulates to reject both object-orientedness and SQL (which - according to the authors - wasted the ideals of the relational model), and to return to the bosom of the pure relational model and 12 Codd's rules. The document is very controversial, at least from the position of current trends of software engineering and query/programming languages. The presented arguments are more ideological ("we know better, you should follow us") than technical and as such are very hard to accept by the wide community of database professionals. There is newest version of the manifesto, 2006, unfortunately, still retaining purely ideological assertions.

The ODMG Standard

Object Data Management Group (ODMG) was founded by a group of startup companies who thought that traditional standard-making processes by official standardization bodies were too slow and cumbersome. They got their first publication (ODMG-93) out very quickly, with a big messages that everything that is necessary for defining object-oriented database management systems is already done: stop think, start implement. They also set expectations far too high, by announcing that all the members were committed to delivering conforming implementations by the end of 1994. Few professionals believed them, but of course, it was part of the game. Till now, there is no evidence that the standard is fully implemented by the ODMG members or by any other organization. The last version of the standard appeared in 2000, then the ODMG announced the big success of the standard and disbanded.

Unfortunately, the standard is no success and some professionals consider it as a dead end that has impeded the progress in object-oriented databases rather than supported it; c.f. the Suad Alagic paper "The ODMG Object Model: Does it Make Sense?", 1997. The standard is far from being complete (especially concerning the semantics and functionality of defined languages) and contains a lot of bugs and inconsistencies, sometimes fundamental ones, undermining consistent implementation. Hence the common opinion that the standard is too early, immature, underspecified (especially concerning the semantics of data model features and OQL) and incomplete. Some professionals consider it also obsolete, in view of new XML and RDF-oriented technologies. The standard presents also some inconsequences or conceptual redundancies concerning the use of OQL and object querying and manipulation interfaces defined directly as C++ (rough) specifications or Java interfaces (presented as syntactic constructs only). The standard misses essential features of current database systems, such as (updateable) views, stored (server side) procedures, functions and classes, triggers, integrity constraints, recursive queries, distributed databases, etc. From our side the biggest disadvantages of the ODMG standard is the underspecified and unnecessarily complex object model and essentially no idea how to cope with the semantics of a query language. Lack of precise formal semantics makes it impossible to develop strong type checkers and query optimizers. These drawbacks were the big motivation for the research into SBA and SBQL.

On the other hand, we must realize that the task undertaken by ODMG was obviously difficult. Although probably the standard will not fulfill all expectations, it already plays an important role of integrating research and development efforts devoted to object bases. The standard has become a pivot and a relative point of many discussions and comparisons concerning object-oriented databases. Currently, many projects both in industry and academia are going along the lines that were determined by the standard. Even if these projects take a critical position on the standard, it becomes a departure point for various improvements and extensions. For this reason the standard should be considered as a very important milestone for development of future object bases, providing we realize what are its disadvantages.

The ODMG standard (version ODMG 3.0) consists of the following parts:

Object Model. It determines the meaning of basic concepts of object-oriented data structures, such as: objects, attributes, relationships, collections, classes, interfaces, operations, inheritance, encapsulation, and others. It is intended to be independent of any programming language as far as possible. The object model assumes strong typing and orthogonal combination of type constructors. It defines also collections, such as sets, bags, sequences, arrays and dictionaries, and other concepts.
Object Definition Language (ODL). Both the object model and ODL are extensions of the corresponding parts of the OMG CORBA standard. ODL is an extension of CORBA IDL. ODL is used to determine the structure of a database, i.e., a database schema. The schema is necessary to understand what the database contains and how is organized. An ODL schema determines collections of objects, relationships between objects, object attributes, operations that can be applied to the objects, exceptions that can be caused by these operations. ODL is neutral to programming languages (though follows the C++-like syntax).
Object Interchange Format. It determines the representation of objects for exchanging them between different OODBMS.
Object Query Language (OQL). The language is claimed to be a compatible extension of the SQL standard, but actually OQL retains some syntactic patterns of SQL only. Semantically, OQL is very different from SQL, mainly because it follows the ODMG object model, which is incompatible with the relational model. OQL is intended to retrieve data from an object base. It does not deal with updating and does not define SQL-like abstractions such views, constraints and stored procedures. OQL is more orthogonal than SQL, although much less orthogonal than SBQL.
Bindings to programming languages C++, Smaltalk and Java. The bindings determine principles of including ODL and OQL statements as constructs of the mentioned above programming languages. Besides, the bindings define many classes (written in the syntax of a particular programming language), allowing to access and process an object base directly from an application written in one of the mentioned languages. Till now, however, the bindings present a lot of limitations and inconveniences. The major disadvantage of them is loose coupling of OQL with a programming language, which leads to the infamous effect referred to as "impedance mismatch".
Metamodel, presenting some view on organization of internal system catalogs, in the spirit of the OMG CORBA Interface Repository. This part is specified intuitively and informally, a lot of terms remain undefined. The part proposes a totally bad (non-implementable) solution, as shown in PhD by Piotr Habela.

The OMG set up the new Object Database Technology Working Group (ODBT WG) and acquired the rights to develop new OMG specifications for object-oriented databases. Although it is announced that the new standard proposal will be based on the ODMG works, it is our hope that ODBT WG will inherit all advantages of the ODMG standard and will abandon or improve all its bad, controversial, redundant or non-implementable features. In our opinion, it will be impossible without learning our experience with the Stack-Based Approach (SBA) and the Stack-Based Query Language (SBQL).

Pure Object-Oriented DBMS

Pure OODBMS products provide traditional database functionality (e.g. persistence, distribution, integrity, concurrency and recovery), but are based on the object model. They typically provide permanent, immutable object identifiers to guarantee integrity. Pure OODBMS also generally provide transparent distributed database capabilities (e.g. transparent object migration, distributed transactions), and other advanced DBMS functionality (e.g. support for Web, support for workgroups, administrative tools). In comparison to their relational peers, OODBMS are well suited for handling complex, highly interrelated data, particularly in cross-platform and distributed environment. There are also some benchmarks showing that performance of pure OODBMS is much better than RDBMS. This is due to the new techniques, such as new caching methods, pointer swizzling, navigation via pointer links instead of performing joins of relations, shifting processing on the client side, and others.

There are however several perceived doubts concerning OODBMS that are listed below:

Maturity of the technology. Many organizations currently use OODBMS for niche applications and not for their mission-critical applications because of a perceived lack of reliable features. The risk connected with this technology is still perceived as too high.
Stability of the vendors. OODBMS vendors tend to be small companies. Decision makers are not sufficiently convinced that a particular OODBMS product will be available in the future.
Availability of qualified personnel. There is a lack of personnel skilled in the object-oriented paradigm in general and OODBMS in particular.
Cost of conversion. In addition to the obvious costs of new software, OODBMS have some difficult leveraging the investment already made in RDBMS.

Despite disadvantages, the market forecast for OODBMS (in total) is optimistic. The great success of object-orientedness on the ground of programming languages (C++, Java), analysis and design tools (UML), interoperability middlewares (CORBA) and the general tendency in software illustrated in Fig.44 creates a hope that sooner or later object-oriented databases eventually conquer the market. New hopes are also created by the OMG initiative concerning developing a new 4-th generation standard for object-oriented databases.

Object-Relational DBMS

Object-relational DBMS (ORDBMS) are based on the idea that the relational model and SQL-92 implemented in the majority of RDBMS should be extended. There are actually many ways to extend the relational model, however, the one chosen by object-relational database vendors is very relation-centric. A database still consists of a set of tables. A number of object features are provided as an extension to this core relational model (multi-row tables, references between rows, inheritance between tables, etc.).

At this time, there is no standard for the object-relational model and each vendor has own object extensions. The differences between Oracle-10, Informix Dynamic Server, UniSQL, IBM DB2 and other object-relational products are significant. They exclude portability and even a common conceptual and didactic basis. Various products present the choice of quite random, redundant, limited and sometimes inconsistent features. There is a new ANSI/ISO standard SQL-99, which is supposed to unify the systems. There are doubts whether the standard will really play an essential part in the development due the size and complexity, a lot of redundant features comming from various schools of the IT business and a lot of historical (obsolete) stereotypes that influenced the construction of the standard. Essentially, the standard does not specify semantics or specifies it very imprecisely. Moreover, the object features are just a minimal part of the standard.

Object-relational companies have demonstrated that this new technology can be implemented and that they are ahead in terms of technology. The relational vendors have financial power, the ownership of the already existing software development base, and a position as well as big authority on the market. They rely on the trust of their former customers. The pure motivation is the commercial profit rather than conceptual clarity or software engineering principles. The products are criticized as huge, complex, eclectic, thus decadent. David Maier claims that essentially nobody is using new object-oriented extensions of relational DBMS.

The key products of this technology include: Informix Dynamic Server, Postgres, Illustra, IBM’s DB2 Universal Database, Oracle-8/9/10, OSMOS, Ingres II, Sybase Adaptive Server, and others. Almost every relational vendor has announced or promised object-relational products. With except of some new systems (Postgress, Montage, Informix DS), the systems are extensions of their relational predecessors. They are equipped with facilities for efficient application development. These are: support for multimedia and Web, spatial data, ADT-s, methods defined by the programmer, collection-valued attributes, and others.

Many professionals consider ORDBMS as a temporary result of the evolution from the relational to the pure object-oriented technology. The current market, however, hardly accepts new database ideas and languages, thus it may happen that this evolution will take tens of years. Actually, it is very hard to predict where this evolution will come.

XML and RDF-oriented DBMS

Formerly, XML was promoted as "better HTML" which will be able to bear structurally the semantic information on Web resources. The information can be thus recognized and utilized by some automatic software tools. Then XML files were recognized as a way to exchange information among different software agents. In particular, XML files can be a component of data exchange protocols or as a units that parameterize and tune some software systems according to wishes of programmers or users. Recently, however, XML is also perceived as a database meta-format that makes it possible to store and to make available huge amount of information.

There is some confusion between XML considered as textual files and XML being stored within specialized XML-oriented systems, such as Tamino or Berkley/DB. XML files have little meaning as a way of massive data storage because of performance problems and lack of many features such as transactions and security support. Parsed XML that is stored in specially prepared databases have their origin in the source XML files, but essentially they are stored as hierarchical data structures that are 1:1 isomorphic with the structures of corresponding XML files. Such data structures can be maintained and processed as objects in an object-oriented database. Essentially, parsed XML data structures form an object-oriented database allowing data structures more complex than relational ones, but much less complex than fully-fledged object-oriented databases. Such an XML-oriented database system does not support many features of object-orientedness, in particular, pointer links among objects, classes and methods, inheritance, encapsulation, polymorphism, etc.

Despite big commercial buzz around, XML-oriented databases present essentially no new quality. It is difficult to imagine why the users have to restrict data structures that they observe in their business domain to pure hierarchies of objects, not supported by advanced object-oriented database notions. Looking on Fig.44, for some database applications limitation of data structures implied by XML will not be justified from the point of view of the conceptual model of the problem domain. Moreover, XML-oriented query/programming interfaces, such as XQuery, are not sufficiently mature yet and even below the state-of-the-art in comparison to SQL.

Similar remarks concern RDF (Resource Description Framework), which initially was promoted as a metaformat for description of business ontologies. Currently some professionals are trying to promote it as a universal database format. The model of RDF is fact-oriented rather than object-oriented (where "facts" are coded as triples <subject, feature, value>). Within this approach even boundaries of objects are unknown and must be deduced by programmers from some informal description. Many object-oriented features, such as classes with behavior, inheritance among classes, etc. are outside of considerations. RDF Schema facilities are much conceptually different from traditional database schemas. Query languages for RDF, such as RDQL, are below the state-of-the-art. Abstraction build in query languages, such as functions and views, are in the infant stage. We are also not optimistic concerning the support of RDF by mathematical theories, in particular, by formal logic. In our opinion, this will not work in practice (as it is already shown by the entire Datalog school). However, currently it is rather difficult to predict how this idea will evolve and what will be the gains from it.

Java and C# -oriented DBMS

In comparison to XML and RDF, Java and C# object models are much more close to some ideal database object-oriented model, but do not share all the necessary features that we have mentioned before. This concerns:

· Collections, which in Java and C# are secondary rather than primary features. In particular, nested collections have no counterparts.

· Associations implemented as pointer links are unavailable;

· More advanced forms of inheritance (multiple inheritance, multiple-aspect inheritance, dynamic inheritance) are unavailable;

· Persistence is not an inborn feature of these languages. Essentially, Java and C# persistence is based on relational databases and SQL rather then on truly object-oriented databases.

· Database schema and metamodel are not considered in these languages as features independent from particular applications acting on a database;

· Query languages that are embedded or integrated with these languages (Hibernate, LINQ) are rather limited and referring (in the deep semantics) to relational rather than to object-oriented databases. LINQ assumes straightforward mapping between C# objects and relational tables; thus SQL as a back end. This assumption involves a lot of limitations concerning data structures and the query language features. Fully-fledged object-oriented query languages such as SBQL are difficult to integrate with Java of C# programming environments, at least according to our implementation experience (ICONS, YAOD, ODRA and J-ODRA).

· Database abstractions such as views, triggers, etc.

These limitations can be considered secondary if one considers small non-critical applications. Limitations are obviously fundamental for very large databases with a critical mission, thus exclude the Java and C# persistency layers as true OODBMS.

Last modified: June 29, 2006