今さら「楽々ERDレッスン」を読んで
市の図書館でなんとなく見つけた、「楽々ERDレッスン」。
なんと2006年に書かれた本だが、DB設計のとっかかり方をよく解説している本だった。
仕事を始めた時にこの本に出会えれば良かったと思うし、これからDB設計を始める後輩にもお勧めしたい本だと思う。
データベースの性能やアーキテクチャはどんどん変わっているが、RDBMSである限り、この本はまだまだ有用だなと感じた。
仕事をやっていると、
「あ～これあるある！」
「この間バグになったのがこれのせいだったんだよなぁ」
「あの時きちんと設計しておけば、こんな大改修にならずに済んだのに」
と共感する人もいるかも。
”DB理論にとらわれすぎず、お客様の業務にとって一番価値の生み出せる設計にできるかどうか”に重きを置いて説明している。
特に気になったものを取り上げると・・・
One fact in One place（１つの場所に１つの事実）
例えば、下記のような「売上伝票」のリレーションがあったとする。
教科書通りに「自明な関数従属性」を排除したり、繰り返し項目を排除すると、下記のようになる。「商品」を切り出した際に、「単価」を商品の方に持っていった。
ただ、もし
「価格は商品マスタの単価ではなく、割引期間中は単価を下げて提供することがある」
「特定の組み合わせだったら合計額が割り引かれる(だから、商品の単価をSUMっただけでは出ないよ)」
といった要件があったら・・・？
その場合は、「商品伝票明細」に「(販売)単価」が必要だし、「商品伝票」に「合計金額」が必要かも知れない。
・商品の価格は「単価」であらわされる
・でも割引することもある
という事実が2つある場合は、1つのリレーションで解決しないようにする必要がある。
(これは極端な例だけど、こうした要件漏れがあって、本番に移ってから不具合として顕在化することもある。)
DB設計はブロック分け・イベント抽出から
ともすると、先に登場人物（物・人間等）を抽出して、何とか属性を洗い出そうとする人もいるが、それは間違い。
まずは大まかなブロック分け(受発注・在庫管理・与信～等々)から始め、その次にイベント（注文とか予約等、～するという動詞・形容動詞にするとしっくりくるもの）を洗い出す。
リソース（商品、顧客... etc)はその次だ。
この順序に従ってERDを作成する演習を紹介しているため、「なんでこの順番に設計するの？」というのが非常にしっくりくる。
データを経営資産としていかに活用し、価値を生み出すか
この本は上記の事が複数の個所で繰り返し書かれている。
DB設計者は背景にある業務について強く意識しないといけない。
プロジェクト内でデータベース設計を任される人間は、
「表にある繰り返し項目や関数従属性を排除して正規化を進めるべきだ」
「元表に近い形で設計して高速に表示させるようにしたい」
等々、なまじDBの仕組みやセオリーを知っているだけに上記の考えがよぎってしまう。
DBの専門知識は当然重要だが、DB設計の本当にそもそもの目的は
”データを経営資産としていかに活用し、価値を生み出すか”
という事だ。
DBの技術的背景よりユーザー業務の理解から始めるのが妥当であり、要件の漏れも少なくなる。性能要件やディスク領域とかの話はその次なのだ。
