AIでデータベース設計を考える方法｜テーブル構成から

AIは要件からentity、table、column、relationの候補を整理する補助になります。ただし、画面で見える項目をそのままtable化すると、同じ事実が複数行に重複し、更新のたびに矛盾が生まれることがあります。まず業務上の事実、識別単位、更新主体、データ保持期間を明らかにし、その後でDBMSの機能とquery patternに合わせてschemaを決めます。

要件をデータの事実へ分解する

設計の入力には、利用者、主要な操作、保存する事実、更新頻度、履歴要件、アクセス境界を含めます。「顧客名を画面に表示する」だけでは、顧客が独立したentityなのか、注文時点の名称をsnapshotとして残す必要があるのか決まりません。現在の値を参照したいのか、過去の時点を再現したいのかで保存方法が変わります。AIには名詞をtableへ変換させるのではなく、各事実について「誰が作るか」「いつ変わるか」「どの操作が読むか」を表にさせます。

表は横にスクロールできます

事実	所有する概念	変化するか	履歴要件	設計上の問い
顧客の現在の連絡先	顧客	変化する	最新値のみか履歴か	注文時の値を別途保存するか
注文した商品と数量	注文明細	注文後は制限することが多い	取引記録として保持	商品master更新後も当時の条件を残すか
支払い状態	支払い / 注文状態	遷移する	変更履歴が要るか	二重処理と取消をどう表すか

これは論点を探す例で、具体的な業務要件を決めるものではありません。決定されていない履歴・削除・監査方針をAIが補完したら、要件へ戻して確定します。

entityと識別子を決める

entity候補ごとに、同じ個体が何度出ても同一と判定する条件を確認します。自然key（メールアドレス等）は変更や再利用、大小文字、正規化の影響を受けます。surrogate keyを使う場合も、自然keyに必要なunique制約を別に設けることがあります。PostgreSQLではPRIMARY KEYが一意かつNOT NULLな識別子となり、FOREIGN KEYは参照先との整合性を保つための機能です。これを踏まえつつ、keyの形式や複合keyの要否はdomain、既存data、公開APIの要件で決めます。

「IDがある」だけでは一意性は保証されません。DB側でuniqueを担保する列、複数列の組み合わせ、NULLを許す場合の意味、ID生成方法、外部systemとの対応を明記します。削除後に同じnatural keyを再利用するのか、IDを外部へ公開するのかも確認します。AIが提案したid列を採用する前に、既存の命名・migration・API契約と合うかを見ます。

relationと制約を図とDDLで対応させる

1対1、1対多、多対多を業務の成立条件から判断します。多対多なら中間tableが候補ですが、その関係自身に開始日、役割、数量、承認状態などの属性がある場合、中間tableが単なるIDの結合ではなく独立したdataになります。optional relationはNULLで表すのか、状態を別列で表すのか、削除時にCASCADEするのかRESTRICTするのかも、data保護と利用操作を考えて決めます。

PostgreSQLのconstraintは、applicationのvalidationとは別の整合性境界を作ります。NOT NULL、UNIQUE、CHECK、FOREIGN KEYが何を保証するかを列ごとに記述し、同じruleを画面だけに置かないようにします。一方で、複雑な業務ruleすべてをCHECKへ押し込めるのが正解とは限りません。複数行や外部依存を伴う条件は、transactionやapplication側の処理も含めて設計します。constraint errorを利用者へどう返すかも契約に含めます。

正規化と読み取りの両立

同じ会社名を注文ごとに持つ場合、改名時に旧名と新名が混在する可能性があります。正規化は、更新・削除時の矛盾を抑えるため、独立して管理すべき事実を分ける考え方です。ただし、請求時点の住所や商品価格など、過去の取引を再現するため意図的にsnapshotを持つ場合があります。重複が見えるだけで常に削除せず、「現在のmaster値」と「取引時点の記録」を区別してください。

