データモデリングについて簡単に整理した。

1. DBエンジニアのための技術勉強会
「やはりデータ設計は大切です」
㈱ファイナンシャル ブレイン システムズ
藤原紀章

2. 本日の講演骨子
 情報システムの付加価値とデータ設計
 データ設計の設計目標
 データモデルについての概説
 データ設計の実際
–
–
要件定義工程
設計工程
 総括
2

3. 自己紹介
 氏名：藤原紀章（ふじわら のりあき）
 学歴：関西学院大学 商学部 卒業
 職歴：
–
–
–
–
–
信託銀行 営業店、システム部
システムインテグレータ アプリケーションSE、PL
DOAコンサルティング会社 DOAコンサルタント
海外パッケージ導入コンサルタント
システムインテグレータ PM
 趣味：フルートを吹く
3

4. 私とデータ設計
「データフロー図自体は、単にシステムを写し
取ったものにすぎないので、直接的な成果と
は認められ難いからである。」
堀内一、『データ中心システム設計』、1988、オーム社 より
4

5. 情報システムが付加価値を生む仕組み
 情報システムを単純なモデルで考察する。
【情報システムの価値実現モデル】
そうだったのか！！
蓄積
事実
情報の
生産
記録
編集
情報の
再利用
価値の
実現
データ
プロセス
 このモデルが示唆することは、
『情報システムによる価値実現は、
データおよびプロセス設計の巧拙による』、と言える。
5

6. 価値実現のイネーブラー
 情報システムの価値実現過程を「情報連鎖」という。
 その場合、「蓄積」と「再利用」が生み出す付加価値を左右する。
【情報連鎖を実現するもの（イネーブラー）】
そうだったのか！！
蓄積
事実
情報の
生産
記録
編集
情報の
再利用
価値の
実現
Data
Process
 連鎖をつなぐ「蓄積」
 利用者にサービスを提供する「再利用」
6

7. データ設計の設計目標
 業務忠実
–
–
ユーザ業務、要求事項を忠実に理解し、
データ構造に表現すること。
「忠実な理解」とは、業務の目的、存在意義、
意味を含む。
 データ品質
–
–
質の良いデータ構造を作成すること。
質とは、「業務忠実」を検証しやすいこと。
7

8. 「業務忠実」を考察する
 「事業・データ生産モデル」で考える。
【事業・データ生産モデル】
資源
投入
･･･ データ
マスタ
営業・生産・財務活動
イベント
分析
･･･ 事業活動
評価・統制
集約
情報
8

9. 「事業・データ生産モデル」の考察
事業の流れに沿っている
→業務の組み立て順に開発工程が設計できる。
単純、判りやすい
→関心の共有。
問題が具体化しやすい。
→事業課題をデータ項目まで構造化出来る
「あるべき姿」を提供できる。
→具体化してこそ、理想は達成できる。
9

10. 例えばこんな課題については？
グループ企業内事業統合をする
①場所 拠点の統合効果
②取引相手 与信管理の一元化
③商品・部品 ＳＣＭ、集中購買によるコストカット
④銀行口座 資金管理、内部統制の厳格化
⑤各種コード 勘定科目の統一、仕事の標準化
グループ統合マスタの「あるべき姿」を定義
イベント、集計情報へ展開 10

11. 具体化すると？
事業統合したいのだが。。。。
①
場所 場所を表すコードが統一されていない。
②
取引相手 取引先、支店、法人、グループが
システムごとに持ち方が違う。
③
商品・部品 同じ商品、部品に複数のコード。
④
銀行口座 口座番号を一元管理していない。
⑤
各種コード 勘定科目が不統一、意味が違う。
多重意味定義な区分が多い。
課題をデータ項目に具体化出来る。
11

12. 「業務忠実」ってレビュー出来るの？
【事業・データ生産モデルから導出されるデータ品質基準】
マスタ
①
範囲 なにをマスタにするか？
②
粒度 １レコードが指示す範囲は適切か？
イベント
③完全 正しく事実を捉えているか？
④存在 その場面で発生して良いか？
集計データ
⑤適合 意思決定に資するか？
⑥正確 偏向がない、再現性があるか？
12

13. データモデルの一般構造
【椿のエンティティ類型（１９９７年）によるデータモデルの一般構造】
【記号の説明】
タイプリソース
オカレンスリソース
イベント
要約
在庫
断面
１：Nの関係
13

