The Data Warehouse Toolkit: 12 章
久野靖∗

2004.6.8

1• open-ended な fact 集合→さまざまな計測を記録

Education• 「何か」が起きるごとにその「もの」の行を書き換え□ 教育機関を考える• 書き換え→ FK や計測値の変更□ 受験生パイプライン→累積スナップショットとして扱う□ 受験生の入試プロセスを累積スナップショットで扱う• 5 章でも累積スナップショットは扱ったが…

• 他の業界でも求職者とか売り込み相手とか類似• ここでは受験生がマイルストンを通過してく様子をモニタ□ 受験生の追跡の場合、多数のマイルストンを順次通過していく□ factless fact table の使用例

• どの段階で何人いるといった情報が必要

2• 漏斗のように先にいくほど候補者が絞られていく

University Case Study□ 粒度→ 1 人の応募者について 1 行。先に進むほど行に多□ 大学その他の教育機関に勤めているものとしよう (実際

くの情報が記入されていく。(図 12.1)

勤めているけど…)□ 1 つ の 行 に 複 数 の 日 付 を 記 入 → role playing• これからは大学も投資/回収をきっちり考えないと…
dimension(耳が痛い)□ 応募者 dimension →多くの興味深い属性• 増大するコスト、他大学との競争に耐えて「高品質• 地域、成績情報、出身校など→分析対象→次の段にの学生」を誘引し確保しないといけないのだ!!!
進む学生を絞る• 卒業したら終わりではない• お客様 (学生さん) はどのような商品 (科目) を購入 □ 短い間存在する「もの」の追跡→累積スナップショットが適するしているだろうか…
• 高いコストの掛かっている教員を目一杯活用する!!!

• 最新の情報が参照できる(恐ろしい…)

3• 「予想合格率」なんかも?→翌年の学生層の予測が可能

Accumulating Snapshot for Ad4
missions Tracking

Factless Fact Tables□ 5 章では注文完遂に至る累積スナップショットを扱った。 □ これまでのところ fact table の構造はどれも類似
また特定生産品を累積スナップショットで追跡すること• 3〜15 くらいの FK カラムも扱った。累積スナップショットの特性は:• 1〜数十くらいの数値データ (できれば additive)• 1 つの行が「あるもの」の完全な履歴を表す• → dimension key 値 (群) に係わる計測値を保持していると考えられる• 比較的存在期間の短い「もの」に適する• マイルストンに対応して複数の日付が記録される□ ここで、もっと別種の fact table を提示→「数値がない!」→ factless fact table∗ 筑波大学大学院経営システム科学専攻1• ここではイベント追跡用とカバレッジ用のものの例• TERM KEY の個数を数えても「学生が何人」が分かる
ところがちょっとヘンに思えるけどこれが SQL とい• これまでにも 2 章と 5 章でカバレッジ型のものは出て来た

4.1

うもの• 本 当 に「 学 期 が い く つ 」を 問 い た け れ ば COUNTDISTINCT を使う

Student Registration Events□ とはいえ、分かりにくいので「常に 1 という値を持つ」「登録数」とかいうフィールドを作るといいかも (「ダミー」はよくない)□ 複数のディメンション群の「遭遇」イベントを記録することはよくある• たとえば各学期における学生の科目登録

SELECT FACULTY, SUM(REGISTRATION_COUNT) ... GROUP BY FACULTY• fact table の 1 行→「あるコースに、ある学期に、ある学生が登録」(図 12.2)• こうなると厳密には factless ではないようだが、「常に 1」なんだから実質 factless• 集計したサマリーテーブルを作るなら「登録数」は□ fact data は学期レベル (日付レベルでなく)そこでは意味のあるデータになる• だが日付次元に適合している必要はある• つまり日付はその日が属する学期 (2002 年度秋学 □ 設計していくうちに、実際に意味のあるデータが現れることもある (ただし学期単位という grain に適合してい期)、年度 (2002 年度)、学期の季節 (秋学期) などること!)の属性を持つ必要、ラベル等も適合• た と え ば 授 業 料 収 入 、履 修 時 間 、成 績 → 当 然
factless ではなくなる□ 学生次元は先の応募者次元の拡張版• 受験時の情報はすべて残す• 加えて入学後の情報→ 1 部/2 部、居住地、運動、専

4.2

攻、学年等

Facilities Utilization Coverage• 6 章で述べたのと同様、いくつかのものはミニ次元 □ factless fact table の 2 番目のタイプ→カバレジ表化←変化していく□ 例:大学では施設に多くのコストが掛かっている→どの施設がどれくらい働いているか検討したい□ fact table はこれら次元間の多対多の関係をうまく表現する手段• 例:最も多く活用されている (ふさがっている) 施設はどれか?

• 時空間内でこれらの次元の「接点」を記録• 例:各時間帯ごとに、最も多く使われている施設はどれか?

□ 多数の興味深い問い合わせに応えられる• 例:どの学生がどのコースに登録?

• 例:金曜日には使用率が下がるか?
は授業出たくない)• 例: 工学専攻学生の何人が専攻外のファイナンスコースに登録?

