しばらく前、たまたま新しい開発グループを組織しました。このグループは、友好的なソフトウェア会社でOLAPおよびBI製品の開発に従事することになっています。 グループは大学の新卒者で構成されているため、OLAPに関する最初の概念をできる限りアクセスしやすく 、データベースのプログラミングと操作の経験がある人がアクセスできるようにするために、「若い戦闘機の短期コース」を作成する必要がありました。

このパブリックドメインの概要を今すぐ広めてください。

この記事では、OLAP、ビジネスインテリジェンス、およびデータウェアハウスの概念が多少混同されていますが、実際には、境界線がどこに行くのかを理解することは困難です。 そして実際のプロジェクトでは、それだけでなく、すべてが並んでいます。 したがって、厳密に判断しないでください。

はじめに

通常、深刻な企業の情報システムには、データ、そのダイナミクス、トレンドなどを包括的に分析するために設計されたアプリケーションが含まれています。 したがって、上位の消費者が分析結果の主要な消費者になります。 このような分析は、最終的に意思決定を容易にすることを目的としています。 また、経営上の意思決定を行うためには、通常は定量的な情報が必要です。 これを行うには、企業のすべての情報システムからこのデータを収集し、一般的な形式に変換してから分析する必要があります。 これを行うには、データウェアハウス（データウェアハウス）を作成します。

データウェアハウスとは何ですか？

通常、分析値のすべての情報を収集する場所。 このようなリポジトリの要件は、OLAPの古典的な定義を満たしています。以下で説明します。

ウェアハウスには別の目標がある場合があります-すべての情報システム内の情報の整合性と関連性を維持するために、すべてのエンタープライズデータを統合することです。 T.O. ストアは分析的な情報だけでなく、ほぼすべての情報を蓄積し、ディレクトリの形式で他のシステムに戻すことができます。

通常、一般的なデータウェアハウスは、通常のリレーショナルデータベースとは異なります。 まず、通常のデータベースはユーザーが日常業務を行えるように設計されていますが、データウェアハウスは意思決定を行うように設計されています。 たとえば、商品の販売と請求は、トランザクションを処理するために設計されたデータベースを使用して実行され、数年にわたる販売動態の分析により、データウェアハウスを使用してサプライヤとの作業を計画できます。

第二に、通常のデータベースはユーザーの作業プロセスの絶え間ない変化の影響を受けやすく、データウェアハウスは比較的安定しています：通常、データベース内のデータはスケジュールに従って（たとえば、必要に応じて毎週、毎日、または毎時）更新されます。 理想的には、補充プロセスは、すでにリポジトリにある古い情報を変更せずに、一定期間だけ新しいデータを追加するだけです。

そして第三に、通常のデータベースは、ほとんどの場合、リポジトリに分類されるデータのソースです。 さらに、統計レポートなどの外部ソースによってストレージを補充できます。

ストレージはどのように構築されますか？

ETL-基本概念： 抽出、変換、読み込み。 3つの段階：

• 抽出-理解可能な形式で外部ソースからデータを抽出します。
• 変換-ソースデータの構造を、分析システムの構築に便利な構造に変換します。
• アップロード-リポジトリにデータをアップロードします。

別のステップ-クリーニング（データ）-統計的または専門的な方法に基づいて、非必須または誤ったデータを修正するプロセスを追加します。 「20011の販売」のような後のレポートを生成しないため。

分析に戻ります。

分析とは何ですか？

分析-意思決定のためのデータの研究。 分析システムと呼ばれる-意思決定支援システム（ DSS ）。

ここでは、DSSを使用した単純な一連の規制レポートと非規制レポートの違いを指摘する価値があります。 DSSでの分析は、ほぼ常にインタラクティブで反復的です。 つまり アナリストはデータを掘り下げ、分析クエリをコンパイルおよび調整し、構造が事前にわからないレポートを受け取ります。 MDXクエリ言語について説明するときに、以下で詳細に戻ります。

OLAP

