« 概念モデルと論理モデルの違い(前編) | トップページ | 1レコード多段表示一覧に対応 »

2012.10.22

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

 前編では、通常のデータ項目(値項目)に加えて「実体そのもの(実体項目)」を利用する点が、概念データモデルの特徴であると説明した。これによって「作為的なデータ項目」を持ち込まずに、管理対象をデータモデリングの俎上に置けるようになる。前編で説明した参照関係(モデル1)に続いて、もう少し例を見ていこう。

<モデル1>(前編より再掲)

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


■親子関係で現れる「交差エンティティ」

 ブログ記事で何度か挙げている例だが、「社員のそれぞれの趣味に対する関心度」を管理するとしよう(ほんとうにおせっかいなシステムだ)。その場合、「社員管理表」と「趣味管理表」の「子」として「社員趣味管理表」が次のように置かれる(モデル2)。

<モデル2>

【社員管理表】[社員],社員名,生年月日,性別,...
 +      ̄ ̄ ̄
 |      ①  山田 ...
 |      ②  鈴木 ...
 |      ③  佐藤 ...
 |
 └─∈【社員趣味管理表】[社員]+[趣味],関心度,...
 ┌─∈          ̄ ̄ ̄ ̄ ̄ ̄ ̄
 |            ①  ④   大好き
 |            ①  ⑤   興味なし
 |            ②  ④   興味なし
 |            ②  ⑤   興味なし
 |            ③  ④   好き
 |            ③  ⑤   大好き
 +
【趣味管理表】[趣味],趣味名,...
        ̄ ̄ ̄
        ④  釣り ...
        ⑤  登山 ...

 モデル1の「活動履歴管理表」では、山田さん(①)と釣り(④)の組み合わせが2回出現していた。山田さんは何度も釣りに行ったということだ。ところが、モデル2において「社員趣味管理表」のPKが、"[社員]+[趣味]"の「複合主キー」になっているため、山田さんと釣りの組み合わせはたかだか1回しか出現しない。もし複数回出現することを許せば、山田さんの釣りへの関心について矛盾した内容が記録され得るモデルになってしまう。

 これは、ある種の概念が「概念の組み合わせ」において成立することを示している。「親の実体の組み合わせが子の実体として重複しない」という独特な制約のもとに、子のインスタンスが成立する。このような概念を「交差エンティティ」と呼び、それ以外の通常の概念を「単独エンティティ」と呼んでおこう。

 モデル1の「活動履歴管理表」と、モデル2の「社員趣味管理表」とは、一見すると似ているが異質な概念である。前者は単独エンティティだし、後者は「社員と趣味の組み合わせ」において成立する交差エンティティだ。他にもたとえば「倉庫在庫」や「顧客別月次取引」はそれぞれ、「商品と倉庫の組み合わせ」および「顧客と月度の組み合わせ」において成立する交差エンティティである。

 データベース設計者は「単独エンティティ」と「交差エンティティ」の違いを意識的に使い分けなければいけない。また、そのためには両者が異なるトポロジで示されるモデリング図法を用いたほうがいい。

 では、「社員趣味管理表」向けに実体項目[社員趣味]を想定するわけにはいかないのだろうか。モデル3のように、これをPKとして、別途[社員]と[趣味]の組み合わせに対してユニーク制約を組み込む形でモデリングしてはまずいのだろうか。

<モデル3>

