データモデリング入門2021
•
0 likes•860 views
以前にも公開した「データモデリング」の改版です。 モデリングの本体部の改版はそれほどでも無いですが、その周辺について、少し書き足しました。 特に、レガシーシステムのブラックボックス化に悩む人や、データを活用したいが何処にあるかわからないとか、データマネジメント（例えばMDM）に取り組もうとしているけどパッケージばかり売りつけられて困っている人、是非ご一読ください。
More Related Content
What's hot
What's hot (20)
Similar to データモデリング入門2021
データモデリング入門2021
- 2. Agenda ◼ はじめに ⚫ 「DXレポート」の発行以来 ⚫ 問題の原因と対策 ⚫ データマネジメント ⚫ システム開発の経緯を振り返る ◼ モデルの変遷 ◼ 標準記法とツール利用 ◼ モデリング手法詳細 ◼ 実践と補助資料 ◼ おさらい ◆ おまけ ◆ 参考資料 ◆ 仲間を見つける ◆ 本書のTMに関する注意 2
- 3. はじめに ◼ 本書について（対象者と目的） ◼ 2014年に公開した「データモデリング入門－astah*を使って、TMの手法を使う－」の 焼き直し版です。 ◼ DXが何かと話題になる中、データマネジメントの重要性が高まり、その中でも 重要な役割を持つデータモデリングとして改めて紹介し、手が動く人が少しでも 増えればと思い、加筆、修正したものです。 ◼ 自社の業務を情報の視点から可視化し、データを利用・活用できるように 整えたい、あるいはそういったお客様を支援するベンダーの方を対象としています。 ◼ 始めるには ◼ 道具（astah*Professional）を手に入れてください。 ◼ 必ず、既に実践的に使える人を見つけて習ってください。 ◼ 本書を使えば、astah*を使って、TMの手法でデータモデルを書いてみることが できますが、それ以上のことは期待できません。 ◼ 一度書いてみれれば、自分の課題について書き始めることができるでしょう。 ◼ その先は、良き先導者を見つけるのが問題解決の近道だと思います。 3
- 4. 「DXレポート」の発行以来 日本でも「DX」が大きく着目されるようになり、「データ駆動型経営」や、 「データドリブン」という言葉を目にする、耳にする機会が増えました。 本書では、次の2つの視点で「データモデリング」を紹介していきます。 4 2025年の崖問題 データ利活用での課題 ⚫ 企業の情報システムが老朽化し、これまでの 経緯により肥大化、複雑化している ⚫ 特に複数のシステムが乱立し、サイロ化している ⚫ 維持費ばかりかかって、新たな投資への抑制と なってしまっている ⚫ 改修も難しく、経営のアジリティを阻害している ⚫ 分析に使おうとしても、準備に8割の時間や 労力が必要となっている ⚫ 見たいデータがどこにあるのか、または無いのか わからない ⚫ 欲しいデータが探せない ⚫ フォーマットがバラバラで、すぐに利用できない ⚫ 項目の意味が不明だったり、似たもの、重複、 多義などがあり、すぐに使えない ⚫ データの正確性が不明
- 5. 問題の原因と対策 5 2025年の崖問題 データ利活用での課題 ⚫ 単純な計算の繰り返しなど、情報システムの 黎明期から「給与計算」といった一つの業務を 単位として自動化や機械化を実現してきた ⚫ 需要が一気に増え、開発者も賄えない中で、 この「業務」を単位として「機能」を作成する 形態でのシステム開発が続いた ⚫ その際に「データ」が付属物のように扱われ、 機能を実現する以上に重視されて来なかった ⚫ 左記のような開発の経緯の中で、利用、活用の 視点が持たれず、「業務を回す」ことが重視 される中で、個々に蓄積された「データ」が保存 されてきたこと ⚫ その中で、個々のシステムに最適化した形で データ項目が設定され、アプリケーションの都合で 意味が変えられることも起きていた ⚫ 統合されず、重複が放置されてきた 対策： ⚫ 情報の構造から分析、設計し直すことから 始める→データモデリングを行う ⚫ 社内の各システムごとではなく、エンタープライズ モデルを作成する ⚫ 統合されたデータ環境を念頭に開発し直す 対策： ⚫ メタデータ、特にビジネスメタデータを定義し、 各項目の意味を明らかにする→データモデリング ⚫ 統合されたデータ基盤を構築する ⚫ メタデータを検索し、統合されたデータ基盤が アクセスできるデータカタログを整備する
- 7. システム開発の経緯を振り返る 7 データはプログラム中に 混在していた データは比較的単純であり、 現在に比べれば少量 経理、販売管理、生産 管理などと部門単位で システム導入が行われた 対象業務が増え、 データ量も増大した 情報自体が企業の 存亡を左右するように なってきた 情報量は比較にならない 程に増大した バッチ オンライン インターネット クラウド マシン語 COBOL 4GL Java、Pythonなどなど ISAM RDBMS NoSQL 構造化 データ中心（旧：DOA） オブジェクト指向 データ駆動
- 8. モデルの変遷 ⚫ モデルの変遷 ⚫ リレーショナルモデル ⚫ ChenのERモデル ⚫ その後の拡張ERモデル ⚫ そしてUML 8
- 10. リレーショナルモデル 10 ⚫ RDBMSの基になったことで知られています ⚫ 複雑化し、データ量が飛躍的に増え、それまでのファイルシステムで扱うことが困難になったことで提唱されました ⚫ 1970年に当時IBM社のE.F.Codd博士により、A Relational Model of Large Shared Data Banks と いう論文で発表されました ⚫ 行（row）と列（column）により「表（table）」の形で表されることで知られています その行と列については、次の考え方で示されました 社員番号 882201 882305 882412 氏名 鈴木次郎 田中太郎 伊藤三郎 本籍地 神奈川県 北海道 石川県 882412 伊藤三郎 石川県 タプル：tuple 属性値の集合（値域：Domain）から、それぞれ値を持ってきて組（タプル：tuple）を作る。
- 11. 11 社員番号 882201 882305 882412 氏名 鈴木次郎 田中太郎 伊藤三郎 本籍地 神奈川県 北海道 石川県 882412 伊藤三郎 石川県 タプル：tuple ⚫ 「社員番号」という属性値の集合（ 𝑋1）に含まれる値（s1）である「882412」 ⚫ 「氏名」という属性値の集合（ 𝑋2）に含まれる値（s２）である「伊藤三郎」 ⚫ 「本籍地」という属性値の集合（𝑋3）に含まれる値（s3）である「石川県」 ⚫ これらが、属性値集合の並びのとおりに取り出されたものがタプルであり、その状態を「関係Rにある」と示しています ⚫ この属性値の集合は、Domain（ドメイン）と呼ばれ、DDDという開発方法論やRDBを扱う方なら、 Data Domainとしてお馴染みかと思います 図を式で表すと、次のように書けます。 関係：R={(s1 , s2, …, sn) | s1 ∈ 𝑋1, s2∈ 𝑋2,…, sn∈ 𝑋n}
- 12. 12 関係：R={(s1 , s2, …, sn) | s1 ∈ 𝑋1, s2∈ 𝑋2,…, sn∈ 𝑋n} 式とともに、次の規則を覚えておいてください。 ① 各行（row）は関係Rのn個の組（n-tuple）を表す ② 行（row）の順序は、重要ではない ③ すべての列が異なっている（識別できる） ④ 列（column）の順序には意味がある 関係Rの定義された各属性値集合の並び{𝑋1, 𝑋2, …, 𝑋n}と一致する （その並び順の意味ではなく、どの行も同じということ） ⑤ それぞれの列（column）の意味は、対応する領域（domain）の名前でそれを標識付けすることに よって、部分的に表わされる ここから、次のことがわかるはずです。 ⚫ あるドメインに異種のものを入れてはいけない。 ⚫ 同種の情報を異なるドメインに分けてはいけない。 ⚫ ある要素snに勝手に意味付け（そのドメインの意味）を変えてはいけない。
- 13. ChenのERモデル Coddは、リレーショナルモデルを示した際に、そのデータを整理するための手法として、正規化を用いる こと（正規形）を提唱しました。並べたタプルの項目を第一正規形に整理し、それを第二、第三と順に 正規化する方法です。 しかしながら、それは面倒で、もっと良い方法があると、P.P.Chen博士が1976年のVLDB学会で 「The Entity Relationship Model – Toward A Unified View of Data」という論文を発表しました。 そこで示されたのは、次の図で表したモデルです。 13 PROJECT PROJECT- WORKER EMPLOYEE WORKER PROJECT M N ENTITY SET ENTITY SETRELATIONSHIP SET 図の表記は、次の通りです。 • ENTITYは、モノ（thing)であり、この集合を矩形で表す • RELATIONSHIPは、モノとモノの関係であり、この集合を、 ENTITY間をつなぐ線の上に菱形で表す
- 14. その後の拡張ERモデル P.P.Chen博士のERモデルは、Chen博士の努力もあり、普及は非常に進みました。 しかしながら、表現力が不足しているとして、様々な拡張が行われてきました。 主な特長として、次のようなものが見られます。 ◼ ChenのERモデルでの関連型（菱形で示す）を廃し、基本的には、 エンティティを1対1、あるいは1対多のみで表現する。 14 従業員 部署 従業員 部署 配属 交差エンティティ 多対多のままの表記 複数の1対多に展開した表記 サブセット（タイプ）の表記 営業所 営業所コード 直営店 営業所コード 特約店 営業所コード 汎化・特化
- 15. そしてUML ここまでは「データ」に関する構造に着目してきましたが、仕様や設計を表すには他の表現力も必要です。 そこで、UMLの登場です。 15 ⚫ UMLは、Unified Modeling Language（統一モデリング言語）の略で、オブジェクト指向技術の標準化 団体であるOMG（Object Management Group）によって仕様が策定されたモデル表記法の定義です ⚫ Booch法のGrady Booch、OMT法のJames Rambaugh、後に加わったOOSE法のIvar Jacobsonの 3氏が、各々の方法論と表記法を統一しようと試み、表記法のみの統一に成功したものです。 ⚫ 現在は、2017年12月にリリースされた 2.5.1 が最新版です。 ◼ 使い分けと併用 ⚫ データモデルとしては、次の用法があります • データモデルとしてはER図を用い、他の表現にはUMLを用いる • データモデルとしてクラス図を用い、ER図は使用しない ⚫ クラス図以外で主に併用される図としては、ユースケース図、ステートマシン図、 シーケンス図、アクティビティ図が有用です
- 17. 標準記法と ツール利用 ⚫ 標準記法と ツール利用 ⚫ 表記法紹介 ⚫ IE法の表記 ⚫ モデリングツール ⚫ astah*Professionalを起動する ⚫ 矩形の色分け ⚫ 書き始めてみる ⚫ 作図練習1 ⚫ 知っておいて欲しいこと ⚫ モデルと図 17
- 18. 表記法紹介 拡張されたER表記には、いくつか代表的な表記法があるので、ここで紹介します。 18 IE法 IDEF1X Barker-ER 最も一般的なデータモデリング作図スタイル が、「インフォメーションエンジニアリング」 （IE）の表記法である。 James MartinがIEについての彼の有名な 著作や、IEについての教育を行っていく中で、 一般に普及するようになったために、この名 前がついた。 IE記法では、三叉の槍または「烏の足」の 形をした線と、○や|の記号を使ってカーディ ナリティを表現する。 別のデータモデリング表記法で、元々は 米国空軍のために開発されたものである。 「烏の足」にかわって丸（黒と白）と線 （実線と点線）を使い、IEと同様の意味を 伝達している。 米国標準技術研究所(NIST)が規格化 したもの。 IDEF0のプロセス図では、IDEF1X記法を 用いることが多い。 Richard Barkerらがイギリスのコンサル ティングファームであるCACIにて1981年頃 開発した表記方である。BarkerのOracle への入社で採択され、Case Methodシリー ズの一部として定義されている。 「烏の足」表記のバリエーションでもあり、 ネストされたボックスでの抽象化表記と、 排他的弧や、ロールアップエンティティなどが 特長的である。
- 19. IE法の表記 ◼ エンティティ ⚫ 矩形の上にエンティティ名 ⚫ 矩形の上部にキー項目 ⚫ 矩形の下部にキー項目以外の属性 ◼ リレーションシップ ① 1対0以上Nまで ② 1対1以上Nまで ③ 0または1対0以上Nまで ④ 0または1対1以上Nまで ◼ 依存関係 A)強い関係（依存） • 矩形の角が丸い B)弱い関係（非依存） • 矩形のまま 19 ① ② ③ ④ A) B)
- 20. モデリングツール データモデルを書くにも、専用の道具が必要です。 20 打合せの場などで、話をするのに ホワイトボードに手書きするような こともありますが、それでも後で使う のなら、いずれ何らかの形でPCで モデルとして書くことになります。 モデル図を書くからとVisioを使う人 や、何でもかんでもExcelで書く人も いますが、それは単なる図に過ぎま せん。 作成や修正の効率を考えても、メタ データとしての定義のことからも、そう いった図だけ書くのではなく、必ず 専用のツールを使ってください。 どのツールを使うか？ いくつか良く知られているものがあるので、紹介しておきましょう。 Erwin Data Modeler ／ Embacadero ER/Studio Oracle SQL Developer ／ SI Object Browser ER ChangeVision社 astah*Professional 物理モデルと、RDBMS間の連携など、 多機能ですが、高価です 左記に比べ、比較的に安価であったり、 無償のものも幾つか見られる Erwinなどより1桁は安価で、かつ UMLを書くことができる ⚫ 本書では、このastah*Professionalを使用します（参考：astah*を使いこなそう ライセンス案内） 実際のプロジェクトでは、お客様の指定のツールを使うこともあるので、できるだけ色んなツールを触っておきましょう。
- 24. 書き始めてみる では、指示に従って、下の図を書いてみましょう。 24 ① ツールパレットからエンティティのアイコンからResorceエンティティを選び、 ダイアグラムエディタ上に置く ② 名称を「従業員」に変更する ③ 右クリックメニューから主キーの追加、或いはShift+CTRL+Kキーで、 「従業員番号」を入力する（◆をクリックでも可） ④ 右クリックメニューから属性の追加、或いはCTRL+Rキーで、 「従業員名」を入力する（◆をクリックでも可） ⑤ 「部門」も同様に作成する ⑥ エンティティのアイコンから対照表エンティティを選んで1つ置き、名称を 「従業員.部門.対照表」とする ⑦ 依存型リレーションシップを従業員から引く ⑧ 依存型リレーションシップを部門から引く ※ リレーションシップは、ツールパレットからの選択でも、エンティティに マウスを重ねて出てくるガイドからも引くことができます。
- 27. 知っておいて欲しいこと ◼ モデルと図 ◼ エンティティを作成すると、プロジェクトビューに作成したエンティティが現れていることに注意する ◼ 「図から削除」と「モデルから削除」は違う ⚫ ダイアグラムエディタ上のエンティティを単純にDELキーで消してもプロジェクトビュー上の定義には 変化がない（モデルは削除されていない） ⚫ モデルをドラッグして、ダイアグラム上にドロップすると、リレーションシップを含めて再現される ⚫ 右クリックメニューから「モデルから削除」すれば、プロジェクトビューからも削除される 図の削除ではない、モデル自体の削除である ◼ プロパティビューの活用 ◼ 先ず、エンティティにしろ、リレーションシップにしろ、各属性にしろ、「定義」が書けるので活用すること これがないと、メタデータとして活用できるようにならない ◼ エンティティの型であったり、多重度であったり、依存と非依存の切り替えなども、ここでもできる 図上での操作と、プロパティ上での操作が可能なことがある 27
- 29. モデリング手法詳細 ⚫ TM(T字形ER手法)とは／特長 ⚫ 本書のベースとなっているサイト、書籍 ⚫ モデルの構成要件 ⚫ モデル作成の手続きの流れ ⚫ TMで作成するドキュメント ⚫ TMのオリジナル表記 ⚫ astah*で書くと？ ⚫ IE法によるリレーションシップ表記 ⚫ エンティティを構成／類別する ⚫ 関係を構成する ⚫ エンティティ間の関係 ⚫ エンティティが集合として正しいか調べる ⚫ エンティティが事実として正しいか調べる ⚫ 作図演習 29
- 30. TM(T字形ER手法)とは TM は佐藤正美氏が開発したデータモデリング手法です。 「DOA(Data Oriented Approach)」と呼ばれているデータ設計手法の範疇に含められて語られる こともありますが、単にデータ設計を行うのではなく、データから業務分析を行う手法です。 （佐藤正美氏本人はDOAの範疇に含められることは否定しており、 成り立ち的にはオブジェクト指向の 方が馴染みが良いでしょう） 本来は、IEの手法に近い独自の記法が用意されていますが、本書ではIEの記法で説明します。 購買管理、販売管理、生産管理などのいわゆる基幹系システムの業務分析・データ設計に適して います。DMBOK2の「第５章 データモデリングとデザイン」を参考にするならば、「リレーショナル」という スキームに属しているものです。 30
- 31. TMの特長 31 事業を解析しながら、データ構造を作る手法です。 ルールに従って作成します。 ⚫ ルールによりある程度機械的に作成できるので素早く作成できます。 ⚫ 正規化を意識しなくても正規化されたデータモデルが作成できます。 ⚫ 漏れ・抜けがないことを検証できます。 データモデルで業務の流れがわかります。 ⚫ タイムスタンプを使ったルールにより実現します。 ⚫ DFDや業務フローは外部システムとの関係を表すもの、個別に流れを説明するものなど、 用途に応じて必要最小限の記述で済みます。 このモデルをベースに開発を行うことで、生産性とパフォーマンスを高めます。 ⚫ プログラムが単純(分岐が少）になります。 ⚫ RDBMSでは、Index-only、Null-keyといったテクニックにより高パフォーマンスを実現します。
- 32. 本書のベースとなっているサイト、書籍 本書は「TM」という手法を扱っており、以下のサイトと書籍をベースとして います。（最終ページも御覧ください） ◼ サイト ◼佐藤正美の問わず語り ◼ TM の最新 バージョン （TM3.0） ◼ 書籍 ◼データベース設計論―T字形ER 関係モデルとオブジェクト指向の統合をめざして ほぼほぼ、本書の内容をベースとしています。 ◼T字形ER データベース設計技法 既に販売されていませんが、私のベースは今でも、こちらの本のままです。 32
- 33. モデルの構成要件 事実(現実的事態)を正確に記述するために以下の点に従いってください。 ユーザー言語を変形しない ◼ 顧客が使用している名前、用語を勝手に変更したり、属性(項目)を勝手に追加しないで ください。(必要な場合は顧客の合意の下で行います) できる限り機械的に構成する ◼ 後述するTMの文法(ルール)に従って構成します。 ◼ ルール（構文）を外すと、他の人が同じように読めないものができてしまいます。 33
- 34. モデル作成の手続きの流れ 下記を左から順に実行する 34 エンティティを 構成する ⚫ 項目の洗い出し ⚫ 個体指定子を見つける ⚫ エンティティの作成 エンティティを 仕分けする ⚫ イベントとリソースの区別 関係を構成する ⚫ イベント：リソース ⚫ リソース：リソース ⚫ イベント：イベント ⚫ 再帰 エンティティが集合と して正しいか調べる ⚫ 部分集合(サブセット) ⚫ 多値 エンティティが事実と して正しいか調べる ⚫ みなしエンティティ ⚫ スーパーセット (クラス概念)※ TMの基本 TMの拡張 ※本資料では説明を割愛します
- 35. TMで作成するドキュメント TMによるデータモデリングでは、ダイアグラムの他に補助資料として 以下のものを作成します。 35 補助資料 作成する単位 分析時 作成 設計時 作成 ①アトリビュートリスト アトリビュート(属性)ごとに作る エンティティ、属性ともにプロパティで定義を記述する ○ ○ ②リレーションシップの 検証表 情報（画面、帳票）ごとに作る ○ ③キー(index-key)の定義書 テーブルごとに作る ○ ④アルゴリズムの指示書 プログラムごとに作る ○
- 36. TMのオリジナル表記 本書ではastah*を使ってIE法で表記していますが、オリジナルの記法に ついても紹介しておきます 36 従業員番号 従業員氏名 ・ ・ 従業員 R AttributesIdentifier Entity名称 Entity種別 R：Resource E：Event エンティティの形が 「Ｔの字形」になっている。 仕訳帳の概念から応用 ◼Eventエンティティを時系列に左から右に並べて配置します。 ◼箱を線で結んで関係を示します。 （TMの結線はIE 表記を使用しています） ◼オリジナル記法に対応したツールには、以下があります。 ⚫ ITS社のTER-MINE2 ルールに準拠したモデルを書くには最適です。 楽々Framawork連携バージョンもあります。
- 37. astah*で書くと？ 表記が異なるため、次の違いが生じます。 37 エンティティ名 ◆ 箱（矩形）の形が異なる ◆ Identifierの(R)が、(FK)になってしまう ◆ IE法では、リレーションシップに依存型と 非依存型が有って、使い分けが必要になる ◆ EとかRとか種別が表記できない （種別毎の色分けだけはできる様になって いるため、それを利用するとともに、 エンティティ名の横に記載することもある） ◼ オリジナル表記 ◼ IE表記
- 41. 最初に行うのは、まず対象領域のインプットから項目を洗い出すことです。 そして、その中から個体指定子を見つけて、エンティティを捕捉します。 ◼ エンティティとは ⚫ TMでは、事業を行なっている者が、それを識別するために付与した何らかの「個体指定子」を持ったモノの集まりを 「エンティティ」として捕捉する ⚫ 個体指定子（認知番号と呼ぶことも）とは、 「xx番号」、「xxコード」、「xxID」といった管理番号のことで、事業を 管理するために事業に携わった人々の間で合意して使われているものである。SEが顧客と合意せずに勝手に作っては いけない。これを疎かにされると、後に事実との照合が難しくなってしまう ◼ エンティティの捕捉 ⚫ 例えば、「顧客コード」を用いた「顧客」エンティティ ⚫ 「商品番号」を用いた「商品」エンティティ など ○○伝票 注文番号：0001 顧客番号：1150 商品番号：AA11 注文日 ：12/12/12 数量 ： 50 エンティティを構成する 41 商品 商品番号 注文 注文番号 顧客 顧客番号
- 42. エンティティを類別する エンティティは、固定指定子を持ったものの集まりですが、TMでは次の2つに類別して扱います。 ◼ イベントエンティティ ⚫ タイムスタンプ（受注日、出荷日など）を持つもの ⚫ つまり、時系列に並べられる ◼ リソースエンティティ ⚫ イベントでないエンティティ ⚫ 並び順に意味が無い 時系列に並びを問うということは、業務上で順序となります。このため、イベントエンティティの並びを 追えば、業務フローを書かなくても、基本的な業務の流れを追うことができます。 一般的にはマスタデータとトランザクションデータといった言い方をされますが、通常その区別は感覚的に 行われています。 TMでは日付が「帰属する / 帰属しない」でイベントとリソースを区別することで、 恣意的な判断を排除しています。 ただし、作成したモデルを「事実として正しいか」顧客と確認する中で、 イベントとリソースの区別を変更する場合があります。 42 受注 Ｅ 受注日 受注数 受注NO 出荷 Ｅ 出荷日 出荷数 出荷NO 請求 Ｅ 請求日 請求金額 請求書NO イベントエンティティを時系列に配置する。
- 43. 関係を構成する エンティティとエンティティは関係を結ぶことができます。 一般的にエンティティ間の関係は「リレーションシップ（関連）」と呼ばれています。 またastah*でもリレーションシップと呼んでいますが、ここでは「関係」という言葉を使って説明します。 エンティティの関係には以下の種類があります。 ① リソース：リソース ② リソース：イベント ③ イベント：イベント（先行イベントが多になる） ④ イベント：イベント（先行イベントが多にならない） ⑤ 再帰 順に見てみましょう。 43
- 45. エンティティ間の関係（イベント：イベント 2種） 45 ◼ イベント：イベント 先行イベントが多（N）になる 対応表（交差エンティティ）を作る ◼ イベント：イベント 先行イベントが多（N）にならない 後続側に引き込む 両方のリソースから 対照表を作る リソースの個体指定子を 後続側に引き込む
- 47. エンティティが集合として正しいか調べる サブセット（真部分集合）を見つけます。 47 真部分集合なので、このサブセット間の 関係は、常にORでなければならない ◆ 「○○区分コード」などにより見つかる場合が多い ◆ 必ずOR （排他的選言）の関係でなければならない ◆ サブセット間の属性の構成が異なる場合には、 その可能性が高い ◆ 階層化することも有る。ものによっては、かなり深い （10階層とか）ことも有る ◆ 階層の順序を入れ替えても成立する場合、部分集合 ではなく、別な視点の分類にすぎない可能性が高い
- 48. １対多の関係は、多値と多義の２種類が有ります。 48 ◼ 多値 ⚫ 同時に複数発生する ⚫ 例：１つの受注と受注明細 ◼ 多義 ⚫ 同時に成立せず、利用時に選択するもの ⚫ 例：商品の或る種類の価格
- 51. 作図演習1 次の画面からデータモデルを作成してください。 51 受注入力画面 品目コード 品目名称 受注数品目単価 受注金額 XXXXXX ×××××××××× 9999,999 9,999,999 受注№：9999 受注日：9999－99－99 顧客№： 999999 顧客区分：×× 顧客名称：×××××× ◆ 書き方や意味については、（更に自分で学習できる様に）佐藤正美氏の 「データベース設計論ーT字形ER」の実践編に有る例題を題材にしています。 ◆ 詳しくは、図書を参照下さい。
- 55. 作図演習2 もう一問、こちらは過程を一通り追う問題です。 次の画面からデータモデルを作成してください。 55 申請情報 品目コード：XXXXXX 品目名称： ×××××××××× 申請日：9999－99－99申請番号： 999999 購入先コード：XXXXXX 購入先名称： ×××××××××× 数量：999 単価種別コード：XXX 単価：99,999 希望納期：9999－99－99 あり なし付属品： あり なし添付資料： 部門コード：XXXXXX 部門名称： ×××××××××× 使用者氏名：××××× 使用者電話番号： 9999999999 配送場所コード：XXXXXX 代替配送場所コード：XXXXXX
- 56. 以下を前提条件とします。 ①単価は、品目単価のことである • 単価には、「正価格（種別コード＝1）」と、「割引価格（種別コード＝2）」が有る ②付属品が「あり」について、資料添付が対象となる • 付属品が「なし」については、資料添付が対象にならない ③使用者は「社員」に限らないので、「社員番号」を使わないで、氏名を記述する ④配送場所は、申請した品目を配送して貰う場所のことである • 配送場所には、それぞれに代替場所の指定が可能で、代替場所コードには、 配送場所コードを使う ⑤品目毎に購入先が決められている 56
- 57. では、画面と前提条件を基に書いてみましょう。 ◼ まず、情報を仕分けし、エンティティを捕捉する ◼ 属性をわかる範囲で、エンティティに割り当てていく ⚫ 配置先が明らかでないものは、ラピュタに置いておく ◼ エンティティを類別する ⚫ タイムスタンプが置ければイベント、でなければリソース ◼ 関係を考え、リレーションシップを引いていく ⚫ リソースとリソースの関係の場合は、対照表を置く ◼ 多値と多義を考える ◼ 部分集合や構造を検討する ⚫ サブセットになるものを検討する ⚫ みなしに該当するものを探す 57
- 63. 検証と考察を行いましょう。 ◼練習問題だから、事実に対する検証はできないので、形式的なものである ◼考察すべき点や疑問点は、次の通り ⚫ その時点の単価を申請に記録しないか？ ⚫ リソース間の関係を点検する • 購入先と配送場所に関係は無いか？ • 品目と配送場所に関係は無いか？ ⚫ 各リソースエンティティと申請への関係が、非依存か依存か？ • TMには無い考え方、ルールであるため規定しにくい ◼結果的に、イベント１つだけなので、配置に関する言及はできない。 複数のイベントが有るなら、時系列に並べる 63
- 69. 実践と補助資料 ⚫ レビューのポイント ⚫ モデルを読む ⚫ 検証にも分析にも ⚫ アトリビュートリスト ⚫ データモデリングと組織のお話 69
- 70. レビューのポイント データモデルのレビューを実施する際のポイントを以下に示します。 70 正しく書けたか モデルは事実を示しているか ◼ 個体指定子は実在しているものか ⚫ 勝手に作成していないか？実在するものか？ ◼ リソースとイベントは類別できているか ⚫ タイムスタンプが置け、順序が問われるか？ ◼ NULLが発生する属性はないか ⚫ 場合分けが必要ならサブセット化を検討する ◼ 区分コードが放置されていないか ◼ サブセット間に同じ情報が存在していないか ◼ みなしエンティティとなる属性を見逃していないか ◼ エンティティ間の関係は正しいか ◼ イベントエンティティの順序(業務の順序)は 正しいか、例外はないか ◼ エンティティの属性(項目)はそのエンティティに あるのは正しいか ◼ モデルに示されていない業務(抜け・漏れ)は ないか
- 74. 検証にも分析にも リソースエンティティ間の関係を検証しましょう。 ◼ 全てのリソースエンティティ間の検証というのは現実的で無いため、例えばある入力画面で 使われているものとか、一連の業務のイベントに関連するものに対して実施する ◼ エンティティの関係があるものに○を付ける ◼ 既に確立しているはずの関係の見落としを検証する ◼ 未だ確立していない関係の成否を検証する ◼ 関係があればデータモデルに記入する 74 顧客 受注 商品 顧客 受注 商品 ○ ○ 持っているのに活用されていないデータを 発見し、他のデータとの関係を考えることに よって、新たなビジネスモデルの発見に つなげられる可能性が有る
- 75. 75 左の図の例で見てみる ◼ 現に成立している関係を○印を付けて記述する ⚫ 顧客と受注は成立している ⚫ 受注と商品は成立している ◼ 成立していない関係を（成立するか否か）検証する ⚫ 顧客と顧客の再帰は可能か？ ⚫ 顧客と商品は関係しているか？ ⚫ 受注と受注の再帰は可能か？ ⚫ 商品と商品の再帰は可能か？ 顧客 受注 商品 顧客 受注 商品 ○ ○ 更にビジネスの可能性を検討してみましょう ◼ 3つのentity間に成立する「関係」の可能態は6つである ◼ 現実に成立している関係は、2つである（1／3の成立） ◼ 関係（ビジネス・ルール）の可能性として、2／3の余地がある ⚫ 顧客-商品に関係はないか？ 「特定顧客にのみ販売する（または販売しない）商品がある」、「欲しいものリスト」 など ⚫ 顧客-顧客に関係はないか？ 「紹介した顧客と紹介された顧客」 など ⚫ 商品-商品に関係はないか？ 「セット商品」 、「代替商品」など
- 76. アトリビュートリスト データ項目ごとに以下の内容を記述したリストを作成します。 モデル図では表現できない制約などを記述します。 個々のデータのメタデータの定義ということです。情報の構造定義とともに、個々の詳細を定義します。 データモデリングツールでは、データ項目ごとにこの内容を設定し、一覧出力できるようになっています。 76 1. 項目名 項目の名前を記述する。必要により論理名と物理名 （データベースに実装する名前） 2. データ定義 データ型、桁数や精度、値の範囲 3. 制約・束縛 他のデータ項目から影響を受ける場合や他のデータ項目に 影響を与えている場合は、その内容を記述する 4. 機密性 機密に該当するデータかを記述する 5. 導出手順や計算式 計算項目の場合はその計算式を記述する アトリビュートリストの例 論理エンティティ名 受注 物理エンティティ名 ORDER 論理名 値引き金額(D) 物理名 ORDER_NEBIKI_KINGAKU データ定義 NUMBER(10) 制約・束縛 顧客エンティティの顧客区分がゴールドの場合、システムパラメータ で指定された「値引き率」と計算し、値引き金額を設定する 機密性 なし 導出手順 顧客区分が一般の場合： 0固定 顧客区分がゴールドの場合： 受注金額(受注明細の１明細 「単価×数量」を計算しその明 細のすべての合計） * 値引率 / 100 小数点以下は切り捨てる
- 80. おさらい ⚫ データモデリング手順 ⚫ モデルは文だ！（モデルを読む） ⚫ モデルは文だ！（書いてあること） ⚫ モデルは文だ！（実際のシーン） ⚫ モデリングする意味（要するに） ⚫ モデリングする意味（開発に際して） ⚫ データモデリングについて 80
- 83. モデルは文だ！（書いてあること） 次のように読めるはずです。 ⚫ 従業員は、従業員番号で識別され、 氏名、かな氏名と生年月日を持っている。 ⚫ 部署は、部署コードで識別され、部署名を 持っている。 ⚫ 従業員は、いずれかの部署に所属することがある。 ⚫ 部署には、何人かの従業員が所属することがある。 ⚫ 従業員は、どの部署にも所属しないことがあり、 複数の部署に所属することもある。 83
- 87. 誰の DXの為には高品質なデータが必要だと気付いた人の 何を 自社ビジネスにおける情報構造の分析を 何で 精緻なデータモデリングを実施することで どうする 自社ビジネスにおける情報を認知、或いは再設計し、 活用可能な情報基盤の基礎となるメタデータを確立する そしてどうなる レガシー化した情報システムを変更が容易なシステムとして再構築したり、 利活用可能なデータとしてカタログ化や統合を推進する データモデリングについて 87
- 89. おまけ２ データモデリングの使い所として、私の同僚に数々の遅いシステムを速くしてきた人が 居ます。「夜間バッチが朝までに終わらない」みたいな声を受け、RDBMSのアクセスを 速くしてきました。（要望があれば、紹介します。或いは、育成もできます。） 過去には、100倍程度速くなったりしています。本人に言わせると、10倍程度では 負けた気分だと。勿論、元が真っ当に作られ、ハードウェアの限界の場合があります。 手順を示しておきます。 89 リバースモデリング アクセスパス確認 インデックス修正 SQL文修正 結果確認 現行システムの関連 テーブルを対象に、 リバースして、不足を 補ってデータモデルを 作成する。 画面等の入力ソース から、或いはヒアリング することで、アクセス パスを確認する。 アクセスパスを基に、 必要なインデックスを 作成する。或いは、 既存インデックスを 修正する。 アクセスに沿い、 インデックスを有効に 使えるようにSQL文を 修正する。 結果を確認し、 必要に応じて調整を 行う。
- 90. 参考資料 ◼ 本書は、以下を参考にしています。 ⚫DAMA／DMBOK • DAMA日本支部 http://www.dama-japan.org/ • 書籍「データマネジメント知識体系ガイド 第二版」 https://www.nikkeibp.co.jp/atclpubmkt/book/18/270160/ ⚫TM（旧：T字形ERデータベース設計技法） • 佐藤正美の問わず語り http://www.sdi-net.co.jp/ • データベース設計論―T字形ER 関係モデルとオブジェクト指向の統合をめざして ⚫ウィトゲンシュタイン『論理哲学論考』を読む 野矢茂樹 著 ちくま書房」の前半 http://www.chikumashobo.co.jp/product/9784480089816/ 90
- 92. 本書のTMに関する注意 本書は、TMの手法を用いながら、TMの記法ではなく、ツールとして astah*Professionalを使ってIE法を記法として採用しています。 私の場合、TMの手法を使っていると言いながらも、勝手に省略したり、 厳密なルールに関しては若干の違反があります。 TMの考案者である佐藤正美さんからは、教えても構わないと言って 頂いていますが、本家本元の佐藤さんのセミナーが開催されているので、 そのお知らせを置いておきます。 COVID-19の影響もあり、開催時期についてはサイトで確認してください。 ⚫ 佐藤正美のデータモデリング講座 「ビジネス分析＝設計モデル / モデル作成の手続き」 ⚫ 記事：～佐藤正美氏、若手エンジニアにデータモデリングを語る～ 92