AIでスキーマ設計

🔄 前回のおさらい: レッスン2では、AI活用SQLライティング——スキーマファーストプロンプトパターン、JOINの検証、反復改良をマスターしました。今回はスキーマそのものを設計します。

ビジネス要件からテーブルへ

最良のスキーマはビジネス理解から始まり、技術的決定からではありません：

[アプリケーション/ビジネス]のデータベースを構築中。

ビジネスドメイン:
- [エンティティ1]は複数の[エンティティ2]を持てる
- 各[エンティティ2]はちょうど1つの[エンティティ1]に属する
- [エンティティ3]は[エンティティ1]と[エンティティ4]を接続（多対多）

予想データ量:
- [エンティティ1]: 約[数]行、[増加率]で成長
- [エンティティ2]: 約[数]行

頻繁に実行するクエリ:
1. [クエリ1の説明]
2. [クエリ2の説明]

データベース: PostgreSQL

正規化スキーマを設計：CREATE TABLE文、適切なデータ型、主キー・外部キー・制約、頻出クエリ用インデックス。

✅ 確認クイズ: プロンプトに「予想データ量」を含める理由は？（量が設計判断を変える。100行のテーブルにインデックスは不要——PostgreSQLがミリ秒でスキャンする。1,000万行のテーブルには戦略的インデックスが必要。量は計算値を格納するか（速度のために非正規化）クエリ時に計算するか（正確性のために正規化）の選択にも影響。）

正規化：ルールに従うべきとき

AIは通常、完全に正規化されたスキーマ（第三正規形）を提案します。多くの場合正しいですが、常にではありません：

正規化すべきとき：

• データが頻繁に変更される（顧客住所、商品価格）
• データ整合性の保証が必要（財務記録）
• 複数エンティティが同じデータを参照（不整合の回避）

非正規化すべきとき：

• 高速な読み取りが必要で、書き込みの遅延を許容できる
• データがほとんど変更されない（履歴記録、ログ）
• レポーティング/分析用データベース（スタースキーマ）

データ型の重要性

制約とインデックスの追加

AIに見落としがちな制約を提案させましょう：NOT NULL（必須データ）、CHECK（データ検証：正の金額、有効なステータス）、UNIQUE（重複禁止）、DEFAULT（適切なデフォルト値）、そして頻出クエリ用インデックス。

✅ 確認クイズ: インデックス提案時にAIに頻出クエリを伝えるべき理由は？（インデックスはそれを使うクエリにのみ価値がある。customer_nameのインデックスは、常にcustomer_idで検索するなら無駄。インデックスにはコストもある——INSERT/UPDATE操作を遅くする。AIにクエリパターンを知らせれば、不要なオーバーヘッドなく実際に恩恵のあるインデックスを提案できる。）

まとめ

• スキーマ設計はビジネス要件とクエリパターンから始める——技術的決定からではない
• プロンプトに予想データ量を含める——量が正規化、インデックス、データ型の決定を変える
• AIは過度の正規化または正規化不足の傾向がある——「これを実際に個別にクエリするか？」で検証
• データ型は意図的に選ぶ：金額にDECIMAL、時刻にTIMESTAMPTZ、IDにUUIDかBIGSERIAL
• 制約（NOT NULL、CHECK、UNIQUE）を追加してデータベースレベルでデータ整合性を強制

次のレッスン

次は「データクリーニングと変換」——AIを使って乱雑で不整合なデータを信頼性の高い、クエリ可能なデータセットに変換する方法を学びます。