データベースの設計の重要な考え方の一つに「正規化」というものがある。まぁザックリ言うと、なるべく同じデータの重複を防ぐための加工法である。
例えば、社員名簿を表形式で管理する場合を考えてみよう。もちろん、どんな情報を管理するのかは会社によるであろうが、社員なので当然、社員の氏名は必要になる。
しかし、社員の氏名は同姓同名の人が登場した場合、どちらがどちらを示すのかがわからなくなってしまうため、一般的には識別可能なIDのようなものを一人一人に対して割り当てる場合が多い（というか厳密な管理が求められるものはほぼ全てそうなっているはず。）データベースではこういったユニークな番号（それがあれば何を示すのかが唯一に特定することができるもの）を主キーと言う。ここでは仮に社員番号としておく。
さて、社員番号と社員の紐付けが管理できていれば、会社の従業員全員を把握することはできる。しかし、それだけの情報では、その人がどこの部署にいるのかもわからないし、連絡の取り方もわからない、顔も分からなければ、年次や役職についても不明である。
情報として有効に活用するためには、当然、その社員の属性（所属部署や電話番号等）がに紐付けられている必要がある。例えば、携帯電話の電話帳に電話番号だけを登録していても誰当ての電話なのかがわからないし、名前だけが登録されていてもどの番号に電話をかければいいのかわからない。二つ揃って初めて意味のある情報になるのである。
というわけで、様々な情報を活用するために、社員番号、氏名、所属部署、勤務地、電話番号、Emailアドレス、役職のデータが紐付けられているとしよう。社員一人につき上記の情報が一行に表され、それが社員全員分の行がつらつら並んでいる管理簿が出来上がったことになる。管理という点においてはこれが一先ずゴールである。
しかし、実態というのは常に移ろいゆくものである。例えば、この管理簿に登録されていたAさんの勤務地がB地点からC地点に変更されたとしよう。この場合、Aさんの行について、勤務地を変更する必要がある。また、勤務地によって電話番号が定められているとしたら、電話番号も同時に変更しなければならないことになる。
もちろん、社員に関する情報が変更になる分には修正は微量で済むかもしれない。ただし、例えば、D担当の部署の電話番号が変更になった場合などにおいては、Dという担当に所属する社員全てを探し出し、それら全てについて電話番号を変更しなければならなくなってしまう。
このようにただ純粋に一つの表に一元で管理されているデータというのは同じ情報があらゆる箇所に登場することにより、保守性が低くなってしまうのである。そして、それを解消するのが正規化である。今の場合だと、各勤務地に対して「勤務地コード」を割り当て、全く別の表として勤務地と電話番号のみ紐付けられた管理簿を作成する。そして社員の管理簿上の勤務地には勤務地コードを記載しておく。
するとどういうことになるかというと、勤務地の電話番号が変更になった場合は、勤務地管理簿における該当勤務地の電話番号を一行分変更するだけでよい。なぜなら、勤務地や勤務地コード自体には変更がないため、社員管理簿上から参照するべき勤務地コードには変更がないからである。予め適切なプログラムを書いていれば、必要最小限のデータを変更するだけで、必要なデータを引っ張ってくることができるのである。おそらく、データの持ち方としては一番最適化されている。
ただし、ここに落とし穴がある。このように最適化されたデータの保管方法が適切であるのはデータベースに閉じた話である、ということだ。それももう少し昔はデータベースにおいても最適ではなかった。なぜなら、あらゆる表からにデータを集めるためには既に一元管理されたデータを参照する場合に比べ、多くの処理時間がかかるからである。
どうも私の部署では、この、データベースの設計手法にインスパイアされたのか、同じ記述を避ける傾向がある。例えば、Aというドキュメントの１章と同じ内容が、Bというドキュメントの２章にも登場する場合、「Aの１章参照」と一言だけ記述されている場合が多い。
もちろん、それ自体を否定する気はない。とは言え、Aから「B参照」と書かれてあり、Bを見ると「C参照」と書かれている箇所があまりにも多いと、実際全体としてどんなことをしているのかが把握しづらくなってしまう。人間はデータベースではないのだ。一定限度以上に最適化すると、今度は逆に処理時間がかかってしまうことも忘れてはいけない。
