今回から２回にわたってOLAPに関するトピックについて解説します。今回は、MOLAPとROLAPについて解説したいと思います。
OLAPとは？
MOLAPとOLAPを説明する前にそもそもOLAPって何でしょうか。Online Analytical Processingの略ですって言われてもよくわかりません。OLAPとはキューブとも呼ばれます。じゃ、キューブって何でしょうか。
キューブとはスタースキーマを多次元データベースで実装した場合の名前になります。リレーショナルデータベースで実装したものはスタースキーマと呼ばれ、多次元データベースでスタースキーマを実装さればキューブと呼ばれます。
スタースキーマとは、復習になりますが、データベース上で分析しやすいようにした設計されたデータモデリングのことで、真ん中に分析するファクトをおいて、その周りに分析する切り口であるディメンションを配置したモデリングとなります。
例えば、売り上げ分析であれば、売り上げをファクトとしてその周りに製品や顧客などのディメンションを配置して製品別や顧客別などに売り上げを分析できます。モデリングのかたちがスターに似ていることからスタースキーマと呼ばれています。
ROLAPとMOLAPの違い
さてMOLAPとROLAPの違いですが、MOLAPはMultiple OLAPの略で、多次元データベースにデータをあらかじめて保存しておく方法です。BIなどのアプリケーションでデータにアクセスする際は多次元データベースにアクセスします。多次元データベースではデータが最適化されていますので非常に高速アクセスできます。
一方、ROLAPとはRelational OLAPの略で、キューブの定義だけをしておいて、アプリケーションがデータにアクセスするたびにオラクルなどのリレーショナルデータベースにアクセスのたびにデータを取得しに行きます。
当然、リレーショナルデータベースは複雑なクエリになるとパフォーマンスが落ちるのでレスポンスが悪くなります。
それぞれの利用方法
では、ROLAPのメリットってなんでしょうか。それは、MOLAPはリレーショナルデータベースが変更されるたびに多次元データベースにその都度データを読み直さないと行けません。その点、ROLAPは都度データをリレーショナルデータベースに読みにいくので再読みの必要はありません。リレーショナルデータベースがテラデータやネティーザなどであれば高速なのでROLAPなどが利用されます。
OLAP製品によってMOLAPやROLAPであったりするのでアーキテクチャに合わせて製品を選びましょう。ちなみにMicrosoftのSQL Sever Analysis Servicesでは設定でMOLAPやROLAPのどちらかが設定できます。
また、定型レポートなどは夜間バッチで作成できるためROLAPが利用され、仮説思考によるピボット分析ではMOLAPなどが利用されたりします。
今回は、ROLAPとMOLAPの違いについて説明しました。次回は、OLAPにアクセスするクエリ言語、MDXについて説明します。
2011年5月31日火曜日
第13回：ETLチェンジデータキャプチャ
今回は、ETLの機能して重要なチェンジデータキャプチャ(Change Data Capture CDCと略されます)について、詳しく説明したいと思います。
チェンジデータキャプチャとは？
復習もかねて、チェンジデータキャプチャとは何かについて説明したいと思います。データウェアハウスでは、業務システムなどの様々なソースシステムからデータを抽出し、クレンジングしてから、データベースに登録または更新を行います。その際、当然、新規追加されたデータまたは、更新、削除されたデータだけ反映したいですよね。では、どうやって、各ソースシステムからどのデータが変更されて、どのデータが変更されていないかを判断するのでしょうか。それを把握するのが、チェンジデータキャプチャという機能です。
代表的なチェンジデータキャプチャのテクニックは大きく下記の４つの方法があります。
・Source Data-Based CDC
・Trigger-Based CDC
・Snapshot-Based CDC
・Log-Based CDC
各チェンジデータキャプチャについてくわしく説明していきましょう。
Source Data-Based CDC
Source Data-Based CDCは、ソースシステムの変更データをあらわす属性を利用します。利用する属性として代表的なものに下記の２つがあります。
・タイムスタンプ
少なくとも更新日付が１つは必要になります。理想としては、新規登録日と更新日の２つあることが望ましいです。
・データベースシーケンス
多くのデータベースが自動でのシーケンス番号付与機能を持っています。これを利用すれば、どれが新規に追加されたどうかがわかります。
この方法を利用する場合、ETLがどのデータまでを利用したかどうかをデータウェアハウス側に保持する必要があります。通常は、ステージングエリアや専用のテーブルを作ってデータを保持しておきます。この方法は、とてもシンプルな方法でよく使われます。しかし、下記の点について考慮する方法があります。
・新規か追加の判断
新規追加日と更新日が両方ある場合に限り、新規と追加の判断が可能になります。
・削除レコード
物理的にデータが削除された場合は、どれが削除されたかがわからなくなります。論理的に削除され、削除日などのデータがある場合は、削除レコードを把握することができます。
・複数更新データの把握
前回のロードから今回のロードまでに複数回更新があった場合は、その中間の更新は把握できません。
・リアルタイム機能
タイムスタンプやシーケンスを利用したデータの判定はバッチ処理での利用となり、リアルタイムロードでは利用できません。
Trigger-Based CDC
この方法は、挿入、更新、削除などのデータ操作が実施された場合に、データベーストリガーを起動させ、ソースシステムの変更テーブルに変更内容を記録し、ETLで抽出する際にそのテーブルを利用する方法です。データトリガーがソースシステムで利用できるケースは少ないので、あまり使用されません。
Snapshot-Based CDC
この方法は、毎回すべてのデータをソースシステムから抽出し、データウェアハウスに登録されている最新バージョンのデータと比べて、変更レコードを把握する方法です。この方法ですと、物理削除されたデータも把握できます。また、ソースシステム側は対応が必要ありまんので、幅広く利用できるデータチェンジキャプチャテクニックとなります。ただ、毎回全件データを抽出するので、処理が重くなると多くのデータ容量が必要となります。
Log-Based CDC
一般的なデータベースであれば、データ変更された情報がログに記録されます。この方法はそのログを利用する方法です。これを利用すれば、物理削除のデータも把握することができます。
以上で一般的なチェンジデータキャプチャの説明は終わりとなりますが、最近のデータベースの多くが、このチェンジデータキャプチャの機能を標準搭載しはじめています。お使いのデータベースが対応している場合もあるので、事前に確認しましょう。
今回は以上となります。次回からはOLAPについて説明をしたいと思います。
チェンジデータキャプチャとは？
復習もかねて、チェンジデータキャプチャとは何かについて説明したいと思います。データウェアハウスでは、業務システムなどの様々なソースシステムからデータを抽出し、クレンジングしてから、データベースに登録または更新を行います。その際、当然、新規追加されたデータまたは、更新、削除されたデータだけ反映したいですよね。では、どうやって、各ソースシステムからどのデータが変更されて、どのデータが変更されていないかを判断するのでしょうか。それを把握するのが、チェンジデータキャプチャという機能です。
代表的なチェンジデータキャプチャのテクニックは大きく下記の４つの方法があります。
・Source Data-Based CDC
・Trigger-Based CDC
・Snapshot-Based CDC
・Log-Based CDC
各チェンジデータキャプチャについてくわしく説明していきましょう。
Source Data-Based CDC
Source Data-Based CDCは、ソースシステムの変更データをあらわす属性を利用します。利用する属性として代表的なものに下記の２つがあります。
・タイムスタンプ
少なくとも更新日付が１つは必要になります。理想としては、新規登録日と更新日の２つあることが望ましいです。
・データベースシーケンス
多くのデータベースが自動でのシーケンス番号付与機能を持っています。これを利用すれば、どれが新規に追加されたどうかがわかります。
この方法を利用する場合、ETLがどのデータまでを利用したかどうかをデータウェアハウス側に保持する必要があります。通常は、ステージングエリアや専用のテーブルを作ってデータを保持しておきます。この方法は、とてもシンプルな方法でよく使われます。しかし、下記の点について考慮する方法があります。
・新規か追加の判断
新規追加日と更新日が両方ある場合に限り、新規と追加の判断が可能になります。
・削除レコード
物理的にデータが削除された場合は、どれが削除されたかがわからなくなります。論理的に削除され、削除日などのデータがある場合は、削除レコードを把握することができます。
・複数更新データの把握
前回のロードから今回のロードまでに複数回更新があった場合は、その中間の更新は把握できません。
・リアルタイム機能
タイムスタンプやシーケンスを利用したデータの判定はバッチ処理での利用となり、リアルタイムロードでは利用できません。
Trigger-Based CDC
この方法は、挿入、更新、削除などのデータ操作が実施された場合に、データベーストリガーを起動させ、ソースシステムの変更テーブルに変更内容を記録し、ETLで抽出する際にそのテーブルを利用する方法です。データトリガーがソースシステムで利用できるケースは少ないので、あまり使用されません。
Snapshot-Based CDC
この方法は、毎回すべてのデータをソースシステムから抽出し、データウェアハウスに登録されている最新バージョンのデータと比べて、変更レコードを把握する方法です。この方法ですと、物理削除されたデータも把握できます。また、ソースシステム側は対応が必要ありまんので、幅広く利用できるデータチェンジキャプチャテクニックとなります。ただ、毎回全件データを抽出するので、処理が重くなると多くのデータ容量が必要となります。
Log-Based CDC
一般的なデータベースであれば、データ変更された情報がログに記録されます。この方法はそのログを利用する方法です。これを利用すれば、物理削除のデータも把握することができます。
以上で一般的なチェンジデータキャプチャの説明は終わりとなりますが、最近のデータベースの多くが、このチェンジデータキャプチャの機能を標準搭載しはじめています。お使いのデータベースが対応している場合もあるので、事前に確認しましょう。
今回は以上となります。次回からはOLAPについて説明をしたいと思います。
2011年5月28日土曜日
注文していたSAP BW ReportingとBusinessObjects本がとどきました
アマゾンで注文していた下記のSAP BWのレポーティング本とBusiness Objects本がとどきました。
これでSAP PRESSのBI/BW本が結構そろいました。
あとはひたすら読んで勉強するだけですね。
これでSAP PRESSのBI/BW本が結構そろいました。
あとはひたすら読んで勉強するだけですね。
Bloggerにログインできず！
最近ずっとブロガーにログインできずに困っていました。
ヘルプページを見たら、対応中のようだったのですぐなおるだろうと持っていましたがなかなかなおらず。。。
しびれを切らして、検索してみたら、他のブラウザやちがうPC環境だとできるらしい。
ということで、普段はクロームですが、サファリでログインしたら、できました。
よし。ということでブログをじゃんじゃん投稿します。
ヘルプページを見たら、対応中のようだったのですぐなおるだろうと持っていましたがなかなかなおらず。。。
しびれを切らして、検索してみたら、他のブラウザやちがうPC環境だとできるらしい。
ということで、普段はクロームですが、サファリでログインしたら、できました。
よし。ということでブログをじゃんじゃん投稿します。
キンボールグループによるビックデータに対するコラム
データウェアハウスのコンサルティング&教育で有名なキンボールからビックデータに関するコラムが掲載されています。
ぜひ、チェックを。
閲覧には登録が必要です。
The Evolving Role of the Enterprise Data Warehouse in the Era of Big Data Analytics
ぜひ、チェックを。
閲覧には登録が必要です。
The Evolving Role of the Enterprise Data Warehouse in the Era of Big Data Analytics
オライリーからHbase本がでる
HBaseは、GoogleのBig tableをモデルに作成された列指向の分散データベースです。
オライリーからThe Definitive Guideが出版される予定です。
出版されたら、ぜひ読みたいと思います。
http://oreilly.com/catalog/9781449396107/
オライリーからThe Definitive Guideが出版される予定です。
出版されたら、ぜひ読みたいと思います。
http://oreilly.com/catalog/9781449396107/
RubyのWebアプリケーションフレームワーク Sinatra
RubyのWebアプリケーションと言えば、Railsが有名ですが、SinatraというWebアプリケーションフレームワークもあります。
http://www.sinatrarb.com/
オライリーから、本が出版されるそうです。（英語ですが）
http://oreilly.com/catalog/9781449304232/
http://www.sinatrarb.com/
オライリーから、本が出版されるそうです。（英語ですが）
http://oreilly.com/catalog/9781449304232/
RedisというKVS（キー・バリュー・ストア）オープンソース
Redisというオープンソースのキー・バリュー・ストアソフトウェアがあります。
永続化に対応したインメモリDBです。
ぜひ、チェックを。
redis
http://redis.io/
オライリーから、The Definitive Guideが今年の8月に出るようです。
出版されたぜひ、読みたいと思います。
http://oreilly.com/catalog/0636920014294
永続化に対応したインメモリDBです。
ぜひ、チェックを。
redis
http://redis.io/
オライリーから、The Definitive Guideが今年の8月に出るようです。
出版されたぜひ、読みたいと思います。
http://oreilly.com/catalog/0636920014294
2011年5月25日水曜日
第12回：ETL34サブシステム 23-34
前回の続きです。ETL サブシステム23-34まで紹介します。
23.バックアップ機能(Backup System)
ETL環境のバックアップとリストア。
24.リカバリーと再スタート(Recovery and Restart)
ETL環境のリカバリーと失敗したジョブの再実行機能。
25.バージョン管理(Version Control)
ETLのバージョン管理。
26.バージョン移行(Version Migration)
開発環境からテスト、本番環境へETLを移行する機能。
27.ワークフロー監視(Workflow Monitor)
ETLワークフローの監視機能。
28.ソート
ETLでソートは重要な機能です。
データのクレンジングなどにもまずソートします。
29.リンクと依存管理(Lineage and Dependency)
ETLの修正で困るのがインパクト分析です。
データベースの項目がわかった場合にどのETLを直すべきか、この機能は非常に重要です。
30.問題エスカレーション
ETLは人的作業を介さずに自動で行うのが基本です。そして問題が発生したときに適切に処理して
通知する。それがこの機能です。
31.並列処理とパイプライング（Paralleling and Pipelining）
これはETLがマルチコアやグリッドコンピューティングを利用して効率よく処理する機能です。
32.セキュリティ
セキュリティはますます重要です。アクセスすべき人にのみアクセスさせる機能です。
33.コンプライアンス管理
コンプライアンス管理機能。
34.メタデータリポジトリ
メタデータの格納と管理。
これで以上になります。
このリストはながいですが、RFPなどのツール選定の評価項目として利用できるなど、なにかと便利です。
ぜひ、利用しましょう。
23.バックアップ機能(Backup System)
ETL環境のバックアップとリストア。
24.リカバリーと再スタート(Recovery and Restart)
ETL環境のリカバリーと失敗したジョブの再実行機能。
25.バージョン管理(Version Control)
ETLのバージョン管理。
26.バージョン移行(Version Migration)
開発環境からテスト、本番環境へETLを移行する機能。
27.ワークフロー監視(Workflow Monitor)
ETLワークフローの監視機能。
28.ソート
ETLでソートは重要な機能です。
データのクレンジングなどにもまずソートします。
29.リンクと依存管理(Lineage and Dependency)
ETLの修正で困るのがインパクト分析です。
データベースの項目がわかった場合にどのETLを直すべきか、この機能は非常に重要です。
30.問題エスカレーション
ETLは人的作業を介さずに自動で行うのが基本です。そして問題が発生したときに適切に処理して
通知する。それがこの機能です。
31.並列処理とパイプライング（Paralleling and Pipelining）
これはETLがマルチコアやグリッドコンピューティングを利用して効率よく処理する機能です。
32.セキュリティ
セキュリティはますます重要です。アクセスすべき人にのみアクセスさせる機能です。
33.コンプライアンス管理
コンプライアンス管理機能。
34.メタデータリポジトリ
メタデータの格納と管理。
これで以上になります。
このリストはながいですが、RFPなどのツール選定の評価項目として利用できるなど、なにかと便利です。
ぜひ、利用しましょう。
第11回：ETL34サブシステム 11-22
前回の続きです。ETL サブシステム11-22まで紹介します。
11.階層管理(Hierarchy Manager)
ディメンションの階層管理機能。
12.スペシャルディメンション管理（Special Dimensions Manager）
ジャンクディメンションやミニディメンション、日付ディメンションなどの特殊ディメンションの管理機能。
13.ファクトテーブル構築
主要な下記３つのファクトテーブルの構築を行う機能。
・トランザクション
・ピリオディックスナップショット
・アキュムレーションスナップショット
14.サロゲートキーパイプライン(Surrogate Key Pipeline)
オペレーションで使用するナチュラルキーを適切なサロゲートキーに変える機能。
15.マルチバリュードブリッチテーブル作成
ブリッチテーブルを作成する機能。
16.遅延データ処理(Late Arriving Data Handler)
データをデータウェアハウスに格納するときは、ディメンションを更新してから、ファクトを格納する必要がある。
しかし、ファクトがもうあるのにディメンションのほうはデータが更新されないということはよくある。
その場合に対応する機能です。基本的には一旦仮のディメンションに紐づけておいて、ディメンションが更新されてから
ファクトの紐づきを更新するのが基本のようです。
SSISでは「 Inferred Member Support」いうのがあってサポートされています。
17.ディメンション管理 (Dimension Manager)
共通ディメンション(conformed dimensions)を管理する機能。
18.ファクトテーブルプロバイダー
ファクトテーブルのアドミン管理、作成、維持、使用の管理機能。
19.サマリービルダー
サマリーを管理する機能。
データをサマリーするのは性能を向上する重要な機能ですが、管理、維持が大変なのでシステムである程度カバーする必要があります。
20. OLAP cubeビルダー
OLAP Cbueのデータロードおよび管理。
ETLというよりはOLAPの機能ですよね。
21.データ統合管理(Data Propagation Manager)
他のシステムとのデータ統合を管理する機能。
22.ジョブスケジューリング機能
ETLジョブの管理。
次回へ続きます。
11.階層管理(Hierarchy Manager)
ディメンションの階層管理機能。
12.スペシャルディメンション管理（Special Dimensions Manager）
ジャンクディメンションやミニディメンション、日付ディメンションなどの特殊ディメンションの管理機能。
13.ファクトテーブル構築
主要な下記３つのファクトテーブルの構築を行う機能。
・トランザクション
・ピリオディックスナップショット
・アキュムレーションスナップショット
14.サロゲートキーパイプライン(Surrogate Key Pipeline)
オペレーションで使用するナチュラルキーを適切なサロゲートキーに変える機能。
15.マルチバリュードブリッチテーブル作成
ブリッチテーブルを作成する機能。
16.遅延データ処理(Late Arriving Data Handler)
データをデータウェアハウスに格納するときは、ディメンションを更新してから、ファクトを格納する必要がある。
しかし、ファクトがもうあるのにディメンションのほうはデータが更新されないということはよくある。
その場合に対応する機能です。基本的には一旦仮のディメンションに紐づけておいて、ディメンションが更新されてから
ファクトの紐づきを更新するのが基本のようです。
SSISでは「 Inferred Member Support」いうのがあってサポートされています。
17.ディメンション管理 (Dimension Manager)
共通ディメンション(conformed dimensions)を管理する機能。
18.ファクトテーブルプロバイダー
ファクトテーブルのアドミン管理、作成、維持、使用の管理機能。
19.サマリービルダー
サマリーを管理する機能。
データをサマリーするのは性能を向上する重要な機能ですが、管理、維持が大変なのでシステムである程度カバーする必要があります。
20. OLAP cubeビルダー
OLAP Cbueのデータロードおよび管理。
ETLというよりはOLAPの機能ですよね。
21.データ統合管理(Data Propagation Manager)
他のシステムとのデータ統合を管理する機能。
22.ジョブスケジューリング機能
ETLジョブの管理。
次回へ続きます。
第10回：ETL34サブシステム 1-10
データウェアハウスの構築に欠かせないのがなんと言ってもETLツールです。
ETLツールとは、Extract, Transfer, Loadの略で、簡単にいってしまえば、データウェアハウスの元データとなるソースシステムからデータを取ってきて、きれいにしてデータウェアハウスに格納するという機能です。と、言われてもピンとこないですよね。
では、具体的にETLツールにはどのような機能があるのでしょうか。
実は、データウェアハウスのコンサルティングで有名なキンボールグループでETLに必要なサブシステムについて
情報を提供しています。
今回はそのキンボールリストにならって各サブシステムについて解説していきたいと思います。サブシステムが３４もあるので、3回に分けて解説していきたいと思います。
1.データプロファイリング (Data Profiling)
データプロファイリングとは、データウェアハウスの構築となるソースデータの現状データを調査することです。
この調査をすることにより、ETLツールでどのようなクレンジングが必要になるかを計画することができます。
SQLなどで個々のテーブルを調査していくこともできますが、主要なETLツールはデータプロファイリングの機能をもっている場合が多いです。
たとえば、MicrosoftのSQL Sever Integration Service (SSIS)もデータプロファイリングの機能を持っています。
また、オープンソースでいえば、「DataCleaner」というツールがあります。
http://datacleaner.eobjects.org
2.チェンジデータキャプチャ(Change Data Capture)
チェンジデータキャプチャとは、ソースシステムでどのデータが追加、変更、削除されたどうかを把握する仕組みです。
データウェアハウスにデータを反映する際は、ETLの負荷を減らすため、差分のみ反映する必要があります。
チェンジデータキャプチャには、さまざまな方法がありますが、最近は主要なデータベースがチェンジデータキャプチャの機能を
取り込んでいますので、確認してみるといいと思います。
3.データ抽出システム（Extract System）
これはソースシステムからデータを抽出し、ステージングエリアへ移動させるシステムです。
ソース元のデータベースへの接続方法や文字コードなど考慮する必要があります。
4.データクレンジングシステム(Data Cleansing System)
ソースデータが来るデータがいつも正しいとは限りません。というかたいていはエラーデータが含まれています。
データをチェックして、クレンジングまたは不正データをつかめることはETLの大事な機能ですね。
5.エラーイベントトラッキング（Error Event Tracking）
エラーを含んだデータを見つけたらそれがトラッキングできるようにする機能です。
どのデータにエラーが起きたのか後で確認できる必要があります。
6.監査ディメンション作成 （Audit Dimension Creation）
監査は現在重要な機能です。ということで、ETLプロセスを後で監査できるようにデータを記録する必要があります。
7.重複処理（Deduplication ）
データウェアハウスは複数のデータベースから情報を取得するため、顧客や製品情報が重複しています。
これを統合して処理する必要があります。
ただ、最近はマスターデータマネジメント機能などがありますので、そちらでデータを統合したほうがよいかと思います。
8.データ共有化（Data Conformance）
これはConform dimensionなどを作ったり、あとでドリルアクロスができるようにディメンションを共有化しておく機能です。
インモンアプローチをとる場合はいらないかもしれません。
9.除々に変化するディメンション管理(Slowly Changing Dimension (SCD) Manager)
スタースキーマの要のSlowly Changing Dimension。これのロジックを管理する機能です。
最近のETLは基本的なSlowly changing Dimensionは簡単に構築できるようになっています。
10.サロゲートキー生成 (Surrogate Key Generator)
ぞれぞれのディメンションで必要となるサロゲートキーを生成する機能。
続きは次回に説明します。
ETLツールとは、Extract, Transfer, Loadの略で、簡単にいってしまえば、データウェアハウスの元データとなるソースシステムからデータを取ってきて、きれいにしてデータウェアハウスに格納するという機能です。と、言われてもピンとこないですよね。
では、具体的にETLツールにはどのような機能があるのでしょうか。
実は、データウェアハウスのコンサルティングで有名なキンボールグループでETLに必要なサブシステムについて
情報を提供しています。
今回はそのキンボールリストにならって各サブシステムについて解説していきたいと思います。サブシステムが３４もあるので、3回に分けて解説していきたいと思います。
1.データプロファイリング (Data Profiling)
データプロファイリングとは、データウェアハウスの構築となるソースデータの現状データを調査することです。
この調査をすることにより、ETLツールでどのようなクレンジングが必要になるかを計画することができます。
SQLなどで個々のテーブルを調査していくこともできますが、主要なETLツールはデータプロファイリングの機能をもっている場合が多いです。
たとえば、MicrosoftのSQL Sever Integration Service (SSIS)もデータプロファイリングの機能を持っています。
また、オープンソースでいえば、「DataCleaner」というツールがあります。
http://datacleaner.eobjects.org
2.チェンジデータキャプチャ(Change Data Capture)
チェンジデータキャプチャとは、ソースシステムでどのデータが追加、変更、削除されたどうかを把握する仕組みです。
データウェアハウスにデータを反映する際は、ETLの負荷を減らすため、差分のみ反映する必要があります。
チェンジデータキャプチャには、さまざまな方法がありますが、最近は主要なデータベースがチェンジデータキャプチャの機能を
取り込んでいますので、確認してみるといいと思います。
3.データ抽出システム（Extract System）
これはソースシステムからデータを抽出し、ステージングエリアへ移動させるシステムです。
ソース元のデータベースへの接続方法や文字コードなど考慮する必要があります。
4.データクレンジングシステム(Data Cleansing System)
ソースデータが来るデータがいつも正しいとは限りません。というかたいていはエラーデータが含まれています。
データをチェックして、クレンジングまたは不正データをつかめることはETLの大事な機能ですね。
5.エラーイベントトラッキング（Error Event Tracking）
エラーを含んだデータを見つけたらそれがトラッキングできるようにする機能です。
どのデータにエラーが起きたのか後で確認できる必要があります。
6.監査ディメンション作成 （Audit Dimension Creation）
監査は現在重要な機能です。ということで、ETLプロセスを後で監査できるようにデータを記録する必要があります。
7.重複処理（Deduplication ）
データウェアハウスは複数のデータベースから情報を取得するため、顧客や製品情報が重複しています。
これを統合して処理する必要があります。
ただ、最近はマスターデータマネジメント機能などがありますので、そちらでデータを統合したほうがよいかと思います。
8.データ共有化（Data Conformance）
これはConform dimensionなどを作ったり、あとでドリルアクロスができるようにディメンションを共有化しておく機能です。
インモンアプローチをとる場合はいらないかもしれません。
9.除々に変化するディメンション管理(Slowly Changing Dimension (SCD) Manager)
スタースキーマの要のSlowly Changing Dimension。これのロジックを管理する機能です。
最近のETLは基本的なSlowly changing Dimensionは簡単に構築できるようになっています。
10.サロゲートキー生成 (Surrogate Key Generator)
ぞれぞれのディメンションで必要となるサロゲートキーを生成する機能。
続きは次回に説明します。
第9回：ディメンショナルモデリング：ファクト設計：ファクトレスファクトテーブル
前回、３つのファクト設計トランザクション、スナップショット、アキュムレーションスナップショットについて説明しましたが、今回はトランザクションの派生設計となるファクトレスファクトテーブルについて説明します。
ファクトレスファクトテーブル
では、ファクトレスファクトテーブルって何でしょうか。日本語に訳せば、ファクトがないファクトテーブルとなります。
そうです、ファクトがないのがファクトテーブルなのです。ファクトって何のことでしたでしょうか。そうです、売上高など分析する数値にあたる部分でした。
この数値部分がないのがファクトレスファクトテーブルなのです。具体例をあれば、会員数などです。売上高データのように登録された会員数のデータには数値は含まれていませんよね。
もちろん、SQLなどのcountを使えば、件数は確認できますが。
ということで、実際数値情報が入っていないが、件数などの情報をファクトして扱うものをファクトレスファクトテーブルと呼びます。
では、どのように設計するのでしょうか。基本はトランザクションと同様にそのままデータを挿入していきます。しかし、ファクトデータがないので、設計をシンプルにするためにあえて、ファクト値のフィールドを作成して１を入力しておきます。このフィールドがなくても、SQLの集計関数を使えば、計算できるのですが、設計とシステムをシンプルにするために１を追加します。
具体例は、下記の図をご覧ください。
短いですが、以上でファクトレスファクトテーブルの説明は終わりです。これでディメンショナルモデリングについて一通り説明が終了しました。
次回よりETL4回にわたって、ETLについて説明をしたいと思います。
ファクトレスファクトテーブル
では、ファクトレスファクトテーブルって何でしょうか。日本語に訳せば、ファクトがないファクトテーブルとなります。
そうです、ファクトがないのがファクトテーブルなのです。ファクトって何のことでしたでしょうか。そうです、売上高など分析する数値にあたる部分でした。
この数値部分がないのがファクトレスファクトテーブルなのです。具体例をあれば、会員数などです。売上高データのように登録された会員数のデータには数値は含まれていませんよね。
もちろん、SQLなどのcountを使えば、件数は確認できますが。
ということで、実際数値情報が入っていないが、件数などの情報をファクトして扱うものをファクトレスファクトテーブルと呼びます。
では、どのように設計するのでしょうか。基本はトランザクションと同様にそのままデータを挿入していきます。しかし、ファクトデータがないので、設計をシンプルにするためにあえて、ファクト値のフィールドを作成して１を入力しておきます。このフィールドがなくても、SQLの集計関数を使えば、計算できるのですが、設計とシステムをシンプルにするために１を追加します。
具体例は、下記の図をご覧ください。
短いですが、以上でファクトレスファクトテーブルの説明は終わりです。これでディメンショナルモデリングについて一通り説明が終了しました。
次回よりETL4回にわたって、ETLについて説明をしたいと思います。
第8回：ディメンショナルモデリング：ファクト設計：トランザクション、スナップショット、アキュムレーションスナップショット
前回は、ディメンショナルモデリングで重要なスローリーチェンジングディメンションについて解説しましたが、今回は分析する数値部分にあたるファクトの設計について説明します。
ファクトって何？
さて、復習です。ファクトって何でしょうか。ファクトはスタースキーマの真ん中に位置するデータで分析する数値のことです。製品によってはメジャーと呼ばれたりします。売上高、ログイン数、会員数などがファクトにあたります。
ファクトの設計
そのファクトデータの格納方法ですが、実は大きく分けてファクトの利用目的によって下記の３つの設計方法にわかります。
・トランザクション
・スナップショット
・アキュムレーションスナップショット
以下順にそれぞれのファクト設計について説明します。
トランザクション
まずはトランザクションからです。これはもっともオーソドックスなファクトの設計方法で、分析するデータがトランザクションデータの積み上げで掲載される場合に使用されます。
よくわからないと思うので、例をもとに説明します。たとえば、売上高ですが、売上高は、当たり前ですが、それぞれの商品の売り上げを足し上げたものが全体の売上高ですよね。
あと、会員サイトの会員数やログイン数、Webサイトのページビュー数もそれぞれの会員、ログイン、ページビューの積み上げで計算されますね。
では、設計はどうすのでしょうか。簡単です。そのまま、各トランザクションのデータをそのままファクトテーブルに挿入していくだけです。とっても簡単ですね。これがトランザクション。
スナップショット
次はスナップショットです。これは、名前から推測できるようにある時点での状況を分析するために利用します。たとえば、在庫ですね。
在庫は、入荷や出庫などが頻繁に行われて在庫は常に変わります。そして、分析する場合はここの出庫、入庫というよりもある時点での在庫がどのくらいあるかということを分析します。たとえば、各月末の在庫状況の推移などです。
では、どのように設計するのでしょうか。もちろん、入庫や出庫などのトランザクションデータを格納しておいて、クエリを投げることによってレポートを作成できるのですが、これでは時間がかかりすぎます。
そのため、ETLツールなどを利用して、トランザクションデータから必要となる時点のスナップショットデータを作成します。これがスナップショットです。
アキュムレーションスナップショット
最後にアキュムレーションスナップショットです。これは関連するトランザクションデータを分析したい場合に利用します。
たとえば、ある製品を販売する場合、注文受付→工場へ発注→工場から商品受取→出荷→商品受取→支払などの一覧のプロセスを経ると思います。
それぞれ個別に分析する場合もあると思いますが、注文受付から商品支払までどのくらい時間がかかているかなど、プロセス全体を分析したい場合があると思います。
その際にこのアキュムレーションスナップショットを利用します。
トランザクションの場合は、トランザクションデータの発生ごとにデータをどんどん追加していきますが、アキュムレーションスナップショットの場合は、プロセスの初めでデータができて、あとはプロセスを経るごとに関連するフィールドを更新していくことになります。たとえば、注文受付の時点でデータの作成と受付日は入ります。次に工場に発注されると、発注日が、工場から商品を受けとると商品受付日が更新されるといった感じです。
今回は、ファクト設計について説明しました。次回は、ファクト設計の派生版であるファクトレスファクトテーブルについて説明します。
ファクトって何？
さて、復習です。ファクトって何でしょうか。ファクトはスタースキーマの真ん中に位置するデータで分析する数値のことです。製品によってはメジャーと呼ばれたりします。売上高、ログイン数、会員数などがファクトにあたります。
ファクトの設計
そのファクトデータの格納方法ですが、実は大きく分けてファクトの利用目的によって下記の３つの設計方法にわかります。
・トランザクション
・スナップショット
・アキュムレーションスナップショット
以下順にそれぞれのファクト設計について説明します。
トランザクション
まずはトランザクションからです。これはもっともオーソドックスなファクトの設計方法で、分析するデータがトランザクションデータの積み上げで掲載される場合に使用されます。
よくわからないと思うので、例をもとに説明します。たとえば、売上高ですが、売上高は、当たり前ですが、それぞれの商品の売り上げを足し上げたものが全体の売上高ですよね。
あと、会員サイトの会員数やログイン数、Webサイトのページビュー数もそれぞれの会員、ログイン、ページビューの積み上げで計算されますね。
では、設計はどうすのでしょうか。簡単です。そのまま、各トランザクションのデータをそのままファクトテーブルに挿入していくだけです。とっても簡単ですね。これがトランザクション。
スナップショット
次はスナップショットです。これは、名前から推測できるようにある時点での状況を分析するために利用します。たとえば、在庫ですね。
在庫は、入荷や出庫などが頻繁に行われて在庫は常に変わります。そして、分析する場合はここの出庫、入庫というよりもある時点での在庫がどのくらいあるかということを分析します。たとえば、各月末の在庫状況の推移などです。
では、どのように設計するのでしょうか。もちろん、入庫や出庫などのトランザクションデータを格納しておいて、クエリを投げることによってレポートを作成できるのですが、これでは時間がかかりすぎます。
そのため、ETLツールなどを利用して、トランザクションデータから必要となる時点のスナップショットデータを作成します。これがスナップショットです。
アキュムレーションスナップショット
最後にアキュムレーションスナップショットです。これは関連するトランザクションデータを分析したい場合に利用します。
たとえば、ある製品を販売する場合、注文受付→工場へ発注→工場から商品受取→出荷→商品受取→支払などの一覧のプロセスを経ると思います。
それぞれ個別に分析する場合もあると思いますが、注文受付から商品支払までどのくらい時間がかかているかなど、プロセス全体を分析したい場合があると思います。
その際にこのアキュムレーションスナップショットを利用します。
トランザクションの場合は、トランザクションデータの発生ごとにデータをどんどん追加していきますが、アキュムレーションスナップショットの場合は、プロセスの初めでデータができて、あとはプロセスを経るごとに関連するフィールドを更新していくことになります。たとえば、注文受付の時点でデータの作成と受付日は入ります。次に工場に発注されると、発注日が、工場から商品を受けとると商品受付日が更新されるといった感じです。
今回は、ファクト設計について説明しました。次回は、ファクト設計の派生版であるファクトレスファクトテーブルについて説明します。
第7回：ディメンショナルモデリング：ディメンション設計：スローリーチェンジングディメンション
今回は、ディメンショナルモデリングで重要なスローリーチェンジングディメンション(Slowly Changing Dimensions (SCD))について説明します。これは非常に重要なテクニックで、データウェアハウス、BIに係る人には必須のテクニックとなります。多くのデータウェアハウス、BI製品はこのスローリーチェンジングディメンションを知っている前提で製品を説明していますので、ぜひここで押さえましょう。
スローリーチェンジングディメンションって何？
では、スローリーチェンジングディメンション(Slowly Changing Dimensions (SCD))っていったい何でしょうか。
（日本語訳として、「徐々に変化するディメンション」や「ゆるかやに変化するディメンション」などの訳語が使用されていますが、ちょっとしっくりこないのでここでは英語をそのままカタカナ表記して記載したいと思います。）
はこれデータウェアハウスで使用するディメンションデータの更新の対応方法のことなのです。ディメンションとは、年や月、製品、住所などのデータを分析する上で必要になる切り口のことですが、これは更新されることがあります。
例えば、Aさんが引っ越して、住所が長野県から東京都にかわるなどです。それをそのまま何も考えずに上書きすると大変なことになります。なぜなら、今まで長野県に住んでいるときに行った過去の行動が東京でおこったことになるからです。
そのため、データウェアハウスの設計ではこの更新する方法論が確立されています。基本はType0~Type4まであり、あとそのハイブリット型があります。
以下、それぞれのタイプについて説明します。
Type 0 SCD
これはデータが更新されても何もしないことです。値がかわっても無視です。まあ、通常はデータを何かに使うために保持しているはずなので、このタイプはあまりないと思います。
Type 1 SCD
これは、値が変化したときに、テーブルの値をそのまま上書き変更します。これは、変更がビジネス上さほど重要でない場合に採用します。たとえば、顧客の名前など。。。
問題点としては、顧客の住所などを上書きすると、過去のデータを地域別でみた場合、データが正しく分析できないことです。また、注意としてサマリーデータなどを持っている場合は、データを再構築する必要があります。
Type 2 SCD
値が変化したときに、新しいレコードを追加します。また、各レコードにStart date(From date)とEnd date(To date)を入れておきます。最新のデータはEnd dateに99991231などを入れておきます。
この方法を採用すると、トランザクションデータ(ファクトデータ)をデータが発生した時に状況で分析することができます。上の例でいえば、引っ越しをして、住所が長野県→東京都に住所が変更になっても、長野県に住んでいたときに発生したトランザクションは長野県に計上され、引っ越し後のトランザクションは東京都に計上されることになります。非常によく使用するタイプとなります。
問題点としては変更が多いとたくさんのレコードが増えます。この場合過去のサマリーテーブルは再構築する必要はありません。
Type 3 SCD
あらかじめデータに現在の値とその前の値のフィールドを用意しておき、変更があった場合に古いデータを以前のデータフィールドへ入れて、最新の現在のデータフィールドへ格納します。問題点は複数の変更に対応できません。保持できるのは一つ前のデータだけ。
これは営業のテリトリー変更などで一つまえのテリトリーで現在の値をみたい場合などに威力を発揮します。
Type 4 SCD
これはテーブルには最新の情報を保持し、古いデータは別途用意した履歴テーブルへ格納します。問題点としてはシステムが複雑になります。
Hybrid SCDs
これ以外にそのハイブリット版として２つの方法があります。
複数バージョンによる予期可能な変更(Predictable changes with Multiple Version overlays)
これは例えば、毎年営業のテリトリーが変更になり、分析要件としてすべての情報を指定した年のテリトリーで分析したい場合などに利用します。方法としては、レコードの列にそれぞれの年のフィールドを用意しておきます。でもシステムがとっても複雑になるので、諸刃の剣です。
単一バージョンによる予測不可能な変更(Unpredictable Changes with Singel version overlay)
これは予測できない変更に対して、分析の切り口として現在の状態での切り口とそのデータが発生したときに切り口で分析したい場合に使用します。これはレコードに現在のデータと過去のデータのフィールドを用意しておき、変更があった場合にレコードを追加し、関連する現在のデータの変更を行う方法です。
これは、Type 2 と Type 3と Type 1を合わせた感じなので、Type 6(2+3+1)と呼ばれています。
これらのタイプは各レコードの列ごとに適用します。設計時に各フィールドをどのタイプにするか詳細に検討する必要があります。
今回はディメンションの変更管理方法について説明しました。次回は、ファクトの構築方法について説明します。
スローリーチェンジングディメンションって何？
では、スローリーチェンジングディメンション(Slowly Changing Dimensions (SCD))っていったい何でしょうか。
（日本語訳として、「徐々に変化するディメンション」や「ゆるかやに変化するディメンション」などの訳語が使用されていますが、ちょっとしっくりこないのでここでは英語をそのままカタカナ表記して記載したいと思います。）
はこれデータウェアハウスで使用するディメンションデータの更新の対応方法のことなのです。ディメンションとは、年や月、製品、住所などのデータを分析する上で必要になる切り口のことですが、これは更新されることがあります。
例えば、Aさんが引っ越して、住所が長野県から東京都にかわるなどです。それをそのまま何も考えずに上書きすると大変なことになります。なぜなら、今まで長野県に住んでいるときに行った過去の行動が東京でおこったことになるからです。
そのため、データウェアハウスの設計ではこの更新する方法論が確立されています。基本はType0~Type4まであり、あとそのハイブリット型があります。
以下、それぞれのタイプについて説明します。
Type 0 SCD
これはデータが更新されても何もしないことです。値がかわっても無視です。まあ、通常はデータを何かに使うために保持しているはずなので、このタイプはあまりないと思います。
Type 1 SCD
これは、値が変化したときに、テーブルの値をそのまま上書き変更します。これは、変更がビジネス上さほど重要でない場合に採用します。たとえば、顧客の名前など。。。
問題点としては、顧客の住所などを上書きすると、過去のデータを地域別でみた場合、データが正しく分析できないことです。また、注意としてサマリーデータなどを持っている場合は、データを再構築する必要があります。
Type 2 SCD
値が変化したときに、新しいレコードを追加します。また、各レコードにStart date(From date)とEnd date(To date)を入れておきます。最新のデータはEnd dateに99991231などを入れておきます。
この方法を採用すると、トランザクションデータ(ファクトデータ)をデータが発生した時に状況で分析することができます。上の例でいえば、引っ越しをして、住所が長野県→東京都に住所が変更になっても、長野県に住んでいたときに発生したトランザクションは長野県に計上され、引っ越し後のトランザクションは東京都に計上されることになります。非常によく使用するタイプとなります。
問題点としては変更が多いとたくさんのレコードが増えます。この場合過去のサマリーテーブルは再構築する必要はありません。
Type 3 SCD
あらかじめデータに現在の値とその前の値のフィールドを用意しておき、変更があった場合に古いデータを以前のデータフィールドへ入れて、最新の現在のデータフィールドへ格納します。問題点は複数の変更に対応できません。保持できるのは一つ前のデータだけ。
これは営業のテリトリー変更などで一つまえのテリトリーで現在の値をみたい場合などに威力を発揮します。
Type 4 SCD
これはテーブルには最新の情報を保持し、古いデータは別途用意した履歴テーブルへ格納します。問題点としてはシステムが複雑になります。
Hybrid SCDs
これ以外にそのハイブリット版として２つの方法があります。
複数バージョンによる予期可能な変更(Predictable changes with Multiple Version overlays)
これは例えば、毎年営業のテリトリーが変更になり、分析要件としてすべての情報を指定した年のテリトリーで分析したい場合などに利用します。方法としては、レコードの列にそれぞれの年のフィールドを用意しておきます。でもシステムがとっても複雑になるので、諸刃の剣です。
単一バージョンによる予測不可能な変更(Unpredictable Changes with Singel version overlay)
これは予測できない変更に対して、分析の切り口として現在の状態での切り口とそのデータが発生したときに切り口で分析したい場合に使用します。これはレコードに現在のデータと過去のデータのフィールドを用意しておき、変更があった場合にレコードを追加し、関連する現在のデータの変更を行う方法です。
これは、Type 2 と Type 3と Type 1を合わせた感じなので、Type 6(2+3+1)と呼ばれています。
これらのタイプは各レコードの列ごとに適用します。設計時に各フィールドをどのタイプにするか詳細に検討する必要があります。
今回はディメンションの変更管理方法について説明しました。次回は、ファクトの構築方法について説明します。
第6回：ディメンショナルモデリング：階層とスノーフレーク
前回は、ディメンショナルモデリングの基本スタースキーマについて解説しました。今回はもう少し踏み込んで解説したいと思います。
階層とドリルダウン
データウェアハウスなどの分析データベースは、業務データベースと違い、個々の明細データに注目せず、月別や顧客別など、ある程度まとまったグループ単位のデータに注目します。その際、重要となるのが、階層という概念です。
売上データ分析を例に説明したいと思います。たとえば、ある企業の経営者が最近5年の売上について分析したいとします。まず、経営者は全体の状況を把握するために年別で各年の売上状況を確認します。この場合、データは年別の売上高で分析されます。そして、ある年だけ極端に売上高が下がっていることに気付いたとします。その場合、経営者はどのような行動をとるでしょうか。
おそらく、その原因を探ろうと、あれこれ分析軸を変えて分析するはずです。今回は、売上高が低い年をさらに詳細に月別で分析するケースを見ていましょう。経営者はでは、その年のどの月が売上が低いのかという疑問をもとに月別の売上データをみます。
そして、さらに月別の売上データで気になる月あれば、さらに日別の売上高というかたちで、どんどん的を絞って詳細にデータを見ていきます。このようにどんどん詳細化して分析していくことを、ドリルダウンと呼びます。ドリルダウンとは逆に、上にあがっていくことをドリルアップと呼びます。
例では、日付情報を年>月>日とみていきましたが、他のディメンション例では、製品情報の大カテゴリ>中カテゴリ>小カテゴリなどがあると思います。ここで使われているのが階層という概念です。そのため、設計の際は、どのような階層で分析したいかどうかについても把握する必要があるのです。
階層は非正規化で保持
通常の業務システムでは、各階層を別のテーブルにして、1対多でリンクするのが一般的だと思いますが、ディメンショナルデータベースでは１つのテーブルに非正規化した形で保持します。これは、おもな理由としてパフォーマンスを向上するためと、ユーザにも分かりやすいようにスタースキーマをシンプルにするためです。業務データベースでは、更新の際の整合性を保つために正規化しますが、分析データベースは更新が少ないため、非正規化によるメリットがデメリットを上回る形になります。
スノーフレーク
もしディメンションを非正規化せずに、正規化で構築した場合はスノーフレークと呼ばれます。スタースキーマが雪の結晶のように見えるためこのように呼ばれています。
ディメンショナルモデリングでは、ブリッチテーブルなどの特殊な場合を除き、あまり望ましくない設計とされています。
業務データベースを経験している人は、つい正規化してしまいがちですが、性能とシンプルさという観点からなるべくスノーフレークは避けたほうがよいでしょう。
今回は、階層とスノーフレークについて説明しました。次回はディメンショナルモデリングで重要なスローリーチェンジングディメンションについて解説します。
階層とドリルダウン
データウェアハウスなどの分析データベースは、業務データベースと違い、個々の明細データに注目せず、月別や顧客別など、ある程度まとまったグループ単位のデータに注目します。その際、重要となるのが、階層という概念です。
売上データ分析を例に説明したいと思います。たとえば、ある企業の経営者が最近5年の売上について分析したいとします。まず、経営者は全体の状況を把握するために年別で各年の売上状況を確認します。この場合、データは年別の売上高で分析されます。そして、ある年だけ極端に売上高が下がっていることに気付いたとします。その場合、経営者はどのような行動をとるでしょうか。
おそらく、その原因を探ろうと、あれこれ分析軸を変えて分析するはずです。今回は、売上高が低い年をさらに詳細に月別で分析するケースを見ていましょう。経営者はでは、その年のどの月が売上が低いのかという疑問をもとに月別の売上データをみます。
そして、さらに月別の売上データで気になる月あれば、さらに日別の売上高というかたちで、どんどん的を絞って詳細にデータを見ていきます。このようにどんどん詳細化して分析していくことを、ドリルダウンと呼びます。ドリルダウンとは逆に、上にあがっていくことをドリルアップと呼びます。
例では、日付情報を年>月>日とみていきましたが、他のディメンション例では、製品情報の大カテゴリ>中カテゴリ>小カテゴリなどがあると思います。ここで使われているのが階層という概念です。そのため、設計の際は、どのような階層で分析したいかどうかについても把握する必要があるのです。
階層は非正規化で保持
通常の業務システムでは、各階層を別のテーブルにして、1対多でリンクするのが一般的だと思いますが、ディメンショナルデータベースでは１つのテーブルに非正規化した形で保持します。これは、おもな理由としてパフォーマンスを向上するためと、ユーザにも分かりやすいようにスタースキーマをシンプルにするためです。業務データベースでは、更新の際の整合性を保つために正規化しますが、分析データベースは更新が少ないため、非正規化によるメリットがデメリットを上回る形になります。
スノーフレーク
もしディメンションを非正規化せずに、正規化で構築した場合はスノーフレークと呼ばれます。スタースキーマが雪の結晶のように見えるためこのように呼ばれています。
ディメンショナルモデリングでは、ブリッチテーブルなどの特殊な場合を除き、あまり望ましくない設計とされています。
業務データベースを経験している人は、つい正規化してしまいがちですが、性能とシンプルさという観点からなるべくスノーフレークは避けたほうがよいでしょう。
今回は、階層とスノーフレークについて説明しました。次回はディメンショナルモデリングで重要なスローリーチェンジングディメンションについて解説します。
日本テラデータ、SSDとHDDのハイブリッドを採用
日本テラデータが、SSDとHDDのハイブリッドを採用した。
下記をチェック。
SSDとHDDのハイブリッドで、常に最適なデータ配置を実現
http://www.atmarkit.co.jp/news/201105/20/tera.html
下記をチェック。
SSDとHDDのハイブリッドで、常に最適なデータ配置を実現
http://www.atmarkit.co.jp/news/201105/20/tera.html
日本IBM、Hadoopベースの大規模データ向け処理ソフトを投入
日本IBMがHadoopベースの処理ソフトを投入した。
下記の記事をチェック。
日本IBM、Hadoopベースの大規模データ向け処理ソフトを投入
http://itpro.nikkeibp.co.jp/article/NEWS/20110523/360580/
下記の記事をチェック。
日本IBM、Hadoopベースの大規模データ向け処理ソフトを投入
http://itpro.nikkeibp.co.jp/article/NEWS/20110523/360580/
2011年5月21日土曜日
SAP BW, Business Objects本を追加で注文！
さらに勉強しようと思い、下記の本をアマゾンで注文しました。
NetWeaverとBusiness Objectsをさらに勉強しようと思います。
注文したら、さっそく読みたいと思います。
NetWeaverとBusiness Objectsをさらに勉強しようと思います。
注文したら、さっそく読みたいと思います。
2011年5月15日日曜日
SAP BW:InfoProviderとInfoSetの謎を解く
SAP BWにInfoProivderとInFosetとという、データやキューブをリンクする機能があります。
この両方の違いって何でしょうか。
実は、InfoProviderがUnion結合で、InfoSetがJoin結合です。
SAP BWは良くできていますね。
この両方の違いって何でしょうか。
実は、InfoProviderがUnion結合で、InfoSetがJoin結合です。
SAP BWは良くできていますね。
2011年5月10日火曜日
第5回：ディメンショナルモデリング：スタースキーマ
今回はデータベースのデザインでもっとも重要なディメンショナルモデリングのスタースキーマについて解説します。
データウェアハウスモデリングは業務データモデリングと違う
まず、スタースキーマについて説明する前に、データウェアハウスのモデリングと業務データベースのモデリングは違うということについて強調しておきたいと思います。業務データベースの設計をやっていた人が、データウェアハウスのモデリングでまず驚くのがこの違いです。私も業務データベースの設計をしていたので、データウェアハウスのモデリングを勉強したときはあまりの違いになかなか馴染めませんでした。
ということでまず次を読む前に業務データベースの設計は忘れてください！
データウェアハウスモデリングの極意！スタースキーマ
データウェアハウスのそもそもの目的ってなんでしょうか。そう、データを分析することです。データ分析って何に注目するのでしょうか。それは数字です。例えば、売上高、ウェブサイトのページビュー、会員数などです。データウェアハウスのモデリングはまずこの数字に着目します。モデリング用語ではこれをファクトと呼びます。製品によってはメジャーと呼んだりもします。
では、そのファクト、例えば売上高に着目した時にどうやって分析しますか？例えば、支社別の売上高とか月別の売上高とか顧客別とか、いくつかのまとまりで売上高を見ますよね？これをモデリングではディメンションと呼ぶのです。
そして、データウェアハウスのモデリングではファクトテーブルを真ん中において、それを囲むようにディメンションをリンクします。モデリングのかたちが星形に似ていることからスタースキーマと呼ばれます。
下記に例を示します。下記は売上ファクトテーブルを真ん中にして、それを日付ディメンション、営業所ディメンション、顧客ディメンションでリンクしています。
これにより簡単にGroup byでレポートを作ることができます。実際にサンプルデータで確認して見ましょう。
下記に上のモデリングのサンプルデータとレポートを示します。
レポートでは月別の売上を表示しています。SQLで言えば、SUM関数とGROUP BYで簡単に結果を出すことができます。スタースキーマの強みはなんといってもレスポンスの早さです。ジョインが少ないので、クエリを素早く実行することができます。
簡単な例ですが、以上がスタースキーマのモデリングの概要になります。
次回は階層とスノーフレークについて解説します。
データウェアハウスモデリングは業務データモデリングと違う
まず、スタースキーマについて説明する前に、データウェアハウスのモデリングと業務データベースのモデリングは違うということについて強調しておきたいと思います。業務データベースの設計をやっていた人が、データウェアハウスのモデリングでまず驚くのがこの違いです。私も業務データベースの設計をしていたので、データウェアハウスのモデリングを勉強したときはあまりの違いになかなか馴染めませんでした。
ということでまず次を読む前に業務データベースの設計は忘れてください！
データウェアハウスモデリングの極意！スタースキーマ
データウェアハウスのそもそもの目的ってなんでしょうか。そう、データを分析することです。データ分析って何に注目するのでしょうか。それは数字です。例えば、売上高、ウェブサイトのページビュー、会員数などです。データウェアハウスのモデリングはまずこの数字に着目します。モデリング用語ではこれをファクトと呼びます。製品によってはメジャーと呼んだりもします。
では、そのファクト、例えば売上高に着目した時にどうやって分析しますか？例えば、支社別の売上高とか月別の売上高とか顧客別とか、いくつかのまとまりで売上高を見ますよね？これをモデリングではディメンションと呼ぶのです。
そして、データウェアハウスのモデリングではファクトテーブルを真ん中において、それを囲むようにディメンションをリンクします。モデリングのかたちが星形に似ていることからスタースキーマと呼ばれます。
下記に例を示します。下記は売上ファクトテーブルを真ん中にして、それを日付ディメンション、営業所ディメンション、顧客ディメンションでリンクしています。
これにより簡単にGroup byでレポートを作ることができます。実際にサンプルデータで確認して見ましょう。
下記に上のモデリングのサンプルデータとレポートを示します。
レポートでは月別の売上を表示しています。SQLで言えば、SUM関数とGROUP BYで簡単に結果を出すことができます。スタースキーマの強みはなんといってもレスポンスの早さです。ジョインが少ないので、クエリを素早く実行することができます。
簡単な例ですが、以上がスタースキーマのモデリングの概要になります。
次回は階層とスノーフレークについて解説します。
SAP BusinessObjects InfoViewについて
SAP BusinessObjectsの製品にInfoViewという製品があります。
これは、簡単に言ってしまえば、BI portalにあたる製品で、SAP businessObjects製品で作成した
レポートやダッシュボードを公開したりできます。
また、PDFやExcelなどのオフィス製品もアップロードできます。
BI Portalとして、マイクロソフトのShare Pointを利用している企業が多いと思いますが、
SAPに"Integration Option for Microsoft SharePoint"というソフトウェアがあり、
これを利用するとShare PointからInfoviewが見ることができるそうです。
これは、簡単に言ってしまえば、BI portalにあたる製品で、SAP businessObjects製品で作成した
レポートやダッシュボードを公開したりできます。
また、PDFやExcelなどのオフィス製品もアップロードできます。
BI Portalとして、マイクロソフトのShare Pointを利用している企業が多いと思いますが、
SAPに"Integration Option for Microsoft SharePoint"というソフトウェアがあり、
これを利用するとShare PointからInfoviewが見ることができるそうです。
データのセキュリティを考える
＠ITの記事を読んでいて、今問題になっているソニーの個人情報流出に関する記事を見つけました。
http://www.atmarkit.co.jp/fsecurity/rensai/talk20/talk01.html
あまり、情報が公開されていないので、推測で記事が書かれていますが、そこにデータベースのログに関する内容が目に留まりました。
記事にあるとおり、データベースのログは軽視されやすいですよね。
でも、何か起こったときに重要なデータとなります。
データを考える上でセキュリティは重要なテーマですので、今後掘り下げて勉強していきたいと思います。
下記にログ管理に関するガイドラインが公開されています。
http://www.db-security.org/report.html
これを参考に勉強したいと思います。
http://www.atmarkit.co.jp/fsecurity/rensai/talk20/talk01.html
あまり、情報が公開されていないので、推測で記事が書かれていますが、そこにデータベースのログに関する内容が目に留まりました。
記事にあるとおり、データベースのログは軽視されやすいですよね。
でも、何か起こったときに重要なデータとなります。
データを考える上でセキュリティは重要なテーマですので、今後掘り下げて勉強していきたいと思います。
下記にログ管理に関するガイドラインが公開されています。
http://www.db-security.org/report.html
これを参考に勉強したいと思います。
Reporting and Analytics Using SAP BusinessObjectsを読み始めました
Reporting and Analytics Using SAP BusinessObjectsを読み始めました。
英語はやさしく、読みやすいです。
よみおわったら、感想を書きます。
英語はやさしく、読みやすいです。
よみおわったら、感想を書きます。
2011年5月8日日曜日
SAP BW本：SAP NetWeaver Business Warehouse 7.0を読み終わりました
SAP NetWeaver Business Warehouse 7.0を読み終わりました。
本書は、SAP NetWeaver BWの基本的なことにカバーしています。
私はSAP BWの経験はありませんが、本書を読むことにより全体像を理解することができました。
内容としては、SAP BWのデータストア群、ETL,フロントエンドの分析ツールをカバーしています。
英語で書かれていますが、わかりやすく英語がある程度できる人であれば問題なく理解できると思います。
おすすめの本です。
全体像を理解するために一部さらっと読んだので、２回目はしっかり精読していきたいとおもいます。
平行して、注文してほかの２冊も読んでいきたいと思います。
本書は、SAP NetWeaver BWの基本的なことにカバーしています。
私はSAP BWの経験はありませんが、本書を読むことにより全体像を理解することができました。
内容としては、SAP BWのデータストア群、ETL,フロントエンドの分析ツールをカバーしています。
英語で書かれていますが、わかりやすく英語がある程度できる人であれば問題なく理解できると思います。
おすすめの本です。
全体像を理解するために一部さらっと読んだので、２回目はしっかり精読していきたいとおもいます。
平行して、注文してほかの２冊も読んでいきたいと思います。
2011年5月5日木曜日
SAP BW:Data Store Object, DSOって何だ？？？
SAP BWにData Store Objectというのがあります。これってなんでしょうか。
簡単に言ってしまえば、これはデータウェアハウスで利用するステージングエリアやインモンモデルでいうエンタープライズデータウェアハウスに相当するものになります。
データソースのデータをDSOに格納してここでクレンジングしたり、ここで元のデータを保持して、InfoCubeと言われる、キューブでデータを送ったりします。
簡単に言ってしまえば、これはデータウェアハウスで利用するステージングエリアやインモンモデルでいうエンタープライズデータウェアハウスに相当するものになります。
データソースのデータをDSOに格納してここでクレンジングしたり、ここで元のデータを保持して、InfoCubeと言われる、キューブでデータを送ったりします。
SAP BW:InfoObjectsって何だ？？？
SAP BWについて勉強をはじめたので、SAP BWについてちょっとずつ紹介していきたいと思います。
今回はInfoObjectsについて。
SAP BWはすべてアプリケーションでデータも制御します。
そのため、テーブルやデータフィールドなどもそれぞれアプリケーションで定義する必要があるのです。
その最小単位がInfoObjectです。これがテーブルになったり、テーブルのフィールドになったりします。
テーブルになるのは、そのプロパティをONにすることによってテーブルみたいなデータの塊になります。
また、それぞれのフィールドもInfoObjectsなので、テーブルに含めるInfoObjectsとリンクさせたりしながら、
データの塊を作っていきます。
ずっとリレーショナルデータベースをやってきた私にとってはなれるまで大変そうです。
今回はInfoObjectsについて。
SAP BWはすべてアプリケーションでデータも制御します。
そのため、テーブルやデータフィールドなどもそれぞれアプリケーションで定義する必要があるのです。
その最小単位がInfoObjectです。これがテーブルになったり、テーブルのフィールドになったりします。
テーブルになるのは、そのプロパティをONにすることによってテーブルみたいなデータの塊になります。
また、それぞれのフィールドもInfoObjectsなので、テーブルに含めるInfoObjectsとリンクさせたりしながら、
データの塊を作っていきます。
ずっとリレーショナルデータベースをやってきた私にとってはなれるまで大変そうです。
SAP BWとは？
SAP BWについて説明したいと思います。
SAP BWはSAPのData warehouse製品で、製品名はSAP NetWeaver BWとなります。
ほかのBW製品とちがうところは、これ全体でアプリケーションソフトウェアとなっていることです。
BW製品を購入する際に、SQL Severやオラクルなどのデータウェアハウス製品を合わせて選ぶことになりますが、これはSAP BWがバックエンドで使用するデータベースとなります。データはすべてSAP BWによってコントロールされるので、データベースの中身をそのままみたり、SQLを直接実行したりはできません。（SQLの実行はやろうとおもえば、できると思いますが、SAP BWで管理しているテーブル構造になっていますので、直接テーブルを見ても何がなんだがわからない状態になります。）
SAP BWにデータにアクセスする場合は、必ずSAP BWのアプリケーションインタフェースをとおすことになります。SAP BWがすべて制御してくれるので運用は楽になりますが、SAP BWの使用方法および開発方法を覚える必要があります。
SAP BWはSAPのData warehouse製品で、製品名はSAP NetWeaver BWとなります。
ほかのBW製品とちがうところは、これ全体でアプリケーションソフトウェアとなっていることです。
BW製品を購入する際に、SQL Severやオラクルなどのデータウェアハウス製品を合わせて選ぶことになりますが、これはSAP BWがバックエンドで使用するデータベースとなります。データはすべてSAP BWによってコントロールされるので、データベースの中身をそのままみたり、SQLを直接実行したりはできません。（SQLの実行はやろうとおもえば、できると思いますが、SAP BWで管理しているテーブル構造になっていますので、直接テーブルを見ても何がなんだがわからない状態になります。）
SAP BWにデータにアクセスする場合は、必ずSAP BWのアプリケーションインタフェースをとおすことになります。SAP BWがすべて制御してくれるので運用は楽になりますが、SAP BWの使用方法および開発方法を覚える必要があります。
Xcelsius本とSAP BusinessObjects本がとどきました
注文していたSAPプレスのXcelsius本とBusinessObjects本がとどきました。
SAP BW NetWeaver本が読み終わったらこちらを読みたいと思います。
SAP BW NetWeaver本が読み終わったらこちらを読みたいと思います。
2011年5月4日水曜日
SAP BW本：SAP NetWeaver Business Warehouse 7.0の本がとどきました。
注文していたSAP NetWeaver Business Warehouse 7.0が早速アマゾンからとどきました。ぱらぱらとめくってみましたが、図表が多くが非常に良さそうです。早速読んでみたいと思います。
2011年5月3日火曜日
第4回：データウェアハウスアーキテクチャ(3)：データボルトモデリング
今回は、３つ目のデータウェアハウスアーキテクチャ、「データボルトモデリング」について説明します。以前紹介したインモンモデルやキンボールモデルほど有名ではありませんが１つの考えとして重要なアーキテクチャなので紹介したいと思います。
データ統合せずにそのまま格納する
データボルトモデルの特徴を一言で言えば、すべてのオペレーションシステムから来たデータをそのまま保管するモデリングです。そのままデータを保管するところがポイントです。そのまま保管する理由はもし後で使用がかわった場合に元データがあるのでそれをもとに再構築できるからです。また、最近のオーディットの対応としてもデータが追えるという点で非常に優れています。
今までとりあえず、万が一のためにローデータをファイルで保管していた会社は多いと思いますがいざとなったら使わないし、どういうデータ構造になっているかもわからないで有効に活用できていなかったので現状です。
そこで、データボルトモデリングです。これを利用すれば、リレーショナルデータベースに保管できるので、いざというときに利用できます。確かにすべてを保管するとデータ量が多くなりますが近年ハードは安くなっていますし、データの圧縮技術も進化しています。また、データ分散の技術も進化していますので、ある程度大きな会社であれば、これらの問題は解消できると思います。
モデリングの詳細
では、データボルトモデリングについて説明します。データボルトモデリングは次の３つのコンポーネントから成り立っています。それはずばり、Hubs ハブLinks リングSatellites サテライトの３つです。
それでは１つずつ簡単に説明していきます。
Hubsとはデータの大きな固まりを表したものです。例えば、顧客とか店舗などになります。
次にLinksです。リンクはHubsとHubsのリンクを管理するテーブルです。データボルトモデリングは柔軟性を持たせるために普段はERで定義するリレーションをリンクテーブルで定義しています。これにより第３正規形ではテーブルの設計変更が発生する場合でもリンクのデータをかえることにより柔軟に変更に対応できます。
最後にSatellites.これは通常にデータの属性を保持するテーブルです。もちろん、ハブとリンクさせるのですが、１つのHubやlinkはサテライトを複数持つことができます。
例えば、既存システムで顧客情報をマーケティングシステムおよびセールスシステムのそれぞれで持っていれば、データボルトモデリングでは名寄せやクレンジングはせずにサテライトをそれぞれ１つずつ作って、顧客ハブの下にそれぞれもたつことができます。これですべてのデータをそのまま保持できるのです。
まだ、詳しくは調べていませんが、この設計によりETLの処理もある程度パラレルで処理ができるので高速で処理ができるようです。
ビックデータを保持する時代この技術は非常に有効だと思います。
データ統合せずにそのまま格納する
データボルトモデルの特徴を一言で言えば、すべてのオペレーションシステムから来たデータをそのまま保管するモデリングです。そのままデータを保管するところがポイントです。そのまま保管する理由はもし後で使用がかわった場合に元データがあるのでそれをもとに再構築できるからです。また、最近のオーディットの対応としてもデータが追えるという点で非常に優れています。
今までとりあえず、万が一のためにローデータをファイルで保管していた会社は多いと思いますがいざとなったら使わないし、どういうデータ構造になっているかもわからないで有効に活用できていなかったので現状です。
そこで、データボルトモデリングです。これを利用すれば、リレーショナルデータベースに保管できるので、いざというときに利用できます。確かにすべてを保管するとデータ量が多くなりますが近年ハードは安くなっていますし、データの圧縮技術も進化しています。また、データ分散の技術も進化していますので、ある程度大きな会社であれば、これらの問題は解消できると思います。
モデリングの詳細
では、データボルトモデリングについて説明します。データボルトモデリングは次の３つのコンポーネントから成り立っています。それはずばり、Hubs ハブLinks リングSatellites サテライトの３つです。
それでは１つずつ簡単に説明していきます。
Hubsとはデータの大きな固まりを表したものです。例えば、顧客とか店舗などになります。
次にLinksです。リンクはHubsとHubsのリンクを管理するテーブルです。データボルトモデリングは柔軟性を持たせるために普段はERで定義するリレーションをリンクテーブルで定義しています。これにより第３正規形ではテーブルの設計変更が発生する場合でもリンクのデータをかえることにより柔軟に変更に対応できます。
最後にSatellites.これは通常にデータの属性を保持するテーブルです。もちろん、ハブとリンクさせるのですが、１つのHubやlinkはサテライトを複数持つことができます。
例えば、既存システムで顧客情報をマーケティングシステムおよびセールスシステムのそれぞれで持っていれば、データボルトモデリングでは名寄せやクレンジングはせずにサテライトをそれぞれ１つずつ作って、顧客ハブの下にそれぞれもたつことができます。これですべてのデータをそのまま保持できるのです。
まだ、詳しくは調べていませんが、この設計によりETLの処理もある程度パラレルで処理ができるので高速で処理ができるようです。
ビックデータを保持する時代この技術は非常に有効だと思います。
顧客データのデータマッチング方法テクニック
実務でよくある問題に顧客情報のマッチングがあります。例えば、データウェアハウスの構築をした際に複数の業務システムで顧客を管理しており、それを１つのマスターデータとしてデータウェアハウスで管理したい、などです。ほかにも単純にAのデータとBのデータをマッチングしたいという要望もあるかもしれません。
この辺のデータマッチングやクレンジング機能は欧米で発達しました。欧米は英語圏なので日本語の漢字などの問題が非常に少ないので比較的単純にできます。その点、日本語は漢字、全角、半角の問題などあって非常に厄介ですよね。
今回は、簡単にできる顧客データマッチングの方法を紹介したいと思います。
通常データマッチングは、データのクレンジング（フォーマットの統一、全角／半角の統一、漢数字の数字変換など）→データマッチングの順で行います。今回はデータマッチングの部分に的を絞って記載します。
顧客マッチングで利用するデータと言えば、顧客名、住所（郵便番号を含む）、電話番号です。まずはこれをクレンジングします。そのあとのマッチングですが、単純に完全一致にしたり、マッチング条件を緩くしすぎるとマッチング精度に問題ができます。そこで利用するのが、じょじょにマッチング要件を緩くしていく方法です。例えば、AデータとBデータがあったとします。まず、顧客名、住所、電話番号の完全一致でマッチングします。そして、マッチングしなかったAデータとBデータを抽出して今度は、少し緩い条件、例えば、顧客名部分一致、住所、電話番号などにします。そしてその後はさらにマッチングしなかったデータをどんどん条件を緩くしてマッチングしてきます。
この方法であれば、マッチング精度が高いものからマッチングしていくので精度も高くなります。また、実際の方法ですが、Accessを利用して、SQLでマッチングしていけば簡単にできます。マッチングしなかったデータはLEFT JOINやRIGHT JOINでNULLの情報を指定することで抽出できます。
この辺のデータマッチングやクレンジング機能は欧米で発達しました。欧米は英語圏なので日本語の漢字などの問題が非常に少ないので比較的単純にできます。その点、日本語は漢字、全角、半角の問題などあって非常に厄介ですよね。
今回は、簡単にできる顧客データマッチングの方法を紹介したいと思います。
通常データマッチングは、データのクレンジング（フォーマットの統一、全角／半角の統一、漢数字の数字変換など）→データマッチングの順で行います。今回はデータマッチングの部分に的を絞って記載します。
顧客マッチングで利用するデータと言えば、顧客名、住所（郵便番号を含む）、電話番号です。まずはこれをクレンジングします。そのあとのマッチングですが、単純に完全一致にしたり、マッチング条件を緩くしすぎるとマッチング精度に問題ができます。そこで利用するのが、じょじょにマッチング要件を緩くしていく方法です。例えば、AデータとBデータがあったとします。まず、顧客名、住所、電話番号の完全一致でマッチングします。そして、マッチングしなかったAデータとBデータを抽出して今度は、少し緩い条件、例えば、顧客名部分一致、住所、電話番号などにします。そしてその後はさらにマッチングしなかったデータをどんどん条件を緩くしてマッチングしてきます。
この方法であれば、マッチング精度が高いものからマッチングしていくので精度も高くなります。また、実際の方法ですが、Accessを利用して、SQLでマッチングしていけば簡単にできます。マッチングしなかったデータはLEFT JOINやRIGHT JOINでNULLの情報を指定することで抽出できます。
第3回：データウェアハウスアーキテクチャ(2)：キンボールディメンショナルデータウェアハウス
さて、今回はデータウェアハウスアーキテクチャの「キンボールディメンショナルデータウェアハウス」について説明いたします。
ディメンショナルデータウェアハウス
ディメンショナルデータウェウハウスアーキテクチャは、ラルフ・キンボールによって提唱されているアーキテクチャです。ラルフ・キンボールはディメンショナルモデリング、いわゆるスタースキーマモデルを提唱した人で、データウェアハウスのグルの一人として数えられています。キンボールグループの創始者で、キンボールユニバーシティと称して、セミナーを開催しており毎年多くの人が参加しています。
さて、ディメンショナルデータウェアハウスアーキテクチャですが、これは簡単にいってしまえば、ディメンショナルモデリング、つまり、スタースキーマでデータウェアハウスを構築することです。インモンの提唱しているインフォメーションファクトリモデルでは、正規化されたセントラルデータベースがあり、そこから部署向けに作られたデータマートを構築するアーキテクチャですが、キンボールではデータマート自体がデータウェアハウスとなります。
データウェアバスアーキテクチャ
キンボールはこのスタースキーマで構築されたデータマート群を共通のディメンショナルテーブルで結び、それをデータウェアバスアーキテクチャと読んでいます。インモンのセントラルデータベースにあたるデータはステージングエリアで蓄積されるイメージです。
トップダウンとボトムアップアプローチ？
インモンモデルとキンボールモデルを対比して、インモンモデルはトップダウンアプローチ、キンボールモデルはボトムアップアプローチと称されることがあります。確かにインモンモデルは一気に導入、キンボールモデルは必要なデータマートから少しずつ作っていくのに便利ですが、キンボールモデルでもトップダウンで構築することもできます。
インモンモデルとキンボールモデル どちらがいいの？
よく聞かれる質問に、では実際どっちのモデルを採用したらよいのか？というのがあります。難しい質問ですが、どちらかにするかは会社の規模やデータ分析の成熟度によると思います。インモンモデルはどうしても大きなシステムになり、費用がかかってしまうので、小規模な会社の場合はキンボールモデルができしていると思います。
ただ、一般的にはこの両方を取り入れたハイブリッド形式が多いようです。
キンボールアーキテクチャ本
キンボールも多くの書籍を出版していますが、日本語に翻訳されている本は非常に少ないです。現在のところ２冊翻訳されています。
これは有名なディメンショナルモデリングを解説した本ですが、残念ながらすでに日本語版は絶版です。オリジナルはすでに第２版が出ていますので、英語が読める人はこちらを読みましょう。
こちらはWebサイトに特化したデータウェアハウスの構築本です。
次回は、第３のアーキテクチャ「データボルトモデリング(Data vault modeling)」について解説します。
ディメンショナルデータウェアハウス
ディメンショナルデータウェウハウスアーキテクチャは、ラルフ・キンボールによって提唱されているアーキテクチャです。ラルフ・キンボールはディメンショナルモデリング、いわゆるスタースキーマモデルを提唱した人で、データウェアハウスのグルの一人として数えられています。キンボールグループの創始者で、キンボールユニバーシティと称して、セミナーを開催しており毎年多くの人が参加しています。
さて、ディメンショナルデータウェアハウスアーキテクチャですが、これは簡単にいってしまえば、ディメンショナルモデリング、つまり、スタースキーマでデータウェアハウスを構築することです。インモンの提唱しているインフォメーションファクトリモデルでは、正規化されたセントラルデータベースがあり、そこから部署向けに作られたデータマートを構築するアーキテクチャですが、キンボールではデータマート自体がデータウェアハウスとなります。
データウェアバスアーキテクチャ
キンボールはこのスタースキーマで構築されたデータマート群を共通のディメンショナルテーブルで結び、それをデータウェアバスアーキテクチャと読んでいます。インモンのセントラルデータベースにあたるデータはステージングエリアで蓄積されるイメージです。
トップダウンとボトムアップアプローチ？
インモンモデルとキンボールモデルを対比して、インモンモデルはトップダウンアプローチ、キンボールモデルはボトムアップアプローチと称されることがあります。確かにインモンモデルは一気に導入、キンボールモデルは必要なデータマートから少しずつ作っていくのに便利ですが、キンボールモデルでもトップダウンで構築することもできます。
インモンモデルとキンボールモデル どちらがいいの？
よく聞かれる質問に、では実際どっちのモデルを採用したらよいのか？というのがあります。難しい質問ですが、どちらかにするかは会社の規模やデータ分析の成熟度によると思います。インモンモデルはどうしても大きなシステムになり、費用がかかってしまうので、小規模な会社の場合はキンボールモデルができしていると思います。
ただ、一般的にはこの両方を取り入れたハイブリッド形式が多いようです。
キンボールアーキテクチャ本
キンボールも多くの書籍を出版していますが、日本語に翻訳されている本は非常に少ないです。現在のところ２冊翻訳されています。
これは有名なディメンショナルモデリングを解説した本ですが、残念ながらすでに日本語版は絶版です。オリジナルはすでに第２版が出ていますので、英語が読める人はこちらを読みましょう。
こちらはWebサイトに特化したデータウェアハウスの構築本です。
次回は、第３のアーキテクチャ「データボルトモデリング(Data vault modeling)」について解説します。
SAP関連書籍の探し方
SAPは日本でも広くしようされているERPソフトウェアです。
でも、SAPの勉強を独学で勉強しようとすると日本語で読める本が余りません。
ということで、英語で情報を探すことになります。
ではどこを探せばいいのでしょうか。
実はマイクロソフトと同じようにSAPも書籍を出版しています。
そのサイトがSAP PRESSです。
ERP関連からSAP BW, ABAP(SAPで利用するプログラミング言語です)まで様々な本があります。
必要な本はここで探しましょう。
でも、SAPの勉強を独学で勉強しようとすると日本語で読める本が余りません。
ということで、英語で情報を探すことになります。
ではどこを探せばいいのでしょうか。
実はマイクロソフトと同じようにSAPも書籍を出版しています。
そのサイトがSAP PRESSです。
ERP関連からSAP BW, ABAP(SAPで利用するプログラミング言語です)まで様々な本があります。
必要な本はここで探しましょう。
SAP BWの勉強
仕事でSAP BWを使用することになりそうなので、SAP BWの勉強が必要になります。
SAP BWはいままで使用したことがないので、早速書籍で勉強することとにしました。
既にデータモデリングの本を買って読み始めましたが、SAP BWの基本がわからないのでなかなか進みません。
ということで、SAP BWの基本的な本を購入することとしました。
また、合わせて、Business objectsとダッシュボード（Xcelius）本も注文しました。
明日くらいにはとどく予定です。
今回のゴールデンウィークはSAP BWの学習ウィークとなりそうです。
SAP BWの情報もなかなかネットで見つけることができないので、このブログで勉強したことをどんどん紹介していきたいと思います。
注文したのは下記本です。SAP PRESSの本なので、信頼性も高いと思います。
なんといっても私は本のデザインがとても好きです。かっこいい。
SAP BWはいままで使用したことがないので、早速書籍で勉強することとにしました。
既にデータモデリングの本を買って読み始めましたが、SAP BWの基本がわからないのでなかなか進みません。
ということで、SAP BWの基本的な本を購入することとしました。
また、合わせて、Business objectsとダッシュボード（Xcelius）本も注文しました。
明日くらいにはとどく予定です。
今回のゴールデンウィークはSAP BWの学習ウィークとなりそうです。
SAP BWの情報もなかなかネットで見つけることができないので、このブログで勉強したことをどんどん紹介していきたいと思います。
注文したのは下記本です。SAP PRESSの本なので、信頼性も高いと思います。
なんといっても私は本のデザインがとても好きです。かっこいい。
2011年5月1日日曜日
第2回：データウェアハウスアーキテクチャ(1)：インモンのコーポレートインフォメーションファクトリー
今回から3回にわたって、データウェアハウスのアーキテクチャについて説明します。
データウェアハウス業界では昔からアーキテクチャについて大きく２つのグループに分かれており、どちらのアーキテクチャモデルがよいかが争っています。その２つのグループはインモンが提唱する「コーポレートインフォメーションファクトリー」とキンボールが提唱する「ディメンショナルデータウェアハウス」の2つです。本コラムでは、この２つのアーキテクチャモデルともう１つ有力な：データボルトマネジメントモデルの３つについて紹介いたします。
今回はインモンの「コーポレートインフォメーションファクトリー」について説明します。
コーポレートインフォメーションファクトリー
コーポレートインフォメーションファクトリーとは、データベースの父と言われるビル・インモンが提唱したアーキテクチャの構造です。では、どのようなアーキテクチャかというと、エンタープライズデータウェアハウスという企業のすべてのデータを集めたセントラルデータベースを構築し、そこから各部署で分析に必要なデータをデータマートとして、抽出、構築して分析はそのデータマートに対して分析をおこなうというものです。
エンタープライズデータウェアハウスは、通常のデータベース設計で使用される正規化を利用して構築されます。クエリパフォーマンスが悪くなるためこちらでは直接分析クエリの実行は行いません。データマートは、非正規化し、データウェアハウスの分析に適したディメンショナルモデリングで構築を行います。ディメンショナルモデリングについては第５回〜第９回で詳細に説明を行います。
データウェアハウス 2.0
また、最近インモンはデータウェアハウス2.0を提供しています。2.0を利用するのは、Web 2.0の影響でずいぶんはやりましたね。では、データウェアハウス2.0はインフォメーションファクトリーとどう違うかというと、全体では大きな違いはありません。大きな特徴と言えば、メールやWeb、ツイッターのつぶやきなどの非構造化データを考慮していることでしょう。企業にとって、このような非構造化データの分析はますます重要になってきています。まだ、企業での需要はそんなに多くないようですが、今後データウェアハウスの構築の際に考慮が必要になってくると思います。
うれしいことにインモンの本については日本語版があります。より詳しい内容を知りたい人は下記の本を読むことをお勧めします。
ただ、上記の本は出版されてから年月がかなり経っていますので、英語が読める人は下記のインモン本をお勧めします。
データウェア2.0を知りたい人はこちら。
データウェアハウス業界では昔からアーキテクチャについて大きく２つのグループに分かれており、どちらのアーキテクチャモデルがよいかが争っています。その２つのグループはインモンが提唱する「コーポレートインフォメーションファクトリー」とキンボールが提唱する「ディメンショナルデータウェアハウス」の2つです。本コラムでは、この２つのアーキテクチャモデルともう１つ有力な：データボルトマネジメントモデルの３つについて紹介いたします。
今回はインモンの「コーポレートインフォメーションファクトリー」について説明します。
コーポレートインフォメーションファクトリー
コーポレートインフォメーションファクトリーとは、データベースの父と言われるビル・インモンが提唱したアーキテクチャの構造です。では、どのようなアーキテクチャかというと、エンタープライズデータウェアハウスという企業のすべてのデータを集めたセントラルデータベースを構築し、そこから各部署で分析に必要なデータをデータマートとして、抽出、構築して分析はそのデータマートに対して分析をおこなうというものです。
エンタープライズデータウェアハウスは、通常のデータベース設計で使用される正規化を利用して構築されます。クエリパフォーマンスが悪くなるためこちらでは直接分析クエリの実行は行いません。データマートは、非正規化し、データウェアハウスの分析に適したディメンショナルモデリングで構築を行います。ディメンショナルモデリングについては第５回〜第９回で詳細に説明を行います。
データウェアハウス 2.0
また、最近インモンはデータウェアハウス2.0を提供しています。2.0を利用するのは、Web 2.0の影響でずいぶんはやりましたね。では、データウェアハウス2.0はインフォメーションファクトリーとどう違うかというと、全体では大きな違いはありません。大きな特徴と言えば、メールやWeb、ツイッターのつぶやきなどの非構造化データを考慮していることでしょう。企業にとって、このような非構造化データの分析はますます重要になってきています。まだ、企業での需要はそんなに多くないようですが、今後データウェアハウスの構築の際に考慮が必要になってくると思います。
うれしいことにインモンの本については日本語版があります。より詳しい内容を知りたい人は下記の本を読むことをお勧めします。
ただ、上記の本は出版されてから年月がかなり経っていますので、英語が読める人は下記のインモン本をお勧めします。
データウェア2.0を知りたい人はこちら。
登録:
投稿 (Atom)