Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!rutgers!tut.cis.ohio-state.edu!bloom-beacon!apple!voder!cullsj!gupta From: gupta@cullsj.UUCP (Yogesh Gupta) Newsgroups: comp.databases Subject: Re: What is an OODBMS (was Re: Object Oriented DB Articles ?) Message-ID: <410@cullsj.UUCP> Date: 1 Sep 88 18:07:00 GMT References: <3560019@wdl1.UUCP> <37@calmasd.GE.COM> <408@cullsj.UUCP> <49@calmasd.GE.COM> Organization: Cullinet Software, San Jose, CA Lines: 97 In article <49@calmasd.GE.COM>, wlp@calmasd.GE.COM (Walter L. Peterson, Jr.) writes: < < The other elements that you mention are closer to the common preception < of what a database is. Data sharing is critical; without that most < of the power and indeed the reason for having a database go away. The < need for transaction support is, I believe, also critical. You have < to be able to establish logical units of work and then commit or rollback < those transactions, just as in an RDBMS. The concept of transactions < also provides a basis for data sharing, since it is usually the framework < arround which locking occurs. I think that one of the things that is being noticed by a lot of OODBMS developers/researchers is that two-phase locking does not lead to much concurrency, especially in the case of OODBMS (I agree that the problem also exists in RDBMS). For example, ObServer (Brown Univ.) supports more than just two-phase locking (I do not know whether ENCORE [OODBMS on top of ObServer] utilizes it or allows the user to specify the locking protocol). < [...] < From the point of view of a definition of what an OODBMS is or should < be, the problems of authorization and security are secondary; from the < standpoint of producing a commercially viable product they are not, < however. Any commercial product will have to address these as closely < if not more so, as the current most successful RDBMSs do. The reason to bring this up was that so far the authorization mechanisms have been based on relations - a user may or may not access data from a specific relation, or specific columns within a relation, or where the value in some field is a specific value. I think that for OODBMS, the authorization and security would be more based on relationships, that is a user may be allowed to look at an object within a class iff it is accessed through "relationship X" and not if it is accessed through relationship Y. Thus, the specification and implementation of access authorization could be quite different from those that we see today. < < The problem of the interface is FAR too broad ( to say nothing of That is why I brought it up :-). < divisive ) to go into in this posting ( I hope to have more to say on < this soon - before OOPSLA, if possible ). < < This collection of issues only scratches the surface of the OODBMS question. < It leaves out one of the main issues that I feel is not being properly < addressed; that is "what about the methods?" An object without methods < isn't much of an object. How should an OODBMS handle the storage and < retrieval of the methods on an object? How could the methods be brought < into a running application, in a runnable form, when the application < retrieves the objects from the DB? Is this possible ? ( I believe it is ). < Is it desirable? ( I also believe that it is ). When I said "store Objects" I implied "objects and methods". I agree with your statements that the methods should be retrieved and be executable for an OODBMS to be efficient enough to be a viable product. I also agree that it is doable. However, the problems of sharing, modifications and security becomes worse - how does one prevent a user from applying incorrect methods to an object? How does one prevent a user corrupting the methods and then applying them on the objects? etc. < Another issue that is frequently not addressed by even the more commercially < successful RDBMSs is that of data integrity. We are changing that :-). < Even integrity issues as < simple as primary key - foreign key consistency are simply not addressed. < Most, if not all, data integrity checks can be made by a properly < designed ACTIVE data dictionary. I emphasized the word ACTIVE, since < far too many people, who should know better, still think that a data < dictionary is just a system documentation tool and not the actual < heart of the DBMS. I know from first hand experience that an active < data dictionary can solve many of the problems that are encountered in < producing a commercial DMBS and that given the power of object oriented < programming such a data dictionary is really quite easy to design and < implement. I agree that integrity constraints are indispensible in a DBMS. I also think that this is something that would fall out of an OODBMS just because one can specify methods that enforce integrity along with the definition of the class. In fact, the OODBMS really is nothing more than a repository :-), and the methods of a class define the operations on the objects in that class. So, the collection of the methods IS the active data dictionary. < < Well, I've stirred the pot long enough; lets see what responses this < brings. < < Walt Peterson GE-Calma San Diego R&D < "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 Thanks for your response. I hope that others get into this also. -- Yogesh Gupta | If you think my company will let me Cullinet Software, Inc. | speak for them, you must be joking.