Path: utzoo!attcan!uunet!wiley!trwarcadia!simpson From: simpson@trwarcadia.uucp (Scott Simpson) Newsgroups: comp.databases Subject: Re: Extended RDB vs OODB Keywords: CASE OODB Message-ID: <5260@wiley.UUCP> Date: 17 Aug 89 17:36:35 GMT References: <3560052@wdl1.UUCP> <408@odi.ODI.COM> <3324@rtech.rtech.com> Sender: news@wiley.UUCP Reply-To: simpson@trwarcadia.UUCP (Scott Simpson) Organization: TRW Arcadia Project, Redondo Beach, CA Lines: 73 You may wish to look at the article "Intermedia: A Case Study of the Difference Between Relational and Object-Oriented Database Systems", Karen E. Smith and Stanley B. Zdonik, Brown University, OOPSLA '87 Proceedings. Basically, the authors implemented a hypermedia system on top of a relational and then an object-oriented database system and they determined that the object-oriented model suited their problem domain better. Some of the conclusions they came to o Relational databases are awkward as information made up of complex, hierarchical data structures need to be flattened into relations and un-flattened when you retrieve data. The authors had to mimic hierarchies with identification keys rather than use pointers or direct references. There was a mismatch between the programming language data structures and the database data structures. o Object-oriented databases provide class-extensibility. With relational databases, their is a single parameterizable type, relation. With an OODB, each object is associated with a class and you can add new classes that are on the same level as the system types. Your new objects are first-class citizens. In fact, you can simulate a relational database by creating a tuple class. o Object-oriented databases provide data abstraction. The behavior of an object is described by a class definition. These class definitions provide data abstraction at the level of the database, not at the level of the application. o OODBs can store active objects. Since methods are stored in the database, an application can ask the database to invoke a method on an object. Since methods are expressed in terms of a programming language, any operation can be performed. This is in contrast to relational query languages that are not computationally complete. Also, since the bulk of the application code resides in the database, it can utilize the built-in concurrency, versioning, etc. o There is no need to copy data to virtual memory in an OODB. The application can send messages to objects and have them invoke methods on those objects. The computation is done on the database side, not on the application side. This is especially critical if your database resides over a network. The data does not need to be shipped across the network. In a RDBMS, data needs to be shipped across for each projection, join, etc. Stored procedures have been added to many databases to address this problem, but I think it is a cleaner solution to have it in your original model than as an add on hack. With an OODB, sending one message can take the place of many relational queries. o OODB have automatic type checking at the point of use. Since methods are executed locally, the database can perform type checking as soon as a method is called. In an RDBMS, type failures are detected when the tuples are checked back in. o OODB provide a better granularity of locking facilities. In an RDBMS, because hierarchies are represented across a number of relations, the application needs to explicitly lock each record to lock the hierarchy. In an OODB, an application can lock a hierarchy in a single operation. My personal view is that relational databases were fine for tabular data such as invoices in the data processing world, but the scientific world deals in objects, not tabular data. The twisting of objects onto a relational structure causes poor performance and a wide semantic gap. Scott Simpson TRW Space and Defense Sector usc!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)