In this TypeDB Academy, we start by gaining an understanding of the fundamental components of TypeDB's type system and what makes it unique. We will see how we can download, install, and run TypeDB, and learn to perform basic database operations. We'll then explore what a schema looks like in TypeDB, starting with clarifying the motivation for schema, the conceptual schema of TypeDB, and its relationship to the Enhanced Entity-Relationship model. Good for: - Beginners to TypeDB and TypeQL - Those who have been using TypeDB and want a refresher on schema and TypeQL - Experienced database administrators and software engineers Takeaways: - Understanding of fundamental components of TypeDB - How to download, install, and run TypeDB on your computer - Be able to articulate why schema is so beneficial when using TypeDB, why we use one, and how it enables a more expressive model - Write a TypeDB schema in TypeQL

1. TypeDB Academy | Schema Design

2. Schema Design
• Motivation for schema
• Conceptual schema of TypeDB, and its relationship to the enhanced ER-Diagram
• How to write schema in TypeQL

3. Coming to terms with schema-less
To better understand the value that schema plays in our ability to be
expressive and efficient in working with a database, we need to come to
terms with what we already know about using NoSQL databases. . .

4. Coming to terms with schema-less
In the chat, drop your answer to the below:
How would we go about implementing logical
consistency to your data in a schema-less database?

5. Motivation for the schema
Schema declares the permissible structure of your data. We do this using
expressive schema constructs, which can constrain our data without
getting in the way.
• logical integrity at insertion-time: constraints on the data inserted
• knowledge representation: expressive querying in near natural language
• store domain context: enables rule based inference
• true-to-life representation of the domain: understanding context

6. TypeDB allows you to model your domain based on logical and object-oriented
principles. Composed of entity, relationship, and attribute types, as well as type
hierarchies, roles, and rules.

7. TypeDB’s Data Model
TypeDB is a database with a rich and logical type system, based on the Enhanced
Entity Relationship Model.
The model embeds context with:
• typing: entities, attributes, relations, roles
• type inheritance: single, not multiple
• fully labeled hyper-relations: including composition via named rules

8. Concept architecture
As entities, relations, attributes are all
sub-types of thing, we should sub-type
each to build a schema for our domain.
These schema concepts define our
types, which can then be instantiated by
our data.
Therefore, we refer to data model and
schema interchangeably.
Terminology:
• type: refers to a sub-type of entity, attribute or relation, as defined
by a a schema
• thing: refers to an instance of any type
• concept: refers to any thing or type

9. Example
Nomenclature
When visually representing
TypeQL, we use:
• rectangle for entity
• oval for attribute
• diamond for relation
person company
organisation
document
name
content
employment

10. person company
organisation
document
name
content
employment
Example
Nomenclature
When visually representing
TypeQL, we use:
• owns to declare ownership
of an attribute
• sub for subtypes
• <role-type name> for role-
players in a relation
sub
owns
owns
employee
employer
contract
owns

11. Visualise the model for our domain
Having seen the TypeDB model, how would you translate this to your domain?
Exercise- 6 minutes:
1) Thinking about your domain and use case, begin to visually map out your
model based on the TypeDB Knowledge Model.
2) What are the entities and their attributes - then what relations between
the data do you recognise or foresee?
3) Draw your model on a scrap piece of paper or an online modelling tool,
we’ll turn it into TypeDB schema next.

12. person company
organisation
document
name
content
employment
Example Nomenclature
When visually representing
TypeQL, we use:
• owns to declare ownership
of an attribute
• sub for subtypes
• <role-type name> for role-
players in a relation
sub
owns
owns
employee
employer
contract
owns

13. Visualise the model for our domain
Let’s share what we came up with and see what
differences we found between us.

14. entity – a thing with a distinct existence in the domain
syntax:
The keyword define is used to precede declarations of our schema. We can
define schema as many times as we want, not just once .
Here person is the entity type. We have declared that we want this type to
inherit from entity using sub . We can refer to the type itself using its type-
name, in this case person.
Defining schema types
define
person sub entity;

15. relation – describes how two or more things are connected to each other
syntax:
define
employment sub relation,
relates employer,
relates employee;
person sub entity,
plays employment:employee;
company sub entity,
plays employment:employer;
Watch Out!
A role must be declared for a
type to play it, either: inside a
relation; or explicitly, outside
a relation
Defining schema types