【社員趣味管理表】[社員趣味],関心度,[社員],[趣味],...
          ̄ ̄ ̄ ̄ ̄     ̄ ̄ ̄ ̄ ̄ ̄ ̄

 この表現は概念モデルとしてはふさわしくない。概念モデルとして「複雑すぎる」といってもいい。どこが複雑かというと、PK以外のユニーク制約を伴っている点だ。また、[社員趣味]が他のテーブルの外部キーとして組み込まれているとすれば、[社員]や[趣味]の実体値が変更されてしまうとデータ間の整合性が危うくなる。したがってそれらに更新制約をかける必要もある。そういったこまごました制約については、概念モデリングではなく、論理モデリングにおいて考慮すべきだ。

 この方針を徹底するためには、概念モデリングに「PK以外の複合ユニーク制約を組み込んではいけない」という制限を盛り込めばよい。こうすれば、交差エンティティである「社員趣味管理表」を、「活動履歴管理表」に類する単独エンティティとして設計してしまうミスを効果的に抑止できる。そのミスは、適切な図法を用いつつインスタンスを併記することでアカラサマになるだろう(*1)。

 前編において、論理モデリングにおける課題は「プラットフォームの特性に合わせて、データ項目を用いてエンティティの一意性や関連をいかに構成するかを示すこと」であると説明した。「サロゲートキーの導入」や「属性項目への複合ユニーク制約付与や更新制約設定」は、論理モデリングでの作業とみなしたほうがいい。

 いっぽう、概念モデリングの目標は「管理されるべき実体をインスタンスとして包含できる概念」を考案・網羅することである。それらが包含する実体を「プライマリに(本来的に)一意に指し示すもの」――すなわち「PK(一次識別子, Primary Key)」を明らかにすることに集中できたほうがいい。それだけでもじゅうぶん難易度が高いのだから。

 まずは概念モデルを確実にまとめる。その後で、実装先プラットフォームの特性に合わせて、サロゲートキーや属性項目に対するユニーク制約や更新制約が組み込まれた論理モデルをまとめる。もしこのときに、基礎となるべき概念モデルが用意されていないとどうなるか。必要な制約が欠落した論理モデルや物理モデルが作られ、「使えば使うほどデータがじわじわと濁ってゆくシステム」が生み出される。

■見出し明細関係と「行番」

 これまでのモデリング例はPKに「実体項目」のみを含むものであったが、そればかりでないことを示そう。「親子関係」の一種である「見出し明細関係」の例である。この関係の特徴は、モデル4のように値項目「行番」がPKに組み込まれる点だ。

<モデル4>

【受注管理表】[受注],受注日,[顧客],顧客注文番号,...
 +      ̄ ̄ ̄
 |
 └─∈【受注明細管理表】[受注]+行番,[商品],受注数,受注単価,...
 ┌─∈          ̄ ̄ ̄ ̄ ̄ ̄
 |
 +
【行番管理表】行番
        ̄ ̄

 なお、この「行番」は「明細の一覧順」ではなく「飛び番を許す明細の追加順」くらいの意味であり、その値はデータのライフサイクルを通じて不変である。明細行の一覧順を管理したいのであれば、属性(可変項目)として別途「一覧順」等を受注明細上に置けばよい。

 あえてモデル4では「行番管理表」を置いた形で示したが、本来はそのようなテーブルを想定する必要はない。なぜなら「行番」は、受注数や受注単価と同様に、コンピュータ上で「実体そのもの」を直接扱えるタイプの項目(値項目)だからだ。受注数のドメイン(定義域)制約を管理するために「受注数管理表」のようなテーブルをわざわざ用意する必要はない。これと同じ理由で、「行番管理表」は不要なのである。

 そこで、「行番管理表」をはずして、インスタンスを書き添えたものをあらためて示す(モデル5)。このように、「現実の実体を指し示す便宜上のポインタ」など使わずに「行番の実体そのもの」をインスタンスとして書き込める。

<モデル5>

【受注管理表】[受注],受注日,[顧客],顧客注文番号,...
 +      ̄ ̄ ̄
 |      ①  ...
 |      ②  ...
 |
 └─∈【受注明細管理表】[受注]+行番,[商品],受注数,受注単価,...
              ̄ ̄ ̄ ̄ ̄ ̄
               ①  1  ...  1,000  500
               ①  2  ...  2,000  300
               ①  3  ...  1,500  700
               ②  1  ...  3,000  400
               ②  2  ...  2,000  300

 ではこれを、実体項目[受注明細]を導入して、モデル6のように描いてはいけないのだろうか。間違いとはいえないにせよ、多少不自然だ。

<モデル6>

【受注管理表】[受注],受注日,[顧客],顧客注文番号,...
 +      ̄ ̄ ̄
 |
 └─…【受注明細管理表】[受注明細],[受注],[商品],受注数,...
              ̄ ̄ ̄ ̄ ̄

 モデル6の受注明細では、実体項目[受注]が属性項目として置かれている。データのライフサイクルを通じてPKの値は不変だが、属性項目は変わり得る。したがってこのモデルは、既存の受注明細レコードが別の受注レコードに含まれる形に変更され得ることを示唆している。この要件をことさら積極的に認める必要性を私は感じない。それゆえにモデル6は「不自然」である。

 じつはこの意味で、モデル5にも改善の余地がある。一般に、いったん受け取った受注を、別の顧客から受け取ったものとして変更できるようにしておく必要はない(*2)。安易に変更すれば、出荷作業や売上計上の段階で混乱を招く。したがって、概念モデルとしてはモデル7のほうが適切である。

