データマートとレポートキューブの違いは何ですか？
これらの用語はいたるところに使用されており、明確な定義はわかりません。私はデータマートが何であるかを知っていると確信しています。また、BusinessObjectsやCognosなどのツールを使用してレポートキューブを作成しました。
また、データマートは単なるキューブのコレクション以上のものであると人々に言われました。
また、データマートはレポートキューブであり、それ以上のものではないと人々に言われました。
あなたが理解している違いは何ですか？
Cube は、非常に具体的なものを意味する可能性があります（そして間違いなくそうすべきです）-OLAP OLAPサーバーを介して提示されるアーティファクトMS Analysis Services やOracle（nee Hyperion） Essbase など。ただし、使用頻度ははるかに低くなります。= OLAPこの種のキューブは、標準のリレーショナルデータベースとは異なるAPIを使用するキューブ対応のクエリツールを使用します。通常、OLAPサーバーは独自の最適化されたデータ構造を維持します（既知as [〜＃〜] molap [〜＃〜] ）、ただし、リレーショナルデータソース（ として知られている）のフロントエンドとして実装できます。 ）[〜＃〜] rolap [〜＃〜] ）またはさまざまなハイブリッドモード（ [〜＃〜] holap [〜＃〜] ）
具体的には、「cube」を使用して、SSASなどのOLAPサーバー上のキューブを参照します。
Business Objects は、1つ以上のソース（リレーショナルデータベース、OLAPキューブ、フラットファイルなど）を介してデータをクエリし、 -インタラクティブなスライスアンドダイスアクティビティをサポートするために使用する MicroCube と呼ばれるメモリデータ構造。AnalysisServicesとMSQueryは キューブ（.cub）を作成できます。 ）ファイル は、ASクライアントソフトウェアまたはExcelで開き、同様の方法でスライスおよびダイシングできます。IIRC最近のバージョンのBusiness Objectsでは、.cubファイルも開くことができます。
ビジネスオブジェクツは、真のOLAP ProClarityなどのシステムと などのアドホックレポートツールの間のどこかにある「半構造化レポート」スペースにあると思います。レポートビルダー 、 Oracle Discoverer または Brio 。クエリパネルへのラウンドトリップにより、純粋なものとしてやや不格好になります。 stream-of-thought OLAPツールですが、従来のレポートにはないレベルのインタラクティブ性を提供します。BusinessObjectsのスイートスポットは2つの場所にあると思います。スタッフは必ずしもSQLに精通しているとは限らず、データへのドリルダウンを可能にするインタラクティブな形式で配信されるスケジュールされたレポートを提供します。
「データマート」 もかなり緩く使用されている用語であり、データウェアハウスシステムのユーザー向けデータアクセスメディアを意味します。定義には、レポートツールとメタデータレイヤー、レポートレイヤーテーブル、またはキューブやその他の分析システムなどの他のアイテムが含まれる場合と含まれない場合があります。
私は、データマートをレポート作成元のデータベースと考える傾向があります。特に、データウェアハウスアーキテクチャ全体の定義が容易なサブシステムである場合はそうです。ただし、特にビジネスオブジェクトやOLAPシステム）などのアドホックレポートツールがエンドユーザーにアクセスできる場合は、ユーザー向けのレポートレイヤーと考えるのが非常に合理的です。データを直接。
「データマート」という用語はやや曖昧になっていますが、伝統的に組織の情報システムの主題指向のサブセットに関連付けられています。データマートは、OLAPなどの多次元テクノロジの存在を明示的に意味するものではなく、データマートは要約された数値データの存在を明示的に意味するものでもありません。
一方、キューブは、データが多次元の命名法（通常はOLAPテクノロジ））を使用して提示され、データは一般に複数の階層の共通部分として要約されることを意味する傾向があります。（つまり、家族の正味価値と個人の正味価値およびその間のすべて）一般に、「キューブ」は非常に具体的なものを意味しますが、「データマート」はもう少し一般的である傾向があります。
OOP話すと、データマートの「has-a」キューブ、「has-a」リレーショナルデータベース、「has-a」気の利いたレポートインターフェイスなどと正確に言うことができると思いますが…これらの個別の「is-a」データマートのいずれかを言うのは正しくありません。データマートという用語はより包括的です。
名前が示すように、キューブは構造化された多次元データセットです（通常、3次元はそれぞれキューブの3つの側面を表します）。データマートは単なるコンテナであり、それ自体は構造ではありませんが、ディメンションとファクトで（テーブルとして）フラットに編成されたデータセットが含まれています。
キューブの構造により、キューブのさまざまな次元に沿ったデータの視覚化または概念化が容易になります。したがって、ほとんどのビジネスアナリストまたは開発者は、キューブのクエリと操作が簡単であると感じています。
データマートはテーブルがたくさんある単なるコンテナなので、ユーザーは、データを照会および分析する前に、まず次元構造を概念化して理解する必要があります。
データマートは、特定のビジネスプロセスのデータのコレクションです。データの保存方法は関係ありません。キューブは、行と列のあるテーブルとは異なり、特別な方法で多次元でデータを格納します。 OLAPデータベースのキューブは、従来のデータベースのテーブルのようなものです。データマートはテーブルまたはキューブを持つことができます。キューブは、事前に集計を事前に計算するため、分析が高速になります。
データマートとは、従来、統計、予算編成、パフォーマンスと売上のレポート、およびその他の計画活動のためにアナリストが使用する、通常は日付/時刻指向の静的データを意味していました。
キューブはOLAPデータベースであり、OLTPデータを、SQLではないクエリ言語を使用する静的な日付/時刻指向のスキーマにかなり徹底的に変換します。ただし、データマートタイプの質問に回答するために特別に構築されています。テーブル、列、行ではなく、メジャー、ディメンション、スタースキーマなどの用語を使用します。最もよく知られている例は、スプレッドシートのピボットテーブルです。
覚えておいてください：
データウェアハウジングは、レガシーおよびトランザクションデータベースシステムからデータを取得し、それをユーザーフレンドリーな形式で整理された情報に変換して、データ分析を促進し、事実に基づくビジネス上の意思決定をサポートするプロセスです。
データウェアハウスは、ソースデータを抽出、クリーンアップ、適合、およびディメンションデータストアに配信し、意思決定を目的としたクエリと分析をサポートおよび実装するシステムです。
キンボール例：データマートは、アトミックデータの基盤に基づいて、組織全体のデータのプロセス指向のサブセットとして一貫して定義されています。これは、予想されるユーザーの質問ではなく、データ測定イベントの物理にのみ依存します。
- データマートは、部門のデータの見方ではなく、データのソースに基づいています。
- データマートには、最低レベルへのドリルダウンをサポートするために必要なすべてのアトミックな詳細が含まれています。
- データマートは、集中管理または分散化できます。
正しい定義
- プロセスベース
- アトミックデータファンデーション
- データ測定
誤解された定義
- 部門ベース
- 集計データのみ
- ユーザーの質問に基づく
マシューに同意します。企業内のさまざまなアプリケーションで使用される一般的なデータとマッピングを格納するデータソースには、「データマート」という用語を使用する傾向があります。データマートには測定可能なデータを保存しないため、データマートはキューブの複数のデータソースの1つと見なされます。ただし、これはweの方法です。データマートに測定可能なデータを保存することを妨げるものは何もないと確信しています。
私にとって、データマートは、データが比較的フラットで使用できない形式でダンプされる場所にすぎません。
Cubeはそのデータを取得し、それを踊らせています。