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

データモデリング入門－astah*を使って、TMの手法を使う－ 2013年 1月 6日（初版） 2014年 7月 6日（微妙に修正入れた版）稲見浩一

はじめに 本書について（対象者と目的）  自社の情報について整理したり見直したりしたいが、どこからどう手を付けて良いかわからないという人  Sierとかの立場で、顧客の事業なり業務を分析するけど、業務フローを書いても書いてもキリがないという人  そんな人たちに、実際に道具を使って手を動かし始めるだけの知識と、実習を提供しています 始めるには  道具（astah）を手に入れて下さい  必ず、既に実践的に使える人を見つけて習ってください  実際に自分のモデルを書く時にも、必ず見て貰ってください astah*を使って、TMの手法を使う Koichi Inami 2013 1

astah*を使って、TMの手法を使う Koichi Inami 2013 2 おおまかな紹介  手法  TM T字形ERデータベース設計技法と呼ばれたものの発展形で、佐藤正美氏により提唱されている業務分析手法です  道具  astah* Professional IE法とIDEF1XのER図と、UMLや、他に幾つかの図を書くことができます ただし、TMに準拠したルール通りの記述はできません Free版ではER図が書けないので、購入をお願いします（Professional版での50日間の試用は可能）

astah*を使って、TMの手法を使う Koichi Inami 2013 3 TMの紹介１ TMを構成する概念 数学的、或いは論理的背景を知りたい方は、ご本家のホームページのTMの最新バージョンを御覧下さい それ以外で知っておくべきこと リレーショナルモデルのキーの概念を使っていない 他のデータモデリングの本を読むよりも、野矢茂樹の「ウィトゲンシュタイン『論理哲学論考』を読む」（の前半部分）を読んだ方が理解が進む

astah*を使って、TMの手法を使う Koichi Inami 2013 4 TMの紹介２ 本家のTMでの表記エンティティの形が「Ｔの字形」になっている。仕訳帳の概念から応用従業員番号従業員氏名・・従業員 R Entity種別 R：Resource E：Event Entity名称 Identifier Attributes リレーションシップは、基本的に IE法に準拠している Eventエンティティを時系列に左から右に並べて配置する

astah*を使って、TMの手法を使う Koichi Inami 2013 5 TMの紹介２’ astah*で書くと？エンティティ名  箱（矩形）の形が異なる  Identifierの(R)が、(FK)になってしまう  IE方では、リレーションシップに依存型と非依存型が有って、使い分けが必要になる  EとかRとか種別が表記できない（その種別毎の色分けだけはできる様になっている）

astah*を使って、TMの手法を使う Koichi Inami 2013 6 TMの決まり TMでは、業務を表していく（解析していく）ための文法として、或いはルールとして、次のものを用意している エンティティの捕捉 エンティティの類別 エンティティ間の関係 サブセット 多値と多義 拡張：みなしエンティティ

astah*を使って、TMの手法を使う Koichi Inami 2013 7 TMの決まり1（捕捉） TMでは、事業を行なっている者が、それを識別するために付与した何らかの「識別子」を持ったものを「エンティティ」として捕捉する 例えば、「顧客コード」を用いた「顧客」エンティティ 「商品番号」を用いた「商品」エンティティなど注文番号：0001 顧客番号：1150 商品番号：AA11 注文日：12/12/12 数量： 50 商品商品番号注文商品番号顧客顧客番号

astah*を使って、TMの手法を使う Koichi Inami 2013 8 TMの決まり2（類別） TMでは、エンティティを次の２つに類別する イベントエンティティ タイムスタンプを持つもの つまり、時系列に並べられる リソースエンティティ イベントでないエンティティ 並び順に意味が無い受注Ｅ受注日受注数受注NO 出荷Ｅ出荷日出荷数出荷NO 請求Ｅ請求日請求金額請求書NO イベントエンティティを時系列に配置する。

astah*を使って、TMの手法を使う Koichi Inami 2013 9 TMの決まり3（関係） エンティティ間の関係を次の様に定める リソースとリソース リソースとイベント引き込む対照表（交差エンティティ）を作る

