2011年10月15日土曜日

おすすめのデータモデリング本

皆様、お久しぶりです。いい訳ですが、なにかと忙しくブログの更新がしばらくストップしておりました。
いろいろと書きたいこともたまってきたので、これからまた頻繁に更新していきたいと思います。

さて、今回はおすすめのデータモデリング本についてです。

アプリケーションについて、要件をまとめたり、設計したりするに、データモデリングを読んで、書ける技術は必須であると考えています。現在、勤務している会社でも、このデータモデリングに関する基礎がない人がいて困っています。しかも、基礎がないことを自覚していないため、議論をしても話がぶれて、ぶれて非常に大変な思いをしています。たとえば、論理設計や物理設計の意味もよくわからないため、論理設計の話をしているときに、物理設計の話を持ち込んだりしています。

そのため、データモデリングのスキルは、業務に非常に影響しますので、データ設計、分析をする人はもちろん、プロジェクトマネージャ、ITマネージャ、開発者まで基礎はきちんと押さえてもらいたいです。

今回は、そのデータモデルを基礎からしっかり勉強できる本を紹介したいと思います。
その本とは、Setve Hobermanによる「DATA MODELING MADE SIMPLE」です。


これは、英語の本で、日本語訳は私の知るところ、まだ出ていないようです。
まずなんといっても、表紙がシンプルでかっこいいです。

また、内容も平易に書かれており、易しい英語で書かれているので非常に読みやすいです。
この本の良いところは、概念設計、論理設計、物理設計に分けて易しく解説しているところです。

この本一冊で、データモデリングを全くしらないレベルから、基礎をしっかり学ぶことができます。
また、ディメンショナルモデリングについても解説しているところもいいですね。

これから、データモデリングを勉強したい人、復習をしたい人にぴったりの本です。
私も日本で書かれたデータモデリング本を結構読んできましたが、その中で一番の本だと思います。
やっぱりデータモデリングの本場は違うなーと感じてしまいました。
日本語訳が出ることを期待します。

ぜひ、読みましょう!!!

2011年7月19日火曜日

新しいSAP BW本、BusinessObjects BI4.0本を予約注文

買う予定であった下記の本を本日予約注文しました。
両方とも発売日が年末なので、まだまだですが、忘れずに予約しました。

SAP NetWeaver BW and SAP BusinessObjects
SAP BusinessObjects BI 4.0 The Complete Reference 3/E

SAP BusinessObjects Web Intelligence 値のリスト選択について

SAP BusinessObjectsのWeb Intelligenceにおいて、クエリの設定画面で
条件をしてすることができます。条件指定の際、フィルタリングをかける条件を定数や値のリスト一覧から指定できる機能があります。

Web Intelligenceをしばらく触っていなかったので、復習のためいろいろといじってみました。
その際、条件指定において、リスト一覧がグレイアウトされており、一覧から指定することができませんでした。

以下になぜ、値を一覧から指定できなかったのか記載しておきます。

理由はとても簡単で実は、データアクセスを設定するUniverse側で値の一覧を出すかどうか指定されているのです。
一覧から値が指定できなかったのは、Universe側で単に禁止していたからのでした。
禁止を解除するには、Universe側でオブジェクトを右クリックし、値が指定できるようにチェックしておく必要があります。

SAP BusinessObjectsのETLツール Data Integrator

どうやら現在かかわっているプロジェクトでETLツールとして、SAP BusinessObjectsのData Integratorを利用するようです。

ということで、早速情報収集。

まずは概要資料。
http://www.datamotive.be/sites/default/files/files/BusinessObjects-Data-Integrator.pdf


あとDesigner Guide
http://help.sap.com/businessobject/product_guides/boexir4/en/sbo401_ds_designer_en.pdf
Tutorial
http://help.sap.com/businessobject/product_guides/boexir4/en/sbo401_ds_tutorial_en.pdf


Data Integratorのトレーニングは受講する予定ですが、こちらでちょっと勉強しておきたいと思います。

EMCのGreenPlum

Hadoopを製品に利用しているEMCのGreenPlumに関する記事です。
チェックを。
EMCに訊く、「企業がHadoopを使うためにすべきこと」

オンラインでのデータ分析

TEchCrunchの記事で、下記の記事を見つけました。

Wondergraphs:データ分析およびレポート作成作業を楽しくかつセクシーにしてくれるオンラインサービス

オンライン上でグラフなどが作成できるらしいです。

MySQLを完全オンメモリ化したMemSQLが資金を調達

MySQLを完全オンメモリ化したMemSQLが資金を調達したらしいです。
通常のMySQLと比べると30倍のスピードになるらしい。

メモリが安くなったこともあって、現在はメモリで運用し、HDDでバックアップを取る企業が多いですよね。

注目したい企業ですね。
MySQLを完全オンメモリ化(スピード30倍)したMemSQLが$2.1Mのシード資金を調達

2011年7月14日木曜日

プレゼンテーション!

その昔、システムエンジニアなどの技術職は1日中机に座ってプログラムを開発しているイメージがありました。しかし、実際は大きく違ってユーザや顧客などとのコミュニケーションに多くの時間を費やす必要があります。

最近では技術者もプレゼンテーション技術が問われます。私もなんどかプレゼンする機会があります。でもなかなか上達するのは難しいんですよね?

そんななか@ITを眺めていたら、下記のプレゼンテーションのコラムを見つけました。
なるほど、なるほどという内容が満載です。

ぜひ参考。私もこの内容を実践してプレゼンの腕を磨きたいと思います。

http://www.atmarkit.co.jp/fjava/column/andoh/andoh57.html

SAP BWでSlowly Changing Dimensionはどうやって実現するのか?

BI/Data warehouseの構築に欠かせないスタースキーマと呼ばれるディメンショナルモデリング。そのディメンショナルモデリングに必須のテクニックがSlowly Changing Dimensionです。Slowly Changing Dimensionとは、ディメンションの履歴の取り方のテクニックのことです。
詳細は下記をご覧ください。
Slowly Changing Dimension

このSlowly Changing Dimensionはリレーショナルデータベースを利用する際jに使用するテクニックです。リレーショナルデータベース内でスタースキーマを作成し、ETLツールを利用してSlowly Changing Dimensionの各タイプについて管理します。

では、このSlowly Changing Dimensionですが、SAP BWではどうやって実現するのでしょうか。SAP BWはデータウェアハウスに必要なアプリケーションがすべて1つになったパッケージ製品です。データベースはアプリケーションで隠されているので、SAP BWのシステムインタフェースを使用してデータベースなどを定義していく方法をとります。
そのため、通常のSlowly Changing Dimensionのテクニックが使えないのです!

では、SAP BWではそもそもSlowly Changing Dimensionに似た運用ができるのでしょうか。それともできないのでしょうか。。。。。

テレビであれば、続くとなるか、コマーシャルとなる部分ですが、以下私が現在調べた限りの内容を記載します。


結論からいうと、Slowly Changing Dimensionと全く同じではありませんが、結果的に同じような管理がSAP BW内でできます。

SAP BWでは、各データの属性単位で設定を定義していくのですが、その際にTIme dependent または Time independentデータにするかどうかを指定することができます。厳密には、Time dependentにする場合はチェックを入れるかたちとなります。Time dependentとは、つまりデータが更新されるたびにFrom data, To dateで履歴をとるということです。そのため、Time dependentにチェックを入れておけば、SAP BWが自動的に履歴をとってくれるのです。

SAP BWでは、InfoCubeと呼ばれるキューブがあるのですが、そのキューブはExtended star schemaと呼ばれる構造をとります。通常のスタースキーマはパフォーマンスのためにある程度非構造化してデータを作成するのですが、このExtended Star schemaはディメンション部分を正規化しており、柔軟な構造になっています。

そのため、Time dependentにチェックをいれば、スタースキーマでもfrom, toで履歴を持った状態でデータを保持するのです。そういった構造であるため、レポートを作成する時に発行するクエリにどの履歴をしようするかをkey dateという名前で指定することができます。このkey dateを上手に利用することによりslowly changing dimensionと同じテクニックを実現することができるのです。

でも、ここで問題が発生です。通常のディメンショナルモデルは、パフォーマンスを向上させるためにシンプルなスタースキーマになっています。しかし、SAP BWのInfoCubeでは構造化しているため多くのジョインが発生し、パフォーマンスが大幅に劣化します。それにより、どうやらSAP BWはパフォーマンスに特に注意する必要がありそうです。

パフォーマンスの向上方法としては、現在は、BWAやHANAなどのインメモリデータベースを利用することができますので、これを利用することにより大幅にレポートパフォーマンス改善することができます。ただし、高いです。

あとは、インデックスやパーティションなどでパフォーマンスを改善できますがこれには限界がありますね。そのためデザイン時にパフォーマンスに注意して設計する必要があるそうです。

2011年7月13日水曜日

SAP Business Explorer

技術メモです。

SAP BWにアクセスツールにBusiness Explorer 通常Bexと呼ばれるツールがあります。
SAP BWのInfoCubeなどのInfoProviderにアクセスするにはこのツールが必要となるようです。

下記に詳細情報があります。
http://help.sap.com/saphelp_nw73/helpdata/en/5b/30d43b0527a17be10000000a114084/frameset.htm

Bexには下記のツールがあります。
BEx Query Designer
BEx Web Application Designer
BEx Broadcaster
BEx Analyzer

SAP BW modelプレゼンテーション

SAP BWのデータモデリングに関するすばらしい資料を見つけました。
SAP BWのデータモデルについてわかりやすくまとまっています。
英語の資料となります。
日本語の資料がなかなかないですね。

http://www.slidefinder.net/s/sap_data_modeling_techniques_data/9442191

Hadoop 第2版日本語版いよいよ発売

Haddopの第2版の日本語版がよいよい7月23日に発売になります。
まだ、買おうがどうか迷っています。
http://www.oreilly.co.jp/books/9784873115030/

SAP NetWeaver BW: Administration and Monitoringを読む

SAP BWの管理本「SAP NetWeaver BW: Administration and Monitoring」を
読みました。と言っても今までSAP BWを管理したことがありませんし、まだ触ったこともないので読んでみてもふーんといった感じでした。
そのため、今回は全体像を把握することを目的にSAP BWの管理項目としてどんなことができるかといったことがなんとなくわかるように
ところどころ飛ばして読みました。

さらっと読んだだけですが、SAP BWのパフォーマンスやインデックスなどにも触れらていて非常によい本だと思います。

SAP BWの勉強がもっと進んだら再び本書に戻りたいと思います。

次は、SAP BWのレポート関連の書籍を読む予定です。一応、下記の本を予定しています。すでに本は購入済みです。

Inside SAP BusinessObjects Advanced Analysis
SAP NetWeaver BW 7.x Reporting ? Practical Guide

データベースのインデックスについて

SAP BWの管理本を読んでいたら、データベースのインデックスに関する話が出てきました。
データベースについてはしばらくご無沙汰していたので、ウェブサイトでちょっとインデックスについて復習してみました。

やっぱりWikipediaのサイトがわかりやすかったです。
索引 (データベース)


また、どのインデックスを使用するかで考えなければいけないのがカーディナリティですね。
カーディナリティの説明は下記のサイトがおすすめです。

カーディナリティとは

2011年7月12日火曜日

SAP BusinessObjects Universeって何だ?

SAP BusinessObjectsのWeb Intelligenceを使用するときにUniverseの選択があります。
では、Universeってなんでしょうか。これは、BusinessObjectsが盛んに宣伝していたセマンティックレイヤーと
いうもので簡単に言ってしまえば、Web Intelligenceなどでアクセステーブルやテーブルのリンクを定義する階層です。

Universeを定義するには、Universe Designerというツールを別途使用する必要があります。

続SAP BusinessObjects Web Intelligence本

アマゾンで、Web Intelligence本を探していたら、以下のトレーニング本を見つけました。

SAP BusinessObjects Web Intelligence XI 3.1 Training Course
SAP BusinessObjects Web Intelligence XI 3.1 Exercises and Answers
http://www.webiworx.com/index.html

中身が見れなかったので、詳細は分かりませんが、サイトを読む限り、Web Intelligenceの必要機能について分かりやすく説明して
あるようです。また、練習と回答本を購入すれば、かなり独習ができそうです。
購入を考えましたが、すでにWeb Intelligence本を購入しているのと、バージョンがXI3.1なので、購入は見送ることに
しました。
Web Intelligence本を購入している人はこちらも候補の1つに入れることをお勧めします。

SAP BusinessObjects Web Intelligenceとは?

今回は、SAP BusinessObjects Web Intelligeceについて説明します。

SAP BusinessObjects Web Intelligeceとは?

Web Intelligenceとは、SQLなどのテクニカルスキルなしに定型レポート、アドホックレポート、データ取得ができる
Webベースのツールです。

