JSON からリレーショナルデータベースへ

Entity Enricher と Supabase MCP の比較

データベースがすべての挿入を受け付けても、算出される購買予算が誤っていることがあります。価格の置き場所を誤ると製品カタログがどのように壊れるか、そして Entity Enricher がレビュー済みのアイデンティティとリレーションシップの判断を、再現可能なテーブルと更新にどのように変換するかをご覧ください。

例を見るDatabase Sync の仕組み

各テーブルに何を入れるかは誰が決めるのでしょうか?

Supabase MCP を使用するエージェント

エージェントが JSON を解釈して SQL を記述します。Supabase MCP はその SQL を apply_migration と execute_sql で実行します。モデリング、識別、繰り返しインポートのルールは、お客様のエージェントまたはアプリケーションが用意する必要があります。

Entity Enricher

キーや、共有型・親所有型のリレーションを含む再利用可能なスキーマをレビューします。エンジンはテーブル、制約、構造インデックスを導出し、以降のデータ変更を同じモデルを通じて反映します。AI はモデルの提案を支援し、そのルールを適用するのはコードです。

この比較は、JSON から Supabase MCP を通じて構築を行うエージェントを対象としています。適切に設計された Supabase アプリケーションでも、これらの安全策を実装できます。以下の誤ったモデルは、モデリング上のリスクを示す例であり、Supabase の既定の動作や実測された失敗率ではありません。

製品は 2 つ。サプライヤーは 1 社。価格は 2 種類。

この架空のカタログには、2 つの製品サンプルが含まれます。サプライヤー SUP-7 はランプを €12、デスクを €85 で販売しています。サプライヤーは共有され、価格とリードタイムは各オファーに属します。

入力 JSON — 同じエンティティタイプの 2 つのサンプル
[
  {
    "sku": "LAMP-01",
    "name": "Reading lamp",
    "offers": [
      {
        "supplier": {
          "supplier_id": "SUP-7",
          "name": "Northstar Supply"
        },
        "unit_cost_eur": 12,
        "lead_time_days": 3
      }
    ]
  },
  {
    "sku": "DESK-02",
    "name": "Writing desk",
    "offers": [
      {
        "supplier": {
          "supplier_id": "SUP-7",
          "name": "Northstar Supply"
        },
        "unit_cost_eur": 85,
        "lead_time_days": 14
      }
    ]
  }
]

Entity Enricher では、これらはスキーマの例であり、自動的なデータインポートではありません。生成されたスキーマをレビューし、サプライヤーを共有、オファーを親所有としてマークしたうえで、公開してエンリッチメントを実行するか、対応するレコードを投入してください。この例では、安定した SKU とサプライヤー ID がアイデンティティを提供します。

外部キーは価格の所有者を示せません

説明用の誤ったマッピング

価格がサプライヤー側に置かれている

product
カラムとキーSQL 型
skuPKtext
nametext
supplier_idFKtext

product.supplier_id → supplier.supplier_id

supplier
カラムとキーSQL 型
supplier_idPKtext
nametext
unit_cost_eurnumeric
lead_time_daysinteger

SUP-7 をデスクのオファーで更新すると、ランプの価格と納期が上書きされます。外部キーは有効ですが、データは誤っています。この構造では、各製品に紐づくサプライヤーも 1 社に限られます。

レビュー済みモデルを使った Entity Enricher

各オファーが自身の事実を保持します

product
カラムとキーSQL 型
skuPKtext
nametext
supplier
カラムとキーSQL 型
supplier_idPKtext
nametext

product 1 → N offer N ← 1 supplier

offer
カラムとキーSQL 型
product_skuPK / FKtext
supplier_idPK / FKtext
unit_cost_eurnumeric
lead_time_daysinteger

サプライヤーの行は 1 件を再利用します。製品とサプライヤーの組み合わせごとに、それぞれ独自の価格とリードタイムを持ちます。デスクのオファーを追加しても、ランプのオファーはそのまま残ります。

テーブル名と自然キーは簡略化し、同期メタデータは省略しています。PK = 主キー、FK = 外部キー。2 つのオファーキーが 1 つの複合キーを構成します。この例では、組み合わせごとに現在のオファーが 1 件であることを前提としています。価格履歴、通貨、数量帯を扱うには追加のモデリングが必要です。

購買予算の変化を見る

購買担当者がランプを100個必要としています。1回目と2回目のインポートを切り替えて、各モデルが返す結果を確認してください。

不正なモデル: ランプ100個の予算

€8,500

