問題タブ [star-schema]

私はスター スキーマ ウェアハウス (MS SQL Server、MS Report Builder と OLAP を介してアクセス) を持っています。これには多くの小さなディメンションがあります。これは、ディメンションが 2 つの列 (ID と説明) から構築され、ファクトから数百がリンクされていることを意味します。テーブル。

これにより、このリターンに対する実際のカウントがない場合でも、ファクトからすべてのアイテムを提示するオプションが提供されます (null を表示)。ただし、これが可能な限り最良の方法でデータを表すとは確信していません。説明がファクトの一部である非正規化テーブルの場合、OLAP アプローチと並行して SQL を介してデータをクエリする機能が向上するためです。

多数の 1 レベル ディメンションのこの構造は正常であり、適切な方法ですか? 正直なところ、空白が表示されると予想されるのは、時間や日付のディメンションなどに対するものだけですが、これらはデータから強制されてチャートやテーブルにギャップが生じる可能性があるため、実際にはそれほど問題ではないようです.

この構造が良いか悪いかについての見解 - 私はこれを変えたいと思っていますが、ベストプラクティスと歩調を合わせていない場合は、喜んで考え方を変えます.

構造の例 (これは 1 つの Fact テーブルの一部です)

ファクト テーブル - (プロパティ)

寸法表 -

これを言い換えると、ディメンションは実際にはファクトの個別の表である必要がありますか、それともファクトの一部としての説明を使用したほうがよいでしょうか? レポートを迅速かつ簡単にし、フィールドに値がない場合のレコードのドロップを最小限に抑えたいと考えています。

次のように、2 つのディメンション テーブルと 1 つのファクト テーブルがあります。

結果を取得するためのクエリ:

上記のクエリの結果は 1,3,4 です

しかし、私は1,2,4を期待しています

どうすれば期待どおりの結果を達成できますか、または私の概念は間違っていますか?

日付で範囲分割された大きなファクト テーブル (数百万行) と分割されていない小さな次元テーブルを持つ次元モデルがあります。クエリのパフォーマンスを向上させるために、これらのシナリオでよく使用されるマテリアライズド ビューに出会いました。

ここで、これらのマテリアライズド ビューを利用して集計レポートを取得するには、次の 2 つの方法のどちらが優れているかを知りたいと思います。

A. ファクト テーブル全体を必要な各ディメンション テーブルと結合して、1 つを作成します。

これは、それらを使用する最も基本的な方法のようです。しかし、それはかなり制限されているようで、作成したいクエリのバリエーションごとに新しい具体化されたビューが必要になります。

B. ファクト テーブルの集計に対して作成し、ディメンション ジョイン バックを実行するときにクエリの書き換えを利用します。

ケース A で上記のように結合を行います。これは、ファクト テーブル全体ではなく、この集約されたマテリアライズド ビューを結合に使用します。

それぞれのケースまたは他のケースをいつ使用するかを誰かに教えてもらえますか?

私は今まで直面したことのない状況に直面しています。

サテライト ロケールによって異なる、同じ ERP システムの複数のインスタンスがあります。各ロケールには独自の ID が割り当てられます。

各サテライト ロケーション内で、DB スキーマは他のものと同じで、同じテーブル、同じ値です。

これらのロケールの 2 つ以上のテーブル、たとえばパーツを組み合わせる場合、それらの自然操作キーは同じになりますが、追加の属性データは異なる場合があります。また、パーツがどのサテライト ロケールから来たかに基づいてパーツにリンクできるようにする必要があるため、ここで複合キー (パーツ ID とサテライト ID) が必要だと考えています。

これは、この 1 つのディメンションでは問題ありませんが、このサテライト ID は他の多くのディメンションでも同じように使用されます。また、多くのファクト テーブルの主要なスライサーでもあります。

この属性をどのように扱うべきですか? それを独自の次元に置き、スノーフレーク？または、値を各ディメンション (複製) にプッシュしますが、ファクト テーブルにサテライト ディメンションへの唯一の FK を保持させますか?

ディメンション キーの構造に関する質問があります。私は古典的なスタースキーマを構築しています。したがって、ディメンション テーブルのすべてのエントリが独自の一意のキーを持つように、シーケンスを使用してディメンション キーを作成しています。ここまでは順調ですね。ここで、Oracle Warehousebuilder によって作成されたプロジェクトによるキー構造を見てきました。このソフトウェアは、ディメンション キーに加えて、ディメンションの階層のすべてのレベルで専用のキーを定義します。次の例のようになります。

それは本当に必要ですか？そうでない場合、このアプローチの利点や一連の考え方は何ですか?

私は BI の世界に足を踏み入れたばかりで、たくさんの質問があります。BI の在宅ワーク プロジェクトを行う必要があるため、以下を使用することにしました。

• MYSQL (データベース)
• ペンタホケトル (ETL)
• Pentaho スキーマ ワークベンチ (スター スキーマ)
• QlikView (レポート)

SUPERMARKETスキーマワークベンチとMySQLデータベース間の接続から編集されたディメンションテーブルがあります:

• テーブルSUPERMARKET (id_supermarket, name_supermarket, number_of_boxes, active (YES or NOT), date_of_update)
• SUPERMARKETテーブルは、外部キーによって Fact テーブルに直接関連付けられますSALES。

私の質問は、SUPERMARKET ディメンションで階層とレベルを確立する方法です。

私が知っているのは、次元テーブルのすべてのメンバーは、時間次元のようにそれらの間に関係を持たなければならないということです (年は四半期を含み、四半期は月を含み、月は週を含み、週は日を含みます)。

もう 1 つ質問があります。Pentaho ワークベンチはスター スキーマを XML ファイルとしてエクスポートしますが、ETL 用に Pentaho Kettle でこのスキーマを呼び出したり使用したりするにはどうすればよいですか?

私は、顧客のステータスに基づいて、オラクルで単純なファクトテーブルを構築しています。顧客には「アクティブ」と「紛失」というステータスがあり、そのステータスで開始した日付と終了した日付があります。

サンプルの 3 行は次のようになります。

ここでは、cust 1 がアクティブでしたが、失われました。アカウントのステータスが現在 (今日の時点) の場合、終了日の列は 31/12/9999 です。Cust 2 は現在アクティブです

私の質問は、どうすればこれをファクト テーブルに入れることができるでしょうか。

ファクト テーブル:

そしてそれをテストします。

オラクルに9999年を認識させることができないようです

Stack Overflow と Google で検索を行ってきましたが、私の質問に対する答えが見つかりませんでした。

「ゼロから」のデータ ウェアハウス プロジェクトを行ってから 1 分が経過したので、過去の知識の一部を払いのけつつ、データ ロード シナリオの 1 つに対する解決策を検討中です。

もちろん、多くのディメンションが結合されたファクト テーブル (factOrderLines) を作成しています。factOrderLines にリンクしたいディメンションの 1 つは、dimItem です。問題は、アイテムのベンダーとベンダーの部品番号、製造元と製造元の部品番号、または ManagedItems (MngItemID) と呼ばれるアイテムのサブセットからの識別子のいずれかに基づいてアイテムが一意であることです。

ソース例:

問題は、ソース テーブルから dimItem テーブルに結合して、factOrderLines テーブルにデータを入力するときに、3 つのルックアップ シナリオがあることです。これにより、数値が膨らみ、パフォーマンスが低下しています。

このシナリオに対して、私が実装し始めたものよりも効率的で優れたアプローチはありますか?

編集: 完全な INSERT クエリ (理解を深めるため)