やはりデータ設計は大切です 藤原紀章

DBエンジニアのための技術勉強会

「やはりデータ設計は大切です」

㈱ファイナンシャル　ブレイン　システムズ

藤原紀章

本日の講演骨子

情報システムの付加価値とデータ設計

データ設計の設計目標

データモデルについての概説

データ設計の実際– 要件定義工程– 設計工程

総括

2

自己紹介

氏名：藤原紀章（ふじわら　のりあき）

学歴：関西学院大学　商学部　卒業

職歴：– 信託銀行　営業店、システム部– システムインテグレータ　アプリケーションSE、PL– DOAコンサルティング会社　DOAコンサルタント– 海外パッケージ導入コンサルタント– システムインテグレータ　PM

趣味：フルートを吹く

3

私とデータ設計

　「データフロー図自体は、単にシステムを写し取ったものにすぎないので、直接的な成果とは認められ難いからである。」

堀内一、『データ中心システム設計』、1988、オーム社　より

4

情報システムが付加価値を生む仕組み

情報システムを単純なモデルで考察する。

このモデルが示唆することは、『情報システムによる価値実現は、　データおよびプロセス設計の巧拙による』、と言える。

記録

蓄積情報の生産

【情報システムの価値実現モデル】 そうだったのか！！

データ

プロセス

事実 情報の再利用

編集

価値の実現

5

価値実現のイネーブラー 情報システムの価値実現過程を「情報連鎖」という。

その場合、「蓄積」と「再利用」が生み出す付加価値を左右する。

連鎖をつなぐ「蓄積」

利用者にサービスを提供する「再利用」

記録

蓄積情報の生産

そうだったのか！！

Data

Process

事実 情報の再利用

編集

価値の実現

【情報連鎖を実現するもの（イネーブラー）】

6

データ設計の設計目標

業務忠実– ユーザ業務、要求事項を忠実に理解し、

データ構造に表現すること。– 「忠実な理解」とは、業務の目的、存在意義、

意味を含む。

データ品質– 質の良いデータ構造を作成すること。– 質とは、「業務忠実」を検証しやすいこと。

7

「業務忠実」を考察する

マスタ

イベント 集約

情報

資源

投入

分析

営業・生産・財務活動 評価・統制

･･･　データ

･･･　事業活動

「事業・データ生産モデル」で考える。

【事業・データ生産モデル】

8

「事業・データ生産モデル」の考察

事業の流れに沿っている

　　→業務の組み立て順に開発工程が設計できる。

単純、判りやすい

　　→関心の共有。

問題が具体化しやすい。

　　→事業課題をデータ項目まで構造化出来る

「あるべき姿」を提供できる。

　　→具体化してこそ、理想は達成できる。

　　9

例えばこんな課題については？グループ企業内事業統合をする

　①場所　　　　拠点の統合効果　

　②取引相手　与信管理の一元化

　③商品・部品　ＳＣＭ、集中購買によるコストカット

　④銀行口座　資金管理、内部統制の厳格化

　⑤各種コード　勘定科目の統一、仕事の標準化

グループ統合マスタの「あるべき姿」を定義

イベント、集計情報へ展開10

具体化すると？

①場所　　　　　場所を表すコードが統一されていない。　

②取引相手　　取引先、支店、法人、グループが

　　　　　　　　　　システムごとに持ち方が違う。

③商品・部品　　同じ商品、部品に複数のコード。

④銀行口座　　　口座番号を一元管理していない。

⑤各種コード　　勘定科目が不統一、意味が違う。

　　　　　　　　　　多重意味定義な区分が多い。

事業統合したいのだが。。。。

課題をデータ項目に具体化出来る。11

「業務忠実」ってレビュー出来るの？

マスタ

①範囲　なにをマスタにするか？

②粒度　１レコードが指示す範囲は適切か？

イベント

③完全　正しく事実を捉えているか？

④存在　その場面で発生して良いか？

集計データ

⑤適合　意思決定に資するか？

⑥正確　　偏向がない、再現性があるか？

【事業・データ生産モデルから導出されるデータ品質基準】

12

