形で覚えるデータベースのテーブル設計

正規化を使って設計するのはめんどくさいと思わなかったでしょうか？
実際には教科書どおりの手順で正規化をすることは少ないです。

この記事を読むことで、現場でどのようにテーブル設計をしていくかを覚えることができます。
実務経験を元にした方法ですので、その形を覚えることで効率的に設計ができるようになります。

テーブル設計の順序

発注や受注といった業務系のシステムを元に紹介します。

教科書的な流れは次のようになります。
要件分析をして必要なデータを洗い出した後に、正規化するという流れです。

この方法は地獄を見るのでおすすめできません。

推奨手順はこちらです。
まず先にテーブル設計をします。その設計に合うように要件定義と業務設計をしていきます。

「利用者の意見を聞かなくていいの？」
と思う方もいるかも知れません。
ですが最初にテーブルの枠が決めることで、
　・議論の方向性が定まり、要件定義がスムーズにいく
　・規定のテーブル設計を使うことでトラブルが起きにくくなる
というメリットがあります。

最初にテーブル設計をすることは、利用者にもメリットがある方法です。

テーブル設計の基本の型

テーブルの8割はこの構成でできているという基本形がこちらです。

・ヘッダーテーブル
・明細テーブ

この２つのテーブルの組合せです。

注文書では次のようになります。

注文番号や会社名が書いてある部分がヘッダーで、品目の情報を持っている部分が明細です。
データーのサンプルを書くと次のようになります。

注文書の構造そのまま書くだけなので簡単ですね。
項目はいったん置いといて、ヘッダーと明細のセットが基本ということを押さえてください。

この型は業務系システムでは頻出です。
発注系ですと次のように業務が進みますが、各業務はヘッダーと明細のセットで表現できます。

このように１つの型を覚えればほぼすべての業務に応用することができます。

補足：もし要件定義を元にテーブル設計を考えたらどうなるか？

発注、受入検収の業務をテーブル設計の基本の型を知らないで作ったらどうなるでしょうか？
発注は問題なくヘッダーと明細のテーブル設計ができると思います。
問題はそれ以降です。

次のように考えて混乱してくる人がでてくると思います。

受入は発注した品目に対して作成するから、発注明細の中に受入情報を入れれば十分だな。
だから
　発注ヘッダー　→　発注明細
の２構成で大丈夫っと。

まてよ、2つ注文した「ゆで卵」が1つずつ納品されたら、行を分割しないといけないな。
　発注ヘッダー　→　発注明細　→　受入検収明細
の3構成の方がいいか。
でも業務ルールで分納は注文明細で行を分けるルールだから、受入検収明細を作る必要ないかもしれないな。ちょっと業務の人に念のため聞いてみよう。

運用後・・・・・
えっ、ミスで「ゆで卵」1つずつ違う日に納品された！！
食パンは1しか注文していないの3つ納品された！！

業務分析を元にすると、深く業務を知らないと設計できないことが問題点です。
業務には運用変更や例外がつきものです。
ユーザの意見を聞いて設計すればするほど深みにハマることになります。

解決策は機械的に型にそって設計していくことです。

・ヘッダーと明細のテーブルを持つ。
・業務が分かれるたびにそのセットを追加する

という考え方で設計していくとスムーズに進みます。
テーブルの設計は下記のようになります。

機械的に同一パターンで設計することが大切です。

まとめ

テーブルの設計は業務分析をしてから作るのでなく、事前に大枠を作成します。
テーブル構成は業務単位にヘッダーと明細の２つのテーブルを機械的に作成します。
業務がそのテーブル設計の枠に納まるように考えながら要件定義をしていきます。

業務系のシステムはほぼヘッダーと明細の組合せでできています。

この型を覚えていると知らない業務システムでも、すぐにテーブル構成を理解できます。
自分で設計するときもわかりやすくスムーズにできるようになります。

とても有益な知識なのでぜひ覚えて役立ててください。