Web Intelligenceには、2つの段階があります。
まず、接続したテーブル群を選びます。接続するテーブル群は、予めUniverse Designerというツールで
定義して必要があります。接続したいテーブル群(Universeと呼ばれます)を選んだあと、ドロップアンドドロップで取得したいデータを定義します。
ドロップアンドドラッグで選んだ内容に応じて、SQLを自動生成します。また、自分でSQLを編集、定義することもできます。

その次は、定義したクエリーを実行し、それを一覧やグラフなどで定義するフェーズです。単純なリストから棒グラフなど様々なテンプレートが容易されていますので
これもドラッグアンドドロップで簡単に作成することができます。また、フォーマットを変えたり、計算を追加したりといったこともできます。

まとめると、
フェーズ1:クエリーを定義する
フェーズ2:見た目を定義する

となります。

さらにすごいのが、同一のテーブル群(Universe)に別々のクエリを定義して、1つのレポートに表示することができます。
また、全く違ったテーブル群も1つのレポートに表示することもできます。さらに、違ったテーブル群をさらに結合して1つのテーブル群として
レポートに表現することもできます。

すぐれたツールのようですが、1つ問題点があります。それはパフォーマンスです。データ量が少なかったり、シンプルなテーブル構造であれば問題ないのですが、
データ量が多かったり、テーブル結合が多いとパフォーマンスが悪化します。
この辺は、サマリーテーブルやシンプルなテーブル構造にするなどの対応が必要になります。

ネティーザやテラデータなどの専用DWHを使えば、レスポンスが早くなるので、こういったアプライアンスを使用するのもおすすめです。

楽天証券はExadataを選択

楽天証券が自身のシステムにExadataを採用したとのことです。とってもデータウェアハウスでの利用ではなく、OLTPでの利用です。消費電力だけで年間約5000万円節約できるとのことです。すごいですね。

ぜひチェックを。

http://enterprisezine.jp/article/detail/3307

やっぱりBIが熱い?

DB onlineというサイトにDBプロに会いたい!というコーナーがあり、DBプロフェッショナルのインタビューを掲載しています。その連載の中のインサイトテクノロジー 代表取締役社長の小幡一郎氏のインタビューで、今後はDWH分野で面白い展開ができるという記載がありました。

やっぱりBI/DWHは今後ますます熱くなりますね。オープンソースBI Pentahoにも言及がありました。

ぜひチェックを。

http://enterprisezine.jp/article/detail/3291

ウルシステムズ漆原氏のインタビュー

ウルシステムズ株式会社と株式会社イーシー・ワンが経営統合を発表しました。
それに関して、ウルシステムズの漆原氏のインタビューが下記に掲載されています。

http://enterprisezine.jp/article/detail/3289

インタビューにおける日本のSIerの体質については私も同感です。

日本のSIerが今後かわることを期待します。

ぜひ、チェックしてみてください。

2011年7月11日月曜日

SAP BWトレーニング

今まで独学でSAP BWの勉強を進めていましたがSAP BWのトレーニング許可が下りましたので8月よりじょじょに受講する予定です。既にある程度書籍によって独学しているので、不明な点を確認していきたいと思います。

でもやっぱりSAP BWのトレーニングは高いですね。

SAP BWトレーニング

SAP NetWeaver BW: Administration and Monitoring

BusinessObjectsのWeb Intelligence本を読み終わったので、次はSAP BW本である「SAP NetWeaver BW:Administration and Monitoring」を読んで見たいと思います。既に購入済みですので、早速明日から通勤電車の中で読み進めたいと思います。

おそらく、通勤電車の中でSAP PRESSの分厚い本を読んでいるは私だけですよね。(笑)
でもこれが結構はかどるんですよ。まあ、結構運ぶのは重いですが。。。
本の表紙がかっこいいので、ちょっと知的に見えるかもしれません。

SAP NetWeaver BW: Administration and Monitoring

SAP BusinessObjects Web intelligence本を読了

勉強するにもマイブームがあります。現在は、プロジェクトでフロントエンドツールについて調べているのでBusinessObjects関連のツールを勉強するのがマイブームです。

ということで、早速現在購入し、読むのが止まっていた「SAP BusinessObjects Web Intelligence」を読みました。Web Intelligenceの一通りの機能が網羅されており、SDKなどのマニアックな情報も載っていました。これ一冊あればWeb Intelligenceについてひとおり勉強できるのではないでしょうか。BusinessObjectsは勉強したけど、もう一度勉強したい人、またBusinessObjectsは使っているけど、トレーニングは高いので書籍で勉強したい人などにおすすめです。

問題は英語でしか読めないというところでしょうか。ちなみに取り扱っているバージョンはXI3.xです。

英語が読める人にはおすすめのWeb Intelligence本です。

SAP BusinessObjects Web Intelligence

BIレポートと業務レポートは分けて考えましょう!

BI/Data warehouseの要件定義段階でほしいレポートや分析について議論すると
思いますが、そこで1つ注意したいのが、BIレポートと業務レポートを分けて考える必要があるということです。

ユーザはとにかく、ほしいレポートを要求してきますので、それがBIレポートなのか、業務レポートに該当するのか
その都度考えましょう。

では、そもそもBIレポート、業務レポートの違いってなんですか。
簡単にいってしまえば、業務レポートは業務を運用する上で必要になるレポートです。
たとえば、注文の明細だったり、まだ支払いをしていない顧客の一覧などです。

BIレポートは、データを分析してその後のアクションにつなげるレポートです。
たとえば、売上レポートなんかがそうですね。

では、なぜわけて考える必要があるのでしょうか。

それは、BIレポート、業務レポートの違いによって、基本的にレポートを出すソースシステムおよびデータモデルが
異なってくるからです。

BIレポートであれば、データウェアハウスのスタースキーマから出す必要があります。
また、業務レポートであれば、業務システムから出力するか、またはデータウェアハウスであれば、
エンタープライズデータウェアハウスなどから出力したほうが良いでしょう。
また、その時のデータモデルは、通常のデータモデルつまり正規化されたデータモデルになります。

このように、レポートの種類によって、レポートを出力する場所がわかってきますので、注意しましょう。

もちろん、例外ありますので注意を。。。

ユーザとのコミュニケーションにスタースキーマを利用しよう

BI/Data warehouseのプロジェクトで困るのが、ユーザとシステムの仕様について
どのようにコミュニケーションするかです。

ユーザには少なくともシステム要件についてレビューしてもらう必要がありますし、UATもあります。
でも、テクニカルスキルがないユーザにとってITが話す言葉はちんぷんかんぶんですよね。

そこでお勧めしたいのが、スタースキーマによるユーザとのコミュニケーションです。
確かにデータについて全くわからないユーザにスタースキーマを教えるのは大変だとは思いますが、
業務システムのデータモデルなんかに比べれば、数段理解しやすいのではないでしょうか。

また、スタースキーマでレポートなんかも作成も考えると頭が整理されて便利です。

ぜひ、スタースキーマを使いましょう。

SAP BW/BusinessObjects関連の注目ブログ

SAP BW/BusinessObjectsに関連する役立つブログを発見したのでご紹介。

http://www.hackingsap.com/blog/

書籍情報なんかも掲載されていて、非常に便利です。

ぜひ、チェックを。

SAP BW/BusinessObjects関連購入予定の書籍

現在かかわっているBI/Data warehouseのプロジェクトでバックエンドにSAP BW,フロントエンドのレポーティングツールとして
BusinessObjectsを利用する予定です。

すでに掲載してあるとおり、ある程度の関連書籍は購入しているのですが、実際使用するBusiness Objectsが、最新バージョンのBI 4.0であるため
下記の書籍を追加購入する予定です。
まだ、出版されていない書籍もあるので、とりあえずアマゾンで注文しておきたいと思います。

SAP BusinessObjects BI 4.0 The Complete Reference 3/E
SAP NetWeaver BW and SAP BusinessObjects
SAP BusinessObjects Dashboards 4.0 Cookbook

2011年7月9日土曜日

BI/Data warehouseの要件定義について

 今回はBI/Data warehouseの要件定義について考えてみたいと思います。現在、仕事でBI/Data warehouseの新しいプロジェクトに携わっています。利用する製品などの選定が終わり、いよいよユーザ要件の定義に入るところです。

 要件定義は誰がやる?

 では要件定義は一体誰がやるがいいのでしょうか。コンサルタントでしょうか。それとも情報システム部?ユーザでしょうか。誰がやるという議論の前に要件定義のフェーズを2つに分けてみたいと思います。それは、まさにユーザによる要件定義とそれをシステムに置き換えたシステム要件の2つです。
 私のおすすめの役割分断は、

ユーザの要件定義→ユーザが主導でまとめる

システム要件→情報システムまたはITコンサルタントが主導でシステムで実現できるように要件に変換

システム要件の承認→ユーザ主導でシステム要件について現場にコミュニケーション、承認を得る

ユーザ要件定義に非常な情報は?
 では、ユーザ要件をまとめる上で必要な情報とはなんでしょうか。最低限下記の情報が必要だと思います。

・分析対象名またはレポート名
・分析、レポートの目的
 利用する部署が複数の場合は、部門ごとに目的を記載
・分析に必要なデータ期間 例:3年分
・分析に必要なファクト(数値)項目
 トランザクション、スナップショットのどちらかの記載
 計算ロジックの記載
・分析に必要なディメンション項目
 履歴の分析方法(Slowly Changing Dimension)
 階層
・レポートレイアウト

ユーザのスキルをアップさせる!

 上の要件定義の項目を見ていただければわかりますが、要件をまとめる上で、ファクト、ディメンションなどについて理解している必要があります。また、ディメンションの階層やSlowly Changing Dimensionの概念については理解している必要があります。この辺のスキルがあるユーザであればいいのですが、たいていはこの辺を意識せずに仕事をしていることが多いので、情報システム部門またはITコンサルタントがユーザに非常なスキルを教育する必要があります。適当な外部研修などはありませんので、社内で資料を作ってトレーニングをやる必要があります。

 現在私のプロジェクトでも要件定義に入るまでの準備を進めています。まずは、各フェーズで必要な成果物(ドキュメント)を定義しました。その後、その成果物を誰が中心でまとめるか、つまり役割と責任についてまとめ、ユーザチームに説明を行います。ユーザチームと「役割と責任範囲」について合意がとれた後で、ユーザに対するトレーニングを行います。今回のプロジェクトではBIスキルがないユーザがほとんどですので、現在トレーニング資料について考慮中です。分析スキルをわかりやすく説明するのは結構たいへんですね。しかし、ここをしっかりやって行いと要件定義がぐちゃぐちゃになってしますので、しっかりやりたいと思います。

2011年6月29日水曜日

MySQLを極めようか

技術が大事とか言っておきながら、自分の技術力も大したことないです。
これじゃ、だめですよね。
ということで、一念発起してオープンソースのMySQLを極めたいと思います。

下記書評を読んで、「MySQL 5.1 Plugin Development 」という本がよさそうのなので、
手始めに読んでみたいと思います。

[書評]MySQLをハックしまくりたい人のためのスゴ本「MySQL 5.1 Plugin Development」

MySQL本は、オライリーから結構出ているのでこちらも読んでみたいと思います。

SAP BWのETLツール

SAP BWは、DWHに必要なツールがすべてそろったパッケージ製品です。
当然、ETLにあたるツールも含まれています。
しかし、ソース元がSAPのERPである場合は、付属のETLツールで問題ないのですが、
SAP BWのETLは通常のETLツールと比べて機能が弱いので、データウェアハウスのソースがSAP ERP以外の
場合は、別のETLツールを利用したほうがよいと思います。

安価にすませたいということであれば、オープンソースのETLツールでもよいと思います。
また、ベンダー製品ということであれば、MicrosoftのSQL Sever Integration Servicesも
よく利用されています。
SAP製品ということであれば、買収したBusinessObject製品の流れをくむData Integratorというツールが
あります。これは、メタデータマネジメントというツールを一緒に利用するとインパクト分析なんかもできるで非常に良いツールだと思います。

Pentaho バージョン4.0のベータ版

Pentaho バージョン4.0 RC版が出たらしいです。
ぜひ、チェックを。
Pentahoバージョン4.0RC(ベータ)版、エンドユーザー向け機能が大幅強化!

Database Watch 2011年6月版

毎月楽しみにしている@ITのDatabase Watch。
今月は、IBMとSQL Severについてでした。

ぜひ、チェックを。
http://www.atmarkit.co.jp/fdb/rensai/dbwatch2011/dbwatch201106_01.html

ストレージも進化しているんですね。

@ITにストレージについて下記の連載コラムがあります。

ストレージ仮想化の体系的理解


この記事も読むとストレージも日々進化しているんですね。

データウェアハウスの高速化にはストレージの選択も非常に重要なので、
記事の内容が非常に参考になりました。

やっぱり技術力は大事ですよね

