1. データ中心“再設計”
データ中心“再設計”
のススメ
インサイトテクノロジー
エンジニアリング本部
三原 健一

2. IT業界はつらいよ
IT業界はつらいよ

3. 運用はつらいよ
運用はつらいよ

4. うまくいって当たり前
何かあったら怒られる
早く何とかしろ！！
自分たちが作ったシステムじゃないのに。。。
自分たちが作ったシステムじゃないのに。。。

6. 開発はつらいよ
開発はつらいよ

7. 要件が
要件が決まらない
納期も厳しい
仕様の変更は当たり前
ドキュメントなんか直してられ
ドキュメントなんか直してられ
るか！

8. 納期は厳しい！！
要件定義
3M
設計 設計
カットオーバー
3M
コーディング コーディング
4M
テスト テスト
2M

9. ユーザはつらいよ
ユーザはつらいよ

10. 何でこんなにトラブルの？
こんなに使い勝手が悪い！
無駄になった時間どうしてく
れる！！

11. IT業界はつらいよ
IT業界はつらいよ
IT業界の3K問題
• きつい
• 厳しい
• 帰れない

12. インサイトテクノロジーは、
インサイトテクノロジーは、
「つらいこと」を
何とかする会社です。

13. 「何とかする」メニュー
「何とかする」メニュー
松コース
設計支援
竹コース
データベースの構築（RAC、
データベースの構築（RAC、D/G etc.）
etc.）
物理構成の変更
物理構成の変更
データ移行
梅コース
初期化パラメータの変更
インデックスの追加
インデックスの追加
SQL文の修正
SQL文の修正

14. 設計に問題があった例
設計に問題があった例

15. 帳票出力が遅くなった…
帳票出力が遅くなった…

16. SELECT
A.ITEM_CODE ITEM_CODE
, A.ITEM_DESCRIPTION ITEM_DESCRIPTION
, ………………………………
, B.PRICE_LIST_ID PRICE_LIST_ID
, B.SO_NUMBER SO_NUMBER
, B.PO_NUMBER PO_NUMBER
, A.SHORT_DATE SHORT_DATE
, (
SELECT
C. SCHEDULE_ARRIVAL_DATE
FROM
この部分をコメントアウト
C, D, E
WHERE C.HEADER_ID = E.HEADER_ID
⇒実行時間が半分に
AND C.LINE_ID
AND D.LOT_NUMBER
= D.ORDER_LINE_ID
= A.CASE_NUMBER
AND D.PICK_RELEASE_FLAG <> ‘Y’
AND ROWNUM = 1
) ETA
, A.INVENTORY_ITEM_ID INVENTORY_ITEM_ID
, A.ORGANIZATION_ID ORGANIZATION_ID
, A.SUBINVENTORY_CODE SUBINVENTORY_CODE

17. ALL-IN-
ALL-IN-ONE TABLE
タイプID 属性1 属性2 属性3 属性4 属性5 属性6 属性7 属性8 属性9 属性10 属性11
NUMBER(2) VARCHAR(100)
デスクトップPC 1 1 10/3 P001
1 2 10/4 P002
1 3 10/11 P003
ノートPC 2 4 10/5 P004
2 5 10/5 P005
2 6 10/6 P006
2 7 10/7 P007
液晶ディスプレイ 3 8 1
3 9 2
3 10 3
ACアダプタ 4 11 4
4 12 5
4 13 6
4 14 7
N/Wカード 5 15 4
5 16 5
5 17 6
5 18 7

