We’ll begin with the bottom-up method. The entity types city, state, and country are clearly very alike. Conceptually, these all represent kinds of place, so it makes sense to give them a common supertype place. This supertype should be abstract, as it is not possible to have a place that is not one of these kinds, or some other kind not yet defined in the schema.

Next, we must consider which properties of the subtypes are actually properties that should be inherited from the supertype. The first is ownership of name. All three subtypes own name, so we can move it to the supertype with no change in expressivity of the current model, however this is a significant change for the development of the model in the future. If we give ownership of name to place, not only will all three current subtypes inherit the ownership, all future subtypes will inherit it as well. For that reason, we should consider if all kinds of places have names, not just the ones in the data model so far. Indeed, we decide that this is the case, so ownership of name is moved to the supertype.

Now we should consider the other interfaces implemented by the subtypes:

None of these interfaces are implemented by all three subtypes, so it might seem that we should leave them defined there rather than at the supertype level. Once again though, we need to consider what the behaviour should be if we introduce more subtypes of place. Should all kinds of place be publishing locations? Probably not. The front matter of books always lists the city of publication by convention. Should all kinds of place be locations for other places? That seems more likely. We might later introduce a "region" type that is superior to countries, or a "street" type that is inferior to cities. As such, we’ll move the playing of locating:located and locating:location to the supertype, but keep that of publishing:location exclusive to city.

Grouping existing types into hierarchies in this way is not always a good idea. As types in the PERA model can only have a single supertype, we must choose our types carefully. The fact the several types exhibit common behaviours is not necessarily an indicator that they are all subtypes of a common supertype, as we can alternatively encode those common behaviours by having the types independently implement the same interfaces. We will see an example of such a case in Lesson 9.5.

Next, we’ll try the top-down method. Building type hierarchies top-down can be harder because it is often less obvious that a hierarchy should be present at all. The biggest indicator of a potential top-down hierarchy is when typing information is being stored as data. Let’s examine an example.

Currently, the schema shows that book owns format. If we examine the data table, we see that each book has exactly one format and that there are only a small number of these formats: "paperback", "hardback", and "ebook". As such, it would make sense for these to be subtypes of book. This is a case where typing information has been stored in a way that is structurally indistinguishable from data, as is often the case when working with tabulated data or non-polymorphic databases. Because of the lack of subtyping in other data modeling paradigms, types must be stored as properties in this way, or that data must be divided into separate structures (tables, documents, etc.) per type.

There is an additional hint that this field in the data table represents a type: the stock attribute is absent for any book with the format "ebook". This makes sense of course, as an ebook cannot possibly go out of stock. The exclusivity of the stock property to physical books is another indicator that formats are best modelled as a type hierarchy, as we can then assign the property only to the appropriate subtypes. Based on this, we will create three subtypes of book: paperback, hardback, and ebook, and move ownership of stock down the hierarchy. As a result, we will also make the supertype abstract, as every book must necessarily have a format.

In general, the following characteristics are good indicators of types stored as data in a particular field:

Where the field always contains a value, this is indicative that the common supertype is abstract, as we have seen with book. If the field is sometimes empty, this would indicate that the common supertype is not abstract, and applies as a non-specialised variant covering cases where the field is empty. We will see an example of such a hierarchy shortly.

Conversely, the following would be indicators against a field containing typing information:

An example of a field like this in the current schema would be genre.

In both of the cases we have examined, those of place and book, it made sense to make the supertype abstract. This is primarily driven by semantic considerations, as it is not possible to have a place without a specific type, or a book without a format. However, non-abstract supertypes are very useful for constructing hierarchies in which some instances will have generalized behaviour, and some will have specialized behaviours in addition to the general behaviours. Let’s consider an example.

The current schema includes the types author, editor, illustrator, and other-contributor. Adopting a bottom-up approach to hierarchy design, it is clear these types should have a common supertype contributor, especially seeing as they have identical interface implementations.

However, this hierarchy includes the redundant representation other-contributor. Such a contributor is merely a contributor that is not an author, editor, or illustrator. In other words, this type is a generalised catch-all subtype. But the type that is supposed to represent the generalised behaviour in a type hierarchy is the supertype. As a result, we should make contributor non-abstract and instantiate directly instead of other-contributor.

Now, if there is a contributor that is an author, editor, or illustrator, we can instantiate the appropriate specialized subtype. Meanwhile, if there is a contributor without a specific role listed, we can instantiate the generalized supertype.