• 戻る（SQL Server、AzureのBI系サービス）
  • SSAS
  • SSMS / SSIS / SSRS
  • Power BI / Azure Data Explorer / Azure Synapse

SQL Server Analysis Services(SSAS:分析サービス) は、
SQL Server の標準機能として搭載されている、"データ分析" のための
サーバ機能（自習書シリーズ「Analysis Services 多次元モデル入門」より引用）。

• AD(Active Directory) のユーザ セキュリティを前提とするので、
  AD 環境が必須

• 下記ビジネス インテリジェンス（BI）アプリケーション用の機能が用意されている。

  • オンライン分析処理 (OLAP) 機能（ビジネス インテリジェンス（BI））

  • データ マイニング機能（ビジネス インテリジェンス（BI））

• Excel のピボットテーブルのデータソースとして利用できる。

• Oracle や DB2 など、ほかのデータベース製品のデータをもとに
  OLAP キューブを作成することもできる

  • Oracle に直接接続するのではなく SQL Server で
    リンク サーバーにするケースもある
    • 参考：SQL Server で Oracle へのリンク サーバーのセットアップおよび
      トラブルシューティングを行う方法（2011 年頃）
      （SQL Server リンクサーバ機能）

• 以下の 3 つのモードを用意している
• インストール時のオプションで設定し、変更はできない。

移行メモ（正誤）: この 3 つはインストール時に決まるものではない。
MOLAP / ROLAP / HOLAP は
パーティション単位で設定するストレージ モードであり、
後から変更できる。
インストール時に決まって変更できないのは、
次節の**サーバー モード（多次元／表形式）**のほうである。
2 つの節の説明が取り違えられていると思われる。

• 集計された実体キューブを構築（コンパイルのイメージ）し、クライアントが参照。
• 直接キューブに対して、読出しと書込みの両方ができる。
• 分析時にデータソースにアクセスしないので、応答時間が速い。
• データを変更した場合、キューブの再構築が必要。

• クライアントの要求に基づき、データソースにアクセスし、分析を開始する。
• データベースの性能がボトルネックになる。
• 実体キューブを構築しないので、データの変更を気にしなくて良い。

• MOLAP と ROLAP の属性を組み合わせたもの
• キューブは構築するが、構造だけでデータは格納しない（データのインデックスのみを保持）
• ※参考 パーティションのストレージ モードおよび処理

補足（使い分け）: 実務では MOLAP が既定にして第一候補である。
集計済みのため応答が速く、元 DB に負荷をかけない。
ROLAP は「リアルタイム性が要る」「データ量が巨大で
キューブ処理の時間が取れない」場合の選択肢だが、
元 DB への負荷とレスポンスの悪化を招きやすい。

• 以下の 2 つのモードを用意している
• インストール時のオプションで設定し、変更はできない。
• 動作モードによってモデル構造も異なる。

• SQL Server 7.0 の OLAP Services の頃から提供されている成熟された技術（モード）
• データ マイニング機能を利用できるが、スキル習得まで時間がかかる

• 2012 から追加されたインメモリで動作する高速な処理エンジン モード

• PowerPivot の処理エンジンを改良したものがサーバ上で動作するイメージ

• セルフ BI を目指したコンセプトと言われている

• 参考

  • テーブル ソリューションと多次元ソリューション (SSAS) の比較
  • BI Semantic Model ※ 本文の word ドキュメント（英語）

補足（2つのモードの違い）: 選択が後から変えられないため、
導入時の判断が重要になる。

	多次元モード	表形式モード
モデル	キューブ（ディメンション / メジャー）	テーブルとリレーションシップ
格納	ディスク（MOLAP 等）	インメモリ列ストア（VertiPaq）
クエリ言語	MDX	DAX（MDX も可）
学習コスト	高い	低い（Excel の関数に近い）
データ マイニング	あり	なし
書き戻し	あり	なし

