A new subtype may be introduced by specialization whenever new features of more specific types of objects have to be captured. We illustrate this for our example model where we want to capture text books and biographies as special cases of books. This means that text books and biographies also have an ISBN, a title and a publishing year, but in addition they have further features such as the attribute subjectArea for text books and the attribute about for biographies. Consequently, we introduce the object types TextBook and Biography by specializing the object type Book, that is, as subtypes of Book.

Figure 1.1. The object type Book with two subtypes: TextBook and Biography

When specializing an object type, we define additional features for the newly added subtype. In many cases, these additional features are more specific properties. For instance, in the case of TextBook specializing Book, we define the additional attribute subjectArea. In some programming languages, such as in Java, it is therefore said that the subtype extends the supertype.

However, we can also specialize an object type without defining additional properties (or operations/methods), but by defining additional constraints.

We illustrate generalization with the following example, which extends the information model of Part 4 by adding the object type Employee and associating employees with publishers.

Figure 1.2. The object types Employee and Author share several attributes

After adding the object type Employee we notice that Employee and Author share a number of attributes due to the fact that both employees and authors are people, and being an employee as well as being an author are roles played by people. So, we may generalize these two object types by adding a joint supertype Person, as shown in the following diagram.

Figure 1.3. The object types Employee and Author have been generalized by adding the common supertype Person

When generalizing two or more object types, we move (and centralize) a set of features shared by them in the newly added supertype. In the case of Employee and Author, this set of shared features consists of the attributes name, dateOfBirth and dateOfDeath. In general, shared features may include attributes, associations and constraints.

Notice that since in an information design model, each top-level class needs to have a standard identifier, in the new class Person we have declared the standard identifier attribute personId, which is inherited by all subclasses. Therefore, we have to reconsider the attributes that had been declared to be standard identifiers in the subclasses before the generalization. In the case of Employee, we had declared the attribute employeeNo as a standard identifier. Since the employee number is an important business information item, we have to keep this attribute, even if it is no longer the standard identifier. Because it is still an alternative identifier (a "key"), we define a uniqueness constraint for it with the constraint keyword key.

In the case of Author, we had declared the attribute authorId as a standard identifier. Assuming that this attribute represents a purely technical, rather than business, information item, we dropped it, since it's no longer needed as an identifier for authors. Consequently, we end up with a model which allows to identify employees either by their employee number or by their personId value, and to identify authors by their personId value.

We consider the following extension of our original example model, shown in Figure 1.4, where we have added two class hierarchies:

Figure 1.4. The complete class model containing two inheritance hierarchies

The intension of an object type is given by the set of its features, including attributes, associations, constraints and operations.

The extension of an object type is the set of all objects instantiating the object type. The extension of an object type is also called its population.

We have the following duality: while all features of a supertype are included in the intensions, or feature sets, of its subtypes (intensional inclusion), all instances of a subtype are included in the extensions, or instance sets, of its supertypes (extensional inclusion). This formal structure has been investigated in formal concept analysis.

Due to the intension/extension duality we can specialize a given type in two different ways:

Typical OO programming languages, such as Java and C#, only support the first possibility (specializing a given type by extending its intension), while XML Schema and SQL99 also support the second possibility (specializing a given type by restricting its extension).

A type hierarchy (or class hierarchy) consists of two or more types, one of them being the root (or top-level) type, and all others having at least one direct supertype. When all non-root types have a unique direct supertype, the type hierarchy is a single-inheritance hierarchy, otherwise it's a multiple-inheritance hierarchy. For instance, in Figure 1.5 below, the class Vehicle is the root of a single-inheritance hierarchy, while Figure 1.6 shows an example of a multiple-inheritance hierarchy, due to the fact that AmphibianVehicle has two direct superclasses: LandVehicle and WaterVehicle.

Figure 1.5. A class hierarchy having the root class Vehicle

The simplest case of a class hierarchy, which has only one level of subtyping, is called a generalization set in UML, but may be more naturally called segmentation. A segmentation is complete, if the union of all subclass extensions is equal to the extension of the superclass (or, in other words, if all instances of the superclass instantiate some subclass). A segmentation is disjoint, if all subclasses are pairwise disjoint (or, in other words, if no instance of the superclass instantiates more than one subclass). Otherwise, it is called overlapping. A complete and disjoint segmentation is a partition.

Figure 1.6. A multiple inheritance hierarchy

