基本概念

キューブのソース・クラス

ほとんどの場合、キューブのソース・クラスは永続クラスです。

データ・コネクタもソース・クラスになる可能性があります。データ・コネクタは、%DeepSee.DataConnectorOpens in a new tab を拡張するクラスです。データ・コネクタは、任意の SQL クエリの結果を、キューブのソースとして使用可能なオブジェクトにマップします。通常、データ・コネクタは InterSystems データベース内に存在しない外部データにアクセスしますが、InterSystems データベースに対する SQL クエリ (ビューに対する SQL クエリを含む) を指定するために使用することもできます。詳細は、"InterSystems Business Intelligence の実装" の "データ・コネクタの定義と使用" を参照してください。

子コレクション・クラスもソース・クラスとして使用できます。

レベルとメンバ

レベルはメンバで構成され、メンバはレコードのセットです。City レベルの場合、メンバ Juniper では、出身地が Juniper である患者が選択されます。逆に、キューブ内の各レコードは、1 つ以上のメンバに属します。

ピボット・テーブルの多くは、単純に 1 つ以上のレベルのメンバのデータを表示します。例えば、Age Group レベルには、メンバ 0 to 29、30 to 59、および 60+ があります。次のピボット・テーブルは、これらのメンバのデータを示しています。

別の例として、以下のピボット・テーブルは、Age Group と Gender レベルのデータを示しています (それぞれ 1 列目と 2 列目に示されています)。

個別のメンバをドラッグ・アンド・ドロップして行または列に使用できます。以下はその例です。

オプションの詳細は、"アナライザの使用法" を参照してください。

メンバ名とキー

各メンバには、名前と内部キーの両方があります。コンパイラでは、同じレベル内にあっても、これらのいずれかが一意である必要はありません。状況によってはメンバ名に重複があることが正当な場合もありますが、メンバ・キーは重複しないように注意してください。

メンバ名の重複が正当である例として、同名異人を単一のメンバに結合しない場合を考えてみます。ユーザがメンバをドラッグ・アンド・ドロップすると、システムで生成されるクエリでは、名前でなくメンバ・キーが使用されるため、常に目的のメンバにアクセスできます。

ただし、メンバ・キーの重複があると、個別メンバの参照が不可能になります。メンバ・キーを指定すると、システムはそのキーを持つ最初のメンバのみを返します。モデルのメンバ・キーは重複しないように確認することができ、またそうする必要があります。

重複メンバ名および重複メンバ・キーの発生するシナリオの詳細は、"メンバ・キーおよび名前の適切な定義" を参照してください。

ソース値

各レベルは、ソース値に基づいています。この値は、クラス･プロパティまたは ObjectScript 式のいずれかになります。例えば、Gender レベルは、患者の Gender プロパティに基づきます。別の例として、Age Group レベルは、年齢に応じて患者の Age プロパティを文字列 (0 to 29、30 to 59、または 60+) に変換する式に基づいています。

階層およびディメンジョン

Business Intelligence では、レベルは階層に属し、階層はディメンジョンに属します。階層とディメンジョンを使用することで、レベルで提供される機能を超えた機能が実現されます。

階層は、データを特に空間および時間を軸に組織化する、現実的で便利な方法です。例えば、市区町村を郵便番号でグループ化したり、郵便番号を地方でグループ化できます。

Business Intelligence の階層の定義には、次に示す 3 つの実用的な理由があります。

• システムには、階層を利用した最適化機能があります。例えば、年を期間の親として定義しているモデルで、期間 (年および月) を行または列として表示し、フィルタ処理して特定の年に絞り込むと、クエリの速度が向上します。

• ピボット・テーブル内では、レベルのメンバをダブルクリックすると、システムでドリルダウンが実行され、そのメンバに子メンバが存在する場合は、その子メンバが表示される、というように階層を使用できます。例えば、年をダブルクリックすると、システムはその年に含まれる期間にドリルダウンします。詳細は、"アナライザの使用法" を参照してください。

