A
Critique of Object Algebras[1]
Kazimierz Subieta, Jacek
Leszczy³owski
Institute of Computer Science Polish Acad. Sci., Warszawa, Poland
{subieta,jacek}@ipipan.waw.pl
Abstract So-called "object
algebras" are meant to be straightforward extensions of the relational
algebra. They are attempts to repeat its success for object-oriented models. In
this paper we carry out critical analysis of this research activity. We
indicate severe flaws of object algebras, subdividing them into conceptual,
mathematical and pragmatic. We argue that these flaws cannot be easily removed,
and for this reason we doubt the potential of object algebras, in the proposed
forms, as formal and intellectual tools for the development of object-oriented
databases and their query optimizers.
1. Introduction
Object
algebras are proposed as tools to formalize object-oriented databases and their
query languages (QLs), see [AlAr93, BMG93, CDV88, Clue89, ClDe92, ClDe94,
DGG94, GZC89, HFLP89, KeMa94, LMSVVZ93, PoSm94, ShZd89a, ShZd89b, ShZd90, StOz90,
SZLV93, SLVZ95, VaDe91] and many others. They are claimed to be well-suited for
query optimization. In this paper we carry out a critical analysis of this
research activity. There are two principal reasons motivating our work. First,
we see in these "algebras" severe flaws, which cause doubts
concerning their scientific and practical meaning. The second reason concerns
frequent misunderstanding of a role of the stack-based approach with respect to
object-oriented, integrated query/programming languages (QLs/PLs)
[SBMS93,SBMS94,SKL95a,SKL95b], which is a new paradigm based on a formal
operational model and an alternative to object algebras and other formal
approaches. There is a popular stereotype opinion that any approach is
inadequate with respect to query optimization unless it includes an associated
"algebra" allowing to rewrite queries to
semantically equivalent forms. We disagree with it and present counter
arguments in this paper.
Object-oriented
models and their QLs are much more complex than the relational ones, thus the
formalization must meet difficulties. There are three sources of the problems.
The first one is the same as in the case of relational systems: database
users/programmers expect much more powerful QLs than "relationally
complete". The second source is the complexity and variety of data
structures introduced in object-oriented models, as well as various features of
object-oriented databases, such as object identity, encapsulation, inheritance,
overriding. The third source concerns the necessity to integrate QLs with
programming features, such as macroscopic imperative statements, views,
procedures, active rules, methods, ADTs, classes, modules, strong typing
systems. Each of these sources of difficulties considered alone must cause
serious doubts if the formalization style of object algebras is adequate. This
is especially evident for people familiar with the denotational semantics of
PLs. Proponents of object algebras tend to neglect this knowledge.
Doubts
concerning object algebras are also (implicitly) expressed in [YuOs91],
however, with liberal attitude to fundamental flaws (such as lack of formal
semantics), as well as with some illusions concerning their potential (e.g.
capturing updating operations or invocation of methods). We are far from
illusions and see no hope for improvements. In this paper we indicate serious
reasons to question any potential of all object algebras that we have
found in the literature, in the proposed forms, as formal and intellectual
tools for the development of object-oriented databases.
In
the following we present in detail our arguments concerning conceptual (Section
2), mathematical (Section 3), and pragmatic (Section 4) flaws of object
algebras. Section 5 concludes.
2. Conceptual Flaws of Object Algebras
Due
to the nature of objects (having a state) the reality to be dealt with while
considering object-oriented systems is much more complex than for the
value-based (relational, functional) ones. Developers of object algebras
simplify their task in many ways, and this is why the main conceptual problems
with object algebras are caused by restrictions of their scope and
universality.
Nowadays
script-based languages (such as SQL) have little meaning as interactive
languages. This role is much better fulfilled by form-, menu- and graph-oriented
languages. On the other hand QLs absorbed many PLs' notions, in particular,
imperative statements acting on database states (creating, updating, inserting,
deleting), processing through cursors (essentially pointer variables), views
(essentially functional procedures), various program control statements,
database procedures, ADTs, library functions and procedures, etc. SQL has
essentially the meaning as a high-level programming facility for professional
programmers and database administrators [Ston88]. In consequence it is evolving
in the direction of universal PLs (see SQL3 [ANSI94]).
Looking
at object algebras as those to support such languages we argue they must lead
to severe conceptual problems if one will intend to capture formally the semantics
of the following language phenomena:
In
[SKL95b] we present more desired features of integrated QL/PL languages, which
are implemented (or - sooner or later - will be implemented) in modern
languages. In view of them an unacceptable feature of object algebras is their
implicit limitations to a very particular and usually over-simplified model of
data structures and QL functionalities, with little care to many vital semantic
aspects.
3. Mathematical Flaws of
Object Algebras
The
papers on object algebras are written in an informal or half-formal way. They
seem to appeal to reader's mathematical knowledge and imagination, but it turns
out that the reason for that is not the form of presentations but lack of
precision and well-foundedness of the constructions. Thus the proposals present
some informal systems, although they use a lot of mathematics. It is likely
that the authors purposely extend the meaning of the term "algebra"
to informal languages (perhaps, useful); this is almost explicitly suggested,
for example, in [BMG93]. Such a non-standard use of this term, however, one may
perceive as abuse of the authority of mathematics: the "scientific
decoration" of immature ideas.
If
there is no trust in the mathematical correctness or even in formality of such an "algebra" then there cannot be trust in
theorems that stem from it. (Incidentally, usually there are no theorems.) The
proponents of object algebras tend to neglect problems, which are against their
wishes. In this section we address the problems explicitly and point out that
they are not solved. Some of them could not be solved even within possibly
extended framework.
3.1. Basics
Before
presenting our arguments we would like to establish basic notions. (Precise
definitions can be found, e.g., in [Cohn81,MaBi79]). An
algebra is a pair <E,O>, consisting of a
set E of elements (which are neither functions nor operators) and a set O
of operators over E. Each operator o Î O is a (partial) function mapping
element(s) of E into an element of E. The set of operators may be
infinite, and the set E may be subdivided into subsets (sorts) in order
to to express domains of the operations more precisely, extending the notion to
a sorted algebra.
This
simple notion of algebra is usually considered together with a language. We
need a language to express elements of E and O while forming
algebraic expressions. A symbol representing an element of E or O
is a different entity than the element itself. For example, a symbol 2 is
simply a character; the symbol's denotation is the number two, which is an
abstract mathematical entity. Another case is the symbol EMP which
represents a relation - an abstract mathematical being. The language of terms
built from such symbols and from variables is called an object language of the
algebra.
Beside
these notions we have to involve yet another language, called meta-language. The
meta-language is just the language of scientific papers, where we want to speak
not only about a concrete algebra or a concrete object language, but about a
wide class of algebras and their object languages. The meta-language is based
on the informal agreement among people (developed through centuries) and
intuitive understanding of some symbols and phrases of a natural language.
Parts
of the meta-language are sometimes formalized, as in the case of algebraic
specification languages. These are formal languages of first-order formulas
built on top of the (object) language of terms. The formulas would be atomic
(involving predicate symbols such as =, <, etc.), and can be compound with
the use of quantifiers and/or by means of logical connectives. There are
attempts of shifting the border between the object and meta-language by
treating predicates as operators with an additional Boolean sort added to the
algebra.
Analyzing
concrete proposals of object algebras we tried to establish clearly what are elements and operators they deal with, what is an object
language of this algebra, and which notions belong to its meta-language. Different
proposals have different qualities in this respect, thus our remarks could not
be equally relevant to all of them. In this short paper we are unable to
criticize every proposal in detail. We have chosen the paper [LMSVVZ93],
written by the team of authors well-known in the field, as the most
representative for this research activity.
3.2. Looking for Definitions
Any
algebra cannot be considered defined if the set E (possibly segmented by
sorts) is undefined. Looking at [LMSVVZ93] our first question is the following:
what are mathematical elements the algebra operates on? We expected they are
not atomic, hence some definition of their structure
is required. We met sentences that the algebra is closed under
"objects" and that "everything is an object". Then there is
a statement about an object's state as a "mapping from AQUA objects to
mathematical values" - but still we do not know which ones. Then, there
are considerations about object types, type hierarchy and mutable/immutable values, also there is the syntax of algebraic expressions
and "definitions" of operators. We reached the end of the paper not
being informed what are the elements the algebra deals with!
Obviously,
if the set E of the algebra is undefined, it is impossible to give
correct definitions of operators.
3.3. Quantifiers
In
mathematics quantifiers are non-algebraic operators. A famous Polish mathematician
A.Tarski dealt with algebraization of them. This was not easy even for the
Master, but eventually possible. The resulting algebra is well-known as cylindrical
algebra; it is quite a sophisticated mathematical notion. Authors of [LMSVVZ93]
have no such problems: quantifiers are treated as algebraic operators of the
defined object algebra. No comment.
3.4. Meta-language Pitfals
Consider
an expression of the relational algebra R1 join1=1 R2.
The expression consists of three meta-language symbols: R1, R2
represent elements of the algebra (i.e. some relations), and join1=1
represents an operator (currently, equi-join according to the first columns of
argument relations). Strictly speaking, we have in this algebra infinitely many
join operators, represented in the object-language as join2=1, join2=2, join2<2, join1<3,
etc. Indices of the operators, such as 1=1, 1<3 are meta-language formulas
used, by convention, within the object language. Symbols such as =, < do
not represent operators of this algebra, but they are predicate symbols of
the meta-language. This convention is informal and is justified only by the
fact that these indices have a construction simple enough to avoid semantic
ambiguities.
The
situation is very different in proposals concerning object algebras, where operators
(selection, join, etc.) are indexed by complex expressions. Indices are usually
informal, but of course, one can formalize them. However, it is rather
cumbersome to introduce and manipulate indices having their own complex syntax
and semantics. Moreover, there are suggestions that these indices may involve
operators of the same algebra. Hence semantics of the operator symbols is
defined through (informal?) indices addressing denotations of the same symbols.
In mathematics such a definitional knot is unacceptable.
3.5. Higher order
In
[LMSVVZ93] the authors tried to avoid the pitfalls but apparently ended up with
another problem. The meta-language definition of the join operator is as
follows:
join(p,f)(A,B) = {f(a,b): a
Î A, bÎ B, p(a,b)}
where the equality symbol is the
definition symbol. The operator has actually not two arguments, as in the
classical relational algebra, but four: joined elements, a formula p
determining the join condition, and a function f determining how the
final result of the join has to be formed.
Note
that the defined join is a second-order operator, as its first two arguments
are operators; the paper contains no word about this non-standard assumption. As
far as the semantics is concerned, the situation is no better, because of lack
of definitions concerning semantics of p, and concerning arguments and
results of f. Moreover, now there is an explicit statement that p
may involve operators of the same algebra (however, unclear, all or some of
them). Such a solution leads (e.g. if p involves the join) not to a
recursive definition, but to an erroneous definition commonly referred to as ignotum
per ignotum (an attempt to define a concept through undefined concepts).
3.6. States and Query Results
Proponents
of object algebras tend to neglect the fact that operators represented in
algebraic expressions have to be defined not on "objects", but on
functions mapping objects' states into some mathematical entities. Let us
discuss the case. Consider an algebra <E,O>
and (to focus our attention) let E be a set of sets of objects
(possibly, segmented into sorts). In object algebras it is explicitly assumed
that the meaning of an algebraic expression q is an element of E.
However, an implicit assumption in the definition of many operators is
different. Because the query is formulated without the knowledge what the
database actually contains, its semantics should be understood as a function
mapping database states into some query results, i.e., the meaning is function f:State® Result, where State and Result are sets
of some mathematical entities. The problem is how to define these domains. One
may assume that the domain Result is E, but such an assumption
for many operators is not adequate (e.g., aggregate functions, boolean operators). For updating the domain Result
has to include the domain State.
The
assumption that Result is different from E violates the so-called
"closure property", which requires that the arguments and results of
queries have to belong to the same domain. (The closure property is advocated
as a prerequisite for nested queries, but this is obviously not true; see
[SKL95a].) Assuming arguments and results of queries are sets of objects, how
are the identifiers of the returned object built? One approach is to restrict
queries to object-preserving operators, i.e. the result of a query is a subset
of its argument set of objects. This solution gives no room for composition of
a query result from many objects, e.g. joins. In another approach (object
generating) [ShZd89a,ShZd89b,ShZd90] the result
objects obtain new unique identifiers. This is in conflict with the determinism
of algebraic operators, where the same operation for the same arguments must
return the same result.
The
closure property makes sense for value-oriented (functional) models. Ullman
[Ullm87,Ullm91], presenting arguments in favour of
them, essentially concludes that for object-oriented models the closure
property is a nonsense. We agree with this thesis (although in our opinion it
cannot serve as an argument against object-oriented models). The consequence is
the following: if for object-oriented models the closure property is nonsense,
then object-oriented query algebras (calculi, logic, etc.) based on this
property must be alike.
4. Pragmatic Flaws of Object
Algebras
Pragmatics
of a scientific proposal concerns how it could be efficiently used in practice.
This issue turns out to be dramatic for almost all theoretical output and
predictions in many domains of computer science, including software
engineering, PLs and databases. Perhaps the reason for (short term) pragmatic
inefficiency of theories is of deep philosophical nature. There is
contradiction between aesthetic goals of science and pragmatic goals of industry.
There is also contradiction between the complexity of mental, linguistic,
physical and other structures build by system developers (on clients' demands),
and the conceptual simplicity of assumptions and axioms, required by abstract,
aesthetic mathematical theories.
4.1. Building a New
Utopia
Implicitly
or explicitly, the proponents of object algebras follow a compromised idea of
mapping a practical system onto a formal one, with the same hope that this will
solve practical problems. The question is whether the case is realistic. Note
that before the formalization an informal but precise specification is
required. This concerns such big systems of notions as the ODMG standard
[Catt94] or SQL3 [ANSI94] (hundreds of pages). The experience has shown that
such an informal specification from the point of view of mathematics is very
incomplete. Moreover, it is common that practical languages involve options,
which are outside of the abstraction level of the assumed formal framework. Also,
the formalization may require correction of the language constructs, because of
irregular, redundant or doubtful features. The question is: who will do this
job?
In
our opinion, formalization of practical languages is a task which nobody is
able and wants to do. People oriented towards practice are unable to do it
because they are not sufficiently familiar with mathematics and in most cases
they (rightly) do not believe that this effort makes sense. Mathematicians will
refuse to do it (rightly, too), because recognizing details of practical
systems is far from methods they are accustomed to. Moreover, such
formalization is below the level of mathematical aesthetic and elegance and is
not intellectually interesting; though, these are the main driving forces of
the mathematical research.
The
assumption that the formalizations of QLs through object algebras will support
practical implementations is so far only an [ideological forecast] of
proponents of object algebras. There is no proof that they are right and there
are arguments that they are wrong. The history of the computer science presents
quite serious ideologies that failed because they were utopias; see, for
example, the Vienna Development Method.
4.2. Really Query
Optimization?
There
are many features of QLs/PLs and their implementations, which can be considered
for performance improvements. The database literature usually assigns the term
"query optimization" to the following methods:
·
Transformations
of external or internal representations of queries to such a semantically
equivalent shape which promises better performance, for example, shifting
selections before joins. This class of optimization methods is referred to as
rewriting.
·
Avoiding
redundant computations, for example, discovering common sub-queries in a group
of queries, reusing results of previous queries, avoiding multiple calculation
of the same sub-query which is nested in a loop.
·
Access
support structures, e.g., indices; fast access/processing algorithms, e.g.
hash-joins.
·
Generating
an optimal plan of computing temporary results of queries. It involves various
measures concerning the cost of operations. An optimal plan can be static
(i.e., generated before a query is executed) or dynamic (after making a step
according to a plan a new its step is re-calculated).
These
methods are not separable. Usually a combination of them is implemented in a
particular system. Also, the methods can be very different in centralised and
distributed databases; they may also depend on a store kind, e.g. disc vs. main
memory databases.
Object
algebras are able to deal only with one class of optimization methods, namely,
methods based on rewriting. Moreover, rewritings that are available in some
languages can become no more available after the mapping of queries into object
algebra expressions. Such a mapping might lose specific information or property
which could be efficiently utilized in a particular QL. For example, we can
expect that the rewriting method "predicate move around" [LMS94] is
unattainable after such a mapping, because the method is dealing with SQL views,
but algebras do not cover this concept. Another example: mapping path
expressions into algebraic formulas (using joins) seems to be a nonsense, because path expressions can be easily and
efficiently implemented utilizing pointer links in data structures; these links
can be utilized by joins only with difficulties. The inference that the join
(as shown in Section 3.5) will be efficient in implementation is obviously
invented. Efficient join algorithms (sort-merge, hash-join) concern equi-joins,
not joins based on a complex joining formula p. There are more such
doubts.
We
note that the popular opinion concerning the success of rewriting methods based
on mapping queries into relational algebra expressions, and then, optimizing
the expressions by rewriting, is not based on real facts. Usually, implementors
apply mapping of queries into informal internal representation, e.g. syntactic
trees, which are more convenient to manipulate during optimization. Optimization
methods, such as performing selections and projection before joins, can be
applied to such representations, with no mapping to the relational algebra. Moreover,
such methods are based on simple observations and perhaps are or would be
invented by talented system developers even not being aware of any formal
methods.
How
often object algebras might be practically used? Defenders
of object algebras make implicit assumption that they need to be used only to
optimize the most essential part of an entire QL. In general, such an approach
is appropriate, providing this part is really the most essential and the
formalization is correct. However, our experience with SQL has shown that
queries that could be correctly formalized through the relational algebra are
not so frequent (because of duplicates, null values, ordering, grouping,
arithmetic operators, exists, etc.). The same probably will concern
object-oriented QLs. Hence the corresponding algebraic methods will play a
minor part, if any.
Summarizing,
the assertion of proponents of object algebras concerning their potential for
query optimization is wishful thinking. There is no practical or theoretical
evidence that they are right, and there are strong arguments that they are
wrong. Moreover, each formal description of semantics can be used to prove semantically
equivalent transformations (for instance, calculus, logic, operational model,
denotational model). No algebra has an advantage in this respect.
5. Conclusions
Conceptual
shortcomings of object algebras concern insufficient level of universality and
explicit and implicit restrictions, which neglect a lot of vital semantic
aspects of real query/programming languages. Mathematical flaws consist in:
lack of many definitions, inadequate mixing of the language and meta-language
levels of consideration, attempts to treat as algebraic some non-algebraic
operators, incorrect treatment of the concept of database state, and others. We
also doubt the possibility of developing mappings of practical languages into
an object algebra, e.g., because there is few or no practicians or
theoreticians who would be skillful enough and/or would believe in this job. Additionally,
algebras can deal only with a particular kind of query optimization
(rewriting), and there are obvious cases when the mapping of a practical
language into an algebra may cancel big sources of
performance improvement. Summarizing, we doubt any scientific or
practical value of such algebras as mathematical systems - although they could
have some meaning as informal languages. The constructive conclusion is that
the database domain needs new formal and intellectual paradigms. The
stack-based approach is our answer to the need.
References
[AlAr93] R.Alhajj, M.E.Arkun. A Query Model for Object-Oriented Databases. Proc. 9th Conf.
on Data Engineering, 1993, pp.163-172
[ANSI94] American National Standards Institute (ANSI)
Database Committee (X3H2). Database Language SQL3.
J.Melton, Editor. 1994
[BMG93] J.A.Blakeley, W.J.McKenna, G.Graefe. Experiences Building the Open OODB Query Optimizer. Proc.
ACM SIGMOD Conf., 1993, pp.287-296
[CDV88] M.J.Carey, D.J.DeWitt, S.L.Vandenberg. A Data Model and Query Language for EXODUS. Proc. ACM SIGMOD
Conf., 1988, pp.413-423
[Catt94] R.G.G. Cattel (Ed.) The Object
Database Standard ODMG-93. Morgan Kaufman 1994
[Clue89] S.Cluet et al. Reloop, an Algebra Based Query Language for an
Object-Oriented Database Systems. Proc. 1st Conf. on Deductive and
Object-Oriented Databases, 1989
[ClDe92] S.Cluet, C.Delobel. A
General Framework for the Optimization of Object-Oriented Queries. Proc.
ACM SIGMOD Conf., 1992, pp.383-392
[ClDe94] S.Cluet, C.Delobel. Towards
a Unification of Rewrite-based Optimization Techniques for Object-Oriented
Queries. (In) Query Processing for Advanced Database
Systems. Morgan Kaufmann, 1994, pp. 245-272
[Cohn81] P.M.Cohn. Mathematics and Its Applications.
Volume 6: Universal Algebras. D. Reidel Publishing Co., Dordrecht, Holland,
1981
[DGG94] B.Demuth, A.Geppert, T.Gorchs. Algebraic Query Optimization in the CoOMS Structurally
Object-Oriented Database System. (In) Query Processing
for Advanced Database Systems. Morgan Kaufmann, 1994, pp.121-142
[GZC89] R.H.Guting, R.Zicari, D.M.Choy. An Algebra for Structured Office Documents. ACM Trans. on
Office Info. Systems, Vol.7, 1989, pp. 123-157
[HFLP89] L.M.Haas, J.C.Freytag, G.M.Lohman,
H.Pirahesh. Extensible Query Processing in Starburst.
Proc. ACM SIGMOD Conf., 1989, pp.377-388
[KeMa94] A.Kemper, G.Moerkotte.Query Optimization in Object Bases:
Exploiting Relational Techniques. (In) Query Processing for
Advanced Database Systems. Morgan Kaufmann, 1994, pp. 63-98
[LMSVVZ93] T.W.Leung, G.Mitchell, B.Subramanian,
B.Vance, S.L.Vandenberg, S.B.Zdonik. The AQUA Data
Model and Algebra. Proc. 4th Workshop on Database Programming Languages,
1993, Springer Workshops in Computing, pp. 157-175
[LMS94] A.Y.Levy, I.S.Mumick, Y.Sagiv. Query
Optimization by Predicate Move-Around. Proc. 20th Conf. on Very Large Data
Bases, 1994, pp.96-107
[MaBi79] S.MacLane, G.Birkhoff. Algebra. MacMillan, New York, 1979
[PoSm94] A.Poulovassilis, C.Small. Investigation of Algebraic Query Optimization Techniques for
Database Programming Languages. Proc. 20th Conf. on Very Large Data
Bases, 1994, pp. 415-426
[ShZd89b] G.M.Shaw, S.B.Zdonik. Object-Oriented
Queries: Equivalence and Optimization. Proc. 1st Conf. on Deductive and
Object-Oriented Databases, 1989, pp. 264-278
[ShZd89a] G.M.Shaw, S.B.Zdonik. An Object-Oriented Query Algebra. Proc. 2nd Workshop on
Database Programming Languages, June 1989, Morgan Kaufmann, pp. 103-110
[ShZd90] G.M.Shaw, S.B.Zdonik. A Query Algebra for Object-Oriented Databases. Proc. 6th
Conf. on Data Engineering, 1990, pp. 152-162
[Ston88] M.Stonebraker. Future Trends in Database
Systems. Proc. 4th Conf. on Data Engineering, 1988
[StOz90] D.D.Straube, M.T.Ozsu. Queries and Query Processing in Object-Oriented Database Systems.
ACM Transactions on Information Systems, Vol.8, No.4, 1990, pp.387-430
[SBMS93] K.Subieta, C.Beeri, F.Matthes, J.W.Schmidt.
A Stack-Based Approach to Query Languages. Institute
of Computer Science Polish Academy of Sciences, Report 738, Warszawa, Dec.
1993, http://www.ipipan.waw.pl/~subieta/EngPapers
[SBMS94] K.Subieta, C.Beeri, F.Matthes, J.W.Schmidt.
A Stack-Based Approach to Query Languages. Proc. 2nd
East-West Database Workshop, 1994, Springer Workshops in Computing, 1995, http://www.ipipan.waw.pl/~subieta/EngPapers
[SKL95a] K.Subieta, Y.Kambayashi, J.Leszczy³owski.
Procedures in Object-Oriented Query Languages. Proc.
21th Conf. on Very Large Data Bases, 1995, pp.182-193,
http://www.ipipan.waw.pl/~subieta/EngPapers
[SKL95b] K.Subieta, Y.Kambayashi, J.Leszczy³owski.
Towards an Integrated Query/Programming Languages for
Object Bases: a Broad Outlook. http://www.ipipan.waw.pl/~subieta/EngPapers
[SZLV93] B.Subramanian, S.B.Zdonik, T.W.Leung,
S.L.Vandenberg. Ordered Types in the AQUA Data Model.
Proc. 4th Workshop on Database Programming Languages, 1993, Springer Workshops
in Computing, 1993, pp. 115-135
[SLVZ95] B.Subramanian, T.W.Leung, S.L.Vandenberg,
S.B.Zdonik. The AQUA Approach to Querying Lists and
Trees in Object-Oriented Databases. Proc. 11th Conf. on Data
Engineering, 1995, pp. 80-89.
[Ullm87] J.D.Ullman. Database Theory: Past i Future. Proc. ACM
SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, 1987, pp.1-10
[Ullm91] J.D.Ullman. A Comparison of Deductive and
Object-Oriented Database Systems. Proc. 2nd Conf. on Deductive and
Object-Oriented Databases, Springer LNCS 566, 1991, pp.263-277
[VaDe91] S.L.Vandenberg, D.J.DeWitt. Algebraic Support for Complex Objects with Arrays, Identity, and
Inheritance. Proc. ACM SIGMOD Conf., 1991, pp.158-167
[YuOs91] L.Yu, S.L.Osborn. An
Evaluation Framework for Algebraic Object-Oriented Query Models. Proc.
7th Conf. on Data Engineering, 1991, pp.670-677
[1] The paper was written in 1995 but unpublished. It was
considered by some journals as offensive for many database authorities, i.e.
excellent and ideal researchers, which should never be criticized.