<モデル7>

【顧客】[顧客],顧客名,与信額,...
 +   ̄ ̄ ̄
 |
 └∈【受注管理表】[顧客]+受注行番,受注日,顧客注文番号,...
    +      ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    |
    └∈【受注明細管理表】[顧客]+受注行番+明細行番,[商品],...
    ┌…          ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    |
    +
   【商品】[商品],商品名,...
        ̄ ̄ ̄

 つまり、受注のPKとして置かれることの多い「受注№("受注番号"であっても、ユーザの目に触れない"ID"等であっても同様)」のような値項目は、論理モデリングの段階で{[顧客]+受注行番}の代わりに組み込まれる「サロゲート(代替)キー」なのである。このように概念モデルでは、PKに「行番」を含むテーブルが予想以上に現れそうだ。

■まとめ

 データモデリングの3つのフェーズ――概念・論理・物理のそれぞれの意味合いをあらためて示そう。

「概念データモデリング」
対象分野において管理されるべき概念を考案・網羅し、それらの関連を示す作業。値項目とともに実体項目が用いられる。PK以外の複合ユニーク制約や「多対多」の関連を含まない。

「論理データモデリング」
利用する実装環境の特性に合わせて、概念データモデルの内容を値項目のみを用いて示す作業。サロゲートキーや属性項目に対するユニーク制約・更新制約が組み込まれる。

「物理データモデリング」
利用するDBMSの特性に合わせて、論理データモデルの内容をDDLレベルの仕様として示す作業。パフォーマンスを向上させるためのインデックス等も考慮される。

 それぞれのフェーズで作られる成果物の対応関係は次図のようになる。最初の概念モデルにもとづいて、それぞれの段階の制約を考慮したモデルが派生する。

Gainen_modeling

 前編でも述べたように、このようにフェーズ毎に課題を振り分けることで、本来なら難易度の高いデータベース設計を着実にこなせるようになる。異なるプラットフォームに移行する際にも、概念モデルに立ち返って企画を進められるようになる。自己満足な概略的モデルを「概念モデル」とカッコつけて呼ぶことの滑稽さも、あらためて理解できよう。

 なお、先日のモデリングライブで試みて気づいたのだが、カギ括弧で実体項目を示すだけでもずいぶんノーテーションが煩雑になる感じがした。それでライブでは途中から、通常のデータ項目(値項目)だけを用いるスタイルに切り替えた。エンドユーザの前でモデリングする場合にはそうしたほうがいいかもしれない。彼らにとっては「実体項目と値項目の区別」など余計な議論であろう。

 そのような実務上の配慮が要るとしても、概念モデリングの位置づけがクリアになったことは喜ばしい。データモデリングを工学的営みとして整理・体系化するための優れたアイデアとして、考案者の杉本さんに賛辞を送りたい。なお、細かい部分で杉本さんの考えと異なる部分があるかもしれないが、私なりに消化した結果と理解していただければうれしい。


*1.インスタンスを併記することはモデルの手軽なテストになるので、モデリングの場で励行したい。
*2.とくに、顧客(注文主)と送り先と請求先とを区別して設計すれば、そのような必要はほとんどなくなる。それほどに「どの顧客から受け取ったか」は受注にとって決定的である。

|

« 概念モデルと論理モデルの違い(前編) | トップページ | 1レコード多段表示一覧に対応 »

コメント

システム設計の初期段階におけるER図の書き方の方法論になるわけですね、効果がありそうで試してみたくなりました。

投稿: web開発者 | 2012.10.24 16:21

「管理表」という表現を省けば、実態項目名とテーブル名が同じになるので、概念データモデルとオブジェクトモデル(メソッド定義抜き)は似ているような気がします。また、概念データモデルは2次元の構造でデータを表現しようとしているので、「見出し明細関係」などのデータ構造を表現する時は、オブジェクトモデルより多少わかりづらい面もありますね。2次元の図面と3次元の模型の違いでしょうか。

投稿: czhong | 2013.01.02 23:55

コメントを書く



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




トラックバック


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

« 概念モデルと論理モデルの違い(前編) | トップページ | 1レコード多段表示一覧に対応 »