データウェアハウス関連の下記の記事を読んでいたら、
日本のIT部門ではマネジメントやプロジェクト管理に重きがおかれて、
ソースを読んだり書いたりする能力があまりないという話が出てきました。
IT部門の技術力がどんどん衰退しているらしいです。

私も全くのそのとおりだと思います。
私が所属しているIT部門は外資系ではありませんが、技術力を持った社員はほとんどいません。
しかも、技術を学ぶ気もあまりないようです。
プレゼンテーション能力やプロジェクトマネジメントだけが注目され、口がうまい人が出世していくようです。
技術力がないから、ベンダーのうそが見抜けなかったりと弊害も出ています。

プロジェクト管理なども大事ですが、技術も大事ですよね。

データウェアハウス戦国時代に思うこと(後編)/そろそろITで儲けようじゃないか

2011年6月23日木曜日

OpenOLAP,OpenStaging

このサイトでは、何度かオープンソースBIを紹介してきたが、すべてが海外製品でした。
では、日本にBIオープンソースがないかということそんなことありません。
アイエイエフコンサルティングが開発した、OpenOLAPとOpenStagingという製品があります。
前からこの製品については知っていたのですが、なぜか紹介が遅れてしまいました。

OpenOLAPが、OLAP製品で、OpenStagingがETLツールとなります。
データベースには、PostgreSQLとMySQLが使用できるようです。

動作するOSは、Linuxのみのようです。Windows版があると普及がいっきに進みそうですが。。。

下記サイトでデモを見ることができます。
http://www.golap.biz/index.html

また、NRIが、オープンソース・サポートサービスOpenStandiaの対象商品として、
サービスを提供しています。
興味のある方は下記をチェック。
http://openstandia.jp/services/openolap/index.html

2011年6月22日水曜日

ETLのドキュメント

 データウェアハウス/BIに限らず、ソフトウェアを作成する上で、ドキュメント作成は非常に重要です。
重要といっても、最も軽視されるもドキュメントの宿命です。

 さて、今回は、ETLを作成する上でのドキュメントについて書いてみたいと思います。
最近のETLツールには、ドキュメント自動生成する機能がありますので、そちらを利用するのは非常に良いことだと
思います。しかし、通常、これは作成したETLがべースになっており非常に詳細な情報になってしまうので、
全体像がわかるハイレベルのフローを作成することをお勧めします。

 また、ETLは、スタースキーマなどと密接に絡み合っているので、そちらとも連携もわかるドキュメントが必要です。

 必要最低限のドキュメントは、保守を軽し、変化につよいシステムをつくります。

 プロジェクトを始める前にどのようなドキュメントが必要かしっかり検討しましょう。

インメモリOLAPデータベース Palo

以前、オープンソースのBI製品としてPaloを紹介しましたが、
ちょっと調べた内容を掲載したいと思います。

PaloはインメモリOLAPデータベースで、データをすべてメモリに展開します。
MicrosoftのPower Pivotみたいな感じでしょうか。

 メモリに展開したデータは、Excelのアドインを利用してアクセスすることができます。

 また、PentahoのETLツール、Kattleは、Paloのキューブにアクセスしてデータを
読み込んだり、書き込んだりできるようです。

 トリビアですが、Paloの名前の由来は、Paloを逆から読むとわかるそうです。

オープンソースBIソフトウェア SpagoBI

オープンソースBIソフトウェアと言えば、PentahoやJasperSoftが有名ですが、
その他にSpagoBIというものがあります。

SpagoBI


勉強不足のため、今までこのようなソフトウェアがあるのを知りませんでした。。。

Webサイトの説明を読むと、Report,OLAP,ETLなど様々なオープンソースソフトウェアが組み合わさってできているようです。
http://www.spagoworld.org/xwiki/bin/view/SpagoBI/TheSuite

今後も注目したい製品ですね。

オープンソース OLAP Mondorian

オープンソースのOLAPにMondorianというOLAPソフトウェアがあります。
全く名前を聞いたことがない人もいるかもしれませんが、オープンソースBIでは、デファクトスタンダードとなっています。
オープンソースBIで有名なPentaho, Jaspersoft, SpagoBIはすべてこのMondorianを使用しているのです。

 ちなみにMondorianは、ROLAP型となります。ROLAPとは、クエリが発生するごとにデータをリレーショナルデータベースに取得しにいく方式となります。

MySQLに関する記事

 MySQLは、オラクルに買収されて死んでしまったと思っているあなた。(私もそう思っていました。)
下記の記事をどうぞ。
MySQLはOracleに救われた―松信嘉範氏

SAP BusinessObjets Enterprise Performance Management(EPM)の最新バージョン 10.0

SAP BusinessObjets Enterprise Performance Management(EPM)の最新バージョン 10.0が
出たみたいです。
下記をチェック。
http://enterprisezine.jp/article/detail/3264

SQL Server Fast Trackは期待はずれ

 現在、どのベンダーもデータウェアハウス専用機としてアプライアンス製品を出してきています。
Microsoftも後発ながら、事前構成済みデータウェアハウス専用構成「SQL Server Fast Track Data Warehouse (ファストトラックデータウェアハウス)を
しばらく前に出しました。

 私が知る限りでは、これはSQL Severはそのままで、ハードウェアだけをデータウェアハウスに合わせて構築したもののようです。
データウェアハウスのアプライアンスとして有名なテラデータやネティーザは、うえに乗っかるソフトウェアもデータウェアハウス専用となっています。
SQL Severは、OLTP用の製品なので、そこはちょっと?ですね。

 マイクロソフトの今後に期待したいと思います。

第4世代のSQL Server Denali

Microsoftのデータベース、SQL Sever。私も新人時代からずいぶん長い付き合いをしています。
現在、SQL Serverの次期バージョンが、コードネームDenaliで開発が進んでいるようです。

下記に詳しい記事があります。
コードネームはDenali/第四世代 SQL Server の世界へようこそ(前編)


ぜひ、チェックを。

SAP HANAについて

 今回は、SAPのインメモリソフト製品 SAP High-Performance Analytic Appliance、HANAについて
書こうと思います。
 SAP HANAは、SAPがサイベース買収後に発表した製品で、データをメモリに保持し、BI側のパフォーマンスを劇的に変化させる製品です。
データウェアハウス/BIによって、懸念となるのが、データ増大によるパフォーマンスです。メモリが安くなってきた昨今インメモリ製品は非常に有効なツールです。

SAP BWには、その他にSAP BWAと呼ばれるインメモリ製品があります。これは、サイベース買収前にSAPが出した製品でこれもインメモリ製品です。
既存のSAP BWにBWAを導入することによりパフォーマンスを向上することができます。

 おそらく、このBWAはHANAに統合されていくと思われます。また、買収したサイベースは、Sybase IQというコラム指向データベースというすぐれたデータウェアハウスデータベースを
持っていますので、これをSAP BWに統合していくものと思われます。SAP BWはすぐれた製品だと思いますが、パフォーマンスが不安なので、今後が楽しみです。

データウェアハウスイノベージョンに関するカンファレンス

 と言っても、日本での開催ではないので注意を。

 あのビル・インモンが、データウェアハウスの新しいテクノロジーに関するカンファレンスを開催するみたいです。

ADVANCED ARCHITECTURE CONFERENCE


取り上げられるトピックスは下記のとおり。
-The Kimball/Inmon debate Redux
-The unstructured data warehouse
-Textual ETL
-DW 2.0 – architecture for the next generation of data warehousing
-Building Applications for the Cloud
-New trends in Data Vault
-Taxonomies and Unstructured Data
-Agile ETL – building the agile data warehouse

どれも興味深いトピックスですね。

アメリカで開催なので、私は出席できないですが。。。。

Hadoopコラム

 @ITでHadoopに関するコラムが始まりました。
Hadoopといえば、ビッグデータに対応する技術として人気が高いソフトウェアですが、
勉強しなければと思いつつ、そのままになっている人も多いのでは?

このコラムで勉強しましょう。

テキストマイニングで始める実践Hadoop活用

2011年6月21日火曜日

NoSQLに関するサイト

 2009年くらいから、NoSQLというデータベースが流行し出しましたね。
Hadoopなどいろいろな種類がありますが、他にどのようなものがあるのでしょうか。

下記サイトにNoSQLデータベースの一覧が掲載されています。NoSQLといってもたくさんあるんですね。
http://nosql-database.org/

さらっと眺めてみましたが、知らないDBがごろごろありました。

ぜひ、チェックしてみてください。

データウェアハウスのモデリングツール

 データウェアハウスを構築する上で重要なのが、モデリングです。
そして、モデリングを行うにあたって、必要なのがモデリングツールですね。
まず、よく使用されているのが、ExcelなどのOffice製品でしょう。
すでに使用しているので、改めて買う必要がないからです。
あとは、Visioとかその他ベンダーから出ているモデリングツールだと思います。

本日は、無料で使えるデータウェアハウスモデリング用のオープンソースツールを紹介したいと思います。
その名も、「SQL Power Architect」です。

Community(無料版)とエンタープライズ版がありますが、無料版でも十分使えます。
また、無料版でOLAPなどのモデリングもできるのも魅力ですね。

ぜひ、ツールを探している人はチェックしてみてください。

MQLとは?

 MQLというクエリー言語があります。
下記に詳細のプレゼンテーションがあるので、ぜひチェックしてみてください。
MQL-to-SQL: a JSON-based Puery Language for RDBMS Access from AJAX Applications

プレゼンテーション資料

ETL:Excelデータに気をつけよう!

 ETLでデータを取得する際に、ソースデータとして、ファイルが使われることがあります。
たとえば、外部から情報をもらったりする場合ですね。
その際に注意です。おそらく、ソースデータをExcelとして使用する場合が必ず出てきますが、
これはなるべく避けて、テキストデータなどで提供してもらいましょう。

 理由は、Excelを利用すると、簡単に情報が欠落してしまうからです。
たとえば、コードのゼロ抜け。これはよくあります。元データにテキストとして、頭にゼロがついていても
Excelによって数値データと判断され、ゼロが抜けてしまうことがよくあります。

 私もずいぶんExcelで泣かされました。
 なるべく、Excelは避けましょう。

BI開発のメゾドロジー

 データウェアハウス/BIの開発は、要件が明確でないことが多いため、ウォーターフォール型の開発よりもスパイラル型での
開発のほうが適しています。そこで、データウェア/BIの開発で利用されるのが、アジャイルです。

 アジャイルといってもピンとこない人もいるかも知れませんが、アジャイルマニフェストというアジャイルの大事なポイントをまとめた標語があります。
下記に日本語訳が掲載されているので、じっくり読んでみましょう。

アジャイルソフトウェア開発宣言


これを読むだけで雰囲気がわかるのではないでしょうか。
言いたいことがこれにしっかりまとめられていますね。

アジャイルもいろいろありますがその中でよくスクラムが使用されるようです。
スクラム (ソフトウェア開発)


ちなみに私の会社では、アジャイルになれていないこともあって、データウェアハウス/BIの開発は未だにウォーターフォール型が取られています。
アジャイルの経験がある人やアジャイルに理解のある人が少ないのが理由です。というかほとんどいないと思います。
私も経験不足なので、あまり偉そうなことは言えませんが。。。
そのため、導入してから、あとは運用や保守でシステムに磨きをかけるといった感じになっています。

アジャイルをちゃんと勉強しないと。。。

Hadoop 第2版 日本語訳が出ます

 動物の表紙で有名なオライリー。Hadoopの第2版の日本語訳が7月に発売になるそうです。
原書は、Hadoop第1版が出てからすぐに第2版が出ていましたが、日本語版も対応が早いですね。
Hadoopの本格学習のために第1版の日本語訳を買おうとしていたので、あぶないところでした。
第2版の日本語訳が出たら、財布と相談して買うかどうか決めます。

2011年6月20日月曜日

LexisNexisがHadoopキラーHPCC systemsをオープンソースに!

 ビッグデータを扱うソフトウェアとして、人気が高いHadoopですが、そのHadoopキラーとなるHPCC systemsがオープンソース化されるそうです。
LexisNexis Open-sources its Hadoop killer

 上記の記事によるとHPCC systemsは、LexisNexis Risk Solutions部門で、膨大な顧客データを分析するために使用されていたものです。
 今回、オープンソースに踏み切った理由として、Hadoopが業界のデファクトスタンダードになる前に、オープンソース化によって優秀な開発者を集め、HPCC systemsをより進化させることが目的のようです。LexisNexisは、HPCC systemsが、Hadoopより優れたシステムであると自信を見せています。

 HPCCは、データアクセスに、Enterprise Control Languageを利用します。
 Hadoopでは、データアクセスにMapReduceを利用しますが、並列処理ワークフローを記載するには難易度が高いので、記事では、その点が強調されています。また、Hadoopは、Javaで作成されていますが、HPCCは、C++で構築されているため、パフォーマンスは良いとのことです。