通常、意思決定支援システムには、初期セットからのさまざまなサンプルの集計データを、知覚と分析に便利な形式（表、図など）でユーザーに提供する手段があります。 ソースデータをセグメント化する従来のアプローチでは、ソースデータから1つまたは複数の多次元データセット（ハイパーキューブまたはメタキューブと呼ばれることもあります）を抽出します。 （さらに、このようなデータはリレーショナルテーブルに格納できますが、この場合は、データの論理的な構成についてであり、ストレージの物理的な実装についてではありません。）各軸に沿って、属性はさまざまな詳細レベルを表す階層の形で構成できます。 このデータモデルにより、ユーザーは複雑なクエリを作成し、レポートを生成し、データのサブセットを受信できます。

複雑な多変量データ分析のテクノロジーは、 OLAP （オンライン分析処理）と呼ばれます。 OLAPは、従来のデータウェアハウスを編成する重要なコンポーネントです。 OLAPの概念は、1993年に、有名なデータベース研究者でありリレーショナルデータモデルの著者であるEdgar Coddによって説明されました。 1995年、Coddが規定した要件に基づいて、いわゆるFASMIテスト（共有多次元情報の高速分析）が策定されました。これには、多変量解析のアプリケーションに関する次の要件が含まれています。

• それほど詳細ではない分析を犠牲にしても、許容可能な時間（通常5秒以内）でユーザーに分析結果を提供する。
• このアプリケーションに固有の論理および統計分析を実行し、エンドユーザーがアクセス可能な形式で保存する機能。
• 適切なロックメカニズムと許可されたアクセス手段のサポートによるデータへのマルチユーザーアクセス。
• 階層および複数階層の完全なサポートを含む、データの多次元概念表現（これは主要なOLAP要件です）。
• ボリュームとストレージの場所に関係なく、必要な情報にアクセスできます。

OLAP機能は、オフィスアプリケーションでのデータ分析の最も単純な手段から始まり、サーバー製品に基づく分散分析システムで終わるさまざまな方法で実装できることに注意してください。 つまり OLAPはテクノロジーではなく、 イデオロギーです。

さまざまなOLAP実装について説明する前に、論理的な観点からキューブがどのようなものであるかを詳しく見てみましょう。

多次元の概念

Microsoft SQL Serverディストリビューションキットに含まれる、Northwindデータベースを使用します。これは、OLAPの原則を説明するために、卸売食品供給会社の取引業務に関する情報を格納する典型的なデータベースです。 そのようなデータには、サプライヤ、顧客、配送された商品とそのカテゴリのリスト、注文と注文された商品のデータ、会社の従業員のリストに関する情報が含まれます。

キューブ

たとえば、会社の注文が含まれているテーブルInvoices1を考えます。 このテーブルのフィールドは次のとおりです。

• 注文日
• 国
• 市区町村
• 顧客名
• 配送会社
• 製品名
• 商品の量
• 注文金額

このビューに基づいてどのような集計データを取得できますか？ 通常、これらは次のような質問に対する回答です。

• 特定の国の顧客からの注文の合計金額はいくらですか？
• 特定の国の顧客からの注文と、特定の会社からの注文の合計金額はいくらですか？
• 特定の年に特定の国の顧客から出され、特定の会社から提供された注文の合計金額はいくらですか？

このすべてのデータは、非常に明白なグループ化されたSQLクエリを使用してこのテーブルから取得できます。

このクエリの結果は、常に数値の列とそれを説明する属性のリスト（国など）になります。これは、1次元のデータセット、または数学言語ではベクトルです。

すべての国からの注文の合計コストとサプライヤーの会社によるその分布に関する情報を取得する必要があることを想像してください-既にサプライヤーが列ヘッダーにリストされ、国が列ヘッダーにあり、セルにある数字のテーブル（マトリックス）を取得します注文の量。 これは2次元のデータ配列です。 このデータセットは、 ピボットテーブルまたはクロス集計と呼ばれます 。

同じデータを取得したいが、まだ年のコンテキスト内にある場合、別の変更が表示されます。 データセットは3次元になります（3次の条件付きテンソルまたは3次元の「キューブ」）。

明らかに、測定の最大数は、集計データ（注文量、商品の数量など）を記述するすべての属性（日付、国、顧客など）の数です。

