第3正規形

部署が引っ越して、社員 40 人分の行を直す

社員の表に、所属部署の ID だけでなく、部署名と所在地まで書いてある設計を考えます。画面に出すときに結合しなくて済むので、最初は快適です。

開発部が横浜に移転しました。直すべきは開発部の所在地 1 か所のはずなのに、実際に書き換える行は開発部に所属する 40 人分あります。休職中の社員の行を 1 つ見落とせば、同じ開発部に東京と横浜が並ぶことになります。

この 40 行の書き換えは、業務としては 1 つの出来事です。1 つの出来事に対して 40 回の書き込みが必要なら、そのどこかが失敗する確率も 40 倍になります。

新設した部署を登録できないのも、同じ原因です。まだ 1 人も配属されていない部署には、名前を書く行がありません。

主キーを経由しないで決まる列がある

前の段階との違いは、主キーの形にあります。この表の主キーは社員 ID 1 列だけで、組にはなっていません。それでも冗長が残っています。

矢印を書くとこうなります。

部署名は社員 ID から直接決まっているのではなく、部署 ID を経由して決まっています。決めているのは主キーではなく、主キー以外の列です。主キーの一部が犯人だった前の段階と違い、ここでは主キーとまったく関係のない列同士が結びついています。

見つけ方は簡単です。主キー以外の列の中から、他の列を決めてしまう列を探します。部署 ID がそれです。部署 ID とそれが決める列をまとめて部署の表へ移し、社員の表には部署 ID だけを残します。これで移転は 1 行の書き換えになり、配属者ゼロの部署も作れます。

実務で見かける形は、たいてい地味です。注文の表に郵便番号と都道府県が並んでいる。社員の表に役職コードと役職名が並んでいる。商品の表に分類コードと分類名が並んでいる。どれも前の列が後ろの列を決めています。コードと名前が隣り合っていたら、まず疑ってよい形です。

真実は 1 か所にだけ置く

やっていることは、コードを書くときの「同じことを 2 度書かない」とまったく同じです。同じ事実の置き場所が 2 か所あれば、いつか必ず食い違います。食い違ってからでは、どちらが正しいのか誰にも分かりません。

主キー以外の列同士に、こうした決定の関係が残っていない状態が第 3 正規形です。この先にはボイスコッド正規形や第 4 正規形といった段階もありますが、名前を知っていれば十分です。第 3 正規形まで進めておけば、書き換えのときに起きる食い違いはほぼ防げます。

分けたあとに困るのは、画面に部署名を出したいときです。結合が 1 つ増えます。それでも、部署が 100 件、社員が 100 万人という規模なら、部署 ID に索引が貼ってあるかぎり実用上の差は出ません。間違った部署名が出るより、1 回の結合を足すほうが安い。結合を怖がって分けないほうが、あとで高くつきます。