HPCCの動作原理については、下記ページを参照してください。
http://hpccsystems.com/Why-HPCC/How-it-works

記事にあるとおり、今後HPCCがHadoopに勝てるかどうかはわかりませんが、ユーザにとって、選択肢が増えることはいいことですよね。

ぜひ、チェックしてみてください。

HPCC systems

オープンソース列指向データベース monetdb

列指向データベースをもう1つ紹介します。
monetdbです。

チェックしてみてください。

オープンソース列指向データベース LucidDB

オープンソースの列指向データベースにLucidDBというデータベースがあります。
MySQLやPostgreSQLは、業務システム、OLTPを主目的としたデータベースですが、
LucidDBは、はじめからデータウェアハウスの利用を目的として開発されています。
そのため、ETLの機能があらじめ組み込まれていたりします。

ぜひ、チェックしてみてください。
LucidDB

MDA: Model Driven Architecture software

データウェアハウスに欠かせないツールと言えば、ETLです。ETLは、Extract, Transfer, Loadingの意味で、
ソースデータと呼ばれる業務システムからデータウェアハウスに必要なデータを取得、クレンジングして、データウェアハウスにデータを格納するツールです。

 現在、これがさらに進化した形で、ETLからデータウェアハウスまでの構築をすべて行うソフトウェアがあります。
Model Driven Architecture、略して、MDAと呼ばれるツールで、業務のビジネスモデルを定義するだけで、ETLからデータウェアハウスの
構築まで自動化できるというすぐれものです。
 しかし、業務をモデリングするにはかなりのスキルが必要とのことです。

 現在、おもな会社として下記があります。

Kalido

BIReady


興味のある方は、チェックしてみてください。

ETLツールの種類

 現在、データウェアハウスの構築に欠かせないETLツールですが、ETLといってもさまざまな種類があります。

 今回は、ETLツールの大きな種類について紹介したいと思います。

自作ETL

これは、そもそものETLの起源となった方法で、つまり、PL/SQLやプログラミング言語でコーディングして自前でETLを作成することである。
現状使用されているETLツールの45%はいまだに自作ツールとのことです。
 自作ツールの問題点は、エラー処理、メインテナンス、メタデータ管理、ログなどの機能が弱いことです。開発した人がいなくなったら、誰も触れないと
いう事態になりかねないので、危険です。

コード生成ETL

自作ETLの次に登場したのが、コード生成ETLです。ETLデザインの応じて、コードを生成します。これに該当するETLとして、Open source ETLとして
有名なTalendがあります。

エンジンベースETL

コード生成ETLの次に登場したのが、エンジンベースETLです。コード生成ETLは、コード生成のため、対応するsourceデータベースの製品が限られてしまうという
弱点があります。これを解消したのが、エンジンベースETLです。PentahoのETLツールであるKettleやMicrosoftのSQL Server Integration Servicesは
は、このエンジンベースETLに該当します。

MDA

さらにこの進化型として、ETLとデータウェアハウスをビジネスモデルによって自動化するModel Driven Architecutre (MDA)と呼ばれるツールもあります。
Kalido, BIReadyなどが有名です。

2011年6月17日金曜日

オープンソースのBI製品

 BIのオープンソース製品について、紹介したいと思います。

 BIのオープンソースといえば、このサイトでも何度か言及しているPentahoが有名です。
また、その他に、JasperSoftも有名ですね。

Pentaho, JasperSoftともに日本のパートナーによって、日本語サポートがあります。
BIのオープンソースと言えば、この2つです。

Pentaho
JasperSoft

日本での知名度はいまいちですが、その他に有名なオープンソースのBI製品として下記があります。

Eclipse BIRT
Palo

Paloについては、詳しくは分かりませんが、サイトで情報を見る限り、非常にすぐれたツールのようです。

オープンソースBIを検討している方はぜひチェックしてみてください。

NoSQLの学習

 現在、流行といってもいいNoSQL。
@ITでNoSQLについての解説記事があります。
ぜひ、チェックを。

RDB開発者におくるNoSQLの常識

2011年6月16日木曜日

第21回:DMBOKの紹介

 今回でいよいよこのコラムも最終回となります。今回は、データ管理をまとめた知識体系であるDMBOKについて紹介します。

DMBOKとは

 DMBOKとは、Data Management Body of Knowledgeの略で、DAMA(The Data Management Association)という
データマネジメントに関する推進団体が策定した知識体系です。知識体系と言えば、プロジェクトマネジメントのPMBOKが有名ですが、データ管理についてもあるんですね。
DMBOKは英語で書かれていますが、データ総研から日本語訳が出ています。

 DMBOKは、下記の10のファクションに分かれています。
1 データガバナンス
2 データアーキテクチャマネジメント
3 データディベロップメント
4 データオペレーションマネジメント
5 データセキュリティマネジメント
6 リファレンス&マスタデータマネジメント
7 DWH&BIマネジメント
8 ドキュメント&コンテンツマネジメント
9 メタデータマネジメント
10データクオリティマネジメント

 データウェアハウスに関連する項目は、「7 DWH&BIマネジメント」となります。ここでは、本コラムでも紹介したインモンアーキテクチャとキンボールアーキテクチャが紹介されています。
また、参考文献が非常に充実していますので、これを手がかりにどんどん学習を進めていくことも可能です。ただし、参考文献のほとんどが日本語に翻訳されていないのが、難点ですね。

 他のファクションも、データウェアハウス、BIを構築する上で密接に関連している項目ばかりですので、一読をお勧めします。

 短いですが、これで今回は終了となります。

 21回にわたって、コラムを記載してきましたが、いかがだったでしょうか。自分の知識不足もあり、断片的な技術紹介になってしまいましたが、ご一読いただきありがとうございました。

 コラムは終了ですが、引き続き、ブログにて、情報発信を行っていきたいと思います。

第20回:データウェアハウス/BI用語解説

今回は、復習も兼ねてデータウェアハウス/BIの重要な用語について説明します。

 ファクト
 分析する対象となる数値データをファクトと呼びます。メジャーやメジャーメントなどとも呼ばれます。

 ディメンション

 分析する軸をディメンションと呼びます。 

 ディメンショナル設計

 ディメンショナル設計とは、データウェアハウスに特化したデータベースの設計方法です。通常の正規化されるデータモデリングと違い、
大量データを素早く分析できるように、シンプルさとパフォーマンスを考慮した設計です。

 スタースキーマ
 
 スタースキーマは、ディメンショナル設計で利用されるモデリングです。分析対象となる数値データであるファクトテーブルを真ん中に配置し、
それを囲むように、分析軸となるディメンションテーブルをファクトテーブルの周りに配置します。見た目が星形に似ているところからスタースキーマと
呼ばれています。

 スローリーチェンジングディメンション

 ディメンショナル設計で利用される履歴を管理するテクニック。分析要件によって利用するテクニックが異なる。

 データマート

 部署に特化した分析データベースをデータマートと呼ぶ。

 キューブ

 スタースキーマを多次元データベースで実現したものをキューブと呼ぶ。

 アドホックレポート

 アドホックレポートは、その場限りで使用される使いすてのレポートのことです。 


 次回はいよいよ最終回です。データに関する知識体系DMBOKについて紹介します。

2011年6月10日金曜日

HSQLDB

HSQLDBはJavaで構築されたデータベースです。
オープンソースBI Pentahoでデフォルトのデータベースとして使用されています。

詳細についてはこちらをチェック。
http://hsqldb.org/

第19回:Open souce Pentaho

今回は、オープンソースのBI製品として有名なPentahoについて紹介したいと思います。

 前回と同様に下記コンポーネントについて対応製品を紹介します。

・ETL
・データウェアハウス(データベース)
・OLAP cube
・BIツール

ETL

 PentahoのETLツールは、「Pentaho Data Integration」という製品になります。
これは、Kettleとも呼ばれています。オープンソースとは言ってもETLに必要な機能はそろっており、
商用に負けない機能となっています。

データウェアハウス(データベース)

 Pentahoには、デフォルトでは、HSQLDBが使用されていますが、MySQLやPostgreSQLなどの
大規模データに対応したオープンソースデータベースを使用することができます。MySQLは、Infobrightや
InfiniDBといったデータウェアハウスに特化した列指向データベースを使用できるので、これらを組み合わせれば、
高速なデータウェアハウスを作成することも可能です。

OLAP cube

 Pentahoでは、「Mondrian」というOLAPエンジンを使用できます。
また、JPivotというツールを使ってMondrianにアクセスできます。
MDXも使用できます。

BIツール
フロントエンドツールもJPivotによるOLAP分析をはじめ、レポーティングやダッシュボードなどの機能がそろっています。
Pentaho1つですべてのツールが揃いますので、商用のツールを買わなくてもオープンソースツールで商用に負けないBIソリューションを
構築することができます。

オープンソースの強みはなんと言っても、価格が安いことだと思います。データウェアハウス/BIは導入しても使いこなせないことが多いので、
いきなり商用ツールの導入はリスクが高いという企業は、Pentahoなどで安価に導入してみるのもいいと思います。

データウェアハウス/BI分野でもその他にも多くのすぐれたオープンソース製品が出ていますので、技術力さえあれば、
テラバイト級のデータにも対応できるシステムを構築することも可能だと思います。

Pentaho以外では、Jaspersoftというオープンソース製品が有名なので、興味のある方はこちらもご検討ください。

次回は、データウェアハウス/BI用語について、一通りのまとめをしたいと思います。

2011年6月9日木曜日

Mastering the SAP Business Information Warehouseを読みました

「Mastering the SAP Business Information Warehouse: Leveraging the Business Intelligence Capabilities of SAP NetWeaver」を読みました。
本書の特徴はなんといってもインモンモデルにそって、SAP BWを説明している点です。

また、メンテナンス性を考慮して、InfoCubeにレポートは直接アクセスせず、間にVirtualProviderを挟むというアドバイスは非常に参考になりました。


オープンソースDBの試験が7月スタート

オープンソースDBの試験が7月にスタートします。
チェック。
PostgreSQLベースの「OSS-DB技術者試験」、7月スタート

SAP BW DataStore Objects

SAP BW DataStore Objectsの技術メモ。

SAP BWのデータコンポーネントであるDataStore objectsには以下の3種類があります。

1.Standard DataStoere Objects
通常データウェアハウスのデータ格納場所として使用
2.Direct-update DataStoer objects
リアルタイムデータが必要とされる場合に使用
3.Write-optimized DataStore Objects
ロードデータが大きい場合に使用

用途に応じて使い分けたい。

第18回:SAP製品

 今回は、SAPのデータウェアハウス/BI製品について、前回と同様に下記コンポーネントについて説明したいと思います。

・ETL
・データウェアハウス(データベース)
・OLAP cube
・BIツール

SAP BWはさまざまな機能がひとまとめに!

SAPのBIソリューションは、SAP BWというアプリケーションを利用します。
このアプリケーションはいわゆるワンストップソリューションで、ETL,データウェアハウス、OLAP cubeがすべてこのSAP BWでカバーすることができます。しかし、ETLツールについては、SAP BWが持っているETL機能が弱いということと、BusinessObjectsを買収した際にBO社がすぐれたETLツールを持っていたことにより、DataServiceというETLツールを別途購入、使用することができます。もちろん、他の会社のETLツールも使えますが。。。

 また、データベースソフトウェアは別途購入する必要があるので、OracleやMS SQLが必要になります。

BIツール

フロントエンドとなる、BIツールは、BusinessObjectsになります。SAP BWには、Bexというレポーティングツールがありますが、現在、買収したBO社の製品でフロントエンドを統一する動きとなっています。また、BOのフロントエンドツールは、Cristal reports,web intelligence,dashobaord design (Xcelsius)などいろいろなツールがありますので、要件にあったツールを選ぶようにしましょう。

BusinessObjectsとSybaseの買収効果

 SAPはここ数年、BIの強化のため、BusinessObjectsとSybaseなどの大型買収を行ってBI側を強化してきました。BOは、フロントエンドの強化にSybaseは、データベースの高速化とモバイル対応といった感じです。BOについては、なかなかシステム統合がすすでいないイメージがあったのですが、今回の最新版で統合が一段と高まりました。SAPは、一般コンシューマにはなじみがありませんが、企業ではERPシステムを中心に非常によく使われています。ERPでSAPを使用していれば、BIツールとして、SAP BWがまず第一候補に上がってくるのではないでしょうか。

今回は、SAPの製品について紹介しました。次回は、オープンソースBIとして、有名なPentahoについて紹介したいと思います。

2011年6月8日水曜日

第17回:マイクロソフト製品

 今回から、3回にわたって、主要なデータウェアハウスベンダーの製品について紹介をしたいと思います。
下記のコンポーネントに該当する製品を紹介していきます。
・ETL
・データウェアハウス(データベース)
・OLAP cube
・BIツール

