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はデータウェアハウスに必要なアプリケーションがすべて１つになったパッケージ製品です。データベースはアプリケーションで隠されているので、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などのインメモリデータベースを利用することができますので、これを利用することにより大幅にレポートパフォーマンス改善することができます。ただし、高いです。

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