• MDX には、階層で使用できる関数があります。例えば、特定の国の子郵便番号に対するクエリや、同じ国内の別の郵便番号に対するクエリを実行できます。

  これらの関数は、手書きのクエリで使用できます。アナライザでは、ドラッグ・アンド・ドロップでこのようなクエリを作成できません。

ディメンジョンには、レコードを類似の方法で組織化する 1 つ以上の親子階層があります。例えば、アレルギーに関連する複数の階層を 1 つのディメンジョンに包含できます。2 つの異なる階層間、またはある階層のレベルと別の階層のレベルとの間に、形式化されたリレーションシップはありません。ディメンジョンの実際的な用途は、ディメンジョンに格納されるレベル、特に All レベルの既定の動作を定義することです。これについては次のサブセクションで説明します。

All レベルと All メンバ

各ディメンジョンでは、そのディメンジョンの全階層に表示される All レベルという特殊な任意のレベルを定義できます。このレベルを定義した場合、このレベルには、All メンバという、キューブ内のすべてのレコードに対応するメンバ 1 つが格納されます。

例えば、AgeD ディメンジョンに、下図に示すようなレベルで構成される 1 つの階層が組み込まれます。

特定のディメンジョンについて、All メンバがその論理名と表示名と共に存在しているかどうかを指定します。このディメンジョン内の All メンバは All Patients と命名されています。

リスト・ベースのレベル

Business Intelligence では、他の多くの BI ツールと異なり、レベルのベースにリスト値を使用できます。例えば、1 人の患者に複数の診断が存在する場合があります。Diagnoses レベルで患者を診断別にグループ化します。以下はその例です。

リスト・ベースのレベルでは、特定のソース・レコードが複数のメンバに属する場合があります。ここに示すピボット・テーブルでは、一部の患者が複数回含まれています。

関連項目

"ディメンジョン、階層およびレベルの定義" を参照してください。

計算メジャー

他のメジャーに基づいて新規メジャーを定義することは大変便利です。例えば、Patients サンプルの場合、Allergy Count メジャーを Count メジャーで除算した結果として Avg Allergy Count メジャーを定義することができます。次のようなピボット・テーブルがあるとします。

このピボット・テーブルを実行すると、Allergy Severities レベルのメンバごとに Count メジャーと Allergy Count メジャーの値が決定されます。このページの後続のセクションでは、この動作の内容について説明します。その後、各メンバの Avg Allergy Count 値を求めるため、Allergy Count 値が Count 値で除算されます。

非メジャーの計算メンバ

非メジャーの計算メンバは、MDX 集約関数を使用して他の非メジャーのメンバと結合します。最も便利な関数は %OR です。

非メジャー・メンバのそれぞれが一連のレコードを参照することを忘れないでください。複数のメンバを新規メンバに結合する際は、そのコンポーネント・メンバが使用するすべてのレコードを参照するメンバを作成します。

簡単な例として、ColorD ディメンジョンを考えてみます。このディメンジョンには、メンバ Red、Yellow、および Blue が組み込まれています。これらのメンバは、赤、黄、青をそれぞれ好む患者にアクセスします。%OR を使用して、3 つの患者グループすべてにアクセスする新規メンバを 1 つ作成することができます。

以下はその例です。

関連項目

"計算メンバの定義" を参照してください。

フィルタ・メカニズム

データのフィルタ処理のために、メンバ・ベース・フィルタとメジャー・ベース・フィルタという 2 つの簡単な方法が用意されています。これらを組み合わせてより複雑なフィルタを作成することもできます。これは特に MDX クエリを直接作成する際に使用できます。

メンバ・ベース・フィルタ

メンバはレコードのセットです。最も単純なメンバ・ベース・フィルタでは、メンバを使用して、ピボット・テーブルをフィルタ処理します (例えば、このセクションで後述するように他のコンテキストを使用できます)。つまり、ピボット・テーブルはそのメンバに属するレコードのみにアクセスすることになります。

