Quote:
the Many-To-One (which I think I need to use) definition really seems like a misnomer to me.
I think you may be interpreting the term many-to-one incorrectly. In object terminology, this always refers to multiplicity. So it describes an association relationship between to objects, where one side of the association has many instances of a given type, and the other side has one instance of another type:
Code:
[ Payment ]-- * ----------- 1 -->[ PaymentType ]
This terms does not describe turning multiple tables into a single class, such as you desire to create in your example of user parts. To do this I think you may do best with joined subclasses. I think you will need one subclass per table type. This could be your hierarchy:
Code:
User
UserProfile
UserAccount
But in my opinion, you may do better with the following class composition:
Code:
User
UserProfile
UserAccount
I suggest this because profile information has little to do with a finanical account, really. But since your example may simply be abstract, the first hierarchy would give you what you are trying to do.
Just a suggestion. I hope I have not misunderstood your question.
Vaughn