問題タブ [saiku]

Pentaho で Saiku プラグインを使用してキューブを分析しています。すべての寸法フィールドと測定フィールドが表示されますが、ファクトは表示されず、すべてのセルが空です。(ツールバーで「空でない」オプションが選択されている場合、Saiku は「結果なし」を返します。オプションが選択されていない場合、すべてのメンバーを列と行に正しくリストしたテーブルが表示されます - セル値はありません)。列と行のメンバー値が正しいため、Saiku がキューブ xml ファイルと MySQL データ ソースを正しく読み取っていることがわかります。指定された測定値に問題がある可能性があると思いますが、エラーは見つかりません (コンソールやログにエラーはありません)。Saiku でキューブ化するときに選択した次元に関係なく、この問題が発生することに注意してください。これは私が schema workbench で作成した Mondrian スキーマ ファイルです。

なぜこれが考えられるのでしょうか？この問題をデバッグするにはどうすればよいですか?

単純な TimeDimension の Pentaho の例を拡張して、曜日別に集計しようとしています

これは提供された例です:

（参考はこちら）

私の変更されたディメンションは次のようになります。

私は、Saiku (モンドリアン キューブのフロント エンドとして使用) が、私のDay列は常に年-月-週の階層に基づいている必要があると主張しているという課題に直面しています。日別 (例: 月曜日と火曜日の平均売上高)。別のディメンションを追加しようとしましたが、何をしても N * 日名レコードになります。ここで、N はレコードの数です (理想的には、関連するメジャーに基づいて 7 行が返されます)。

Saiku サーバーのモンドリアン スキーマでキューブを設計しています。以下は、作成するキューブに対しても複製する必要があるデモ Foodmart スキーマのディメンションです。「レベル」の下の「プロパティ」の役割が理解できません。また、この「プロパティ」のリストが Saiku のディメンションとして表示されないのはなぜですか。

Pentaho BI Server 5.0.1 と Pentaho 用の Pivot4J プラグインおよび Pentaho Metadata Editor (PME) 5.1.0 を使用しています。PME でテーブル、関係、セキュリティなどを含むドメインを作成し、Pentaho サーバーに公開しました。管理コンソールで [データソースの管理] に移動すると、このドメインが「メタデータ」タイプのデータソースとして表示されます。ただし、新しい Pivot4J ビューを作成しようとすると、ドメインがソースとして表示されません。

Pivot4J で Pentaho デモ (Sampledata と Steel Wheels) を確認できますが、ドメイン/メタデータが表示されません。また、Pentaho のドキュメントで提案されているように、PentahoObject.spring.xml ファイルを編集して、メタデータ オブジェクトのセキュリティを削除しました。斎藤も同じ。ここで欠けているステップは何ですか?

openshift プラットフォームに saiku サーバーを実装しています。saiku アプリケーション用に openshift で mysql データベースに接続する方法。

デモ構成

上記の構成でmysql環境変数を使用する方法

ありがとう

Mondrian と Pentaho および Saiku を使用して、MySQL データベースで OLAP 分析を行っています。ファクト テーブルにリンクする 2 つのディメンション (受益者とメンバー) を持つデータ ウェアハウスがあります。受益者には次のフィールドがあります: beneficiary_type1、beneficiary_type2、beneficiary_type3。メンバーには性別のフィールドがあります。

以下で定義されたモンドリアンスキーマを作成しました。

（個別に）閲覧できるようにしたい：受益者_type1の男女数、受益者_type2の男女数、受益者_type3の男女数、

性別を受益者タイプ 1 の上にドラッグすると、次のように表示されますが、これは正しいものです。

性別を受益者タイプ 2 にドラッグすると、次のように表示されますが、これは正しくありません。

これは beneficiary_type2 列であるため、両方のフィールドを追加するとわかるように、benefiiary_type1 でグループ化されます。

beneficiary_type2 で性別を表示すると、「成人」用と「19 歳までの子供」用の 2 つの行しか表示されないことが予想されます。私が読んだことから、uniqueMembers 属性は beneficiary_type2 レベルで設定する必要があるようですが、これにより次の結果が得られます。

これにより、正しい番号付けされた結果が得られますが、行は依然として受益者タイプ 1 によってグループ化されているかのように表示されます。また、この方法では、3 番目のイメージのように、beneficiary_type1 の下に正しくグループ化された beneficiary_type2 を生成できません (番号付けされた結果は、親レベルに従ってグループ化されることはありません)。

分析に含めた親レベルによって決定される行数を持つように、スキーマをどのように構築すればよいですか? （saiku を使用してキューブにドラッグ）つまり、beneficiary_type1 と beneficiary_type2 をドラッグすると、beneficiary_type2 は beneficiary_type1 に従ってグループ化され（3 番目の画像のように）、beneficiary_type2 のみの場合は、固有の値に従ってグループ化されます（2 行、「Adults」用に 1 行）。 」と「19歳までの子供」用の1つ）。

私は OLAP に比較的慣れていないので、理解できない基本的な概念がいくつかあるかもしれません。説明があれば遠慮なく分岐してください。

-------------------- 更新 --------------------

@nsousa で説明されているように、同じ階層は、親子関係を意味します。スキーマの正しい変更は次のようになりますか?

別の解決策として、受益者テーブルに 3 つの個別のディメンションをロードするという理解で正しいでしょうか? これは、3 つの別個のテーブル (受益者メンバーごとに 1 つ) がデータベースにも存在する必要があることを意味しますか?それとも、同じテーブルを複数のディメンションに使用できますか? 明らかに、メンバーごとにデータベース テーブルを用意するのは理想的ではありません。このようにする利点はありますか?

私は、Saiku 2.6 のキューブ生成を自動化しようとしているいくつかの異なるデータ セットを持っています。ディメンションとメジャーの数が限られているデータ セットの場合、これは非常にうまく機能します。ただし、Saiku が多くのメジャー (具体的には CalculatedMembers) を持つスキーマのスキーマにすべてのメジャーを表示しないという問題が発生しています。実際、Saiku が任意の時点で表示する小節 (CalculatedMembers) の数は 115 であると思われます。

私はこれが多くのように聞こえることを知っています - それはそうですが、私たちの場合は必要です. スキーマ定義に問題はないようです。たとえば、230 個のメジャーを含むスキーマを作成すると、最初の 115 個が表示されます。最初の 115 を削除してスキーマを更新すると、以前は表示されていなかった次の 115 が表示されます。

これは Saiku のバグのようですが、まだ特定できていません。他の誰かがこれを経験しましたか？何かアドバイス？

ありがとう！