多くの要因を考慮せずに、この質問に答えることはできません。
多くの人は、より新しくてより優れているため、表形式モデルに切り替える必要があると考えています。 しかし、これは原則的に非現実的または不可能です。 ただし、これについては後ほど説明します。
多次元モデル
多次元データベースには特定の構造があり、非常に迅速にレポートを生成できます。 昔々、多次元データベースを作成するためには、多次元モデルが唯一の解決策でした。 このモデルはSQL Server 2005以降変更されていません。AnalysisServicesの各リリースの新機能を見ると、ほとんどの革新が表形式モデルに関連していることが明らかになります。
表形式モデル
テーブルモデルはSQL Server 2012に登場し、積極的に開発されています。以降の各バージョンには新しい機能が含まれています。
テーブルモデルは別のエンジン（xVelocity）で実行され、適切なデータ圧縮に加えて、列ストレージ（多次元モデルは文字列ストレージを使用）を使用するため、列クエリを迅速に実行するように設計されています。 データはRAM（メモリ内モード）に保存されるため、サーバーに大量のメモリと非常に高速なプロセッサを搭載することが非常に重要です。 表形式モデルのディスクはそれほど重要ではありません。 表形式モデルの主な利点の1つは、その中の一部のクエリが高速に動作することです（たとえば、個別のカウントに基づく測定で非常に高速に動作します）。圧縮率は1/10（以下は圧縮原理の説明とのリンクです）一方、多次元モデルでは1/3のみです。 圧縮率はおおよその値で示されていますが、データに応じて変動する可能性があります。
ハードウェア
ほとんどの場合、多次元データベースに使用されるハードウェアは、表形式のモデルには使用できないことに注意してください。 表形式モデルは、RAMの量に直接依存します。 メモリが多いほど、パフォーマンスが向上します。 十分なメモリがない場合、表形式モデルは警告なしに動作を停止します。
CPU周波数は、表形式モデルにとっても非常に重要です。
繰り返しますが、表形式モデルの場合、ディスクは二番目に重要ですが、RAMの量とCPU速度は非常に重要です。
それで、どれくらいのメモリが必要ですか？ そのような表現があります-より良い！ しかし、それは非常に抽象的で理解するのは不可能です。もっと具体的なものが欲しいですよね？ 一方では、単純な式<Relational database size> / 10 * 2がありますが、テーブルデータベースに接続するユーザーがいることを忘れないでください。つまり、SSASはより多くのメモリを必要とします-要求をキャッシュするには、OSのメモリも必要ですおよびSQL Serverカーネルキャッシュ（SSASとリレーショナルデータベースが同じマシン上にある場合）。 テーブルモデルでは、計算されたテーブルと列を作成することができます。したがって、リレーショナルデータベースは以前のサイズのままですが、テーブルデータベースのサイズは増加します。
式の中で、データベースのサイズを2で割った結果はなぜですか？ デフォルトでは、バッファで処理が実行されるため（実際、テーブルデータベースの一時コピーがメインモデルの隣に作成されます）、メインモデルは引き続き存在し、変更されずに動作します（処理が正常に完了するまで、メインモデルデータはバッファからのデータ、エラーが発生した場合はすべて変更されないままになります）。 したがって、SQL Serverのエディションを選択するときは注意してください。 テーブルデータベースのサイズが5 GBを超える場合、標準エディション（ キャッシュを含む SSASの制限は16 GB）は、おそらく動作しません！ キャッシュが不足すると、ひどいブレーキがかかります。
必要なメモリ量に関する詳細な記事は、 こことここにあります。
表形式および多次元モデルの使用に関する統計
この記事のデータによると、ウェビナーの440人の参加者を対象に2つのモデルを比較する調査が行われ、そのうち212人（〜48％）が「どのモデルを使用していますか？
- 両方-61（〜29％）
- 多次元-75（〜35％）
- 別の-43（〜20％）
- 表形式-33（〜16％）
移行
すでに多次元モデルを使用していて、それが自分に合っている場合は、そのままにしておくことをお勧めします。 表形式モデルがニーズを解決できると信じる理由がある場合、移行について考えることは理にかなっています。 しかし、多次元から表モデルへの移行は簡単な作業ではありません。 基本的に、すべてを手動で行う必要があり、マジックコンバーターを使用して切り替える簡単な方法はありません。 SSIS、PowerShellなどのツールを使用して、カスタム移行ツールを作成できます。
また、多次元モデルには、表形式モデルではサポートされていない機能（ライトバックなど）があることも理解しておく必要があります。
表形式モデルでサポートされていない機能の完全なリストは、多次元モデルと比較して、 公式ドキュメントに記載されています 。 この記事では、機能をエミュレートするいくつかの方法について説明します 。
移行を開始する前に、これに注意してください。
新しいプロジェクト
新しいプロジェクトの場合、通常、多次元モデルでのみサポートされる機能が必要でない限り、表形式モデルを使用することをお勧めします。 これまでに分析に遭遇したことがない人にとっては、表形式モデルは通常のリレーショナルデータベースのように見えるため、より理解しやすくなります。 さらに、ほとんどの場合、完全に機能するには十分な機能がサポートされています。
推奨事項
それでも表形式モデルを使用することに決めた場合は、レーキを踏まない方法についてアドバイスさせてください。
テーブルモデルには計算列があります。 彼らの助けを借りて、どの測定でも、リレーショナルデータベースにないフィールドを追加し、計算式を書くことができます。 たとえば、Customersテーブルのフィールドに、隣接するテーブルに保存されている国と地域の名前を追加します。 計算列はテーブルデータベースに格納され、処理時に書き込まれます。
美しさ、ロジックはモデルのメタデータに格納されているため、ビューを修正してフィールドを追加する必要はありませんが、ニュアンスがあります。 それを理解するために、処理の段階を見てみましょう。
- リレーショナルデータベースからデータを取得する
- データ圧縮
- 計算値と指標の計算
処理の段階から、2つの問題が発生します。
- 計算列があると、処理時間が長くなります
- 計算列は圧縮されていません
すなわち 計算列は便利ですが、乱用しないでください。
指に関するこの記事では、データの圧縮方法について説明します。
表形式モデルの処理速度を上げるためのいくつかのヒント