Single Most Specific Type (Possible Problem)

William Kent
Database Technology Department
Hewlett-Packard Laboratories
Palo Alto, California

Nov 1993

SQL3 Discussion Paper
ANSI Number: X3H2-93-372r1
Nov. 15, 1993
Title: Single Most Specific Type (Possible Problem)
Author: William Kent

References:

1 X3H2-93-359R/ISO DBL MUN-003, (ISO-ANSI Working Draft) Database Language SQL (SQL3), Jim Melton (ed.), August 1993.

1 DISCUSSION

There are problems with the requirement that things have exactly one most specific type. This should be documented as a possible problem.

2 ACTION PROPOSED

Add the following material as a new possible problem in [1].

Single Most Specific Type

The restriction that an object cannot have more than one most specific type creates several problems.

One problem arises with the results of set operations (Subclause 9.3). Consider the type graph

        ..........
        : Person :
        ..........
           /\        
          /  \       
         /    \      
        /      \     
...........  ...........
: Student :  : Teacher :
...........  ...........
   |    \      /    |
   |     \    /     |
   |      \  /      |
   |       \/       |
   |       /\       |
   |      /  \      |
   |     /    \     |
   |    /      \    |
...........  ...........
: Intern  :  : Trainee :
...........  ...........

in which Intern and Trainee are each subtypes of both Student and Teacher.

Consider SET(Intern) UNION SET(Trainee). By the current rules, the only way to satisfy the requirement of a single most specific type is to make the result type be SET(Person). However, all the instances of the resulting union will be students, and this union should be acceptable wherever SET(Student) is required. The same holds for teachers and SET(Teacher).

Under the current rules, any situation requiring SET(Student) or SET(Teacher) cannot accept SET(Intern) UNION SET(Trainee).

Another problem concerns proliferation of subtypes. While this problem has probably been discussed before, it bears recording as a problem. There are potentially a great many types to which the same object might belong, and which have no particular relationship to each other. Examples abound: Employee, Customer, Dependent, Stockholder, Parent, Patient, Pilot, Passenger, etc. etc. etc. Since a person might be an instance of any combination of these n types, this requires approximately 2**n subtypes of the form Employee_Customer, Customer_Dependent, Employee_Customer_Dependent, and so on.

This proliferation is annoying (and time- and space-consuming) because:

There are so many of them.
They introduce no new interface, since no new members will be defined These types inherit everything from their supertypes. (In a sense, they are the converse of abstract types. These have instances but no members.)
Changing types becomes a nightmare. Instead of simply asserting that an object has become a pilot, the user has to discover the object's current most specific type (say X_Y_Z), remove the object from X_Y_Z, and insert the object in X_Y_Z_Pilot (after determining the correct name of this type, which might also have been or Pilot_X_Y_Z or X_Pilot_Y_Z and so on).
Extending the schema by introducing a new type, say Consultant, requires the introduction of 2**n new types of the form X_Y_Z_Consultant.

Supporting multiple most specific types does pose language and implementation difficulties, but they are all solvable. Not providing such support simply shifts the problems to the user. Supporting multiple most specific types would address both of these problems.