14. 椿のエンティティ類型の功績
①データ発生順序を提示した
【記号の説明】
タイプリソース
オカレンスリソース
イベント
要約
在庫
断面
１：Nの関係
作業展開するにあたり上記順序で検討する
14

15. 椿のエンティティ類型の功績
②「タイプリソース」の発見
【記号の説明】
タイプリソース
オカレンスリソース
イベント
要約
在庫
断面
１：Nの関係
ビジネルルールを可視化した
15

16. データ設計の実際（要件定義）
要件定義工程のポイント




現行分析は「必ず」行う。
データ設計を行う。
凝った業務フローは作らない。
「用語」の意味定義を行う。
16

17. データ設計の実際（要件定義）
要件定義工程 作業展開例
【再構築プロジェクトの例】
素材収集
現行IPF
作成
現行
部分図
作成
新規IPF
作成
現行
統合図
作成
 IPF:インフォメーション・プロセス・フロー（椿、２００５）
 部分図：１つの業務画面、帳票のデータ構造を図示したもの。
 統合図：システム化範囲すべてのデータ構造を図示したもの。
17
新規
統合図
作成
データ
定義書
作成

18. データ設計の実際（要件定義）
IPFの紹介（椿、２００５）
【証券取引の例】
「処理」を書かない。
用紙は横向きがお勧め。
18

19. データ設計の実際（要件定義）
よくある 「業務フロー」 は使えない
【よくある「業務フロー」】
受注
出荷
売上計上
【IPF】
請求書
電話
注文
受注
受注
伝票
出荷
売上計上
納品書
無駄な分析をしなくていい。
客観的で標準化可能。
19
損益
仕訳

20. データ設計の実際（要件定義）
データ設計はKJ法と同じ発想で行う。
業務入出力
（具体的な事実）
部分図A
モデル化
統合図
画面
統合
部分図B
モデル化
帳票
※KJ法とは川喜田二郎氏が提唱した知的生産方法。
川喜田二郎、「発想法」、中公文庫、１９６７ 20

21. データ設計の実際（設計）
設計工程のポイント
 「意味論的ドメイン設計」を行う。
 データ構造に基づく部品化を行う。
21

22. データ設計の実際（設計）
「意味論的ドメイン設計」は意味がある。
【ドメイン設計の例】
 区分：排他集合（分岐に使用）
 分類：集約キー項目
 コード：マスタのキー項目
 シーケンス番号：イベントのキー項目
 数値：演算の対象
 文字列：属性

「１桁文字」、「９桁数値」（形式的ドメイン）は
使い勝手が悪い
22

23. データ設計の実際（設計）

データ構造は情報システムの部品の集合。

部品化に適した構造をしている。
【株式約定照合データモデル例】
※表記の説明
23

24. 総括
 データ設計は、情報システムがユーザにもた
らす付加価値を最も左右する。
 なので、情報システム開発において最も関心
を置かなければならない。
 要件定義工程では、要求事項の具体化と、
実現可能性の両者を具現化する。
 設計工程では、用語の意味とデータ構造に
沿った部品化を行うことで、そこに示された要
求事項を正確に設計することが可能になる。
24

25. 「統合」と「総合」
 要素技術を提供するベンダと、価値を実現す
るために要素技術を「統合」するユーザの構
図はこの４０年間変化していない。
 情報システムは「統合」によりユーザの業務
に付加価値をもたらす。
 要素技術を集めただけの状態、すなわち
「総合」では、付加価値を提供したことになら
ない。
25

26. 参考文献
•
•
•
•
•
堀内一、『データ中心システム設計』 、オーム社、１９８８
椿正明、『データ中心システムの概念データモデル』 、オーム社、１９９７
椿正明、『名人椿正明が教えるデータモデリングの“技“』、翔泳社、 ２００５
川喜田二郎、『発想法』、中公文庫、１９６７
ルイス・ガースナー、『巨像も踊る』、日本経済新聞社、２００２
26

27. ご清聴ありがとうございました。
本セミナー資料は、筆者が経験した知見やノウハウを集約し、技術交流を
図り コメントを頂戴することを意図しています。ただし、資料の中で示され
た内容 や意見は、株式会社ファイナンシャルブレインシステムズの公式見
解を示すも のではありません。 無断での転載・複製はご遠慮ください。商
用目的で転載・複製を行う場合は、 予め弊社までご相談ください。
27