キューブの最新状態の維持
ここでは、Business Intelligence の実装プロセスで、必要に応じてキューブを最新の状態に保つ方法について概説します。その他のページでは、キューブの同期とキューブ・マネージャについて詳しく説明します。
概要
一般的なフレーズ「キューブの更新」は、ソース・テーブルおよび関連テーブルの現在の内容をキューブに反映させるプロセスを表します。以下の 3 つの手法が使用できます。
-
キューブを再構築します (例えば、アーキテクトで [構築] オプションを使用)。このプロセスは時間がかかる場合があり、キューブの再構築中にはクエリを実行できません。
-
ソース・テーブルの特定の列のみが更新されたと予想される場合は、選択的構築を使用して、キューブの特定の要素を再構築することもできます。
-
-
キューブを同期します。キューブの同期機能 (DSTIME feature とも呼ばれる) を使用すると、InterSystems IRIS Business Intelligence でデータへの変更を追跡できます。定期的にキューブを同期し、変更を組み込みます。
同期中にクエリを実行することは可能です。
キューブの実装および変更するデータによっては、この機能を使用できない場合があります。"キューブの同期が可能なとき" を参照してください。
-
キューブを手動で更新します。このプロセスは、%ProcessFact() メソッドおよび %DeleteFact() メソッドを使用します。他のオプションと異なり、この場合、ファクト・テーブルのどのレコードを更新または削除するかをコードが認識する必要があります。
手動更新中にクエリを実行することは可能です。
これらの方法を適切に組み合わせて使用できます。以下のテーブルでは、上記の方法を比較しています。
再構築 | 同期 | 手動による更新 | 選択的構築 | |
---|---|---|---|---|
プロセスにかかる時間の比較 | 長い | 短い | 短い | 長い |
プロセス中にクエリを実行できるか | いいえ | はい | はい | はい (再構築中のキューブ要素はクエリに使用できない) |
すべてのシナリオで使用可能か | はい | いいえ | はい | はい* |
変更するレコードを認識している必要があるか | いいえ | いいえ | はい | いいえ |
結果キャッシュの一部が無効になるか | はい | はい | いいえ | はい |
このオプションを提供するユーザ・インタフェース | キューブ・マネージャおよびアーキテクト | キューブ・マネージャ | なし | アーキテクト |
*選択的構築では、主な構築手順の最後に、キューブの同期が試行されます。同期が不可能な場合でも選択的構築は実行できますが、選択的構築では、構築に含まれる列以外のファクト・テーブルの列のデータは更新されません。このような場合、キューブのすべてのデータを最新の状態に保つには、完全構築が必要です。
キューブ・マネージャの詳細は、"キューブ・マネージャを使用する方法" を参照してください。
キューブの更新および関連キューブ
どのような更新でも、キューブ間のリレーションシップがある場合には必ず、特定の順序でキューブを更新する必要があります。特に、まず独立したキューブを更新します。次に、これに依存するキューブを更新します。これを行うために、キューブ・マネージャを使用できます。これは、リレーションシップを検索し、正しい更新順序を判断します。
または、キューブを適切な順序で構築するユーティリティ・メソッドまたはルーチンを作成して使用できます。
キューブの更新および結果キャッシュ
(既定で) 512,000 レコードより多く使用するキューブの場合、システムは、結果キャッシュを保持して使用します。更新方法とツールのどのような組み合わせでも、キューブの更新の頻度も注意深く考慮する必要があります。これは、どの更新でも結果キャッシュの一部を無効化する可能性があるためです。
大量のデータ・セットの場合、システムは、以下のように各キューブの結果キャッシュを保持して使用します。ユーザが (例えばアナライザを使用して) クエリを実行するたびに、システムはそのクエリの結果をキャッシュします。次回そのクエリを任意のユーザが実行すると、システムはそのキャッシュがまだ有効かどうかをチェックします。有効な場合は、キャッシュの値が使用されます。それ以外の場合、システムはクエリを再実行し、新しい値を使用して、それらをキャッシュします。その実質的な効果は、より多くのユーザがより多くのクエリを実行するほど、経時的にパフォーマンスが向上することです。
同期または再構築することでキューブを更新した場合、有効でなくなった一部の結果キャッシュがシステムによってクリアされます。詳細はキューブ定義のオプションに応じて異なります ("キャッシュのバケットとファクトの順序" を参照)。したがって、通常、頻繁に更新することは望ましくありません。
キューブを手動で更新した場合は、結果キャッシュが自動的に無効になることはありません。これは、InterSystems IRIS では、キャッシュされている結果が古くなっているとの判断が、%ProcessFact()Opens in a new tab および %DeleteFact()Opens in a new tab メソッドによって更新されない ^OBJ.DSTIME グローバル内のエントリに基づいているためです(^OBJ.DSTIME は、キューブの更新の自動プロセスでバッファとして機能します。これについては、次のセクションで説明します)。キューブのクエリがキャッシュされている古い結果を返すことのないように、手動更新の後に %SetCubeDSTime() メソッドを呼び出す必要があります (キューブ・クラスの %OnAfterProcessFact() メソッドでこのメソッドを呼び出すなど)。ファクトの挿入が重複しないようにするための予防措置をとる場合は、手動更新の後に、%SynchronizeCube() を呼び出してキャッシュを無効にすることもできます ("キューブの手動更新" を参照)。
キューブの手動更新
"キューブの同期が不可能なとき" で説明したように、キューブを手動で更新することが必要な場合があります。このような場合、アプリケーションで以下のことを実行する必要があります。
-
ベース・クラス内の影響を受けるレコードの ID を判断する。
-
%DeepSee.UtilsOpens in a new tab の %ProcessFact() および %DeleteFact() メソッドを呼び出すことで、それらのレコードに対してキューブを更新する。
入力として、これらのメソッドには影響を受ける行の ID が必要です。
%ProcessFact を使用すると、開発者は DeepSee キューブへの単一 ID の挿入または更新を完全に制御できます。その機能を提供するために、%ProcessFact は、%BuildCube および %SynchronizeCube 内で提供される同時性保護をバイパスします。この保護は、複数のプロセスが同じ作業を試行することを防止するためのものです。
カスタム・コードに %ProcessFact を含める場合は、このコードで同じキューブ、ID ペアで複数の呼び出しを行わないようにすることを強くお勧めします。この保護がなければ、%ProcessFact が複数のプロセスの同じ ID で同時に呼び出された場合、重複する挿入が実行される可能性があることがわかっています。
以下のリストにこれらの方法に関する情報が用意されています。
classmethod %ProcessFact(pCubeName As %String,
pSourceId As %String = "",
pVerbose As %Boolean = 0) as %Status
pCubeName はキューブの論理名、pSourceID はそのキューブで使用されるベース・クラス内のレコードの ID です。指定されたキューブに対して、このメソッドはファクト・テーブルの対応する行、関連付けられたインデックス、および影響を受ける場合はレベル・テーブルを更新します。
pVerbose が True の場合、メソッドはステータス情報をコンソールに書き込みます。
classmethod %DeleteFact(pCubeName As %String,
pSourceId As %String = "",
pVerbose As %Boolean = 0) as %Status
pCubeName はキューブの論理名、pSourceID はそのキューブで使用されるベース・クラス内のレコードの ID です。指定されたキューブに対して、このメソッドはファクト・テーブルの対応する行を削除し、それに応じてインデックスを更新します。
pVerbose が True の場合、メソッドはステータス情報をコンソールに書き込みます。
キューブの無効化
特定のシナリオでは、一時的にキューブを無効にすることができます。これにより、キューブの定義の編集中や既知のエラーの修正中にキューブを使用しようとした場合に、ユーザにエラーが表示されるのを防ぐことができます。キューブの削除とは異なり、キューブの無効化では、手動で編集した内容はコードとは別に保持されます。無効化したキューブはキューブ・マネージャで非表示になるため、既にリレーションシップを確立したキューブを無効化しないことを強くお勧めします。
キューブを無効化するには、以下の手順を実行します。
-
管理ポータルに管理者権限を持つユーザとしてログインします。
-
希望のアナリティクス対応ネームスペースにいることを確認します。
-
[ホーム]→[アナリティクス] に移動し、[実行] をクリックします。
-
[開く] をクリックし、ポップアップ・ウィンドウから適切なキューブを選択します。
-
インタフェースの右側にある [詳細] ペインに、[無効] というラベルのチェックボックスが表示されます。キューブを無効にするには、このチェックボックスをクリックします。
実装したい変更内容を実装し終えたら、前述の [無効] ボックスのチェックを外すことによって、キューブを再度有効化できます。再度有効化する場合、キューブを再構築する必要があります。
ファクト・テーブルへのファクトの挿入
まれに、どのソース・レコードとも対応しないレコードを含むファクト・テーブルが必要なことがあります。その場合は、キューブ・クラスの %InjectFact() メソッドを使用します。
このメソッドには、以下のシグニチャがあります。
classmethod %InjectFact(ByRef pFactId As %String,
ByRef pValues As %String,
pDimensionsOnly As %Boolean = 0)
as %Status
以下は、この指定の説明です。
-
pFactId は、ファクトの ID です。これを "" (挿入を表します) に設定します。この引数が返されるときに、ファクトで使用される ID が格納されます。
-
pFactId は、ファクト値の多次元配列です。この配列では、添え字は sourceProperty 名 (大文字と小文字の区別あり) です。
-
pDimensionsOnly では、このメソッドがファクト・テーブルとディメンジョン・テーブルの両方に影響するか、ディメンジョン・テーブルのみに影響するかを制御します。この引数が True の場合、このメソッドはディメンジョン・テーブルにのみ影響します。この引数は、次のセクションの説明に従ってディメンジョンを事前構築する場合に使用します。
Caution:ソース式に基づくレベルのディメンジョン・テーブルを更新する場合には、このメソッドを使用しないでください。これらのテーブルにレコードを追加するには、代わりに SQL UPDATE 文を使用します。
ソース・プロパティに基づくレベルのディメンジョン・テーブルを更新する場合、%InjectFact() を使用できます。
ディメンジョン・テーブルの事前構築
既定では、ファクト・テーブルが構築されると同時に、ディメンジョン・テーブルにデータが入力されます。ファクト・テーブルより前にディメンジョン・テーブルにデータが入力されるように (何らかの理由でこれが必要な場合)、1 つまたは複数のディメンジョン・テーブルを事前構築できます。
1 つまたは複数のディメンジョン・テーブルを事前構築するには、以下の手順を実行します。
-
キューブ定義クラスに %OnBuildCube() コールバックを実装します。このメソッドには、以下のシグニチャがあります。
classmethod %OnBuildCube() as %Status
%BuildCube() メソッドは、古いキューブ・コンテンツを削除した直後、新しいコンテンツの処理を開始する前にこのメソッドを呼び出します。
-
この実装では、キューブ・クラスの %InjectFact() メソッドを呼び出して、pDimensionsOnly 引数を True に指定します。
このメソッドの詳細は、前のセクションを参照してください。
例えば、以下の部分実装では、HoleFoods サンプルの Cities ディメンジョンが事前定義されています。
ClassMethod %OnBuildCube() As %Status
{
// pre-build City dimension
Set tVar("Outlet.Country.Region.Name") = "N. America"
Set tVar("Outlet.Country.Name") = "USA"
Set tVar("Outlet") = 1000
Set tVar("Outlet.City") = "Cambridge"
Do ..%InjectFact("",.tVar,1)
Set tVar("Outlet") = 1001
Set tVar("Outlet.City") = "Somerville"
Do ..%InjectFact("",.tVar,1)
Set tVar("Outlet") = 1002
Set tVar("Outlet.City") = "Chelsea"
Do ..%InjectFact("",.tVar,1)
Quit $$$OK
}
メモ :
-
メンバの名前のほかに一意の ID も指定する必要があります。
-
完全を期すために、このコードでは市の人口、経度、および緯度も指定する必要があります。これは、対応するディメンジョン・テーブルにはこれらの値が格納されているためです。
-
また、より高レベルのメンバの値を指定する必要もあります。
手動でのディメンジョン・テーブルの更新
場合によっては、ベース・クラスに変更がなくても、レベルとして使用される検索テーブルに変更があることがあります。そのような場合、このページで前述した方法のいずれかでキューブを更新できます。ただし、1 つのディメンジョン・テーブルを変更するだけであれば、そのレベルのテーブルを直接更新する方が簡単です。これには、%DeepSee.UtilsOpens in a new tab の %UpdateDimensionProperty() メソッドを使用します。
このメソッドには、以下のシグニチャがあります。
classmethod %UpdateDimensionProperty(pCubeName As %String,
pSpec As %String,
pValue As %String,
pKey As %String)
as %Status
以下は、この指定の説明です。
-
pCubeName は、キューブの名前です。
-
pSpec は、更新するレベル・メンバを参照する MDX メンバ式です。この式では、ディメンジョン、階層、およびレベルの識別子を使用する必要があります。例 : "[docd].[h1].[doctor].&[61]"
バリエーションとして、pSpec はメンバのプロパティへの参照とすることができます。例 : "[homed].[h1].[city].&[Magnolia].Properties(""Principal Export"")"
システムは、この引数と pCubeName 引数を使用して、更新するテーブルと行を確定します。
-
pValue は、このメンバの新しい名前です (存在する場合)。
また、メンバのプロパティを指定した場合は、pValue がそのプロパティの新しい値として使用されます。
-
pKey は、このメンバの新しいキーです (存在する場合)。
この引数は、pSpec のメンバを指定した場合のみ指定します。
このメソッドを使用して、以下の 3 種類の変更を行うことができます。
-
メンバの新しいキーを指定する。以下はその例です。
Set tSC = ##class(%DeepSee.Utils).%UpdateDimensionProperty("patients","[docd].[h1].[doctor].&[186]",,"100000")
既定では、キーは名前としても使用されます。そのため、このアクションによって名前も変更されることがあります。
-
メンバの新しい名前を指定する。以下はその例です。
Set tSC = ##class(%DeepSee.Utils).%UpdateDimensionProperty("patients","[docd].[doctor].&[186]","Psmith, Alvin")
既定では、名前はキーです。そのため、このアクションによってキーも変更されることがあります。
-
他のプロパティの新しい値を指定する (Name と Key はどちらもプロパティです)。以下はその例です。
Set memberprop="homed.h1.city.Pine.Properties(""Principal Export"")" Set tSC = ##class(%DeepSee.Utils).%UpdateDimensionProperty("patients",memberprop,"Sandwiches")