「データモデリング入門-astah*を使って、TMの手法を使う-」はとても良いモデリング資料
astahを使って、T字形ERによるデータモデリング手法を解説した資料があったのでメモ。
これはすごくためになる。
自分なりの理解をまとめるためにメモ。
間違っていたら後で直す。
【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」:対応表を生成する。
(例)受注と請求(複数の受注に対し請求は一つ)
受注-請求の対応表を生成し、リレーションシップを保全する。
(後略)
リソースとイベントのリレーションシップは、リソースの外部キーで関連付ける。
イベントとイベントが先行・後続の関係にある場合、先行イベントの外部キーで関連付ける。
先行イベントを後続インベントが集約する場合、連関テーブル(親子テーブル)を作ると良い。
上記のパターンを覚えておけば、たいていのデータモデリングにすぐに役立てられる。
業務ロジックをデータモデリングはどこまで表現できるか?: プログラマの思索
【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の本にも記載されているらしく、かなり有名な話。
下記の記事が詳しい。
sdi - Page: 149 対照表と 「resource」 の相関関係
リソース数がビジネスの可能性に関係する理由: プログラマの思索
データモデリングに慣れてくると、ER図からビジネスロジックの微妙な違いから、顧客のビジネスのニュアンスを感じ取れるようになる。
この辺りが分かれば、顧客のビジネスに疎いモデラーでも、システム上はこんなビジネスも可能ですよ、と経営コンサルタントっぽく振る舞うこともできるかもしれない。
【4】astahは、UMLだけでなく、ER図もお手軽に書けるのが良い。
また、ER図からExcelのテーブル定義書やDDLを出力できるので便利だ。
個人的には、astahはIE記法やIDEF1X記法にも対応しているので、T字形ERにも対応してもいいのではないか、と思ったりする笑
【追記】続編が公開されていたのでリンクしておく。
| 固定リンク
「モデリング」カテゴリの記事
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- UMTPモデリングフォーラムのパネル討論の感想(2022.11.29)
- Go言語でできることは何なのか(2022.11.06)
「astahによるUMLモデリング」カテゴリの記事
- テストアーキテクチャ設計モデルとJSTQB概念モデルの比較(2023.07.02)
- 統計学の考え方をastahでまとめた(2023.05.28)
- JSTQBのテストプロセスの概念モデルを描いてみた(2023.05.26)
- 第85回IT勉強宴会の感想~概念データモデルからビジネスモデルを構築すべきという考え方(2023.05.13)
- 令和4年度春期試験のITストラテジスト試験第4問をastahでモデル化してみた(2023.04.15)
コメント