astah*を使って、TMの手法を使う Koichi Inami 2013 10 イベント対イベント イベント対イベント（２）対応表（交差エンティティ）を作る ※先行イベントがN（多）にならないのが確定ならば、引き込む引き込む

astah*を使って、TMの手法を使う Koichi Inami 2013 11 再帰 リソースを使った再帰 イベントを使った再帰２本目のリレーションシップを引き、なおかつ２つの(FK)を書くためには、工夫が必要である • 最初のリレーションシップを引く • ２本目のリレーションシップを引く • そのキータブで、子キーをリストボックスで選択（_０がついたもの）、キーの名前を変更する残念ながら、astah*には、１アクションで再帰を書く機能が無い

astah*を使って、TMの手法を使う Koichi Inami 2013 12 TMの決まり4（集合） サブセット（真部分集合）を見つける真部分集合なので、このサブセット間の関係は、常にORでなければならない 「○○区分コード」などにより見つかる場合が多い 必ずOR （排他的選言）の関係でなければならない サブセット間の属性の構成が異なる場合には、その可能性が高い 階層化することも有る。ものによっては、かなり深い（10階層とか）ことも有る 階層の順序を入れ替えても成立する場合、部分集合ではなく、別な視点の分類にすぎない可能性が高い

astah*を使って、TMの手法を使う Koichi Inami 2013 13 TMの決まり5（多値と多義） １対多の関係は、２種類有る 多値 同時に複数発生 例：１つの受注と受注明細 多義 同時に成立せず、利用時に選択 例：商品の或る種類の価格多値多義

astah*を使って、TMの手法を使う Koichi Inami 2013 14 TMの拡張（みなし） 実情に合わせるために拡張を設けた TMでは、エンティティは識別子により識別できるものと規定しているが、実業務では識別子の流用が見られる例えば、注文番号をそのまま使った出荷など見た目には、独自の識別子の無いエンティティである

astah*を使って、TMの手法を使う Koichi Inami 2013 15 TMには「エンティティの捕捉」というルールが設けられていて、独自の「識別子」を持つものだけが「エンティティ」であると定義されている それは、特に業務上「それ」として認識すべきと考えたものには、「それ」として認識するための記号が与えられていると考えるからである そして、「それ」としての識別子を持たないものは、識別子を与えられている別なものに関連した何かであると考える なので、エンティティとして補足したものの属性に着目し、本当にその「属性」なのか、関連した何かが混入しているのかを見分ける必要がある

astah*を使って、TMの手法を使う Koichi Inami 2013 16 TMの作成手順 概ね、文法通りに作業を進める エンティティを補足する インプットとなるものを用意する 現行システムの画面、伝票、帳票、運用で使っているExcel表など、登場する項目や、入出力の順のわかるものを用意する T字形フォームで整理するインプット情報受注一覧顧客NO 受注NO 品目コード顧客区分コード顧客名称受注日品目名称受注数品目単価 TMの図に展開する。

astah*を使って、TMの手法を使う Koichi Inami 2013 17 識別子を見つける  エンティティを作成し、識別子の名前からエンティティ名をつける  識別子をキーとして書き込む 該当する属性を書き込む  わからないものは、ラピュタとして箱を作って入れておく  エンティティを類別する タイムスタンプ（○○日付）を探し、有ればイベントに エンティティの型を選ぶ（リソースなど）  関係を書き込む リソース・リソース間では、対照表を置く イベント・イベント間では、対応表を置く リレーションシップを引く  識別子を他に継承する場合は、依存型にしておく

astah*を使って、TMの手法を使う Koichi Inami 2013 18  多値と多義を見つける 多値になるものは、ヘッダ側の依存型のディテールという形になる（伝票で言えば、鏡と明細の関係） 多義も、独自の識別子を持たない依存型エンティティである  サブセットを見つける 明示的な区分を見つけて、真部分集合が形成できるか調べる 属性に、場合によって有ったり無かったりするものを見つけ、それらをそれぞれの構造として部分集合とする  拡張：みなしエンティティ 属性の中で、外に切り出されるものが有れば、外に出す

