danielg@.med.unc.edu (Daniel Gene Sinclair) (02/03/89)
In my quest to understand things way over my head, I will again post a
simple question - how else do we get non-programmers to use the net ? :-)
My question is this : could someone define and contrast relational and
object-oriented databases?
Thanks,
Daniel G.
================================================================================
| 'If you knew how much I was holding back,
danielg@uncmed.med.unc.edu | you would commend me.' -Spurgeon
================================================================================render@m.cs.uiuc.edu (02/03/89)
Written 3:39 pm Feb 2, 1989 by danielg@.med.unc.edu: >My question is this : could someone define and contrast relational and >object-oriented databases? Seeing as I'm fresh from taking a database course, I'll take a stab at this. A conventional relational database is an implementation of the relational model of E.F. Codd (there are other such models, but Codd's is the one which gained widest acceptance). In a relational database, all data is stored in tabular structures called "relations". Each column of the relation corresponds to an "attribute", and each row of the relation is an n-tuple of attribute values (n is the number of attributes for the relation). In a strict relational database, attributes can only have simple values, i.e. numeric, boolean, character, integer, etc. The ones which I have used also usually have a character string type which can be given as the domain of an attribute. Some subset of the attributes can be denoted to be "key" attributes, and their collective values serve to distinguish tuples from one another. A relation is usually defined by giving its name, its attributes and their domains, e.g. relation employee [key idno] of idno: integer, name: cstring, dept: cstring, salary: float, mgr: cstring end; The basic relational operations are relation creation & deletion, tuple insertion & deletion, selection, projection and set ops (a relation can be viewed as a set of n-tuples, so set operations are usually defined for them). Selection is the choosing of tuples (rows) from a relation based on their attribute values, and projection is the choosing of attributes (columns) from one or more relations and joining them into a single relation. Both selection and projection return a relation as their results. There are other operations which one may define for a relational database manager based on either relational algebra or relational calculus, but they can usually be expressed in terms of those mentioned. Object-oriented databases are less well-defined. They look a lot like O-O programming systems except that the objects created persist after you leave the database manager program. The basic data structures are records and sets, making them similar to relations in some implementations. A record is a collection of named variables (instance variables, attributes, properties, the names differ) which hold the values for a single entity. The sets are collections of entities of the same type. A declaration for the employee relation in a O-O database might look like empType = record idno: integer; name: string; dept: cstring; salary: float; mgr: string ; end; empSet = set of empType; See how they look similar? Of course, since O-O databases have no universal formal model underlying them, details of implementation and functionality can vary. Most obviously support record and set creation and destruction, variable assignment, querying and so forth, just like an abstract data type. Beyond this it depends on the DBMS. The one O-O DBMS I've read most about is Orion (done mostly at MCC in Texas) and it supports the above ops as well as a relational sort of selection operation. The big difference stressed in my DB class is that relational databases are "value" oriented, i.e. the values which comprise a tuple are what distinguish one tuple from another. O-O databases are "identity" oriented, and each record has some unique ID, given as part of its creation, and not made up of its variable values. Also, almost all relational operations have relations as both input and output, while O-O operations can take records, sets, variables, or whatever the model defines. This sort of sums up my understanding of the two. It's hard to compare them fully because of the lack of agreement on what an O-O database is. Maybe if that ever gets formalized, the differences will be easier to quantify, but I don't see this happening any time soon. Hal Render University of Illinois at Urbana-Champaign render@a.cs.uiuc.edu (ARPA) {seismo,pur-ee}!uiucdcs!render (USENET)
moiram@tekcae.CAX.TEK.COM (Moira Mallison) (02/14/89)
In article <3900003@m.cs.uiuc.edu> render@m.cs.uiuc.edu writes: >The basic data structures >are records and sets, making them similar to relations in some implementations. >A record is a collection of named variables (instance variables, attributes, >properties, the names differ) which hold the values for a single entity. >The sets are collections of entities of the same type. I have experience with two object-oriented databases, and read about a couple others. Hal is correct that there is no concensus about what an OODBMS really is. I think, however, that Hal oversimplifies what many people would consider essential in the data model. All of the attributes in his example had primitive data types, such as the ones relational attributes are constrained to. This constraint does not exist in the OO models, as a rule, giving rise to legal non-first-normal- form structures. There are a good number of classes/types provided with the database, and operations for users to build their own. Collections (a supertype of sets, lists, arrays, etc) are not constrained to be entities of the same type in all systems; the constraint may be an option. The existence of the named variable may be optional. In some systems, facilities are included for maintaining referential integrity. >The big difference stressed in my DB class is that relational databases >are "value" oriented, i.e. the values which comprise a tuple are what >distinguish one tuple from another. O-O databases are "identity" oriented, >and each record has some unique ID, given as part of its creation, and not >made up of its variable values. In the two systems I've worked with, the unique ID is not under the control of the user. ie, rather than given as part of the creation, it is assigned by the system as part of the creation. But it is true that while you can't change the key of a relational row (because of the value-orientation) you could change the "key" of an object. It's kind of the same as a person's name. If I were to change my name, would I be a different person? No. In the same way, the object maintains it's identity regardless of attribute values. Moira Mallison CAX Data Management Tektronix, Inc.
stuart@bms-at.UUCP (Stuart Gathman) (02/14/89)
An O-O database is a relational database whose field/attribute/column
types are O-O "classes". Therefore, the fields/elements/members are
"objects". The relation is called a "set" and the records/tuples/rows
are called "records". An aggregate class supports inserting records
into and querying the sets. (Just like an "array" aggregate class
supports collections of objects in array form.)
--
Stuart D. Gathman <stuart@bms-at.uucp>
<..!{vrdxhq|daitc}!bms-at!stuart>render@m.cs.uiuc.edu (02/15/89)
Written 6:01 pm Feb 13, 1989 by moiram@tekcae.CAX.TEK.COM: >I have experience with two object-oriented databases, and read about a >couple others. Hal is correct that there is no concensus about what >an OODBMS really is. I think, however, that Hal oversimplifies what >many people would consider essential in the data model. > [Moira goes on to point out some things I missed.] I agree with everything Moira said. From what I've read, the big plusses in OODBMS are the more advanced data structuring facilities, particularly the ability to define true complex objects, and the built-in object identity facility. I neglected to mention these because I decided to stick with what I learned in my DB class about OODBMS (not much) and not mention what I've only read about. One other thing I didn't discuss because I haven't read much about it--the ability of the user to define new operations and associate them with classes/types. This is a standard feature of OOPLs like Smalltalk and C++ but isn't mentioned in the OODB papers I've read. I'd be interested to hear from Moira (or anyone else who has used and OODBMS) if the OODBMS they've used have facilities for defining operations and associating them with data types. Hal Render University of Illinois at Urbana-Champaign render@m.cs.uiuc.edu uiucdcsm!render
wilson@carcoar.Stanford.EDU (Paul Wilson) (02/16/89)
I may have missed the info I'm looking for, since I just started reading this group, but could somebody point me to a bozo-level introduction to OODB's? I have programmed in object-oriented languages, so something that leverages off of that would be nice. (My understanding of relational databases is only very basic, millimeter-deep stuff.) The paragraph-long explanation that this is a followup to was just the sort of thing I'm looking for -- concise but clear. Now I'm looking for several pages, going a little deeper and giving examples. (I've started to read two or three "pop" articles that seemed contentless and confusing. Something more to the point would be nice, as in "how you can do relational operations on polymorphic data without horrendous problems".) Thanks prematurely, Paul Paul R. Wilson Human-Computer Interaction Laboratory lab ph.: (312) 413-0042 U. of Ill. at Chi. EECS Dept. (M/C 154) Box 4348 Chicago,IL 60680 wilson@carcoar.stanford.edu Paul R. Wilson Human-Computer Interaction Laboratory lab ph.: (312) 413-0042 U. of Ill. at Chi. EECS Dept. (M/C 154) Box 4348 Chicago,IL 60680 wilson@carcoar.stanford.edu
bouguett@boulder.Colorado.EDU (Athman Bouguettaya) (02/16/89)
In article <152@bms-at.UUCP> stuart@bms-at.UUCP (Stuart Gathman) writes: > >An O-O database is a relational database whose field/attribute/column >types are O-O "classes". Therefore, the fields/elements/members are >"objects". The relation is called a "set" and the records/tuples/rows >are called "records". An aggregate class supports inserting records >into and querying the sets. (Just like an "array" aggregate class >supports collections of objects in array form.) >-- >Stuart D. Gathman <stuart@bms-at.uucp> > <..!{vrdxhq|daitc}!bms-at!stuart> I do not think that you are giving a proper definition of the Relational and OO databases. These two concepts are very different from one another. I believe that a more accurate definition would be as follows: The basic concept used in relational databases is the relation. A relation has attributes. No behavior is embedded within a relation. This latter is embedded within aplication programs. The basic concept in OO databases is the object. An object consists of instance variables and methods. The instance variables determine the structure of the object whereas the methods define the behavior of the object. In class-oriented systems, similar objects are grouped into a class. Roughly speaking, if one makes a comparison with programming languages, objects are equivalent to variables and classes are equivalent to types with the exception that classes are used to store some shared and default information whereas types are merely a representation. The other major component od OO databases is the relationship. Classes are related by relationships. Their semantics is as rich as one wants. A priori, there is no limitation on the semantics attached to relationships. -Athman ------------------------------------------------------------------- | | |Athman Bouguettaya | |Dept of Computer Science, University of Colorado at Boulder. | |E-mail: arpanet : bouguett@boulder.colorado.edu | | csnet : bouguett@boulder.csnet | | bitnet : bouguett@boulder.bitnet | | uucp : {ncar|nbires}!boulder!bouguett | -------------------------------------------------------------------
jim@athsys.uucp (Jim Becker) (02/17/89)
Athena has implemented an object-oriented database for our OO product. We store the actual instances of the classes and data structure objects into the database intact. One thing that this has shown is that the process to upgrade or change the class definitions of the objects results in an entire schema change and upgrade process for the entire database. Meaning that the modification of a single class definition results in an upgrade problem/path that must be addressed before databases created prior to the modification can be used. Also, all databases used must be used against the exact matching software (classes have to matchup exactly). Note that this problem only would exist during the development process, not once in the field. This problem can also be aggravated by something as simple as a compiler change or upgrade, if this results in a different layout or structuring of the data elements. I'm not a relational database expert, but they seem to be disjoint enough that it is fairly easy to adjust the various fields and add or subtract new fields. They also appear simplier to reconstruct and manage. In our approach to OO database design and usage this has not proved to be the case. -Jim Becker ...!sun!athsys!jim
render@m.cs.uiuc.edu (02/17/89)
Written 10:33 am Feb 15, 1989 by wilson@carcoar.Stanford.EDU: >I may have missed the info I'm looking for, since I just started reading >this group, but could somebody point me to a bozo-level introduction >to OODB's? Unfortunately I don't know of one. Looking throught the articles I have, you might check out the following: Zdonik, Stanley and Peter Wegner, "Language and Methodology for Object-Oriented Database Environments," Proceedings of the 19th Annual Hawaii International Conference on Systems Sciences, January, 1986. For a comparison of OODBs and RDBs, try Smith, Karen E. and Stanley B. Zdonik, "Intermedia: A Case Study of the Differences Between Relational and Object-Oriented Database Systems," Proceedings of OOPSLA '87, pp. 452-465. I only have a reference to the first, but the second is an okay comparison of an RDBMS and an OODBMS. I have a lot more OODBMS-related articles, althought most of them are written from the configuration management standpoint (my research area). If there is sufficient interest, I'll post them. Hal Render University of Illinois at Urbana-Champaign render@m.cs.uiuc.edu uiucdcsm!render
moiram@tekcae.CAX.TEK.COM (Moira Mallison) (02/25/89)
Wrt Hal's question about extensibility of classes: yes and no!
While we have agreed that the object-oriented data model is
not clearly defined, I think you'd have a hard time convincing
both the database folks and the language folks that your model
was object-oriented if it didn't have some facilities for
extending the model by the user.
I have worked mostly with GemStone (*). You cannot add methods
to any of the System Library classes, which only enforces good
programming practice: don't change a classes you haven't authored.
The problem is that you can't subclass off of certain system
classes, either. Integer is one of them (in fact, it might be
the super class, Number). So when the operation I wanted
wasn't in GemStone's methods, I had to punt. What I did was
put in a protocol for "utilities" for the object that held the
database and put my methods in there. Then the message gets
sent to the database with an Integral argument, instead of
sending it to the Integer object directly.
It works, but it feels kind of kludgey if you're used to
Smalltalk. And it's harder to share code, because general
kinds of operations (like random number generation) are
embedded in your database code, not in generic classes.
Note that this only applies to select System classes, not
all of them.
I've worked with Vbase (**) somewhat less, and it has some
similar kinds of restrictions. In any case, that product
is being re-architected and there may be changes to the
data model in Vbase+.
A third commercially available database is Gbase (***),
and I have not used it .
Moira Mallison
CAX Data Management
Tektronix, Inc.
(*) GemStone is a product of Servio-Logic Corporation, Beaverton, OR.
(**) Vbase is a product of Ontologic, Inc, Billerica, MA. Vbase+ is
in development.
(***) Gbase is a product of Graphael.plogan@mntgfx.mentor.com (Patrick Logan) (02/26/89)
In article <2514@tekcae.CAX.TEK.COM> moiram@tekcae.CAX.TEK.COM (Moira Mallison) writes:
<>
<> I have worked mostly with GemStone (*).
<> I've worked with Vbase (**) somewhat less,
<> A third commercially available database is Gbase (***),
<> and I have not used it .
<>
<> Moira Mallison
<> CAX Data Management
<> Tektronix, Inc.
<>
<> (*) GemStone is a product of Servio-Logic Corporation, Beaverton, OR.
<> (**) Vbase is a product of Ontologic, Inc, Billerica, MA. Vbase+ is
<> in development.
<> (***) Gbase is a product of Graphael.
Last April I used G*base briefly (a few days) and attended their training class.
I used it on a Symbolics and seem to recall it also runs on TI Explorers
(including the MacII/MicroExplorer) and Suns. A port to Vaxen was either
planned or in progress.
G*base requires a CommonLISP environment. It doesn't provide what some may
consider the essentials of a true object-oriented system: there are no "methods"
for objects managed by the database and there is no user-definable class hierarchy
(i.e. there are user-defined types but no inheritance). One could provide "methods"
easily using the Lisp interface, all I'm saying here is such a mechanism is not
managed automatically by G*base.
It also doesn't provide some essential database features: e.g. it is not multi-user.
I also don't recall any versioning mechanisms, although it does provide the concept
of commiting a transaction.
In essence, G*base provides a persistent store for a "property list"-style
single-user database. On top of that it adds an interesting query/report/data-entry
interface, a fairly extensive procedural interface (Lisp only), a Prolog interface
(using their version of Prolog that runs within the same Lisp environment, and
strong support for arbitrary data (e.g. sound, bit-maps, structured graphics, anything-
you-want-and-can-get-into-a-computer).
Graphael seemed to be aware of the difference between G*base and a "true" object-
oriented database. Some work was in progress, for instance concurrency and inheritance
I believe were either being planned or implemented.
*** I have never been associated with Graphael. All information here is based on hazy
recall that may not be accurate. I suggest contacting Graphael for facts. They're
located somewhere around Boston. ***
--
Patrick Logan ...!tektronix!sequent!mntgfx!plogan
"Scheme - that's the news... the, ahh, minimalist news." =8)