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


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


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


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:

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.