In a class diagram, we can express these constraints by annotating the shared generalization arrow with the keywords complete and disjoint enclosed in braces. For instance, the annotation of a segmentation with {complete, disjoint} indicates that it is a partition. By default, whenever a segmentation does not have any annotation, like the segmentation of Vehicle into LandVehicle and WaterVehicle in Figure 1.6 above, it is {incomplete, overlapping}.

An information model may contain any number of class hierarchies.

Consider the simple class hierarchy of the design model in Figure 1.1 above, showing a disjoint segmentation of the class Book. In such a case, whenever there is only one level (or there are only a few levels) of subtyping and each subtype has only one (or a few) additional properties, it's an option to re-factor the class model by merging all the additional properties of all subclasses into an expanded version of the root class such that these subclasses can be dropped from the model, leading to a simplified model.

This Class Hierarchy Merge design pattern comes in two forms. In its simplest form, the segmentations of the original class hierarchy are disjoint, which allows to use a single-valued category attribute for representing the specific category of each instance of the root class corresponding to the unique subclass instantiated by it. When the segmentations of the original class hierarchy are not disjoint, that is, when at least one of them is overlapping, we need to use a multi-valued category attribute for representing the set of types instantiated by an object. In this tutorial, we only discuss the simpler case of Class Hierarchy Merge re-factoring for disjoint segmentations, where we take the following re-factoring steps:

In the case of our example, the result of this design re-factoring is shown in Figure 1.7 below. Notice that the constraint (or "invariant") represents a logical sentence where the logical operator keyword "IFF" stands for the logical equivalence operator "if and only if" and the property condition prop=undefined tests if the property prop does not have a value.

Figure 1.7. The design model resulting from applying the Class Hierarchy Merge design pattern

Subtyping and inheritance have been supported in Object-Oriented Programming (OOP), in database languages (such as SQL99), in the XML schema definition language XML Schema, and in other computational languages, in various ways and to different degrees. At its core, subtyping in computational languages is about defining type hierarchies and the inheritance of features: mainly properties and methods in OOP; table columns and constraints in SQL99; elements, attributes and constraints in XML Schema.

In general, it is desirable to have support for multiple classification and multiple inheritance in type hierarchies. Both language features are closely related and are considered to be advanced features, which may not be needed in many applications or can be dealt with by using workarounds.

Multiple classification means that an object has more than one direct type. This is mainly the case when an object plays multiple roles at the same time, and therefore directly instantiates multiple classes defining these roles. Multiple inheritance is typically also related to role classes. For instance, a student assistant is a person playing both the role of a student and the role of an academic staff member, so a corresponding OOP class StudentAssistant inherits from both role classes Student and AcademicStaffMember. In a similar way, in our example model above, an AmphibianVehicle inherits from both role classes LandVehicle and WaterVehicle.

6.2. Subtyping and Inheritance with Database Tables

A standard DBMS stores information (objects) in the rows of tables, which have been conceived as set-theoretic relations in classical relational database systems. The relational database language SQL is used for defining, populating, updating and querying such databases. But there are also simpler data storage techniques that allow to store data in the form of table rows, but do not support SQL. In particular, key-value storage systems, such as JavaScript's Local Storage API, allow storing a serialization of a JSON table (a map of records) as the string value associated with the table name as a key.

While in the classical, and still dominating, version of SQL (SQL92) there is no support for subtyping and inheritance, this has been changed in SQL99. However, the subtyping-related language elements of SQL99 have only been implemented in some DBMS, for instance in the open source DBMS PostgreSQL. As a consequence, for making a design model that can be implemented with various frameworks using various SQL DBMSs (including weaker technologies such as MySQL and SQLite), we cannot use the SQL99 features for subtyping, but have to model inheritance hierarchies in database design models by means of plain tables and foreign key dependencies. This mapping from class hierarchies to relational tables (and back) is the business of Object-Relational-Mapping frameworks such as Hibernate (or any other JPA Provider) or the Active Record approach of the Rails framework.

There are essentially two alternative approaches how to represent a class hierarchy with relational tables:

1. Single Table Inheritance is the simplest approach, where the entire class hierarchy is represented with a single table, containing columns for all attributes of the root class and of all its subclasses, and named after the name of the root class.

2. Joined Tables Inheritance is a more logical approach, where each subclass is represented by a corresponding subtable connected to the supertable via its primary key referencing the primary key of the supertable.

