How to model a Many to many-relationship in code?

Question

Suppose I have 2 tables in a database. eg: Dog & Boss This is a many to many relationship, cause a boss can have more than 1 dog, and a dog can have more than 1 owner. I am the owner of Bobby, but so is my wife.

But many to many is not allowed, so there is a helpertable: DogsPerBoss

How to model this in code?

Class Boss can have a collection of Dogs. Class Dog can have a collection of Bosses. --> at least, that is what I think. Perhaps there are better solutions?

How about extra data that is in the helper-table? Should that be in de Boss-class or in the Dog-class? eg: Nickname (I call the dog "good boy" and my wife calls him "doggie")

I hope my question is kinda clear? Are there any best-practices on what is the best way to achieve this? Can you give me some references?

An ORM (like NHibernate) is not an option.

Answer 1

If you didn't need to record the nickname, then Dog should have a list of Bosses and Boss should have a list of Dogs.

If the relationship between Dog and Boss has attributes, in this case nickname, then you should create a class to represent that relationship and have Dog and Boss both hold lists of that type.

I've been using NHibernate for a while now and find it very useful for easing this sort of object relational impedance mismatch.

Answer 2

Am I missing something or is the only code you need for this as follows:

List<Bosses> BossList;

class Dog {}
class Boss { Dog[] Dogs; }

You don't need to explicitly model the two-way relationship. It's implicit in the code structure. There may be other reasons to do so, but in general it is sufficient to have a one-way reference and a way to traverse the set of referencing objects.

Answer 3

This is a classic issue between databases where many to many doesn't work, hence your helper table, and the object world where many to many works fine. As soon as the relationship has attributes then you should create a new class to hold that information. However, you'll save yourself a lot of head time if you look at Object Relation Mapping - ORM - that whole field grew up to solve this (and many other) problems between DB and Object.

Answer 4

the traditional many to many relation would have no extra fields on the matching table.

Because you do have fields with unique information I tend to stop thinking of these relations as many to many.

Once you add information to the matching table i think you have then made this table into an entity in its own right and so needs its own object to represent it.

At this point you can begin to have a DogsName class to connect a person and a dog - both of which would contain references to this object as part of a collection.

However whether you give the dog a name to be called by or own the dog are independant.

As well as modelling the relation of dogs name according to different people you also need to model the ownership relationships. In memory this would mean both objects contain a list of the other objects.

Answer 5

In a relational model, the best way to model a many to many relationship (using your example of Dogs/Bosses) is to have three separate tables.

One table for DOGS, one table for BOSSES (and each of these tables has a unique key), and the third table is usually a "junction table".

This table will usually have at least two fields, one field for the foreign key for a Dog and the other field for the foreign key of a Boss. This way each Dog can have many bosses, and each Boss can have many Dogs.

Now, when it come to modeling this in code in a more object-oriented manner, this is usually achieved by having a Dog class and a Boss class. As well as having the usual atomic properties for each of these objects, each one would also expose a property that is a collection of the other.

So, for example, a Dog object would have a property called "Bosses". This property would expose a collection of Boss objects that are allocated to the specific Dog object (as defined in the junction table), and on the other side, each Boss object would expose a property called Dogs which would be a collection of Dog objects allocated to that specific Boss object (as defined by the junction table).

Note that there may well be some "overlap" in these objects (i.e. one "dog" object may have "boss" objects that another "dog" object has), however, this is the traditional mechanism for translating a three-table many-to-many relational model into an object oriented one.

Answer 6

I guess am missing something. Why is many to many not allowed?

public class Boss
{
    Dog[] dogs;
}

public class Dog
{
    Boss[] bosses;
}