データモデルの一般構造

タイプリソース

オカレンスリソース

イベント

要約

在庫

断面

１：Nの関係

【椿のエンティティ類型（１９９７年）によるデータモデルの一般構造】

【記号の説明】

13

椿のエンティティ類型の功績

タイプリソース

オカレンスリソース

イベント

要約

在庫

断面

１：Nの関係

【記号の説明】

①データ発生順序を提示した

作業展開するにあたり上記順序で検討する14

タイプリソース

オカレンスリソース

イベント

要約

在庫

断面

１：Nの関係

【記号の説明】

椿のエンティティ類型の功績

②「タイプリソース」の発見

ビジネルルールを可視化した15

データ設計の実際（要件定義）

要件定義工程のポイント

現行分析は「必ず」行う。

データ設計を行う。

凝った業務フローは作らない。

「用語」の意味定義を行う。

16

要件定義工程　作業展開例

素材収集現行IPF

作成

現行部分図作成 現行

統合図作成新規IPF

作成

新規統合図作成

【再構築プロジェクトの例】

IPF:インフォメーション・プロセス・フロー（椿、２００５）

部分図：１つの業務画面、帳票のデータ構造を図示したもの。

統合図：システム化範囲すべてのデータ構造を図示したもの。

データ定義書作成

データ設計の実際（要件定義）

17

IPFの紹介（椿、２００５）

データ設計の実際（要件定義）

18

【証券取引の例】

「処理」を書かない。

用紙は横向きがお勧め。

データ設計の実際（要件定義）

よくある　「業務フロー」　は使えない

19

【よくある「業務フロー」】

受注 出荷 売上計上

電話注文

受注伝票

請求書

納品書

損益仕訳

受注 出荷 売上計上

【IPF】

無駄な分析をしなくていい。客観的で標準化可能。

データ設計の実際（要件定義）

データ設計はKJ法と同じ発想で行う。

業務入出力

（具体的な事実）

画面

帳票

20

モデル化

部分図A

モデル化

部分図B

統合図

統合

※KJ法とは川喜田二郎氏が提唱した知的生産方法。

川喜田二郎、「発想法」、中公文庫、１９６７

データ設計の実際（設計）

設計工程のポイント

「意味論的ドメイン設計」を行う。

データ構造に基づく部品化を行う。

21

データ設計の実際（設計）

「意味論的ドメイン設計」は意味がある。

22

【ドメイン設計の例】

区分：排他集合（分岐に使用）

分類：集約キー項目

コード：マスタのキー項目

シーケンス番号：イベントのキー項目

数値：演算の対象

文字列：属性

「１桁文字」、「９桁数値」（形式的ドメイン）は使い勝手が悪い

データ設計の実際（設計）

データ構造は情報システムの部品の集合。

部品化に適した構造をしている。

23

【株式約定照合データモデル例】 ※表記の説明

総括

データ設計は、情報システムがユーザにもたらす付加価値を最も左右する。

なので、情報システム開発において最も関心を置かなければならない。

要件定義工程では、要求事項の具体化と、実現可能性の両者を具現化する。

設計工程では、用語の意味とデータ構造に沿った部品化を行うことで、そこに示された要求事項を正確に設計することが可能になる。

24

「統合」と「総合」

要素技術を提供するベンダと、価値を実現するために要素技術を「統合」するユーザの構図はこの４０年間変化していない。

情報システムは「統合」によりユーザの業務に付加価値をもたらす。

要素技術を集めただけの状態、すなわち「総合」では、付加価値を提供したことにならない。

25

参考文献

• 堀内一、『データ中心システム設計』 、オーム社、１９８８

• 椿正明、『データ中心システムの概念データモデル』 、オーム社、１９９７ 

• 椿正明、『名人椿正明が教えるデータモデリングの“技“』、翔泳社、 ２００５

• 川喜田二郎、『発想法』、中公文庫、１９６７

• ルイス・ガースナー、『巨像も踊る』、日本経済新聞社、２００２

26

ご清聴ありがとうございました。

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

用目的で転載・複製を行う場合は、 予め弊社までご相談ください。

27