それで、多次元の概念とその具体化、つまり多次元立方体に行き着きます。 このようなテーブルは、「 ファクトテーブル 」と呼ばれます 。 キューブのディメンションまたは軸（ dimensions ）は、ファクトテーブルに存在するこれらの属性の個々の値によって座標が表現される属性です。 つまり たとえば、2003年から2010年までシステムで注文情報が維持された場合、この年の軸は8つの対応するポイントで構成されます。 3か国からの注文の場合、国の軸には3ポイントなどが含まれます。 国のディレクトリに含まれる国の数に関係なく。 軸上のポイントは、その「メンバー」と呼ばれます。

この場合の集計データ自体は、「メジャー」（ Measure ）と呼ばれます。 「測定値」との混同を避けるために、後者を「軸」と呼ぶことが望ましい。 メジャーのセットは、「メジャー」の別の軸を形成します（ メジャー ）。 ファクトテーブルには、メジャー（集計列）と同じ数のメンバー（ポイント）があります。

ディメンションまたは軸のメンバーは、1つまたは複数の階層（ 階層 ）で結合できます。 階層とは、例を挙げて説明します。注文からの都市は、地域、地域の地域、国の地域、大陸の国、または他のエンティティに結合できます。 つまり 階層構造があります-大陸- 国-地域-地域-都市 -5レベル（ レベル ）。 地区については、その地区に含まれるすべての都市のデータが集計されます。 すべての都市などを含むすべての地域の地域 なぜ複数の階層が必要なのですか？ たとえば、注文日が設定された軸で、階層Year-Month-DayまたはYear-Week-Dayに従ってポイント（つまり日）をグループ化することができます。どちらの場合も、3つのレベルがあります。 明らかに、週と月は異なる方法で日をグループ化します。 階層もあり、レベルの数は決定されず、データに依存します。 たとえば、コンピューターディスク上のフォルダー。

データの集約は、合計、最小、最大、平均、数量などのいくつかの標準機能を使用して実行できます。

MDX

多次元データのクエリ言語に移りましょう。
SQL言語は元々プログラマ向けではなく、アナリスト向けに設計されました（したがって、自然言語に似た構文を持っています）。 しかし、時間の経過とともにより複雑になり、今ではそれをうまく使用する方法を知っているアナリストはほとんどいません。 彼はプログラマーのツールになりました。 MDXクエリ言語は、Microsoftの荒野でかつての同胞Moysha（またはMoshe）Posumanskyによると噂されていましたが、もともとアナリストを対象としていましたが、その概念と構文（SQLに漠然と似ており、無駄です）混乱させるだけ）SQLよりもさらに複雑です。 それにもかかわらず、その基礎はまだ理解するのが難しくありません。

一般的なXMLAプロトコル標準のフレームワーク内で標準言語のステータスを取得した唯一の言語であるため、また、 PentahoからのMondrianプロジェクトの形式でのオープンソース実装があるため、詳細に検討します。 他のOLAP分析システム（たとえば、Oracle OLAPオプション）は通常、SQL構文拡張を使用しますが、MDXのサポートも宣言します。

分析データ配列の操作は、それらの読み取りのみを意味し、書き込みを意味しません。 T.O. MDXには、データを変更するための文はありませんが、選択節は1つしかありません-select。

OLAPでは、多次元キューブからスライスを作成できます。 データが1つまたは複数の軸に沿ってフィルター処理される場合、または投影 -キューブが1つまたは複数の軸に沿って「崩壊」する場合、データを集約します。 たとえば、国からの注文の合計を使用した最初の例は、国の軸上の立方体の投影です。 この場合のMDXリクエストは次のようになります。

select [Territory].[Cities by Countries].[All].Children on rows from [invoices1] 

ここに何がありますか？

