Re: [T] Clean Object Class Design -- What is it?

>
> <D_at_B.A> wrote in message news:Ogu17.10320$Kf3.116960_at_www.newsranger.com...
> > In article <tqt17.30637$3O.5592_at_newsfeed.slurp.net>, Rico says...
> >
> > >Re: object databases ... not true. As I'm sure has been pointed out to
 you,
> > >the relational model simply manipulates sets of tuples using set
 theoretic
> > >operations. There is no concept in the model of "inheritence" ... a key
> > >property of the object-oriented model ... this must be simulated by
> > >flattening the hierarchy. However, this means that related child objects
> > >are now in separate relations, and cannot be easily manipulated without
> > >multiple SQL statements. For example, change the model year of all
 vehicles
> > >on the lot at dealership A, where the parent object class Vehicle has
 been
> > >subclassed into Sedan, Coupe, and SUV.
> > >
> > Only object proponents would irresponsibly partition Vehicles into 3
 different
> > tables. In fact is there any significance in assigning 3 separate
 subclsses to
> > them? You are not going to suggest overriding "drive" method based upon
 object
> > subtype to dilership owner, arent you? Those vehicles categories are no
 more
> > than categories that can be just sitting in a single category column. BTW,
 this
> > column is functionally dependent upon such things as weight, number of
 doors,
> > fuel efficiency, etc.
> >
>
> It was a toy example. Here's the abstract version, substitute whatever
> worthy real-world objects you'd like in there:
>
> abstract class A
> {
> domainType1 x;
> // operations follow
> }
>
> class B extends A
> {
> ...
> domainType2 y;
> // operations follow
> }
>
> class C extends A
> {
> domainType3 z;
> // operations follow
> }
>
> A very typical object-oriented programming pattern would be to have a
> container containing objects of type B and C. We could iterate across that
> container setting attribute x to values, without concern as to whether we
> are dealing with an object of type B or type C.
>
> How do we accomplish the same function using the relational model? Well, we
> can flatten the hierarchies (assume we find a primary key somewhere in the
> objects, another complication of using relations with an OO model):
>
> B(...,domainType1 x, domainType2 y), C(...,domainType1 x, domainType3 y)
>
> Now the update on that container means asking the object "what kind of thing
> are you?" and then executing one of two kinds of update statements based on
> the response.
>
> Of course, another option is to split parent/child attributes into two
> tuples in different tables, but now we have to come up with primary keys to
> match them, and do a join to get them back together when we need the object
> in the application. Doing this drops all pretenses that a tuple is an
> object.
>
> The final option, and the one you mention in your response, is to put all
> attributes of every class in the inheritance tree into a single relation.
> An additional field can then indicate what kind of object it is. Problem
> with this is obvious: you'll waste a lot of space if you have a
> moderately-sized application. A lot of your fields will be empty because
> you'll only use a subset of them at any given time.
>

This is highly dependent on the implimentation. Many modern RDBMS use up ZERO space for empty fields. In other words, the physical length of the record in storage is variable. The absence of a field-value pair in the record can internally signify that the field is empty/null/blank.

As far as modeling, I agree with the prior message that you have not established a sufficient basis for "subtyping" here. Those "types" you gave could change, merge, etc. (I can envision commercials for a half sportscar and half SUV, or new gov laws WRT classifications.) One should only subtype if the divisions are permanent and significant. (I rarely find those for commerical and biz apps, BTW.)

-T- Received on Sun Jul 22 2001 - 01:34:27 CEST