現在の新規開発は表形式モードが標準である。
Power BI のデータ モデルは表形式モードと同じエンジンであり、
スキルが直結する。
多次元モードは保守モードに近く、新機能はほぼ追加されていない。

アクセス セキュリティをロールで設定可能で、
モデルによって設定箇所が異なる（サーバ ロールは同様？）。

• 大きく分けてサーバ ロール、データベース ロールがあり、
  グループ - グループ メンバ的な管理が可能
• オブジェクト毎に細かい設定ができ、例えばディメンションに対して
  見れるユーザと見れないユーザをロールによって制御することができる
• 参考
  • セキュリティ ロール (Analysis Services - 多次元データ)

• 多次元モデルと同じように設定可能。※ どこが違うのかは未調査

• 参考

  • ロール (SSAS テーブル)

補足（「どこが違うのか」）: 表形式モデルのロールは、
DAX 式による行フィルターで絞り込む方式である
（例: =[Region] = "East"）。
多次元モデルがディメンション メンバー単位で許可／拒否を指定するのに対し、
表形式は**行レベル セキュリティ（RLS）**の考え方に近い。

USERNAME() 関数と組み合わせると、
ログイン ユーザに応じて動的に絞り込む
動的行レベル セキュリティが実装できる。
Power BI の RLS も同じ仕組みである
（Elastic Scale, Elastic Database Poolの
Row-Level Security の補足も参照）。

• 多次元モデルが前提
• SQL Server Data Tools を使用
• 分析に適した接続可能な対象データベースがある

参考：自習書：Analysis Services 多次元モデル入門・
STEP 2. Analysis Services 多次元モデルの基本操作

• SQL Server Data Tools（Visual Studio）を起動し、プロジェクトを作成
• 「Analysis Services 多次元およびデータマイニング プロジェクト」を選択、
  基本項目（プロジェクト名）などを入力

• キューブの元となるデータを格納しているデータベース サーバに対して接続の設定をする
• プロバイダを指定することによって Oracle に接続する事も可能
• Windows サーバにプロバイダをインストールする事によって
  他のデータベースの接続も理論的には可能 ※ 未検証

• 基本的なビューのスキーマはウィザードで自動的に作成可能
  （キーがしっかり定義されていれば、インテリジェンスが自動でリレーションも作成する）
• 「テーブルの置換 > 名前付きクエリ」を実行すると、
  SQL エディタが表示され SQL を書くことができる
  （WHERE 句や JOIN も普通に使用できるので、
  ここで大福帳的なデータを作成することも可能）

• 必要に応じて、テーブル内の項目同士を式を使って演算したカラムを作成
• ※ 単価 * 数量 = [受注金額] など

• キューブ・ウィザードを使用して、ディメンションやメジャーを大まかに定義
• ※ 詳細な設定は後で一つ一つ行う必要がある。

• 分析軸となるディメンションの「属性」、「階層」を設定（設計）
• メジャーに対して、どの関連データの切り口で分析するか、
  どんな階層をもたせるかデザインする

キューブの処理を実行すると、

• 「MDX クエリ デザイナー」と呼ばれるツールでキューブを確認
• Excel の PivotTable のデータソースとして接続することで利用

できるようになる

補足（スター スキーマが前提）: 「データ ソース ビュー」で
大福帳を作れるとあるが、OLAP の性能を出すには
ファクト テーブル（メジャー）とディメンション テーブルに分けた
スター スキーマにするのが原則である。
これは表形式モデルや Power BI でも変わらない
（むしろ Power BI では強く推奨されている）。

• 名前付き計算はテーブルに設定してメジャーとして使用するが（※）、
  テーブルには設定せずにキューブ内に計算メジャーを作成し、同様な事ができる
  ※ 使用しないこともある
  • 難易度高でパフォーマンスが悪いが、
    組込みの集計関数を使用して特殊な計算ができる
    • 参考： メジャーおよびメジャー グループ
    • 参考： 集計関数の使用