16. relation – in general, any type can be defined to play a role
<schema-type> could be entity , relation , attribute , or your own subtype of one of these. Therefore, relations
can relate anything. These are very useful constructs for building schemas that reflect the real domain well.
We scope the <role-type> a particular <schema-type> can play, in <my-relation-type>. This allows for a
more simple and efficient model, which we can make use of once we begin to query the database.
syntax:
Defining schema types
define
my-schema-type sub <schema-type>,
plays <my-relation-type>:<role-type>;

17. attribute – a piece of information, describing a property of a thing in a domain
syntax:
Attribute values
long, double, string, Boolean, date – the specifications for these are the same as in Java
Defining schema types
define
full-name sub attribute,
value string;
person sub entity,
owns full-name;

18. attribute – can only be instantiated at the leaves
Any time we create a new sub-type of an existing <my-attribute-type>, the parent type must be abstract and
defined as such in the schema.
attribute, is already abstract and so sub-types of attribute can be instantiated.
syntax:
Defining schema types
define
name sub attribute,
abstract,
value string;
full-name sub name;

19. type hierarchies – ”type Y is a subtype of type X, if and only if, every Y is necessarily an X”
syntax:
This means that any charity, company, and university is necessarily an organisation and inherits all
attributes and role-types from the parent.
define
organisation sub entity,
owns name;
charity sub organisation,
plays <relation-type>:group;
company sub organisation,
plays <relation-type>:employer;
university sub organisation,
plays <relation-type>:employer;
:: watch out ::
When sub-typing an
attribute, the parent
must be abstract.
Defining schema types

20. Defining schema types
Also…
syntax:
define
person sub entity,
owns email @key;
organisation sub entity,
abstract;
request sub relation,
abstract,
relates requestor;
friendship sub request,
relates friend as requester;
:: sneak peak ::
All roles defined to relate
to the parent relation
must also be defined to
relate to the child relation
using the as keyword.

21. Visualise the model for our domain
Now, let’s build off our “hand-made” model….
Exercise- 10 minutes individually:
1) Iterate on the model you drew and take a run at writing your schema in
TypeQL.
2) Define the entity(s), relation(s), and attribute(s), for your own domain or
use case
3) Once you have gotten to a ”complete” spot, drop your response to:
What was most challenging about this? What caught you up?

22. Schema syntax reminders
• start with define
• a sub b to subtype a from b
• value string to declare the datatype of an attribute
• owns to declare something can own an attribute
• relates to declare a role in a relation
• plays to declare something can play a role within a specific relation-type
• abstract to declare a <schema-type> to be abstract
• Commas between properties, and semicolon to end a statement

23. Define
role hierarchies – as is used to sub-type a role inside a relation
syntax:
define
ownership sub relation,
relates owner,
relates owned;
group-ownership sub ownership,
relates group-owner as owner,
relates owned-group as owned;
person sub entity,
plays group-ownership:group-owner;
social-group sub entity,
plays group-ownership:owned-group;
:: note ::
To be able to use both
the sub-type role and the
parent role, we need to
redeclare the parent role.

24. Schema flexibility
Schema file (.tql) – schema can be added to trivially, at any point.
and then later…
define
person sub entity;
name sub attribute,
value string;
define
person owns name;
## OR
person sub entity,
owns name;

25. Undefine schema types
Order of undefining – first no instances of that type (to protect our data)
syntax:
It's important to note that undefine [label] sub [type] owns [attribute's label]; undefines the label itself,
rather than its association with the attribute.
undefine
<my-schema-type> sub <schema-type>;
person owns social-handle;
rule co-workers;
employment sub relation;
commit

26. TypeQL keywords
define – Declare that a statement will create schema types
undefine – Declare that a statement will delete schema types
sub – Declare a subtype
owns – Attaches an attribute type to a type
relates – Declares a role to be involved in a relation (creates the role if it isn’t
otherwise defined)
plays – Declares that a type can be connected through a role’
as – Subtypes a role inside a relation
@key – Declares an attribute to be used as a unique identifier for a type
abstract – Declares that a type cannot have instances

27. Iterative modelling approach
You can create you schema by writing a TypeQL file.
1) Write/update your .tql file. This can contain define statements, and also
insert and match...insert statements (the latter two are to add example data)
2) Load the .tql file into your database
3) Identify the flaws in your model by:
- Trying to query the model for the insights you need. If the insights cannot be found
correctly, then try to understand why your model is limited. Assessing whether the data you
have can be stored in the model.
4) Clean the database
5) Go back to step (1.) and repeat

28. Thank you!!