The Artima Developer Community
Sponsored Link

Java Answers Forum
Modelling a Many-to-Many Relationship

5 replies on 1 page. Most recent reply: Oct 15, 2003 3:51 AM by Joe Parks

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 5 replies on 1 page
Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Modelling a Many-to-Many Relationship Posted: Oct 14, 2003 4:48 AM
Reply to this message Reply
Advertisement
In my current database there are two tables People and Properties with a many-to-many relationship (i.e an person can have many properties and a property can have multiple people owning it). In the relational database, modelling this in 3nf is simple, just add an Ownerships cross reference table that links the two original tables.

What is the usual way to model this in Object form? Is it simply a matter of replacing the tables with classes (so that each person has an ownership list, as does each property)? This seems to lead to duplication of data, since each ownership is stored in two places. A change of ownership would require the same data to be modified for both the owner and the property.

I'm sure this is a faily standard problem, so any simple pointers would be welcome.

Thanks,
Vince.


Matthias Neumair

Posts: 660
Nickname: neumi
Registered: Sep, 2003

Re: Modelling a Many-to-Many Relationship Posted: Oct 14, 2003 9:12 AM
Reply to this message Reply
In a database you would create a table Ownership with 2 columns: keyPeople and keyProperty and maybe a description.


Do just the same thing in your program.

Create a class Ownerships wich is capable to hold a reference
to the class People and a reference to the class Property.

Then simply create a Vector or whatever you want and insert your list of Ownerships.

If you want to do it right, create some Methods to control, if a Ownership is allready set, if someone adds it to the list.

Joe Parks

Posts: 107
Nickname: joeparks
Registered: Aug, 2003

Re: Modelling a Many-to-Many Relationship Posted: Oct 14, 2003 2:50 PM
Reply to this message Reply
In the object model, there should only be an intermediate object if there are properties/behavior that go along with the many-many association.

That is, if you want to track information such as when the ownership began/ended, then you should create an intermediate object (an "Association Class"). Otherwise, you should not.

It is difficult to implement this by hand without the intermediate object, but O/R tools like Hibernate and OJB--and even CMP Entity Beans--will handle this for you.

Do not let the implementation details of the underlying database unduly clutter your object model.

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Modelling a Many-to-Many Relationship Posted: Oct 14, 2003 7:16 PM
Reply to this message Reply
So Joe, outside of introducing a lot objects by adding a whole a library or framework, what do you suggest?

Here is an article that fleshes out the idea mentioned above, of each object having a collection of the things it aggregates:
http://www-106.ibm.com/developerworks/webservices/library/ws-tip-objrel4/

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Modelling a Many-to-Many Relationship Posted: Oct 15, 2003 3:28 AM
Reply to this message Reply
> Here is an article that fleshes out the idea mentioned
> above, of each object having a collection of the things it
> aggregates:
> http://www-106.ibm.com/developerworks/webservices/library/w
> -tip-objrel4/

It looks like the choice is between imitating the DB by using an Ownership class to model the relationship between people and property. I think this would only be useful if the Onwership class contained extra information such as price paid, start and end dates, etc.

The alternative is the way suggested in the article above but this has the disadvantage of very close coupling between the two classes.

Calling in propietary libraries to deal with a generic problem seems like overkill.

Ringing in my ears is the constant refrain of "Keep it simple". I can see that the coupled-classes solution might be simpler in the short term but that it would lead to more work if (when) later use-cases required the existence of a detailed ownership class.

Vince.

Joe Parks

Posts: 107
Nickname: joeparks
Registered: Aug, 2003

Re: Modelling a Many-to-Many Relationship Posted: Oct 15, 2003 3:51 AM
Reply to this message Reply
As I understand it, the two objects are closely coupled--they contain collections of each other.

As far as Ambler's article is concerned, I think that this only goes half way. I would agree that this is the appropriate object model for the solution, but how is the state of the objects persisted? I think that was (at least partly) the original question: How do you map a many-many relationship between a database and an object model?

Depending on the deployment environment, I don't think that the sheer number of objects introduced by a useful library (including JDBC) should be an obstacle, as long as there is a clear separation of concerns. That is, for example, don't let database tables simply translate one-one into objects. And don't put persistence-related code directly in business objects. Or presentation-related code, for that matter.

Now, if you want to spend project time rolling your own application-specific data access code with straight JDBC, that's up to you.

I would suggest, though, that this (specific) argument is moot, because the Ownership object almost certainly contains its own data and behavior; it is not a true many-many relationship.

Flat View: This topic has 5 replies on 1 page
Topic: Help me for my program regarding with File listing, checking and copying Previous Topic   Next Topic Topic: Collision in games

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use