Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!m.cs.uiuc.edu!render
From: render@m.cs.uiuc.edu
Newsgroups: comp.databases
Subject: Re: relational vs object-oriented
Message-ID: <3900003@m.cs.uiuc.edu>
Date: 3 Feb 89 04:59:00 GMT
References: <376@uncmed.med.unc.edu>
Lines: 86
Nf-ID: #R:uncmed.med.unc.edu:376:m.cs.uiuc.edu:3900003:000:4138
Nf-From: m.cs.uiuc.edu!render    Feb  2 22:59:00 1989


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)