問題タブ [star-schema]

pentaho を使用する BI プロジェクトに取り組んでいます。

私の DW は、スター スキーマとしてモデル化されます。分析の部分では、このスター スキーマ (リレーショナル DW) から、たとえばスキーマ ワークベンチに基づいてキューブを設計する必要があることはわかっています。そのおかげで、分析ツールは多次元のリクエストを行うことができます

レポートの部分については、キューブについても知る必要がありますか、それともスター スキーマ リレーショナル DW で通常の要求を行うことができますか?

それは良いことですか、それとも悪いことですか？

助けてくれてありがとう

スタースキーマモデリングを使用してDWを構築しています。ペンタホを使ったBIプロジェクトに使用します。もちろん、時間ディメンションテーブルを用意します。ファクトテーブルをさまざまな粒度（日、週、月、年、おそらくその他）で分析します

これらの粒度ごとに1つの属性をディメンションテーブルに配置する必要があります（つまり、1日属性、1か月属性、1年属性...）、または日付を書き込んでから、この日付ですべてを計算する必要があります（日付の月、日付の年...）？

あなたの助けをたくさんありがとう

ディメンション テーブルの欠損値を処理する最善の方法は何ですか?

テキスト列の場合、「NA:欠落」と簡単に書きますが、特定の値を保持することが重要な数値列についてはどうすればよいでしょうか。注: バンド値を使用するソリューションは必要ありません (たとえば、"0-50"、"50-100"、"NA: Missing" のテキスト列)。

たとえば、顧客次元に生年があるとします。生年月日の不明はどのように処理すればよいですか？ヌルのままにしますか？1900 などの任意の数値をプレースホルダーとして追加しますか?

場合によっては、プレースホルダー番号を見つけるのが難しい場合があります。たとえば、今日までの売上がマイナスではなく、ゼロになる可能性がある場合、null のプレースホルダーとして「0」を入れたくありません。「-1」などの負の値を使用できますが、合計を使用するクエリが台無しになります。

OLAP データベースは、非正規化形式のデータで構成されています。これはデータの冗長性を意味し、このデータの冗長性により、少ない結合回数でデータを取得できるため、取得が高速になります。

しかし、OLAP データベースの一般的な設計は、ファクト ディメンション モデルです。ファクト テーブルには数値のファクト ベースのエントリ (販売数など) が格納され、ディメンション テーブルにはファクトに関連する「記述属性」、つまり販売先の顧客の詳細が格納されます。

私の質問は、この設計では、すべてのディメンション テーブルにファクト テーブルへの外部キー参照があるため、まったく非正規化されていないように見えるということです。OLTP 設計との違いは何ですか?

ソース リレーショナル データベースには、親 SuretyId 行を指す自己参照 ExtendsSuretyId FK 列を持つ INT IDENTITY PK SuretyId を持つ CompanySurety というテーブルがあります。

このデータをスター スキーマ モデルに取り込んで、CompanySurety ファクト テーブル (これまでのところ) を次のように設計しました。

問題は、この親子関係を適切な次元の方法でモデル化するにはどうすればよいか (実際には、次元モデルで親子階層をモデル化する方法) です。

親ファクトを表すために、すべてのディメンションとファクト列を複製することを検討しました (現時点では、階層の深さは 1 レベルのみであるため)。しかし、これは私には間違っているようです。