€7,300 分、過大に計上されています。利益率レポートと購買予測が、デスクの価格を使うようになります。

レビュー済みの EE モデル: ランプ 100 個分の予算

€1,200

ランプのオファーは €12、リードタイム 3 日のまま維持されます。デスクのオファーは別の行になります。

サンプルデータに基づく説明用の計算です。実際のデータベース呼び出しや計測された金銭的損失ではありません。

テーブルができた後に発生するコスト

断片化したサプライヤーのレコード

インポートのたびに新しいサプライヤー ID を発行すると、購買が重複したプロファイルに分散します。支出合計やサプライヤー比較が誤った内容になります。

Entity Enricher

安定したキーを宣言することで、繰り返し現れるエンティティが収束します。ラベルが揺れる場合は任意のセマンティックIDが役立ちますが、一致結果は引き続きレビューが必要です。

サプライヤー検索の遅延と不要な書き込み

product_sku で始まる中間テーブルのキーは、supplier_id で始まるインデックスの代わりにはなりません。カタログが大きくなるにつれて、逆引き検索のコストが高くなる可能性があります。

Entity Enricher

EE はリレーションシップ用の構造インデックス(中間テーブルの逆引きを含む)を生成し、先頭プレフィックスが重複する冗長なインデックスを回避します。その他のインデックスは実際のクエリに合わせて調整してください。

新しいフィールドが下流のインポートを壊します

JSON にオファーのフィールドが追加されても、対象テーブルやインポート用の SQL には追加されません。新しいデータは読み込みに失敗するか、必要とするレポートに届きません。

Entity Enricher

公開されたスキーマが、テーブル構造とデータの反映の両方を決定します。公開する前に、サポートされているマイグレーションをプレビューしてください。サポートされていない変換はブロックされます。

再試行が処理を重複させたり、新しいデータを上書きしたりします

インポート後に接続が切断されます。リプレイ規則がないと、再試行によって重複が生じたり、古い更新がより新しいオファーを置き換えたりする可能性があります。

Entity Enricher

EE は順序付き配信、アイデンティティに基づくアップサート、リビジョンガードを提供します。PostgreSQL クライアントはバッチをトランザクション内で適用し、コミット後に確認応答を返します。

エンリッチメントは成功、カタログは不完全

モデルは JSON を返しますが、オファーに必須キーが欠けていたり、書き込み先が書き込みを拒否したりします。成功メッセージだけでは、欠落した製品やオファーが見えなくなることがあります。

Entity Enricher

受け入れポリシーによって、エンティティが拒否されたり、不完全な子要素が省略されたりすることがあります。EE は部分的な結果を報告し、レプリカへの配信を個別に追跡するため、修復が必要な箇所を特定できます。

更新のたびにカタログ全体が書き換えられます

変更のないオファーを書き直すと、データベースの処理を消費し、不要なインデックス更新が発生し、下流の変更処理のノイズも増えます。

Entity Enricher

EE はエンティティの状態が変化していないことを検出し、値が変わらない行の更新を防ぎます。コンシューマーは差分フィードで、削除を含む変更を追跡できます。

引き続きお客様の判断が必要なこと

公開する前に、各フィールドの識別、所有関係、意味を確認してください。EE はそれらの決定を実行可能にしますが、お客様のビジネスモデルが正しいことを保証するものではありません。セマンティックマッチングには誤りが生じる可能性があり、クエリ性能は引き続きワークロードとデータベースの規模に左右されます。

最新のエンリッチメントが現在の状態を置き換えます。値が欠落していると以前の値が消え、所有するオファーのリストが短くなると省略されたオファーが削除されます。必要に応じて履歴は別途保持してください。部分的なデータや拒否されたデータは、修正して再送信する必要があります。配信ステータスは自動的な修復を意味しません。

すでに Supabase をお使いですか?

Supabase MCP は、エージェントにデータベースを調査させ、カスタム SQL を書かせたい場合に役立ちます。EE は、同じデータ契約から一貫したリレーショナル更新を継続的に生成する必要がある場合に役立ちます。接続とデータベースの権限が許す範囲で、EE の同期クライアントの出力先として Supabase PostgreSQL を利用できます。アプリケーションのアクセスポリシーの設定は、引き続きお客様が行います。

出典と比較の範囲

2026年9月10日にレビュー済み。Supabase はマイグレーションと、不足しているインデックスを指摘する Advisors を提供します。EE の特徴は、レビュー済みのエンリッチメントスキーマからルールを生成して適用する点です。