How can I map several one-to-many relations to a single entity? For instance, consider you have entities Person and Account (there are no subtypes of account). Each account belongs to a single person. A person can have several accounts, but they may play different roles. E.g., a person can have n private accounts and n business accounts.

The Java code looks quite straightforward:



How can I map such a situation, where I have two 1-n relations to the same class?

Nobody an idea?

what is the problem ? It is an assocation like anything else (you might need a 'where' limitation to distinguish them if they are in the same table)

Sorry, I have the same problem and I can't follow your "what is the problem". The problem is 1) if the class Person is loaded by Hibernate, it has to look into the Account table chasing the foreign keys for the Person. But how can it decide which Account goes to 'privateAccounts' and which goes to 'businessAccounts'?

2) if I map this example with annotations, i would do it like this:
in class Person:
@OneToMany(mappedBy = "person)
List<Account>privateAccounts;
@OneToMany(mappedBy = "person)
List<Account> businessAccounts;

and in class Account i would have:
@ManyToOne
private Person person;

So, the two different roles would be mapped by the same property! I cannot image how Hibernate can distinguish in this situation.

My thoughts now go to model the different roles as different subclasses. But this would be just artificiell, just caused by a mapping problem.

Is there a solution? Or do I miss something in my understanding of Hibernate/JPA mappings?

Carlo

Look at it from the other perspective. How would you model this using a relational database? For example:

Table Person
Id Primary Key

Table Account
AccountId
AccountHolderId FK referencing Person
AccountType

So here we use an account type column to distinguish between Private and Business accounts. Obviously this is a prime candidate for an entity hierarchy with AccountType as the discriminator. You then use:
List<PrivateAccount> privateAccounts
List<BusinessAccount> businessAccounts
in your Person entity.

IMO very logical, nothing artifical about such a model.

It gets slightly more complicated if you need to model multiple account holders. You then need to use intermediate tables for a many-to-many mapping:

Table Person
Id Primary Key

Table Account
Account Id
AccountType

Table AccountHolders
AccountId FK referencing Account
PersonId FK referencing Person
Primary Key (AccountId, PersonId)

But the basic idea to have a structure like
public abstract Account ...
public PrivateAccount extends Account ...
public BusinessAccount extends Account ...
remains.

Logical if we are from the relational background. Though the OP's problem is more 'natural' for people without the normal forms hammered into their head. In other words, I would have the same question. since we are talking about a more 'tree' like model(as otherwise, why don't I just go back to my nth normal form strict SQL instead of inserting yet another layer ORM), I would also like to know the answer.

EDIT:

I think the mappedby has to be dropped and the reverse ManyToOne also needs to be dropped. A natural design like this can only do uni-directional(from person to account).