Translate

SASとPower BIは相性が悪そうだがDr.Sumとは良さそう

Power BIで使用出来るデータソースは沢山あるが、SASに対しては割とネガティブ




SASは囲い込みが酷くて、Power BIのデータマートに乗り換えるレベルで検討した方が良い。


言ってみれば、SAS自体がDWHであり、そんな簡単にMicrosoft社の製品に乗換えて欲しくは無いだろう。

SASに限らずDWH製品をリリースしているメーカーはどこも同じだと思うのが、ただ、Dr.Sum等、他のDWHはODBCや、SDKを使用したデータ取得としての手段は割と多い。

SASについては、完全に囲い込み製品体質と思われる為、基本的にデータソースに直接繋いで取得という方法よりも、CSVで連携した方が良いと思う。

特にSASのODBC接続製品(別途必要)は金額が何百万円という世界で、DWHからDWHへデータを渡すだけの為にしようするにはあまりにも高額過ぎる。

Dr.Sum、SQL Server等、SAS以外のDWHやデータベースを使用している場合は、追加でPower BIも活用するという方法が使える

特に、Dr.Sumを使用している場合、MotionBoadという製品を導入してデータ可視化を行う事が多いが、Power BIの方が可視化に対する機能としては比較にならない程優れているように感じた。

Dr.SumのDatalizerで、表形式での分析は割と行いやすいとして・・(ただデータ件数が多くなると弱く、データ粒度を諦めないとまともに使用出来ないシーンが多い)

Dr.SumのDatalizerだけでは、可視化が足りないと感じた場合は、Power BIは非常に良い選択と思われる。

作った帳票は、WEBでもスマホアプリでも閲覧操作が可能に加えて、帳票自体をコピーして、エンドユーザーが自由に書き換えると言う事も可能で、権限も、ワークスペースの権限を使用すれば上手くコントロールが出来る。

データの更新の自動化もオンプロミスデータゲートウェイと使用すると、とても簡単にデータ更新の自動化も行える。

データの集計処理自体もPower BIのPower Queryや、Power BIのDAXで組んだり等、物によっては、そもそもノンプログラミングで対応可能な機能も多く、とても便利だ。

ちにみに、データレコード単位でユーザーの権限コントロールをしている場合には、RLS(Row-level security ローレベルセキュリティ)を使用する事で、コントロールする事が可能だ。

RLSを組み込んだPower BIの帳票は、ワークスペースの権限が閲覧権限のみのユーザーが、セキュリティコントロールされたデータのみ閲覧可能となる。

Power BIは今、マイクロソフトが非常に力を入れている製品である為、進化もめまぐるしい。

最近では、DWHのようなデータマートの代わりになるレベルでPowerBIのデータマート(セマンティックモデルというらしい)も発展しており、今まで世の中にあるDWHはマイクロソフト社ののPowerBIに置き換えて行けるレベルに達したかもしれない。

乗り換えが遅れた場合には、導入されているDWH製品は保守的になり、外部からのデータ取得手段を制限していく対応も考えられるので、乗換えた方が良いと思ったら、早めに対応した方が良いのだろう。

このブログの人気の投稿

ACCESSでバーコードをスキャンして登録更新する簡単なサンプル

VBAのADOで「パラメーターが少なすぎます。xを指定してください。」と表示された場合の原因

ACCESSのVBAを実行するとACCESSが強制終了する事がある

DataSpiderのファイル処理が遅い原因は大体コレ

ACCESSでバーコードスキャンしたら自動でイベントを起こす方法

DataSpiderでお手軽に配列でマッチングするみたいな事をする方法

PostgreSQL 11 でpg_dumpallを使ってバックアップしたデータをリストアするとき文字化けの対処法

VBSでマクロの実行時に警告を非表示にする方法

pgAdmin 4が遅いのは仕方がない | PostgreSQL things.

ACCESSのVBAでADOを利用したバインド変数を利用したデータベース連携方法