□------------------------------------------------------------------□
□　Ａ社ＤＷＨ構築におけるデータベース設計
□------------------------------------------------------------------□

---------------------------------------------------------------------
（設問ア）
---------------------------------------------------------------------
1.Ａ社ＤＷＨ構築
---------------------------------------------------------------------
1.1.開発の背景
----
　Ａ社は東日本を中心に１００店舗を展開する中堅クラ
スのスーパーである。Ａ社においてはＰＯＳレジスター
の導入は比較的早い時期に完了していたが、その利用は
レジの省力化など業務効率化に止まっており、ＰＯＳ
データをマーチャンダイジング（品揃の計画）業務に活
かすまでには至っていなかった。これはデータ提供の仕
組みが、ホスト計算機によるオンライン画面や帳票によ
るものであった為であり、実際のデータ分析にはパソコ
ンへの再入力を余儀なくされていた事による。
　一方でＡ社は西日本への進出を計画しており、より戦
略的な品揃を実現する為に、単品管理の強化を目的とし
て、データウェアハウス（以下ＤＷＨ）の構築が企画さ
れた。
　私はＡ社ＤＷＨ構築に営業時点より参画しており、受
注後はＳＥとして開発に携わる事となった。
----
1.2.適用業務から見たＤＷＨ構築のポイント
----
　ＤＷＨは商談を行い商品を決定する『本社バイヤー』
及び、店舗での発注を行う『売り場主任』から利用され
る。いずれの利用者も業務は多忙を極めており、システ
ムのレスポンスは厳しく要求された。
　一方で、ＰＯＳデータをシステムに取り込むバッチ処
理においては、対象データ件数が７０万件程度である事、
及び夜間は９時間程度サービスを停止可能であった事か
ら、経験的に夜間バッチ処理には時間的余裕があると判
断する事ができた。
　以上から、オンライン（検索）のレスポンスを保証す
る事が、ＤＷＨ構築プロジェクトの成否を握っていると
判断し、この部分を中心にデータベース設計を進めて
いった。
---------------------------------------------------------------------
（設問イ）
---------------------------------------------------------------------
2.業務分析とデータベース設計の考慮点
---------------------------------------------------------------------
2.1.業務分析の結果
----
　ＤＷＨ構築に際し、その具体的な活用方法について、
適用業務、及び必要な画面・帳票の観点からヒヤリング
を行った。しかしながら、ヒヤリングの回数を重ねても
なかなか具体的な意見は上がらず、総じて『どの様に利
用するかは判らない』との意見であった。
　これは、それ迄のデータ提供がホストで実現され利便
性が充分で無かった事を鑑みると、情報リテラシーの醸
成が充分で無い事もやむを得ないと言わざるを得ない。
　その様な状況下において、やっと以下の活用イメージ
を導き出すに至った。
　a.本社での商談業務においては、商品の売れ筋・死筋
　　を判断する為に、全店舗の合計でかつ、週次単位の
　　比較的長い期間での検索を行う。
　b.店舗での発注業務においては、直近の販売実績を参
　　考にする為に、自店の情報でかつ、前日・前々日、
　　或いは前週同曜日の短期間での検索を行う。
　c.本社では、予算対実績の評価を行う為に、商品の単
　　品レベルでは無く、課・部門の組織単位での検索を
　　行う。
　以上のかなり大雑把なニーズからは、業務目的別に検
索機能を用意する事は不可能であると判断し、商品・期
間・店舗を自由に設定してデータを抽出できる『自由検
索』機能を用意する事で、Ａ社と合意に至った。
　また、ＤＷＨにおいてはレスポンス要件を定義する事
が重要であり、単にレスポンス時間のみを約束した場合、
想定した検索条件に齟齬があると、要求仕様を実現でき
ず、検収問題に発展する場合がある。特に、Ａ社ＤＷＨ
では自由検索機能の構築であり、その危険性が高く、
Ａ社とは慎重にレスポンス要件の定義を進めていった。
以下はその一例である。

　　本社でのデータ活用においては、ある部門の全商品
　（１００程度）・１００店舗合計・１３週（１シーズ
　ン）において、５秒〜１０秒程度のレスポンス時間と
　する。

----
2.2.データベース設計上の留意点
----
　ＰＯＳデータを正規化し取り扱う場合には、商品別・
店別・日別に管理する事となる。しかしながら、それで
は前述のレスポンス要件を満たす事は困難であると判断
された為、以下の導出データを用意する事とした。
　a.週次単位の集計データ
　b.全店の集計データ
　尚、組織単位での導出データの必要性も議論されたが、
組織変更が生じた場合に、過去に遡ってデータ内容を保
証する事が難しい為、以下の前提で導入は見送った。
　a.実データを使用したテストにおいて、レスポンスが
　　著しく悪い場合には、組織単位の導出データを用意
　　する。
　b.開発に際しては、Ａ社本番用機器を借用する。これ
　　により、早い時期にレスポンスの傾向を見極める。
---------------------------------------------------------------------
3.開発時の課題と対策
---------------------------------------------------------------------
3.1.実現されないレスポンス
----
　本番機および実データを使用し、開発・テストを進め
たところ、殆どの機能はレスポンス要件を満たす事が出
来たが、当初から危惧された通り、組織単位での検索が
極めてレスポンスが悪く使用に耐えない結果となった。
具体的には、１０秒のレスポンス要件に対して、１０分
もかかってしまうという状況であった。
　これについては、インデクスの付与やＳＱＬ文の見直
しにより、１分までには短縮する事が出来たが、最終的
に１０秒を実現するには至らず、Ａ社との約束通り、組
織単位の導出データを導入する事を決定した。
----
3.2.導出データ導入時の考慮点
----
　導出データを導入する場合のポイントは以下の２点に
ある。
　a.導出データを作成する為の、バッチ処理時間の増大。
　b.組織変更時における、過去データの保証
　組織単位の導出データを用意するプログラムの難易度
は低く数日で作成が完了し、かつ当時は既にテスト
フェーズにあり、その他のバッチ処理は全て完成してい
た事から、導出データ作成に必要な時間を実際に測定し、
その結果バッチ処理全体に与える影響は小さいと判断す
る事が出来た。
　一方の組織変更における過去データの保証については、
大幅な組織変更は２回／年である事から、臨時オペレー
ションを実施して頂く事、および必要なオペレーション
マニュアルを用意する事で合意が得られた。
---------------------------------------------------------------------
（設問ウ）
---------------------------------------------------------------------
4.データベース設計の評価と反省
---------------------------------------------------------------------
4.1.データベース設計の評価
----
　前述の様に、適用業務が具体的に提示されない状況下
において、レスポンス要件を定義し、それを満足する
デーベース設計を行った事は、私自身高く評価している。
　しかしながら、運用後１年を経過した頃、Ａ社からレ
スポンスが悪化しているとの問い合わせがあり、ここで
はその調査結果と反省について述べる。
　実際にＡ社にてレスポンス測定を行った結果、確かに
数秒から数十秒程度悪化しており、その原因は店舗の拡
大や取り扱い商品の増加に伴う、データベースの増加に
原因がある事が判った。
　データベース設計においては、当然余裕率を考慮して
いるが、その見通しが甘かったと言わざるを得ない。
----
4.2.データベース設計の反省
----
　データベースを設計する上で必要となるデータ件数に
ついてはＡ社からの提供を受けていたが、Ａ社の業容拡
大に伴う成長率の見通しについては、レビューを怠って
おり、ここに反省すべき点があったと考えている。
　またこれは、客先の業務分析・データベース設計を行
う、我々アプリケーションエンジニアの役割であると認
識している。