« 「生産管理」で業務知識の学びを効率化しよう | トップページ | 概念モデルと論理モデルの違い(後編) »

2012.10.17

概念モデルと論理モデルの違い(前編)

 管理会計システムの開発ツール「FusionPlace」の開発者であり会計士でもある杉本さんが、9月の「第19回関西IT勉強宴会」でたいへん興味深い発表をされた。それを聞いて、私の中で曖昧だった「概念データモデル」の位置づけがはっきりして、「論理データモデル」との違いが浮き彫りになった。この快適なスッキリ感をおすそわけしたい。

■従来の「概念データモデル」の危うさ

 これまで「概念データモデル」という用語は「対象領域における重要なテーブルのみを示したデータモデル」くらいの意味で使われていた。1ページか2ページに収まるように重要なテーブルのみを置き、しばしばキーが省略された形で示される。一部を示すとたとえばこんな調子だ。

┌─∈【出荷】出荷日,顧客C,出荷数量,出荷単価,...


└─∈【請求】請求日,顧客C,請求額,...

 以前に書いた記事「危ういデータモデルを見破るコツ」で、概念データモデルと呼ばれる図面の上に「多対多」のテーブル関連が現れることを批判した。一部のテーブルを省略すれば必然的に「多対多」が出現するわけだが、このテーブル関連はそれを見る者に設計上の何の洞察も与えない。それだけならまだしも、それを見た人が概念データモデルを「思いついたテーブルを適当に結んだ絵」として理解してしまうかもしれない。

 多対多を含むモデルの他に「多対多を含まない完全なデータモデル」が用意されていれば何ら問題はない。ところが、完全なモデルを別途用意していないことが「概念データモデルであるゆえに許される」かのように都合よく解釈されることがある。言い換えると、概念データモデルを用意する前の段階で「多対多を含まない完全なデータモデル」を完成させておくことが強制されない点が、この表記法の問題である。

 上のモデルのように「出荷」と「請求」のテーブルを載せて、両者を「なんとなく関連がある」として多対多で結ぶだけなら素人でもやれる。「多対多を含まない完全なデータモデルはないのか」と訊くと「ない」という。「そういうモデルがないのに、多対多が含まれるモデルが先行して作られるのはおかしいのではないか」と食い下がる。それで「"概念データモデル"として描いたものだからこれでいいんです」なんて答えられたら、もうズッコけるしかない。

 そのように悪しきに流されやすいので、この種の図面は「概念データモデル」ではなく「集約データモデル」とか「概要データモデル」と呼ばれたほうがいい(どう呼び換えてもそういうものをわざわざ作る意味があるとは思えないが)。それを気取って「概念データモデル」と呼ぶのは、日常会話で「概念(concept)」が「概要(summary)」の意味で誤用されやすいことに関係しているのかもしれない。どちらの誤用も恥かしい。

 などとエラそうに批判はするものの、ではどのような図面を本来の「概念データモデル」と呼んだらいいかについてのアイデアは私にはなかった。それを杉本さんがクリアに示してくれた。これがまたコロンブスの卵のように、シンプルでシャープなアイデアなのである。

