Inheritance

1. An object-oriented database schema typically requires a large number of classes. Often, however, several classes are similar. For example, bank employees are similar to customers.
2. In order to allow the direct representation of similarities among classes, we need to place classes in a specialization hierarchy. E.g., Fig. 8.1 is a specialization hierarchy for the ER model.

    
   Figure 8.1:   Specialization hierarchy for the banking example
   

   The concept of a class hierarchy is similar to that of specialization in the ER model. The corresponding corresponding class hierarchy is shown in Fig. 8.2.

    
   Figure 8.2:   Class hierarchy corresponding to the banking example
   

   The class hierarchy can be defined in pseudo-code in Fig. 8.3, in which the variables associated with each class are as follows. For brevity, we do not present the methods associated with these classes.

    
   Figure 8.3:   Definition of class hierarchy in pseudo-code
   

3. The keyword isa is used to indicate that a class is a specialization of another class. The specialization of a class are called subclasses. E.g., employee is a subclass of person; teller is a subclass of employee. Conversely, employee is a superclass of teller.
4. Class hierarchy and inheritance of properties from more general classes. E.g., an object representing an officer contains all the variables of classes officer, employee, and person. Methods are inherited in a manner identical to inheritance of variables.
5. An important benefit of inheritance in OO systems is the notion of substitutability: Any method of a class, A, can be equally well be invoked with an object belonging to any subclass B of A. This characteristic leads to code-reuse: methods and functions in class A (such as get-name() in class person) do not have to be rewritten again for objects of class B).
6. Two plausible ways of associating objects with nonleaf classes:
   • associate with the employee class all employee objects including those that are instances of officer, teller, and secretary.
   • associate with the employee class only those employee objects that are instances neither officer, nor teller, nor secretary.

   Typically, the latter choice is made in OO systems. It is possible to determine the set of all employee objects in this case by taking the union of those objects associated with all classes in the subtree rooted at employee.

7. Most OO systems allow specialization to be partial, i.e., they allow objects that belong to a class such as employee that do not belong to any of that class's subclasses.