第1回目は、マイクロソフト製品です。

ETL

 マイクロソフトのETLツールは、「SQL Sever Integration Services」です。
一通り、機能を有しており、Slowly chaning dimensionにも対応しています。
難点といえば、メタデータがXMLでの管理となってあり、インパクトアナリシスがちょっと大変なところでしょうか。

データウェアハウス(データベース)

 これは当然、SQL Severになります。大規模データにも対応できるデータベースですが、
難点といえば、やはりデータウェアハウス専用ではないため、パフェーマンスが他のアプライアンス製品とくらべると
おそいことでしょうか。しかし、この点については、「SQL Server Fast Track Data Warehouse」や
「SQL Server Parallel Data Warehouse」などデータウェアハウスに絞った製品を投入してきているので
今後に期待です。

OLAP cube

 OLAPはSQL Sever Analysis Servicesになります。
これは、OLAP機能とデータマイニング機能が付いています。

BIツール

 マイクロソフトのBIツールは、定型レポート→「SQL Sever Reporitng Services」、OLAP分析→Excelとなります。
マイクロソフトの強みはなんといっても、使い慣れているExcelがインタフェースになっていることでしょうか。

以上マイクロソフトの製品について紹介してきました。もちろん、各コンポーネントの一部のみを他の製品と組みわせて使用することも可能です。
マクロソフトの強みはすでに他のマイクロソフト製品を利用している可能性が高いため、その資産を利用して導入できることではないでしょうか。
また、大企業だけあって、今後の製品の向上が期待できるのも強みですね。

 今回は以上です。次回は、SAPの製品について紹介します。

第16回:Data warehouse/BI導入の勘どころ

今回は、データウェアハウス、BIシステムを導入する際に注意するポイントについて説明したいと思います。

まずは社内の分析能力成熟度を把握しよう

 データウェアハウス、BIシステムを導入する前に、必要なのが、導入する組織、部署の分析能力の成熟度を把握することです。この分析能力成熟度とは、組織がどの程度、データを重視して意思決定に利用しているか、また、社員がデータの品質の重要度を理解しているかなどです。まあ、簡単にいってみれば、データウェアハウス、BIを導入してもちゃんと使う意思があるかどうかということです。

 よくあるのが、社長の一声で、データウェアハウス/BIを導入したものの、誰もデータに注目せずに、そのままシステムが埃をかぶってしまうというものです。これは、組織の分析能力が成熟していないために起こる事象です。

 もし、成熟度が低いようでしたら、成熟度を向上させる業務改革を実施しましょう。

データウェアハウス/BIシステムは使ってもらってなんぼ!

 当り前の話ですが、システムは使ってもらわないと意味がありません。しかし、よくあるのがシステムを構築したのはよいが、使い勝手がわるくて結局ユーザは生データをアクセスにダウンロードして分析しているなんてことがあります。これでは、システムを導入した意味がありません。
 では、どうすれば、ユーザに使ってもられるのでしょうか。当たり前ですが、これはユーザをシステム構築のプロジェクトに巻き込むしかありません。また、ユーザ視点でシステムを構築することです。まあ、言うのは簡単ですが。。。

リリース後の保守、運用が重要

 データウェアハウス/BIシステムは、特にリリースした後が大事です。分析要件は変わりますし、そもそもユーザははじめは要件がよくわからないので、リリース後にやりたいことが明確になることがあるからです。そのため、システムはリリース後にどんどん進化していく必要があるのです。

現場の功績がただしく評価される仕組みが必要

 しかし、リリース後の保守、運用がうまくいかないひとつに現場の保守作業が正しく評価されないということがあります。
プロジェクトマネージャをやったほうが目立って昇進しやすかったりして、保守、運用はないがしろにされがちです。

 ということで、最後にマネージャの方にお願いです。目立つだけで評価するのはやめましょう。仕事への評価で現場の人も正しく評価しましょう。

 もし、そんな素晴らしいマネージャがいなかったら?運命と諦めて、粛々と作業を進めましょう。

第15回:MDX超入門

 今回は、OLAPからデータを取得するクエリMDXについて説明します。

MDXって何?
 まず、MDXとは何でしょうか。これは、「Multi Dimensional eXpressions」の略で、OLAPからデータを取得するためのクエリです。SQLのOLAP版と考えればよいでしょう。このMDXは、最初マイクロソフトによって実装されましたが、その後、各ベンダーもMDXをサポートするようになり、業界のデファクトスタンダードとなりました。

 しかし、悲しいかな、SQLに比べるといまいち知名度がありません。私が勤務する会社でも、SQLは知っていてもMDXについては?という人が少なくありません。また、その使いかたとなると、ぐんと数は少なくなります。

今回は、そんなMDXのほんのさわりだけ紹介したいと思います。MDXの構文を説明しようと思いましたが、基本を説明するだけでもかなりの分量になるので、またの機会としたいと思います。

基本構文
 MDXの基本構文は下記のようになります。SQLと構文上はよく似ています。

SELECT
[メジャー(ファクト)またはディメンション] ON COLUMNS, ←横軸(1)
[メジャー(ファクト)またはディメンション] ON ROWS ←縦軸(2)
FROM
<キューブ名> ←キューブ
WHERE
[ディメンション] ←スライサ(3)

 まず、SELECTのあとに表示したい、メジャー(ファクト)とディメンションを縦軸、横軸それぞれ指定します。そして、FROMのあとにキューブ名を記載します。
 通常、スライシングと呼ばれているキューブデータの絞り込みをする場合は、WHERE句のあとにしてします。ただし、ここで注意です。(1)~(3)のディメンションはすべて違うディメンションを指定する必要があります。そのため、もし、(1)や(2)でデータを絞りたい場合は、filterという機能を使って、(1),(2)内で条件をしてすることなります。

MDXを使用する場合は、出力したレポートをイメージすることが重要になります。ただ、SQLと似ているようで結構違いがありますので、とにかく使って覚えていくのが上達への近道ですね。

 今回は、MDXのほんのさわりを説明しました。次回は、Data warehouse/BI導入について説明します。

SPARQLって何?

SPARQLというクエリ言語があります。
どうやら、名前からしてSQLと関係がありそうだと思ったあなた、正解です。

SPARQL

WikipediaによるとRDFクエリ言語の一種らしいです。

くわしいことは、まだ勉強していないのでよくわかりませんが、注目されているクエリであることは間違いないようです。

オライリーからSPARQLを扱った本ででるので、ぜひチェックを。

Learning SPARQL

統計は大事です。

競争が激しくなる昨今、データ分析による意思決定がますます必要になってきています。
データを分析するうえで避けて通れないのが統計分析です。
といっても、たいていのエンジニアは統計学をきちんと学んでいないので、苦手な人が多いですよね。
というか、私もそのうちのひとりです。(鋭意勉強中)

さて、あのオライリーから統計に関するプログラミング本が出るようです。

Think Stats


ぜひ、チェックを。。。

2011年6月7日火曜日

SAP BW:各データ格納コンポーネントの説明とインモンモデル、キンボールモデルへの利用法

 SAP BWは、データウェアハウスとデータウェアハウスのマネジメントアプリケーションが一体となったソフトウェアです。
データベースには、OracleやSQL Serverなどのデータベースが利用できますが、SAP BWがシステムDBとして利用するので
自分でテーブルを作ったりすることはできません。

 今回は、SAP BWで使用される各データ格納コンポーネントの説明と、データウェアハウスアーキテクチャである、インモンモデルとキンボールモデルを利用した
場合にどのように使用できるかを説明したいと思います。
 
 各コンポーネントの説明

 SAP BWには、様々なデータオブジェクトがありますが、ここでは、データウェアハウスに利用する主にもののみ説明します。

・PSA(Persistant Staging Area)
PSAはソースシステムからデータを取得する際に利用するステージングエリアです。

・DSO(Data Store Object)
DSOは、通常のデータウェアハウスで利用するデータベースにあたる部分です。ソースシステムから集出したデータを格納します。

・InfoCube
InfoCubeは名前からわかるようにキューブです。

MultiProvider
・MultiProviderは複数のInfoCubeを仮想的に1つにまとめることができます。いわゆるドリルスルーというテクニックです。

インモンモデルでの利用

 では、実際のアーキテクチャモデルの利用を考えてみたいと思います。
インモンが提唱したエンタープライズモデルでは、セントラルデータウェアハウスといわれる正規化したデータベースにすべてのデータを格納し、
そこから各部門が必要とするデータをディメンショナルモデルで構築されたデータマートとして抽出し、各レポートがデータマートにアクセスするかたちとなります。

その場合、
ソースシステムからのデータ抽出→PSA
セントラルデータベース→DSO
データマート→InfoCube
といった利用になります。

キンボールモデルでの利用

 キンボールモデルでは、ディメンショナルモデルで構築されたそれぞれのスタースキーマがリンクされたものがデータウェアハウスとなります。
インモンでのセントラルデータベースはステージングエリアに格納されることになります。

その場合、
ソースシステムからのデータ抽出→PSA
ステージングエリア→DSO
スタースキーマ→InfoCube
といった利用になります。

上記は、あくまで例ですので、他にもさまざまに組み合わせがあると思います。

 さて、最後に1点注意ですが、どちらのモデルを採用するにせよ、レポートはInfoCubeにアクセスしたほうが良いと思います。
SAP BWで提供しているレポーティングツールはDSOにもアクセスできるのですが、パフォーマンスやデータの特性上、InfoCubeのみに
アクセスさせたほうがよいと思います。

2011年6月6日月曜日

SAP BusinessObjects 4.0の製品名

SAP BusinessObjectsの最新版である、BO 4.0。

前回のバージョンから名称が変わっていたりして混乱するので、ちょっと整理の意味を込めて、BO 4.0の製品を紹介してみたいと思います。

Dashboard design
>これは、ダッシュボードを作成する製品です。以前の名前はXcelsiusです。わかりやすい名前になりましたね。

Cristal reports
>これは、帳票などの定型レポートを作成する製品です。クリスタルレポートって昔から有名ですよね。

Web Intelligence
>これは、定型レポートやアドホックを作成ツールです。BOではおなじみの製品です。ちなみにつうは、Webi、うぇびーと読みます。

Live Office
>Web IntelligenceのインタフェースがMS Officeになった製品です。

Analysis edition for OLAP
Analysis edition for Microsoft Office
>これはSAPのレポーティングツールとして利用されていたBex、ベックスの新バージョンです。OLAPのほうがWebベースでMS Officeの方が、ExcelなどのOffice製品がインタフェースなどとなります。OLAP分析にはこれですね。

なんか、もりだくさんですね。

自分の会社にあったツールを選びましょう。

BusinessObjects LiveOfficeについて

BusinessObjectsの製品にLive Officeという製品があります。
これは、マイクロソフトのOffice製品からUniverseやWeb Intelligenceなどのアクセスできるツールです。

Web IntelligenceはWebベースなのですが、ユーザから慣れのせいか、使い勝手はあまり評判がよくありません。

その点、Excelなどのオフィス製品はユーザが慣れているので抵抗が少ないようです。

Live Officeという必ず、デモの例としてExcelが使われます。なので、私はずっとExcelからしかアクセスできないと思っていたのですが、名前の通り、WordsやPowerPointなどの他のオフィス製品からもアクセスできます。
まあ、でも通常はExcelですよね。

ちなみにLive Officeを使用する場合は、アドオンのインストールが必要になります。

SAP BusinessObjects Xcelsiusの読み方

SAP BusinessObjectsのダッシュボード製品としてXcelsiusという製品があります。
Xcelsius読み方という検索条件でこのサイトにきている方がいるので、この際、日本語名を掲載しておきたいと思います。

ずばり、日本語読みは「エクセルシウス」です。

ちなみに現在の最新バージョン BO 4.0から名前が変わります。

SAP BW:SAPに関する情報を集める

SAPシステムについて疑問やわからないことがあった時に便利なのがSAP HELP PORTALです。

各システム別に状況が集約されており、しかも各システム別に検索できます。グーグル検索でなかなか見つからなくてもここで簡単に見つかったりします。

便利なので、ぜひ利用しましょう。

2011年6月5日日曜日

