はじめに

すべての実用的なアプリには3つの層が必要です。データを保存する場所、データが変化したときに何が起こるかを決定するルール、そして反応するための手段です。従来のコードベースでは、SQLマイグレーション、ORM、コントローラー、cronジョブを書きます。ノーコードのアプローチでは、これらを図形のビルディングブロックに置き換えて、同じ結果を生み出します。このレッスンでは、データベースツールを選び、関連する2つのテーブルをモデル化し、行が作成されるたびに実行されるワークフローを設定します。グリッドビューで関係性を確認しやすいAirtableを主な例として使用しますが、同じパターンはSupabase、Baserow、Xanoにも当てはまります。

最初のベースのセットアップ

baseはテーブルを格納する最上位のコンテナです。base内では、各テーブルがスプレッドシートのようなグリッドになっていて、列はすべて型付けされたフィールドです。フィールドタイプを行に対する「質問」と考えてください。Single Line Textフィールドは短い文字列を尋ね、Numberフィールドは数字を強制し、Dateフィールドはカレンダー値を格納し、Linked Recordフィールドは別のテーブルの行を指します。最初から適切なフィールドタイプを選ぶことで、不正なデータの流入を防げます。

Airtableを開き、「Bookings」という名前のbaseを作り、2つのテーブル「Customers」と「Appointments」を追加します。Customers内に以下のフィールドを追加します：

Customers
- Full Name      (Single line text)
- Email          (Email)
- Loyalty Points (Number, integer)

次にAppointmentsテーブルに移動して追加します：

Appointments
- Date           (Date)
- Service        (Single select: Haircut, Color, Trim)
- Price          (Currency, USD)
- Customer       (Linked record → Customers)

Customerフィールドが名前をコピーする単なるテキストフィールドではない点に注目してください。これはリンクなので、顧客行を削除しようとすると警告が表示され、顧客でのビュー絞り込みは瞬時に行われ、ロールアップフィールドでロイヤリティポイントを横断的に取得できます。

データ関係の定義

すべてのプロジェクトで再利用することになる関係の形が3つあります。1対多は、1つの親行が複数の子を所有することを意味します（1人の顧客が複数の予約を持てる、など）。多対多にはジャンクションテーブルが必要です（1人のスタイリストが複数のサービスを提供でき、1つのサービスを複数のスタイリストが担当できる、など）。1対1はまれで、通常は同じテーブルに置くべき2つのフィールドが存在していることを示しています。

AirtableではLinked Recordフィールドはデフォルトで1対多です。多対多として動作させるには、両側で複数レコードへのリンクを許可すると、Airtableが自動的にジャンクションを作成します。Stylist-Serviceブリッジのスキーマは次のようになります：

Stylists
- Name        (Single line text)
- Services    (Linked record → Services, allow multiple)

Services
- Name        (Single line text)
- Duration    (Number, minutes)
- Stylists    (Linked record → Stylists, allow multiple)

両側にある対称的なフィールドが、その関係を双方向に横断可能にしている理由です。片側だけにリンクがある場合、逆方向からのクエリは何も返さず静かに失敗します。これが「ワークフローが動かない」バグのよくある原因です。

ビジュアルワークフローの構築

ワークフローとは、トリガーとアクションの連なりで、コードを書かずに実行されます。最も一般的なトリガーは、特定のテーブルでの「レコードが作成されたとき」です。最も一般的なアクションは、「メール送信」、「別のテーブルにレコード作成」、「レコード更新」です。Booking appの実用的なワークフローは次のとおりです。新しいAppointment行が作成されたとき、 appointmentのPriceを追加して対応するCustomerのLoyalty Pointsを自動的に更新します。

Airtable Automationsでの設定は次のようになります：

Trigger:   When record created  →  Table: Appointments
Action 1:  Find records         →  Table: Customers, where Email = {Appointment.Customer.Email}
Action 2:  Update record        →  Table: Customers (the record from Action 1)
                                  Loyalty Points = {Current Loyalty Points} + {Appointment.Price}

中括弧のトークンが、ステップ間でフィールド値を渡す方法です。実行時に評価されるため、後でフィールド名を変更した場合は、トークンピッカーで再選択する必要があります。さもないとワークフローが壊れます。テーブル全体で自動化を有効にする前に、必ずサンプル行でテストしてください。すべての履歴行に対して発火するオートミンは、暴走スクリプトに相当します。

よくある間違いと簡単なチェック

ノーコードバックエンドの失敗のほとんどは、3つのパターンに集約されます。1つ目は、Linked Recordが必要な場所でSingle Line Textフィールドを使用することです。参照整合性が失われ、ロールアップが機能しなくなります。2つ目は、フィールドが空でないことに依存するロジックを条件分岐を追加せずに組むことで、トリガー行が不完全な場合に静かにエラーが発生します。3つ目は、ワークフロー内で4つ以上のアクションを連結し、各ステップを個別にテストしないことです。ステップ3が失敗した場合、ステップ1と2が役割を果たしたかどうかがわからなくなります。

信頼性の高いデバッグ方法として、ワークフロー内で参照したすべての変数を要約する最後の「自分にメール送信」アクションを追加することです。この1行で、フィールド不一致のバグの80%をキャッチできます。メール本文には置換されたトークンの実際の値が表示されるからです。

まとめ

2つのテーブルを持つbaseをセットアップし、CustomersとAppointmentsの間の1対多のリンクをモデル化し、予約が記録されるたびに loyalty pointsを更新するオートメーションを作成しました。覚えておくべきメンタルモデルは次のとおりです。テーブルは事実を格納し、リンクフィールドは関係を符号化し、オートメーションは反応を符号化します。明日のレッスンでは、この同じデータをフロントエンドビルダーに公開し、ユーザーが実際のUIを通じてやり取りできるようにします。