データベース設計の手順｜正規化とアンチパターンを、業務アプリを作る前の非エンジニア向けに

この記事は、表を何枚に分け、何を項目にするかという考え方と手順を扱います。表と線を図にする方法はER図の書き方で、手元のスプレッドシートを分ける作業はスプレッドシートのデータベース化で説明しています。

「データベース設計」と検索すると、SQLやツールの解説が多く出てきます。一方で、中小企業の現場で相談を受けるのは、顧客や案件の管理をAIや業務アプリで作り直したいが、何を決めてから頼めばよいか分からない、という場面です。この記事では、プログラムを書かない人が、AIに頼む前に決めておくことに絞って、手順を説明します。

データベース設計は、業務の言葉から表を決める6ステップで進める

データベース設計は、画面を描く前に「何を表にし、1行を何と数えるか」を決める作業です。次の6つを上から順に進めます。

1. 覚えておきたいものを、業務の言葉で書き出す：「お客様」「案件」「請求」「商品」のように、現場で使っている名詞を付箋かメモに並べます。システム用語は使いません
2. 名詞ごとに表を1枚ずつ作り、1行が何を表すかを一文で書く：「案件の表は、1行が1つの契約を表す」のように書きます。この一文が書けない名詞は、まだ表にしません
3. 表ごとに項目を並べ、項目ごとに「なぜ要るか」を書く：使う場面を言えない項目は作りません。足りなければ、運用して必要になった時点で足します
4. 表ごとにIDを振り、表どうしをIDでつなぐ：名前や電話番号はあとで変わります。変わらない番号を1列目に置き、他の表からはその番号で呼びます
5. 正規化で、同じ情報が2か所に書かれていないかを見直す：1つのセルに複数の値がないか、主役のIDで決まらない項目が混ざっていないか、他の項目から決まる項目を置いていないかを、表ごとに確かめます。履歴として残す項目だけは、あえてコピーを持たせます
6. 誰が・何で入力し、どの表とつながるかを表にする：ここまでを1枚にまとめたものが、AIやアプリ制作者に渡す資料になります

3番目の「項目ごとに、なぜ要るかを書く」は、地味ですが効きます。顧客管理の作り直しでは、「列は後から足せるから急がなくていい」という話が出ました。足せるのは事実ですが、項目を作る前に理由を書いておくと、使われない項目で入力画面が長くなることを防げます。

正規化は、同じ情報を2か所に書かないための3つの問い

正規化は、データベースの教科書では第1〜第3正規形という段階で説明されます。業務アプリの設計で使うときは、「この情報は、いまの表に置くのが正しいか」を問い直す作業と考えれば十分です。表ごとに、次の3つを当てます。

表の3つの問いは、左の列にある第1・第2・第3正規形にそれぞれ対応します。Microsoftの解説も、第3正規形をほとんどのアプリケーションに必要な最高レベルとしています。中小企業の受注管理や案件管理なら、第3正規形まで見直せば足ります。それより先の段階は、実際の設計ではほとんど考慮されません。

一方で、正規化しすぎない場面もあります。請求書の表に、請求した時点の単価と宛名をそのまま残すのがその例です。商品の表の単価を後で改定しても、過去の請求金額は変わってはいけないからです。値を呼び出すのか、その時点の値を残すのかは、「あとで変わったときに、過去の記録も変わってよいか」で決めます。

現場で起きやすいアンチパターン6つと、直し方

アンチパターンは、よくある失敗の型のことです。どれも、作り始める前なら表の1行を書き換えるだけで直せますが、運用が始まってからだと、入力済みのデータごと直すことになります。

「項目は後から足せる」で始めると、初日に止まることがある

案件管理の基盤づくりで、「列は後から追加できるので、今は決めなくていいのでは」という問いが出たことがあります。仕組みとしては正しい指摘です。ただ、その考え方で始めた管理は、運用初日に止まりました。足せない箇所があったからです。

足しやすいものと、直すと全部が動くものは、次のように分かれます。

決めておかなかった場合に何が起きるかは、支援先で2つ見ています。

• 1行の単位：既存のお客様は、商品ごと・契約期間ごとに登録していました。一方、新規の案件は、複数の商品を1件にまとめたり、月ごとに金額が変わる契約を1行に入れたりしていました。そこで、登録の単位を請求書と同じ「商品×契約期間」にそろえました。請求書はお金の動きが最後に確定する書類なので、そこに合わせると案件管理と請求のずれが出にくくなります
• 呼び名：在庫を管理したいという相談で現場に行くと、在庫のシステムは前の年に導入済みでした。動いていなかった理由はシステムではなく、商品の呼び名が決まっていないことでした。システムを入れ替える前に、呼び名の一覧を作る必要がありました

取引先名や商品名を誰がどう管理するかは取引先マスタの責任者設計、商品の粒度の決め方は商品マスタの粒度で扱っています。

AIに作らせる前に、確認表を1枚にまとめる

ここまでを1枚にまとめたものが、AIに渡す資料になります。AIにコードを書かせる前に、誰が・何を使って・どのデータとつながるかを決めておかないと、修正のたびに別の場所が崩れ、修正の沼にはまります。確認表は次の形で足ります。

この表を埋めてから「この内容でデータベースの設計案を出して。足りない点があれば先に質問して」と頼むと、AIの案を1つずつ確かめられます。AIが出した案を確認するときは、表ごとに「1行は何を表すか」を自分の言葉で言い直せるかを見ます。言い直せない表があれば、AIが業務を取り違えているか、こちらの説明が足りていません。要件全体の整理は要件定義をAIで進める方法、作らせるときの進め方はAI駆動開発のベストプラクティスに書いています。表と線を図にして確かめたいときはER図をAIで作成する方法が使えます。

設計の良し悪しは、直した回数と問い合わせ回数で測る

設計を決めたあとの1か月は、次の3つを数えます。始める前の数字を先に控えておくと、比べられます。

• 表の形を変えた回数：項目の追加ではなく、表を分ける・統合する・IDを付け直すといった変更の回数です。回数が減らないなら、1行の意味が決まりきっていません
• 同じ相手・同じ商品の重複：名前の列を抜き出し、同じものが何通りの書き方で入っているかを数えます
• 「これはどこに入れるのか」の質問：入力する人から出た質問の回数を記録します。質問が多い項目は、名前か置き場所が分かりにくい項目です

表の形の変更が続くなら、2番目の手順に戻り、1行の意味を書き直します。重複が減らないなら、手入力できる経路が残っています。入力はプルダウンかフォームに限ると、表記ゆれは止まります。SalesDockは、経営者の方が業務の流れと数字の置き場所を整えて、仕組みとして定着させる支援をしています。表の形を整理する段階から、現場の業務に合わせて一緒に決めることもできます。

一次情報・公式情報

• Microsoft「データベース正規化の説明」（同じ情報を複数の場所に置かない、第1〜第3正規形の考え方。Microsoftのアーカイブ記事）

製品の仕様は変更されます。最新の情報は公表元でご確認ください。

データベース設計のよくある質問