18. データ構造はシンプル、でも…
データ構造はシンプル、でも…
CASE
WHEN :A = 1 THEN -- デスクトップPC
デスクトップPC
INSERT ハードウェア INTO (タイプID, 属性1, 属性2, 属性3)
タイプID, 属性1, 属性2, 属性3
VALUES (:A , :B , :C , :D );
プログラムは複雑
INSERT ハードウェア INTO
VALUES (3
(タイプID, 属性1, 属性6)
(タイプID, 属性1, 属性6)
, :E , :F); -- 液晶ディスプレイ
:F);
メンテナンス性が悪く
WHEN :A = 2 THEN
INSERT ハードウェア INTO
-- ノートPC
ノートPC
(タイプID, 属性1 属性4 属性5
(タイプID, 属性1, 属性4, 属性5)
VALUES (:A , :G , :H , :I );
バグの原因となる
INSERT ハードウェア INTO
VALUES (4
(タイプID, 属性1 属性7
(タイプID, 属性1, 属性7)
, :J , :K); -- ACアダプタ
:K); ACアダプタ
INSERT ハードウェア INTO (タイプID, 属性1 属性8
(タイプID, 属性1, 属性8)
VALUES (5 , :L , :M); -- ネットワークカード
ELSE NULL;
END CASE;

19. もっとちゃんと
“設計”をしよう！

20. ER図はありますか？
ER図はありますか？

21. 企業情報システムの現状

22. 販売管理システム
人事管理システム
全社システム？
資材調達管理システム
会計管理システム
生産管理システム

23. “つぎはぎ”だらけのシステム

24. Σ(部分最適)≒全体最適
部分最適)

25. なぜ、要件定義が難しいのか？
• 要件＝機能？
• 納期と優先順位
• 機能要求の変化
• 文書化
機能を中心に考えるからダメ

26. データを中心に考える

27. データ中心”再設計”とは？
データ中心”再設計”とは？
• 個別のシステムをいったん忘れる
• ビジネスを“メタ”にとらえる
• データモデル（ERD）を作成する
• できればモデリングツールを使う
• 開発期間にとらわれない
「こんな家に住みたい」のイメージ

28. インサイトテクノロジーのビジネスを
データモデルで表現してみる -Step1-
Step1-
リソース系エンティティ候補の洗い出し

29. インサイトテクノロジーのビジネスを
データモデルで表現してみる –Step2-
Step2-

30. インサイトテクノロジーのビジネスを
データモデルで表現してみる –Step3-
Step3-
Demo

31. データモデルは情報システム部と
外部組織等との共通言語となる
外部組織等との共通言語となる
ERP/クラウド
開発ベンダ セキュリティ担当 新規事業
コンサルタント
情報システム部
ハードウェア

32. 堅固なデータモデルとするために

33. データモデリングは
“お作法”が必要

34. リレーショナルデータベース理論“再考”
• One Fact In One Place
• Codd's 12 Rules (1985)
Rule 2: Guaranteed Access Rule
All data should be accessible without ambiguity.
This can be accomplished through a combination of
the table name, primary key, and column name.
ルール2: アクセス保証のルール
すべてのデータは曖昧さなしにアクセス可能でなけれ
ばならない。
これは、テーブル名、主キーおよびカラム名を組み合
わせることによって達成される。
Edgar Frank "Ted" Codd
1923.8.23 – 2003.4.18

35. 主キー（Primary-Key）
主キー（Primary-Key）
について考える

36. 何を主キーとすべきか？
何を主キーとすべきか？
社員
* 社員NO
社員ID VARCHAR2(15)
NUMBER(5,0) 社員No.
社員No.
社員氏名 VARCHAR2(30)
社員NO VARCHAR2(15)
入社年月日 DATE
社員氏名 VARCHAR2(30) 「F980012」⇒「199804012F」
F980012」 199804012F」
入社年月日 DATE
主キーから値の大小以外の意味を
できるだけ排除する
保有特技
保有特技 扶養家族
扶養家族
* * 社員ID ((F K) V A R CH A R 5,0)
社員N O F K) N U MB ER ( 2( 15) * 社員ID ( F K) FN U MB ER ( 5,0) 2( 15)
* 社員N O ( K) V A R CH A R
* * 連番
連番 NUMBER(2,0)
NUMBER(2,0) * 続柄
* 続柄 VARCHAR2(10)
VARCHAR2(10)
特技名
特技名 VARCHAR2(30)
VARCHAR2(30) 氏名 氏名 VARCHAR2(30)
VARCHAR2(30)
経験年数
経験年数 NUMBER(2,0)
NUMBER(2,0)

37. 何を主キーとすべきか？
何を主キーとすべきか？
社員
* 社員ID NUMBER(5,0)
社員NO VARCHAR2(15)
社員氏名 VARCHAR2(30)
入社年月日 DATE
主キーはなるべく単一列に定義し
複合キーとしない
保有特技 扶養家族
* 保有特技ID NUMBER(5,0) * 扶養家族ID NUMBER(5,0)
* 社員ID ( F K) N U MB E R ( 5,0) * 社員ID ( F K) N U MB E R ( 5,0)
* 連番 NUMBER(2,0) * 続柄 VARCHAR2(10)
特技名 VARCHAR2(30) 氏名 VARCHAR2(30)
経験年数 NUMBER(2,0)

38. これらは“お作法”の
ほんの一部です

39. インサイトが
何とかします
業務知識＋お作法
業務知識＋お作法
＝最強のデータモデル

40. 情報システム部門が
情報システム部門が
企業を変える！

41. ＣＩＯの3つの壁はこうして突破しろ！
き
http://diamond.jp/articles/-
http://diamond.jp/articles/-/14260
• 経営者の理解欠如
• コスト削減圧力
コスト削減圧力
• 人材育成
• ユーザ部門と一緒になって、ビジネスのあるべき姿
ユーザ部門と一緒になって、ビジネスのあるべき姿
を考え、実現するために最適な仕組みを作る
を考え、実現するために最適な仕組みを作る
木内 里美氏 • ビジネスを動かす可能性を秘めた、情報システム部
門の仕事は今、おもしろくて仕方がない。
門の仕事は今、おもしろくて仕方がない。

42. 独自のITの創造を目指す企業は、
独自のITの創造を目指す企業は、
成長・変革のためにITに積極的に投資する
成長・変革のためにITに積極的に投資する
企業を４つのカ
IT予算の増加率 IT予算の配分率
テゴリに分類
ガートナー EXP CIO サーベイ 2008
http://www.itmedia.co.jp/enterprise/articles/0807/04/news034.html

43. おわりに
~データ中心“再設計”はなぜ必要か~
データ中心“再設計”はなぜ必要か~
• ビジネスの本質はデータだ！（ヒト、モノ、カネ）
• 再設計とはビジネスの再定義である。
• データ構造をRDB理論で可視化したのがデータモデル
データ構造をRDB理論で可視化したのがデータモデル
• データモデルを見ると企業の真の全体像が見えてくる
• 経営層に効果的なIT投資をアピールする
経営層に効果的なIT投資をアピールする
• データモデルは情報システム部のデータベース担当者
（DBA）が作成するのが適任
DBA）が作成するのが適任
• DBAよDA（Data Architect） を目指そう！
DBAよDA

44. 完