Slowly Changing Dimensions (SCD)について

Slowly Changing Dimensions (SCD)って何でしょうか。
実はこれデータウェアハウスで使用するディメンションデータの更新の対応方法のことなのです。
ディメンションとは、年や月、製品、住所などのデータを分析する上で必要になる切り口のことですが、
これは更新されることがあります。例えば、Aさんが引っ越して、住所が長野県から東京都にかわるなどです。
それをそのまま何も考えずに上書きすると大変なことになります。なぜなら、今まで長野県に住んでいるときに
行った過去の行動が東京でおこったことになるからです。
そのため、データウェアハウスの設計ではこの更新する方法論が確立されています。
基本はType0~Type4まであり、あとそのハイブリット型があります。

Type 0 SCD:
何もしない。値がかわっても無視です。

Type 1 SCD:
値が変化したときに、テーブルの値をそのまま上書き変更します。
これは、変更がビジネス上さほど重要でない場合に採用します。たとえば、顧客の名前など。。。
問題点としては、顧客の住所などを上書きすると、過去のデータを地域別でみた場合、
データが正しく分析できないことです。
また、注意としてサマリーデータなどを持っている場合は、データを再構築する必要があります。

Type 2 SCD:
値が変化したときに、新しいレコードを追加します。
また、各レコードにStart dateとEnd dateを入れておきます。
最新のデータはEnd dateに9999131などを入れておきます。
問題点としては変更が多いとたくさんのレコードが増えます。
また、この場合過去のサマリーテーブルは再構築する必要はありません。

Type 3 SCD:
あらかじめデータに現在の値とその前の値のフィールドを用意しておき、
変更があった場合に古いデータを以前のデータフィールドへ入れて、最新の現在のデータフィールドへ
格納します。
問題点は複数の変更に対応できません。保持できるのは一つ前のデータだけ。
でもこれは営業のテリトリー変更などで一つまえのテリトリーで現在の値をみたい場合などに威力を発揮します。

Type 4 SCD:
これはテーブルには最新の情報を保持し、古いデータは別途用意した履歴テーブルへ格納します。
問題点としてはシステムが複雑になります。

Hybrid SCDs
これ以外にそのハイブリット版として２つの方法があります。

Predictable changes with Multiple Version overlays
これは例えば、毎年営業のテリトリーが変更になり、分析要件として
情報すべてを指定した年のテリトリーで数値をみたい場合などに利用します。
方法としては、レコードの列にそれぞれの年のフィールドを用意しておきます。
例：District 2010, District 2009, District 2008.....
でもシステムがとっても複雑になるので、諸刃の剣です。

Unpredictable Changes with Singel version overlay
これは予測できない変更に対して、分析の切り口として現在の状態での切り口とそのデータが発生したときに
切り口でみたい場合にしようします。
これはレコードにCurrentとPreのフィールドを用意しておき、変更があった場合に
レコードを追加し、関連するCurrentの変更を行う方法です。
例をみるとこんな感じ。
key,name, current, pre
1,AAA,TOKYO,NAGANO
2,AAA,TOKYO,KANAGAWA
3,AAA,TOKYO,TOKYO
これは、Type 2 と Type 3と Type 1を合わせた感じなので、Type 6(2+3+1)と呼ばれています。。。

このタイプは各レコードの列ごとに適用ですので、設計時にどれにするか入念な検討が必要となります。
設計する上で非常に重要な概念です。

UPCsって何の略？

UPCsはUniversal Product Codesの略です。

SKUって何の略？

SKUsはStock Keeping Unitsの略です。

サロゲートキーって何だ？

Demensionテーブルとリンクするために使用される連番番号です。
ファクトテーブルとディメンションテーブルをリンクするときは、基幹システムなどで
使用されているコードでなく、連番のサロゲートキーを使用します。
理由としてはまさにデータベースが柔軟になるからです。
例えば、製品コードなど、一度使ったものが再度使い回されることがあります。
この場合、長い期間でみると違った製品が同じコードで管理されていることになります。
ただ、オペレーションのほうは短い期間で運用しているのでオペレーション上は問題ないわけです。
もう古い製品は売っていないわけですから。。。
でも、長い期間で分析するデータウェアハウスではこれでは困ります。
そこでサロゲートキーの登場です。
これを使うと、同じ製品コードでも製品が違うので違ったサロゲートキーがふられます。
そのため、データウェアハウス上はきちっと管理できるわけです。

Degenerate dimension(DD)って何だ？