ピーターの法則

 データやデータウェアハウスとは直接関係ないが「ピーターの法則」と呼ばれる法則について紹介したいと思います。このピーターの法則に関する本を始めて読んだときはあまりの面白さとその法則の適用率の高さに感動しました。自分の仕事環境にたいへん当てはまり、うんうんと読み進めたのを覚えています。

 では、「ピーターの法則」とはいったいなんでしょうか。これは簡単にいってしまえば、人は無能になるまで昇進するという法則です。たとえば、日本のIT業界を例にとれば、まず、プログラマとしてスタートします。そして、プログラマとして成功すれば、たとえば、チームリーダーに任命されています。そして、そこでチームリーダーとしての能力を発揮すれば、プロジェクトーマネージャとして昇進、さらに管理職といった感じで昇進していきます。これはよくある光景ですが、ポイントはうまく行かなかった場合、つまり、そのポジションにふさわしい能力がなかった場合はその地位にとどまるということです。決して、その前に地位に降格することはありません。なので、無能になると、そこでとまってしまう、つまり、これがピーターの法則です。

 では、この状況をさけるには一体どうしたらいいのでしょうか。個人的な対策として示されているには、時々無能を装って自分の能力が発揮できるポジションに居座り続けることです。しかし、他の人には気づかれないように。。。

 この法則は自分のキャリアを考える上で常に参照している法則です。現場として、仕事をするのが自分にあっていると感じているからです。

 この本は非常におすすめなので、一読をお勧めします。

SAP BW: Net weaver本とWeb intelligence本が早速とどく

追加で注文しておいた「SAP NetWeaver BW: Administration and Monitoring」と「SAP BusinessObjects Web Intelligence」が早速アマゾンからとどきました。

これで、バックエンドからフロントエンドまでSAP BW本がかなりそろったことになります。

あとは勉強するだけですね。

早速、読み始めたいと思います。



2011年6月4日土曜日

Reporting and Analytics Using SAP BusinessObjectsを読み終わりました

BusinessObjectsの勉強の一環として読んでいた「Reporting and Analytics Using SAP BusinessObjects」を読み終わりました。

BusinessObjectsのレポーティングについてひとおり説明してあります。たとえば、Cristal reports, Xcelsius, Web Intelligence, Live office, Explorerなどです。SAP BWとの接続方法が各ツールについて説明してあり、非常に参考になりました。

現在、SAP BWのフロントエンドのレポーティングツールとしてどのツールを使用するか検討していますが、その際、重要になるのが、SAP BWとどのように接続できるかです。SAPがBusinessObjectsを買収した関係上、現在、SAP BWで使用されているレポーティングツールベックスとBusinessObjectsツールが混在しています。また、SAP BWのデータに接続するのも様々なインタフェースがあって、まだ完全に統一されていません。そのため、どのツールがどういった接続方法が利用できるかが重要になるのです。そのため、本書は非常に参考になりました。

SAP PRESSのBI/BW本をある程度そろえましたが、次はSAP BW Modelingを読んでみようと思います。



SAP BusinessObjects Web intelligence本を購入

現在、仕事でSAP BWとBusinessObjectsをレポーティングツールとして使用するプロジェクトに関わっていますが、主にユーザインタフェースとなるBusinessObjects側を担当することになりそうです。

Web Intelligenceが主なツールになりそうなので、早速SAP PRESSのWeb intelligence本を購入して、勉強することにしました。

早速、アマゾンで下記の書籍を購入。
明日、とどく予定です。

おそらく、SAPのトレーニングも受ける予定ですが、その前に独学である程度勉強しておきたいと思います。


2011年5月31日火曜日

第14回:ROLAP,MOLAPの違い

 今回から2回にわたって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について説明します。

第13回:ETLチェンジデータキャプチャ

 今回は、ETLの機能して重要なチェンジデータキャプチャ(Change Data Capture CDCと略されます)について、詳しく説明したいと思います。

チェンジデータキャプチャとは?

 復習もかねて、チェンジデータキャプチャとは何かについて説明したいと思います。データウェアハウスでは、業務システムなどの様々なソースシステムからデータを抽出し、クレンジングしてから、データベースに登録または更新を行います。その際、当然、新規追加されたデータまたは、更新、削除されたデータだけ反映したいですよね。では、どうやって、各ソースシステムからどのデータが変更されて、どのデータが変更されていないかを判断するのでしょうか。それを把握するのが、チェンジデータキャプチャという機能です。

 代表的なチェンジデータキャプチャのテクニックは大きく下記の4つの方法があります。
・Source Data-Based CDC
・Trigger-Based CDC
・Snapshot-Based CDC
・Log-Based CDC

 各チェンジデータキャプチャについてくわしく説明していきましょう。

Source Data-Based CDC

 Source Data-Based CDCは、ソースシステムの変更データをあらわす属性を利用します。利用する属性として代表的なものに下記の2つがあります。
・タイムスタンプ
 少なくとも更新日付が1つは必要になります。理想としては、新規登録日と更新日の2つあることが望ましいです。
・データベースシーケンス
 多くのデータベースが自動でのシーケンス番号付与機能を持っています。これを利用すれば、どれが新規に追加されたどうかがわかります。

 この方法を利用する場合、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本が結構そろいました。

あとはひたすら読んで勉強するだけですね。




Bloggerにログインできず!

最近ずっとブロガーにログインできずに困っていました。
ヘルプページを見たら、対応中のようだったのですぐなおるだろうと持っていましたがなかなかなおらず。。。

しびれを切らして、検索してみたら、他のブラウザやちがうPC環境だとできるらしい。
ということで、普段はクロームですが、サファリでログインしたら、できました。

よし。ということでブログをじゃんじゃん投稿します。

Programming Pig

Hadoop上で利用するプログラミング言語 PIG本がオライリーかできます。
出版されたら、読んでみたい。
http://oreilly.com/catalog/9781449309121/

Ingres VectorWise

Ingres VectorWiseは次世代のデータウェアハウス製品です。
今後、注力していきたいと思います。
Ingres VectorWise

キンボールグループによるビックデータに対するコラム

データウェアハウスのコンサルティング&教育で有名なキンボールからビックデータに関するコラムが掲載されています。
ぜひ、チェックを。
閲覧には登録が必要です。

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/

RubyのWebアプリケーションフレームワーク Sinatra

RubyのWebアプリケーションと言えば、Railsが有名ですが、SinatraというWebアプリケーションフレームワークもあります。
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

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などのツール選定の評価項目として利用できるなど、なにかと便利です。

ぜひ、利用しましょう。

第11回:ETL34サブシステム 11-22

 前回の続きです。ETL サブシステム11-22まで紹介します。

11.階層管理(Hierarchy Manager)
ディメンションの階層管理機能。

12.スペシャルディメンション管理(Special Dimensions Manager)
ジャンクディメンションやミニディメンション、日付ディメンションなどの特殊ディメンションの管理機能。

13.ファクトテーブル構築
主要な下記3つのファクトテーブルの構築を行う機能。
・トランザクション
・ピリオディックスナップショット
・アキュムレーションスナップショット

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に必要なサブシステムについて
情報を提供しています。
 今回はそのキンボールリストにならって各サブシステムについて解説していきたいと思います。サブシステムが34もあるので、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回:ディメンショナルモデリング:ファクト設計:ファクトレスファクトテーブル

 前回、3つのファクト設計トランザクション、スナップショット、アキュムレーションスナップショットについて説明しましたが、今回はトランザクションの派生設計となるファクトレスファクトテーブルについて説明します。

ファクトレスファクトテーブル

 では、ファクトレスファクトテーブルって何でしょうか。日本語に訳せば、ファクトがないファクトテーブルとなります。
そうです、ファクトがないのがファクトテーブルなのです。ファクトって何のことでしたでしょうか。そうです、売上高など分析する数値にあたる部分でした。
 この数値部分がないのがファクトレスファクトテーブルなのです。具体例をあれば、会員数などです。売上高データのように登録された会員数のデータには数値は含まれていませんよね。
もちろん、SQLなどのcountを使えば、件数は確認できますが。

 ということで、実際数値情報が入っていないが、件数などの情報をファクトして扱うものをファクトレスファクトテーブルと呼びます。
 では、どのように設計するのでしょうか。基本はトランザクションと同様にそのままデータを挿入していきます。しかし、ファクトデータがないので、設計をシンプルにするためにあえて、ファクト値のフィールドを作成して1を入力しておきます。このフィールドがなくても、SQLの集計関数を使えば、計算できるのですが、設計とシステムをシンプルにするために1を追加します。
 具体例は、下記の図をご覧ください。


 短いですが、以上でファクトレスファクトテーブルの説明は終わりです。これでディメンショナルモデリングについて一通り説明が終了しました。
 次回よりETL4回にわたって、ETLについて説明をしたいと思います。

第8回:ディメンショナルモデリング:ファクト設計:トランザクション、スナップショット、アキュムレーションスナップショット

 前回は、ディメンショナルモデリングで重要なスローリーチェンジングディメンションについて解説しましたが、今回は分析する数値部分にあたるファクトの設計について説明します。

ファクトって何?

 さて、復習です。ファクトって何でしょうか。ファクトはスタースキーマの真ん中に位置するデータで分析する数値のことです。製品によってはメジャーと呼ばれたりします。売上高、ログイン数、会員数などがファクトにあたります。

ファクトの設計 

 そのファクトデータの格納方法ですが、実は大きく分けてファクトの利用目的によって下記の3つの設計方法にわかります。
・トランザクション
・スナップショット
・アキュムレーションスナップショット

 以下順にそれぞれのファクト設計について説明します。
 
トランザクション

 まずはトランザクションからです。これはもっともオーソドックスなファクトの設計方法で、分析するデータがトランザクションデータの積み上げで掲載される場合に使用されます。
 よくわからないと思うので、例をもとに説明します。たとえば、売上高ですが、売上高は、当たり前ですが、それぞれの商品の売り上げを足し上げたものが全体の売上高ですよね。
 あと、会員サイトの会員数やログイン数、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

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

複数バージョンによる予期可能な変更(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対多でリンクするのが一般的だと思いますが、ディメンショナルデータベースでは1つのテーブルに非正規化した形で保持します。これは、おもな理由としてパフォーマンスを向上するためと、ユーザにも分かりやすいようにスタースキーマをシンプルにするためです。業務データベースでは、更新の際の整合性を保つために正規化しますが、分析データベースは更新が少ないため、非正規化によるメリットがデメリットを上回る形になります。

スノーフレーク

 もしディメンションを非正規化せずに、正規化で構築した場合はスノーフレークと呼ばれます。スタースキーマが雪の結晶のように見えるためこのように呼ばれています。

 ディメンショナルモデリングでは、ブリッチテーブルなどの特殊な場合を除き、あまり望ましくない設計とされています。
業務データベースを経験している人は、つい正規化してしまいがちですが、性能とシンプルさという観点からなるべくスノーフレークは避けたほうがよいでしょう。

 今回は、階層とスノーフレークについて説明しました。次回はディメンショナルモデリングで重要なスローリーチェンジングディメンションについて解説します。

日本テラデータ、SSDとHDDのハイブリッドを採用

日本テラデータが、SSDとHDDのハイブリッドを採用した。
下記をチェック。
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/

2011年5月21日土曜日

SAP BW, Business Objects本を追加で注文!

さらに勉強しようと思い、下記の本をアマゾンで注文しました。
NetWeaverとBusiness Objectsをさらに勉強しようと思います。









注文したら、さっそく読みたいと思います。

2011年5月15日日曜日

SAP BW:InfoProviderとInfoSetの謎を解く

SAP BWにInfoProivderとInFosetとという、データやキューブをリンクする機能があります。
この両方の違いって何でしょうか。

実は、InfoProviderがUnion結合で、InfoSetがJoin結合です。

SAP BWは良くできていますね。

米EMC、旧Greenplumが構造化データ向けにHadoop提供

米EMCが買収した旧Greenplumが非構造化データ向けにHadoopの提供をするとのことです。
非構造化データの分析ニーズはますます高まりそうですね。

@IT関連記事

2011年5月10日火曜日

第5回:ディメンショナルモデリング:スタースキーマ

今回はデータベースのデザインでもっとも重要なディメンショナルモデリングのスタースキーマについて解説します。

データウェアハウスモデリングは業務データモデリングと違う
まず、スタースキーマについて説明する前に、データウェアハウスのモデリングと業務データベースのモデリングは違うということについて強調しておきたいと思います。業務データベースの設計をやっていた人が、データウェアハウスのモデリングでまず驚くのがこの違いです。私も業務データベースの設計をしていたので、データウェアハウスのモデリングを勉強したときはあまりの違いになかなか馴染めませんでした。

ということでまず次を読む前に業務データベースの設計は忘れてください!

データウェアハウスモデリングの極意!スタースキーマ
データウェアハウスのそもそもの目的ってなんでしょうか。そう、データを分析することです。データ分析って何に注目するのでしょうか。それは数字です。例えば、売上高、ウェブサイトのページビュー、会員数などです。データウェアハウスのモデリングはまずこの数字に着目します。モデリング用語ではこれをファクトと呼びます。製品によってはメジャーと呼んだりもします。

では、そのファクト、例えば売上高に着目した時にどうやって分析しますか?例えば、支社別の売上高とか月別の売上高とか顧客別とか、いくつかのまとまりで売上高を見ますよね?これをモデリングではディメンションと呼ぶのです。

そして、データウェアハウスのモデリングではファクトテーブルを真ん中において、それを囲むようにディメンションをリンクします。モデリングのかたちが星形に似ていることからスタースキーマと呼ばれます。

下記に例を示します。下記は売上ファクトテーブルを真ん中にして、それを日付ディメンション、営業所ディメンション、顧客ディメンションでリンクしています。



これにより簡単に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が見ることができるそうです。

データのセキュリティを考える

@ITの記事を読んでいて、今問題になっているソニーの個人情報流出に関する記事を見つけました。
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,フロントエンドの分析ツールをカバーしています。
英語で書かれていますが、わかりやすく英語がある程度できる人であれば問題なく理解できると思います。

おすすめの本です。

全体像を理解するために一部さらっと読んだので、2回目はしっかり精読していきたいとおもいます。

平行して、注文してほかの2冊も読んでいきたいと思います。


2011年5月5日木曜日

SAP BW:Data Store Object, DSOって何だ???

SAP BWにData Store Objectというのがあります。これってなんでしょうか。
簡単に言ってしまえば、これはデータウェアハウスで利用するステージングエリアやインモンモデルでいうエンタープライズデータウェアハウスに相当するものになります。

データソースのデータをDSOに格納してここでクレンジングしたり、ここで元のデータを保持して、InfoCubeと言われる、キューブでデータを送ったりします。

SAP BW:InfoObjectsって何だ???

SAP BWについて勉強をはじめたので、SAP BWについてちょっとずつ紹介していきたいと思います。

今回は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の使用方法および開発方法を覚える必要があります。

Xcelsius本とSAP BusinessObjects本がとどきました

注文していたSAPプレスのXcelsius本とBusinessObjects本がとどきました。
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):データボルトモデリング