例えば、次のようなピボット・テーブルがアナライザで表示されるとします。

Age Group レベルの 0 to 29 メンバを使用するフィルタを適用するとします。フィルタ適用後のピボット・テーブルは次のようになります。

アナライザには、NULL の行と列を表示するオプションがあります。NULL 行を表示すると、ピボット・テーブルは次のようになります。

どのピボット・テーブルでも同じフィルタを使用できます。例えば、フィルタ処理されていない次のようなピボット・テーブルがあるとします。

見出しには示されていませんが、このピボット・テーブルには、Patient Count メジャーが表示されます。このピボット・テーブルに前と同様にフィルタを適用すると、次のように表示されます。

いずれの場合も、合計レコード数は同じであることに注意してください。どちらの場合も、0 to 29 メンバに属する患者にのみアクセスしています。

また、1 つのフィルタで複数のメンバをまとめて使用することも、異なるレベルのメンバを参照する複数のフィルタを結合することもできます。また、含めるメンバを選択するのではなく、除外するメンバを選択することもできます。

Tip:

メンバ・ベース・フィルタは作成が容易でかつ強力であるため、フィルタでの使用専用のレベルを作成するだけの価値があります。

メジャー・ベース・フィルタ

システムは、検索可能メジャーをサポートしています。このメジャーを使用すると、ソース・レコード自体のレベルで値を評価するフィルタを適用できます。

Patients サンプルに対して、受診回数が 10 回以上の患者のみにアクセスするフィルタを設定できます。このフィルタをピボット・テーブルで使用すると、以下のようになります。

同じフィルタを別のピボット・テーブルで使用すると、以下のようになります。

いずれの場合も、ピボット・テーブルでは受診回数が 10 回以上の患者のみが使用されるため、患者の合計数は同じです。

検索可能メジャーにはテキスト値が含まれることもあります。このようなメジャーでは、=、<、>、および LIKE 演算子を使用してレコードをフィルタ処理できます。

より複雑なフィルタ

メンバ・ベース・フィルタとメジャー・ベース・フィルタを結合して、より複雑なフィルタも作成できます。以下は、アナライザで作成したフィルタの例です。

内部的には、クエリでは AND や OR が使用されるのではなく、MDX 構文が使用されます。すべての Business Intelligence フィルタは MDX 構文を使用します。

MDX 関数を使用するフィルタも作成できます。以下はその例です。

• FILTER 関数は、メジャー・ベースのフィルタが使用する最下位レベルの値ではなく、メジャーの集約値を使用します。例えば、これを使用して、患者数が 1000 未満の市区町村に属する患者をフィルタで除外することができます。

  アナライザでは、行または列に対する Levels オプションでこの関数が内部的に使用されています。

• EXCEPT 関数は、特定のメンバの削除に使用できます。選択したメンバを除外するメンバ・ベース・フィルタを作成する際に、この関数がシステムによって使用されます。

  InterSystems MDX には、このほかにも、SET 演算を実行する関数が多数用意されています。

• TOPCOUNT およびその他の関数は、ランキングに基づいてメンバにアクセスします。

MDX の概要およびオプションの概要は、"InterSystems MDX の使用法" を参照してください。"InterSystems MDX リファレンス" も参照してください。

フィルタの使用

ピボット・テーブルの定義時には、フィルタ方法を指定できます。ただし実際は、ピボット・テーブルの管理が困難になるため、フィルタの異なる類似した複数のピボット・テーブルを作成することは推奨されません。この代わりに、以下のツールのいずれかまたはすべてを使用できます。

• アナライザで、名前付きフィルタを定義し、それを複数のピボット・テーブルで使用できます。名前付きフィルタは、アナライザでキューブまたはサブジェクト領域のコンテンツと共に使用できます (次の項目を参照してください)。