AIには、各tableが表す一つの事実、候補key、relation、更新anomalyの例を出させます。その後、代表的な読み取り操作を当てて、joinや集計が許容できるかを見ます。正規化を保つ範囲と、読み取りperformanceのために集約・cacheを検討する範囲は別判断です。早い段階で性能最適化を入れるより、実際のqueryと測定結果を基に検討します。

query patternからindexを検討する

indexは検索を速くする一方、保存容量やinsert/update costを増やし、すべての条件に効くわけではありません。対象DBMSで利用できるindex type、複合indexの列順、filter条件、sort、cardinalityを確認します。PostgreSQLのEXPLAINやEXPLAIN ANALYZEを使う場合、後者はstatementを実行して実測するため、更新系statementや本番dataでは影響を理解してから使います。統計情報やdata量によってplanが変わるため、小さなfixtureだけで全環境を推定しないでください。

AIがindex案を出したら、想定query、既存indexとの重複、更新頻度、query planで何を改善するかを一つずつ対応づけます。列名だけからindexを増やしたり、「検索に使いそう」という理由だけで採用したりしません。database製品によって構文とplannerの挙動が違うので、PostgreSQL固有の説明をMySQL等へそのまま適用しないことも重要です。

Migrationとrollbackを設計段階に含める

新規schemaだけならDDLで終わるように見えても、既存dataがあればnull値、重複、外部key不整合、変換不能値の扱いが必要です。migration planには、事前検査、追加列やtableの作成、backfill、読み書き切替、検証、不要構造の除去という順序を明記します。大きなtableでlockや長時間処理が起こるかはDBMSとversion、実行方法に依存するため、production相当の量と監視方法を確認します。

rollbackは、migration downを用意しただけでは保証されません。既存writeが新schemaだけに入ったあと、旧schemaへ戻すときにdataを失わないかを確認します。戻せない変換なら、復旧方針、backup、停止条件を先に決めます。AIにはDDLだけでなく、旧・新schemaの対応表、backfill例、検証query、失敗時の扱いを出させ、実行前に人がreviewします。

設計を止めて確認する条件

情報が足りないときは、仮のschemaを完成形に見せず、決定が必要な問いを優先順位付きで返します。削除・保持期間、個人情報の暗号化、監査log、複数tenantの境界、二重登録の扱い、履歴を上書きするか追記するかは、product・security・法務の判断を含む場合があります。AIが一般的な案を出しても、既存規程や業務契約に代わるものではありません。

その判断が下るまで、検討用のschema案に仮定をラベル付けし、採用済み仕様と混ざらないようにします。リレーションを曖昧なままforeign keyへ固定すると、後から大量migrationが必要になることがあります。未確定要件を保持した状態で設計を止めることも、誤ったschemaを実装しないための成果です。

最小の設計成果物

設計を終える前に、少なくとも次の成果物を揃えます。

• entity一覧と各entityが表す事実

• key、unique条件、foreign key、削除時の扱い

• 代表的な読み書きqueryと利用者権限

• nullable、default、履歴・保持期間の説明

• constraintが守る条件とapplication validationとの境界

• index案の対象queryと測定計画

• migration順、backfill、validation、rollback

• 不明点と、誰が決める必要があるか

AIの出力に不明点が残ること自体は問題ではありません。重要なのは、未決定のbusiness ruleがDDLへ紛れ込まないことです。schema案に反映する前に、entityの責務とdataの所有者を担当者が確認します。

AIものさしの判断

AIにdatabase設計を任せる範囲は、entity候補、relation、constraint、migrationの抜けを見つけるところまでが中心です。AIのDDLをそのまま適用せず、業務上の事実、既存data、query pattern、DBMSの仕様を照合してください。dataを守る制約と戻せるmigrationが説明できてから、schemaを確定します。

AIの出力を実装へ渡す前に

DDLとmigrationを同時にreviewし、既存dataを入れたときにconstraint違反が出ないか確認します。small fixtureでは、重複key、参照先のないforeign key、NULL、境界値、削除・更新の順序を試します。実行planや性能は対象環境で別途測定し、AIの説明だけで本番適用を決めないでください。