補足（どこで計算するか）: 計算の置き場所は 3 通りあり、
上に行くほど速く、下に行くほど柔軟である。

場所	計算タイミング	性能
データ ソース（SQL / ETL）	事前	最速
名前付き計算（データ ソース ビュー）	キューブ処理時	速い
計算メジャー（MDX / DAX）	クエリ実行時	遅い

「難易度高でパフォーマンスが悪い」という本文の指摘どおりで、
可能な限り前段（ETL や SQL）で計算しておくのが定石である。

• 多次元モデルの場合、「書き戻し」と言って
  処理後のキューブのデータに対してメジャーの更新が可能
  • キューブ ＞ パーティションの設定で有効にする必要がある
  • Excel(Pivot Table) から利用する場合、あわせて Pivot Table オプションから
    「What-if 分析」を有効にする必要がある
• この機能をうまく利用すると、現在のデータを元に将来の予測増減データを更新保存し、
  予測シミュレーション的な事ができる
• 書き戻しで保存したデータは、[メジャーの格納テーブル名]_WriteTable と
  言う名前のテーブルに差分として格納される
  • 元々の値 100 を 101 に変更保存した場合、_WriteTable には 1 が格納される
  • 元々の値 100 を 99 に変更保存した場合、_WriteTable には -1 が格納される
    • PivotTable などで接続して確認すると、
      メジャーの格納テーブル（元テーブル）のデータと
      その WriteTable のデータが合算されて表示される
• 差分のトランザクションが保存されるため、
  更新回数が多いとレコード数が嵩んでいきパフォーマンスに影響する
  （自動で集約される事は無い）
  • 1 レコードは PivotTable の 1 セルに相当する
    • 1000 セル更新したら 1000 レコードのトランザクションが格納される
    • 毎日毎日更新したら、毎日毎日トランザクション データが増えていく
  • 書き戻しのデータを集約する方法はいくつかあるが、例えば tmp テーブルに
    WriteTable のデータをキーで Group かつ sum して格納しておき、
    さらに tmp と元テーブルとを合算したデータをあらたな tmp に作成後、
    元のテーブル データを消去、合算したデータを元のテーブルに入れると言った
    操作が必要となる（tmp テーブルはビューで代替しても良い）
• 参考： パーティションの書き戻しの設定
• 参考： Excel 2010 Writeback to Analysis Services（YouTube）

補足: 書き戻しは多次元モードにしかない機能であり、
表形式モードや Power BI には存在しない。
予算計画・シミュレーション用途で多次元モードが
今も選ばれる数少ない理由の一つである。

移行メモ（体裁）: 元ページには、この後に
「ToDo:」で始まるコメントアウトされた執筆予定メモ
（分析ツールとしての Excel PivotTable、開発言語、
SQL Server Data Tools と Management Studio の違い、
ADOMD.NET、ローカル キューブ）が含まれていたが、
本文ではないため移行対象外とした。

• エディション毎の機能サポートについては
  SQL Server の各エディションがサポートする機能を参照
  （SQL Server のエディション）
• 自習書シリーズ
  • Analysis Services 多次元モデル入門
  • Analysis Services 多次元モデル応用
  • Analysis Services によるインメモリ BI 入門

補足（最新化：SSAS の現在地）: 分析基盤の選択肢は
大きく広がっており、現在の位置付けは以下のとおり。

製品	位置付け
SSAS	オンプレミス。多次元／表形式
Azure Analysis Services	SSAS 表形式モードの PaaS 版（AzureのBI系サービス）
Power BI Premium / Fabric のセマンティック モデル	表形式エンジンの発展形。現在の主軸

Microsoft は Azure Analysis Services から
Power BI Premium（Fabric）への移行を推奨しており、
移行ツールも提供している。

一方で、多次元モード（MDX / キューブ）に相当する機能は
クラウド側に存在しない。
書き戻しやデータ マイニングを使っている資産は、
移行時に設計を作り直す必要がある点に注意。

---

Tags: 移行, データアクセス, SQL Server