astah*を使って、TMの手法を使う Koichi Inami 2013 19 TMの検証 取り敢えず書いたら、次の観点で検証する 器の確認をする 識別子は、実在するコード体系のものか？ 実際の業務で認識され、使われているものか？ 勝手に作成すると恣意的になる 既に意識して管理されているか区別できなくなる リソースとイベントを正確に類別しているか？ タイムスタンプが置けるか？ 言い方を変えると、順序が問われるか否か？ 参照キーの挿入ルールが異なるので注意！

astah*を使って、TMの手法を使う Koichi Inami 2013 20 リソースが名称ファイルに成り下がってないか？ 従来型のプロセス中心の手法だと、イベントと名称ファイルになってしまうことが多い 現行システムのテーブル構造に引きずられると陥りがち 対照表が少ないと、その兆候が有るので注意！ 逆に対照表が多すぎないか？ 不必要なＶｉｅｗばかりを生成してないか？ タイムスタンプを仮定するとイベントになるか？ 又は構造を示す意味が有るか？

astah*を使って、TMの手法を使う Koichi Inami 2013 21 データ解析 アトリビュートの中にNULL値の起こる可能性は無いか？ その値が存在しない場合、というのが隠されていないか？ サブセット化する必要が残されてないか？ 区分コードが放置されてないか？ データ中に区分が隠蔽（○○コードが１００以上なら ××、など）されてないか？ 分析段階で見つけておかないで実装すると、プログラム中に余分なIF文が使われることになる

astah*を使って、TMの手法を使う Koichi Inami 2013 22 サブセット間は、排他（OR）の関係であるか？ ANDの関係が成立するなら、それらはサブセットではない 実は、別のエンティティではないか？ 階層を入れ替えられるサブセットが存在しないか？ 本来の部分集合として有り得ない 別なエンティティととの関連である可能性が高い リソースを見捨ててないか？ イベントのエンティティのアトリビュートにリソースが隠されてないか？ 本来、その属性であるべきものか、関連した別のものか？

astah*を使って、TMの手法を使う Koichi Inami 2013 23 データモデルから、色々読んでみよう！ 検証するにも必要だが、書いたものは意図通りに書けたかどうか、読んでみないといけない 関係を読んでみる

astah*を使って、TMの手法を使う Koichi Inami 2013 24  左の図が一般形であるとする  真ん中の図では  受注と支払いに関連が無く、顧客を介してのみ繋がっている  つまり、アカウント制と想像できる  右の図では、  支払いは、必ず受注した顧客に限るという制約がかかる  左の一般形の図では、受注は子供から、支払いは親からという様な形も可能  その関係は何を意味しているか、成立するのか精査する  実情に対する可能性の検証にも使える

astah*を使って、TMの手法を使う Koichi Inami 2013 25 属性を読んでみるさて、オープン価格制、標準原価、正価販売（値引きを許さない）は、どの図であろうか？属性の配置によって、何が語れるか？

astah*を使って、TMの手法を使う Koichi Inami 2013 26 構造（過程）の違いを見て見ようここだけ見ると、コードの並び順の差にしか見えない生成過程が異なることが読める。例えば、染色しない生成りの製品が発生するとしたら？

astah*を使って、TMの手法を使う Koichi Inami 2013 27 検証にも分析にも リソースエンティティ間の関係を検証する 全てのリソースエンティティ間の検証というのは現実的で無いため、例えばある入力画面で使われているものとか、一連の業務のイベントに関連するものを使う 既に確立しているはずの関係の見落としを検証する 未だ確立していない関係の成否を検証する顧客受注品目 ○ ○ 顧客受注品目持っているのに活用されていないデータを発見し、他のデータとの関係を考えることによって、新たなビジネスモデルの発見につなげられる可能性が有る

