2007年02月12日

データモデル洗練テクニック−「スコープ概念の抽出」と「参照関係の逆転」

データモデルを設計するときに役立つかもしれないテクニックをひとつ。


X社では得意先ごとに異なる条件で売掛金を回収している。だから、売掛金管理システムでは、回収条件を得意先別に登録できるようにしたい。また、1ヵ月後に20%、2ヵ月後に残り全額といった分割回収もある。回収条件を表にするとこんな感じだろうか。

回収条件表

A社は2ヵ月後100%回収、B社は上述した通りの分割回収の例だ。これをデータモデルに落とすと、こうなる。

回収条件DM-素朴な形

このモデルは直観的にわかりやすく、このままでも、まあまずくはない。しかし、あえてもう少し考えてみよう。僕が気になるのは回収条件の一意キーに含まれている[得意先]だ。これは何のためにあるのだろうか。よく考えると、[得意先]は2つの機能を担っていることがわかる。

  1. 回収条件は、複数(1つ以上)の行が集まって、意味あるひとつの単位となる。[得意先]はそのまとまりを識別する機能を担っている。
    − 上の表で言うと、2行目と3行目がまとまって「1ヵ月後に20%、2ヵ月後に80%」という分割回収条件を示している。この2行がひとまとまりであると判るのは、得意先欄に同じ値が記述されているからだ。
  2. 当然のことながら、このように識別された回収条件のまとまりが、どの得意先エンティティに帰属しているかを示す機能も[得意先]が担っている。
それぞれ、「スコープを定義する機能」、「帰属を示す機能」と呼んでおこう。
さてこの二つの機能を[得意先]が担うのは必然だろうか。後者についてはそうかもしれない。得意先への帰属を示すために得意先への参照を用いるのはごく自然に感じられる。しかし、前者については疑問の余地がある。ようするに何行かをひとまとめにする手段があれば良いのだ。[得意先]に頼る必然性はない。そこで、「何行かをひとまとめにする」機能だけを担うあらたなエンティティを登場させよう。モデルは以下のように変更される。

回収条件DM-スコープ抽出@

名前がないと可哀相なので、このエンティティに名前をつけてあげよう。このモデルでいう「回収条件」が複数あつまって(この「あつまり」が新しいエンティティ)、意味あるひとつの業務ルールを表現していることから考えると、新しいエンティティを「回収条件」と呼び、もとの「回収条件」は「回収条件明細」とでも呼び変えた方が良さそうだ。

回収条件DM-スコープ抽出A

さて、これで、[得意先]は「スコープを定義する機能」から解放された。その役割は[回収条件]が担ってくれている。ここで、あらためて「帰属を示す機能」について再考しよう。もとは「回収条件明細」に含まれていた[得意先]は「回収条件」に移動させられたが、あいかわらず、回収条件がどの得意先に「帰属」するかを示している。ところで、実務上は、同一の回収条件が複数の得意先に適用されることも多いはずだ。であれば、回収条件が特定の得意先に「帰属」するというのは不自然だろう。むしろ複数の得意先に同一の回収条件を「適用」すると考える方がスジがいい。
そこで、発想を「回収条件が得意先に帰属する」から「得意先に回収条件を適用する」に切り替えてみよう。モデルは以下のように修正される。

回収条件DM-参照逆転

修正前のモデルでは、回収条件が得意先を参照していたのに対して、変更後では得意先が回収条件を参照している。この修正によって次のようなメリットが期待できる:

  1. 登録データの共用:ひとつの回収条件を複数の得意先で共用可能になり、回収条件をたくさん登録しなくて済む。
  2. 要件変更時の影響の局所化:たとえばX社では、現在は、得意先ごとに回収条件が決まっているが、将来は、同じ得意先でもX社側の事業部ごとに別々の回収条件を適用したくなるかもしれない。修正後のモデルであれば、こうした変化が起きても、回収条件・回収明細の設計はそのままでよい。

ここまでの洗練ステップをまとめると、次のようになる。

DB洗練プロセス-回収条件

僕の経験上、このテクニックはけっこう使いでがあると感じている。他の例をひとつ挙げよう。ある企業が複数の子会社の会計処理をまとめて行なうシステムを構築しようとしている。ほとんどの子会社では同じ勘定科目コード体系を使っているが、中には違ったコード体系を使っている会社もある。この場合も、回収条件の場合とまったく同様に、以下のような洗練ステップが考えられる。

DB洗練プロセス-勘定科目表

最終形では、あらかじめ決められた勘定科目表(=勘定科目体系)のどれかひとつを各社が選択して自社に適用できるようになっている。

この2段階の洗練ステップで面白いのは、実際に業務上の価値をもたらすのは2段階目の「参照関係の逆転」なのだが、難しいのはそれに先行する「スコープ概念の抽出」だという点だ。スコープ概念(たとえば「勘定科目表」)の存在がはっきりと認識されていれば、2段階目の修正は容易に思いつく。スコープ概念は、業務上の制約条件("ひとつの得意先に対する回収割合の合計は100%であること")や一意性の範囲の指定("勘定科目コードはひとつの会社内で一意でなくてはならない")の中に曖昧に姿をほのめかせている。この曖昧な概念を捕まえて適切な名前をつける。そうすると以降のステップはほぼ自動的に進む。名前付けは重要だ。

posted by keis at 16:39| Comment(0) | TrackBack(0) | システム外部設計 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/393131354
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。