WebObjects 4: Inheritance in EOModeler

In a Cocoa or WebObjects application, EOModeler supports the expression of your application's model as objects and handles the details of writing a structure that EOF can use to interface with a data source. In the common case of mapping objects to relational database systems, EOModeler will:

• Map object classes to relational database tables
• Map relationships between objects to relational database joins
• Map object class inheritance to relational tables via these joins

Types of Inheritance in EOModeler

Inheritance is a powerful property in any object-oriented design, but it is still optional. First, decide whether inheritance is necessary in your implementation. Any attempt to add an object-oriented layer to non-object-oriented data sources inevitably results in a performance and complexity overhead, but by design EOF handles this transformation effectively and efficiently. EOModeler supports three types of inheritance: vertical, horizontal, and single table.

There are several considerations for selecting a type of inheritance. Each type has advantages and disadvantages. Some of the questions you should consider are:

• Are fetches directed primarily to leaf or root classes?
• How deep is the class hierarchy?
• What is the database storage cost for nulls?
• What is the likelihood of changing the model?
• Will other tools access the database?

The next three sections will concisely describe the characteristics, implementation steps, advantages and disadvantages of each EOModeler inheritance type.

Vertical Mapping

This is the most elegant of the three types, as it maps both to object-oriented concepts and to the normalized relational database structure often preferred by DBA's and data modelers. Performance issues may result from the multiple joins inherent in well normalized relational data. EOModeler represents vertically-inherited attributes in a bold oblique font in subclasses, making it easy to discern inherited properties.

Sample Output

This is an example of the SQL generated by EOModeler for an implementation of vertical mapping. The data model used in this implementation has three classes. The superclass Person has two subclasses, Employee and Customer. The SQL output was generated by the command line option -EOAdaptorSetDebugEnabled YES.

Inserting a Customer

SELECT UNIQUE FROM "PERSON";
INSERT INTO "Customer" ("Custacctno", "Id") VALUES ('Cust123', 1000001);
INSERT INTO "Person" ("Id", "Firstname", "Lastname", "Persontype")
VALUES (1000001, 'Fred', 'Foobar', 'C');
COMMIT;

Searching for an Employee with a Customer name

SELECT t0."Id", t0."Empno", t1."Firstname", t1."Lastname", t1."Persontype"
FROM "Person" t1, "Employee" t0
WHERE UPPER(t1."Lastname") LIKE 'FOOBAR%'
AND t0."Id" = t1."Id";
Inserting an Employee
SELECT UNIQUE FROM "PERSON";
INSERT INTO "Employee" ("Empno", "Id")
VALUES ('EmpNo1234', 1000002);
INSERT INTO "Person" ("Id", "Firstname", "Lastname", "Persontype")
VALUES (1000002, 'Johnny B.', 'Goode', 'E');
COMMIT;

Selecting a Person (Person.lastName = 'Foobar')

SELECT t0."Id", t0."Custacctno", t1."Firstname", t1."Lastname",

t0."Persontype" FROM "Person" t1, "Customer" t0 WHERE UPPER(t1."Lastname")
LIKE 'FOOBAR%' AND t0."Id" = t1."Id";
SELECT t0."Id", t0."Empno", t1."Firstname", t1."Lastname", t0."Persontype"
FROM "Person" t1, "Employee" t0 WHERE UPPER(t1."Lastname") LIKE 'FOOBAR%' AND
t0."Id" = t1."Id";
SELECT t0."Id", t0."Firstname", t0."Lastname" FROM "Person" t0 WHERE
UPPER(t0."Lastname") LIKE 'FOOBAR%';

Characteristics

• Each entity class has its own database table
• The model directly reflects the class hierarchy
• Superclass data will be fetched with subclass fetch
• Relational joins resolve inheritance relationships

Implementation

• Create a superclass entity with superclass attributes only
• Create subclass entities with subclass-specific attributes
• The superclass and all subclasses need a stored primary key
• Create to-one relationships from the subclasses joining on primary keys; do not set them as class attributes
• Flatten the superclass attributes into subclasses
• Set the attributes as class properties if they are class properties in superclass
• EOModeler displays attributes in bold oblique style
• Flatten superclass relationships into each subclass and set them as a class property per the superclass property
• Set superclass relationships as class properties if they are class properties in the superclass
• Set the superclass as the parent of the subclasses in the Advanced Entity Inspector
• Attributes defined in the parent appear italicized in the subclass's attribute list
• Derived attributes must have table columns
• Set the superclass as abstract if it is never instantiated
• If the superclass needs persistent storage for its attributes, then this class must have a table

