Union and Vertical Mapping of Classes
Meet the challenge of impedance mismatch with object to relational mapping. Part 2 looks at union and vertical mapping as best practice approaches
by Richard Jensen
Posted May 5, 2004
Editor's Note: This is Part 2 of a two-part article on best practices for object to relational mapping. Part 1, "Mapping Classes to Relational Tables" (Java Pro Online, April 28, 2004), provided an overview of the necessity to overcome the challenge of impedance mismatch between object-oriented and relational data and of using the horizontal mapping approach. Part 2 looks at the union and vertical mapping approaches and provides examples of both.
While horizontal mapping requires duplicating columns representing base class attributes in the database tables to which leaf classes map, union mapping (sometimes called filtered mapping or typed mapping) offers a way to eliminate this redundancy. Union mapping allows multiple classes within an inheritance hierarchy to share a common table and thus reuse columns representing the common data. The term "union mapping" refers to the fact that the attributes in the table represent the union of the object attributes for objects that are mapped to that table.
For the Employee hierarchy within the previous object model (see"Mapping Classes to Relational Tables," Java Pro Online, April 28, 2004), a union mapping stores all of the concrete classes in one table by sharing the name, dob, hiredate, and ssn columns (see Table 1). Supporting the PartTime and FullTime classes requires adding a payrate column, and supporting the Exempt and Manager classes requires adding a salary column.
The complication with a union inheritance mapping is that the data layer has no way of knowing how to instantiate certain closely related classes. For example, with the sample table structure described previously, there is no way of knowing whether the NonExempt data (those with a NULL salary column) is for a full or part-time employee, or whether the Exempt data (those with a NULL payrate column) is for a manager.
To determine the type of object to which a row will map, a union inheritance mapping must introduce a distinguishing "class type code" value. The added "code" column illustrates this approach, where all rows in the table with a value of F in the code column map to a FullTime instance, and the P code column values map to a PartTime instance (see Table 2).
Two Union Tables
There are times when it makes sense to partition a set of related classes across more than one union table. For example, the Employee hierarchy could be mapped to two tables by storing the NonExempt types in one union table and the Exempt types in another union table. Figure 1 illustrates this mapping approach.
With union mapping, there is some extra complexity associated in determining how to map each row to a particular class. However, this approach produces very compact database schemes, with all the data associated with a certain column in one table, as opposed to spreading similar data across multiple tables as in the vertical inheritance mapping. There are several benefits of a union inheritance mapping scheme, including more efficient queries at the superclass level and more elegant database schema, that is, fewer overall tables to manage.
Again, however, there are limitations to the union inheritance. It's a more complex coding effort, particularly for a hand-coded data mapping layer, and the time required to implement features such as type codes may be significant. And there may not be a match for underlying table structures: for legacy tables, union mapping may not fit the existing table layouts. In addition, it may not be possible to add the type code column to facilitate the mapping.
These snippets demonstrate the SQL portion of the mapping code for creating, reading, updating, removing, and retrieving persistent data (with the example object model mapped to a single database table). To create the database row corresponding to a new PartTime employee object, we insert one row into the CodedEmp table:
insert into CodedEmp name, code,
dob, hiredate, ssn, payrate
values ("Elijah Banks", 'P',
Back to top