■「実体そのもの」を扱う

 たとえば、あるシステム化対象領域(ドメイン)において、職場の山田さん、鈴木さん、佐藤さんに関して情報管理したいとする。その場合、この3人が「管理されるべき実体」である。

 彼らを眺めながら分析者は、ふと「社員」という上位概念が求められていることに気づく。そこで、モデルに「社員管理表」を置く。管理したい属性をそこに盛り込めば、次のようになる。

 【社員管理表】[社員],社員名,生年月日,性別,...
         ̄ ̄ ̄
 この図で、PK(一次識別子)として置かれているカギ括弧の"[社員]"に注目してほしい。じつはこれは「実体そのもの」を示している。この説明だけではわかりにくいと思うので、具体値(インスタンス)を書き添えてみよう。

 【社員管理表】[社員],社員名,生年月日,性別,...
         ̄ ̄ ̄
         ①  山田 ...
         ②  鈴木 ...
         ③  佐藤 ...

 "①","②","③"の数字記号はそれぞれ、社員である山田さん、鈴木さん、佐藤さん「そのもの」を表している。厳密に言えば、それは現実の彼らを指し示す「便宜上のポインタ」である。それらの記号が3人の頭の上に浮かんでいると想像してもらえばいい。"①","②","③"と書く代わりに、モデル上にそれぞれを特定できるような何らかの手がかり(たとえば写真)を置いても同じことだ。このようなインスタンスを想定する項目を「実体項目(entity field)」と呼んでおこう。

 いっぽう通常の、カギ括弧で囲まれていない項目は「値そのものが実体」であることを示している。"山田","鈴木","佐藤"といった社員名の「値」は、社員名の「実体そのもの」だ。この種の項目を「値項目(value field)」と呼んでおこう。

 実体項目(カギ括弧で囲んだもの)がPKを構成する場合、実体そのものに対するレコードの一意性が成立する。レコード上の属性項目の値は、個々の実体に関する情報を従属的に表現していることになる。

 以上が杉本さんのアイデアの骨子なのだが、概念モデリングをこういうものと考えることで、何がうれしいのか。概念レベルの関数従属性や一意性を、作為的なデータ項目を介さずにダイレクトに扱えるようになる。結果的に、概念モデリングにおいて「サロゲートキー」や「自然キー」にかかわる議論を排除できる。作業課題を「管理されるべき概念を考案・網羅し、それらの関連を(作為的なデータ項目を用いずに)示すこと」に絞り込める。

 では、概念モデリングに後続すべき「論理モデリング」の課題は何なのだろうか。それは「プラットフォームの特性に合わせて、データ項目を用いてエンティティの一意性や関連をいかに構成するかを示すこと」にある。この段階で初めて、実体項目である"[社員]"が、「社員№」なり「社員コード」なり「ID」なりの「作為的な値項目」に置き換えられる。さらに、これに続く「物理モデリング」の段階では「どのRDBMS上で実装するか」が考慮される。

 このように概念、論理、物理のフェーズ分けをすることで、データベース設計の難しさを分散できる。それにしても、もっとも難しく責任重大な課題が概念モデリングにあることは言うまでもない。これに失敗すれば、それ以降のフェーズでどうあがいても挽回できないからだ。

■参照関係

 概念モデリングの利点は、複雑な構造において際立つ。具体例を見よう。社員による趣味活動の実施履歴を管理したいとする(おせっかいな話だ)。そのために「趣味管理表」と「活動履歴管理表」を前のモデルに追加しよう。

<モデル1>

【社員管理表】[社員],社員名,生年月日,性別,...
 +      ̄ ̄ ̄
 |      ①  山田 ...
 |      ②  鈴木 ...
 |      ③  佐藤 ...
 |
 └─…【活動履歴管理表】[活動履歴],[社員],[趣味],実施日,...
 ┌─…          ̄ ̄ ̄ ̄ ̄
 |             ⑥   ①   ④  9/11
 |             ⑦   ③   ⑤  9/12
 |             ⑧   ①   ④  9/18
 +
【趣味管理表】[趣味],趣味名,...
        ̄ ̄ ̄
        ④  釣り ...
        ⑤  登山 ...

 「社員管理表」と「趣味管理表」のPKが実体項目であるからには、「活動履歴管理表」上の各テーブルへの「外部キー」も必然的に実体項目である。併記されたインスタンスに注目してほしい。それらの値も、あくまでも現実の実体そのもの(実体を即物的に指し示す便宜上のポインタ)である。そして、それらの項目は「活動履歴管理表」上ではPKを構成していないため、同一の値が複数回現れている(社員の①や趣味の④)。

 このように、作為的なデータ項目を挿入せずに「実体そのもの」をダイレクトに用いながら、データモデリングにおける関数従属性や正規化の知見を利用できる。概念モデリングの効果の一端を理解していただけると思う。さらに興味深いのは「親子関係」なのだが、これについては後編で説明しよう。

|

« 「生産管理」で業務知識の学びを効率化しよう | トップページ | 概念モデルと論理モデルの違い(後編) »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 概念モデルと論理モデルの違い(前編):

« 「生産管理」で業務知識の学びを効率化しよう | トップページ | 概念モデルと論理モデルの違い(後編) »