今回は、3つ目のデータウェアハウスアーキテクチャ、「データボルトモデリング」について説明します。以前紹介したインモンモデルやキンボールモデルほど有名ではありませんが1つの考えとして重要なアーキテクチャなので紹介したいと思います。

データ統合せずにそのまま格納する
データボルトモデルの特徴を一言で言えば、すべてのオペレーションシステムから来たデータをそのまま保管するモデリングです。そのままデータを保管するところがポイントです。そのまま保管する理由はもし後で使用がかわった場合に元データがあるのでそれをもとに再構築できるからです。また、最近のオーディットの対応としてもデータが追えるという点で非常に優れています。

今までとりあえず、万が一のためにローデータをファイルで保管していた会社は多いと思いますがいざとなったら使わないし、どういうデータ構造になっているかもわからないで有効に活用できていなかったので現状です。

そこで、データボルトモデリングです。これを利用すれば、リレーショナルデータベースに保管できるので、いざというときに利用できます。確かにすべてを保管するとデータ量が多くなりますが近年ハードは安くなっていますし、データの圧縮技術も進化しています。また、データ分散の技術も進化していますので、ある程度大きな会社であれば、これらの問題は解消できると思います。

モデリングの詳細
では、データボルトモデリングについて説明します。データボルトモデリングは次の3つのコンポーネントから成り立っています。それはずばり、Hubs ハブLinks リングSatellites サテライトの3つです。
それでは1つずつ簡単に説明していきます。

Hubsとはデータの大きな固まりを表したものです。例えば、顧客とか店舗などになります。

次にLinksです。リンクはHubsとHubsのリンクを管理するテーブルです。データボルトモデリングは柔軟性を持たせるために普段はERで定義するリレーションをリンクテーブルで定義しています。これにより第3正規形ではテーブルの設計変更が発生する場合でもリンクのデータをかえることにより柔軟に変更に対応できます。

最後にSatellites.これは通常にデータの属性を保持するテーブルです。もちろん、ハブとリンクさせるのですが、1つのHubやlinkはサテライトを複数持つことができます。

例えば、既存システムで顧客情報をマーケティングシステムおよびセールスシステムのそれぞれで持っていれば、データボルトモデリングでは名寄せやクレンジングはせずにサテライトをそれぞれ1つずつ作って、顧客ハブの下にそれぞれもたつことができます。これですべてのデータをそのまま保持できるのです。

まだ、詳しくは調べていませんが、この設計によりETLの処理もある程度パラレルで処理ができるので高速で処理ができるようです。

ビックデータを保持する時代この技術は非常に有効だと思います。

顧客データのデータマッチング方法テクニック

実務でよくある問題に顧客情報のマッチングがあります。例えば、データウェアハウスの構築をした際に複数の業務システムで顧客を管理しており、それを1つのマスターデータとしてデータウェアハウスで管理したい、などです。ほかにも単純にAのデータとBのデータをマッチングしたいという要望もあるかもしれません。

この辺のデータマッチングやクレンジング機能は欧米で発達しました。欧米は英語圏なので日本語の漢字などの問題が非常に少ないので比較的単純にできます。その点、日本語は漢字、全角、半角の問題などあって非常に厄介ですよね。

今回は、簡単にできる顧客データマッチングの方法を紹介したいと思います。

通常データマッチングは、データのクレンジング(フォーマットの統一、全角/半角の統一、漢数字の数字変換など)→データマッチングの順で行います。今回はデータマッチングの部分に的を絞って記載します。

顧客マッチングで利用するデータと言えば、顧客名、住所(郵便番号を含む)、電話番号です。まずはこれをクレンジングします。そのあとのマッチングですが、単純に完全一致にしたり、マッチング条件を緩くしすぎるとマッチング精度に問題ができます。そこで利用するのが、じょじょにマッチング要件を緩くしていく方法です。例えば、AデータとBデータがあったとします。まず、顧客名、住所、電話番号の完全一致でマッチングします。そして、マッチングしなかったAデータとBデータを抽出して今度は、少し緩い条件、例えば、顧客名部分一致、住所、電話番号などにします。そしてその後はさらにマッチングしなかったデータをどんどん条件を緩くしてマッチングしてきます。

この方法であれば、マッチング精度が高いものからマッチングしていくので精度も高くなります。また、実際の方法ですが、Accessを利用して、SQLでマッチングしていけば簡単にできます。マッチングしなかったデータはLEFT JOINやRIGHT JOINでNULLの情報を指定することで抽出できます。

第3回:データウェアハウスアーキテクチャ(2):キンボールディメンショナルデータウェアハウス

さて、今回はデータウェアハウスアーキテクチャの「キンボールディメンショナルデータウェアハウス」について説明いたします。

ディメンショナルデータウェアハウス
ディメンショナルデータウェウハウスアーキテクチャは、ラルフ・キンボールによって提唱されているアーキテクチャです。ラルフ・キンボールはディメンショナルモデリング、いわゆるスタースキーマモデルを提唱した人で、データウェアハウスのグルの一人として数えられています。キンボールグループの創始者で、キンボールユニバーシティと称して、セミナーを開催しており毎年多くの人が参加しています。

さて、ディメンショナルデータウェアハウスアーキテクチャですが、これは簡単にいってしまえば、ディメンショナルモデリング、つまり、スタースキーマでデータウェアハウスを構築することです。インモンの提唱しているインフォメーションファクトリモデルでは、正規化されたセントラルデータベースがあり、そこから部署向けに作られたデータマートを構築するアーキテクチャですが、キンボールではデータマート自体がデータウェアハウスとなります。

データウェアバスアーキテクチャ
キンボールはこのスタースキーマで構築されたデータマート群を共通のディメンショナルテーブルで結び、それをデータウェアバスアーキテクチャと読んでいます。インモンのセントラルデータベースにあたるデータはステージングエリアで蓄積されるイメージです。

トップダウンとボトムアップアプローチ?
インモンモデルとキンボールモデルを対比して、インモンモデルはトップダウンアプローチ、キンボールモデルはボトムアップアプローチと称されることがあります。確かにインモンモデルは一気に導入、キンボールモデルは必要なデータマートから少しずつ作っていくのに便利ですが、キンボールモデルでもトップダウンで構築することもできます。

インモンモデルとキンボールモデル どちらがいいの?
よく聞かれる質問に、では実際どっちのモデルを採用したらよいのか?というのがあります。難しい質問ですが、どちらかにするかは会社の規模やデータ分析の成熟度によると思います。インモンモデルはどうしても大きなシステムになり、費用がかかってしまうので、小規模な会社の場合はキンボールモデルができしていると思います。
ただ、一般的にはこの両方を取り入れたハイブリッド形式が多いようです。

キンボールアーキテクチャ本
キンボールも多くの書籍を出版していますが、日本語に翻訳されている本は非常に少ないです。現在のところ2冊翻訳されています。


これは有名なディメンショナルモデリングを解説した本ですが、残念ながらすでに日本語版は絶版です。オリジナルはすでに第2版が出ていますので、英語が読める人はこちらを読みましょう。




こちらはWebサイトに特化したデータウェアハウスの構築本です。


次回は、第3のアーキテクチャ「データボルトモデリング(Data vault modeling)」について解説します。

SAP関連書籍の探し方

SAPは日本でも広くしようされているERPソフトウェアです。
でも、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の本なので、信頼性も高いと思います。
なんといっても私は本のデザインがとても好きです。かっこいい。





2011年5月1日日曜日

第2回:データウェアハウスアーキテクチャ(1):インモンのコーポレートインフォメーションファクトリー

今回から3回にわたって、データウェアハウスのアーキテクチャについて説明します。

データウェアハウス業界では昔からアーキテクチャについて大きく2つのグループに分かれており、どちらのアーキテクチャモデルがよいかが争っています。その2つのグループはインモンが提唱する「コーポレートインフォメーションファクトリー」とキンボールが提唱する「ディメンショナルデータウェアハウス」の2つです。本コラムでは、この2つのアーキテクチャモデルともう1つ有力な:データボルトマネジメントモデルの3つについて紹介いたします。

今回はインモンの「コーポレートインフォメーションファクトリー」について説明します。

コーポレートインフォメーションファクトリー
コーポレートインフォメーションファクトリーとは、データベースの父と言われるビル・インモンが提唱したアーキテクチャの構造です。では、どのようなアーキテクチャかというと、エンタープライズデータウェアハウスという企業のすべてのデータを集めたセントラルデータベースを構築し、そこから各部署で分析に必要なデータをデータマートとして、抽出、構築して分析はそのデータマートに対して分析をおこなうというものです。

エンタープライズデータウェアハウスは、通常のデータベース設計で使用される正規化を利用して構築されます。クエリパフォーマンスが悪くなるためこちらでは直接分析クエリの実行は行いません。データマートは、非正規化し、データウェアハウスの分析に適したディメンショナルモデリングで構築を行います。ディメンショナルモデリングについては第5回〜第9回で詳細に説明を行います。

データウェアハウス 2.0
また、最近インモンはデータウェアハウス2.0を提供しています。2.0を利用するのは、Web 2.0の影響でずいぶんはやりましたね。では、データウェアハウス2.0はインフォメーションファクトリーとどう違うかというと、全体では大きな違いはありません。大きな特徴と言えば、メールやWeb、ツイッターのつぶやきなどの非構造化データを考慮していることでしょう。企業にとって、このような非構造化データの分析はますます重要になってきています。まだ、企業での需要はそんなに多くないようですが、今後データウェアハウスの構築の際に考慮が必要になってくると思います。

うれしいことにインモンの本については日本語版があります。より詳しい内容を知りたい人は下記の本を読むことをお勧めします。


ただ、上記の本は出版されてから年月がかなり経っていますので、英語が読める人は下記のインモン本をお勧めします。


データウェア2.0を知りたい人はこちら。

2011年4月30日土曜日

第1回:業務データベースと分析データベース

皆さん、こんにちは。
今回は第1回ということで、予定どおり、業務データベースと分析データベースについて説明したいと思います。

業務データベースと分析データベース
データベースをデータの利用という観点から考えると、「業務データベース」と「分析データベース」という2種類のデータベースに分けることができます。

業務データベースはその名の通り、業務で利用するデータベースです。英語で、Operational databaseと言います。人事データベース、会計データベース、販売管理データベースなどが業務データベースにあたります。簡単に言ってしまえば、そのデータベースがないと業務自体成り立たないデータベースのことです。業務データベースのデータは業務が完結してしまえば、データが不要になりますので、データの保持期間は短くなります。データは挿入(Insert), 更新(Update), 削除(Delete)が中心となります。また、業務に利用するデータベースなので、明細の情報に素早くアクセスできる必要があります。

一方、分析データベースとは、分析に利用するデータベースです。英語でAnalytical databaseと言います。データウェアハウスはこの分析データベースにあたります。当然、分析がメインですので、データの保持期間が多く、大量のデータを保持します。データの変化にも着目しますので、変更履歴を保持することとなります。分析が目的ですので、データは挿入(Insert)が中心となります。また、分析に必要となるレポーティングを提供するので、データベースのレスポンスは業務データベースと比べて、レスポンスタイムの許容時間は大きくなります。

