Hibernate Inheritance Mapping Strategies

There is much more than plain association mappings in hibernate to study. Few uncommon things can be understood from hibernate documentation. The association mappings were bringing flavors of database relations to the mapping and objects, but this, inheritance mapping, takes the object oriented concept to the database through this mapping style. I am not going to explain inheritance here. Just recall the implements/extends key words, which, in broader terms mean inheritance. You have a parent class and many children extending from it. In out example, we have a customer, this customer can purchase a telephone product, or an internet product, or a mobile product. This should be enough to brand the customer as telephony-customer, internet-customer and mobile-customer. We want to deal with these three types of customers in Java, mapping and in database. There can be multiple ways to handle persistence and retrieval of these entities. Hibernate supports following three strategies to get this working. This will tell us how the data will be persisted in these strategies.

• Table per class hierarchy

• Table per sub class

• Table per concrete class

There is one more which is implicit polymorphism. Refer hibernate documentation for this.

Table per Class Hierarchy:

In this strategy, everything goes in one table, and we differentiate our customers based on a column value, which is called as discriminator in hibernate terms. Thus the TAB_CUSTOMER will contain columns required to all telephony, internet and mobile customers, in addition to this we will have a column CUSTOMER_TYPE to differentiate the customers. Off course, the attributes common across all will also be there.

TAB_CUSTOMER
 CUSTOMER_ID
 CUSTOMER_NAME
 TELEPHONE_NUMBER
 INTERNET_CONNECTION_TYPE
 MOBILE_CONNECTION_TYPE
 CUSTOMER_TYPE

By now you must have understood that in case of each type of customer, few columns will be null and you need to define them null able in table schema definition. This is how the mapping would be -

 

 
  
 
 
 
...
 
  
 ...
 
 
 ...
 
 
 ...
 

The discriminator value is your choice. I kept it to one letter, you can have anything. Just define the relevant column also of that data type. We would be having these three Java classes TelephonyCustomer, InternetCustomer, and MobileCustomer, all implementing Customer interface.

Table per sub-class:

Instead of one table in above strategy, here we would need one table for each type of customer and one parent table, so in all four tables. The common columns in our example, CUSTOMER_ID and CUSTOMER_NAME would go in the parent/super TAB_CUSTOMER, while specific columns e.g. TELEPHONE_NUMBER, INTERNET_CONNECTION_TYPE will be in respective tables. Also, the child table will link to parent table using reference to primary key of parent, thus, CUSTOMER_ID will be duplicated in each table though foreign key reference to TAB_CUSTOMER. This makes the mapping simply – one to one mapping.

...



...



...



...

Mind you, the parent would be an abstract class here, i.e. all three classes will extend from the abstract customer class.

Table per Concrete Class:

Here the table count will be reduced to three, as we won’t have table for the abstract class. This means we have to duplicate the common columns (CUSTOMER_ID, CUSTOMER_NAME) in each of the tables. Just that the mapping will handle this duplication differently. Union-subclass will be used to define mapping in this scenario.

...


...


...


...

Advantages and Disadvantages of Strategies:

• Ad hoc reporting/querying would be easy in Table per hierarchy and Table per concrete class strategy

• Table per sub class is close to object oriented concepts.

• Table per sub class, table per class hierarchy, table per concrete class is the order in which polymorphism support goes on decreasing.

• Table per class hierarchy requires few columns to be null-able, this might not allow to add constraints to the columns. Also the table space size would be high.

• Table per sub class would end up creating too many tables in database.

• Table per concrete class leads to data duplication, i.e. common attributes are duplicated in each table.