業務分析・メタデータ発掘のためのデータモデリング入門

データマネジメントの必要性の認識が進んだ中で、データモデリングの必要性の認識も高まっています。
特に、AIにデータを単に与えるのではなくて、意味や関係を与えたいという声に最も応えるものとしてもデータモデリングに注目が集まっています。
本資料では、初学者が最も確実に学びやすいと私が長年進めてきたTMという方法論を用いて、比較的安価なツールを使っての実践講座です。
第一部は、データモデリングにまつわる様々な話題を読んで頂きたく書いたもの、
第二部は、方法論とルールを使っての実践的なレクチャー資料となっています。
どうやって学ぶかな？と考えている方、迷っている方は、是非チャレンジしてみてください。
データ横丁のSlackで質問も受け付けますし、書いてみての悩みなど相談も受け付けています。
私以外にも多くのベテラン勢が居るので、是非データ横丁のモデリング通りをのぞいてみてください。

Transcript

1. 業務分析・メタデータ発掘のための データモデリング入門 2026年 5月10日 稲見 浩一
2. はじめに 作者について • 作者：稲見 浩一 「データモデラーです」と自己紹介してきた者です。 データモデリングを中心技術としつつ、組織の立ち上げから運用プロセス設計などを含めて、 データマネジメント実践の支援をしています。 本書について • 私がこれまで公開してきた「データモデリング入門」類の資料を基に書き直したものです。 • 第一部：データモデリングについて知って欲しいことを書き留めてみました • 第二部：TMと呼ばれるモデリング手法を解説し、ツールを用いて実際にモデルを作成する ところまで見ていきます。 • データモデリングについて、色々と知っておきたいと思った方は第一部から、ともかく早く実際に 書けるようになりたいという方は第二部だけ読んで使ってください。 作成：稲見 浩一 2026 2
3. 作成：稲見 浩一 2026 3 第一部： データモデリングについて
4. 作成：稲見 浩一 2026 4 第一部 アジェンダ • データモデリングへの注目 • 情報システムの歴史と課題 • データはどうなっているのか？ • 企業の中のデータは？ • 企業のデータの問題いろいろ • データを扱うモデル • モデルの続き（ERモデル） • モデルの続き（拡張ERモデル） • 拡張された表記 • データモデリングは行われてきたか？ • DMBOK2に登場するデータモデリング • データモデルの詳細レベル • 方法論 • 方法論について • テーブル構成図とデータモデル • データモデリングには時間がかかる • データモデリングはいつするのか？ • 利活用時のモデリング対象 • システム開発 • 人材育成
5. データモデリングへの注目 DXが謳われ、データドリブン経営、更に生成AIの台頭があり、その資源となるデータ に注目が集まっています。 • 使えるデータが揃っていないのでは？ • 十分に共有されておらず、使おうとするといちいち整備しないと使えない！ • データ品質に不安があり安心して使えない • 誰が使うかきちんとコントロールされないと他部門にはデータ提供できない といった声が聞かれ、データマネジメントに取り組む企業が増えています。そこで多くの 人が手にするのが「データマネジメント知識体系ガイド（DMBOK2）」です。 • 第5章として「データモデリングとデザイン」が用意されています • 手元にあるKindle版の改訂第二版で検索してみると、“データモデリング”という言葉が110件、 “データモデル”が249件でてきますが、各章でデータモデリングについて言及されています • また、ナレッジグラフやGraphRAGを扱うのに役立つのでは？と気づき始めた方も増えています 作成：稲見 浩一 2026 5
6. 情報システムの歴史と課題 DXレポートの登場で2025年の崖と騒がれたりしましたが、ここでは少し過去の情報 システムを振り返ってみましょう 作成：稲見 浩一 2026 6 登場 給与計算など比較的単純で多 量に処理されるものから順に 「電算化」され始めました。 入力→処理→出力という形で、 帳票に出力されてデータの寿命 が終わりだったりしました。 #汎用機 #COBOL #フラットファイル #バッチ処理 拡大 対象とする処理が拡張し、経 理、販売管理、生産管理など と部門単位でのシステム導入が 行われました。 対象業務が増え、データ量も 増大しました。 #オープン化（UNIX） #クライアントサーバ #Java #RDBMS #サイロ化 複雑化 製造と販売を合わせての需要 予測など、部門間でのデータ連 携が増え、システム間連携機 能が次々と作られ、複雑化しま した。 #インターネット #クラウド #メッシュ化 #スパゲッティ状態 情報自体が企業の 存亡を左右するとも いわれるようになりま した。 一方でレガシーとも呼 ばれる古い基幹シス テムの刷新が進まな いなど、課題を抱えた 状況です。
7. データはどうなっているのか？ まず、良く使うクイズを出していきましょう。 次のものはなんですか？ 作成：稲見 浩一 2026 7 １７ • 今なら、大谷翔平の背番号という声が強いでしょうか？ • いや、Kevin De BruyneとかDavid Beckhamという人も いるかも知れません • いや、F1でJules Bianchiが付けていて永久欠番となった カーナンバーだという方もいるかもしれないですし、 • 今日の最高気温（17℃） • 私の誕生日（17日） • 約束の時間（17時） • 靴のサイズ（17㎝） • など、他にも色々ありそうです。 単にデータ、値そのものだけあっても解釈ができません。 少なくとも、並びに「大谷翔平」があると、背番号だろうと想像がつくかも知れませんが、 きちんとした定義なり説明が必要です。
8. 企業の中のデータは？ 次のようになっていることが多そうです。 • 目の前で使っている本人は理解している。 • ただし、別部門の人が見ると違っているかも知れません。 • よくある例で、「顧客」を見てみましょう。 • 他にも「受注額」は個別の明細の話なのか、部門での月の合計なのか、単位は円なのか千円なのか？ • 定義を明らかにしておかないと、誤解が生じます。 作成：稲見 浩一 2026 8 部門 「顧客」の解釈 営業 商談した相手先企業。まだ契約前でも含む 受注管理 注文実績のある取引先 請求・経理 請求先として登録されている法人 カスタマーサポート 問い合わせをした利用者 マーケティング メールアドレスや会員登録のある見込み客 現場サービス 実際に製品・サービスを利用している人
9. 企業のデータの問題いろいろ 作成：稲見 浩一 2026 9 もう少し、発生している問題を見てみましょう。 • システム間で、あるいはシステム内の機能間でさえ、同音異義や異音同義の項目がある • システム間で値を交換（複写）していて、同期の問題で異なっているものがある • アプリケーションは変更されているのに設計書が更新されておらず、差が出ている • 「顧客名」という項目なのに、ある部門では先頭に【A】など見込みのレベルを前につけていたり、 別な部門では[新規]と分類の一種を含めてしまっていたりで、顧客名として純粋に扱えない • 注文から参照してるのに商品だけが削除されてしまって、参照整合性が保てていない • データ共有でレプリカデータとテーブル定義を渡されたが、アプリを通してでないと意味が 解釈できずに分析に使えない • 別部門のデータを使って自部門の業務の予測に使いたいが、提供してもらうのにいちいち申請 が必要でタイムリーに使えない • アプリケーションの改造の依頼を受けたが、データ分析に毎回手間と時間がかかってしまう
10. データを扱うモデル 現状は少し置いておいて、この複雑なデータを扱うために開発されてきたモデルについ てみていきましょう。 1. リレーショナルモデル • Edgar F. Codd氏によって1970年に“A Relational Model of Data for Large Shared Data Banks”という論文で発表されたものです。 • 表の形を用いて、それぞれの列にはそれぞれの名前で代表される集合（値域：Domain） からひとつ取った値が置かれ、それらが幾つか同じ並びで並べられる。 • 一つの行をタプルと呼び、すべての行の値域は同じ順で並んでいる。 作成：稲見 浩一 2026 10 列A 列B 列C データは複数の表から構成され、その複 雑な構造を整理するために正規化という 考え方を導入しました。 タプル
11. モデルの続き 2. （Chenの）ERモデル • Peter Chen氏によって1976年に“The Entity-Relationship Model—Toward a Unified View of Data”という論文で発表されました。 • 正規化（1NF→2NF→3NF）などという面倒な段階を経ず、もっと簡単に整理できるとして 発表されていたものです。 作成：稲見 浩一 2026 11 PROJECT PROJECT- WORKER EMPLOYEE WORKER PROJECT M N ENTITY SET ENTITY SET RELATIONSHIP SET 図の表記は、次の通りです。 • ENTITYは、モノ（thing)であり、この集合を矩形で表す • RELATIONSHIPは、モノとモノの関係であり、この集合を、 ENTITY間をつなぐ線の上に菱形で表す
12. モデルの続き 3. その後の拡張ERモデル • Chen博士のERモデルは、本人の努力もあり、普及は非常に進みました。 しかしながら、表現力が不足しているとして、様々な拡張が行われてきました。 • 主な特長として、ChenのERモデルでの関連型（菱形で示す）を廃し、基本的には、矩形 で示したエンティティを1対1、あるいは1対多のみで表現する。 作成：稲見 浩一 2026 12 従業員 部署 従業員 部署 配属 交差エンティティ 多対多のままの表記 複数の1対多に展開した表記 サブセット（タイプ）の表記 営業所 営業所コード 直営店 営業所コード 特約店 営業所コード 汎化・特化
13. 拡張された表記 拡張されたER表記には、いくつか代表的な表記法があるので、ここで紹介します。 作成：稲見 浩一 2026 13 IE法 IDEF1X Barker-ER 最も一般的なデータモデリング作図スタ イルが、「インフォメーションエンジニアリン グ」（IE）の表記法である。 James MartinがIEについての彼の有 名な著作や、IEについての教育を行っ ていく中で、一般に普及するようになった ために、この名前がついた。 IE記法では、三叉の槍または「烏の足」 の形をした線と、◦や|の記号を使って カーディナリティを表現する。 元々は米国空軍のために開発されたも のである。「烏の足」にかわって丸（黒と 白）と線（実線と点線）を使い、IEと 同様の意味を伝達している。 米国標準技術研究所(NIST)が規格 化したもの。 IDEF0のプロセス図では、IDEF1X記 法を用いることが多い。 Richard Barkerらがイギリスのコンサ ルティングファームであるCACIにて1981 年頃開発した表記法である。Barker のOracleへの入社で採択され、Case Methodシリーズの一部として定義され ている。 「烏の足」表記のバリエーションでもあり、 ネストされたボックスでの抽象化表記と、 排他的弧や、ロールアップエンティティな どが特長的である。
14. データモデリングは行われてきたか？ 私は受託開発における要件、特に業務分析の手段としてTM（当時はT字形 ER）というデータモデリング手法を導入しました。 • 1990年代には多くなかったですが、2000年代には本屋さんに「データモデリング」とついた本が 溢れていました。 • 一方で周囲を見回しても、業務システムの開発は、業務フロー→画面設計→DB設計の順で データモデリングを採用する開発プロジェクトは稀でした。 • 奨めてみても、できる人が居ないし「これまでもそんなことしてこなかった」と言われたのが実情です。 • 私には経験がないですが、仕様の大きな見落としや齟齬によって開発を大幅にやり直す、手戻りを起こすプロ ジェクトが沢山あり、納期が来ても動かないというプロジェクトも沢山見かけました。 • その後に、手作業からの新規開発というものは減り、何らかの形で既存システム、既存のDBが 存在する状況となってからは、なおさらデータモデリングは不要、新規じゃないからという人が増え ていきました。 • また、「データモデリング」という言葉が示しているものにも幅があるようです。 作成：稲見 浩一 2026 14
15. DMBOK2に登場するデータモデリング データを取り巻く世界ということでデータモデリングもデータマネジメントの一環と捉えて、 データマネジメントの教科書ともいわれるDMBOK2を見てみましょう。 • 左の図はDAMAホイール図と呼ばれるもので、主な知識領域を 表しています。第5章に「データモデリングとデザイン」があります。 • 冒頭のイントロダクションで次のようにあります。 作成：稲見 浩一 2026 15 図は、DAMA日本支部のダウンロードサイトから データモデリングとは、データ要件を洗い出し、分析し、取り扱い範囲を決め るプロセスである。このデータ要件を表現し伝えるために、データモデルと呼ば れる明確に定義された様式が用いられる。 データモデリングはデータマネジメントに必須の要素である。組織はこのモデリ ングプロセスを通して、データの関係性を突き止め、文書化しなければなら ない。このモデリングプロセスこそが、データの体系を設計することである （Simsion, 2013）。組織はデータモデルを使って自らが持つデータ資産 を視覚化し把握する。
16. データモデルの詳細レベル DMBOK2の中でも次の3つが紹介されています。 • 概念モデル 概念データモデルには、関連する概念の集合体としてデータ要件の概要が取り込まれる。ここには、特定の領域 や業務機能に関する基本的で重要なビジネスエンティティのみが含まれ、各エンティティの説明とエンティティ間の リレーションシップが含まれる。 • 論理モデル 論理データモデルは、詳細なデータ要件が表現されたものであり、通常、アプリケーション要件のような特定の使 用シナリオに適応する。論理データモデルも技術や具体的な実装上の制約から独立している。論理データモデル は概念データモデルの拡張として始まることが多い。 • 物理モデル 物理データモデル（PDM）は詳細な技術的ソリューションを表す。このモデルは論理データモデルを出発点とし て作成されることが多く、そこからハードウェア、ソフトウェア、ネットワークツールを組合せた環境に適応するように設 計される。物理データモデルは特定のテクノロジ向けに構築される。例えば、リレーショナルDBMSは、データベー ス管理システム（IBM DB2、UDB、Oracle、Teradata、Sybase、Microsoft SQL Server、または Microsoft Accessなど）が持つ特定の機能を考慮して設計する必要がある。 作成：稲見 浩一 2026 16
17. 方法論 拡張された表記としては、IE法、IDEF1X、Barker-ERがあると紹介しました。しか しながらこれらは表記の方法であり、モデリングの方法論自体ではありません。 • DMBOK2 • 特に方法論は紹介されていません。 • 海外では、David Hay氏、Len Silverstone氏、Steve Hoberman氏といった著名人が沢山の著書を出 し、或いは育成プログラムを提供していますが、特定の名付けたような方法論は存在しません。 • 日本国内 • 国内では、いくつかの良く知られた方法論があるので紹介します。 • TH法 • T（椿氏）、H（穂高氏）の両名が開発した方法論で、ChenのERモデルと同じ学会で発表されたものです。 • TM • 古くはT字形ERと呼ばれ、佐藤正美氏が開発したもので、私が利用している方法論です。 • 三要素分析法(TEA Method) • 渡辺幸三氏が考案したもので、企業システムの方法論として作られたものです。 作成：稲見 浩一 2026 17
18. 方法論について 方法論については「宗教論争」とも称されたことがあるように、自分が使ってきた道具 への拘りが強くなる面が見られます。ここではChatGPTに紹介してもらいましょう。 作成：稲見 浩一 2026 18 モデル 中心に置くもの TM経験者が物足りなく感じやすい点※ リレーショナルモデル 正規化・整合性 「DBを壊さず作る」 関係の意味が設計者の判断に埋もれやすい Chen ER エンティティと関連 「業務の登場人物を整理する」 関係が線で済みやすい TH法 分類・型 「業務で使われる概念の境界を揃える」 関係の管理実体が弱くなりやすい TM イベント＋対照表による関係の独立管理 「業務の因果と事実を捉える」 — ※私がTMの利用者であることと知っているChatGPTが加えてくれた視点です。
19. テーブル構成図とデータモデル 論理設計と物理設計があると出しましたが、この物理モデルにあたるテーブル構成図 をデータモデルだと考え、論理モデルを意識していない層がいることも課題です。 作成：稲見 浩一 2026 19 ⚫左側が論理モデル（TMという手法で IE記法で書いたもの）です。 ⚫右側は物理モデルやテーブル関連図と 呼ばれるものです。 ⚫業務としては左の図にあるように、 • 顧客には一般顧客と登録顧客が居 て、注文には一般注文の他に先行 注文がある。 • 先行注文できるのは登録顧客のみ で、一般顧客は一般注文のみで先 行注文はできない。（矢印部分） ⚫物理モデルとして実装時にまとめてしま うと、業務としては読み出せなくなってし まう。 データモデルとして、こちらしか 認識していない人が多い。 左側の業務を表したものを 知らないままである。
20. データモデリングには時間がかかる データモデリングを採用しない理由として「時間がかかり過ぎる」という話を聞きます。 1. データモデラーが居ないから • いざ始めるとなっても実際にはデータモデラーが居ないことは珍しくない • 育成してから書こうとすると立ち上がり時期の効率は良くない • 育成して実践支援する仕組み（外部から調達してでも）がないと難しいことは事実 2. 業務の解析に時間がかかる • 業務を解析してモデルに記述しようとすると実際に時間がかかることがあります • かかっているのは、モデルを書いている時間ではないことが殆どです • モデルを書いて業務仕様を詳細に詰めようとすると、疑問が出てきます • これは、属人化して知っている人が限られたり、厳密に規定しようとすると現場でも定義しきれない • 業務として規定し直す必要があると、そこに時間がかかります • これは、データモデリングを行わなくても仕様として抽出する必要があるものです • モデリングをしないと早くから課題に上がらない • 結果として手戻りにつながるが初期の進捗は早く見える • 余計に時間がかかることはなくて、早い段階で業務仕様の詳細化、特定に時間を要することがあるということを 時間がかかり過ぎると誤解することがあるようです。 作成：稲見 浩一 2026 20
21. データモデリングはいつするのか？ システム再構築時には、次のように行います。 作成：稲見 浩一 2026 21 現行に 関する インプット 論理 データ モデル 物理 データ モデル マッピング 現行 データ プロファイリング フィード バック 論理 データ モデル AsIsの世界（現状分析） ToBeの世界（業務からの設計） ⚫ AsIsでの課題 ⚫ 新規要件 物理 データ モデル • 標準化 • 設計 データ移行： AsIsの論理モデルとToBeの論理モデル間で変換の要件を決め、 AsIsの物理モデルからToBeの物理モデルへの変換仕様を作成する いきなり物理から物理では変換仕様に漏れが生じる 新規 システム マッピング 実装
22. 利活用時のモデリング対象 利活用時も、必要なデータがどこにあるか探した後、論理モデルを書かないとデータ 統合が難しくなります。 • 左図は、DMBOK2の第4章にあるエンタープライズモデルを示 した図です。 • 残念ながら、最下層の論理モデルが作成されていることは殆 どなく、すべてのモデルを書いてからしか利用できないのは現実 的ではないでしょう。 • 利用したい対象データが、この中のどこにあるのか特定し、その 周辺だけでも部分的にデータモデリングしておきましょう。 • これを場合によってはAシステムにあるものとBシステムにあるも のでは少しずつ異なっている、結果として統合が必要という形 で見つかることは稀ではありません。 • この結果をメタデータとして貯めていくことが必要です。 作成：稲見 浩一 2026 22
23. システム開発 かつて受託開発を行っていた頃の開発について別途説明してくれているものがあるの で、そちらを使って紹介します。 • ICONIXプロセスと呼ばれるものです。 作成：稲見 浩一 2026 23 この部分を TMによる データモデリング により実践 ① 業務の解析をTMというデータモデリング 手法により行います。 ② 機能を考える際にはユースケースモデル を用いて考えます。 ③ ユースケースを満たすデータモデルになっ ているのか、利用されていないエンティ ティがないようユースケースは足りている のか、両面から相互に検証します。 ④ 画面遷移など開発用のフレームワークを 含めた方式設計を行う。 ⑤ それらを元に、オブジェクトプログラミング などで実装する。
24. システム開発（関連情報） ICONIXは、本家サイト以外に次の情報があります。 作成：稲見 浩一 2026 24 Amazon（中古） 翔泳社 • 関連サイト • 関連動画 • ICONIXプロセスから学ぶオブジェクト指向モデリング 前編 後編 • 更に関連書籍です 上 流 か ら 下 流 ま で 生 成 AI が 変 革 す る シ ス テ ム 開 発 ソ フ ト ウ ェ ア 要 求 と 仕 様 : 実 践 , 原 理 , 偏 見 の 辞 典 酒匂 寛さんの課題・仕様・設計という本のP87に次のよう に書かれていました。 なお、ここで考えている前提は「システムとは外から与えられる 情報により、ドメインモデル*が更新され続けるものである」とい うものです。こうした考え方は特に目新しいものではなく、事務 処理系のソフトウェアを、巨大なデータモデルを更新し続けて いるものとして捉える見方はむしろ一般的な方法です。 *ドメインモデル ドメインモデルという言葉は、さまざまな意味で使われているが、 本書の中では「システム仕様が参照する情報モデル」という意 味で使用している。 2003年12月1日 初版第1刷発行
25. 人材育成 データモデラーの育成をどうするか？ • 2000年代に実践していた人たちは、最近では絶滅危惧種なんて呼ばれていたこともありまし たが、最近新たに取り組む人も増えているようです。 • 左図は、私が昔から使ってきた図です。 成長の段階を左から右へと書いています。 • 学習してある程度分かっても、実際に仕 事として取り組む、一人でできるまでには 大きな壁があります。 • 最も簡単に乗り越えるのは、既にできる 人に一緒にやって貰うことです。 • 社内にそういう人が居なければ、外部の コミュニティで探すという手もあります。 • DAMA日本支部 第10分科会 • データ横丁 などを活用しましょう。 作成：稲見 浩一 2026 25
26. 人材育成の例 私の後輩でもあり、富士通では最後には上司だった人物を紹介しておきます。 • 富士通グループ内でデータモデリングのコミュニティに相談に来てくれたのがきっかけで、それまで 学んできたもので十分にデータモデリングできると思っていたら、とんでもない勘違いだったと気付 いて、すっかり学び直してくれた人です。 • その後は仕事での実践も通じて、今ではすっかり仕事として確立し、お客様と共著で本を出す までになり、最近では海外での講演までこなすようになりました。 作成：稲見 浩一 2026 26 記事 と 動画 本書で紹介しているデータモデリングの手法を用い、それ に続いてデータプロファイリングを行い、実装設計のための データ標準化までを実践したプロジェクトについて、お客 様と一緒に書かれた本です。是非ご一読を！
27. 作成：稲見 浩一 2026 27 人材育成トピック ①業務の教育にも実力を発揮！ 再構築の準備として支援したお客様で、異動 してきてまだ間がなく、その部署の仕事について それ程詳しくない方に、データモデリングとデータ プロファイリングを実践していただきました。 • 最初にレクチャーをし、現行の業務の画面の情報を 基に、データモデルを書き始めてもらいました。 • 私ともう一名で、週に2～3回の支援時間を設けて、 何を書きたかったのか、それは業務としての詳細は？ というようなレビューを繰り返し実践しました。 • 最終報告の際に上司の方から、部署で最も業務に 詳しくなってしまっていて驚いた！凄い武器を手に 入れたものだと言っていただくことができました。 • 他にも、業務の教育という観点で役立ったのは当初 の計画外の成果だと言っていただく機会がありました。 ②もちろんエンジニアの教育にも！ 社内で別な部署からチームに人を預かり、育成 するというサービスをしていました。 • その部署の仕事を持ったまま、一時的に異動してき て貰い、そのプロジェクトで支援する他にチーム内の 活動としての育成にも参加してもらいました。 • 中に2年目になったところという若者が居て、まだその プロジェクトに配属されて間がなく、その業務の経験 もなかったので、仕事で疑問に思ったことも、うまく質 問することができなかったそうです。 • データモデルで業務を明らかにしながら共有していく ことができ、具体的にこれは必須なのか、単独で存 在するか複数なのか、こっちのモノとは関係しないの か？など具体的で的確な質問ができるようになり、 一気に成長した姿を見せてくれました。 • 今では元の部署にて先生と頼りにされているそうです。
28. 作成：稲見 浩一 2026 28 第二部： データモデリングの実践
29. 第二部について 第二部では、「astah*を使ってTMのモデルを書く」ということを通じて、実際に道具 を使いながら、データモデルが書けるようになることを目指します。 • データモデリングの本体である方法論としてはTM（Theory of Models）を用います • モデルを書く道具として、astah*professionalを用います • TMにはオリジナルの記法がありますが、ここではツールで書けるIE記法を採用しています • 途中には操作を覚えるために、簡単な演習を用意しているので、是非実践してみてください 作成：稲見 浩一 2026 29 ※試用でもastah*professionalを使えない方は、こちらへ
30. 準備 ◼ IE記法について ◼ ツール（astah*professional） 作成：稲見 浩一 2026 30
31. IE記法での表記 「拡張された表記」で紹介した中から本書ではIE記法を採用しています。 ◼ エンティティ • 対象を矩形で表します • 矩形の上にエンティティ名 • 矩形の上部にキー項目 • 矩形の下部に属性 ◼ リレーションシップ • エンティティ間を線で繋ぎます • 両端の記号で多重度を示します • 依存関係を持ちます • 強い関係（依存） • 弱い関係（非依存） 作成：稲見 浩一 2026 31 親必須 ① ② ③ ④ 左図の4つは、すべて依存の 関係にあります。 左のエンティティから右のエンティ ティに向けてリレーションシップを 引いたものです。 多重度は上から、 ①0以上 ②1以上 ③0または1 ④1 です。 非依存の関係については、 次のページで紹介します。
32. IE記法での表記（非依存） 前ページでは依存の関係を示しましたが、こちらでは非依存について示します。 作成：稲見 浩一 2026 32 親任意 依存の関係 （直線） 非依存の関係 （破線） 親必須 依存（強い関係）の関係では、 • リレーションシップの線は直線 • 引き込まれたエンティティの角は丸い • 親は必ず必須 • 親のキーがキー側に引き込まれる ですが、非依存（弱い関係）では • リレーションシップの線は破線 • 引き込まれても角は丸くならない • 親は必須でも任意でも構わない • 親側のキーは属性側に引き込まれる ため、更なる関連に伝播しない です。
33. 専用のツールを使う 昔は、お客さんのところに行って、話を聞きながら「それってこんな感じですか？」などと 言ってホワイトボードに図を書きながら話を聞いたりしてました。 • 現代では、ノートPCを持って行って、あるいはオンラインで話をしているので、初めから ツールを使って書いた方が効率的です • ツールには単にお絵描きとして矩形や線を書くことができるものがあり、Excelの描画機能や Visioなどを使って書く方も居ます。しかしながら、非常に効率が悪いのと、単なる絵だけでなく、 そこで分かっていること（業務仕様）は一緒に書きたいです • そのため、モデル自体を単なる図としてだけでなく、登場する個々の要素を記録できるツールが 必要です • そして、簡単に使えて、それなりに使える、なるべく安価なツールということで、次のツールをお奨 めしています • チェンジビジョン社のastah*professional です 33 作成：稲見 浩一 2026
34. astah*professionalの入手 こちらのサイトから入手してください • さまざまなライセンス形態があります • 20日間の無料トライアルが可能です • 無料ビューアーが用意されています レビューだけの方にご利用いただけます 34 入手して インストール済みの 前提で次に進みます 作成：稲見 浩一 2026
35. astah*Professionalを起動する astah*Professionalを起動してください • 様々な種類の図が書けます。「図(D)」メニューから「ER図(G)」を選んでみましょう 35 作成：稲見 浩一 2026
36. ER図を書く画面 ER図を書く画面が開きました。各部の名称を覚えておいてください 36 ツールパレット プロジェクトビュー プロパティビュー ダイアグラムエディタ 「表記」は、「IE」を 選択しておいてください マップビュー 作成：稲見 浩一 2026
37. TMを書く準備 TMにはモノの集まりなどの矩形に様々な意味付けをしています • astah*professionalには、この分類表記が無いため色分けでその分類を示します • 「ツール」タブから「システムプロパティの設定」で、「新規ERエンティティの型の色」を選び、 下図のように設定してください 37 色を設定する対象は以下のものです 色自体は何でも構いませんが、一般には プロジェクトなどで統一します • Resource（リソース） • Event（イベント） • 対照表 • 対応表 • クラス • 多義 • 再帰 作成：稲見 浩一 2026
38. 書き始めてみる では、指示に従って下の図を書いてみましょう 38 ① ツールパレット上のエンティティのアイコンからResourceエンティティを 選び、ダイアグラムエディタ上に置く ② 名称を「従業員」に変更する ③ 右クリックメニューから主キーの追加、またはShift+CTRL+Kキーで、 「従業員番号」を入力する（◆をクリックでも可） ④ 右クリックメニューから属性の追加、またはCTRL+Rキーで、 「従業員名」を入力する（◆をクリックでも可） ⑤ 「部門」も同様に作成する ⑥ エンティティのアイコンから対照表エンティティを選んで1つ置き、名称を 「従業員.部門.対照表」とする ⑦ 依存型リレーションシップを従業員から対照表に引く ⑧ 依存型リレーションシップを部門から対照表に引く ※ リレーションシップは、ツールパレットからの選択でも、エンティティに マウスを重ねて出てくるガイドからも引くことができます。 作成：稲見 浩一 2026
39. 作図練習1 39 作成：稲見 浩一 2026
40. 作図練習2 40 作成：稲見 浩一 2026
41. 知っておいて欲しいこと 1. モデルと図 • エンティティを作成すると、プロジェクトビューに作成したエンティティが現れていることに注意する • 「図から削除」と「モデルから削除」は違う • ダイアグラムエディタ上のエンティティを単純にDELキーで消してもプロジェクトビュー上の定義には 変化がない（モデルは削除されていない） • プロジェクトビューからモデルをドラッグして、ダイアグラム上にドロップすると、リレーションシップを含めて 再現される。あるいは別な図を作成してドロップすることも可能 • 右クリックメニューから「モデルから削除」すれば、プロジェクトビューからも削除される こちらは図からの削除ではなく、（プロジェクトからの）モデル自体の削除である 2. プロパティビューの活用 • 先ず、エンティティにしろ、リレーションシップにしろ、各属性にしろ、「定義」が書けるので活用すること これがないと、メタデータとして活用できるようにならない • エンティティの型であったり、リレーションシップの多重度であったり、依存と非依存の切り替えなども、 プロパティ上でもできる 41 作成：稲見 浩一 2026
42. モデルと図 42 ①こちらがモデル ②こちらは、単に 図に過ぎない ③図から、単純にDeleteしても、 モデルからは削除されない プロジェクトビューから「従業員」を 選んで、ダイアグラムエディタに ドラッグ&ドロップすると、きちんと 甦る 別な図にドロップしても表示可能 作成：稲見 浩一 2026
43. 図を書くだけがモデリングではない 事業における業務仕様の分析では、矩形と線で表されているだけではないものが 色々と判明してくるので、きちんと記載しておきます。 • astah*professionalではプロパティに定義欄があるので必ず書いてください • 定義欄は、ノートとして表示することも可能です 43 作成：稲見 浩一 2026
44. astah*を使って TMのモデルを書く マサミさんのサイトにある「モデル作成の手続き」の資料を使って、 astah*professionalでモデルを書いていきます 44 作成：稲見 浩一 2026
45. TMとは？ TMは、佐藤正美氏が開発したデータモデリング手法です。 データを捉えた事業解析手法と表現した方が適切かも知れません。 正美さんが書いているサイトがあります。ここに、TMの最新バージョンという ページがあり、図書の案内とTM3.0を説明した資料があります。 45 ▪図書 この方法論の成り立ちや、背景となる考え方が知りたい方は、是非こちらの本を読んでみてください 私が最初にこの手法を知った頃は、「T字形ERデータベース設計技法」という本だったので、データベース 設計という色が濃いかと思いきや、そこで使われる情報を明らかにしながら事業を解析する、あるいは 事業を設計するという手法です この本の巻末には、この手法を学び、実践した人たちからの寄稿による事例集もあって興味深いです また、途中にいくつか挟まる「問わず語り」というコラムも非常に面白いので読んでみて欲しいです ▪説明資料 TMについて手っ取り早く知りたければ、この資料を見れば良いと思います ただし、知った上で振り返るのに向いていますが、初めてという人には図書を読んでからの方が良さそうです 作成：稲見 浩一 2026
46. サイト 46 • こんな感じのサイトがあります • ここで「バージョン3.0」にオリジナルの解説があります • 本書で「TM」に興味が湧いたら、是非訪れて あちこちつついてみて下さい • 簡単には読み切れない情報量があります クリック 作成：稲見 浩一 2026
47. TMの特長 事業を解析しながら、データ構造を作る手法です。 47 ルールに従って作成します ⚫ ルールによりある程度機械的に作成できるので素早く作成できます ⚫ 正規化を特に意識しなくても、第三正規形（3NF）は保証されます ⚫ 漏れ・抜けがないことを検証できます データモデルで業務の流れがわかります ⚫ タイムスタンプを使ったルールにより実現します ⚫ DFDや業務フローは外部システムとの関係を表すもの、或いは個別に流れを説明するものなど、 用途に応じて必要最小限だけ作成すれば良いでしょう このモデルをベースに開発を行うことで、生産性とパフォーマンスを高められます ⚫ プログラムが単純(分岐が少ない）になります ⚫ RDBMSでは、Index-only、Null-keyといったテクニックにより高パフォーマンスを実現します 作成：稲見 浩一 2026
48. モデルの構成要件 図を「モデル作成の手続き（tm3-1.pdf）」からそのまま掲載します。 作成：稲見 浩一 2026 48 モデルの要件 「関係」の網羅性 「制約・束縛」の網羅性
49. モデルの構成要件（続き） モデルとは「模型／実例（現実の写像）」です。 1. 「ユーザ言語」を変形しない ⚫ 顧客（業務を行っている人）が使用している名前、用語を勝手に変更したり、 属性（項目）を勝手に追加しないでください ⚫ 変更や追加が必要な場合は、顧客の合意の下で行います 2. できる限り機械的に構成する ⚫ TMの文法（ルール）に従って構成します ⚫ ルール（構文）に則って書いたモデルは、ルール通りに読むことができます ⚫ ルールを外すと、他の人が同じように読めないモデルができてしまいます 49 作成：稲見 浩一 2026 取引のない管理はない。管理のない取引もない。 L-真（導出的な真）は複数あり得るが、 F-真（事実的な真）は一つしかない。
50. モデル作成の心得 「モデル作成の手続き（tm3-1.pdf）」からそのまま掲載します。 作成：稲見 浩一 2026 50 構文論＝妥当な（無矛盾な）構造 意味論＝①真とされる値 ②事業構造と一致 1.構文論が先で、意味論は後。 2.「関係」が一時的で、モノは変数。 （箱（モノ）じゃない、線（関係）を観よ！） 3.モノが一意に存在するかどうかははさておいて、 モノを一意にするアルゴリズムがある。
51. TMでの記法 TMには、オリジナルの記法がありますが、本書ではIEの記法を使います。 作成：稲見 浩一 2026 51 （TER-MINE2で作図したもの）
52. IEでの記法 astah*で同じ内容をIE表記で書くと次のようになります 作成：稲見 浩一 2026 52
53. ルールの話 モデリングの実施手順が決まっています。 1. 準備 ① モノを集める ② ものを分類する ③ モノを並べる 2. モデル（構文論） ① 関係を構成する ② セット（集合）を作る ③ 多値 3. モデル（意味論） ① クラスで整える 53 詳しくは、 サイトや図書を ご覧ください 作成：稲見 浩一 2026
54. １．モノを集める データモデリングのインプットとなるのは、業務の中での文章ですが、場合によっては業 務マニュアル（多くはその業務システムのマニュアル）の画面などを使って、言葉と意 味を拾っていきます。その際に、その何かに対して「それ」とか「これ」を指すものとして 個体指定子と呼ぶものがあり、これを取り上げます。 • 注文番号によって、注文を指している • 商品コードによって、商品を指している 何かを指す場合、それに従属して持たれている属性があります。 • 注文番号で指された注文には、注文日や注文金額といった属性がある • 商品コードで指された商品には、商品名や単価などの属性がある インプットの中から、個体指定子になり得る属性と、ならない属性に分類しながらイン プットごとの属性を集めていきます 54 作成：稲見 浩一 2026
55. モノを集める（仕訳帳） 情報を仕分けする • インプットとなる資料から項目（語彙）を抽出し、仕訳帳に転記する 55 上側に番号・コード類、 その他は下側に配置 仕訳帳 作成：稲見 浩一 2026
56. モノを集める（続き） 項目を転記する 56 ① 個体指定子（上側に仕訳されたNO・コード等）を上側 に転記して元帳をつくる ② 続いて、項目を下側に転記してモノの集まりを完成させる ① ② 3つの元帳（モノの集まり）が できた 作成：稲見 浩一 2026
57. 2．モノを分類する モノの集まりをイベントとリソースの2種類に分類します。 ① イベント 出来事・行為・取引・等（Event） 条件として「日付（タイムスタンプ）」が帰属する ② リソース（イベント以外） 出来事に関与するモノ（Not Event） イベント以外のモノの集まりである 57 操作としては、各元帳で「型」を選択する 受注日があるのでイベント 日付（タイムスタンプ）がなくイベントではないのでリソース 作成：稲見 浩一 2026
58. ３．モノを並べる 出来事など（イベント）の集まりを並べます。 ① イベントは時系列に並べる ② リソースは並びを問わない 58 受注番号 受注数 受注日 受注 顧客番号 顧客区分コード 顧客名称 顧客 商品コード 商品単価 商品名称 商品 出荷日 出荷番号 出荷 請求日 請求番号 請求 行為者(リソース)を並べる → 半順序 注文を受けて、出荷して、請求する できごと・行為・取引（イベント）を 時系列に並べる → 全順序 時系列で順序を持つイベントは左から右や上から下 へと組織で決めた書き方で並べて配置する 並びを問わないリソースは、その上下などに配置する 受注日 ≦ 出荷日 ≦ 請求日 作成：稲見 浩一 2026
59. 演習1 ここまでを実際にastah*を使って操作してみましょう。 ⚫ 受注入力画面抽出した仕訳帳を使ってモノを取り出してください 作成：稲見 浩一 2026 59
60. 演習1操作 作成：稲見 浩一 2026 60 こうやって転記して
61. ４．関係を構成する 分類し並べたイベント／リソースごとに関係を構成する 1. aとbが違うモノの集合である場合のaとbとの間の関係 ① イベントとリソースの関係：E ← R • イベントがリソースを引き込む ② イベントとイベントの関係：E +→ E またはE >-対応表- E • 後続イベントに対して先行イベントが1なら、後続イベントが先行イベントを引き込む • 先行イベントがNになるなら、先行イベントと後続イベントの間に対応表を置く ③ リソースとリソースの関係：R-対照表-R • 並びを問わないので、必ずリソース間に対照表を置く 2. 1つのモノの集まりからいくつかを選んで並べる：再帰 • 一つのモノから再帰表に2本の関係を引き込む 61 作成：稲見 浩一 2026
62. 関係を構成する（E-R関係） ①行為・出来事・取引(イベント)にモノ(リソース)が関与する • リソースからイベントに非依存の リレーションシップを引く • オリジナルのTMでは、関係を引き込むと 関係を示す(R)が付くが、IEの記法では リレーションシップを引くと(FK)が付く • RはRelationのRである • 個体指定子は属性側のエリアに引き 込まれる 62 非依存 作成：稲見 浩一 2026
63. 演習2 イベントにリソースが関与する関係を書いてみましょう。 ⚫ 図書館で会員に対して図書を貸し出します ⚫ 1回の貸し出しで貸し出すのは1冊のみです ⚫ 関係を書いてください 作成：稲見 浩一 2026 63
64. 演習2操作 作成：稲見 浩一 2026 64 非依存のリレーションシップを 会員から貸出しに引いて、 プロパティで 親は必須にチェック 0以上を選択
65. 関係を構成する（E-E関係） ②行為・出来事・取引(イベント)の先行、後続の関係 • 先行側が1かNかで分けられる • 先行側が1であれば、先行イベントから 後続イベントに向けて非依存のリレーション シップを引く • 先行側がNであれば、先行と後続の間に 対応表を置く 65 先行が1 先行がN 作成：稲見 浩一 2026
66. 演習3 イベント間の関係を書きましょう。 ⚫ 受注して出荷と請求を行います ⚫ 受注一つ毎に出荷し、請求は複数の受注にまとめて請求します 作成：稲見 浩一 2026 66
67. 演習3操作 作成：稲見 浩一 2026 67 非依存のリレーションシップを 受注から出荷に引いて、 プロパティで 親は必須にチェック 0または1を選択 受注と請求から、対応表を作る 依存で引き、受注からは0または1、 請求からは1以上を選択
68. 関係を構成する（R-R関係） ③2つのモノで作られる対照表 • リソース間に対照表を置く • イベントと異なり、並べる順番がなく、先行が1かと いう判断は入らず、常に対照表を置く • 必ず2つの間に置き、3つ以上の関係では、2つ ずつの関係とする 68 倉庫に棚があり、 その棚に商品が置かれている 作成：稲見 浩一 2026
69. 演習4 リソース間の関係を書きましょう。 ⚫ 生地をあるサイズに裁断して ⚫ 裁断した生地をカラーで染色する 作成：稲見 浩一 2026 69
70. 演習4操作 作成：稲見 浩一 2026 70 業務の順で、先に生地とサイズ で対照表を作る 作成した対照表とカラーで次の 対照表を作る
71. リソース間には、必ず対照表を置く 業務で、1対多の関係だとわかっていたとしても、必ず対照表を置いてください。 • 部門と従業員の関係で、従業員が部門を持てば所属部門を示せます。 • 果たして、兼務で二つの部門に属することがあれば？ • 従業員が、部門コード2を持つのでしょうか？ • まだ配属の無い新人の部門コードには何が入りますか？ • リソース間の関係は、必ず対照表を置いてください。 • 対照表に配属日の属性を持つこともできるようになります • 配属がなければインスタンスがなく、兼務なら複数あるだけです 作成：稲見 浩一 2026 71
72. 関係を構成する（再帰） 再帰表により、ひとつのモノの集まりの中から2つのメンバを選んで並べる • モノの箱と再帰表の間で2つのリレーションシップを引く • リレーションシップごとに(FK)が付いて、属性名が 引き込まれるが、2つ目には” _0“が付くので、 引き込まれた個体指定子の表はわかり易く名称を 整えて（変更して）おく 72 ある集合から値を2つ 取り出して並べる 作成：稲見 浩一 2026
73. 演習5 再帰表を書いてみましょう。 ⚫ 前ページの部品表を書いてみましょう 作成：稲見 浩一 2026 73
74. 演習5操作 作成：稲見 浩一 2026 74 ⚫ 再帰表を置きます ⚫ 部品から再帰に依存でリレーションシップを引きます ⚫ もう一本引くと引き込んだキーの名称に_0が付きました ⚫ 名称を変更します ⚫ 仕訳帳から残りの項目を移せば完成です 両方の名称を変えて、 親部品と子部品に しています
75. ５．集合(セット)をつくる モノの集まりで妥当な集合（セット） をつくる • モノを区分（分割・細分）する（集合と部分集合） • 同じ型の箱を必要個数分（下の図では2個）作り、 • ツールパレットからサブタイプを選び、箱を結ぶ • 識別子属性で集合を区分する属性を選ぶ 75 2本目は、最初の線の どこかから引く 作成：稲見 浩一 2026
76. サブセットとならない例 以下の場合は、分割されたサブセットにならない • 取引先には、（取引先区分コードによって分けられる）請求先、支払先、納入先がある • 一見すると、部分集合のようにも見えるが、請求先であり、支払先でもあり、かつ納入先となる 取引先があれば、「または」の関係が成立しない • あくまでも、取引先とその種類を示す取引先区分の組合せ（対照表）である 作成：稲見 浩一 2026 76
77. 演習6 「従業員」をサブセット化してください。 ⚫ 従業員区分コードで正社員とパートに分けられます ⚫ 福利費は正社員のみが持つ属性です 作成：稲見 浩一 2026 77
78. 演習6操作 作成：稲見 浩一 2026 78 ⚫ 同じ型の箱を二つ作ります ⚫ パレットからサブタイプを選び、元 のエンティティから子エンティティに 線を引きます ⚫ 最初に引いた線のどこかを起点に もう一本引き、属性を移動します プロパティで識別子属性区分を 選択します
79. ６．多値（多値のOR） 1つの属性値に複数の候補があり、選択して1つを用いる • 多値のOR（多義）の箱を用意する • 取り出した属性（例では商品単価）の候補の意味を示す属性を加える 例では、単価種別に「正価格」と「割引価格」が入る 79 これは、データベースでよく繰り返し項目を持って しまっているような例の分解とも言え、2種類存在 する ※列として単価1、単価2、単価3などと持っている 二つの内の一つが多値のOR（多義）で、 もう一つが次頁で紹介する多値のAND （HDR/DTL）です 作成：稲見 浩一 2026
80. 演習7 多義（多値のOR）を書いてみましょう。 ⚫ 元の情報としては、次のようになっています ⚫ 繰り返し項目になっている単価を取り出しましょう 作成：稲見 浩一 2026 80
81. 演習7操作 作成：稲見 浩一 2026 81 ⚫ 多義の箱を置いて、リレーションシップを引きます ⚫ 繰り返し項目を1つにまとめて、多義の箱に移します ⚫ 候補の意味を示す属性を加えて完成です。
82. 多値（多値のAND） 一度に複数の値を持つもので、いわゆる「ヘッダ-ディティール（HDR-DTL）」構成 （one-header-many-details） • 元のイベントやリソースから、同じ型のモノを作り、1以上の関係でつなぐ • 集合内の対象を示すための属性(明細番号)を個体指定子側に挿入しておく 82 この受注HDRと受注DTLの両方をもって、 受注というものを表している この二つを受注という概念的なスーパー セットで繋いでも良い 作成：稲見 浩一 2026
83. 演習8 一度に一つの商品しか受けられない受注を複数の商品を受けられるようにしましょう。 ⚫ 受注を多値（HDR/DTL）の形にしてください 作成：稲見 浩一 2026 83
84. 演習8操作 作成：稲見 浩一 2026 84 ⚫ 同じ型の箱を置いて、リレーションシップを引きます ⚫ キー項目側に明細番号を追加します ⚫ 商品からのリレーションシップをDTL側に移動します ⚫ DTL側に持つべき属性を移動します
85. ７．クラスで整える オリジナルでは「T字形の左側にクラスを適用」と「T字形の右側にクラスを適用」とし て2種類示されている • ここでは「右側に適用」に相当するものを取り上げる • 入社日は、従業員自身の属性ではなく、従業員が入社した事実を表すが、独自の個体指定 子を持たない出来事なため、「クラス」の箱を出して、入社日をそこに移す 85 従業員に従属するが 「入社」というイベントが 混入している 作成：稲見 浩一 2026 左側 右側 ※TMオリジナル表記
86. クラスで整えるの例 作成：稲見 浩一 2026 86 本来、そのモノ（集合）に属さない（混入している）属性を外に出す ①一つのリソースの中に、 イベント的性質が混入している ②一つのリソースの中に、 他のリソース的性質が混入している ③一つのイベントの中に、 リソース的性質が混入している ④一つのイベントの中に、 他のイベント的性質が混入している
87. クラスで整える（左側） かつては概念的スーパーセットと呼んでいたものである • 2つのリソースがある • これらを1つのクラスの箱を作って概念的にまとめる • サブセット化の逆で、スーパーセットとしてクラスを置く • ここでは、個体指定子を持たない 87 営業所も特約店も 取扱店である 概念的な スーパーセットを設ける 作成：稲見 浩一 2026
88. 演習9 次の受注から、受注自体の属性ではないものをクラスに出してください。 ⚫ 出荷時に、必要に応じてコメントを付けます 作成：稲見 浩一 2026 88
89. 演習9操作 作成：稲見 浩一 2026 89 ⚫ クラスの箱を置いて、リレーションシップを引きます ⚫ 多重度は、0または1にします ⚫ 受注ではない出荷の属性を移動します ⚫ 同様に、任意であるコメントも別のクラスに出します
90. ここまでがルールの紹介です 90 1.モノを集める • 仕訳帳を作る 2.モノを分類する／並べる • 取り出してイベントとリソースに分ける • イベントを時系列に並べる 3.関係を構成する • リソースをイベントに引き込む • 先行イベントを後続イベントに引き込む • 複数の先行イベントを対応表でまとめる • リソースとリソースを対照表でつなぐ • 同じ集合から取り出す再帰 4.セット（集合）を作る • サブセット化できるものは分ける 5.多値を扱う • 多義を取り出す • HDR/DTLを構成する 6.クラスで整える • 紛れ込んだものを取り出す • 概念的スーパーセットを形成する 作成：稲見 浩一 2026
91. 練習問題 次の資料を使ってモデル図を作成してください。 • 資料1：受注入力画面 91 受注番号：XXXX 顧客番号：XXXXXXXX 顧客名称：XXXXXXXXXXXXXXXXXX 顧客住所：XXXXXXXXXXXXXXXXXX 顧客電話番号：XXXXXXXXXXX（ハイフンなし） 商品番号：XXXX 商品単価：99.999 受注日：XXXX-XX-XX 個人・法人区分：X 顧客区分：X 商品名称：XXXX 受注数：99 ※注：個人・法人区分コードで「個人」と「法人」に分けられる この例題は著書「事業分析・データ設計のためのモデル作成技術入門」のP223から引用したものである 著書ではオリジナル表記なものをIE表記を用いて図示している 作成：稲見 浩一 2026
92. （続き） • 資料2：出荷照会画面 92 出荷伝票番号：XXXX 運送業者コード：XXX 地域：X 顧客番号：XXXXXXXX 顧客名称：XXXXXXXXXXXXXXXXXX 顧客区分：X 顧客住所：XXXXXXXXXXXXXXXXXX 顧客電話番号：XXXXXXXXXXX（ハイフンなし） 受注番号 商品番号 商品名称 受注数 受注日 XXXX XX XXXXXX 99 XXXX/XX/XX XXXX XX XXXXXX 99 XXXX/XX/XX XXXX XX XXXXXX 99 XXXX/XX/XX XXXX XX XXXXXX 99 XXXX/XX/XX 出荷日：XXXX-XX-XX 運送業者名称： XXXXXXXXXXXXXXXXXX 便番号：XX 倉庫コード：X 個人・法人区分：X 作成：稲見 浩一 2026
93. （続き） • 資料2の補足 ①出荷伝票番号は自動的に採番される ②顧客は地域（コード）ごとにまとめられている ②-1 地域ごとに運送業者が割り当てられている ②-2 1つの倉庫は複数の地域を割り当てられている ②-3 便番号は運搬車の番号である ②-4 顧客の受注はいくつかまとめて出荷される ③運送業者に対して代替え運送業者も考慮されている ④出荷数量は受注数と同じである。 93 作成：稲見 浩一 2026
94. 練習問題（集める／仕分ける） 94 入力から項目を集めて仕訳帳を作り、個体指定子ごとに仕分ける 出荷照会画面にて受注が複数 あるので（xM：Multiple）と 注記しておくと作業しやすい 作成：稲見 浩一 2026
95. 練習問題（分類する／並べる） 95 これら2つだけがタイムスタンプを 持つので、イベントである 残りはリソース 作成：稲見 浩一 2026
96. 練習問題（関係を構成する） 96 作成：稲見 浩一 2026
97. 練習問題（集合／事実として正しいか調べる） 97 作成：稲見 浩一 2026
98. レビューのポイント データモデルのレビューを実施する際のポイントを以下に示します。 98 正しく書けたか モデルは事実を示しているか ◼ 個体指定子は実在しているものか • 勝手に作成していないか？実在するものか？ ◼ リソースとイベントは類別できているか • タイムスタンプが置け、順序が問われるか？ ◼ NULLが発生する属性はないか • 場合分けが必要ならサブセット化を検討する ◼ 区分コードが放置されていないか？ ◼ サブセット間に同じ情報が存在していないか？ ◼ クラスとして取り出せるような属性を見逃して いないか？ ◼ モノとモノの間の関係は正しいか？ ◼ イベントの順序(業務の順序)は正しいか、 例外はないか？ ◼ モノの中の属性(項目)はそのモノ自身に属する ことは正しいのか？ ◼ モデルに示されていない業務(抜け・漏れ)は ないか？ 作成：稲見 浩一 2026
99. プロパティの記載について 「図を書くだけがモデリングではない」でも記載しましたが、astah*professionalで は、プロパティに定義欄があります。 • この記入を徹底し、一つ一つのモデルのレビュー時には内容を確認してください。 • 特に、業務担当ではない人が代わりにモデリングするような場合には、個々のモノ、属性、 対照表、対応表、再帰を含めたすべての関係に対して、説明を記載しておいてください。 • 人が読むだけではなく、MCPサーバを呼び出す形で生成AIからastah*professionalの内容 を読みだすことができます。 • モデルから抜き出してメタデータとして活用する際のリッチさが大きく異なります。 • 単に名称が書かれているだけとは異なり、その説明がきちんとされていると、後で役立つものです。 • 対照表は、具体的に実際に使われているものなのか、単なるビューに過ぎないものなのか、この 定義を書いておくと、何を目的としてその関係を持たせたかが一目瞭然です。 • 特に、業務部門の方が自らモデリングしている際は、当たり前のこと過ぎて書いておくのは面倒 に感じるかも知れませんが、他の人やAIが読むためにも必ず書いておいてください。 作成：稲見 浩一 2026 99
100. 関係の検証表 リソースエンティティ間の関係を検証しましょう。 • 全てのリソースエンティティ間の検証というのは現実的で無いため、例えばある入力画面で 使われているものとか、一連の業務のイベントに関連するものに対して実施する • エンティティの関係があるものに◦を付ける • 既に確立しているはずの関係の見落としを検証する • 未だ確立していない関係の成否を検証する • 関係があればデータモデルに記入する 作成：稲見 浩一 2026 100 顧客 受注 商品 顧客 受注 商品 ◦ ◦ 持っているのに活用されていないデータを 発見し、他のデータとの関係を考えることに よって、新たなビジネスモデルの発見に つなげられる可能性が有る
101. 検証表（続き） 作成：稲見 浩一 2026 101 左の図の例で見てみる ◼ 現に成立している関係を◦印を付けて記述する ⚫ 顧客と受注は成立している ⚫ 受注と商品は成立している ◼ 成立していない関係を（成立するか否か）検証する ⚫ 顧客と顧客の再帰は可能か？ ⚫ 顧客と商品は関係しているか？ ⚫ 受注と受注の再帰は可能か？ ⚫ 商品と商品の再帰は可能か？ 顧客 受注 商品 顧客 受注 商品 ◦ ◦ 更にビジネスの可能性を検討してみましょう ◼ 3つのentity間に成立する「関係」の可能態は6つである ◼ 現実に成立している関係は、2つである（1／3の成立） ◼ 関係（ビジネス・ルール）の可能性として、2／3の余地がある ⚫ 顧客-商品に関係はないか？ 「特定顧客にのみ販売する（または販売しない）商品がある」、「欲しいものリスト」 など ⚫ 顧客-顧客に関係はないか？ 「紹介した顧客と紹介された顧客」 など ⚫ 商品-商品に関係はないか？ 「セット商品」 、「代替商品」など
102. モデルは文だ！（モデルを読む） 次のようなモデルの部分図があります。 • 何が書かれていますか？ 102 作成：稲見 浩一 2026
103. モデルは文だ！（書いてあること） 次のように読めるはずです。 • 従業員は、従業員番号で識別され、 氏名、かな氏名と生年月日を持っている • 部署は、部署コードで識別され、部署名を 持っている • 従業員は、いずれかの部署に所属することがある • 部署には、何人かの従業員が所属することがある • 従業員は、どの部署にも所属しないことがあり、 複数の部署に所属することもある 103 作成：稲見 浩一 2026
104. モデルは文だ！（実際のシーン） 実際の出現順は逆で、文章が最初にあります 104 ②モデルとして書く モデルで 表現する ①話を聞く 文章で 伝える モデルを見て、 文章として読む モデルを見て、 文章として読む ③モデルで意味を共有する 作成：稲見 浩一 2026
105. モデリングする意味（要するに） 105 業務の世界で使われている文を分解、 整理して一定の表記で表したもの 文はもともと命題なので、分解して 解明すれば、そこに論理を働かせる ことができる 文のままより、 「色々と扱える文」ということ モデルは「文」なので モデルが使えるということは、 次の３つができるということ 聞いたことを分解して、 モデルとして表現できる モデルを文として読める 元の業務を表す文章に戻せる 聞いたことと合っているか 確かめられる 結果として、メタデータの整備ができ、業務を可視化できる。 作成：稲見 浩一 2026
106. AI Ready？ ここまでお読みいただいた方は、この技術がナレッジグラフ、GraphRAGへの適用に 非常に効果がありそうだとお気づきかと思います。 • 「プロパティの記載について」にある通り、プロパティの定義欄が充実していると、ナレッジとしての 価値が高まります。 • データモデリングだけでは十分ではありません、そこから取り出してメタデータとして管理し、さらに データ品質の評価基準として用いること、それに対してデータプロファイリングを定期的に実行し て品質を確認、対策の手順を決めて実行することなどが求められます。 • これらはデータモデリングの実践に他なりません。DMBOK2の中でデータモデリングが頻繁に言 及されているという通り、データモデリングはデータマネジメントの中でも非常に重要かつ有効な ものです。 • データモデルもメタデータの一部として、継続して維持管理する必要があります。 • データガバナンスの一環として、データの定義と利用権限の付与と合わせて管理が必要です。 作成：稲見 浩一 2026 106
107. ここからは、おまけ情報 107 作成：稲見 浩一 2026
108. TMの歴史 TMの学習を行うなどの活動をしている「TMの会」というコミュニティにて 次のような図が掲載されていました。 108 T字形ER TM1.0 TM2.0 TM3.0 本書の 原点 作成：稲見 浩一 2026
109. 佐藤正美の書籍 過去に様々な書籍があります 抜粋を掲載していますが、右端の「最新刊！」としているものを入手しましょう RAD本で、「T字形のフォーム」が登場し。黒本から「T字形ER」という 名前が登場し、赤本の頃から「TM」という名称になりました 109 RAD本 黒本 論考 赤本 最新刊！ 作成：稲見 浩一 2026
110. モデルによって生み出される可能性 是非、こんな本を読んでみてください • マサミさんは、昔から趣味でウィトゲンシュタインの本を読んでいたりして、「黒本」や 「論考」には『論理哲学論考』という本からの解釈が色々と登場したりしました • しかしながら、論考自体は私には難しくて読めたようなものではありませんでした • そこで、この本の登場です 110 ウ ィ ト ゲ ン シ ュ タ イ ン 『 論 理 哲 学 論 考 』 を 読 む •シリーズ:ちくま学芸文庫 •1,430円(税込) •Cコード:0110 •整理番号:ノ-3-1 •刊行日: 2006/04/10判型:文庫判 •ページ数:384 •ISBN:978-4-480-08981-6 •JANコード:9784480089816 この本の32ページ辺りを じっくり味わってください。 「１・１改 世界は事実の総体 であり、個体、性質、関係の総 体ではない。」 「２－３ なぜ事実は対象へと 解体されなければならないのか」 作成：稲見 浩一 2026
111. 何故TM？ 敢えて、ここで書きますが、私がなぜTMを使い続けてきたのか？ もともと計測制御から、いわゆる基幹業務へと対象を広げる際に最も問題だったのは、 取り扱われている業務について知らないことでした。 単なる設計方法というより、その業務で扱われている情報について詳細に知り、知っ たと思ったことをお客様と共有して確認、合意する方法を模索しました。 その中で見つけ、最もヒットしたのがTM（T字形ER）でした。 最大の理由はシンプルに作られたルールです！これによって誤解なく読むことも含めて 業務知識の暗黙知を形式的に表して可視化することができました。 他の方法論が良いという方はそれで良いでしょう、使い慣れ、それで問題なく運用で きるなら無理に変えようと言うつもりはありません。ただ、初学者の方は、できれば既 にできる人からTMを習うのが最強だと思っています。 作成：稲見 浩一 2026 111
112. なんでastah*を使っているの？ そもそもUMLを書くツールだった（Jude竹という名の頃から） • そして、ER図を書けるモデリングツールとしては絶対的に安価！ • モデルと図を分けられるし、直感的にパッと書ける 良く、データモデリングと一緒に奨めてきたのがICONIXです 112 この部分に TMの手法を 使ってきたと 言っても 良いでしょう 左図のこの部分以外には様々なUMLの 図を用います よって、同じツールでパッと書けると便利です 実は、ICONIX自体を推奨してやってきた のではなくて、ER図とUMLを併用してきて 振り返ると、昔から提唱されていたものが あったので、それを推奨してきたものです こういったものが参考になると思います 作成：稲見 浩一 2026
113. 他の無償で使えるツールは？ 例えば、A5:SQL Mk-2を試してみました。 113 似た図が書けなくはないが、書くのが手間で、 文法をしっかり知っていないと間違い易い そういう意味で初心者の学習に向いている とは言いにくい また、図が書けるだけで定義も書けず、図と モデルが分離できていない そういう意味では、実用性がない でも、どうしても無償の環境で書くのなら、 書けましたよということで 作成：稲見 浩一 2026 なお、無償ではなくても企業で使えるデータ モデリングツールが決められている場合は、 astah*でのエンティティの型の色に変わる 方法がないか検討してください 最悪の場合、名称の末尾に【R】、【E】、 【MO】、【Class】などと書く方法もあります。
114. 最後にもう一度 ここまでお付き合いくださり、ありがとうございました。 ここで紹介したTMというモデリング手法については、開発者である佐藤正美さんに、 今でもアクセス可能です。 作成：稲見 浩一 2026 114 著書： 本書での説明だけで、現実にモデリングは可能になりますが、 それでもこちらの著書は、必ずお読みください。 初心者に向けて敢えて本書では取り上げなかった事項も含 めて、是非読みこんで欲しいです。 →にあるセミナーも是非受講してください。 サイト： TM3.0の説明資料もあるし、セミナーの案内もあります。 過去の本の読み方、解説もあるし、様々な物事の学び方の ページも用意されています。 訪れて、あちこち読み漁ってみてください。
115. コミュニティ活動 次のコミュニティに顔を出しています • DAMA日本支部 第10分科会 • JDMC（以下のリンクはFY25のモノです） • MDMとデータガバナンス研究会 • 生成AIによるデータ管理研究会 • データマネジメントの価値研究会 • 「データマネジメント座談会」コミュニティ • データ横丁のデータモデリング通り • TMの会：モデサロン←これはconnpass上のもの 115 ➢ 詳細はこちらから ➢ Slack 最後の1つ以外のコミュニティでは、 TMの手法に限らず様々な話題が 扱われています 作成：稲見 浩一 2026
116. ご覧いただき、 ありがとうございました 質問などご連絡は、 各コミュニティにてお願いします データ横丁のSlackが最も便利そうです あるいは、FacebookやLinkedInのメッセージなど お仕事での依頼でという方は、メールでご連絡ください 116 作成：稲見 浩一 2026