Downloaded 98 times
Uploaded byKoichi Inami
データモデリング入門－astah*を使って、TMの手法を使う－
情報システムを効果的に活用できる様に、企業が有している情報を分析する手法が有ります その一つであるTMという手法と、astah*という道具を用いてデータモデルを書いて分析するための手引きです 以前にある人向けに作成しましたが、せっかくなので公開しておくことにしました
データモデリング入門－astah*を使って、TMの手法を使う－
- 1. データモデリング入門 －astah*を使って、TMの手法を使う－ 2013年 1月 6日（初版） 2014年7月 6日（微妙に修正入れた版） 稲見 浩一
- 2. はじめに 本書について（対象者と目的） 自社の情報について整理したり見直したりしたいが、どこからどう手を付 けて良いかわからないという人 Sierとかの立場で、顧客の事業なり業務を分析するけど、業務フローを 書いても書いてもキリがないという人 そんな人たちに、実際に道具を使って手を動かし始めるだけの知識と、 実習を提供しています 始めるには 道具（astah）を手に入れて下さい 必ず、既に実践的に使える人を見つけて習ってください 実際に自分のモデルを書く時にも、必ず見て貰ってください astah*を使って、TMの手法を使う Koichi Inami 2013 1
- 3. astah*を使って、TMの手法を使う Koichi Inami2013 2 おおまかな紹介 手法 TM T字形ERデータベース設計技法と呼ばれたものの発展形で、 佐藤正美氏により提唱されている業務分析手法です 道具 astah* Professional IE法とIDEF1XのER図と、UMLや、他に幾つかの図を書くこと ができます ただし、TMに準拠したルール通りの記述はできません Free版ではER図が書けないので、購入をお願いします （Professional版での50日間の試用は可能）
- 4. astah*を使って、TMの手法を使う Koichi Inami2013 3 TMの紹介１ TMを構成する概念 数学的、或いは論理的背景を知りたい方は、ご本家 のホームページのTMの最新バージョンを御覧下さい それ以外で知っておくべきこと リレーショナルモデルのキーの概念を使っていない 他のデータモデリングの本を読むよりも、野矢茂樹の 「ウィトゲンシュタイン『論理哲学論考』を読む」（の前 半部分）を読んだ方が理解が進む
- 5. astah*を使って、TMの手法を使う Koichi Inami2013 4 TMの紹介２ 本家のTMでの表記 エンティティの形が 「Ｔの字形」になっている。 仕訳帳の概念から応用 従業員番号 従業員氏名 ・ ・ 従業員 R Entity種別 R：Resource E：Event Entity名称 Identifier Attributes リレーションシップは、基本的に IE法に準拠している Eventエンティティを時系列に 左から右に並べて配置する
- 6. astah*を使って、TMの手法を使う Koichi Inami2013 5 TMの紹介２’ astah*で書くと？ エンティティ名 箱（矩形）の形が異なる Identifierの(R)が、(FK)になって しまう IE方では、リレーションシップに依存 型と非依存型が有って、使い分け が必要になる EとかRとか種別が表記できない （その種別毎の色分けだけはでき る様になっている）
- 7. astah*を使って、TMの手法を使う Koichi Inami2013 6 TMの決まり TMでは、業務を表していく（解析していく）ため の文法として、或いはルールとして、次のものを用 意している エンティティの捕捉 エンティティの類別 エンティティ間の関係 サブセット 多値と多義 拡張：みなしエンティティ
- 8. astah*を使って、TMの手法を使う Koichi Inami2013 7 TMの決まり1（捕捉） TMでは、事業を行なっている者が、それを識別す るために付与した何らかの「識別子」を持ったものを 「エンティティ」として捕捉する 例えば、「顧客コード」を用いた「顧客」エンティティ 「商品番号」を用いた「商品」エンティティ など 注文番号：0001 顧客番号：1150 商品番号：AA11 注文日 ：12/12/12 数量 ： 50 商品 商品番号 注文 商品番号 顧客 顧客番号
- 9. astah*を使って、TMの手法を使う Koichi Inami2013 8 TMの決まり2（類別） TMでは、エンティティを次の２つに類別する イベントエンティティ タイムスタンプを持つもの つまり、時系列に並べられる リソースエンティティ イベントでないエンティティ 並び順に意味が無い 受注 Ｅ 受注日 受注数 受注NO 出荷 Ｅ 出荷日 出荷数 出荷NO 請求 Ｅ 請求日 請求金額 請求書NO イベントエンティティを時系列に配置する。
- 10. astah*を使って、TMの手法を使う Koichi Inami2013 9 TMの決まり3（関係） エンティティ間の関係を次の様に定める リソースとリソース リソースとイベント 引き込む 対照表（交差エン ティティ）を作る
- 11. astah*を使って、TMの手法を使う Koichi Inami2013 10 イベント対イベント イベント対イベント（２） 対応表（交差エン ティティ）を作る ※先行イベントがN（多）にならないのが確定ならば、引き込む 引き込む
- 12. astah*を使って、TMの手法を使う Koichi Inami2013 11 再帰 リソースを使った再帰 イベントを使った再帰 ２本目のリレーションシップを引き、 なおかつ２つの(FK)を書くためには、 工夫が必要である • 最初のリレーションシップを引く • ２本目のリレーションシップを引く • そのキータブで、子キーをリストボック スで選択（_０がついたもの）、 キーの名前を変更する 残念ながら、astah*には、１アク ションで再帰を書く機能が無い
- 13. astah*を使って、TMの手法を使う Koichi Inami2013 12 TMの決まり4（集合） サブセット（真部分集合）を見つける 真部分集合なので、このサブセット間の 関係は、常にORでなければならない 「○○区分コード」などにより見つかる 場合が多い 必ずOR （排他的選言）の関係でな ければならない サブセット間の属性の構成が異なる場 合には、その可能性が高い 階層化することも有る。ものによっては、 かなり深い（10階層とか）ことも有る 階層の順序を入れ替えても成立する 場合、部分集合ではなく、別な視点の 分類にすぎない可能性が高い
- 14. astah*を使って、TMの手法を使う Koichi Inami2013 13 TMの決まり5（多値と多義） １対多の関係は、２種類有る 多値 同時に複数発生 例：１つの受注と受注明細 多義 同時に成立せず、利用時に選択 例：商品の或る種類の価格 多値 多義
- 15. astah*を使って、TMの手法を使う Koichi Inami2013 14 TMの拡張（みなし） 実情に合わせるために拡張を設けた TMでは、エンティティは識別子により識別できるものと 規定しているが、実業務では識別子の流用が見られる 例えば、注文番号をそのまま使った出荷など 見た目には、 独自の識別子の無 いエンティティである
- 16. astah*を使って、TMの手法を使う Koichi Inami2013 15 TMには「エンティティの捕捉」というルールが設けられて いて、独自の「識別子」を持つものだけが「エンティティ」 であると定義されている それは、特に業務上「それ」として認識すべきと考えたもの には、「それ」として認識するための記号が与えられていると 考えるからである そして、「それ」としての識別子を持たないものは、識別子 を与えられている別なものに関連した何かであると考える なので、エンティティとして補足したものの属性に着目し、 本当にその「属性」なのか、関連した何かが混入している のかを見分ける必要がある
- 17. astah*を使って、TMの手法を使う Koichi Inami2013 16 TMの作成手順 概ね、文法通りに作業を進める エンティティを補足する インプットとなるものを用意する 現行システムの画面、伝票、帳票、運用で使っているExcel表 など、登場する項目や、入出力の順のわかるものを用意する T字形フォームで整理する インプット 情報 受注一覧 顧客NO 受注NO 品目コード 顧客区分コード 顧客名称 受注日 品目名称 受注数 品目単価 TMの図に 展開する。
- 18. astah*を使って、TMの手法を使う Koichi Inami2013 17 識別子を見つける エンティティを作成し、識別子の名前からエンティティ名をつける 識別子をキーとして書き込む 該当する属性を書き込む わからないものは、ラピュタとして箱を作って入れておく エンティティを類別する タイムスタンプ（○○日付）を探し、有ればイベントに エンティティの型を選ぶ（リソースなど） 関係を書き込む リソース・リソース間では、対照表を置く イベント・イベント間では、対応表を置く リレーションシップを引く 識別子を他に継承する場合は、依存型にしておく
- 19. astah*を使って、TMの手法を使う Koichi Inami2013 18 多値と多義を見つける 多値になるものは、ヘッダ側の依存型のディテールという形になる （伝票で言えば、鏡と明細の関係） 多義も、独自の識別子を持たない依存型エンティティである サブセットを見つける 明示的な区分を見つけて、真部分集合が形成できるか調べる 属性に、場合によって有ったり無かったりするものを見つけ、それ らをそれぞれの構造として部分集合とする 拡張：みなしエンティティ 属性の中で、外に切り出されるものが有れば、外に出す
- 20. astah*を使って、TMの手法を使う Koichi Inami2013 19 TMの検証 取り敢えず書いたら、次の観点で検証する 器の確認をする 識別子は、実在するコード体系のものか？ 実際の業務で認識され、使われているものか？ 勝手に作成すると恣意的になる 既に意識して管理されているか区別できなくなる リソースとイベントを正確に類別しているか？ タイムスタンプが置けるか？ 言い方を変えると、順序が問われるか否か？ 参照キーの挿入ルールが異なるので注意！
- 21. astah*を使って、TMの手法を使う Koichi Inami2013 20 リソースが名称ファイルに成り下がってないか？ 従来型のプロセス中心の手法だと、イベントと名称ファイル になってしまうことが多い 現行システムのテーブル構造に引きずられると陥りがち 対照表が少ないと、その兆候が有るので注意！ 逆に対照表が多すぎないか？ 不必要なＶｉｅｗばかりを生成してないか？ タイムスタンプを仮定するとイベントになるか？ 又は構造を示す意味が有るか？
- 22. astah*を使って、TMの手法を使う Koichi Inami2013 21 データ解析 アトリビュートの中にNULL値の起こる可能性は無い か？ その値が存在しない場合、というのが隠されていないか？ サブセット化する必要が残されてないか？ 区分コードが放置されてないか？ データ中に区分が隠蔽（○○コードが１００以上なら ××、など）されてないか？ 分析段階で見つけておかないで実装すると、プログラム中 に余分なIF文が使われることになる
- 23. astah*を使って、TMの手法を使う Koichi Inami2013 22 サブセット間は、排他（OR）の関係であるか？ ANDの関係が成立するなら、それらはサブセットではない 実は、別のエンティティではないか？ 階層を入れ替えられるサブセットが存在しないか？ 本来の部分集合として有り得ない 別なエンティティととの関連である可能性が高い リソースを見捨ててないか？ イベントのエンティティのアトリビュートにリソースが隠されて ないか？ 本来、その属性であるべきものか、関連した別のものか？
- 24. astah*を使って、TMの手法を使う Koichi Inami2013 23 データモデルから、色々読んでみよう！ 検証するにも必要だが、書いたものは意図通りに 書けたかどうか、読んでみないといけない 関係を読んでみる
- 25. astah*を使って、TMの手法を使う Koichi Inami2013 24 左の図が一般形であるとする 真ん中の図では 受注と支払いに関連が無く、顧客を介してのみ繋がっている つまり、アカウント制と想像できる 右の図では、 支払いは、必ず受注した顧客に限るという制約がかかる 左の一般形の図では、受注は子供から、支払いは親からという 様な形も可能 その関係は何を意味しているか、成立するのか精査する 実情に対する可能性の検証にも使える
- 26. astah*を使って、TMの手法を使う Koichi Inami2013 25 属性を読んでみる さて、オープン価格制、標準原価、正価販売（値引きを許さない）は、どの図であろうか？ 属性の配置によって、何が語れるか？
- 27. astah*を使って、TMの手法を使う Koichi Inami2013 26 構造（過程）の違いを見て見よう ここだけ見ると、 コードの並び順の 差にしか見えない 生成過程が異なることが 読める。例えば、染色しな い生成りの製品が発生す るとしたら？
- 28. astah*を使って、TMの手法を使う Koichi Inami2013 27 検証にも分析にも リソースエンティティ間の関係を検証する 全てのリソースエンティティ間の検証というのは現実的で 無いため、例えばある入力画面で使われているものとか、 一連の業務のイベントに関連するものを使う 既に確立しているはずの関係の見落としを検証する 未だ確立していない関係の成否を検証する 顧客 受注 品目 ○ ○ 顧客 受注 品目 持っているのに活用されていないデータを発 見し、他のデータとの関係を考えることによっ て、新たなビジネスモデルの発見につなげら れる可能性が有る
- 29. astah*を使って、TMの手法を使う Koichi Inami2013 28 前ページの図の例で見てみる 現に成立している関係を○印を付けて記述する 顧客と受注は成立している 受注と品目は成立している 成立していない関係を（成立するか否か）検証する 顧客と顧客の再帰は可能か？ 顧客と品目は関係しているか？ 受注と受注の再帰は可能か？ 品目と品目の再帰は可能か？ 可能性の検証 ３つのentity間に成立する「関係」の可能態は６つである 現実に成立している関係は、２つである（１／３の成立） 関係（ビジネス・ルール）の可能性として、２／３の余地がある
- 30. astah*を使って、TMの手法を使う Koichi Inami2013 29 演習問題 演習問題は、別紙で取り扱います 実業務なり課題を抱えている人は、できれば演習問題 などせず、その業務をモデル化してみることを奨めます TM（T字形ER）の手法の本質は、実際のビジネス で行われていることが書かれているのか、きちんと検証 可能なのかが問われることです 演習問題は仮定に過ぎないので、作図の練習にしか ならないからです
- 31. astah*を使って、TMの手法を使う Koichi Inami2013 30 TMのモデル観 敢えて、説明の最後にもってきました TMは、事業過程・管理過程をモデル化する一般手続きである TMは、次の2点を実現するために使う一般手続きである 事業過程・管理過程を 「正確に」記述する（現実的事態に対 して形式的構成 ［ モデル ］ を作る） モデル（すなわち、事業過程・管理過程）に対して以下の2点 を調査して、改善案（ソリューション） を考える 「モデル」 そのもの-の強み・弱み 「モデル」 の環境に対する適応力 と言っても、ここではこれ以上説明しません。 詳細は本家のサイトで詳しくお読みください。
- 32. astah*を使って、TMの手法を使う Koichi Inami2013 31 TMでモデリングしていて 過去に質問されたことを少し並べてみます そんなにバラバラにして扱いにくくないか？ 概念というレベルで考えて、特に問題は無い 逆に、勝手に幾つかをまとめると、検証できなくなる エンティティ＝テーブル として実装すると、結合が多くな り過ぎないか？ 必ずしもイコールには実装していない 例えば、実装不要なエンティティも有るし、サブセットは実 装方向を考えたり、みなしについては、NULLを許してエン ティティ側に吸収することが無い訳ではない 勝手に非正規化なんてすると碌なことにならない
- 33. astah*を使って、TMの手法を使う Koichi Inami2013 32 識別子が無いとエンティティが作れないなら、新規の事 業は解析できないのでは？ 何を以て、その集合の中で、個別のインスタンスを特定す るか、それを識別子と呼んでいるだけで、「○○コード」とい う名称とは限らない 業務をする複数の人達で、そのインスタンスを特定する何 かが有れば良い 逆に、新規ビジネスで発生する、或いは管理可能となる データを精査する意味で、モデルを書いてみることが役立 つという面も有る まだ事実が無いなら、トップダウンにならざるを得ない
- 34. astah*を使って、TMの手法を使う Koichi Inami2013 33 どこから書き始めれば良いか？ どこからでも良い。わかっていることをルール（文法）に従って書 いていけば良い わかりやすいところから書くという手も有る。書きやすい代わりに、書いた 意味を見出しにくいかも 業務が複雑で整理したいところから書くという手も有り。書く難易度は 高くなるが、書いた効果は実感しやすくなるはず 誰が書くのが良いか？ 実際に、その事業を行なっている会社の、もし存在するならデー タ管理担当の方が最も適している モデリングという技術自体は、ベンダー側が持っていることも有る が、その場合でもユーザの業務を引っ張り出し、書くという行為 を代行する（勝手なものを混入しない）のが望ましい
- 35. astah*を使って、TMの手法を使う Koichi Inami2013 34 UMLも使ってみよう（せっかくのastah*) 分析過程での利用 アクティビティ図を使う 業務分析をするのに、SIerの多くでは「業務フロー」という 図を使うことが多い様ですが、プロセス改善の目的以外で 詳細に書くのは、お薦めしません ただし、データの分析を行う場合でも、エンティティの順序 などを考える際に、あるいは特定の関連を考える際には、 その業務の一部をアクティビティ図として書いてみることが 有効な場合が有ります また、ER図では表せない、業務上のアルゴリズムに関して 表すのに向いている場合が有ります
- 36. astah*を使って、TMの手法を使う Koichi Inami2013 35 ステートマシン図を使う サブセットの分析や、サブセットと他のエンティティの関連を 考える場合に便利です 場合分けを考えるのに、アクティビティ図で分岐を使って書くこと もできますが、特にその条件と遷移先について考えるには、ス テートマシン図の方が向いています エンティティ間の関連が、ある特定のサブセットの場合に限定さ れるのか、という条件を見直す際に、特に便利に使えます
- 37. astah*を使って、TMの手法を使う Koichi Inami2013 36 システム構築に向けて シーケンス図を使う 利用するシナリオを考える際に、システムとのやり取りレベル でシーケンス図を書いてみると、整理しやすいことが有る 書き捨てで構わない ユースケース図を使う これも、このシステムを使って、誰が何ができるかという目的 の確認にも繋がる 図だけでなく、ユースケース記述を書くことに意味が有る
- 38. astah*を使って、TMの手法を使う Koichi Inami2013 37 astah*と専用ツールとの違い 専用ツールのTER-MINEと比べると、 最大の違いは、ルール準拠でないこと。ITS社のTMD 作図ツールであるTER-MINEでは、リソースエンティティ 間でリレーションシップを引くと、必ず対照表を作る様に なっている（ルール適用の補助） TER-MINEでは部分図が書けないが、astah*では 一つのプロジェクトに、幾つものER図を書くことができる イベントの並びで業務を追うという点では、部分図が余り に部分的すぎると効果が無くなる 全体図を書いておいて、特定の部分だけを部分図にする こともできるので、より良い使い方を工夫する
- 39.
- 40. astah*を使って、TMの手法を使う Koichi Inami2013 39 ご参考 TMと佐藤正美さんについて SDIのホームページを参照 astah*について チェンジビジョンのページを参照 関連図書 ウィトゲンシュタイン『論理哲学論考』を読む (ちくま学芸文庫) 野矢 茂樹 著 エンティティとか、その属性を考える上で、「事実」と「可能的事 実」ということを考えるのに、この本を読んで欲しい（前から1/3 位までで良いので） 他にも、野矢氏の「入門！論理学」など参考になるもの多し！
- 41.
- 42. astah*を使って、TMの手法を使う Koichi Inami2013 41 おまけ 現行システムの良し悪しを見極める一つの基準 • OLTP系のシステムに関し、 RDBMSを使っている場合の判 断基準と考えて下さい • データベース設計書の各テーブル 定義の列数を見てみる • 特殊な例を除き、20列を超える 様なテーブルが有るのは、危険な 兆候！（更新日など、どのテーブ ルにも設けてある固定的な列は 除く） • 100列以上のテーブルが幾つも 有るのは、残念としか言えません