« 在庫引当から在庫推移へ(後編) | トップページ | 代理キーは「スタイル」ではなく「テクニック」 »

2006.08.27

関数従属性は多重度に先行して認識される

 「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。

 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるORマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。

 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次TTMレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあるが、「複合キー」はそのような業務要件があれば要請されてしまうもので、そういう要件の頻度は業務システムとして本格的かどうかとは関係ない。id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。

 とはいえ、Railsは伸びしろのある優れたフレームワークである。問題があるようならどんどん報告して改善してもらえばいい。実際、Railsで複合キーを扱うためのプラグインが早くも公開されていることを、その後にある方が見つけて報告してくださった。侮り難しはRailsである。

 ここらへんに関して今回取り上げたいのが「n:n関係」である(Railsでは"has and belongs to many"と呼んでいる)。テーブルAとテーブルBの間に何らかの関係がありそうなことがわかった。よく考えてみると、どうも多重度としては「n:n関係」っぽい。そこで第三のテーブルCを導入しましょう――DOAやOOAに限らず、モデリングの本ではそのように説明されることが多いが、これがなかなかわかりにくい。たとえば「倉庫テーブル」と「品目テーブル」とは「n:n関係」なので、これを解消するためにそれぞれの識別子を複合させたテーブルを「第三のテーブル(この場合ならば在庫テーブル?)」として導入すればいいという話になったりする。

 こんな調子で「n:n関係」から未分析のテーブルやテーブル関連が見出されると説明されても、筆者はどうも腑に落ちない。そのような手順を踏まずとも、必要なテーブルは別途、関数従属性やドメイン(定義域)の規定や業務要件にもとづいて見出されているはずだと考えるからだ。

 そもそも「出荷明細テーブル」や「入荷明細テーブル」や「一般在庫取引テーブル」や「棚卸明細テーブル」などをモデルからはずすことでも、「倉庫テーブル」と「品目テーブル」との「n:n関係」は立ち現れる。どうも「n:n関係」は偶発的な関係でしかなくて、それが「未分析のテーブルの存在を示唆する」とは言えても、その気づきは多様なテーブルを見出すための指針としてはほとんど役に立たないような気がしてならない。

 つまり、「『品目テーブル』と『倉庫テーブル』とのn:n関係を解消するためにテーブルが導入される」のではなく、「『品目コード』と『倉庫コード』の組み合わせを問題にする業務要件が認識されているから、その組み合わせを含む多彩なテーブルが導入される」だけの話である。したがって、筆者にとって「自然」なモデリング過程の説明は次のようなものだ。

1.ユーザとの対話を通じてデータ項目間の関数従属性を把握する
2.これにもとづいてテーブルのまとまりとテーブル関連とを同時に描き出す

 この手順において、テーブル関連(多重度)は事後的に了解されるものでしかないし、「n:n関係」は問題にされようがない。筆者にとって、最初に認識されるものはテーブルのまとまりでもテーブル関連でもなく、関数従属性である。

 しかしまあ以前にも書いたように、どっちのやり方が適切かなんて議論は退屈だ。どんな手順であっても要するに気の利いたモデルを生み出せさえすればよい。近々、在庫管理向けの「気の利いたモデル」を含む「CONCEPTWARE/販売管理」を公開する。こういった教材を用いて学べるようになれば、どんな手順でモデリングを進めるかなんて瑣末な問題になる。教材のモデルをマネしながら身につければいいからだ。

|

« 在庫引当から在庫推移へ(後編) | トップページ | 代理キーは「スタイル」ではなく「テクニック」 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 関数従属性は多重度に先行して認識される:

» [開発] ID or not ID [A.R.N [日記]]
おぉ、ガチだ。 [RDBMS]複合主キー? 18:57 ・・・まだそんなこと言ってる人いるのか。 複合主キー? はぶにっき id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。 関数従属性は多重度に先行して認識さ... [続きを読む]

受信: 2006.08.28 20:58

« 在庫引当から在庫推移へ(後編) | トップページ | 代理キーは「スタイル」ではなく「テクニック」 »