Object Database Systems

Kazimierz Subieta

Institute of Computer Science, Polish Academy of Sciences, Warszawa, Poland

Polish-Japanese Institute of Computer Techniques, Warszawa, Poland

subieta@ipipan.waw.pl

 

Abstract

In the last decade major changes have occurred in the database domain, as the result of increased interest to non-traditional database applications such as multimedia, office automation, CAD, CASE, GIS, Web databases, and others. In contrast to the relational era, the current database world is more diverse and showing contradictory tendencies. On the one hand, vendors of popular relational database management systems (DBMS), such as IBM, Informix and Oracle, extend their products with new capabilities, including support for non-traditional data types (text, graphics, sound, video, spatial data, etc.) and for object-oriented concepts, such as ADT-s, classes and inheritance. The products are called "object-relational". On the other hand, there is a competitive revolutionary wave, called "pure object-oriented DBMS", which includes products such as GemStone, ObjectStore, Versant, O2, Objectivity/DB, Poet, and others. Substantial effort is devoted to database standards. The emerging SQL3 standard has roots in the relational model, but includes many object-oriented extensions. Independently, the Object Data Management Group (ODMG) proposes a standard based on a pure object model. A lot of research and development from the industry and academia is devoted to various aspects of object-relational and object-oriented DBMS. The presentation is a short overview of these directions and tendencies.

1.     Introduction

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 base" in particular. For many people the term "object-oriented" is a kind of a commercial buzzword with a lot of meanings. Many professionals are trying to assign strong, technical criteria to this buzzword, allowing us to distinguish the "object-oriented" systems from others.

What makes up object-orientation in databases? There are several views. 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 that addresses the human psychology and the way humans perceive the real world and think. James Martin wrote [Mart93]: "my cat is object-oriented", as he observed that his cat distinguishes objects and predicts their behaviour. This is of course a nice metaphor to make 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 behaviour. Object-orientedness in computer technologies, from the psychological point of view, is founded on inborn mechanisms of our minds, 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 pointed out the negative syndrom that is referred to as "software crisis". The software crisis can be described as the growing cost of software production and maintenance, the problem with "legacy" (obsolete) software, very big risk of unsuccessful projects, immature methods of software design and construction, lack of reliability, various frustrations of software designers and producers, and so on. Together with these negative factors and dangers, there is a growing responsibility of the software, its critical role in a mission of many organizations.

The main factor causing the software crisis is the complexity of software and the complexity of methods of software manufacturing. It depends on four worlds influencing the world of software, Fig.1.

Fig.1. Factors of the software complexity

The worlds presented in Fig.1 are under the influence of uncertainty concerning the future, which itself presents a big factor amplifying the complexity.

The object-orientedness, which follows the natural human psychology, is considered as a new hope to reduce the complexity; in consequence, to reduce the software crisis. This is supposed to be achieved by reducing 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, Fig.2. Minimizing the distance between these 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.

Fig.2. Three views in the conceptual modeling of software

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 (e.g., OMT, UML, OPEN) 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 the classical capabilities of relational database management systems (RDBMS), with new functionalities assumed by the object-orientedness. The traditional capabilities include:

New capabilities of object databases include:

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, and others.

This shift of the database paradigms 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 model. At that time the relational model eventually won, but some of its promises have never been accomplished. 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 this development can be described as "modestly evolutionary" rather than "revolutionary".

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 conceptual basis. This vision is of course negated by vendors of these systems, who invented the buzzword "universal server" as the stereotype of "doing everything both with relations and objects, and more".

One aspect of the debate between advocates of pure object-oriented DBMS and object-relational DBMS is worth attention. Despite the fact that differences between, e.g., IBM's DB/2 Universal Database, and e.g., Informix Dynamic Server are fundamental, there is no religious war between IBM and Informix. The war unites vendors of RDBMS and ORDBMS against the proponents of the pure object model and pure OODBMS. This is the sign showing where the vendors see the real danger for the commercial position of relational DBMS and their successors.

Actually, however, 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. Hence, there is enough room for the coexistence of both ideas.

The rest of the paper presents the key topics related to object-oriented databases that are currently discussed in the database world.

1.     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 most typical [Loom95].

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.

1.     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 commercial concepts are going even farther and farther from the ideal.

The essential role in the development of object DBMS was fulfilled by "The Object-Oriented Database System Manifesto" by Atkinson et al [Atki89]. 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:

The object database manifesto was unacceptable for the conservative wing of the relational camp. The competitive "The Third Generation Database Systems Manifesto" [Ston90] by Stonebraker et al 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.

"The Third Manifesto" by Darwen and Date [Darw95] 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 rules. The document presents some naivety of the (quite famous) authors. The presented arguments are very difficult to accept by the wide community of database professionals.

