Union and Vertical Mapping of Classes (Continued)

To instantiate a FullTime employee object, we need to read from four tables and join them on the common key value:

select p.name, p.dob, 
  e.hiredate, e.ssn, ne.payrate 
  from PersonPart p, 
  EmployeePart e, NonExemptPart 
  ne,
  FullTimePart ft
  where name = 'Sarah Jackson'
  and p.name = e.name and 
  p.name = ne.name
  and p.name = ft.name

Similarly we can update an Exempt employee by writing to multiple tables:

update PersonPart set dob=
  "06/30/1962"
  where name = 'Nicky Colson'
update EmployeePart set 
  hiredate="06/15/1997",
  set ssn="567-89-0123"
  where name = 'Nicky Colson'
update NonExemptPart 
  set salary = 52000.00
  where name = 'Nicky Colson'

To delete an object:

delete from ManagerPart where 
  name = 'Susan Jekel'
delete from ExemptPart where 
  name = 'Susan Jekel'
delete from EmployeePart where 
  name = 'Susan Jekel'
delete from PersonPart where 
  name = 'Susan Jekel'

To find employees hired since 01/01/1998, we need to perform the query (through joins) for each of the concrete classes and return the combined results (see Listing 1).

The design of the O/R mapping layer is crucial for system development where efficient data access is a prime concern. Database optimization and object-oriented design often have conflicting requirements. O/R mapping flexibility offers developers the ability to make the appropriate trade-offs and still achieve performance objectives. It is also possible to use combinations of the different mapping strategies in the same application, or to use hybrids of the three strategies discussed here.

When considering different mapping options, remember the primary benefits of each: the horizontal inheritance is easiest to code, the union inheritance provides best query performance, and the vertical inheritance provides the most flexible legacy mapping.

A well-designed object model and carefully chosen mapping strategy provide a robust foundation for enterprise applications. However, after these high-level decisions are made, developers encounter another challenge. As shown by the examples discussed here, hand coding the data access layer is time consuming. The resulting code can be difficult to maintain, especially when changes occur—as they inevitably will—to the data model and the database schema. An O/R mapping tool that automatically generates the data access layer can pay for itself in productivity savings alone. Look for a tool that offers flexibility for choosing an optimal mapping strategy.

About the Author
Richard Jensen is a senior architect at Persistence Software.