astah*を使って、TMの手法を使う Koichi Inami 2013 28  前ページの図の例で見てみる  現に成立している関係を○印を付けて記述する  顧客と受注は成立している  受注と品目は成立している  成立していない関係を（成立するか否か）検証する  顧客と顧客の再帰は可能か？  顧客と品目は関係しているか？  受注と受注の再帰は可能か？  品目と品目の再帰は可能か？  可能性の検証  ３つのentity間に成立する「関係」の可能態は６つである  現実に成立している関係は、２つである（１／３の成立）  関係（ビジネス・ルール）の可能性として、２／３の余地がある

astah*を使って、TMの手法を使う Koichi Inami 2013 29 演習問題 演習問題は、別紙で取り扱います 実業務なり課題を抱えている人は、できれば演習問題などせず、その業務をモデル化してみることを奨めます TM（T字形ER）の手法の本質は、実際のビジネスで行われていることが書かれているのか、きちんと検証可能なのかが問われることです 演習問題は仮定に過ぎないので、作図の練習にしかならないからです

astah*を使って、TMの手法を使う Koichi Inami 2013 30 TMのモデル観 敢えて、説明の最後にもってきました TMは、事業過程・管理過程をモデル化する一般手続きである TMは、次の2点を実現するために使う一般手続きである 事業過程・管理過程を「正確に」記述する（現実的事態に対して形式的構成［モデル］を作る） モデル（すなわち、事業過程・管理過程）に対して以下の2点を調査して、改善案（ソリューション）を考える 「モデル」そのもの-の強み・弱み 「モデル」の環境に対する適応力と言っても、ここではこれ以上説明しません。詳細は本家のサイトで詳しくお読みください。

astah*を使って、TMの手法を使う Koichi Inami 2013 31 TMでモデリングしていて 過去に質問されたことを少し並べてみます そんなにバラバラにして扱いにくくないか？ 概念というレベルで考えて、特に問題は無い 逆に、勝手に幾つかをまとめると、検証できなくなる エンティティ＝テーブルとして実装すると、結合が多くなり過ぎないか？ 必ずしもイコールには実装していない 例えば、実装不要なエンティティも有るし、サブセットは実装方向を考えたり、みなしについては、NULLを許してエンティティ側に吸収することが無い訳ではない 勝手に非正規化なんてすると碌なことにならない

astah*を使って、TMの手法を使う Koichi Inami 2013 32 識別子が無いとエンティティが作れないなら、新規の事業は解析できないのでは？ 何を以て、その集合の中で、個別のインスタンスを特定するか、それを識別子と呼んでいるだけで、「○○コード」という名称とは限らない 業務をする複数の人達で、そのインスタンスを特定する何かが有れば良い 逆に、新規ビジネスで発生する、或いは管理可能となるデータを精査する意味で、モデルを書いてみることが役立つという面も有る まだ事実が無いなら、トップダウンにならざるを得ない

astah*を使って、TMの手法を使う Koichi Inami 2013 33  どこから書き始めれば良いか？ どこからでも良い。わかっていることをルール（文法）に従って書いていけば良い わかりやすいところから書くという手も有る。書きやすい代わりに、書いた意味を見出しにくいかも 業務が複雑で整理したいところから書くという手も有り。書く難易度は高くなるが、書いた効果は実感しやすくなるはず  誰が書くのが良いか？ 実際に、その事業を行なっている会社の、もし存在するならデータ管理担当の方が最も適している モデリングという技術自体は、ベンダー側が持っていることも有るが、その場合でもユーザの業務を引っ張り出し、書くという行為を代行する（勝手なものを混入しない）のが望ましい

astah*を使って、TMの手法を使う Koichi Inami 2013 34 UMLも使ってみよう（せっかくのastah*) 分析過程での利用 アクティビティ図を使う 業務分析をするのに、SIerの多くでは「業務フロー」という図を使うことが多い様ですが、プロセス改善の目的以外で詳細に書くのは、お薦めしません ただし、データの分析を行う場合でも、エンティティの順序などを考える際に、あるいは特定の関連を考える際には、その業務の一部をアクティビティ図として書いてみることが有効な場合が有ります また、ER図では表せない、業務上のアルゴリズムに関して表すのに向いている場合が有ります

