The relational model and its extensions are often considered incompatible with object-orientation.However, on the one hand nested relations provide the complex object features demanded by object models. Particularly, powerful query languages exploit the complex data structure while keeping the advantages of the declarative, set-oriented paradigm. On the other hand, object models provide semantically rich constructs for advanced modeling, and abstractions of operations as well as data. In this paper, we show an evolutionary path from relational, essentially nested relational, to object-oriented data models and query languages. Basically, allowing nested relation schemes to be recursively defined yields the necessary flexibility w.r.t, structure. The query language, i.e., nested relational algebra, carries over to this "network" model. As a first step towards the object-oriented integration of cooperative systems, different views onto the objects have to be supported. We present a powerful view definition facility that basically allows object views as well as relational views to be defined in our object algebra."Why isn't there an object model?" is a question raised in [26]. "How to fit round objects into square databases" is another prominent quotation [45]. These questions reflect important research directions and can be rephrased as "what are the essential differences between object-based and value-based models. , or "how can the advantages of the relational model be kept when the essentials of object-orientation are added?" General agreement exists that the relational algebra with its set orientation, view definition facility, and algebraic optimization are on the pro side for relations. Nested relations and complex objects are extensions which try to keep these advantages [1]. On the OO side the most convincing advantage is the high level of abstraction which is obtained by considering objects as instances of abstract data types, only manipulated by functions, and by organizing the types into a generalization (semi-) lattice.The problem is whether these concepts from both sides can be combined into one model or whether they are incompatible by their very nature. While the integration of two different approaches is an interesting task per se, leading to deeper insight and understanding of the differences and of the similarities, there is a second, practically more important aspect: Providing transformations from one system to another or viewing the same data differently depending on from what system we kx~k at them, is important if we want to or if we have to distinguish several systems. This is necessary and important for application programmers, i.e., application specialists, who develop methods and algorithms to cooperate with the database, for database type implementors who have to integrate or extend existing types by new methods in extensible database systems [43, 11, I8, 33], or database administrators who have to integrate heterogeneous subsystems and various (often existing) applications. Especially to...