The Data Warehouse Toolkit: 8 章
久野靖∗

2004.6.8

1HumanResourcement(HRM)• 社員トランザクションをトランザクション単位の粒度で記録する fact table。1 行 1 トランザクション。

Manage-factless (数値データはなし)□ HR 情報→ 7 章の会計/財務情報同様、組織内に遍在• 付随するデータ→社員プロフィールへの変更内容。

• 一方、HR 情報の技術に強いアナリストがいるわけで□ 次元→トランザクションの日付/時刻、種別、社員。

はあまりない• 種別次元→変更の種別によってさまざまなデータを保持• 今日の競合的環境→社員の特性を把握し活かすことは重要

2• 社員次元→多数の属性を持つ幅の広いテーブル。社
員 ID はここに保持Time-Stamped
Transaction □ 社員情報の変化は社員次元を TYPE2SCD として扱うとしようTracking in a Dimension• トランザクションごとに社員次元に新しい TYPE2 の行を追加□ ここまでに例示した次元モデルは互いに類似• fact table に KPM(key performance metrics)□ …とすると、社員次元とファクトテーブルの行数が同じが含まれ縦横に足せるに?そりゃヘン• 次元モデラ→加法性に安住しがち。普通はそれでい□ そこで社員次元を強化してファクトテーブルはなくす→
いが HR データは足せない。数値ですらない。でも絶図 8.2
えず変化している• トランザクション種別等もここに含まれる□ 100,000 社員の大企業の人事部にいるものとしよう• 数値データはない (あったとしても単に前のものを• 各社員には 100 以上の項目を持つプロフィールが付属。雇用日、職位、給与、考課日、考課内容、休暇置き換え)• c.f.

状況、部署、教育、住所、保険プラン、その他。

サマリーが取れるような (足せるような) ものであればファクトテーブルにする必要• このデータに関する変更トランザクションの流れ→□ 社員トランザクションキー (代理キー) が主キー
雇用、移動、昇進、…

• 社員 ID+トランザクションコード+日付を組み合わせ□ これらの事象を正確に追跡し分析したい。トランザクたスマートキーを作るのはよくない。これらはいずションヒストリにはすべての情報が含まれている。

れもカラムデータ• 複雑な (予想もできない) 問い合わせもあるかも知れないが、答えは必ずここから得られる。

□ 重要なのは 2 番目の日付/時刻である「終了日時」:「次の」トランザクションの日時□ 図 8.2 のスキーマ。

• つまり 2 つの日時の「間」(1 秒〜数か月) がこのプロフィールの有効範囲• 現在有効のプロフィールでは終了日時は未来の適当な日時。null はクエリーがしにくくなるのでよくない。

∗ 筑波大学大学院経営システム科学専攻1□ 最終更新フラグ→現在有効なものをすぐ取れるために• すべての断面において調べたい→当該範囲にトランザクションがなくても使用• 更新があったら新しい行を追加し、これまでのはフ □ HR 定期スナップショット fact table(図 8.3) を用意。
ラグを降ろす• 月次元は普通に月をあらわす。社員トランザクショ□ この方法で大企業でもディスク量は大したことはない
ンキーはその月の最後のトランザクションをあらわす。組織次元は企業の各組織をあらわす。
• 100,000 人× 10 変更/年× 2,000 バイト/行× 5 年=10GB□ fact はその月ぶんの数値サマリーで、トランザクションから直接計算するのが難しいもの。マネージャからの□ このトランザクション次元だけで多くの情報が取り出せる検索要求を満たす。

• 特定社員に関する全経歴• すべての値は (balance を除いて) すべての次元に対して加算可能。balance は準加算可能、他の次元に• 過去の特定時点における全社員のプロフィールついて足した後、時間平均を取る必要がある。

• 取り出すだけでスナップショットになっているのは便利□ ☆トランザクションに開始/終了日を付加することで、 3

TYPE2SCD は過去時点の正確な断面を提供可能になる

Audit Dimension□ fact table は「真だと分かっているすべてのこと」を□ トランザクション次元の詳細についてきちんと考える記録。この延長として、メタデータのキー情報を入れて必要おくことも考える• HR 運用システムは細かいデータを保持していて、全• fact を供給したソースシステム

部データウェアハウスに取り込みたくはないかも• 行を挿入したソフトウェア/バージョン• たとえば「昇進」多数の個別変更 (マイクロトラン• 行挿入時の allocation logic のバージョンザクション) の累積として記録されているかも→我々• Not Applicable の詳細…未知、不可能、破損、未は 1 つの「昇進」として扱いたい

到着• このような「複合トランザクション」をうまく取得するのは簡単ではないかも。HR 運用システム側が対• その fact が最初の投入後変更されたか、されたのならなぜか応する情報を持っているのがベストだが。

• 値が標準偏差の 2(3、4) 倍以上外れているか

2.1

Time-Stamped Dimension with Peri- □ 前半 3 つはデータの起源、後半 3 つはデータの信頼性にかかわる
odic Snapshot Facts• このようなデータを入れるには図 8.4 のように audit□ 社員トランザクション次元はタイムスタンプ付きなの次元を作りそのキーを入れる

