• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The best 'Many to Many' approach?

 
Andles Jurgen
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is it best to model all many-to-many relationships using 2 one-to-many relationships either side? (which I like, very simple to set up)

I am reading 'Hibernate In Action' and I am struggling to make much sense of the more 'exotic' many-to-many mapping options - the book seems to suggest avoiding these more 'exotic' options. Just wondering, what is the point of the other alternatives to 2 one-to-many mappings? What do you gain with them?

TIA
 
Thomas Whitmore
Ranch Hand
Posts: 33
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Andles,

Interesting question. We use JDO but the same fundamental logic applies.

Businesses and business systems require responsibility for actions and data, and normally designate this in a heirarchical structure.

This means that most of the first-class entities with which a business deals primarily, will be structured with 1-many rather than many-many relationships.

Exceptions to this are relatively infrequent in business modelling. Route planning and multiple transport or connection paths is the one which springs to mind. This would be used where eg transport connections needed to be modelled, but there was no 1st-class need of management, responsibility or other data; just a reference to the opposite end.

(Actually most distribution or logistics applications are immediately going to want costs or congestion-delay data on their connections. This would require this to be promoted to a 1st-class entity anyway, obviating the many-many relationship).

Hope this helps.


Regards,
Thomas
www.powermapjdo.com
 
Loren Rosen
Ranch Hand
Posts: 156
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are basically 3 ways to deal with many-to-many mappings in Hibernate.

In all of them you end up with the same structure in the database: an association table that manages the many-to-many relation.

One approach is to make the association table implicit (hidden from the Java code). This is done via the <many-to-many> tags.

But an interesting thing happens to real-world many-to-many relations. I can best show this via an example. Think about airline passengers and airplane flights. A flight takes many passengers and a passenger can take many flights, so this is a many-to-many relationship. But the relationship has its own properties. For each passenger-flight pair, we want to know if a ticket has been issues, whether it has been paid for, etc. In fact the passenger-flight pair has its own name: it's a "reservation". In other words, the many-to-many relationship breaks down into two many-to-one relationships: passenger-reservation and flight-reservation. Then the data about whether the reservation has been paid for, etc. has a natural place to live.

So using a pair of many-to-relations is not only easier to understand, it may in fact be essential once you start adding real-world features to your model.

Finally, about ternary relations. Suppose we also want the reservation to reference the travel agent through which the reservation was made. So we add a reservation-agent relationship. From a broader prospective, we have a ternary relationship between passenger, flight, and agent, which is mediated by reservation.

The bottom line is to go ahead and use pairs of many-to-one relations.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to echo Loren's point, in the sixteen years I've been writing database applications, I have never not needed to add properties to the relation itself. In other words, I've used a pair of one-to-many relationships in every case.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic