How to design many-to-many relationships in an object database?

Question

I thought it was about time to have a look at OO databases and decided to use db4o for my next little project - a small library.

Consider the following objects: Book, Category.

A Book can be in 0-n categories and a Category can be applied to 0-m Books.

My first thought is to have a joining object such as BookCatecory but after a bit of Googling I see that this is not appropriate for 'Real OO'.

So another approach (recommended by many) is to have a list in both objects: Book.categories and Category.books. One side handles the relationship: Book.addCategory adds Category to Book.categories and Book to Category.books. How to handle commits and rollbacks when 2 objects are been altered within one method call?

What are your thoughts? The second approach has obvious advantages but, for me at least, the first 'feels' right (better normed).

Answer 1

There are really only two ways I can think of to solve this problem, both of which you've mentioned. Personally, I would go with the first approach (creating a mapping object as an OO entity). This prevents you from keeping redundant information around and having to synchronize; it also means that if the association ends up having fields of its own (the date that the book was assigned to that category, let's say), they can be incorporated easily. We use this approach for a variety of associations in our system.

The OO entities would look like:

BookCategory {
 Book book
 Category category
}
Book {
 Collection <BookCategory> categories
}
Category {
 Collection <BookCategory> categories
}

Here you have to keep the relation object and the two collections in synch; however, the collections are optional in this case. Typically you could get the same information with an ORM query, something like: select b.book from BookCategory b where b.category = MyCategory

The alternative is to have a setup like:

Book {
 Collection<Category> categories
}

Category {
 Collection<Books> books
}

If your ORM/DB tool automatically maintains the associations, this is fine; otherwise, you are stuck updating both collections. (In Hibernate, one side will have the property: inverse=true on the mapping; this side is not updated, so strictly speaking it doesn't need to be maintained. This seems to me like bad practice, though.)

If you typically only access the relation one way (for example, getting all of the books in a category), you could eliminate the collection on other side; then I think you would have to work around the ORM tool and use a native query in order to access the relationship from the other direction.

We use Hibernate (a java-based Object Relational Mapping tool) on our project; the Hibernate docs are a good reference for OO/relational design problems, though you may have to spend a little time learning Hibernate to make them useful: http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#collections-ofvalues

HTH!