である種の fact table なんじゃないかと思うかも知れ• これによりメタデータが普通のデータ同様分析可能になるない。

• 技術的にはそうかも知れないが、実際にはその内容はテキスト文字列が中心で、クェリー条件や出力ラ □ audit 次 元 の 内 容 は テ キ ス ト。「Employee extract
ベルとして参照→次元テーブルと考えるのがよい
versin 5 using ETL vendor ABC release 6.4」
「Altered」「Not Altered」など• 社員次元を必要とするようなすべての fact tableと組み合わせて使うこともできるし (社員代理キー• ELT(extract-transoformation-load) プロセスでの代わりに社員トランザクション代理キーを使う)

これらの内容を調整して投入。トランザクションが多ければほとんどは同じ値のはず。

□ 毎月のサマリーのようなものを作るのにも使いたい→社
員数、給与総額、休暇取得/残余日数、新入社員数、昇進数、など

24Keyword Outirigger Dimension 4.2 Searching for Substrings□ たとえば、IT 部門が社員次元に「IT スキル情報」を追 □ 図 8.6 のように単純な形にして and/or を避けることもできる加したいと考えたとする。

• スキル記述は 1 つの長い文字列にして決まった区切• 1 人の社員が非常にさまざまな IT スキルを持つこと

り文字で区切る (例:があり得る。

/UNIX/C++/)• ただし多数の社員が同じ行を共有する場合。そうで• スキル自体もさまざまだが、ある程度構造はありそう。プログラミング言語 (Cobol、C++、Pascal)、ないなら文字列を各社員ごとに入れてしまう。

• 文字列探索は曖昧だったりして難しい。UNIX? Unix?
unix? (たとえば大文字に統一したりケース無視探OS(Unix、Windows、Linux)、DBMS、…
• スキルを指定して誰がそのスキルを持つか調べたり索を使ったり…)

もしたい□ AND/OR 問題は次のように解決できる (%は多くの SQL で「任意文字列にマッチ」機能)□ 各社員が可変個のスキルを持つ→スキルは多値次元の候補

SKILL_LIST LIKE ’%/UNIX/%’ OR
SKILL_LIST LIKE ’%/LINUX/%’• キーワードは本質的に open ended…絶えず新しいものが追加

SKILL_LIST LIKE ’%/UNIX/%’ AND
SKILL_LIST LIKE ’%/LINUX/%’• 図 8.5 →スキルを outrigger として設計。場合によっては fact table に混ぜることもあるが (13 章 □ 標準 SQL の機能なのでどこでも動くという利点参照)□ ただし「%」が先頭にある探索はのろいという問題□ Skill Group はある集合 (例:Oracle+Unix+SQL) に対• Skill List outrigger をメモリ常駐させると速くして 1 つ。この 3 つをスキルとして持つ社員は同じできる

Skill Group Key を持つ。

• DBMS によっては特別なパターンインデックスを構築可能かも• スキルごとのデータが多くなれば分けるがここでは2 つしかないので混ぜてある

54.1

AND/OR Dilemma□ 人事部はしばしば社員に対してサーベイを実施 (ピアレビュー、マネージャによる考課などでとくに)。

□ 図 8.5 のスキーマでの問題点• OR クェリー (例:Survey Questionnaire Data

• これらのデータを分析したい (各社員の平均点数、部Oracle または Linux のスキルを署の平均点数など)持つ社員) は簡単• AND クェリー (例: 〃かつ〃) は outrigger で 2 つ □ このためには 1 つの質問ごとに 1 行を持つ fact tableの行の分かれるので難しいを作成 (図 8.7)
• 解決策: SQL で union/intersection を使ったクェリーを用意してユーザからは隠す• 社員次元は「評価社員」「被評価社員」の 2 つの役割次元(SELECT EMPLOYEE_ID, EMPLOYEE_NAME
FROM EMPLOYEE, SKILLSWHERE EMPLOYEE.SKILLGROUP = SKILLS.SKILLGROUP
AND SKILL = "UNIX")UNION / INTERSECTION(SELECT EMPLOYEE_ID, EMPLOYEE_NAME
FROM EMPLOYEE, SKILLSWHERE EMPLOYEE.SKILLGROUP = SKILLS.SKILLGROUP
AND SKILL = "LINUX")• サーベイ次元はどういうサーベイかを記録• 質問次元は質問内容とその分類カテゴリを記録 (たぶん同じ質問が複数のサーベイで用いられるし)• サーベイ次元や質問次元を探索することで「こういう事項の評価」という形で探せる• 応答次元は応答内容とカテゴリ (よい、悪い)□ 図 8.7 のような単純なスキーマでも多くの分析が可能。
さまざまなサーベイに応用可能。

36Summary□ HR データの文脈でいくつかの概念を検討□ 次元テーブルをうまく修飾することで主要情報を格納するだけでなくトランザクションを追跡することまで可能• HR データの場合、これだけで多数のクェリーに対応可能□ audit dimension でデータの由来やメタデータ情報の格納□ キーワードグループの導入→ outrigger または文字列のリスト□ サーベイ/アンケートデータの取り扱い

4