1.     Architecture of Object-Oriented DBMS

There are several concepts of the OODBMS architecture. The most abstract is the ANSI/SPARC architecture, which assumes three layers: the external user layer, the layer of a conceptual schema, and the layer of physical data. Another architecture is client/server, where database applications are subdivided into two parts: the database server (executing e.g. SQL statements sent by clients) and one or more clients sending requests to the server. More advanced are the three-tier architecture and multi-tier architecture, where layers (tiers) of a user interface and a database are separated by one (or more) layers devoted to business logic.

Fig.3. The architecture of OODBMS

From the functional point of view, a typical OODBMS architecture is presented in Fig. 3. It shows dependencies between basic functional components of a system.

2.     ODMG Standard

Object Data Management Group (ODMG) was founded by a group of startup companies who thought that traditional standard-making processes were slow and cumbersome and that they could do better. They got their first publication (ODMG-93) out very quickly, then discovered that making real standards is actually very hard work. 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 (except O2) the standard is fully implemented by other ODMG members.

There are also doubts what it means to be "compliant" with the standard, as the compliance criteria remain undefined. For instance, ObjectStore has a query language claimed to be "compliant" to ODMG OQL, but even the syntax of these languages is different. Moreover, the standard still presents a moving target, as currently three versions are released and a next version is announced. The standard is far to be complete (especially concerning the semantics and functionality of defined languages) and contains many bugs and inconsistencies. This suggests that the standard is too early and immature, but probably, from the point of view of the commercial competition, this is another part of the game.

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. 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 comparisons, improvements and extensions. For this reason the standard is considered very important for future object bases.

The ODMG standard (version ODMG 2.0 [ODMG97]) consists of the following parts:

The current version of the ODMG standard has many drawbacks, caused probably by the "committee syndrome" (the camel/horse case) and not sufficient understanding of a lot of issues that are covered by the document. This caused some critique of the standard [Rupp99] (even by those professionals, who generally support the object-orientation in databases). Nevertheless the interest to the standard from wide academic and industrial communities creates a big hope that further standard releases will be much improved.

1.     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, shifting processing on the client side, and others.

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

Despite disadvantages, the market forecast for OODBMS (in total) is optimistic. The Barry & Associates Consulting Company presents the following data:

 

1995

$ 115 000 000

1996

$ 165 000 000

1997

$ 241 000 000

1998

$ 387 000 000

1999

$ 720 000 000

2000

$ 1 607 000 000

Table 1. Major OODBMS commercial players

The above data could be obsolete, as almost each month the market configuration is changing.

1.     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-8, Informix Dynamic Server, UniSQL, 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 an emerging ANSI/ISO standard SQL3, which is supposed to unify the systems, however, there are doubts whether the standard will really play an essential part in the development (see the next section). 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.

The key products of this technology include: Informix Dynamic Server (formerly Postgres, Illustra and Informix Universal Server), IBM's DB2 Universal Database, Oracle-8, UniSQL/X, OSMOS, Ingres II, Sybase Adaptive Server, and others. Every relational vendor has announced or promised object-relational products. With except of some new systems (Postgress, Montage, Informix DS, UniSQL), 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.

2.     SQL3

SQL3 is a new SQL standard developed by ANSI and ISO [ANSI94, Mano95]. In contrast to its predecessors (SQL-86, SQL-89, SQL-92) SQL3 is assumed to be a programming language with full computational and pragmatic power. The main data structure the language deals with is the table, equipped however with a lot of options (thus using the term "relation" to denote this structure makes very little sense). SQL3 supports user-defined abstract data types (ADTs), including methods, object identifiers, subtypes, inheritance and polymorphism. Some enhancements are introduced to statements defining tables, in particular, types of rows, row identifiers, and (specific) inheritance between rows of families of tables. Further facilities include control statements and parameterized types. Together with an extremely rich collection of various features, SQL3 is downward compatible with SQL-92 and follows the (too sweet and non-orthogonal) select...from...where... syntax.

Each SQL3 table has a predefined column named IDENTITY containing row identifiers. These identifiers can be used as values in other rows. Thus SQL3 makes it possible to create pointer-based, network data structures a la DBTG CODASYL. This presents a dramatic violation of the relational model rules. Of course, this is not an argument against SQL3 (actually nobody cares about the rules), but shows that SQL3 follows a very eclectic idea.

The ADT concept in SQL3 enables the user to associate values stored in the tables with methods. In such a case these values are not directly accessible, but exclusively by methods. Methods can be written in SQL3 or other languages, in particular in C++ and Java. The user can also declare derived (virtual) attributes of a table, i.e. functional methods. For each declared table a "sub-table" can be declared. A sub-table contains all the attributes of its parent table plus some new attributes. On the other hand, the projection of a sub-table on attributes of its parent table results in some subset of the parent table.

