DynamoDB は外部キーをサポートしていますか？

いいえ。DynamoDB には外部キー、参照整合性制約、カスケード削除がありません。NoSQL データベースとして、アイテムやテーブル間のリレーションシップを強制することは決してありません。代わりにリレーションシップは自分でモデリングします。関連データを1つのアイテムに非正規化するか、シングルテーブル設計で共有パーティションキーの下に関連アイテムを同居させます。

外部キーがない理由

外部キーは、正規化されたテーブル間で結合をサポートし、整合性を強制するために存在します。DynamoDB は意図的に JOIN 演算子を省いており（AWS は代わりに非正規化を推奨しています）、そのため外部キー制約は、クエリモデルが決して活用しないリレーションシップを取り締まることになります。別のアイテムのキーを属性として_格納する_ことは何も妨げられません。DynamoDB がそれを検証したりカスケードしたりしないだけです。強制された参照整合性が譲れないなら、DynamoDB vs PostgreSQL が両モデルの境界線を引きます。

代わりにリレーションシップをどうモデリングするか

埋め込み — 小さく範囲の限られた子データを、リストやマップとして親アイテム内に置く。
同居 — 親と子がパーティションキーを共有し、別々のソートキーを持つことで、1回の Query でリレーションシップ全体が返る。これがシングルテーブル設計の核心です。
複製 — 各アクセスパターンが必要とするフィールドを、それを必要とするアイテムにコピーし、単一リクエストの読み取りと引き換えに書き込み時のメンテナンスを受け入れる。

1対多と多対多のガイドが、それぞれの形を詳しく解説しています。

整合性が重要な場合に強制する

制約に頼っていたであろうケースのために、DynamoDB は構成要素を提供します。条件式は書き込まれるアイテムの状態に基づいて書き込みをガードし、トランザクションの ConditionCheck は、同じ全か無かの操作の中で_別の_アイテム（たとえば親）が存在することを検証できます。カスケード削除は、明示的なアプリケーションロジックか、Streams 駆動のクリーンアップになります。

さらに詳しく

まずはシングルテーブル設計から始め、ガードする条件を Expression Builder で組み立て、アイテムコレクション（親と子を並べて）を1つのビューで見るには DynoTable をダウンロードしてください。

参考資料

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。