|
ExcelからAccessへという管理台帳のアップグレードを経験したことのある人にとっては、正規化という問題がデータベースを考える上での肝となることはよくご存知と思います。 私も数年前、業務上の必要性から本格的なデータベースを設計･構築した際には、肥大化しすぎた台帳を簡素化してマスターテーブルを次々と作ってゆく過程に快感すら覚えたものです。 しかしここには避けることのできない問題も発生します。 正規化の過程で増殖するマスターテーブルが次第に目障りになってくるのです。 「目障りになる」。 ただこれだけの理由のために、ちょっと特殊なマスター管理を導入する人もいます。 それが「ＯＴＬＴ (One True Lookup Table)」と呼ばれる手法です。 「一目集約マスター」と言ったところでしょうか。「マスターテーブルなんて、どうせコード番号列と漢字列の2列しかないのだから」と考えた人が、「ならば、マスターテーブルを全部合体させてしまおう」と編み出したものでしょう。 「ＯＴＬＴ (One True Lookup Table)」とは、複数のマスターテーブルを1つに集約したものです。 下の図の例では、都道府県マスターとメーカーマスターをひとつにしています。  他にも、性別や商品コードなど、マスター化できる要素は無限に存在しますので、システムによっては300以上のマスターテーブルを持つ必要のあるものも出てきます。そのようなとき、図のようにテーブルをひとつにしておけば便利というわけです。 確かに、オブジェクトブラウザを常時使っている人にとっては、マスターテーブルは目障りかもしれません。私が以前構築したシステムにも、30個ほどのマスターテーブルが存在しており、OTLTを採用してないことをバカにされたものです。 その時には私も助言に応じて、OTLTの作成に取り組みましたが、関係図がどうしてもイビツになってしまいます。台帳テーブルの複数の列から、OTLTの一つの列をめがけて複数の関係線が伸びるという構図になってしまうのです。 OTLTの分身を表記して別々に関係線をのばすという手もありますが、これはデータベースを扱うものとしては生理的に受け付けられるものではありません。 結局、OTLTの導入は断念しました。 Ｊ.セルコは、OTLTが便利である反面、様々な問題を誘発すると指摘します。なにより、SQLのパフォーマンスの低下は無視できません。パフォーマンスの低下は、「目障りである」ことの解消の代償としては大きすぎます。 マスターテーブルの大増殖と簡素化の問題。 この二つの折り合いをつけることができるモデルは今のところなさそうです。 マスターテーブルをカテゴリ分けしてテーブルの命名規則を工夫するなど、センスが問われるところです。 ※現在、ＯＴＬＴの問題については日本語の資料は殆ど見当たりません。それは、日本のデータベースシステムでＯＴＬＴが横行する理由の一つかもしれません。 ＯＴＬＴの欠点については下記サイトを参考にしました。 http://decipherinfosys.wordpress.com/2007/02/01/otlt-one-true-lookup-table/  Joe Celkoのご尊形 2010/04/18 |
←前の記事 次の記事→