FC2ブログ

最新記事

月別アーカイブ(タブ)

dicdicのランニング

カウンタ (ホームページと合算)

リンク

最新トラックバック

検索フォーム

カテゴリ

QRコード

QR

:スポンサーサイト

--/--/-- (--) --:--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

スポンサー広告

137:禁じ手、OTLT (一目集約マスター) の功罪

2010/04/18 (Sun) 21:06
ExcelからAccessへという管理台帳のアップグレードを経験したことのある人にとっては、正規化という問題がデータベースを考える上での肝となることはよくご存知と思います。 私も数年前、業務上の必要性から本格的なデータベースを設計・構築した際には、肥大化しすぎた台帳を簡素化してマスターテーブルを次々と作ってゆく過程に快感すら覚えたものです。

しかしここには避けることのできない問題も発生します。
正規化の過程で増殖するマスターテーブルが次第に目障りになってくるのです。
「目障りになる」。 ただこれだけの理由のために、ちょっと特殊なマスター管理を導入する人もいます。 それが「OTLT (One True Lookup Table)」と呼ばれる手法です。 「一目集約マスター」と言ったところでしょうか。「マスターテーブルなんて、どうせコード番号列と漢字列の2列しかないのだから」と考えた人が、「ならば、マスターテーブルを全部合体させてしまおう」と編み出したものでしょう。

「OTLT (One True Lookup Table)」とは、複数のマスターテーブルを1つに集約したものです。 下の図の例では、都道府県マスターとメーカーマスターをひとつにしています。
201004718a.jpg

他にも、性別や商品コードなど、マスター化できる要素は無限に存在しますので、システムによっては300以上のマスターテーブルを持つ必要のあるものも出てきます。そのようなとき、図のようにテーブルをひとつにしておけば便利というわけです。

確かに、オブジェクトブラウザを常時使っている人にとっては、マスターテーブルは目障りかもしれません。私が以前構築したシステムにも、30個ほどのマスターテーブルが存在しており、OTLTを採用してないことをバカにされたものです。 その時には私も助言に応じて、OTLTの作成に取り組みましたが、関係図がどうしてもイビツになってしまいます。台帳テーブルの複数の列から、OTLTの一つの列をめがけて複数の関係線が伸びるという構図になってしまうのです。 OTLTの分身を表記して別々に関係線をのばすという手もありますが、これはデータベースを扱うものとしては生理的に受け付けられるものではありません。 結局、OTLTの導入は断念しました。

J.セルコは、OTLTが便利である反面、様々な問題を誘発すると指摘します。なにより、SQLのパフォーマンスの低下は無視できません。パフォーマンスの低下は、「目障りである」ことの解消の代償としては大きすぎます。 マスターテーブルの大増殖と簡素化の問題。 この二つの折り合いをつけることができるモデルは今のところなさそうです。 マスターテーブルをカテゴリ分けしてテーブルの命名規則を工夫するなど、センスが問われるところです。

※現在、OTLTの問題については日本語の資料は殆ど見当たりません。それは、日本のデータベースシステムでOTLTが横行する理由の一つかもしれません。 OTLTの欠点については下記サイトを参考にしました。
http://decipherinfosys.wordpress.com/2007/02/01/otlt-one-true-lookup-table/


Joe_Celko1.jpg
Joe Celkoのご尊形
スポンサーサイト

テーマ : データベース - ジャンル : コンピュータ


パソコンコメント(0)トラックバック(0)|

≪前の記事 媒体整理
≫次の記事 世界分節とデータベース

コメント

コメントの投稿

名前
題名
メールアドレス
URL
コメント

パスワード
Secret
管理者にだけ表示を許可する

トラックバック

ブログ TOP


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。