« 代理キーは「スタイル」ではなく「テクニック」 | トップページ | 「オーバースペック」でコストが下がる話 »

2006.09.09

テーブル関連を「コード」で構成することの是非

 前回のエントリーは各方面で議論を引き起こしたようだが、「複合キーを許すべきかどうか」ではなく「関連をコード項目で構成すべきかどうか」の議論が目立ってしまった印象がある。筆者がもともと主張したかったことは「複合キーを許すべきかどうか。それは許される」である。つまり、その識別子項目が何と呼称されるものであっても、他の識別子項目と「複合」して識別子を構成するケースがいくらでもあるというものだ。

 たとえば「商品テーブル」の識別子が何と呼ばれようが、そして「倉庫テーブル」の識別子が何と呼ばれようが、それらが複合したものを識別子とする情報のまとまりが存在し得る(「在庫テーブル」だったりする)。それに単独項目の識別子を与えるよりも、素直に商品と倉庫の識別子を複合したものを識別子として与えたほうがいいよ、というのが筆者のもともとの主張である。

 では、「関連をコード項目で構成すべきかどうか」の議論はどのようなものだろう。

Hanbaimodel 具体例で説明しよう。この図は近日公開予定の「CONCEPTWARE/販売管理」の「在庫管理サブシステム」のデータモデルである。基本設計のWEB公開を前提に、実ユーザーからヒアリングしながら数ヶ月前からまとめているものだ。棚(棚記号で識別される物理領域のこと)にはいろいろな商品が置かれるが、倉庫毎に、それぞれの商品を保管すべき棚は決まっている。また、「在庫推移監視方式」を実現するために、「出荷明細」などのさまざまな取引のスーパクラス「受払明細」を、過去から未来に渡る受払情報とみなしている。そんな業務要件を反映しているモデルだ。

 「CONCEPTWARE/販売管理」の実物でUI(ユーザインタフェース。パネル等の入出力フォームのこと)のデザインを見てもらえばわかるのだが、このモデルにある「商品№」と「倉庫№」の値はユーザーからは見えない(そういう項目を「○○コード」と呼ぶか「○○id」と呼ぶか「○○№」と呼ぶかは瑣末な問題である)。それらの値は、ユーザーが商品情報や倉庫情報を登録するたびに自動採番されて内部的に設定される。したがって、現場において商品は「商品№」でなく「メーカー品番」あたりで荷捌きできることが前提である。いっぽう、「棚記号」の値については、規定のコード体系にもとづいてユーザーが意識的に決めて入力する。

 「商品№」と「倉庫№」を用いてテーブル関連が構成されていることには何も問題はない。それらはユーザから見えないのでコード体系が変化しようがないからだ。ところが「棚記号」の体系はユーザーがその都度に決めるもので、棚構成が変われば変わり得る。そういう項目にもとづいて、このモデルのようにテーブル関連を形作っていいものだろうか――というのが「関連をコード項目で構成すべきかどうか」の議論の意味あいである。ここで言う「コード項目」とは「実世界(それは変わり得る)の事情に体系が連動している項目」くらいと理解してもらえばいい。

 「棚記号」のコード体系は、倉庫での物理的な棚構成や、置き場所としての論理的な構成をどう認識するかで決まる。その枠組みが未来永劫変わらないことはあり得ないので、それでテーブル関連を構成することはいかにも危なっかしく見えるかもしれない。しかし、この場合はこれでかまわないのである。

 棚記号の体系が変わるとき、倉庫で棚記号ラベルを張替えなければならない。商品の棚間移動もしなければならない。それと同時にDB上の棚記号の体系と在庫レコード上の棚記号の値も打ち変えてやる必要がある。このように、棚記号のコード体系が変化することにともなって業務上の一定の撹乱が起こるが、それは実務上もシステム上も致命的なものではない。日常的ではないにせよ、手順を踏んで対処可能な業務上の一場面である。

 そういうわけで、「関連をコード項目で構成すべきかどうか」の筆者の回答としては「それで問題のあることもあればないこともある。問題があるようなら避ける」という中途半端というか煮え切らないものだ。かように現実は、単純なモデリング方針をあざわらうかのように多様かつ繊細である。

 だからこそ設計者はその都度頭を絞らねばならないのだが、そういう悩みは筆者のように考えることが好きなモノズキにまかせておけばよい。とくに初学者は「CONCEPTWARE/販売管理」のようなリソースを用いてスマートに軽やかに学べばよい。複合キー否定派もオブジェクト指向系モデラーも「CONCEPTWARE」をどんどんダウンロードして活用してほしい。そういうものを叩き台とすれば、それぞれの信念に沿うモデルもよほど効率的に組み立てられるからだ。スクラッチモデリングよさらば、である。

|

« 代理キーは「スタイル」ではなく「テクニック」 | トップページ | 「オーバースペック」でコストが下がる話 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: テーブル関連を「コード」で構成することの是非:

« 代理キーは「スタイル」ではなく「テクニック」 | トップページ | 「オーバースペック」でコストが下がる話 »