• アーキテクトでは、ベース・キューブのフィルタ適用済みビューであるサブジェクト領域を定義できます。この定義後にピボット・テーブルを作成し、キューブ自体ではなくサブジェクト領域から開始します。これらのピボット・テーブルは、ピボット・テーブル自体に固有のフィルタに加え、サブジェクト領域フィルタによって常にフィルタ処理されます。

  サブジェクト領域では、ハードコードされたフィルタを指定したり、コールバック・メソッドをカスタマイズして実行時にフィルタを (例えば、$roles などの値に基づくように) 指定できます。

• ユーザ・ポータルでは、ダッシュボードの作成時にフィルタ・コントロールを組み込むことができます (これは単純なメンバ・ベース・フィルタの場合にのみ適用されます)。その後、ユーザは包含または除外する 1 つ以上のメンバを選択できます。

フィルタは常に累積的です。

ファクト・テーブルの構造

一般にファクト・テーブルには、ベース・テーブルのレコードごとに 1 つのレコードが存在します。この行がファクトです。ファクトには、レベルおよびメジャーごとに、それぞれ 1 つのフィールドが含まれます。以下は、部分的な例です。

指定されたレベルのフィールドには、値が含まれていない場合もあれば、値が 1 つ、または複数含まれている場合もあります。個別値はそれぞれ、このレベルのメンバに対応します。任意のメジャーに対するフィールドには NULL 値、または単一値が含まれます。

システムはこのファクト・テーブルを構築するときに、対応するインデックスも生成します。

ファクト・テーブルには、階層およびディメンジョンに関する情報は含まれません。ファクト・テーブルでは、レベル間のリレーションシップに関係なく、各レベルが同様に処理されます。ファクト・テーブルには各レベルに列が 1 つ含まれ、その列には各ソース・レコードに適用される 1 つ以上の値が含まれます。

ファクト・テーブルへのデータ入力

キューブの完全構築の実行時に、システムはベース・テーブルのレコードを繰り返し処理します。各レコードに対して以下の処理が実行されます。

• 各レベルの定義を調査し、0 個、1 個または複数の値を取得します。

  この手順では、システムによって、レコードの分類方法が決定されます。

• 各メジャーの定義を調査し、0 個、または 1 個の値を取得します。

その後、このデータがファクト・テーブルの対応する行に書き込まれ、インデックスが適切に更新されます。

選択的構築の実行時に、システムは既存のファクト・テーブルを繰り返し処理し、選択された列を更新するか、この列に値を入力します。

ファクト・テーブルの使用法

次のようなピボット・テーブルがあるとします。

最初の列には Age Bucket レベルのメンバの名前が表示されます。最初のデータ列には Patient Count メジャー、2 番目の列には Test Score メジャー、最後の列には Avg Test Score メジャーが表示されます。Avg Test Score メジャーは計算メンバです。

これらの値は、次のようにして決定されます。

1. 最初の行は、Age Bucket レベルの 0-9 メンバを参照しています。システムでは、インデックスを使用して、ファクト・テーブル内の関連する患者 (ここでは赤でハイライト表示) をすべて検出します。

   

2. ピボット・テーブルの Patient Count 列には、特定のコンテキストで使用される患者数が表示されます。

   この列の最初のセルでは、0-9 メンバに対して検出されたファクト・テーブル内のレコードの数がカウントされます。

3. ピボット・テーブルの Test Score 列には、特定のコンテキストにおける患者の累積テスト・スコアが表示されます。

   この列の最初のセルに対して、システムは、まず、0-9 メンバに対して検出されたファクト・テーブルで Test Score の値を検索します。

   

   次に、これらの数値を集計します。この例では加算します。

4. ピボット・テーブルの Average Test Score 列には、特定のコンテキストにおける患者のテスト・スコアの平均値が表示されます。

   Avg Test Score メジャーは計算メンバで、Test Score を Patient Count で除算して算出されます。

結果セットのすべてのセルについて、この手順を繰り返します。