SQL3 introduces a lot of extensions to previous SQL versions, including e.g. enriched support for BLOBs, CLOBs, collections, triggers, transactions, cursor processing, etc. It includes also new features such as support for user-defined aggregate operations, transitive closures, and even deductive rules. Unfortunately, these extensions are done with little care about minimality, non-redundancy and clean separation between primary (built-in), secondary (add-on, library) and external features. Thus cleaning up the inconsistency between various language features takes a lot of time. Actually, the standard is late with respect to the initial schedule. The first release is expected in mid 1999, although this term is not sure. Some people claim that the standard will be ready not earlier than in 2002.

There is a lot of controversy around the SQL3 standard. First, the standard is extremely huge, currently ca. 1100 - 1600 pages (sources report different figures). It is sometimes emphasized that in the history of software no language having specification longer than 1000 pages has ever been implemented. If different companies implement different subsets of SQL3, then the standardization effect will be wasted. Hence, they will ask for a "core" subset of SQL3, i.e. a new standard. Second, a controversy is caused by the fact, that research and development concerning a new programming language is carried on in the standardization office, which status does not provide this kind of activity and which has incompatible competence. Third, some people doubt if the standardization office (financed from public sources) can spend a lot of money on support of private ORDBMS vendors (SQL3 addresses their products) rather than other technological options (pure OODBMS, in particular).

3.     Query languages

The commercial success of the relational model and relational database systems to a big extent has been amplified by the idea of query languages. Initially, query languages addressed a non-experienced user, who needed a simple mean for making ad hoc reports from the database and for performing simple updating operations. SQL, the most representative language from the family, has various other applications, in particular, as a programming interface to a relational database (so-called embedded SQL), as language for defining various database abstractions (views, stored procedures, constraints, active rules, and others). Unfortunately, in this role SQL is not sufficiently powerful, hence it must be coupled with some universal programming language, e.g. C, PL/I or Pascal. This has led to clumsy programmers' options, which collectively have been referred to as "impedance mismatch".

Query languages should have the following properties:

Query languages are the main catalyst of various formal methods addressing databases, in particular, the relational algebra, the relational calculus, formal methods based on the predicate calculus, and others.

The advent of pure OODBMS caused a lot of confusion concerning query languages. Some relational purists have claimed that query languages are an inherent property of relational databases and it is impossible to define them for object bases. It has been shown that this is a nonsense, but still some advocates of ORDBMS repeat this "argument". Some other people from the relational camp have claimed that it is impossible to build a consistent theory for object query languages. This is another nonsense, but again, notoriously repeated by some ORDBMS fans.

However, some part of the critique of object-oriented query languages is unfortunately true. We note the following circumstances connected with the critique:

Some new idea in this respect is presented by a research line, which postulates building an integrated query and programming language. This research is carried on by the author of this paper [Subi95, Subi97] and some other authors.

1.     Persistent Polymorphic DBPL-s

In the shadow of the commercial competition between the camps of pure OODBMS and ORDBMS there is a camp of so-called database programming languages (DBPLs) [Atki95]. DBPL is a regular programming language that introduces a programming abstraction called "persistent variable" (or "persistent object"). A persistent variable has all properties of a programming variable, but it retains its value after the program that used it is terminated. A next run of the program takes the value of this variable from the previous run. In other words, a persistent variable is a variable stored in a database. A database can be considered a collection of persistent variables.

This research and development paradigm started in the camp of programming languages. The first language of this kind was Pascal/R, then a lot of other languages were developed, among them Amber, Galileo, Fibonacci, PS-Algol, Napier-88, OPAL, DBPL, Tycoon, Machiavelli, MUMPS and recently PJama (formerly Persistent Java and PJava). They are developed mainly at universities (although PJama is developed by Sun, and there are some startup companies, such as Higher Order Inc., which develops and uses Tycoon). The languages are based on the following tenets:

Till now, the concept of persistent polymorphic DBPLs is not popular in the commercial world. There are several reasons, among the fact that very few people and companies are ready to accept a new programming language. Although this development is technically and intelectually much more advanced than competitors (including SQL3, the ODMG standard, and other industrial concepts) there is unfortunately a psychological barrier for wide popularity of these languages. People don't want to realize that database programming is a very professional job, which requires a very professional approach. There is a lot of illusion that the job can be accomplished by very simple tools. Thus, the development is focused on e.g. a bottom-up extension of the "select...from...where..." construct, combined with a lot of additional (but in fact secondary) options. Unfortunately, this point of view results in language monsters, such as SQL3, or in weakly defined artifacts, such as the ODMG standard.