業務データベースと分析データベースは分ける必要があるか?
業務データベースと分析データベースは分離するのが、一般的です。これは上で説明したようにデータベースの利用目的が異なるためです。仮に業務データベースと分析データベースを一緒にした場合、分析に利用するクエリやプログラムはサーバに大きく負荷がかかるため業務データベースに支障をきたします。最悪の場合、業務が遅れるということもありえます。また、分析データベースは様々なデータの関連性を見るため、様々n業務データベースを1つの場所にまとめる目的もあります。
これによりキャンペーンと売上の関連性Webの利用と売上の関連性などの分析が可能になります。たまに業務システムで分析機能も網羅しようとし、肥大化してしまったシステムを見ることがありますが、システムメインテナンスが膨大になり、分析も満足にできない状態です。そのため、業務データベースと分析データベースは必ずわけましょう。

分析データベースには業務データベースと違ったアーキテクチャ、テクニックが必要となる
上記で説明したように分析データベース、つまりデータウェアハウスは大量データを保持し、大量データを分析処理する必要があります。そのため、その要件を満たすために業務データベースとは違ったアーキテクチャ、データモデリングテクニックが必要となります。たとえば、業務データベースに正規化のリレーショナルモデリングのテクニックがあるように、分析データベースにはスタースキーマと呼ばれるテクニックがあります。各ベンダーが販売しているデータウェアハウス、BI関連ツールもデータウェアハウス用のテクニックを前提に開発されています。そのため、これらのテクニックをすることはこれのツールを最大限に利用するための良いバックグランドとなります。

次回以降では、データウェアハウスのアーキテクチャ、モデリングテクニックなどを紹介していきます。

第0回:自己紹介とコラム紹介

皆さん、こんにちは。SHIMOと申します。
これから21回にわたって、「データウェアハウス/BI技術を学ぼう!」と題して、データウェアハウス/BI技術についてのコラムを掲載していきたいと思います。今回は、コラム掲載の最初ということで、第0回と称して、自己紹介と掲載するコラムの全体像について記載したいと思います。

自己紹介
では、最初に自己紹介。改めまして、名前はSHIMOともうします。
経歴ですが、大学を卒業後、システムインテグレータに勤務して、Webシステムを中心に、システムエンジニアとして勤務していました。その後、アメリカのソフトウェアを日本市場に販売するソフトウェアの代理店会社に転職し、そこでマーケティング部門のITスペシャリストして勤務しました。その後、さらに転職し、現在某外資系消費財メーカーのシステム部門でシステムアナリストして勤務しています。長らく、マーケティングシステムのプロジェクトを担当しておりましたが、現在はセールシステムのデータウェアハウス/BIを担当しています。

日本語で読めるデータウェアハウス/BI技術の情報が少ない
現在の会社に勤務してから、データウェアハウス/BIについての知識が必要になり、勉強し始めました。大学を卒業して以来、システムの勉強は書籍などを利用して独学を中心に勉強してきましたので、早速書籍を購入して独学でデータウェアハウス、BIの勉強を始めることとしました。しかし、日本語で読めるデータウェアハウス/BI技術情報が非常に少ないことに気づきました。また、日本語で読めるものは、概要を扱ったものが多く、実際に設計をしてデータウェアハウスを構築するレベルが勉強できるものはほとんどありませんでした。Webサイトで情報を探してみましたが、それぞれの製品に特化した情報が多く、私が臨んでいた情報を提供するサイトはありませんでした。そんな中で、アメリカでは非常に優れたデータウェアハウス/BI技術に関する書籍が多く出版されているのに気づきました。早速、その多くを購入し、すこしずつ読み進めていくとデータウェアハウス/BIには昔から優れた設計技術などが考案されており、各会社が販売している製品もそれらの設計思想をもとに開発されており、それらを学ぶことによりより生産性が高まることがわかりました。

優れたデータウェアハウス/BI技術を広げたい
しかし、それらの優れた設計技術などは日本ではあまり広まっていないようです。何度がデータウェアハウス/BI技術を担当しているSEの方にお会いしましたが、業務システムのテクニックをそのまま、データウェアハウスに利用しており、各会社の製品ツールも使いこなしているレベルにほど遠いことがわかりました。
そこで、このコラムでは、21回にわたって、データウェアハウス/BIにおける主要トピックスについて、説明をしたいと思います。このコラムが皆様がデータウェアハウス/BIを構築するにあたって少し役に立てば幸いです。

コラムの全体像
このコラムでは、全21回にわたって、データウェアハウス/BI技術について解説します。これがすべてではありませんが、どうしても知ってほしいトピックスはある程度カバーしているのではないかと思います。
予定している内容は下記となります。

コラム内容:
データウェアハウス基礎
第1回:業務データベースと分析データベース
第2回:データウェアハウスアーキテクチャ(1):インモンのコーポレートインフォメーションファクトリー
第3回:データウェアハウスアーキテクチャ(2):キンボールディメンショナルデータウェアハウス
第4回:データウェアハウスアーキテクチャ(3):データボルトモデリング
データウェアハウスモデリング
第5回:ディメンショナルモデリング:スタースキーマ
第6回:ディメンショナルモデリング:階層とスノーフレーク
第7回:ディメンショナルモデリング:ディメンション設計:スローリーチェンジングディメンション
第8回:ディメンショナルモデリング:ファクト設計:トランザクション、スナップショット、アキュムレーションスナップショット
第9回:ディメンショナルモデリング:ファクト設計:ファクトレスファクトテーブル
ETL
第10回:ETL34サブシステム 1-10
第11回:ETL34サブシステム 11-22
第12回:ETL34サブシステム 23-34
第13回:ETLチェンジデータキャプチャ
OLAP
第14回:ROLAP,MOLAPの違い
第15回:MDX超入門
Data Warehouse/BI導入
第16回:Data warehouse/BI導入の勘どころ
製品紹介
第17回:マイクロソフト製品
第18回:SAP製品
第19回:Open souce Pentaho
データウェアハウス用語
第20回:データウェアハウス/BI用語解説
知識体系
第21回:DMBOKの紹介

最初にデータウェアハウスの基本的知識について解説し、データモデリング,ETL,OLAPについて解説します。これでひととおりカバーできますが、具体的な製品イメージがあったほうがよいと思いますので、主要な製品について解説したいと思います。最後に用語と知識体系についてちょこっと説明します。

あくまで予定ですので、書いていくうちに内容がどんどん膨らむかもしれません。内容が膨らんでしまった場合は、適宜内容をわけていきたいと思います。

それでは、次回より第1回を掲載します。

データウェアハウス/BI技術についてのコラムを掲載

このブログサイトで、データウェアハウス/BI技術について紹介、説明してきましたが、コラムというかたちで体系的にまとめたものを掲載していきたいとおもいます。
コラムタイトルは「データウェアハウス/BI技術を学ぼう!」です。
データウェアハウス、BIの主要トピックをメインに解説していきたいと思います。

2011年4月26日火曜日

マイクロソフトのデータウェアハウス、BIソリューション

マイクソフト、されど、マイクロソフト。
マイクソフトが嫌いな人は多いですが、会社で一番使われているはマイクロソフトです。
しかも、マイクロソフトの製品を既に使っているので、使い勝手などのなれについてはやっぱりマイクロソフトに軍配があがります。

というわけで、マイクロソフトの製品でデータウェアハウス、BIソリューションを実施した場合の製品構成について書いてみたいと思います。

まずはデータベース。これはなんといってもSQL Server 2008 R2です。しかし、今度の課題はパフォーマンスでしょうか。やっぱり、テラデータやネティーザなどの専用データベースにくらべるとちょっと感は否めません。しかし、パラレルデータベースなど新製品がどんどん出てきているので、今後に期待です。

次にETLツール。これは、SQL Server Integration Serviceという製品になります。通常SSISなんてよばれます。Slowly Changing Dimensionなど一通りの機能は備わっていますが、弱いのが、メタデータ管理。メタデータをXMLで出力できるのですが、インパクト分析などがブジュアルでみる機能がありません。XMLファイルを自分で検索して分析する必要があります。今後に期待です。

次はOLAPデータベース。これは、SQL Server Analysis Serviceとなります。これは非常にいいツールです。あと、Excelからピボットでアクセスできるので非常にユーザフレンドリーです。

次は定型レポート。これはSQL Server Reporting Serviceとなります。私は使用したことはありませんが、おそらく定型レポートを作成するには十分な機能がそろっているようです。

さて、最後にマイクロソフトの強みですが、なんといってもコピーがうまいことでしょう。
豊富な資金がありますし、ほかのベンダーのいい機能をどんどん取り込んでいますので、どんどん進化していくと思います。
マクロソフトはトータルで安いので、おすすめです。

データウェアハウス、BIの開発方法について

またもや、コメントをいただいていることがわからず、そのままとなっておりました。
たいへん失礼いたしました。
さきほど、コメントについて返信をしたのですが、データウェアハウス、BIの開発、導入方法についての質問をいただいていたのでここでちょっと経験と持論を展開させていただきたいと思います。

データウェアハウス、BIの導入方法ですが、基本的にはスパイラルやアジャイルなどの繰り返して、改良する方法がいいと思います。理由としては、ユーザもはっきりとした要件を示すことができませんし、具体的なイメージがないので、とにかく作って直していくという方法がよいと思います。
また、データウェアハウス、BIは投資効果がわからないので、最初から大きな投資をするリスクがあります。ということで、実際使ってみて効果があったら徐々に増やしていくのがセオリーですね。
ただ、問題があります。それは。。。非常に重要な仕事なのにマネージャにあまり目立たないことです。ユーザが欲しいデータをタイムリーに提供していくとユーザに非常に喜ばれるのですが、マネージャにはいまいち目立ちません。なので、いつも評価はいまいち。。。まあ、仕方ないですね。とにかく、ここはシステム部門の腕のみせどころです。世の中のデータウェアハウス、BI担当の皆様、がんばりましょう。

あと、既にエクセルやアクセスなどで会社のBI成熟度が高い場合は、フォーターフォール型も可能です。しかし、環境がどんどんかわっていくので、運用での見直しも必要ですね。

The Microsoft Data Warehouse Toolkitを読みました

早速、今年の3月に出たばかりの「The Microsoft Data Warehouse Toolkit」を読み終えました。
本書はData warehouseのコンサルティングで有名なキンボールグループが出版しているツールキットシリーズのマイクロソフト版です。
特徴はなんといっても、キンボールメソッドをマイクロソフト製品を利用してどう応用していけばよいかを説明しているところです。
キンボールメソッドを解説してそれからマイクロソフトの製品の利用法を説明しています。
ただ、中心はあくまでキンボールメソッドをマイクロソフト製品で実現するには?に焦点が絞られていますので、各マイクロソフト製品の
詳細な利用、開発方法を知りたい人は別の本を読んだほうがいいでしょう。
ただし、その際にまずこちらの本を読んでから、詳細を勉強することをお勧めします。

マイクロソフトを嫌いな人は多いですが、そうはいってもマイクロソフトです。
おそらく、手軽にBIを構築したい人は、コスト面から言って非常に有力な候補だと思います。

マイクロソフトのSQL Serverを利用して、BIを構築する予定の人、または、すでに構築している人はぜひ読みましょう。
また、他の製品を利用している人でもキンボールメソッドをどう製品に利用するかについて大いに参考になると思います。

英語のみで、日本語翻訳版は出版されていませんが、平易な英語ですので英語はできる人はぜひチャレンジを。。。


2011年4月25日月曜日

ETLに必要な34の機能とは?

データウェアハウスの構築に欠かせないのがなんと言ってもETLツールです。
ETLツールとは、Extract, Transfer, Loadの略で、簡単にいってしまえば、
データウェアハウスの元データとなるソースシステムからデータを取ってきて、きれいにしてデータウェアハウスに
いれるという機能です。
と、言われてもピンとこないですよね。
では、具体的にETLツールにはどのような機能があるのでしょうか。

実は、データウェアハウスのコンサルティングで有名なキンボールグループでETLに必要なサブシステムについて
情報を提供しています。
今回はそのキンボールリストにならって各サブシステムについて解説していきたいと思います。
サブシステムが34もあるので、ちょっと長くなりますがお付き合いください。

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)
ぞれぞれのディメンションで必要となるサロゲートキーを生成する機能。

11.階層管理(Hierarchy Manager)
ディメンションの階層管理機能。

12.スペシャルディメンション管理(Special Dimensions Manager)
ジャンクディメンションやミニディメンション、日付ディメンションなどの特殊ディメンションの管理機能。

13.ファクトテーブル構築
主要な下記3つのファクトテーブルの構築を行う機能。
・トランザクション
・ピリオディックスナップショット
・アキュムレーションスナップショット

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ジョブの管理。

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などのツール選定の評価項目として利用できるなど、なにかと便利です。

ぜひ、利用しましょう。