難しいとされるデータベースの設計ですが、それができる人はいとも簡単にやってしまうことを目の当たりにして、何かコツはあるのだろうなとは思うところでしょう。そのコツは実は言語化しづらいものではあるものの、それを実例を通じてなんとか言語化してみようというのが一連の記事の目標でもあります。以前にも説明したように、数学的な意味で基礎から積み上げた理屈は完全に正しいものです。しかしながら、現実のデータベース設計を全て数学ではできません。なぜなら、要求がベースにあり、要求が数学的な意味で正しく定義できるような場面は現実にはないからです。要求は曖昧なところだらけなのです。なので、実際のデータベース設計では、表という基本的なデータ構造を書いたりあるいは思い浮かべたりしながら、矛盾のないデータ構成を作り上げるということを行います。
ここまでは、部署ごとにどんな表が必要かということを出発点にしました。もちろん、これは単一部署で使うようなシステムでも、ともかく業務で発生するデータを表の形にまとめてみて、そこから検討を行うという方法を取りました。もちろん、共通の情報は共通化する、つまりよく言われるマスター化するということを行うのですが、「商品」という同一名称のものが部署によって扱いが異なると、それは同じ商品でいいのかどうかということを考えなければなりません。ここまでの記事は一例であり、実際の案件ではもっといろんな制約や要求が出てくると思われます。こうして、いくつかの表が登場した時、その表の関係性を見ると、理想的には、１対多になっているということです。表に分けるというのは、実は１対多の関係を洗い出していることに他なりません。一方、１対１の関係は、同一の表に存在することが多くなりますが、これはちょっと言い訳がましい説明です。ともかく、１対多の関係を見つけるということが重要になります。
ここまで、営業部門での単純な納品書を考えてきました。そして、システム開発ではよくある仕様変更です。「仕様変更はしてはならない」ということは今では言えないことになっています。仕様変更を受け入れないと、顧客が望むシステムに到達できないからです。顧客が自身の業務を知っているのは当然と思うかもしれませんが、実は全くそんなことはありません。業務ができるというのと知っている、そしてそれを説明できるというのは全く異なります。まず、業務ができるとは言っても、1人が全部把握していることはほぼありえず、結局は複数の従業員にノウハウが分散しているのは一般的です。そして、それら業務の関連を理解していてワークフローに展開できるかというとそれができる人はまた限られますし、下手をすると社内では誰もそれができないこともあります（そういう事例にも当たったこともあります）。説明可能性はもういうまでもないですね。ズバリ言えば、お客さんの頭の中はファンタジーでいっぱいで、お客さんが話す内容はポエムなのです。私たちエンジニアは、ポエムで記述されたファンタジーを、実際に稼働するシステムへと展開する役割を持つ非常に重要な立場にいるのですが、過剰にポジティブに考えると余計凹むかもしれませんね。
ともかく、システム構築をしているとこんな話が出てきたとしましょう。納品書のレイアウトができてきて、テストをし始めると、ある担当者が口走ったとしましょう。
仕様検討する段階で持ち込んだ納品書のサンプルには、なぜか出荷日がなかったのか、どうだったのか、ともかく、出荷日が必要だそうです。これは、レイアウトに必要なのか、あるいは記録として必要なのか、どっちなのかもよくわかりませんが、そういうファンタジーだと諦めましょう。
次回より、この「出荷日が必要」という要求がどんな世界に発展するかをじっくりと追いかけることにします。