□ これらのデータのためにも factless fact table が活• 例: 過去 3 年にある教官の科目に登録した学生は何人?
• 例:(誰も金曜日に用できる• 各施設、各時間帯 (時限) ごとに 1 行ずつを (施設のその教官の科目を 2 つ以上取っているのは何人?

利用有無に関わらず) 入れる→図 12.3

□ fact には数値はないから、データは「個数」というこ□ 施設次元はその施設の記述を全部入れる。建物、施設種とに別、広さ、定員、アメニティ□ SQL で factless fact table から個数を検索する→非対称なクェリー□ 利用次元は「利用可能」「使用中」SELECT FACULTY, COUNT(TERM_KEY) ... GROUP BY FACULTY

2• 複数の組織が関わって来る場合も

4.3• 「ない」データを用意する必要がないのでよさそう
だが欠点もStudent Attendance Events□ 学生のコースへの出席も同様のスキーマで表現可能→図• NOT EXIST を入れ子クェリとしてきっちり区切って12.4呼ぶ必要がある• この場合は各学生×科目×各開講日ということに (学□ 例:期 vs 日の違い)…

• 科目登録 fact と共通する次元が多数ある□ クェリーの例:

宣伝したけど売れなかった製品を知りたいとすると• まず当該期間において売れたすべての製品を列挙し、「もっとも出席が多かったコースは?」その範囲内で NOT EXIST をサブクェリーとして使用「学期全体を通じて最も出席が少かったコースは?」「どするの教官が最も多くの学生を教えたか?」• 弱点: 「まったく売れなかった」商品をカバーし損
なう

4.4

Explicit Rows for What Didn’t Happen

遅い (複雑なクェリだから)• 弱点:

データアクセスツールによっては対応していないかも□ 「コースに登録したけど出席しなかった」も知りたいこ□ 図 12.5 の テ ー ブ ル に つ い て 、San Antonio Main
Outlet に お い て 、2002.1 月 に 販 売 さ れ た が 、
2002.1.15 の ActivePromotion で 宣 伝 し た の に売れなかった商品を取り出す SQLとがら• 「欠席」イベントを登録することも考えられる• 「欠席」は「出席」と同じ次元群を持つからこれが可能

SELECT P1.PRODUCT_DESCRIPTIONFROM SALES_FACT F1, PRODUCT P1, STORE S1,DATE D1, PROMOTION R1
WHERE F1.PROD_KEY = P1.PROD_KEY
AND F1.STORE_KEY = S1.STORE_KEY
AND F1.DATE_KEY = D1.DATE_KEY
AND F1.PROMO_KEY = R1.PROMO_KEY
AND S1.STORE_LOCATION = ’San Anto...’AND D1.MONTH = ’January, 2002’
AND NOT EXISTS(SELECT R2.PROMO_KEY
FROM SALES_FACT F2, PROMOTION R2, DATE D2
WHERE F2.PROMO_KEY = R2.PROMO_KEY
AND F2.PROD_KEY = F1.PROD_KEY
AND F2.STORE_KEY = F1.STORE_KEY
AND F2.DATE_KEY = D2.DATE_KEY
AND R2.PROMOTION_TYPE = ’ActivePromotion’
AND D2.FULL_DATE = ’January 15, 2002’)• 表が大きくなりすぎることもない• 「出席」fact → 0 または 1 →これを入れるた fact
table は factless でなくなる□ 一般の場合は「不在」を fact に入れるのはまずいことが多い

4.5

• 弱点:

Other Relational Options for What
Didn’t Happen□ 多くのケースではトランザクションは「疎」となる• たとえば、それぞれの日においてすべての商品のうち売れるのはごく一部• このため、「売れなかった」トランザクションを入れると表が大きくなりすぎる

4.6

Multidimensional Handling of What
Didn’t Happen• 2 章の「宣伝カバレジ fact table」のような方法で「宣伝したが売れなかったもの」を分析可能←宣伝さ □ OLAP ツールであれば「ないもの」をうまく扱ってくれるれた品文句に限定されるため• データキューブ構築時に「疎な」データに対処→「0」• このような特定テーブルでは (宣伝が週単位であれが多数でも OKば) 粒度を日でなく週にするなどの方法も可能• fact が疎すぎなければ「ある」「ない」をともに扱• 売れた製品については売れたデータから取って来てえる→関係データベースだけでやるより楽に突き合わせ可能□ もう 1 つの方法として、SQL の「NOT EXIST」機能を使うことも3

5

Other Areas of Analytic Interest□ 閑話休題。(tangentってそういう意味だったの?)□ 高等教育機関の話に戻ると…

• 前章までで扱った購買、HRM などはすべて大学でも役に立つ• 収入側はほかに研究資金、同窓生の寄付なども□ 研究資金の分析は 7 章の財務分析と似ているがより細かく見ると subledger(その部分についてのみの元帳?) のようなもの• 粒度としては資金に関するものを追加 (企業提供/政府資金、研究対象、期間、研究者)• 研究プロジェクトごとにその予算と執行を把握した
いというニーズ• 経費を最小化し、資金を有効活用• 多くの次元ごとに累計し分析→適切な運営かどうかチェック□ 同窓生の寄付は CRM によく似ている• 同窓生の情報→所在、職、興味、その他の情報 + 生
徒として在籍時の情報• これらの情報を活用→同窓生をよりうまく活用□ 寄付だけでなく、職の斡旋、仕事発注、共同研究などでも活用• フルスケールの CRM システムによってすべての接点を記録することも

6

Summary□ accumlating snapshot• トランザクションや定期スナップショットに比べて使われることが少いが…
• 比較的短期間で終わるプロセスでマイルストンが標準化されているものに適用すると好都合□ faltless fact table• 複数次元間の「関連」を捕捉• 「起きなかったこと」を扱うための工夫

4