astah*を使って、TMの手法を使う Koichi Inami 2013 35 ステートマシン図を使う サブセットの分析や、サブセットと他のエンティティの関連を考える場合に便利です 場合分けを考えるのに、アクティビティ図で分岐を使って書くこともできますが、特にその条件と遷移先について考えるには、ステートマシン図の方が向いています エンティティ間の関連が、ある特定のサブセットの場合に限定されるのか、という条件を見直す際に、特に便利に使えます

astah*を使って、TMの手法を使う Koichi Inami 2013 36 システム構築に向けて シーケンス図を使う 利用するシナリオを考える際に、システムとのやり取りレベルでシーケンス図を書いてみると、整理しやすいことが有る 書き捨てで構わない ユースケース図を使う これも、このシステムを使って、誰が何ができるかという目的の確認にも繋がる 図だけでなく、ユースケース記述を書くことに意味が有る

astah*を使って、TMの手法を使う Koichi Inami 2013 37 astah*と専用ツールとの違い 専用ツールのTER-MINEと比べると、 最大の違いは、ルール準拠でないこと。ITS社のTMD 作図ツールであるTER-MINEでは、リソースエンティティ間でリレーションシップを引くと、必ず対照表を作る様になっている（ルール適用の補助） TER-MINEでは部分図が書けないが、astah*では一つのプロジェクトに、幾つものER図を書くことができる イベントの並びで業務を追うという点では、部分図が余りに部分的すぎると効果が無くなる 全体図を書いておいて、特定の部分だけを部分図にすることもできるので、より良い使い方を工夫する

astah*でTMのモデルを書き始める前に 前述の通り、TMの表記をastahで完全に書くことはできません そこで、リソースやエンティティの類別、対照表や対応表、みなしエンティティなどを識別しやすい様に、エンティティの色を設定しておいてください ツール(T)→システムプロパティ(S)→新規エンティティの型の色 複数人でモデルを書く場合は、最初に設定して、その設定を共有してください astah*を使って、TMの手法を使う Koichi Inami 2013 38

astah*を使って、TMの手法を使う Koichi Inami 2013 39 ご参考  TMと佐藤正美さんについて  SDIのホームページを参照  astah*について  チェンジビジョンのページを参照  関連図書  ウィトゲンシュタイン『論理哲学論考』を読む (ちくま学芸文庫) 野矢茂樹著  エンティティとか、その属性を考える上で、「事実」と「可能的事実」ということを考えるのに、この本を読んで欲しい（前から1/3 位までで良いので）  他にも、野矢氏の「入門！論理学」など参考になるもの多し！

最後に TMは、ビジネスの世界に限定し、識別子をテクニックとするオブジェクト指向分析（OOA）と考えて下さい 独自に始めるより、既に実践できる人と一緒に始めることが肝心です。 最も良い選択肢は、佐藤正美さんに相談することです そこは何となく敷居が高いかもと思った方は、私にでもご連絡ください データマネジメントの一環として始めるなら、DAMA日本支部にコンタクトする方法も有ります astah*を使って、TMの手法を使う Koichi Inami 2013 40

astah*を使って、TMの手法を使う Koichi Inami 2013 41 おまけ 現行システムの良し悪しを見極める一つの基準 • OLTP系のシステムに関し、 RDBMSを使っている場合の判断基準と考えて下さい • データベース設計書の各テーブル定義の列数を見てみる • 特殊な例を除き、20列を超える様なテーブルが有るのは、危険な兆候！（更新日など、どのテーブルにも設けてある固定的な列は除く） • 100列以上のテーブルが幾つも有るのは、残念としか言えません

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

by Koichi Inami, Working at PFUアプリケーションズ株式会社

on Jul 06, 2014

Statistics

Views

Actions

3 Embeds 13

Accessibility

Categories

Upload Details

Usage Rights

Report content

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

https://twitter.com	7
http://iteman.tumblr.com	5
http://www.tumblr.com	3