Introduction

Summary

TypeDB:

  • Is a strongly typed database that is unique in many ways:

  • Is a transactional (OLTP) DBMS with ACID guarantees.

  • Has data separated by databases, each one with its own schema.

The core of any TypeDB database is the representation of our business domain: the schema. A schema is the blueprint of a TypeDB database. Using TypeQL, we define a schema to model a domain true to nature:

  • Types are defined to add context and constraints to data using strong typing with inheritance. All user-defined types in a schema are subtypes of other user-defined types or one of the following built-in root types:

    • Entities. Representing self-sufficient objects.

    • Relations. Representing n-ary relationships.

    • Attributes. Representing properties with a value: numeric, text string, boolean, or date&time.

  • Rules are defined to add a logical deduction to the schema. Any read queries with the inference option enabled can benefit from new attribute ownerships or relations that are deduced from data patterns. Those inferred concepts are transaction bound and are not persisted in a database.

TypeDB description

TypeDB is a new kind of DBMS:

  • not an SQL database, but uses an enhanced Entity-Relationship model, further extended by attributes as first-class citizens;

  • not a graph database, but utilizes the power of hypergraphs without the need for developers to understand how it works to use it.

Entity, Relation, and Attribute correspond to the components of an Entity-Relation-Attribute model, an extension of the well-known ER model, in which attributes (properties) are also treated as first-class citizens.

TypeDB guarantees data integrity and safety while enabling data-level inferences within the database. A strong type system with subtyping and inheritance helps us break down complex problems into meaningful and logical data models. TypeDB uses its own declarative query language, TypeQL, that gives powerful abstraction over the implementation of storage to enable us to use complex data patterns and the reasoning engine.

With TypeQL, we describe data that we need by patterns consisting of constraints. TypeDB will use those patterns to retrieve all data that satisfies all the constraints in the most efficient way. We don’t have to think about query optimization, limitations of data storage implementation, etc.

By combining TypeQL and TypeDB, we can close the gap between the language of our domain and the database. Queries written in TypeQL are easily readable. Carefully designed database schema lets us use the terminology of the business domain, making our queries sound familiar to subject-matter experts. This new paradigm gives us a higher level of flexibility and expressivity to simplify our work and tackle domains that seemed impossibly complex before.

TypeQL and TypeDB allow us to build a data model with entity, relation, and attribute types. Inheritance allows us to define a hierarchy of subtypes and reduce complexity, while rules and relations with type constraints on their role-players further enhance our schema. These abstractions provide a higher-level framework to build intuitive and understandable models.

In other databases, we implement relations with a join table (SQL) or an edge between two vertices (graph databases). TypeDB relations generalize both: they flexibly relate one, two, or any number of roles. And each role can be played by any types defined as role-players for this particular role in the schema.

This expanded idea of a relation is more powerful than either SQL or graph relations. However, we can further improve this idea: if we allow relations not just to specify which instances relate to each other but also how they relate by adding context. This has been implemented in the form of a role.

Any relation type specifies one or many roles connected by this relation. Any type in a schema can play roles that were explicitly defined in the type definition. Roles have labels that provide the context and type constraints for roles to enforce this context.

Finally, we can use the reasoning engine to infer new data based on the patterns found in the database. To do that, we define rules in the database schema. Rules can dramatically shorten complex queries (e.g., transitivity of relations), perform explainable knowledge discovery, and implement business logic at the database level.

Learn more

  1. First, use the installation guide to install TypeDB on the local machine.

  2. The TypeDB journey starts with our Quickstart guide.

    It goes through the step-by-step process of creating a new database, applying schema, loading sample data, and querying. The resulting environment is suitable for executing most examples in our documentation. On top of that it familiarizes users with TypeDB Studio — IDE, specifically designed for TypeDB database management and development.

  3. Fundamentals — essential knowledge of how TypeDB works:

  4. Connect page: Connect to TypeDB using databases, sessions, transactions, and ACID guarantees.

  5. Define schema page: Find out how to define, undefine, and modify types and rules in a TypeDB database.

  6. Writing data and Reading data pages: How to perform Insert, Delete, Update, and Get queries.

  7. Response interpretation page: How to use responses from TypeDB.