data management,modeling,EA

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

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

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

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

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

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

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

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

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