Degenerate dimensionとはファクトテーブルにあるkeyでDimensionテーブルを持たないディメンションのことです。
通常、ファクトテーブルがトランザクションレベルで保持されている場合、その粒度を一意に特定するコードが
Degenerate dimensionとして使用されます。例えば、注文番号や請求書番号など。
この利用法ですが、後で基幹システムのデータベースとデータをつきあわせることができます。

Coverage Factless Fact Tableって何だ？

例えば、キャンペーンなどの販売促進活動を行ったとします。
当然、どのような結果になったか各商品の売り上げなどを分析したいと思います。
その場合、スタースキーマでデータが保存されていれば、
当然ファクトテーブルをもとに必要なディメンションで分析を行うことができます。
ただ、下記のような質問には答えることはできません。

このキャンペーンで売れなかった商品はなんだろうか？？？

なぜなら、通常ファクトテーブルは実際に売り上げがおこったデータが格納されているからだ。
では、キャンペーン中、売れなかった商品はどのようにすれば分析できるのだろうか。

その場合に使用するのが、Factless fact tableだ。
方法としては、まずFactless tableに１日ごとまたは１週間ごとにすべての対象商品のレコードを格納します。
ちなみにこのFactless tableはFact tableと同様にディメンジョンを持っています。
違うのは数値データが入っていないことです。そのため、ファクトがないので、Factlessになっています。

そして、キャンペーン中に売れなかった商品を探すのは以下の２ステップを行います。
ステップ１
まず、factless tableで対象日の対象商品を抽出します。

ステップ２
次にファクトテーブルを利用して対象日に売れた商品を抽出します。

ステップ１とステップ２で抽出したデータをつきあわせれば完成です。

ディメンショナルデザイン（Dimensional design）における４つのステップ

データウェアハウスの構築する上で必ず必要になるのがディメンショナルデザインです。
ディメンショナルデザインを行うは次の４つのステップに従って行う必要があります。

1.モデリングプロセスを選ぶ
>実際にモデリングするビジネスを特定します

2.ビジネスプロセスの粒度(Grain)を決める
>これはデータをどの詳細レベルまで持つことにするか決めます。
ただ、ハードウェアは安い今、これは一番細かいレベルまで持つのでセオリーです。

3.ファクトテーブルに使うディメンションを決める
>データをどのような切り口でみる必要があるかを決めます。

4.ファクトテーブルの数値項目を決める
>実際に分析する数字を決めます。例えば、売り上げとかコストなど。

また、上記ステップを行うにあたって、ビジネス要件と実際のデータをもとに考えます。

ビジネスインテリジェンスの要件定義のコツ

データウェアハウスの設計、そのデータにアクセスするインタフェースの設計において大事なのはなんといっても
ユーザの要件をどこまで把握して定義できるかにかかっています。
これがきちっとできないとスケジュール、コスト、品質もさだまりません。
とはいってもデータ分析については正直ユーザも手探りで行っている場合が多いのでしっかりした
要件を把握することは非常に難しくなります。

また、よくあるのが、すべてテストが終わってUATの段階であれこれ追加要件が出ることです。
同然、プロジェクトマネジメントのセオリーとして各フェーズごとにサインをもらっているので
システム屋として突っぱねることもできるのですが、やっぱりユーザが使わないシステムはまずいということになります。
とはいってもユーザは優先順位などはよく考えず、Nice to haveなのに要件をがんがんだしてきます。

じゃ、どこまで対応すればいいのでしょうか。
そこでたよりになるのが、２０対８０の法則。
そうこの法則はビジネスインテリジェンスの要件定義にも当てはまるのです。
２０対８０の法則とは全体の２０％の商品が売り上げなどの８０％を占めるという法則。
よく使う２０％を対応し残りは運用などでアドホック的に対応するといいと思います。
でもあくまでこれはデータにアクセスするインタフェースについての目安です。

データウェアハウスのデータは核になる部分ですので、これはしっかり考えて対応しましょう。

The O'Reilly School of Technology

コンピュータの本（動物が描かれているすてきな本）で有名なオライリーですが
The O'Reilly School of Technologyと称してコンピュータのオンラインコースが
あります。
現在私はそこのData Administration certificateコースを受講しています。
このコースは４つのコースからなっています。
１つのコースは４００ドル前後となります。
また、毎月１５ドルくらいの維持費を払えば、期限はありません。
コースは簡単にいうと以下のコースとなります。
１.データベースアドミニストレーション入門
>My SQLを利用してテーブルやSQLなどの基礎を学びます。