選択はキーワードであり、美しさのためだけに構文に含まれています。
[テリトリー]は軸の名前です。 MDXのすべての固有名は角括弧で書かれています。
[国別都市]は、階層の名前です。 私たちの場合、それはCountry-City階層です
[すべて]は、階層の最初のレベル（つまり、国）の軸メンバーの名前です。すべては、軸のすべてのメンバーを結合するメタメンバーです。 このようなメタタームは各軸にあります。 たとえば、年の軸は「すべての年」などです。
子はメンバー関数です。 各メンバーにはいくつかの機能があります。 親など。 レベル、階層。それぞれ、祖先、階層内のレベル、およびこの場合にメンバーが参照する階層自体を返します。 子-このメンバーの子孫メンバーのセットを返します。 つまり 私たちの場合、国。
on rows-このデータをサマリーテーブルに配置する方法を示します。 この場合、行ヘッダーで。 可能な値は次のとおりです。列、ページ、段落など。 0から始まるインデックスで単純に示すこともできます。
from [invoices1]は、選択元のキューブを示しています。

すべての国が必要なわけではなく、特定の国が数か所しか必要ない場合はどうなりますか？ これを行うには、リクエストで必要な国を明示的に指定し、すべてのChildren機能を選択することはできません。

 select { [Territory].[Cities by Countries].[All].[Russia], [Territory].[Cities by Countries].[All].[Ukrain] } on rows from [invoices1] 

この場合の中括弧は、セットの宣言です。 セットはリストであり、1つの軸からのメンバーの列挙です。

次に、2番目の例のリクエストを作成します-プロバイダーのコンテキストでの出力：

 select [Territory].[Cities by Countries].[All].Children on rows [Shipper].Members on columns from [invoices1] 

ここに追加されました：
[Shipper] -軸;
.Membersは、その上のすべてのメンバーを返す軸関数です。 階層とレベルには同じ機能があります。 なぜなら この軸には1つの階層があり、その指示は省略できます。 レベルと階層も1つなので、すべてのメンバーを1つのリストに表示できます。

長年にわたって詳細を述べた3番目の例でこれを続ける方法はすでに明らかだと思います。 しかし、年ごとにドリルダウンするのではなく、フィルターをかける方が良いでしょう。 スライスを構築します。 これを行うには、次のクエリを作成します。

 select [Territory.Cities by Countries].[All].Children on rows [Shipper].Members on columns from [invoices1] where ([Date].[2007]) 

そして、フィルタリングはどこにありますか？

where-キーワード
[2007]は[Date]階層のメンバーの1つです。 すべての用語を含むフルネームは、 [Date.By months]。[すべての日付]。[2007] しかし、以来 軸内のこのメンバーの名前は一意であり、名前のすべての中間的な絞り込みは省略できます。

日付メンバーが括弧で囲まれているのはなぜですか？ 括弧はタプルです。 タプルは、 異なる軸に沿った1つ以上の座標です。 たとえば、2つの軸に沿ってかっこで一度にフィルター処理するには、 異なる次元からの2つの用語をコンマで区切ってリストします。 つまり、タプルはキューブの「スライス」を定義します（そのような用語が近い場合は「フィルタリング」）。

タプルはフィルタリングに使用されるだけではありません。 タプルは、行/列/ページなどの見出しに含めることもできます。

これは、たとえば、3次元クエリの結果を2次元テーブルに表示するために必要です。

 select crossjoin( [Territory].[Cities by Countries].[All].Children, [Date.By months].[All dates].Children ) on rows [Shipper].Members on columns from [invoices1] where ([Date].[2007]) 

Crossjoinは機能です。 タプルのセット（セット）を返します（はい、セットにはタプルを含めることができます！）。2つのセットのデカルト積の結果として取得されます。 つまり 結果セットには、国と年のすべての可能な組み合わせが含まれます。 したがって、行ヘッダーには、 Country-Yearの値のペアが含まれます。

問題は、どの数値特性を表示する必要があるかをどこに表示するかです。 この場合、このキューブに指定されたデフォルトのメジャーが使用されます。 注文金額。 別のメジャーを導出する場合、 メジャーはメジャーディメンションのメンバーであることを思い出してください。 そして、他の軸と同じように動作します。 つまり いずれかのメジャーでクエリをフィルタリングすると、そのメジャーがセルに正確に表示されます。

質問：どこでフィルタリングするか、行で軸メンバーを指定してフィルタリングすることの違いは何ですか？ 回答：実質的には何もありません。 ヘッダーの形成に関与しない軸のスライスを示すのは、まさにwhereです。 つまり 同じ軸を 行と場所の 両方に同時に存在させることはできません 。

