Lesson 9.1: The PERA model

A PERA data model comprises data-storing types and interface types (or simply "interfaces") between them, similar to classes and interfaces in OOP. The modeling paradigm is based on the theory of dependent types, and interfaces serve as abstractions of the dependencies between data-storing types. All data-storing types in the PERA model are either entity types, relation types, or attribute types. Each is used to model a different class of concepts in the data domain.

A key difference between entity or relation types and attribute types is that entity and relation types contain objects whereas attribute types contain values. Entity and relation types can be collectively referred to as object types, as distinct from attribute types, similar to composite types and primitive types respectively in OOP. Much like their OOP analogs, objects types are freely instantiable, so it is possible to create two objects that have identical properties but are not themselves identical. Meanwhile, values are not freely instantiable, so two attributes with the same type and value are in fact the same attribute.

This difference also affects permitted interface implementations in the PERA model. Only object types are able to implement interfaces: own attribute types and play roles in relation types. It is not possible for an attribute type to own another attribute type, or to play a role in a relation type.

The biggest difference between the ER and PERA models is that the PERA model permits the use of polymorphic features like interfaces, inheritance, and abstraction. Interface implementations are used to define capabilities of object types, and an interface can be independently implemented by multiple object types. Meanwhile, inheritance allows types to be made subtypes of other types, and the interface implementations of an object type are inherited by its subtypes. Finally, abstraction is used to prevent instantiation of a type, which can only be instantiated through a concrete subtype.

The following table summarises the key properties of data-storing types in the PERA model. As we saw in Lesson 5.2, only an abstract attribute type can have subtypes, in order to prevent ambiguities in the interpretation of queries.

In addition to these data-storing types, interface types and value types together make up the data-structuring types. In fact, all parts of the PERA model are types! This arises from the PERA model’s core philosophy:

The key difference between data-storing and data-structuring types is that only data-storing types can be instantiated directly, and their instances operated on. Meanwhile, the data-structuring types serve to define the behaviours of these data instances. The following diagram summarises the ways in which different kinds of types in the PERA model are associated.

The upcasting of types into their supertypes enables the use of inheritance polymorphism in queries. Similarly, object types can be upcast into the interface types they implement, which enables interface polymorphism in queries. Finally, attribute types can also be upcast into their value types, which enables arithmetic expressions.

A new type is defined using a sub statement. For example, in the above schema excerpt:

A role interface is defined using a relates statement. The label of the created role interface is given by the label of the dependent relation followed by the name of the role, separated by a : delimiter. For example, in the above schema excerpt:

Unlike roles, ownership interfaces are not explicitly defined in TypeQL. Because every attribute has only one ownership interface, an attribute’s ownership interface is created implicitly when the attribute is defined. As a result, an ownership does not have an explicitly referenceable label like a role does, but we can describe it with an implicit label comprising the label of the dependent attribute followed by an :OWNER suffix. For example, in the above schema excerpt:

An implementation of a role interface is declared using a plays statement. For example, in the above schema excerpt:

Meanwhile, an implementation of an ownership interface is declared using an owns statement. As ownership interfaces do not have explicit labels, the object of an owns statement is the label of the dependent attribute rather than the interface itself. For example, in the above schema excerpt:

Interface implementations are independent, allowing multiple object types to implement the same interfaces, even if they share no common supertypes. For example, in the above schema excerpt:

A type hierarchy is defined using a sub statement. For example, in the above schema excerpt:

When an object type implements interfaces, those implementations are inherited by its subtypes. For example, in the above schema excerpt:

Finally, a type if defined to be abstract using an abstract statement. For example, in the above schema excerpt:

When TypeQL queries are executed by TypeDB, casting of types takes place automatically via type inference. Let’s consider some example constraints, starting with the following example of inheritance polymorphism.

In this case, the variable $x is of type book. To resolve this constraint, TypeDB determines the list of types that can be upcast into book, and finds paperback, hardback, and ebook. Thus, instances of these types can be matched for $x. Now let’s consider an example of interface polymorphism.

In this case, the variable $y is of type price:OWNER. TypeDB determines that book and order-line can be upcast into price:OWNER, and so can have instances matched for $y. Finally, we’ll consider parametric polymorphism.

In this case, the variable $z is of type entity. Thus, TypeDB will match instances of any entity types, as they can all be upcast into entity.