Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!decvax!tektronix!tekcae!moiram
From: moiram@tekcae.CAX.TEK.COM (Moira Mallison)
Newsgroups: comp.databases
Subject: Re: relational vs object-oriented
Message-ID: <2477@tekcae.CAX.TEK.COM>
Date: 14 Feb 89 00:01:45 GMT
References: <376@uncmed.med.unc.edu> <3900003@m.cs.uiuc.edu>
Reply-To: moiram@tekcae.CAX.TEK.COM (Moira Mallison)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 41

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.