« たったひとりで踊るために | トップページ | DB設計セミナー開催します(東京7/30-31) »

2012.06.24

フィールド数のメトリクス

 「CONCEPTWARE」の販売管理システムと生産管理システムについて、テーブルに含まれるフィールドの数を集計してみた(2つのシステムに含まれるテーブル数は、それぞれ68本と83本)。その結果、通常のテーブルに含まれるフィールドは「25個以下」であることがわかった。また、フィールド数が「10個以下」のテーブルが全体の6割以上を占めることもわかった。私も意外だったが、テーブル毎のフィールド数は案外少ないものだ。

Fieldstables

 含まれるフィールド数が25個より多いテーブルは、いずれも「月次統計情報」であった。必然的に多くのフィールドを含むものなので、それらを特殊なものとして除けば、「フィールド数はふつう25個を越えない」という経験則を導き出せそうだ。私の過去の経験から言っても違和感はないし、賛同される技術者も多いのではないかと思う。

 もちろん、25個以上のフィールドを抱えるテーブルが設計として直ちにおかしいという話ではない。最近、友人が設計したデータモデルを見せてもらったのだが、その中のあるテーブルはフィールドを100個以上含んでいた。しかしその定義を見て納得できた。管理すべき属性項目が多い概念をたまたま扱っていただけで、そういう管理対象は実在する。

 いっぽうで、フィールドを25個以上含むテーブルが全体の比率として目立つようであれば、ピアレビュー(同業者によるレビュー)で設計妥当性を検証する必要があるだろう。私は500個のフィールドを含むテーブルを見たことがあるのだが、正規化を理解していない技術者は平気でそういう設計をする。彼らに悪気はないのだが、自分の仕事について他人からとやかく言われる経験がない。そんな姿勢のままでは成長できないうえにまわりに迷惑をかけるので、ピアレビューでボコボコにされ鍛えられたほうがいい。

 いっぱんにDBを正規化することで、フィールド数(テーブル当たりでもDB全体でも)が減って、テーブル数が増える。異なるテーブルに分散して置かれていた重複フィールドが整理されるとともに、「横持ち」されていた繰り返しセグメントが「縦持ち」の形に別テーブルとして切り出されるためだ。

 それと同時に、テーブル数が減るような動きも伴う。たとえば、従来は部門毎に別れてサイロ化していたマスターがひとつに統合されたりする。この場合、ひとつのテーブルに管理部門の異なるフィールドが混在することになるが、UIで捌けるので問題はない(ただし運用上の扱いが異なる等の理由で分けたほうがいいこともある)。また、正規化とは関係ないが、グローバル変数毎に別れていたテーブルが「システム変数テーブル」や「システム区分テーブル」として統合される動きもある。これらの動きを総合することで、テーブル別のフィールド数のちらばり具合も似通ってくるだろう。

 このように、フィールド数やテーブル数は設計妥当性を判断するための一定のメトリクス(数値指標)となるが、もうひとつ興味深い指標がある。「主キーに含まれるフィールドの数」だ。2つのシステムで以下のような比率になった。いずれもキーに含まれるフィールドの数は4個が最多であった(4個以上を含むケースはあまりなく、私の経験でこれまでの最多は7個である)。

               1個  2個  3個  4個
テーブル数(販売管理) 53%  24%  13%  10%
テーブル数(生産管理) 46%  24%  18%  12%

 予想できたことだが、主キーに含まれるフィールド数が1個(単独主キー)のテーブルがいちばん多く、2個、3個と増えるたびに減っている。このちらばりを「単独主キー」と「複合主キー」に分けるとつぎのようになる。

              単独主キー 複合主キー
テーブル数(販売管理)   53%     47%
テーブル数(生産管理)   46%     54%

 単独主キーのテーブルの中には、意図的にサロゲートキーを導入したものが1割ほど含まれるので、実質的には複合主キーのほうが多い。生産管理のように複雑なデータ要件をともなうシステムでは、さらに複合主キーが増える傾向がある。いっぱんに「DBに含まれる半数かそれ以上のテーブルが、複合主キーにもとづく関数従属性要件を伴う」といえそうだ。

 「単独主キー主義」、つまり単独主キーの一本槍で戦えると考える技術者は、この現実を知っておいたほうがいい。扱うテーブルの数が10本や20本であれば、単独主キー主義でもなんとかなるだろう。サロゲートキーを組み込む羽目になるテーブルが10本以内で済むからだ。しかし、50本以上のテーブルを扱う本格的なDBシステムであれば、サロゲートキーのような搦め手ではなく、正面から複合主キー要件に立ち向かわざるを得ない。そこで単独主キーにこだわれば、「サロゲートキーの掟」の網で締め上げられる。

 それゆえに、少なくとも基幹システムのように本格的なDBを相手にするのであれば、サロゲートキーは「設計スタイル」ではなく「設計上の高度なテクニック」として限定的に用いられるべきだ。なお、複合主キーの必要性が「IDかコードか」とか「ナチュラルキー」云々の議論と無関係であることは、「ナチュラルキーを主キーにしてはいけない」で説明したとおりだ。

 単独主キー主義にはそのような制約があるにもかかわらず、ある種の開発ツールが単独主キーを強制するのはなぜか。複合主キーを禁止することで「システムの複雑さを抑えるため」ではない。基本的には「開発ツールそのものの複雑さを抑えるため」だ。意地悪く見れば「そのツールで簡単に開発できそうに見せかけるため」にも役立っているのかもしれない。しかし実際はその逆で、その種のツールで複雑なDBを扱うためには、むしろレベルの高い設計スキルが求められる。それだけは理解しておこう。

|

« たったひとりで踊るために | トップページ | DB設計セミナー開催します(東京7/30-31) »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: フィールド数のメトリクス:

« たったひとりで踊るために | トップページ | DB設計セミナー開催します(東京7/30-31) »