Notice that the Single Table Inheritance approach is closely related to the Class Hierarchy Merge design pattern discussed in Section 5 above. Whenever this design pattern has already been applied in the design model, or the design model has already been re-factored according to this design pattern, the class hierarchies concerned (their subclasses) have been eliminated in the design, and consequently also in the data model to be coded in the form of class definitions in the app's model layer, so there is no need anymore to map class hierarchies to database tables. Otherwise, when the Class Hierarchy Merge design pattern does not get applied, we would get a corresponding class hierarchy in the app's model layer, and we would have to map it to database tables with the help of the Single Table Inheritance approach.

We illustrate both the Single Table Inheritance approach and the Joined Tables Inheritance with the help of two simple examples. The first example is the Book class hierarchy, which is shown in Figure 1.1 above. The second example is the class hierarchy of the Person roles Employee, Manager and Author, shown in the class diagram in Figure 1.8 below.

Figure 1.8. A class model with a Person roles hierarchy

6.2.1. Single Table Inheritance

Consider the single-level class hierarchy shown in Figure 1.1 above, which is an incomplete disjoint segmentation of the class Book, as the design for the model classes of an MVC app. In such a case, whenever we have a model class hierarchy with only one level (or only a few levels) of subtyping and each subtype has only one (or a few) additional properties, it's preferable to use Single Table Inheritance, so we model a single table containing columns for all attributes such that the columns representing additional attributes of subclasses are optional, as shown in the SQL table model in Figure 1.9 below.

Figure 1.9. An SQL table model with a single table representing the Book class hierarchy

Notice that it is good practice to add a special discriminator column for representing the category of each row corresponding to the subclass instantiated by the represented object. Such a column would normally be string-valued, but constrained to one of the names of the subclasses. If the DBMS supports enumerations, it could also be enumeration-valued. We use the name category for the discriminator column.

Based on the category of a book, we have to enforce that if and only if it is "TextBook", its attribute subjectArea has a value, and if and only if it is "Biography", its attribute about has a value. This implied constraint is expressed in the invariant box attached to the Book table class in the class diagram above, where the logical operator keyword "IFF" represents the logical equivalence operator "if and only if". It needs to be implemented in the database, e.g., with an SQL table CHECK clause or with SQL triggers.

Consider the class hierarchy shown in Figure 1.8 above. With only three additional attributes defined in the subclasses Employee, Manager and Author, this class hierarchy could again be implemented with the Single Table Inheritance approach. In the SQL table model, we can express this as shown in Figure 1.10 below.

Figure 1.10. An SQL table model with a single table representing the Person roles hierarchy

In the case of a multi-level class hierarchy where the subclasses have little in common, the Single Table Inheritance approach does not lead to a good representation.

6.2.2. Joined Tables Inheritance

In a more realistic model, the subclasses of Person shown in Figure 1.8 above would have many more attributes, so the Single Table Inheritance approach would be no longer feasible, and the Joined Tables Inheritance approach would be needed. In this approach we get the SQL data model shown in Figure 1.11 below. This SQL table model connects subtables to their supertables by defining their primary key attribute(s) to be at the same time a foreign key referencing their supertable. Notice that foreign keys are visuallized in the form of UML dependency arrows stereotyped with «fkey» and annotated at their source table side with the name of the foreign key column.

Figure 1.11. An SQL table model with the table Person as the root of a table hierarchy

The main disadvantage of the Joined Tables Inheritance approach is that for querying any subclass join queries are required, which may create a performance problem.

Java provides built-in support for subtyping with its extends keyword, but it does not support multiple inheritance. Consider the information design model shown in Figure 2.1 below.

Figure 2.1. Student is a subclass of Person

First we define the superclass Person. Then, we define the subclass Student and its subtype relationship to Person by means of the extends keyword:

public class Person {
  private String firstName;
  private String lastName;
  ...
}
public class Student extends Person {
  private int studentNo;

  public Student( String first, String last, int studNo) {
    super( firstName, lastName);
    this.setStudNo( studNo);
  }
  ...
}

Notice that in the Student class, we define a constructor with all the parameters required to create an instance of Student. In this subclass constructor we use super to invoke the constructor of the superclass Person.

In this example we implement the Book hierarchy shown in Figure 1.1. The Java Entity class model is derived from this design model.

2.1. Make the Java Entity class model

We make the Java Entity class model in 3 steps:

1. For every class in the model, we create a Java Entity class with the corresponding properties and add the set and get methods corresponding to each property.

2. Turn the plaform-independent datatypes (defined as the ranges of attributes) into Java datatypes.

