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

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

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

データモデリング入門－astah*を使って、TMの手法を使う－ from Koichi Inami

【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をつなぐ場合
** 「１：１」「１：ｍ」：時系列の遅い方に持たせる。
　（例）受注と請求（一つの受注に対し請求は一つ）
　　　　　請求に受注番号を持たせる。
** 「ｍ：１」「ｍ：ｍ」：対応表を生成する。
　（例）受注と請求（複数の受注に対し請求は一つ）
　　　　　受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)

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

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

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

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

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

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

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

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

データモデリング入門～astahを使ってT字型ERを試す from akipii Oga

【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*を使って、TMの手法を使う- from Koichi Inami