データベースをスキーマにリンクすると、Entity Enricher はエンリッチメント済みのエンティティをお客様が所有するリレーショナルテーブルとして維持します。エクスポートファイルではなく、revenue カラムを持つ実際の company テーブルです。すぐに実行できる SQL スナップショットを一度ダウンロードし、その後は冪等な upsert による増分デルタフィードでデータベースを収束させ続けます。
一度保存し、オンデマンドで投影します。 エンリッチメントは現在のエンティティの状態をエンティティレイヤーに書き込みます。リンクされた各データベースはその状態の投影であり、一度限りのスナップショットと、確認応答するデルタフィードとして提供されます。スキーマの編集にかかるのは再投影のみで、データ移行は発生しません。
database_sync: falseを渡します）。他のユーザーのエンリッチメントは通常どおりルーティングされ続けます。.sql スナップショット（テーブルとデータ）をダウンロードし、お使いの PostgreSQL に適用してください。この DDL には結合インデックスと外部キーが含まれています（entity が削除されると、子行とリンク行がカスケード削除されます）。ファイルヘッダーには、どの差分カーソルから再開すべきかが記載されています。各エンティティタイプにはデータベースキーがあります。これは、テーブルが一意インデックスおよび upsert の競合ターゲットとして使用するカラムの組み合わせです。データベースを連携すると、AI による分類パスがデータベースモデル全体（キー、カラム型、インデックス、所有権）を提案し、内容をご確認いただけます。提案できない場合は、単純な優先順位にフォールバックします。オブジェクトにセマンティックIDがあればそれを、なければID らしきフィールド（id、product_id、…）、それもなければオブジェクトの自然キーを使用します。テーブル上では、セマンティックIDはsemantic_idカラムとして作成されるため、idという名前は自由にお使いいただけます。これらはデータベースの「Model」タブでいつでも変更できます。ただし公開後の変更はマイグレーション相当となるため、変更後はスナップショットを再ダウンロードしてください。そのタブからスキーマを公開するまで、データベースには何も反映されません（連携しただけではテーブルも行も作成されません）。
データベースキーは決してnull許容にできません。null値はどのレコードにも一致しないため、エンティティを更新する代わりに、エンリッチメントのたびに新しい重複を挿入してしまいます。そのため、キーが空で返されたエンリッチメントは、保存されずに拒否されます。エディターはこの2つのフラグを区別しており、両方を設定したスキーマは保存時やデータベースのリンク時に拒否され、修正方法として次の2つが示されます。プロパティを常に存在させるか、別のプロパティを型のキーにするか、です。
データベースキーがセマンティックIDではなくエンリッチされたテキストフィールドである場合、保存される値は送信したテキストではなくモデルの回答になります。リクエストで企業を Embraer と指定しても、そのフィールドは固定されません。エンリッチメントが Embraer S.A. と回答することもあり（表記の統一、法人格の補完、識別子の省略など）、その値が行のキーになります。そのため、送信した値で行を検索しても見つからない場合があります（保存された各エンリッチメントとともに返される entity_keys をご利用ください）。また、後から異なる表現で実行すると別のキーとなり、既存の行が更新されずに 2 行目が挿入されます。これはエンリッチされたテキストで構成されるキーに共通の挙動です。解決策は、その型に セマンティックID を設定することです。同じ名称のさまざまな表記が単一の安定したアイデンティティに解決されるため、モデルがどのように表記しても行は維持されます。スキーマの生成時に有効化してください。後から追加する場合は、すべてのオブジェクトを編集する必要があります。
配列内にネストされたオブジェクトは、順序を保持する接合行を持つ独立したテーブルになります。アイデンティティを持たない値オブジェクトは、親のカラムにフラット化されたまま残ります。プロパティ名はそのまま（引用符付きで）使用されます — カラム名はスキーマのプロパティ名そのものであり、ネストされたパスが PostgreSQL の命名可能な長さを超える場合にのみ短縮されます。
投影は決定的です。同じスキーマは常に同じテーブルと列にマッピングされます。プロパティ名はそのままverbatim列名になります（引用符付き）。型名はsnake_case化されてテーブル名になります（VideoGame → video_game）。唯一の例外は長さです。PostgreSQLは63バイトを超える識別子を保持できないため、深くネストされたパスは収まるように親オブジェクトを短縮します（morphological_description_ → morpdesc_）。そのオブジェクトのすべての列に同じプレフィックスが使われ、リンク前にModelタブで表示・編集できます。プロパティは、データベースにすでに存在する列に合わせて、プレフィックスを完全に削除することもできます（product_identifiers.stock_keeping_unit → sku）。これはModelタブの名前の横にあるリンクトグルで行います。すべてのテーブルには、再実行を収束させるために使われる_sync_revision列が含まれます。
| スキーマ内 | データベース内 |
|---|---|
| アイデンティティ（セマンティックIDまたはキー）を持つオブジェクト | 専用のテーブル。データベースキーが一意インデックスおよびアップサートの対象になります |
| スカラーフィールド（string、number、boolean） | 型付きカラム（TEXT、BIGINT、NUMERIC、BOOLEAN） |
| クローズドセット（値のリストに限定されたフィールド） | 単なる TEXT カラムです — CHECK もデータベースの enum 型もありません。リストは AI が回答する際に適用されるため、後から値を追加してもデータベースが移行されることはありません。制約が必要な場合はご自身で追加してください — 同期がそれに触れることはありません |
| NULL許容またはNULL非許容のフィールド | 非 null 許容フィールドは既定で NOT NULL 列となり、下の品質ゲートと連動します。最も厳格なゲートでは、必須参照の外部キーにも NOT NULL が付きます。この強制を無効にすれば（登録時でも、後からでも構いません。初回同期後の変更はフィード内でガード付きマイグレーションとして配信されます）、すべての列を null 許容のままにし、完全性の担保をゲートだけに任せられます |
| 多言語フィールド | すべての言語を保持する単一のJSONB列 |
| 埋め込み値オブジェクト（識別子なし） | プレフィックス付きの列にフラット化されます（dimensions_width） |
| 値オブジェクトの配列 | 親をキーとし、順序付けされ、削除時にカスケードする子テーブル |
エンティティの配列 / $ref リレーション | ソース行とターゲット行をリンクし、順序を保持する中間テーブル |
キーフィールド（identifying） | 高速検索のためのセカンダリインデックス |
| クエリ形状インデックス（順序付きフィールドリスト） | 宣言された形状ごとに 1 つの複合インデックスを作成し、対象となる一覧画面のクエリと同じ順序で並べます。ファセットと閉じた集合を先頭に、ソートまたは範囲のカラムを最後に配置し、多言語フィールドも含めます（そのような形状はデータベースが受け取った言語ごとに 1 つ作成されます）。分類パスが理由とともに提案し、Model タブで調整します。エンティティごとに複数作成できます |
| 検索フィールド（インデックス意図） | 検索ボックスが断片一致で検索するテキストに対するトライグラムインデックス（pg_trgm）です。多言語カラムでは言語ごとに作成され、上限はありません。ドロップダウンの値には決して作成されません。それらはクエリ形状のインデックスに属します（多言語のものも含め、そのようなインデックスはデータベースが受け取った言語ごとに 1 つ作成されます）。拡張機能のないレプリカでは、データベースのオーナーがインストールするまでスキップされます（何も行いません） |
| 座標ペア（緯度 + 経度） | ペア全体に対する 1 つの空間インデックスです（PostgreSQL ネイティブの GiST、拡張機能は不要）。半径検索、最近傍検索、地図の表示範囲のクエリに使用します |
| 期間ペア（開始 + 終了の境界） | ペア全体に対する 1 つの範囲インデックスです。重なりの判定や「この日付時点で有効だった値」といったクエリに使用します |
1 つのデータベースは複数のスキーマを同期できます。リンクされたスキーマ間で同じ名前を持つエンティティタイプは、データベースキーによってマージされ、同じテーブルに格納されます。各スキーマのエンリッチメントはそれぞれ自身の列のみを更新するため、2 つのスキーマでエンリッチされた企業は、両方の列セットを持つ 1 行になります。スキーマ固有のタイプは単に独自のテーブルを追加し、フィード内の自動マイグレーションデルタを通じて配信されます。再ダウンロードは不要です。
スキーマをリンクすると、比較ステップでどのテーブルがマージされ（キーと追加される列を含む）、どれが新規かが正確に表示されます。テーブルを共有するスキーマは、そのテーブルの既存のデータベースキーを採用し、レビュー用に表示されます。スキーマ間で共有するものが何もない場合、フローは代わりに専用のデータベースを提案します。スキーマのリンク解除でデータベースが変更されることはありません。同期されたテーブルはそのまま残ります。
スキーマのリンク解除、または同期の削除を行うと、当社側に2つのものが残ります: もう何も書き込まれない保存済みのエンティティの状態と、スキーマが保持するデータベースプロパティ（データベースキー、カラム型、インデックス、所有権）です。どちらの確認画面でもそれらの削除を提案しますが、それはデータベースがまったく残っていないスキーマに限られます — 他の場所でまだ同期されているスキーマはすべてを保持します。スキーマ自体、そのエンリッチメントのレコード、そのコストが影響を受けることはありません。
リンクされたスキーマには公開契約があります。これはエンリッチメントとデータベースが実際に使用するバージョンです。スキーマを編集しても作業コピーが変更されるだけです。文言の変更は自動的に反映されますが、構造的な変更（新しいフィールド、型やキーの変更）は公開を押すまで待機します。公開すると正確な影響がプレビューされ、適切なマイグレーションがデルタフィードに送られます。新しい列はALTER TABLEデルタとして届き、より重い変更（新しいデータベースキー、型の変更）はご自身のデータベースに対してガード付きマイグレーションとして実行されます。データがそれを妨げる場合（キー値の欠落または重複）、フィードは正確な問題を示して一時停止し、修正すると自動的に再試行します。
公開機能はデータベースのModelタブにあります（スキーマがリンクされている間、Workflow Editorはそこへ誘導するバナーを表示します）。公開する前に、両方の状態が表示されます。現在データベースが従っている契約と、作業コピーで変更されるすべての差分です。編集に納得できませんか？公開版に戻すを使えば契約が元に戻ります。これは取り消し可能で、脇に置いたドラフトは24時間復元可能なまま保持されます。
リンク解除中に編集されたスキーマを再リンクする場合も同様に動作します。同期はデータベースがすでに持っているものを記憶し、差分のみを送信し、その間に書き込まれた行のためのスナップショット更新を加えます。手動での DROP は一切不要です。
同じお約束は当社自身のアップグレードにも適用されます。新しいリリースでschemaのテーブルへのマッピング方法が改善された場合、お客様の同期は自動的に移行されます。追加的な変更はそのままフィードに届きます。アップグレードによって既に保持しているテーブルの形が変わる場合、当社が予告なくお客様のデータに手を加えることは一切ありません。配信が一時停止され、Database Syncページで適用をお願いし、何が変わるかを事前に正確に表示します。
多言語 enrichment もここでは第一級の機能です。ローカライズされた値は、enrichment のすべての言語を保持する JSONB カラム として届き — {"en": "Headache", "fr": "Céphalée"} — 一つのデータベースがすべてのロケールを同時にまかないます。クエリ内で直接言語を選択でき(name->>'fr')、JSON 差分ペイロードにも同じ言語キー付きオブジェクトが含まれます。
データベースは登録時にひとつの問いに答えます。エンリッチメントに欠落（非 null 許容フィールドが埋まっていない状態）があった場合、何を書き込むか？ 答えは 3 段階になっています。何も書き込まない：ネストされたオブジェクトの中も含め、どこかに 1 つでも欠落があれば、エンティティは拒否されます。不完全な子を除いてエンティティを書き込む（既定）：エンティティ自身の行は完全でなければなりませんが、壊れた子はエンリッチメント全体を巻き込まずにスキップして報告されます。すべて書き込む：欠落は NULL として格納され、何も拒否されません。ただしエンティティの状態は後勝ちで、最新のエンリッチメントがそのまま行になるため、後から実行した不完全な結果が、以前に埋まっていた値を消してしまいます。厳格な 2 段階は、まさにこの消失を防ぐために存在します。
ゲートを通過しなかったエンリッチメントもレコードとして保存され、record.created Webhook も発火します（database.saved は false になります）。どの必須フィールドが欠けていたかが正確に示されるため、不完全なデータが黙って消えることはありません。欠落した各フィールドについて、モデルが不明であると明示したのか、単に出力しなかったのかも示されます。前者はより高性能なモデル、Web 検索、またはソース文書が必要なサインであり、後者はスキーマまたは入力を見直すサインです。常に必須となるのはデータベースキーのフィールドだけで、キーの値が欠けているエンリッチメントはどの段階であっても拒否されます。
厳格な段階では、チェックボックスひとつで同じ契約を自分のデータベースにも反映し、常に存在するすべてのフィールドを NOT NULL 列にします。最も厳格な段階では必須参照の外部キーにも制約が付き、受け入れられる行にそれらが欠けることはありません。不完全な子をスキップでは、外部キーはあえて null 許容のままです。自身の値が欠けたリスト項目は破棄され、対象が不完全な共有 1 対 1 参照（開業年が誰にも分からないスタジアムなど）は切り離されます。その対象は書き込みも更新もされず、保存された行はそこへのリンクを持たないため、該当する外部キー列にはちょうど NULL が書き込まれます。いずれもエンリッチメントのレスポンスで報告され、トップレベルフィールドの欠落は常に拒否されます。初回同期後にポリシーを変更しても、作業が無駄になることはありません。フィード内でガード付きマイグレーションとして配信され、データベースに既にある行に対して検証されます。
2 つ目のゲートは重複した識別情報を検出します。同じリストの 2 つの項目が同じデータベースキーに解決される場合 — モデルが異なる 2 社に同じ id を作り出した、あるいはキーが両者を区別できない場合 — 行は 1 つしか存在できないため、最後の項目が書き込まれ、それ以前のものは破棄されます。他の箇所と同じ last-write-wins のルールです。各衝突は、両方の項目の識別値と判定とともに報告されます。重複は同じ値の繰り返しであり、失われたものはありません。競合による破棄では、記載された値が失われています。モデルが 1 つの対象をノイズを含めて繰り返したか、あるいはこれらが別の対象であり、キーに区別用のプロパティ（地域、年、バージョンなど）が必要かのいずれかです。このリストはレコードに保持されるため、レスポンスが失われたずっと後でも、部分的な書き込みが何を失ったかを確認できます。
再エンリッチメントの前に一つ知っておいていただきたいことがあります。親に属するリストについては、最新のエンリッチメントのリストがそのリストそのものです。最新の回答が繰り返さなかった子行は、データベースから削除されます。これが実際の削除があなたに反映される仕組みであり、レスポンスはそれを報告しません。これは、モデルが列挙するのではなく思い出すタイプのリストの場合に問題となります。ある元素の同位体や人物の受賞歴を二度尋ねると、二度目の回答の方が短くなることがあり、その結果、正しかった行が削除されてしまいます。すべての実行の和集合が必要な場合は、ご自身で履歴を保持してください。
エンリッチメントはリンクされたデータベースへ自動的に反映されます。それ以外のもの、たとえばスキーマを修正する前にゲートが拒否した結果、意図的に反映させなかった実行、先にレビューまたは修正したい出力などは、データベースへのレコード送信を経由します。履歴ページで選択するか、ワークフローから API を呼び出してください。
ラウンドトリップ。Database Sync をオフにしてエンリッチメントを実行し、独自のワークフローで結果を整形または承認してから送信します。送信内容はスキーマの公開コントラクトに対して再検証され、エンリッチメントと同じ受入ゲートを通過します。エンリッチメントで書き込めないものは、インジェクションでも決して書き込めません。
知っておきたい点が 2 つあります。レコードを変更せずに送信すると、そのレコードの下に保存されます。変更した出力を送信すると、元のレコードを参照する新しいレコードが作成されます。レコードは監査証跡であり、それを引用するデータの下で変更されることは決してないためです。これにより、データベースが保持する内容は、常にまさにその値を含むレコードまで追跡できます。また、検証には現時点の契約が使用されます。レコードの生成後にスキーマが変更されている場合は、送信前に履歴ページで警告が表示されます。
履歴ページでは、レコードごとにデータベースへ到達したかどうか（送信済み、一部送信、拒否とその理由）も確認できます。Web アプリ、API、MCP、n8n、Make から利用できます。
フィードはデータベースごとの厳密な FIFO キューです。ウィンドウを取得し（任意でリースを設定でき、クラッシュしたワーカーのバッチがより新しいものより先に再配信されます）、適用して、確認応答します。Webhook 通知はデバウンスされます。新しい差分ごとに待機期間のタイマーがリセットされるため、大量のエンリッチメントが一度にまとめて通知されます。設定可能な最大遅延によって待ち時間に上限が設けられ、取得ページが満杯になった場合は即座に通知されます。Entity Enricher が保持するデータは 2 つのパージオプションで制御します。確認応答時に配信済みの差分コピーを削除するオプションと、データ最小化のために、スキーマに紐づくすべてのデータベースが受信した時点でエンティティの状態そのものを削除するオプションです。いずれも日数による遅延を任意で指定できます。配信済みコピーは確認応答後その日数だけ保持され（再送用のウィンドウ）、配信済みエンティティは更新のないままその日数が経過するまで保持されます。期限切れのものは 1 時間ごとのパージで削除されます。なお、状態のパージは最小化であり消去ではありません。エンリッチメントのレコードは削除するまで残り、パージされたエンティティではエンリッチメント間のマージが無効になります。
テーブルごとの チェックサムエンドポイント により、何も再ダウンロードすることなく、レプリカが収束したことをいつでも確認できます。
すべての操作はアプリ内の一か所、サイドバーの History のすぐ下にある Database Sync で行えます。任意のスキーマにデータベースを登録し（データベースキーのレビューあり）、スキーマをリンク／リンク解除し、スイッチでリンク済みスキーマのエンリッチメント配信を一時停止し（再度有効にするまで新しいデータも通知も届きません。スキーマのパブリケーションは引き続き DDL を送信し、停止中に実行されたエンリッチメントはスナップショットの再取得によってのみレプリカに反映されます）、オプションを編集し、Webhook エンドポイントを確認して署名キーを表示し、スナップショットをダウンロードし、現在のエンティティ状態を閲覧し、保留中のデルタキューを確認し（読み取り専用で、ワークフローのカーソルには一切影響しません）、生成されたテーブルとそのキーおよびジャンクションのエンティティ関連図を表示できます。複数データベースの同期では、図を1 つのスキーマに絞り込むことができます。他のスキーマが供給するテーブル・カラム・リンクはグレーアウトし、その場に表示されたまま残るため、各スキーマが共有テーブルに何を提供しているかが正確に分かります。
複数のデータベースが同じマシンに配置される場合、ツールバーの Sync hosts ボタンを使えば、データベースごとのペアリング作業が不要になります。そのマシンを一度ペアリングし、あとは登録を割り当てるだけです。ホストは各登録を引き受け、物理データベースが存在しなければ作成し、同期を開始します。つまりデータベースの登録は、サーバー上のターミナル操作ではなく、この画面での判断になります。ペアリングは Entity Enricher サーバーごとに行われるため、1 台のマシンで複数のインスタンスを並行して運用できます。
データベースが拒否するステートメント（多くは、新しいユニークインデックスの下で既存の重複が生じることが原因です）があっても、後続のキューが滞ることはありません。そのエンリッチメントのバッチは隔離され、フィードは流れ続け、バッチはデータベースが拒否したステートメントとともに隔離タブに一覧表示されます。原因を修正して再投入してください。再投入では、古いステートメントを再生するのではなく、現在の状態からエンティティを再射影します。不要であれば破棄することもできます。
GET /api/databases//changes?since=…&format=sql の後に POST /api/databases//ack。Supabase をお使いですか？Supabase MCP の比較では、EE のリレーションと同期のルールが製品カタログをどのように守るのかを、JSON と簡単なテーブル図でご紹介します。
同期処理のいずれもデータベースサーバー上で実行されることはありません — 上記のすべての経路は、指定した DSN に接続するアウトバウンドのコンシューマーです。Azure Database for PostgreSQL、OVHcloud、AWS RDS、Supabase、その他のマネージドインスタンスは、セルフホスト型とまったく同じように動作します。コンシューマーをクラウドの DSN に向け（マネージドプロバイダーは通常 TLS を強制するため、sslmode=require を追加してください）、適用してください。
--dsn を向けたラップトップ、小さな VM、またはコンテナ（Azure Container Apps、Docker サイドカー…）があれば十分です。delta_available webhook が Azure Function / AWS Lambda / OVHcloud function を起動し、REST フィードを取得し、SQL を実行し、確認応答します。2つのルールで自作のコンシューマーを安全に保てます：各バッチのステートメントを順番どおりに、1つのトランザクション内で実行し、コミット後にのみ確認応答すること。デルタは冪等でリビジョンによって保護されているため、確認応答の前にクラッシュしても、単にバッチが再配信され、再適用によって収束します。
データベースは有料プランでご利用いただけます（登録できる数はプランによって決まります）。提供開始時の方言は PostgreSQL です。各データベースは自身の方言を宣言し、MySQL / MariaDB、SQL Server、Oracle に対応予定です。