3. Add the set and get methods corresponding to each direct property of every class in the hierarchy (subclasses must not define set and get method for properties in superclasses, but only for their direct properties).

This leads to the Java Entity class model shown in Figure 2.2.

Figure 2.2. The Java Entity class model

public enum BookTypeEL {
  TEXTBOOK( "TextBook"), BIOGRAPHY( "Biography");
  private final String label;

  private BookTypeEL( String label) {
    this.label = label;
  }
  public String getLabel() {return this.label;}
}

@Entity @Table( name="books")
@Inheritance( strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn( name="category", 
    discriminatorType=DiscriminatorType.STRING, length=16)
@DiscriminatorValue( value = "BOOK")
@ManagedBean( name="book") @ViewScoped
public class Book {
  @Id @Column( length=10)
  @NotNull( message="An ISBN is required!")
  @Pattern( regexp="\\b\\d{9}(\\d|X)\\b", message="The ISBN must be a ...!")
  private String isbn;
  @Column( nullable=false) @NotNull( message="A title is required!")
  private String title;
  @Column( nullable=false) @NotNull( message="A year is required!")
  @UpToNextYear
  @Min( value=1459, message="The year must not be before 1459!")
  private Integer year;
  // constructors, set, get and other methods
  ...
}

@Entity @Table( name="textbooks")
@DiscriminatorValue( value="TEXTBOOK")
@ManagedBean( name="textBook") @ViewScoped
public class TextBook extends Book {
  @Column( nullable=false) @NotNull( message="A subject area value is required")
  String subjectArea;
  // constructors, set, get and other methods
  ...
}

CREATE TABLE IF NOT EXISTS `books` (
  `ISBN` varchar(10) NOT NULL,
  `TITLE` varchar(255) NOT NULL,
  `YEAR` int(11) NOT NULL,
  `SUBJECTAREA` varchar(255) DEFAULT NULL,
  `ABOUT` varchar(255) DEFAULT NULL,
  `category` varchar(16) DEFAULT NULL,
) 

<h:dataTable value="#{bookController.books}" var="b">
  ...
  <h:column>
    <f:facet name="header">Special type</f:facet>
    #{b.getClass().getSimpleName() != 'Book' ? b.getClass().getSimpleName() : ''}
  </h:column>
</h:dataTable>

<h:panelGrid id="bookPanel" columns="3">
  ...
  <h:outputText value="Special type: " />
  <h:selectOneMenu id="bookType" value="#{viewScope.bookTypeVal}">
    <f:selectItem itemLabel="---"/>
    <f:selectItems value="#{book.typeItems}" />
    <f:ajax event="change" execute="@this" 
            render="textBookPanel biographyBookPanel standardBookPanel" />
  </h:selectOneMenu>
  <h:message for="bookType" errorClass="error" />
</h:panelGrid>

<h:panelGroup id="standardBookPanel">  
  <h:commandButton value="Create" rendered="#{viewScope.bookTypeVal == null}"
                   action="#{bookController.add( book.isbn, book.title, book.year)}" />
</h:panelGroup>
    
<h:panelGroup id="textBookPanel">  
  <h:panelGrid rendered="#{viewScope.bookTypeVal == 'TEXTBOOK'}" columns="3">
    <h:outputText value="Subject area: " />
    <h:inputText id="subjectArea" value="#{textBook.subjectArea}"/>
    <h:message for="subjectArea" errorClass="error" />
  </h:panelGrid>
  <h:commandButton value="Create" rendered="#{viewScope.bookTypeVal == 'TEXTBOOK'}"
                   action="#{textBookController.add( book.isbn, book.title, book.year, textBook.subjectArea)}" />
</h:panelGroup>

<h:panelGroup id="biographyBookPanel">  
  <h:panelGrid rendered="#{viewScope.bookTypeVal == 'BIOGRAPHY'}" columns="3">
    <h:outputText value="About: " />
    <h:inputText id="about" value="#{biographyBook.about}"/>
    <h:message for="about" errorClass="error" />
  </h:panelGrid>
  <h:commandButton value="Create" rendered="#{viewScope.bookTypeVal == 'BIOGRAPHY'}"
                   action="#{biographyBookController.add( book.isbn, book.title, book.year, biographyBook.about)}" />
</h:panelGroup>

The starting point for our case study is the design model shown in Figure 1.8 above. In the following sections, we show how to eliminate the Manager class by using the Class Hierarchy Merge design pattern and how to implement the Person hierarchy and use Joined, Multiple Table Inheritance storage with the help of JPA framework.

3.1. Make the Java Entity class model

We design the model classes of our example app with the help of a Java Entity class model that we derive from the design model by essentially leaving the generalizatiion arrows as they are and just adding getters and setters to each class. However, in the case of our example app, it is natural to apply the Class Hierarchy Merge design pattern to the segmentation of Employee for simplifying the data model by eliminating the Manager subclass. This leads to the model shown in Figure 2.3 below. Notice that we have also made two technical design decisions:

1. We have declared the segmentation of Person into Employee and Author to be complete, that is, any person is an employee or an author (or both).

2. We have turned Person into an abstract class (indicated by its name written in italics in the class rectangle), which means that it cannot have direct instances, but only indirect ones via its subclasses Employee and Author. This technical design decision is compatible with the fact that any Person is an Employee or an Author (or both), and consequently there is no need for any object to instantiate Person directly.

Figure 2.3.  The Java Entity class model of the Person class hierarchy

@Entity
@Inheritance( strategy = InheritanceType.JOINED)
@DiscriminatorColumn( name = "category", discriminatorType = DiscriminatorType.STRING, length = 16)
@Table( name = "persons")
public abstract class Person {
  @Id
  @PositiveInteger
  @NotNull( message = "A person ID value is required!")
  private Integer personId;
  @Column( nullable = false)
  @NotNull( message = "A name is required!")
  private String name;

  // constructors, set, get and other methods
}

@Entity
@DiscriminatorValue( value = "AUTHOR")
@Table( name = "authors")
@ManagedBean( name = "author")
@ViewScoped
public class Author extends Person {
  @NotNull( message = "A biography is required!")
  private String biography;

  // constructors, set, get and other methods
}

@Entity
@DiscriminatorValue( value = "EMPLOYEE")
@Table( name = "employees")
@ManagedBean( name = "employee")
@ViewScoped
public class Employee extends Person {
  @Column( nullable = false)
  @NotNull( message = "An employee ID is required!")
  @Min( value = 20000, message = "Employee no. must be greater than 20000!")
  @Max( value = 99999, message = "Employee no. must be lower than 100000!")
  private Integer empNo;
  @Column( nullable = false, length = 32)
  @Enumerated( EnumType.STRING)
  private EmployeeTypeEL type;
  @Column( nullable = true, length = 64)
  private String department;

  // constructors, set, get and other methods
}

CREATE TABLE IF NOT EXISTS `persons` (
  `PERSONID` int(11) NOT NULL,
  `category` varchar(16) DEFAULT NULL,
  `NAME` varchar(255) NOT NULL
);

CREATE TABLE IF NOT EXISTS `authors` (
  `PERSONID` int(11) NOT NULL,
  `BIOGRAPHY` varchar(255) DEFAULT NULL
);
ADD CONSTRAINT `FK_authors_PERSONID` FOREIGN KEY (`PERSONID`) REFERENCES `persons` (`PERSONID`);

CREATE TABLE IF NOT EXISTS `employees` (
  `PERSONID` int(11) NOT NULL,
  `DEPARTMENT` varchar(64) DEFAULT NULL,
  `EMPNO` int(11) NOT NULL,
  `TYPE` varchar(32) DEFAULT NULL
);
ADD CONSTRAINT `FK_employees_PERSONID` FOREIGN KEY (`PERSONID`) REFERENCES `persons` (`PERSONID`);

<h:column>
  <f:facet name="header">Special type of employee</f:facet>
  #{e.type != null ? e.type.label.concat( " of ").concat( e.department).concat( " department")  : ""}
</h:column>

Running your application is simple. First stop (if already started, otherwise skip this part) your Tomcat/TomEE server by using bin/shutdown.bat for Windows OS or bin/shutdown.sh for Linux. Next, download and unzip the ZIP archive file containing all the source code of the application and also the ANT script file which you have to edit and modify the server.folder property value. Now, execute the following command in your console or terminal: ant deploy -Dappname=subtypingapp. Last, start your Tomcat web server (by using bin/startup.bat for Windows OS or bin/startup.sh for Linux). Please be patient, this can take some time depending on the speed of your computer. It will be ready when the console display the following info: INFO: Initializing Mojarra [some library versions and paths are shonw here] for context '/subtypingapp'. Finally, open a web browser and type: http://localhost:8080/subtypingapp/faces/views/app/index.xhtml

You may want to download the ZIP archive containing all the dependency libaries, or run the subtyping app directly from our server.