Class vs table design

Thread view:

John O'Conner - 29 Jan 2004 10:03 GMT

Hi all,

I'm working on a project for my son's Little League. In designing the
app, I've created several Java business objects with the following
relationships:

Every PARTICIPANT has one or more ROLES in the LEAGUE. They can be a
PLAYER, MANAGER, COACH, GUARDIAN (a parent, aunt, or uncle), etc.

One problem I'm having is understanding whether Guardians should be a
property of a Player or not. The alternative is an intermediate object
that relates Players to Guardians.

I seem to have this problem often. That is, it seems quite difficult at
times to decide whether an attribute of an object is really an attribute
or a separate object that is tied to the orginal object through a
relationship.

I suspect that this problem is created when I try to think about the
relational table design at the same time I'm designing the Java classes.
Is this a common problem? How do you resolve these types of questions?

Regards,
John

Reply to this Message

Bjorn Abelli - 29 Jan 2004 21:53 GMT

"John O'Conner" wrote...

> Every PARTICIPANT has one or more ROLES in the LEAGUE. They can be a
> PLAYER, MANAGER, COACH, GUARDIAN (a parent, aunt, or uncle), etc.
>
> One problem I'm having is understanding whether Guardians should be a
> property of a Player or not. The alternative is an intermediate object
> that relates Players to Guardians.

It looks like you're into the problem of m:n-relations between entities in a
relational database (RDBMS) vs associations between objects in an
object-oriented application.

> I seem to have this problem often.

It's a common problem when shifting from one paradigm to another.

Depending on which database you use, and which technology you use for
persistence, there are several solutions to the problem. If you make use of
a true Object-oriented Database (OODBMS), there shouldn't necessarily be any
problems, as you can use the same scheme in both the database as in the
application.

A big difference between designing a scheme for a Java application and an
RDBMS is that in the former every association is made up of *references*,
while in the latter the relations are based on *values* in the related
columns (foreign key columns to primary key columns).

This makes it *necessary* in an RDBMS to have "relationship entities"[1] to
resolve m:n-relations, though they would be redundant in the Java
application.

A common approach is hence to actually create two designs! One for the
application and one for the database, and then the problem is confined to
the "mapping" of one to the other (as when you fetch/save data from/to the
database).

my 2c.

// Bjorn A

[1] At this moment I don't recall what it's actually called in English, but
I hope you'll know what I mean.

Reply to this Message

Class vs table design

Free Magazines