2. My SQL管理
>My SQLの管理

3.データウェアハウス
>データウェアハウスの基礎およびETLなど

4.データ分析
>主にMDXの習得

なかなか時間がなくてあまり進んでいませんが、
あらためて勉強を始めました。
復習もかねてはじめから勉強しています。

ブラウザだけあれば、すべてそこからソフトウェアにアクセスできるので
特別なソフトウェアは必要ありません。

このサイトでも勉強したことのエッセンスを紹介していきたいと思います。

The O'Reilly School of Technology

データウェアハウスとはいかにあるべきか論

ラルフ・キンボールの「The Data Warehouse Toolkit」という本に
Goals of a Data warehouseと称してデータウェアハウスとはいかにあるべきかが
述べらています。
すばり要点が述べられており、ちまたのデータベース技術者にぜひとも読んでもらいたい
ものなので、要点を記載したいと思います。

・データウェアハウスは組織の情報を簡単にアクセスさせること。
ユーザの立場から言えば、まさにその通りと納得でしょう。システム屋からいうと
そう簡単にいうなよって感じでしょうか。
ただ、ちまたにはパフォーマンスが悪くてユーザがアクセスしにくいシステムが
あふれています。データ量が多くてパフォーマンスが悪いのはわかりますが
きちんとデザインしてきちっと分析すればそれは実現できますよね。
私も含めて皆さんがんばりましょう。

・データウェアハウスは組織の情報を首尾一貫して表現すること。
これはいわゆるデータの品質のことです。
担当者がかわるなどで通常企業のデータの定義がかわってしまったりします。
数年立つとデータはぐちゃぐちゃってことはよくあります。
で最初からデータのクレンジングをやり直し。。。
品質が保たれていないとよけいな運用時間もとられますよね。。。

・データウェアハウスは変更に柔軟に対応できること。
会社の戦略は環境によって日々かわるし、扱うデータ、分析するデータも
日々かわります。
変化に対応できることは生存競争において必須条件です。
これもあたり前ですが、なかなか難しい。。。

・データウェアハウスはセキュアであれ。
これは当然。データにアクセスすべき人しかアクセスできないこと。
これは会社の死活問題です。

・データウェアハウスはよりよい意思決定の土台でして機能すること。
そうそう、データウェアハウスは意思決定を助けますね。

・データウェアハウスの成功とはビジネス側が使ってなんぼ。
これはそのとおり。いくら、予定どおりにプロジェクトを終わらせたって
使われないとしょうがない。
近くにいませんか。俺はプロジェクトマネジメント力があっていくつもの
プロジェクトを完了したって言って出世していく人。
でもそのシステムは結局あまり使われず運用チームがなんとか直すか
だましだまし使ってもらうか、ユーザが生データをひっこ抜いて、Accessか
なんかで実は分析していたりします。

これは耳が痛いですね。システム屋として。。。
でもその通り、これを目指しましょう。

YTD,3MMAって何だ？

仕事において、YTDと3MMAのデータが欲しいって言われました。
これって何かわかりますか？

YTDはすぐわかりました。これはYear To Dateの略ですね。
分析ではよく使われます。定義としては、その年の１月１日から現在までの合計ですね。
では、3MMAって何でしょうか。
これは3 Month Moving Averageの略のようです。日本に訳すと３ヶ月移動平均。
つまり、直近３ヶ月の平均になります。今が、三月だったら、１月から３月までの値を
足して三で割るとその値になります。なあーんだ、聞くと簡単ですね。
あと6MMAとか12MMAとかよく目にしますがこれも考えた方は同じです。
略称って難しいですよね。

ちなみにデータベースエンジニアはデータ分析の知識とスキルも必要に
なると思います。これがわからないとユーザとお話できないですからね。
また、社内の情報システム部はちょっとコンサル的な仕事も求められています。
例えば、業務分析してその改善点を提案するとか、またレポートの提案とか。
そう考えるとデータ分析のスキルはかなりのレベル必要ですよね。
システムエンジニアって大変！！！

がんばって勉強しようっと。

ビル・インモンかラルフ・キンボールかそれが問題だ！

データウェアハウスといえば、いわゆるオペレーションで使用される基幹システムとは
別に情報系のシステムとして情報をためるデータベースのことです。
データウェアハウスは基幹システムとは違って大量にデータを保存する必要が
あります。また、そこからデータを引っこ抜いて分析するのでパフォーマンスも
大事ですし、企業全体の数字をすべてみる必要があれば、やっぱりマスターなどは
きれいに整理しまとめる必要があります。
そのようなシステムだけにやはり作りなども基幹システムとは非常に異なってきます。
それには基幹システムでは学ばないテクニックとスキルが必要とされるのです。