計算されたメンバー

より複雑なクエリの場合は、計算されるメンバーを宣言できます。 属性軸とメジャー軸の両方のメンバー。 つまり たとえば、注文の合計金額に対する各国の貢献度を反映する新しいメジャーを宣言できます。

 with member [Measures].[Part] as '[Territory].CurrentMember / [Territory].[Cities by Countries].[All]', FORMAT_STRING='0.00%' select [Territory].[Cities by Countries].[All].Children on rows from [invoices1] where [Measures].[Part] 

計算は、すべての座標属性がわかっているセルのコンテキストで行われます。 対応する座標（メンバー）は、キューブの各軸のCurrentMember関数によって取得できます。 ここで、式[Territory] ​​.CurrentMember / [Territory]。[Cities by Nations]。[All]は、1つのメンバーを別のメンバーに分割するのではなく、 対応する集約キューブスライスデータを分割することを理解してください。 つまり 現在のテリトリーのスライスは、すべてのテリトリーのスライスに分割されます。 すべての注文の合計値。 FORMAT_STRING-出力値の形式、つまり ％

計算された用語の別の例ですが、すでに年の軸に沿っています：

 with member [Date].[2007 and 2006 difference] as '[Date].[2007] - [Date].[2006]' 

明らかに、レポートはユニットではなく、対応するスライスの違い、つまり この2年間の注文量の差。

ROLAPでの表示

OLAPシステムは、何らかの種類のデータストレージと組織システムに基づいた何らかの方法です。 RDBMSに関しては、ROLAPについて話します（ MOLAPとHOLAPは独立した研究のために残します）。 ROLAP-リレーショナルデータベース上のOLAP、つまり 通常の2次元テーブルの形式で記述されます。 ROLAPシステムは、MDXクエリをSQLに変換します。 データベースの主な計算上の問題は、高速集約です。 より速く集約するために、データベース内のデータは通常非常に非正規化されています。 これらは、ディスク領域とデータベースの整合性制御の観点から非常に効率的に保存されていません。 さらに、部分的に集約されたデータを格納する補助テーブルが追加されます。 そのため、OLAPの場合、通常、個別のデータベーススキーマが作成され、ディレクトリに関して元のトランザクションデータベースの構造が部分的にのみ繰り返されます。

ナビゲーション

多くのOLAPシステムは、すでに生成された要求（およびそれに対応して選択されたデータ）用の対話型ナビゲーションツールを提供します。 この場合、いわゆる「ドリル」または「ドリル」（ドリル）が使用されます。 ロシア語へのより適切な翻訳は、「深化」という言葉です。 しかし、これは趣味の問題です。一部の環境では、「ドリル」という言葉が定着しました。

ドリルは、他の軸（または複数の軸）に沿ったフィルタリングと組み合わせて、データ集約の度合いを減らすことによるレポートのドリルダウンです。 ドリルにはいくつかの種類があります。

• ドリルダウン -選択したフィルタリングメンバーの階層内の子孫による詳細情報の出力を使用して、ソースレポート軸の1つに沿ってフィルタリングします。 たとえば、国と年ごとの注文の分布に関するレポートがある場合、2007をクリックすると、同じ国と2007年の月のコンテキストでレポートが表示されます。
• ドリルアサイド-1つ以上の選択された軸の下でフィルタリングし、1つ以上の他の軸に沿った集約を削除します。 たとえば、国と年ごとの注文の分布に関するレポートがある場合、2007をクリックすると、別のレポートがセクションごとに表示されます（たとえば、2007年のフィルタリングを使用する国とサプライヤー）。
• drill-trough-すべての軸に沿った集計の削除およびそれらに沿った同時フィルタリング-ファクトテーブルからソースデータを表示して、レポートの値を取得できます。 つまり セル値をクリックすると、この金額を与えたすべての注文を含むレポートが表示されます。 立方体のまさに「腸」への一種のインスタントドリル。

以上です。 ここで、ビジネスインテリジェンスとOLAPに専念することを決めた場合は、本格的な文献を読み始めましょう。