A bit of optimism is caused by the fact that some ideas of persistent polymorphic DBPLs are slowly influencing the commercial world. This concerns, e.g. strong typing. Other ideas, such as the minimality of languages' options, full orthogonality of independent features, clear separation between primary (built-in) and secondary options, the common naming-scoping-binding mechanisms for both querying and programming, etc. are still waiting for their position in the commercial development.

1.     Summary and Conclusion

Among the variety of topics related to object database systems we presented here just a few, which we consider the most crucial for the understanding where the domain is going to. Other topics include: databases in the CORBA standard, Web databases, processing semi-structured data, design of object database applications, integration of object-oriented query and programming languages, active rules, transaction processing, physical organization, mapping between object and relational databases, distributed databases, and many others. There are also many topics related to application of object databases, such as data warehouses, multimedia, CAD, CASE, GIS, mobile agents, workflows, groupware, and others.

Object databases have already a position on the market, which is permanently growing. Despite a lot of commercial confusion and despite the object-relational rivals, object databases are already successfully applied in various practical areas. Although the current market segment of pure object databases is not bigger than 5%, there are many symptoms showing that this situation is changing. First, this ratio is permanently growing (some claim that up to 50% per year). Second, the object-relational world is adopting more and more object-oriented concepts thus probably in some time we can expect the convergence of both ideas.

The relational model has already lost its position as a scientific and technical authority in the database domain, thus there has been an intellectual gap, which is currently filled in by object-oriented concepts. This paradigm shift sooner or later will push the relational model to the intellectual "underground" (as it has already happened with the hierarchical and network database models), i.e. people will stop to consider the relational model as a development paradigm. The pure object database model, a probable intellectual winner (which authority is amplified by thousands of universities and other development institutions) has big chances to be a commercial winner.

2.     References

The material presented in this paper comes from hundreds of publications and thousands of Web pages. Below we present some small excerpt of relevant publications only.

[ANSI94] American National Standards Institute (ANSI) Database Committee (X3H2). Database Language SQL3. J.Melton, Editor. August 1994

[Atki89] M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier, S. Zdonik. The Object-Oriented Database System Manifesto. Proc. of Intl. Conf. on Deductive and Object Oriented Databases, pp.40-57, 1989

[Atki95] M. Atkinson, R. Morrison. Orthogonally Persistent Object Systems. The VLDB Journal, 4(3), 1995, pp.319-401

[Bana98] L. Banachowski. Bazy Danych - Tworzenie aplikacji. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1998 (in Polish)

[Banc92] F. Bancilhon, C. Delobel, P. Kanellakis. Building an Object-Oriented Database System, The Story of O2. Morgan Kaufmann 1992

[Darw95] H. Darwen, C.J. Date. The Third Manifesto. SIGMOD Record, 24(1), 1995, pp.39-49

[Figu96] D. Figura. Obiektowe bazy danych. Akademicka Oficyna Wydawnicza, Warszawa 1996 (in Polish)

[Kim90] W. Kim. Introduction to Object-Oriented Databases. The MIT Press, Cambridge, Massachusetts, 1990.

[Loom95] M.E.S. Loomis. Object Databases: The Essentials. Addison Wesley, 1995

[Mano95] F. Manola (ed.). X3H7 Object Model Features Matrix. GTE Laboratories Report X3H7-93-007-v10, 1995

[Mart93] J. Martin. Principles of Object-Oriented Analysis and Design. Prentice hall, 1993

[ODMG97] The Object Database Standard ODMG, Release 2.0. R.G.G. Cattel, Ed., Morgan Kaufman, 1997.

[Rupp99] S. Rupp. A Critique of Release 2.0 of ODMG-93 Standard. http://gameboy.gia.rwth-aachen.de/odmgbugs

[Simo95] A.R. Simon. Strategic Database Technology: Management for the Year 2000. Morgan Kaufmann 1995

[Ston90] M. Stonebraker, L.A. Rowe, B. Lindsay, J. Gray, M. Carey, M. Brodie, P. Bernstein, D. Beech. Third-Generation Data Base System Manifesto. ACM SIGMOD Record 19(3), pp.31-44, 1990

[Subi95] K. Subieta, Y. Kambayashi, J. Leszczyłowski. Procedures in Object-Oriented Query Languages. Proc. of 21-st VLDB Conf., Zurich, 1995, pp.182-193

[Subi97] K. Subieta. Object-Oriented Standards: Can ODMG OQL be Extended to a Programming Language? Proc. CODAS '96 Conf., World Scientific 1997

[Subi98] K. Subieta. Obiektowość w projektowaniu i bazach danych. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1998 (in Polish)

[Subi99] K. Subieta. Słownik terminów z zakresu obiektowości. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1999 (in Polish)