# Relationships

> As you might have guessed, relationships are a crucial part of any relational database. Directus supports all standard
> relationship types, as well as a few more _compound_ types that offer greater flexibility.

[[toc]]

### Introduction

While it may seem complex at first, relational data is actually quite straightforward once you understand what's
happening behind the sometimes confusing terminology. Before diving into the details of each type, let's first cover a
few basics that will help you better visualize them in your mind's eye.

### Primary and Foreign Keys

Every [Item](/getting-started/glossary/#items) in a relational database has a unique
[Primary Key](/getting-started/glossary/#primary-key-pk) (or "PK") that identifies it within its
[Collection](/getting-started/glossary/#collections). Because it's required, the key is the first
[field](/getting-started/glossary/#fields) created within a collection, typically storing an "auto-increment" number, an
automatically generated unique hash, or a manually entered value. They are often abbreviated to "PK" (Primary Key), "ID"
(Identifier), "UID" (Unique Identifier), or "UUID" (Universally Unique Identifier), depending on the type of value they
store. After it's created, the value of an item's PK should _never_ change.

To link items together relationally, you simply save a reference to an item's PK in a different field. That _reference_
is called a Foreign Key (FK). If the primary key is a _person_, the foreign key is like their _business card_. It
references the actual person, providing just enough information to find them.

::: tip Composite & Compound Keys

In the above explanation we've ignored _composite_ and _compound_ keys, which are essentially unique keys created by
combining _multiple_ field/column values.

:::

### Perspective Matters

Just like primary and foreign keys, relationships are always described relative to their "parent" collection. Looking at
the same relationship/key from the perspective of the opposite collection would reverse it. This means that a
many-to-one relationship can also be seen as a one-to-many relationship, it just depends on which collection is
considered the parent.

## Many-to-One (M2O)

The Many-to-One is the only relationship type with an actual field on the parent Collection. This field saves the
foreign key to a single related item. For example, a _city_ can only be in one _country_, but a _country_ can have many
_cities_.

Below is an example of a M2O relationship:

```
cities (the "Many" Collection)
- id (Primary Key)
- name
- country (the M2O field that stores the country key)

countries (the "One" Collection)
- id (Primary Key)
- name
```

### Setup

![M2O](../assets/guides/fields/m2o.png)

The parent collection and field are already known (it's the field you're currently creating), so configuring those are
disabled. All you need to configure is the related collection and its primary key field.

If you select or enter an **existing** Related Collection (highlights green) then the primary key field is known and
automatically selected. If you enter the name of a **new** Related Collection (doesn't already exist), you will also be
prompted to enter the name of its primary key field, which will default to an auto-increment integer type.

You also have the option to create a **Corresponding Field** during this process. This allows you to more easily create
the O2M alias (see below) that pairs with this M2O.

**Relational Triggers** allow for control over what happens when a relationship is broken. There is one option:

- **On Delete of [Related Collection]** — When the related item (O2M) is deleted...
  - Nullify the parent M2O field (default)
  - Set the parent M2O field to its default value
  - Delete the parent collection's item (cascade)
  - Prevent the deletion

## One-to-Many (O2M)

The One-to-Many relationship is the **exact same relationship** as a Many-to-One (above), just seen from the opposite
collection's perspective. The O2M is stored as an [Alias](/getting-started/glossary/#alias) field on its parent
Collection that dynamically lists all items connected via the opposite Many-to-One. So, while the M2O will show a single
country for the parent city, the O2M shows all cities for the parent country.

Below is an example of a O2M relationship:

```
countries (the "One" Collection)
- id (Primary Key)
- name
- *cities* (the O2M alias field that lists references from "cities.country")

cities (the "Many" Collection)
- id (Primary Key)
- name
- country (the M2O field that stores the country key)
```

### Setup

![O2M](../assets/guides/fields/o2m.png)

The parent collection and field are already known (it's the field you're currently creating), so configuring those are
disabled. All you need to configure is the related collection and its M2O field.

You can select or enter an **existing** Related Collection (highlights green) or create a **new** one by entering a
unique collection name. Next, you can select an existing field (highlights green) or create a new one by entering a
field name unique to its collection.

The related field will store the value of this collection's primary key field, so both must have the same type. For this
reason, when selecting existing fields, options will be disabled if they don't have a matching type.

You also have the option to create a **Corresponding Field** during this process. This allows you to more easily create
the M2O field (see above) that pairs with this O2M.

The optional **Sort Field** can be used enable manual reordering of items within this O2M field. This is configured by
selecting an existing numeric type field (highlights green) from the Related Collection, or entering the name of a new
field to be created.

**Relational Triggers** allow for control over what happens when a relationship is broken. There are two options:

- **On Deselect of [Related Collection]** — When the value of the M2O is deselected...
  - Nullify the M2O field value (default)
  - Delete the M2O item (cascade)
- **On Delete of [Parent Collection Item]** — When this O2M item is deleted...
  - Nullify the related M2O field (default)
  - Set the related M2O field to its default value
  - Delete the related collection's item (cascade)
  - Prevent the deletion

## Translations (O2M)

The Translations relationship is just a special version of the standard O2M. Just like the O2M, it creates an
[Alias](/getting-started/glossary/#alias) field that is used to list all related items (the translations). Translations
themselves are stored in a separate collection, which is then further related to _third_ collection that stores all
languages.

### Setup

![Translations](../assets/guides/fields/translations.png)

The easiest way to add translations is to use the wizard, which only asks for the Translation field name. All required
fields and relationships will then be automatically created and configured.

![Translations](../assets/guides/fields/translations-2.png)

If you choose to switch to **manual setup**, you will be presented with a similar relationship setup to O2M or M2M. The
parent collection and primary key are know, so those fields are disabled.

Next, we configure the Translation Collection. Set to "Auto Fill" by default, this will enter intelligent naming based
on related names, and disables all fields. Disabling Auto Fill will enable all fields, allowing you to name the
collection that holds the translations, as well as the two fields (each a M2O) that store foreign keys to the parent
item and language.

Lastly, you would select/create the Languages collection, which stores the languages available for this translations
field. It is common practice to reuse a single languages collection throughout your project, unless translation fields
need to support different language sets. For the language `code` we recommend using the IETF language tag (eg: `en-US`)
which combines the ISO 639-1 and ISO 3166‑1 standards, but anything can be used (eg: `english`).

## Many-to-Many (M2M)

The Many-to-Many relationship is actually just **two relationships combined** (O2M+M2O) that join together three
different collections. The M2M is stored as an [Alias](/getting-started/glossary/#alias) field on its parent Collection
that dynamically lists all items connected via a [junction collection](/getting-started/glossary/#junction-collections).
For example, a _recipe_ can have many _ingredients_, and _ingredients_ can be in many _recipes_.

Below is an example of a M2M relationship:

```
recipes (Collection)
- id (Primary Key)
- name
- *ingredients* (M2M/O2M alias field that lists references from "recipe_ingredients")

ingredients (Collection)
- id (Primary Key)
- name
- *recipes* (M2M/O2M alias field that lists references from "recipe_ingredients")

recipe_ingredients (Junction Collection)
- id (Primary Key)
- recipe (stores the recipe key)
- ingredient (stores ingredient key)
- quantity (other optional data on the connection)
```

Notice that the example above also has a `quantity` field on the Junction Collection, which tracks how much of each
ingredient is needed for the recipe. You can add any other _contextual_ fields to the junction, and they will also be
included at the top of the App's relational Item Page form.

::: tip Self-Referencing

You can also have a M2M relationship that connects items within the _same_ collection. An example of this is "Related
Articles", where an article might relate to many other articles.

:::

### Setup

![M2M](../assets/guides/fields/m2m.png)

The parent collection and field are already known (it's the field you're currently creating), so configuring those are
disabled.

Next you should configure the Related Collection. If you select or enter an **existing** Related Collection (highlights
green) then the primary key field is known and automatically selected. If you enter the name of a **new** Related
Collection (doesn't already exist), you will also be prompted to enter the name of its primary key field, which will
default to an auto-increment integer type.

Lastly, we configure the [Junction Collection](/getting-started/glossary/#junction-collections), which sits between the
two related collections, storing all links between the two. You can leave this set to "Auto-Fill", which sets
intelligent naming defaults, or disable it to select existing options or enter custom names.

You also have the option to create a **Corresponding Field** during this process. This allows you to more easily create
the reverse M2M field on the _related_ collection.

The optional **Sort Field** can be used enable manual reordering of items within this O2M field. This is configured by
selecting an existing numeric type field (highlights green) from the Junction Collection, or entering the name of a new
field to be created.

**Relational Triggers** allow for control over what happens when a relationship is broken. There are three options:

- **On Deselect of [Junction Collection]** — When the value of this M2M is deselected...
  - Nullify the junction field (default)
  - Delete the junction item (cascade)
- **On Delete of [Parent Collection Item]** — When this M2M item is deleted...
  - Nullify the junction field (default)
  - Set the junction field to its default value
  - Delete the related junction item (cascade)
  - Prevent the deletion
- **On Delete of [Related Collection Item]** — When the related M2M item is deleted...
  - Nullify the junction field (default)
  - Set the junction field to its default value
  - Delete the related junction item (cascade)
  - Prevent the deletion

## Many-to-Any (M2A)

Sometimes called a "matrix field" or "replicator". Like the M2M, the M2A is stored as an
[Alias](/getting-started/glossary/#alias) field on its parent Collection that dynamically lists all items connected via
a [junction collection](/getting-started/glossary/#junction-collections). However, there is one key difference: one side
of the junction also stores a **collection key**. This combination of collection name and primary key means that you can
effectively store a reference to _any_ item in the database. You can then artificially limit which collections are valid
through a related collections "allow list".

A common example of a M2A is a "Page Builder", which has a _Pages_ collection that includes any number of different
"section" Collections, such as: "Heading", "Text", and "Image". In this example the junction table will link different
sections (from different collections) with a page, creating relational layouts.

Below is an example of a M2A relationship:

```
pages (Collection)
- id
- name
- *sections* (O2M/M2A alias field that lists references from "sections")

page_sections (Junction Collection)
- id
- pages_id (stores the primary key of the parent page)
- collection (stores name of the related collection, for example "headings", "text", or "images")
- item (stores the primary key of the related item)

headings (Collection)
- id
- title

text (Collection)
- id
- text

images (Collection)
- id
- file
```

### Setup

![M2A](../assets/guides/fields/m2a.png)

The parent collection and field are already known (it's the field you're currently creating), so configuring those are
disabled.

Next, we configure the [Junction Collection](/getting-started/glossary/#junction-collections), which sits between the
related collections, storing all links between them. You can leave this set to "Auto-Fill", which sets intelligent
naming defaults, or disable it to select existing options or enter custom names.

Lastly, you should select any desired Related Collections. Unlike other relationships, you can't _create_ these related
collections here, so ensure all related collections you need are created before hand.

::: tip Auto-generating

If you enter a collection/field name that doesn't exist yet, Directus will auto-generate these collections/fields once
you save the changes on the new M2A field.

:::

The optional **Sort Field** can be used enable manual reordering of items within this M2A field. This is configured by
selecting an existing numeric type field (highlights green) from the Junction Collection, or entering the name of a new
field to be created.

**Relational Triggers** allow for control over what happens when a relationship is broken. There are three options:

- **On Delete of [Parent Collection Item]** — When a M2A item is deleted...
  - Nullify the junction field (default)
  - Set the junction field to its default value
  - Delete the related junction item (cascade)
  - Prevent the deletion
- **On Deselect of [Junction Collection]** — When the value of this M2A is deselected...
  - Nullify the junction field (default)
  - Delete the junction item (cascade)

## One-to-One (O2O)

Directus does not include a dedicated One-to-One (O2O) relationship type or interface. However, O2O is essentially the
same as a M2O (storing a foreign key). The only difference is that a O2O enforces the cardinality. In other words,
selecting a relational item in a O2O means that item can not be selected elsewhere (it can only be used once). This
functionality can be added by checking and constraining uniqueness via a [custom event hook](/extensions/hooks/) or
[custom interface](/extensions/interfaces/).

An example of this is a _person_ only has one unique set of _fingerprints_, and those _fingerprints_ only belong to one
_person_.
