Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!usc!apple!netcom!rodent
From: rodent@netcom.COM (Ben Discoe)
Newsgroups: comp.object
Subject: Re: Has anyone taken an approach like this?
Message-ID: <1991Mar21.014903.17384@netcom.COM>
Date: 21 Mar 91 01:49:03 GMT
References: <1991Mar19.042444.20834@netcom.COM> <21256@shlump.nac.dec.com>
Organization: Netcom - Online Communication Services  UNIX System {408 241-9760 guest}
Lines: 65

d_muller@suisse.enet.dec.com (Dan Muller) writes:
>rodent@netcom.COM (Ben
>Discoe) writes:
>| I'd rather store the relationship once:
>| Dog		"A eats B" relations	 Bird
>| ----		--------------------	 ----
>| eats	->	DogOID/BirdOID	   <-	eaten by

>I believe that in relational database theory, this organization of
>data is used to form many-to-many relationships.  Treating Dog and
>Bird as data tables, then the "A eats B" column is a special type of
>data table called a "dictionary", and is in fact the _only_ way of
>constructing many-to-many relationships between Dogs and Birds in a
>properly normalized database system.

>Given a Dog instance, you can look up all Bird instances eaten by the
>Dog by searching the dictionary for entries containing that Dog's ID.

  I was hoping to avoid any kind of brute-force searching.  Every object
(class) should have links to any related object (class) that the
application is likely to correlate.

>If there's a one-to-many relationship (a more likely situation in this
>example), each Bird object can contain a Dog ID and all of a Dog's
>meals can be found by searching for matching Dog IDs in the table of
>Birds.

  Wouldn't it be much more elegant to form a relationship between the
Dog and an aspect of Animal, a superclass of Bird?  That way instead of
each class of bird containing a link to each kind of object that eats
it, the query "What eats this bird" can search upward through the
object heirarchy, looking for links to "eaten by" relations, finding
the link under Animal and concluding that the bird is lunch.

  This way of forming many-to-many relationships (generality, saying
"Dog eats [Animal with certain values in its fields]") seems like the
most desirable (conceptually and implementationally) way.

>Of course, if you feel that a particular application can benefit from
>treating the relationship itself as a separate object (for instance,
>if the same type of relationship can hold among lots of unrelated
>classes of objects and you wish to manipulate the relations per se
>independently of the referenced objects)

Isn't this true of the "real world" and the way we handle it conceptually?
Our minds re-use the concept "A eats B" for all kinds of classes.
(Uh-oh, I'm starting to sound like a Marvin Minsky wanna-be)
Not that human metal processes can be readily modeled with Objects,
but why not use the Object facilities we're comfortable with to
describe relationships also.

>, then the organization you
>describe has obvious advantages.

OK, everyone, now how should we describe the operations on Classes
that determine whether or not a particular relationship holds true for
it?  Perhaps if the Class pointed to the relationship Class which in
turn evaluated the Class's fields... no, that ruins the reusability
of the relationship.  Hmmm, any thoughts? 

>| Dan Muller / KA1UXL / d_muller@took.enet.dec.com
>| "So THAT's what an invisible barrier looks like!"

------------------
Ben in San Jose, struggling to be a generalist in a world of specialists.