twine@uqcspe.OZ (Steven Twine) (09/01/88)
Before everybody jumps into the wading pool with their two cent's worth about OO databases, I'd like people to be very clear about *what* purpose these OO DBMS will be used for. There seems to be a general tendency to say that OO DBMS are *a priori* good, without saying what they are good at. One useful way of viewing matters is the ANSI/SPARC three schema architecture (Hands up everybody who knows this; hands up everybody who's forgotten about it..) This architecture includes three schemas: an external schema, a conceptual schema and an internal schema. The external schema specifies a particular way to view the data in the database. There may be different external schemas for different users (or user groups). The conceptual schema specifies the "semantics" of the data. In particular, it must specify all constraints on valid database states and transitions. There is only one conceptual schema. The internal schema specifies how the database information is physically stored and manipulated. There is only one internal schema. Now, the question comes: Are OO DB techniques useful at the external level, conceptual level, or internal level (perhaps more than one). Some people say OO DB are good because they are more efficient that (say) relational DB for certain applications (eg CAD). This is an argument at the internal level. Some people say that OO DB are good because they "express more semantics". This is an argument at the conceptual level. Some people say that OO DB are good because they present an intuitive interface to the user (eg smalltalk-based DBMS). This is an argument at the external level. If we can clearly distinguish these arguments, and see that OO DB may be good at one level, but not at another, then we might have a chance for a productive discussion rather than a lot of unsubstantiated claims and "waste heat". My personal view is: they may be good at the internal level (they support clustering, by definition); they are not good at the conceptual level (they require arbitrary grouping of facts, and there are generally too many ways to represent an arbitrary fact -- btw, these are similar to Bill Kent's arguments against record-based models); they may be good, for certain classes of users, at the external level. I could elaborate on this if there is interest. As an example, most of Yogesh Gupta's points for OO DBMS are at the internal level (authorization, persistent objects etc). This is irrelevant to the use of OO DB at the conceptual or external level. Most OO DBMS do not distinguish these levels: this is bad, because it means that performance and user convenience factors influence the design of the database (with negative effects on evolvability and maintenance). References for further reading: D. Tsichritzis, A. Klug (eds) The ANSI/X3/SPARC DBMS Framework. Report of the Study Group on Database Management Systems. AFIPS Press, Montvale, NJ, 1977. J. J. van Griethuysen (ed) ISO TC97/SC5/WG3 Report on Concepts and Terminology for the Conceptual Schema and the Information Base.
wlp@calmasd.GE.COM (Walter L. Peterson, Jr.) (09/06/88)
In article <1983@uqcspe.OZ>, twine@uqcspe.OZ (Steven Twine) writes: > Before everybody jumps into the wading pool with their > two cent's worth about OO databases, I'd like people to be > very clear about *what* purpose these OO DBMS will be used > for. There seems to be a general tendency to say that OO > DBMS are *a priori* good, without saying what they are good > at. This is, I think, a valid question. If OODBMSs were simply "new", then there really would not be much substance to them. There is always the possibility that, in the long run, we will find that that is just the case; that is, that they hold no great advantage over the relational or hierarchical models. However, my experience tells me that that will not be the case. I believe that OODBMSs will be found to be good at doing four things: 1) They will allow users to move to higher levels of abstraction than any of the current model now allow, thus permitting users to more closely model the "real world" (whatever that is). 2) They will better model one of the most troublesome relationships in any DBMS, the many-to-many relationship. 3) They will permit, with the expanding use of object-oriented languages, closer ties between the language in which systems and applications are programmed and the underlying database. 4) They will allow a powerfull mechanism for extendability, evolvability and maintenance that is simply not possible with current systems. This point of extendability, evolvability and maintence is so closely tied to the object-oriented paradigm ingeneral that it is virtually part of the definition of object-oriented systems. > [...Very good review of the ANSI/SPARC three schema architecture > deleted to conserve space...] > > > Now, the question comes: Are OO DB techniques useful at the > external level, conceptual level, or internal level (perhaps > more than one). > I would like to address these one-by-one: > Some people say OO DB are good because they are more > efficient that (say) relational DB for certain applications > (eg CAD). This is an argument at the internal level. OODBMSs have been especially good for CAD systems, whereas the more "traditional" relational, hierarchical and network models have done a very poor job with things as complex as CAD. If CAD were the only application where OODBMSs were superior to the traditional systems, that alone might be reason enough to pursue them; CAD is an important application area that is expanding as business attempts to meet the challenges of the emerging global economy. But CAD is not the only area where these kinds of complex data structures and relationships are found. The increasing interest in the various kinds of "hypertext" systems also presents the traditional database models with problems that they either cannot solve or only solve poorly. I realize that I may get arguments to the effect that hypertext is "just a toy" or that it is "not that important"; I won't waste space here with answering those assertions. > > Some people say that OO DB are good because they "express > more semantics". This is an argument at the conceptual > level. The conceptual level is one of the areas where OODBMSs will shine. The ability of object-oriented modeling techniques to model real world applications and then to map those models DIRECTLY on to an OODBMS will take much of the grief and 'heartburn' out of constructing the conceptual level for virtually any applications. ( see Loomis, Shah and Rumbaugh [1] ) > > Some people say that OO DB are good because they present an > intuitive interface to the user (eg smalltalk-based DBMS). > This is an argument at the external level. This is true, but the argument from the external level goes beyond just the user interface. The Smalltalk-like user interface is finally gaining in popularity and it is an inherently object-oriented interface, but that is not the only reason that OODBMSs are good at the external level. The ability of objects to inherit fields and methods from ancestor classes and the abstraction ability inherent in objects will allow OODBMSs to approach the external level in ways that are just now becomming clear. > > [...] > > My personal view is: they may be good at the internal level > (they support clustering, by definition); they are not good > at the conceptual level (they require arbitrary grouping of > facts, and there are generally too many ways to represent an > arbitrary fact -- btw, these are similar to Bill Kent's > arguments against record-based models); they may be good, > for certain classes of users, at the external level. I > could elaborate on this if there is interest. > ANY grouping of facts is arbitrary. Object-oriented system, be they databases or programming languages do not REQUIRE grouping of facts; an object may be as complex as the model of reality demands or it may be as simple as a single byte. A more important thing to note is that objects are, most emphatically not records. Objects ability to inherit has already been mentioned here, so I will not pursue it further on this issue other than to point out that any so-called "inheritance" that may be found in a record based system is not a built-in feature of the system and must be directly accounted for by the builders of the system. The fact that objects cary with them their methods is a major departure from anything that even remotely resembles a record. In some systems objects can have relations with other objects that are not directly expressed as fields of the object. This too is a major departure from record based or even relational systems. If a relational system needs a relationship to exist between two tables, then one of the tables must have a "hard-coded" attribute that is a foreign key to a key in another table. One foreign key attribute is needed for each such relationship and any changes in the relationships require corresponding changes in the tables and in the applications. In an object-oriented system this is not the case. Relationships between objects do not have to be established by any sort of foreign key type of method, nor do they have to be explicitly "hard-coded" into the database schema. OODBMSs will allow any number of relationships to exist between any number of objects, with any cardinality (even the infamous many-to-many) without requiring that these relationships be "hard-coded" into the database schema. This allows them to be added, deleted and modified for any applications that need them ( see Rumbaugh [2] ). > > As an example, most of Yogesh Gupta's points for OO DBMS are > at the internal level (authorization, persistent objects > etc). This is irrelevant to the use of OO DB at the > conceptual or external level. ... Just because these points might be irrelevant at other levels does not make them irrelevant in the general sense. The discussion in Mr. Gupta's posting was generally addressing the internal level; at that level these points are NOT irrelevant. > ... Most OO DBMS do not > distinguish these levels: this is bad, because it means that > performance and user convenience factors influence the > design of the database (with negative effects on > evolvability and maintenance). > Most OODBMSs don't directly address all three levels, granted. However, many realtional systems do not DIRECTLY address all three either. A further point may be made that just because the ANSI/SPARC three schema architecture has served us well for the hierarchical, network and relational models does not mean that it was devinely inspired. Perhaps we need or even want a different paradigm for future systems. I'm not saying that that is necessarily the case. I have not really taken the time to address that issue, nor have I seen any other researchers or developers address it. This has been and I fear will continue to be one of the problems that we face with OODBMSs; namely that noone has yet given them the firm theoretical grounding that Codd gave to realtional systems. I must, however, take issue with the second and third points made here; that is, that it is bad because 'performance and user convience influence the design of the database' and that this is with 'negative effects on evolvability and maintence'. The first point regarding preformance and user convience I find very strange. For whom are we supposed to be developing these systems ? Ourselves, for our own ammusement ? Our collegues, so they can see how clever we are ? No. We are developing these systems for users. While there are considerations other than user convience and performance these are vitally important considerations. A systems that is painfully inconvient will not last long in the "real world" nor will one that performs like a turtle with a rock tied to it. The various theoretical considerations of database systems are important, but they are not an end in themselves. They are a means to an end; and that end is the production of a system that makes life easier for its users and performs at least to their expectations, if not beyond them. The claim that there is a negative effect on evolvability and maintainability, I believe I have addressed ( at least to the level that I can in this venue ) in my discussion about inheritance and object-oriented relationships. OODBMSs are and will be inherently more evolvable and far more maintainable than any previous systems. --------------------- References: [1] Loomis, M.E.S., A. Shah, J. Rumbaugh; "An Object Modeling Technique for Conceptual Design", Proceedings of the European Conference on Object-Oriented Programming (ECOOP), Springer-Verlag, 1987. [2] Rumbaugh, J.; "Relations as Semantic Constructs in an Object-Oriented Language", Proceedings of the 2nd conference on Object-Oriented Programming: Systems, Languages and Applications (OOPSLA), Association for Computing Machinery, 1987-- Walt Peterson GE-Calma San Diego R&D (Object and Data Management Group) "The opinions expressed here are my own and do not necessarily reflect those GE, GE-Calma nor anyone else. ...{ucbvax|decvax}!sdcsvax!calmasd!wlp wlp@calmasd.GE.COM