db-normalization について
リレーショナルスキーマを監査し、1NF から 3NF と、記録された非正規化を確認するモジュールです。静的な DDL チェックと読み取り専用クエリを使い、データベース設計レビューで疑わしい問題を検証します。
主な機能
- 011NF・2NF・3NF の確認
- 02繰り返し列と区切りリスト列の検出
- 03未文書化の非正規化の確認
- 04DDL の静的解析
- 05読み取り専用の検証クエリ
活用シーン
- 01リレーショナルスキーマ設計の監査
- 02列に格納されたリストの検出
- 03テーブル列間の依存関係の確認
- 04データベースで疑わしい問題を検証
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ hainrixz/ claude-db --skill db-normalizationインストール後、Claude Code で/db-normalizationを入力して読み込まれたか確認します。
詳細
db-normalization(M1)
正規化はリレーショナル設計の要です。各事実の格納先を一つに定めることで、更新・挿入・削除時の異常を取り除きます。このモジュールでは、1NF→3NFと、意図的に設けられた文書化済みの例外(読み取りパスのための非正規化)を監査します。対象は設計軸のみです。ドキュメント/KV パラダイムでは、プロファイル内の Access-pattern&embedding がこのモジュールに置き換わります。Mongo のコレクションが「3NF を満たしていない」ことを理由に減点しないでください。
チェック項目
- 1NF — 原子性:リストを格納する列(カンマ区切りの値を含む
tags VARCHAR、phone_numbers TEXT)、繰り返しグループの列(addr1, addr2, addr3、item_1, item_2)、または結合テーブルの代替として使われる配列です。静的なシグナルには、列名のパターンと、サンプル DDL/コメント内で区切りデータを含むtext/varchar型があります。 - 2NF — 部分関数従属:複合 PK において、キー以外の列がキーの一部だけに依存している状態です(例:
order_items(order_id, product_id, product_name)で、product_nameがproduct_idのみに依存している場合)。 - 3NF — 推移的関数従属:キー以外の列が、別のキー以外の列によって関数従属している状態です(例:
employees(id, dept_id, dept_name)の場合、dept_nameはdepartmentsに属します)。 - 非正規化の管理:生成列の定義、トリガー、文書化された更新方法のいずれもない重複列/導出列(
total、full_name、キャッシュされた件数など)は、気づかないうちに実データと乖離します。db-defaults-generated(M6)と相互確認してください。
軸と重大度
- 軸:設計。重大度は高・中・低の段階で示し、異常発生率を捏造しないでください。
- 書き込み頻度の高いテーブルの繰り返しグループ/列内 CSV:重大度 3〜4、
warn/fail、確信度はdirectional(静的)です。 - 冗長な更新可能データを生む推移的関数従属:重大度 3、
warnです。 - 乖離するおそれのある、文書化されていない非正規化の重複:重大度 3、
warn、fixable: proposedです。 - M1 が重大度 5 の上限を設けることはありません。Modelado カテゴリの値に影響します。
Tier-0 静的チェック
scripts/parse-schema.mjs で DDL を解析し、列一覧を調べます。区切り文字付きリストを格納する列名、番号付きの繰り返し列、および別のテーブルのエンティティ名と一致する名前を持つキー以外の列(*_id と並ぶ *_name、*_label)にフラグを付けます。プログラムソースの解析結果は directional のままとし、上限を設けてはいけません。
Tier-1 検証クエリ
列内 CSV が実際に複数の値を含むことを確認します。
-- $DATABASE_URL, read-only; does the column hold delimited lists?
SELECT count(*) AS rows_with_delimiter
FROM <table>
WHERE position(',' IN <column>::text) > 0; -- >0 confirms 1NF violation
推移的関数従属について、行をまたいで関数従属が成り立つことを確認します。
SELECT dept_id, count(DISTINCT dept_name) AS distinct_names
FROM employees GROUP BY dept_id HAVING count(DISTINCT dept_name) = 1;
稼働中の DB を利用できない場合、件数の検証に関する検出結果は needs_api のままにしてください。黙って問題なしとしてはいけません。
検出結果
schema/finding.schema.json に従って出力します。例:
M1.users.tags_csv_in_column—tags VARCHAR(255)にカンマ区切りの値が格納されています(重大度 4、fail、fixable: proposed、軸design、確信度directional)。M1.order_items.partial_dependency_product_name— キー以外のproduct_nameが複合 PK の一部に依存しています(重大度 3、warn、軸design)。M1.invoices.total_denormalized_undocumented— 生成列/トリガーによる更新方法がないtotal導出列です(重大度 3、warn、fixable: proposed)。 各検出結果では、evidence.observedに実際の DDL 行をそのまま引用します(シークレットは伏せます)。verification.reproduceは上記の実行可能なコマンド(静的チェックではmethod: ddl_parse、Tier-1 ではquery_stat/schema_introspect)です。expected_impactは、根拠と確信度タグを付け、段階的に示します。
正直さ
- 非正規化は正当な選択であり、場合によっては適切です。フラグを立てるのは、更新方法や文書化がないなど、管理されていない非正規化だけです。非正規化そのものを問題視してはいけません。
- 1NF/2NF/3NF はリレーショナルモデルに適用されます。ドキュメントストアに埋め込まれたドキュメントは正規化の欠陥ではありません。その判断はドキュメントプロファイルで行います。
- Tier-1 クエリによる裏付けなしに、異常の発生頻度や行数を決して捏造しないでください。