Airtableが普通の表計算アプリケーションと違うのは、関連する概念を結びつけることができることです。
この記事では、エンティティのリスト間の関係の種類を定義し、例を示して、自分でそれらを識別できるようにします。 また、”ジャンクション テーブル “と呼ばれる手法を使って多対多の関係を表現する方法についても説明します。
関係の種類
1対1
1対多
多対多
多対多の関係とジャンクションテーブル
例1：学生とクラス
例2：応募者と面接官。 応募者と面接官
例3：顧客、顧客の注文、製品、メーカー
計算フィールドとジャンクションテーブル
関係の種類
Airtableはデータベースです。
1対1
最も単純な関係の種類は、1対1の関係です。 例えば、人の名前のリストと社会保障番号のリストがあるとします。 各人は1つの社会保障番号しか持っておらず、各社会保障番号は1人の人にリンクしています。 Airtableベースの文脈では、1対1の関係は通常、2つの情報リストを2つのフィールドを使って1つのテーブルに統合することで表現するのが最適です。
また、同じテーブル内のリンクされたレコード フィールドを使用して、1対1の関係を示すことも可能です。 例えば、フィギュア スケート競技の出場者のリストがあるとします。 ペア スケート競技に出場する個人の各ペアは、各パートナーが他のパートナーを 1 人しか持たないため、その関係は 1 対 1 です。
1対1の関係は比較的珍しいものです。なぜなら、ある関係の両側が1つだけの相手と一致する可能性は低いからです。
- People-Passports (各人は特定の国のパスポートを1つだけ持っており、各パスポートは1人だけのためのものである。
- Country-Flag (各国には1つの国旗しかなく、各国旗は1つの国にしか属していません。)
- Spousal Relations (各人には1人の配偶者しかいません。)
One-to-many
より複雑な（しかし、はるかに一般的な）タイプの関係として、1対多/多対1があります。 たとえば、芸術作品のリストと美術館のリストがある場合、それぞれの芸術作品は一度に 1 つの美術館にしか入れませんが、各美術館には多くの芸術作品を入れることができます。 ベースでは、この2つのリストのエンティティ（美術館と作品）を2つのテーブルに分割することで、それぞれのエンティティに関連する情報を格納することができます。
美術館のリストと作品のリストの一対多の関係を表すAirtableベースを作るとしたら、それぞれのリストをMuseumテーブルとWorksテーブルに分けます。
一対多の関係の2つの部分を別々のテーブルにすることはよくありますが、関係にあるすべてのエンティティが同じクラスである場合は、自己リンクテーブルを使用する方が理にかなっていることがあります。 例えば、全従業員の名前が記載された会社の名簿があるとします。各マネージャーが多くの従業員を管理し、各従業員には1人のマネージャーしかいないことから、マネージャーとその部下の関係をモデル化したいとします。
他にも一対多の関係の例をいくつか挙げてみましょう：
- 人-住所（各人は1つの住所に住むことができますが、各住所には1人以上の人が住むことができます。
- Owners-Pets (各ペットの所有者は1人ですが、各所有者は1人以上のペットを持つことができます。)
- Farmer-Equipment (各農機具の所有者は1人の農家ですが、各農家は多くの農機具を所有することができます。)
Many-to-many
最後に、エンティティは多対多の関係を持つこともできます。 例えば、本のリストと著者のリストがあり、各本には1人以上の著者がいて、各著者が複数の本を書いている場合があります。 この場合、多くの著者に関連する多くの本があります。
Airtableでは、2つのリストのエンティティの関係を表現するのは、1対多の関係を表現するのと同じくらい簡単です。
1対1の関係や1対多の関係と同様に、すべてのエンティティが同じクラスである場合など、多対多の関係を単一の自己リンクテーブルで表現することに意味がある場合があります。 例えば、あるグループ内の友人関係を追跡したいとします。 各人には多くの友人がいて、さらにその友人には他にも多くの友人がいます。
以下に多対多の関係の他の例を示します。
- 食材-レシピ（各食材は複数のレシピで使用でき、各レシピは複数の食材を必要とします）
- 医師-患者（各医師は多くの患者を診察し、各患者は多くの医師を診察します。
- Employees-Tasks (各従業員は一度に多くのタスクをこなし、各タスクは1人または複数の従業員によって処理される。)
- Customers-Products (各顧客は多くの製品を購入することができ、各製品は多くの異なる顧客によって購入されることができる。)
多対多の関係とジャンクションテーブル
多くの場合、Airtableで多対多の関係を表現するのは、2つのテーブルをリンクするだけで簡単です。 しかし、状況によっては、2つのエンティティの間に関係があることを知るだけでなく、その関係に関する他の情報を表現したり、保存したりする必要があります。 このような場合には、ジャンクション（またはジョイン）テーブルと呼ばれる3つ目のテーブルを作成する必要があります。
例 1: 学生とクラス
抽象的に聞こえるかもしれませんが、具体的な例を見てみましょう。 学生のリストとクラスのリストがあるとします。 各学生は複数のクラスを受講でき、各クラスには複数の学生が登録できるため、学生とクラスの間には多対多の関係があります。 学生のテーブルとクラスのテーブルを作り、それらをリンクさせてそのままにしておくこともできます。 しかし、各生徒のクラスの成績に関する情報を保存したいとしたらどうでしょうか。 あるいは、その生徒がどの学期に授業を受けたのか？
学生のクラスの成績やクラスを受講した時期は、学生と入学したクラスとの関係の属性と考えることができます。
このジャンクション テーブルを段階的に構築していきましょう。
学生にリンクしたフィールドとクラスにリンクしたフィールドを持つ新しいテーブルを作ることができます。 このテーブルを「Grades」、「Enrollment」、「Students/Classes」など、このテーブルが「Students」テーブルと「Class」テーブルの間のジャンクション テーブルであることを覚えやすい名前にすることができます。
このジャンクション テーブルのプライマリ フィールドを入力する必要があります。 ジャンクション テーブルのレコードに名前を付ける最も良い方法の 1 つは、テーブル内の他のフィールドからデータを取得して各レコードに固有の名前を構成する、数式を使用することです。 概念間の関係を表すレコードには、一意の主フィールドを設定できないことが多いため、この方法はジャンクションテーブルで特に有効です。
Students または Classes テーブルに戻ると、ジャンクション テーブルにリンクされた新しいフィールドが自動的に作成されているのがわかります。 これらのテーブルにロールアップまたはルックアップ フィールドを作成して、ジャンクション テーブルから Students または Classes テーブルに情報を自動的に取り込むことができます。
例 2: 応募者と面接官
ここでは、ジャンクション テーブルを使用する別の例を示します。 求職者のリストと、面接官のリストがあります。 各応募者は異なる面接官と複数回の面接を行い、各面接官は異なる応募者と複数回の面接を行います。 面接は、応募者と面接官の間の関係と考えることができ、そのため、各面接に関する情報を格納するジャンクション テーブルが必要になります。png
例3：クライアント、クライアントの注文、製品、メーカー
ここではもう少し複雑な例を紹介します。 顧客とその注文、商品とその製造者のリストを整理したAirtableベースを作りたいとします。
同様に、各メーカーは多くの製品を作ることができますが、各製品には1つのメーカーしかありません。
各クライアントの注文は多くの製品を持つことができ、各製品は多くのクライアントの注文の一部になることができます：
しかしながら、ここでの問題は、クライアントの特定の注文における各製品の数量に関する情報を保存する良い場所がないことです。
以下に、Airtableベースでの例を示します。 クライアントテーブルは、クライアントオーダーテーブルにリンクされています:
クライアントオーダーテーブルは、クライアントテーブルとオーダーラインアイテムテーブルにリンクされています:
注文ラインアイテムテーブルは、productsテーブルとクライアントの注文テーブルからのリンクと、各製品の数量を取り込んで、それぞれのラインに固有の主フィールド値を作成します。
productsテーブルは、注文のラインアイテムとメーカーにリンクされています:
計算されたフィールドとジャンクション テーブル
多くのリンクされたフィールドがある場合、実行するデータ入力の量を最小限にするために、ルックアップ フィールドとロールアップ フィールドを有利に使用することが重要です。
たとえば、顧客の注文テーブルに、個々の顧客の注文の合計コストを自動的に計算するフィールドを設けたいとします。
その後、数式を使用して、ラインアイテムごとの合計コストを計算することができます。
そして最後に、顧客の注文テーブルのロールアップ フィールドを使用して、任意の顧客の注文におけるすべての注文行項目の合計コストを合計することができます。