I am trying to map a legacy database. I have a Person table that needs to be broken up into a hierarchy with Person as the base class and Patient, Doctor as subclasses that inherit from Person. The problem is that it is possible for a Patient to also be a Doctor. I have tried using a discriminator column, but that doesn't work if the column can't just be a 1 for Patient and 2 for Doctor because it could also be a 3 for Patient and Doctor:



The Person table has columns IsPatient and IsDoctor, and I added a computed column to act as the discriminator column that gives me a 1, 2 or 3 depending on the values in the IsPatient and IsDoctor columns.

My question: is there a standard practice for how this is done? All of the data for the Person class/interface, Doctor class, and the Patient class comes from the Person table and I need to map it into a hierarchy. I can't use a simple discriminator to tell me if it's a Patient or if it's a Provider, because I want to be able to do an HQL query to retrieve Providers, but, that would only return the ones that are Providers and not also a Patient. Any help here?

The answer to your question depends of the way your classes are hierarchized; I know that Person is the base class and that Patient and Doctor inherit from Person. But when you say that a Patient to also be a Doctor, how is it done ? If you have a class PatientAndDoctor that inherit from Patient and Doctor, then you can map it with discriminator-value="3" :)

* Are you sure that you should use <subclass>? (because it is for table-per-subclass strategy). <joined-subclass> is for table-per-hierarchy (like your example seems to show) :idea:

* Your columns IsPatient and IsDoctor are useless if you have EntityRole

* I can't use a simple discriminator to tell me if it's a Patient or if it's a Provider ???

Get rid of Patient. Any Person (employees, retirees, Doctors, etc.) is a potential patient anyhow. Doctor is a subclass of Person.

Of course, this could leave out other details of your environment.


The most important thing to remember when working with any ORM and a legacy DB is that you cannot cleanly map relationships that don't exist. The Relational model is not a 1:1 map to the OO world. Inheritance does not exist in the Relational world. If you are designing the schema with OO in mind, it can be simulated. However, if you're working with a legacy DB, don't force it.

You know what. I've come to a different conclusion.

What you have is an improper OO design, despite the fact that it's a lot like the canonical Person/Employee or Dog/Labrador example we were all taught in school. Doctor/Patient/Person is not an inheritence relationship, which is why you're having trouble modeling it as such.

Instead, you are dealing with 100% Person objects and Person either has an IsDoctor flag or IsInRole(Roles.Doctor) method.

Likewise with IsPatient, but IsPatient() may be a method which queries whether or not they have ever had any appointments.

If you model Doctor as a sublcass of Person, what happens when...

Patient J. Smith has an appointment with Dr. B. Coole.
Dr. B. Coole later loses his medical license and is no longer a Doctor.
Someone looks up the appointment history of J. Smith.
Your code tries


And *poof*! your app is borken.

Thanks for the replies. I am excited to have a community to help me think about the relationships that I'm trying to model and to be able to leverage your experience.:D

First, let me respond to the issue of the OO design. My approach in the past has come from a database perspective (my experience/positions have dictated such), but, that creates issues for the non-database developers because the objects end up looking funny. I agree with rponton's conclusion not to get rid of the Patient class. If I were an the customer (developer) to use these classes, what would I want them to look like. Forget about the database and what should the hierarchy look like and what should the classes act like? The answer is easy because I have other developers telling me what they don't want the classes to look like. So, we keep the hierarchy of Patient and Doctor inherit from Person.

This also brings us to the conclusion that there shouldn't be a PatientAndDoctor class. It's just not right logically. So, the suggestion to map it with Discriminator-value="3" is not going to work.

Sorry to shoot down those ideas, but, I think what I have come up with seems to be similar to KPixel's suggestion about trying to use <joined-subclass> (I don't think I see how I could implement this though). So, what I have done is map the Person object as it was before. What I changed is I mapped all of the properties for a Person directly onto the Patient and Doctor classes.


The only problem with this method is that I have to explicitly map the IsPatient property and explicitly set this property in my code before saving the object out. But, now I can do queries like "from Patient" and it automatically hydrates the parent class Person. It works, but, there's got to be a better way. :?:

Is there a way to do it with the <joined-subclass> even though the entire hierarchy comes from the same table?

I still think you're taking the wrong approach to the issue.

The problem is not DB vs. OO. The problem is that it's a bad OO design. You're using Inhertiance to represent Roles. And golly gee, you're running into problems modeling what happens when people have multiple roles or when they gain or lose roles.

This is not an inheritance relationship. This is a roles relationship.