DynamoDB は外部キーに対応していますか？

対応していません。DynamoDB に外部キー、参照整合性制約、カスケード削除はありません。NoSQL データベースとして、アイテム間やテーブル間のリレーションシップを強制することは決してありません。代わりに、リレーションシップは自分でモデル化します。関連データを 1 つのアイテムに非正規化するか、シングルテーブル設計で関連アイテムを共有のパーティションキーの下に同居させるかです。そうしてモデル化したリレーションシップを見て辿るには、DynoTableの Smart Tables が 2 つのテーブルの関係をキャンバス上に描き、結合された行を閲覧させてくれます。

外部キーが存在しない理由

外部キーは、正規化されたテーブルをまたいで結合を支え、整合性を強制するために存在します。DynamoDB は意図的に JOIN 演算子を省いており（AWS は代わりに非正規化を推奨しています）、したがって外部キー制約は、クエリモデルが決して活用しないリレーションシップを取り締まることになります。別のアイテムのキーを属性として 保存する こと自体は何も妨げられません。DynamoDB がそれを検証したりカスケードしたりしないというだけです。

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

埋め込む — 小さく上限のある子データは、リストやマップとして親アイテムの中に置きます。
同居させる — 親と子がパーティションキーを共有し、ソートキーで区別します。こうすれば 1 回の Query でリレーションシップ全体が返ります。これがシングルテーブル設計の核心です。
複製する — 各アクセスパターンが必要とするフィールドを、それを必要とするアイテムにコピーします。1 リクエストで読める代わりに、書き込み時の手入れを引き受けます。

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

重要な場面で整合性を強制する

制約に頼りたくなるようなケースのために、DynamoDB は部品を用意しています。条件式は、書き込もうとしているアイテムの状態に対して書き込みをガードします。そしてトランザクションの ConditionCheck は、同じ全か無かの操作の中で別のアイテム（たとえば親）が存在することを検証できます。カスケード削除は、明示的なアプリケーションロジックか、Streams 駆動のクリーンアップになります。

実際に実行するとどうなるか

pk = "CUSTOMER#1" の下に PROFILE アイテム 1 つと ORDER# アイテム 2 つを置き、プロフィールを削除して、そのパーティションをもう一度クエリしました。

Count: 2
[{"sk":{"S":"ORDER#1"},"pk":{"S":"CUSTOMER#1"}},
 {"sk":{"S":"ORDER#2"},"pk":{"S":"CUSTOMER#1"}}]

削除は成功を返しました。孤児が 2 つ、警告なし、捕捉すべきエラーもなしです。PostgreSQL なら、同じ削除は、宣言した制約に応じて失敗するか、カスケードするか、子側の参照を null にします。

次に、それにいちばん近い代替を試します。3 件目の注文を書く前に親を条件チェックする TransactWriteItems です。

TransactionCanceledException: Transaction cancelled, please refer cancellation
reasons for specific reasons [ConditionalCheckFailed, None]

CancellationReasons: [
  {"Code":"ConditionalCheckFailed","Message":"The conditional request failed."},
  {"Code":"None"}
]

配列の位置は TransactItems の位置と対応しているので、[ConditionalCheckFailed, None] は、アクション 0（親のチェック）が失敗し、アクション 1（子の書き込み）は問題なかったことを示します。ガードが 1 つならこれは素直に読めますが、アクションが 8 つあると、どれが壊れたのかを知る手段はこの配列だけです。

課金もされます。トランザクション書き込みはアイテムあたり 2 書き込みユニットを消費し、AWS は "this capacity is consumed even when the transaction is canceled" と明言しています。拒否された書き込みは、受理された書き込みとまったく同じだけかかります。

さらに詳しく

まずシングルテーブル設計から始め、ガードの条件は式ビルダーで組み立て、そうしたリレーションシップをビジュアルに閲覧するには DynoTable をダウンロードしてください。Smart Tables が親と子のテーブルをキャンバス上で結合するので、アイテムコレクション全体を 1 つのビューで見られます。

参考資料

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

孤児となった子のクエリとキャンセルの出力は、2026-07-28 に Node v24.18.0 上の @aws-sdk/client-dynamodb 3.1095.0 で DynamoDB Local 3.3.0 に対して再現しました。