そこで、早速スキルの学習となるのですが、やっぱりシステムエンジニアたるもの
まず必要なのは独学です。
そこで一番たよりになるので、書籍です。
インターネットの情報源も役に立ちますがそうはいっても体系的にまず
学ぶには書籍が最適だと思います。
私も自分書籍を買い込みました。また、コンピュータの本は非常に高いため
かなり出費しましたがそこは投資と割り切りました。
皆さんも本をたくさん買って読みましょう。

そこでまず書籍選びですが、定番ものから読みましょう。
じゃ、データウェアハウスの定番って何でしょうか。
実はデータウェアハウス業界は２つの派閥に分かれているのです。（本当か？）
その派閥とはデータウェアハウスの父と言われるビル・インモンと
ディメンショナル・データベースのラルフ・キンボールです。
その違いですが、まず、ビル・インモンは企業には１つの大きなデータウェアハウスが
あってそこから必要なデータをもとにそれぞれ必要なデータマートを作成する考えです。
また、大きなデータウェアハウスはいわゆるリレーショナルデータベースの第３正規形と
なります。
一方、ラルフ・キンボールですが、キンボールはデータウェアハウスを
データマートの寄せ集めと考えています。また、データマートはすべて
ディメンショナルデータベースとなります。ディメンショナルデータベースとは
一般的にスター型と言われるデータ構造でデータを素早く抽出するのに適しています。

じゃ、どっちにすればいいのでしょうか。私は断然ラルフ・キンボールの考えを
おすすめします。なんと言っても各ベンダーが出しているツールはキンボールの
考えにのっとって考えれているからです。
ということでまずはキンボール本から読みましょう。
実は言うとキンボールおよびキンボールの会社キンボールグループは非常に
多くの書籍を書いています。残念ながら日本語に翻訳されているのは本の
一部です。誰か翻訳してくらないかな。
っていうか、私が翻訳してもいいくらいなので、出版社のかた待っています。

ということで英語になってしまいますが、まずキンボールの本を全部読みましょう。
ちなみに私は全部買いましたがまだ読み終わっていません。
まずは「The Data Warehouse Toolkit: The complete Guide to Dimensional Modeling」から読みましょう。
私も今読み直しているところですので、このブログでいくつかエッセンスを紹介
して行きたいと思います。

スーパーデータエンジニアへの道

現在、世の中は不況のまっただ中です。

また、不況に関わらず中国などとは違って日本のような成熟社会では

ものはなかなか売れない状況です。

そんな状況の中、各企業は優れた戦略を立案し、実行していく必要があります。

優れた戦略を立案し、実行して行くにはまさに洗練された情報に基づいて

計画実行して行く必要があります。

そこで必要になるのが、企業の情報力、分析力です。

またそれをさされるのが情報技術です。

ただ、個人的な意見ですが日本の分析、情報テクノロジーは欧米に比べると

劣っていると言わざるを得ません。

それはデータベースやビジネスインテリジェンスなどの製品をみても明らかです。

利用率が高いものはすべて欧米のものです。

また、それらを支えるデータデザイン力、モデリングなどのスキルも非常の劣っています。

また、日本のシステムエンジニアの技術力は私も含めてまだまだなのではないでしょうか。

特にBIなどのスキル全滅と言っても過言ではないと思います。

このままではまずいと思い、このブログを開始しました。

このブログではスーパーデータエンジニアへの道と題して、データベース、

データウェアハウス、データ分析などのデータに関わるスキル、技術について学習したこと、

考えたことなどを日々書き込んでいきたいと思います。

このブログは自分の成長の記録および自分が後で参照する貴重な情報源になればと思います。

また、願わくはこのサイトが少しでも日本の技術の向上に役立てばと思います。

余談ですが、このブログのタイトルは私の好きなG.M.ワインバーグの

「スーパーエンジニアへの道」をもじって作成しています。

スーパーエンジニアへの道は名著であり、システムエンジニアにとっては

必読の書だと思いますが私はこの本のリアリティが非常に好きです。

普通の書籍は正直言うときれいごとばかりで自分の考えを整理するうえでは

役に立ちますが、いいことしかかいてないなあというきがします。

その点、スーパーエンジニアへの道はまさに実務で出会うリアリティが

書かれており非常に参考になります。

このブログのそのような内容にちょっとでも近づけられればと思います。