Advantages

• Add subclasses at any time without affecting other parts of model
• Clean, normalized database schema
• Most closely resembles normal object-oriented inheritance

Disadvantages

• Least efficient performance
• Particularly slow for deep hierarchies and fetching from superclass

Horizontal Mapping

This is perhaps the most balanced of the three types. It provides enforcement of superclass attributes in subclasses similar to that of abstract classes or Java interfaces, but has much less performance overhead. As with vertical inheritance, EOModeler represents horizontally-inherited attributes distinctly; they are shown in a plain oblique font in subclasses.

Sample output

This is an example of the SQL generated by an implementation of horizontal inheritance. the data model used in this implementation has three classes. The superclass Person has two subclasses, Employee and Customer. The SQL output was generated by the command line option -EOAdaptorSetDebugEnabled YES.

Inserting a Customer

SELECT UNIQUE FROM "PERSON";
INSERT INTO "Customer" ("Persontype", "Custacctno", "Firstname", "Lastname", "Id")
VALUES ('C', 'cust2323', 'Sherlock', 'Holmes', 1000001);
COMMIT;

Querying for a Person (Person.personType = 'C')

This example is a bit different. A type attribute for the subclass could be added either to the superclass or the subclass. If it is added to the superclass, a person who is both an employee and a customer would be represented twice in the database. If it is added to the subclass, the person would only be in the database once. In this case, additional care must be taken so that there is no redundant information between the subclasses.

SELECT t0."Custacctno", t0."Firstname", t0."Lastname", t0."Id",
t0."Persontype" FROM "Customer" t0 WHERE (t0."Persontype" = 'C' AND
UPPER(t0."Persontype") LIKE 'C%');
SELECT t0."Empno", t0."Firstname", t0."Lastname", t0."Personid",
t0."Persontype" FROM "Employee" t0 WHERE (t0."Persontype" = 'E' AND
UPPER(t0."Persontype") LIKE 'C%');
SELECT t0."Personid" FROM "Person" t0 WHERE UPPER(t0."Persontype") LIKE 'C%';

Characteristics

• Subclasses contain all class-specific attributes, plus all superclass attributes
• The superclass can be abstract or concrete
• The superclass must have a database table if it is instantiated
• The superclass is specified as the parent entity in Advanced Entity Inspector
• The superclass acts as an abstract class specification

Implementation

• Create a superclass entity with superclass attributes
• Create subclass entities with all superclass and subclass-specific attributes
• EOModeler displays attributes in oblique style
• Set the superclass as parent of the subclasses
• Set the parent as abstract if it is never instantiated
• Flattening is not required

Advantages

• No joins required for fetch since all parent attributes are in subclass table
• More efficient than vertical mapping for deep hierarchies
• Best if only subclass fetches are required

Disadvantages

• New parent attributes must be added to every subclass
• Frequency of table changes must be balanced against frequency of fetches

Single Table Mapping

This is perhaps the easiest of the three types. It inherently enforces superclass attributes in subclasses, but has little or no performance or maintenance overhead. But it also is the least elegant solution from a data modeling and normalization perspective.

Characteristics

• All superclass attributes and all attributes of all subclasses are combined in one table
• Nulls are assigned for attributes not in a particular subclass object
• Use a class attribute for a subclass type identifier

Implementation

• Create a superclass entity and all subclass entities
• Add a type attribute to distinguish the subclasses
• In the Advanced Entity Inspector, set the superclass as parent to the subclasses
• In the Advanced Entity Inspector, create qualifiers in each of the subclasses to fetch only objects of that subclass
• The superclass may be abstract if it is never instantiated

Advantages

• Superclass objects retrieved with single fetch
• Model changes are only made on one entity

Disadvantages

• Every row in database contains columns for all subclasses' attributes
• Depending on database's null storage this can consume a lot of space
• Limitations on number of database columns can preclude using this inheritance type