最新記事

月別アーカイブ(タブ)

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)|

136:世界分節とデータベース

2010/04/13 (Tue) 23:34
 冷蔵庫に入れていた白菜に花がついてしまった。
カミさんがその花を切り出して玄関に飾った。
見た目が菜の花そっくりで、知らずに見たら
茎がちょっと太いと感じるくらいでほとんど区別がつかない。
で、webで調べてみた。 どうも、菜の花というのは特定の種を表す語では
ないらしい。 菜の花=アブラナだと思っていた私にとっては発見だった。 
データベースを扱う現場にいると、こういう 「種の細分化」といった発見が、
生活の上での何気ない一場面とは済まされなく感じるようになる。 
このような細分化(分節化)と、グループによる括り(仲間分け)が、
データベースの設計の上で重要だからだ。 それはどういうことか。

 我々が何か物を見るとき、見たものの名前や種など、分節された世界の一部を
見ることになる。以前の私にとってはアブラナと白菜は同じものだけれども
パンジとかヒマワリのような花からは区別されていた。 それが細分化された
ということは、世界認識の仕方(分節の仕方)の一部が変形したことを意味する。 
「学習」とか「知る」というのはまさしく、世界認識の分節化のプロセスである
と言えるのだ。現代のweb検索の世界も、その延長線上にあるといえる。 

201004101330s.jpg
 2010.4.13 戸張近辺にて

 菜の花とブランコは全く別のものだとすぐに判るのは、
「菜の花=植物」、「ブランコ=無生物」というグルーピング(世界分節)の習慣を
知らず知らずのうちに獲得しているからなのだが、「公園で見られるもの」という
見方に変えれば、どちらも同じ分節の中に切り取られることになる。
(やや無理のある例だが....)

 そこで問題になるのは、どのような世界分節の形態を採用するかということだが、
それは管理したり知ろうとしたりする範囲(スコープ)により異なるものの、
その場その場によって必ず 『最適な』 世界分節の仕方が存在するはずであり、
その形にいかに漸近させるかを考え抜くところにデータベースの妙味がある。 
もっと言うと、菜の花やブランコは物質であるのに対して、「人の好み」とか
「動詞の態」、「権利」、「時間帯」、「自治体」といった抽象的な概念を扱わなければ
ならない場合などは更にハナシが込み入ってくる。 システムの可能性と限界の間で、
それらをうまくまとめることが出来るかどうかに、データベースを扱うセンスが
表れるのだと思う。
----------------------------------------------
Written by: dicdic
http://dicdic.web.fc2.com/index.html
----------------------------------------------

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


データベースコメント(0)トラックバック(0)|

135:雪柳、菜の花

2010/04/03 (Sat) 18:25
大津川-手賀沼(西側)-利根川-利根運河 と走りました。
先週より寒く、上着を着て走りました。

4月から職場が変わりましたが、
こうして走れることに感謝です。

※クリックで拡大します。
201003271407s.jpg

201003271258s.jpg

201003271259s.jpg

この時期に桜のリポートはあまりにベタなので、
雪柳と菜の花を。

201004031257s.jpg

あけぼの山公園は、角ごとに警官が配置されるほどの
警戒ぶりでした。 しかし、本当の見頃は明日のようです。

利根川は寒くなく、上着を着てても暑くなく、最高の天候でした。
サイクリストも大勢いました。
201004031454s.jpg
201004031353s.jpg

----------------------------------------------
Written by: dicdic
http://dicdic.web.fc2.com/index.html
----------------------------------------------

テーマ : ジョギング・ランニング - ジャンル : スポーツ


ランニングコメント(0)トラックバック(0)|

ブログ TOP


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