« astahによるモデリングのメモ | トップページ | Redmine2.5.2の新機能~プラグインアップデートチェック »

2014/07/07

「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料

astahを使って、T字形ERによるデータモデリング手法を解説した資料があったのでメモ。
これはすごくためになる。
自分なりの理解をまとめるためにメモ。
間違っていたら後で直す。

【元ネタ】
Twitter / akipii:凄く良い資料!dddosaka勉強会の人は必読でしょう笑 RT @hatsanhat: データモデリング入門ーastah*を使ってTMの手法を使う http://www.slideshare.net/mobile/inamiK/ss-36665472 … 大変親切にわかりやすく解説されています。

【1】T字形ERのデータモデリングをastahProfessionalのER図でどのように表現すべきか、を解説している。
非常に丁寧で分かりやすい。

個人的には、既存システムのリバース・エンジニアリングの設計技法を選択するとしたら、T字形ERが最強だと思っている。
既存の画面や帳票、テーブルさえ分かれば、どんな仕様なのかを明確に提示できるからだ。

また、T字形ERは、リバース・エンジニアリングの手法も定型的な手順で示しているので、どの設計者がER図を書いても同じようなER図になる可能性が高い。
つまり、設計した成果物の再現性が高いと思われる。

【2】T字形ERの設計技法の中で、丸暗記しても良いくらい重要なパターンは、「リソース」「イベント」のテーブルの間のリレーションシップの貼り方だ。

データモデリングの初心者が設計したER図を見ると、普通は親子関係のテーブルをたくさん作りがちで、外部キーを使った関連がほとんどないのが普通。
外部キーというリレーションシップをどんな時に使えば良いのか、理解できていないのだろうと思う。


業務ルールをどのように外部キーとして張ればいいのか、という問題に対しては、T字形ERが鮮やかに解決している。
※「リソース」「イベント」のテーブルの間のリレーションシップの貼り方については、既に@papandaさんが以前Blogで書かれている。

自分流モデリング探しの旅(2)~T字形ER データベース設計技法 - papandaDiary - Be just and fear not.

(前略)
* resourceとresourceをつなぐ場合:対照表を生成する。対照表はeventである。
 (例)従業員と営業所
     従業員-営業所の対照表を作成し、リレーションシップを保全する。
* resourceとeventをつなぐ場合:event側に参照キーを持たせる。
 (例)顧客と注文
     注文entityに顧客コードを持たせる。
* eventとeventをつなぐ場合
** 「1:1」「1:m」:時系列の遅い方に持たせる。
 (例)受注と請求(一つの受注に対し請求は一つ)
     請求に受注番号を持たせる。
** 「m:1」「m:m」:対応表を生成する。
 (例)受注と請求(複数の受注に対し請求は一つ)
     受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

リソースとイベントのリレーションシップは、リソースの外部キーで関連付ける。
イベントとイベントが先行・後続の関係にある場合、先行イベントの外部キーで関連付ける。
先行イベントを後続インベントが集約する場合、連関テーブル(親子テーブル)を作ると良い。

上記のパターンを覚えておけば、たいていのデータモデリングにすぐに役立てられる。

業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索

候補キーと2次識別子に関する概念: プログラマの思索

データベース設計で派生関係は難しい: プログラマの思索

2次識別子を使ったデータモデリング: プログラマの思索

データモデル表記読み替えハンドブック: プログラマの思索

【3】データモデリングが興味深く面白い点は、ビジネス分析に強力に役立つことだ。
データモデリング入門-astah*を使って、TMの手法を使う-の中の図を説明してみる。

【3-1】P.23:受注・支払いの関連の違いから、ビジネスの違いを見出す

【231】通常の受注・支払いパターン
・受注・支払いに顧客番号がある。
→顧客が受注したデータは、支払いデータに引き継がれる。
・支払いに受注番号がある。
→顧客が受注した後、1回で支払った。

【232】一括/分割支払い
・受注と支払いに関連がない
→受注データと支払いデータは顧客番号を通じてつながっている
→顧客は複数の受注データを1回で支払うor複数回で支払う

【233】家族会員の受注・支払い
・支払いデータに顧客番号がない
→支払いは必ず、顧客が受注したデータから発生する。
→例えば、受注は顧客番号を持つ学生(子供)、支払いは顧客番号を持たない親御さんの場合もあり得る。

【3-2】P.25:注文された商品の価格の違いから、ビジネスの違いを見出す

【251】正価販売(値引きなし)
・注文に「商品単価」がない
→商品マスタの価格でそのまま販売して、注文を受け付ける。
→注文テーブルに「商品単価」がないから、値引きした価格を記録できない。

【252】値引きありの販売
・商品にも注文にも「商品単価」がある
→商品マスタの価格で販売するが、店頭では店員が値引きを受け付けて注文できるようにする。
→「商品.商品単価」と「注文.注文商品単価」は異なる価格の場合がある。

【253】オープン価格の販売
・商品に「商品単価」がない
→商品の値段が販売前に確定していない。
→店頭で販売する時に値段が付けられる。

【3-3】P.27:イベントの順序の違いから、ビジネスの違いを見出す

【271】染色→裁断
⇒伝統的なセーターの製法は「糸を染めてからセーターを編む」。
⇒染色から販売まで6ヶ月もかかるので、見込生産になる。在庫が蓄積されやすい。

【272】裁断→染色
⇒ベネトンは「セーターを編んでから染める」手法へ製造順序を逆転した
⇒製造期間を短縮できるので、受注生産や直販が可能になった。在庫も減らせる。

この話は、T字形ERの本にも記載されているらしく、かなり有名な話。
下記の記事が詳しい。

T字形で事業を解析する、とは - 極北データモデリング

sdi - Page: 149 対照表と 「resource」 の相関関係

リソース数がビジネスの可能性に関係する理由: プログラマの思索

データモデリングに慣れてくると、ER図からビジネスロジックの微妙な違いから、顧客のビジネスのニュアンスを感じ取れるようになる。
この辺りが分かれば、顧客のビジネスに疎いモデラーでも、システム上はこんなビジネスも可能ですよ、と経営コンサルタントっぽく振る舞うこともできるかもしれない。

【4】astahは、UMLだけでなく、ER図もお手軽に書けるのが良い。
また、ER図からExcelのテーブル定義書やDDLを出力できるので便利だ。

個人的には、astahはIE記法やIDEF1X記法にも対応しているので、T字形ERにも対応してもいいのではないか、と思ったりする笑

【追記】続編が公開されていたのでリンクしておく。


|

« astahによるモデリングのメモ | トップページ | Redmine2.5.2の新機能~プラグインアップデートチェック »

モデリング」カテゴリの記事

astahによるUMLモデリング」カテゴリの記事

コメント

コメントを書く



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


コメントは記事投稿者が公開するまで表示されません。



« astahによるモデリングのメモ | トップページ | Redmine2.5.2の新機能~プラグインアップデートチェック »