問題タブ [star-schema]

コンタクト履歴ファクト テーブルのデータ ウェアハウス ファクト テーブルの設計に取り組んでいます。私の現在のスキーマは次のようになります。

私のアプリケーション要件の 1 つは、ディメンションContactResultの選択リストの最新のものを見つけることです。ディメンションには、ContactTypeフィルタリングする値の範囲を識別するために使用される属性があります。ContactTypeContactClass

上記の構造により、ContactTypeによって選択されたすべての連絡先情報をContactClass取得でき、そのリストを処理して最新の値を取得できます。

問題は、特定の最新の連絡先イベントを簡単に取得できるように、上記の変更を誰かが提案できるContactClassかどうかです。現在、これはトランザクション ファクト テーブルですが、使いやすさが向上する場合は喜んで変更します。

この操作は、幅広い顧客 (200K+) に対してかなり頻繁に実行されるため、パフォーマンスが重要です。操作は Web インターフェイス上の C# コードで行われるため、BI ツール固有のソリューションはこの場合には役に立ちません。

これまでのところ、私が思いついた唯一のアイデアは、各 の最新のレコードのみを記録する累積ファクト テーブルですContactClass。このオプションの改善は大歓迎です。

私はコマンドを使用していないのでJOIN、これが本当に a であるかどうか疑問に思っていますJOIN(そうでない場合は、何と呼ぶべきか)?

これは、代理キーと主キーを使用して詳細を照合する次元モデル用です

構築中の分析アプリのバックエンドとして機能するスター スキーマを構築しています。私のクエリ ジェネレーターは、通常のスター結合パターンを使用してクエリを作成しています。以下のサンプル クエリでは、ファクト テーブルが 2 つのディメンション テーブルに結合され、エンド ユーザーが選択した定数値によってディメンション テーブルがフィルター処理されます。

MySQL 5.5 を使用しており、すべてのテーブルは MyISAM です。

この問題では、単純に最初の N 行 (この場合は最初の 1 行) を取得しようとしています。

Explain の出力は次のとおりです。値に適用される一意のキーがあるため、両方のディメンション キーが定数値に解決されます。

ファクト テーブルのインデックスは次のとおりです。

このクエリをプロファイリングすると、クエリがファイルソート操作の「結果のソート」の実行にほとんどの時間を費やしていることがわかります。私の質問は、正しいインデックスを使用している場合でも、なぜこのクエリは並べ替えを行わずに最初の値を単純に取り出せないのでしょうか? my_idx は既に右側の列でソートされており、計画に示されているように、インデックスで最初に表示される 2 つの列は定数として解決されます。

クエリを次のように書き直すと、ファイルの並べ替えなしで、目的のプランを取得できます。

これらの SQL コマンドを生成するツールを変更するとコストがかかるため、クエリが元の形式で記述されている場合でも、このファイルソートは避けたいと考えています。

私の質問は、インデックスの最初のキーが (INNER JOIN を介して) 定数であり、インデックスが正しい順序でソートされている場合でも、MySQL がファイルソートを選択するのはなぜですか? これを回避する方法はありますか？

Postgres を分析 (スター スキーマ) に使用します。数秒ごとに、約 500 種類のメトリクスに関するレポートが取得されます。最も単純なスキーマは次のとおりです。

当社の DBA は、同じ 5 秒間のすべてのレポートを次のように平坦化することを提案しました。

一部の開発者はこれに反論し、これにより開発が非常に複雑になり (データをバッチ処理して 1 回で書き込む)、保守性が低下します (テーブルを確認したり、フィールドを追加したりするのはより複雑です)。

DBA モデルはそのようなシステムの標準的な方法ですか、それとも元のモデルが明らかに十分にスケーラブルでない場合の最後の手段ですか?

編集: 最終的な目標は、ユーザーの折れ線グラフを描画することです。したがって、クエリはほとんどの場合、いくつかのメトリックを選択し、それらを時間単位で折り畳み、1 時間 (またはその他の期間) ごとに最小/最大/平均を選択します。

編集: DBA 引数は次のとおりです。

1. これは 1 日目から関連していますが (以下を参照)、そうでなかったとしても、システムが最終的に行う必要があるものであり、別のスキーマからの移行は面倒です。

2. 行数を 500 倍減らすと、より効率的なインデックスとメモリが可能になります (この最適化前のテーブルには数億行が含まれます)。

3. 複数のメトリックを選択する場合、提案されたスキーマでは、メトリックごとに個別のクエリ (または OR と GroupBY の複雑な組み合わせ) の代わりに、データを 1 回渡すことができます。

編集: 500 メトリクスは「上限」ですが、実際にはほとんどの場合、5 秒あたり ~40 メトリクスしか報告されません (ただし、同じ 40 ではありません)。

私のテーブル構造は次のとおりです

今、私はグレードとレベルをディメンションのレベルとして持つ必要があります。

「dim_question_tbl」テーブルに書き込まれたキューブ。

寸法を次のように書きました

これは機能しません。私が得ている例外は、「[グレード]」には少なくとも1つのレベルが必要です。

SQLクエリでも試してみました

SQLクエリでも同じ例外が発生します。

スノーフレークスキーマで複数のレベルを取得するにはどうすればよいですか?

BI Start スキーマのディメンション テーブルを設計しています。レポートで非常に簡単かつ効果的に使用できるため、各ディメンション値に関連付けられた使いやすい属性値の値を既に観察しました。

ソース システムのエンコードされた値を含めたり公開したりするメリットはありますか (もちろん、ソース システムの一意のキーは含まれません)。

たとえば、ソース システムのネイティブ コード値がそれぞれ x2、x7、赤、青、緑の x9 である Color という属性がある場合、ディメンション テーブルに 2 つの列を維持する価値はありますか?ソース システム コードの値 (例: x2)とユーザー フレンドリな値 (例: Red) の 1 つは?

BI レポート (現在、スター スキーマの上に Cognos を使用しています) では、ソース システムに戻って他の属性を取得することは一般的ですか?

これらの「その他」の属性は常に BI スキーマに表示され、ソース システムに再び結合されないようにする必要がありますか?

学校で用語とクラスをモデル化するためのスター スキーマを作成しています。

学習管理システム (LMS) - クラスが行われる場所で、各クラスを特定の LMS タームに関連付けます。

学生情報システム (SIS) - 学生がクラスに登録する場所であり、LMS よりも細かい方法で用語をモデル化します。したがって、各 LMS 用語には複数の SIS 用語があります。

各ファクト レコードは、クラス内の生徒の粒度であり、1 つの LMS タームに関連付けられます。

DimSisTerm と DimLmsTerm の 2 つのディメンション テーブルを作成できたようです。

または、適合したディメンション テーブルを 1 つ作成することもできます: DimTerm

単一の適合ディメンションの場合、SIS Term ごとに 1 つのレコードが存在しますが、LMS Term キーとその属性は、関連するすべての SIS Term レコードに対して繰り返されます。

以前にこれを経験したことがある人は、2 つのシナリオ間のトレードオフについてガイダンスを提供できますか?

これが些細な質問である場合はご容赦ください。私は新しい蜂です。日付範囲のコストを表示する必要がある OLAP システムの設計段階にいます。私は、製品、ベンダー、言語のような他の 3 つの次元を持っています。日付をもう 1 つのディメンションとして追加する必要がありますか?? 私のクエリは、ほとんどの場合、1997 年 5 月 11 日から 01 月 9 日 2 月 13 日までのような日付範囲でコストがかかります。これが最善の方法です。