問題タブ [fact-table]

クエリを微調整しようとしていますが、フィードバックが必要です。job_factジョブの最終イベント ( ) の測定単位を持つ倉庫テーブルがありますfinal_event_type。成功/失敗の比率が得られるという事実についてクエリを実行しようとしています。これが私がこれまでに持っているものです：

このクエリでは、2 行の結果で生の成功値と失敗値のみが得られます。

a) 1 つの行で結果を取得し、b) 2 つの行の比率 (失敗率など) を計算できる方法があるかどうかは誰にもわかりません。このための手順を書いたほうがいいと誰かが言うだろうと思いますが、できれば避けたいと思います。これを行うためのエレガントな方法があることは知っていますが、今日は sql-foo が不足していると思います。

PostgreSQL 9.0.1 を実行しています。ご協力いただきありがとうございます。

アップデート

選択した回答 (@Ronnis から) に基づいて、疑問に思っている場合に備えて、ここに私の最後のクエリがあります。

データ ウェアハウスにいくつかのエンティティがあります。

1. Person - personId、dateFrom、dateTo などの属性を使用して、姓、生年月日などを変更できます - 徐々に変化するディメンション

2. ドキュメント- documentId、番号、タイプ

3. 住所- addressId、city、street、house、flat

(Person と Document) の関係は 1 対多、(Person と Address) の関係は多対多です。

私の目標は、次の質問に答えることができる履歴ファクト テーブルを作成することです。

1. 定義された日付に定義された住所に住んでいたのは、どの文書を持ったどの人物ですか?

2, 定義された住所には、定義された時間間隔でどのような居住者の履歴がありますか?

これはDWが設計したものだけではなく、DWの設計で最も難しいことだと思います。

たとえば、personId=1 の Miss Brown と documentId=1 および documentId=2 のドキュメントは、2005 年 1 月 1 日から 2010 年 2 月 2 日まで addressId=1 のアドレスに存在し、その後 addressId=2 に移動しました。 2010 年 2 月 3 日から現在の日付まで住んでいます (NULL?)。しかし、彼女は 2006 年 4 月 5 日から姓を Mrs Green に変更し、2007 年 6 月 7 日から documentId=1 の最初のドキュメントを documentId=3 に変更しました。personId=2、documentId=4 の Mr Black は、2010 年 2 月 3 日から現在の日付まで addressId=1 に住んでいます。

addressId=1 で、時間間隔が 2000 年 1 月 1 日から現在までである質問 2 のクエリで期待される結果は、次のようになります。

行:

複合キー (personId、documentId、addressId、dateFrom) を使用してファクト テーブルを作成するというアイデアがありましたが、このテーブルをロードして、この構造で期待される結果を得る方法がわかりません。

どんな助けでも喜んでします！

こんにちは、私はデータ ウェアハウジングの初心者です。宿題として、論理設計、物理、および実装について質問してください。データ ウェアハウスでこれをどのようにモデル化しますか。

野球リーグに関する統計の回答を提供するデータ ウェアハウスを設計したい

プレイヤー向け

攻撃的に:

•打者が何回打者を打ったか。

•得点は何ランです。

•ヒット、ダブルヒット、トリプルヒットの数。

•本塁打の本数。

•打点が多い。

•多くのベースボール

守備で：

▪ アウト数、ダブル プレーにかかる回数

▪ アシスト数

▪ リードまたはピッチャーのエラー数:

▪ 負けたゲームの数

▪ たくさんのゲームに勝った

▪ 保存したゲームの数

▪ 完投でリードした回数

▪ ブリーチが何回も開始されたゲームの数

▪ ヒット数、ダブルヒット数、トリプルヒット数、ホームラン数

選手のデータに関しては、これをシーズンとして見ることができることが重要です.DWの設計の正確な部分に関する参考文献を知っている人はいますか? 何か案は？

どうもありがとう。

事実を含まないレコードを保存する方法は? たとえば、店が何人の人が店内に入ったかを数えたいとします (そして、店内に入ったすべての人について情報を取得します)。ウェアハウスには、さまざまな属性を持つディメンション テーブル "Person" があると思いますが、ファクト テーブルはどのようになりますか? 外部キーのみが含まれますか?

ファクトテーブルのフィールドを挿入し、行を最後に更新することが重要であることがわかりました。しかし、これが良いことだと言っている標準的なデータウェアハウスやリファレンスは見つかりませんでした。これが悪い習慣であるためかどうかはわかりません。もしそうなら、なぜそうすべきですか？データサイズが原因である場合、完全な日付フィールドではわずか8バイトであることがわかります。

どんな助けでも大歓迎です!!!

Dimension Usage タブの下にある「FACT Relationship Type」の適切な使用法を誰かが説明してくれることを期待していました。ファクト テーブル自体の属性にアクセスするために、ファクト テーブルからディメンションを作成するだけですか?

前もって感謝します！

データマートを構築しようとしています。

私は多くのディメンションといくつかのメジャー - 事実を持っています。すべてのメジャーは、ビジネスの観点からすべての次元に接続されています。すべてのメジャーを含む 1 つの大きなファクト テーブルを作成するという標準的なアプローチがあります。

しかし、私には考えがあります。メジャーごとに個別のファクト テーブルがあるとしたらどうなるでしょうか。データベースのパフォーマンス、ソリューションの拡張性などはどうなりますか?

編集::: 非常に複雑な企業環境では、olap キューブに基づく巨大なソリューションが存在します。したがって、ニーズは、最初は拡張性と保守の容易さであり、次にパフォーマンスです。

データベースにファクト テーブルを作成しようとしているので、多くの外部キーを挿入する必要があります。特定の外部キーを挿入しようとすると、次のエラーが発生します。

外部キー '%.*ls' の参照列リストの列数が、参照先テーブル '%.*ls' の主キーの列数と一致しません。

fkey のデータ型が同じであるため、このエラーが発生する理由がわかりません。

ありがとう！！

SQL Server 2008 と Analysis Services を使用してウェアハウスを作成しています。ディメンション テーブルを作成してデータを入力することはできましたが、ファクト テーブルをロードするための SQL を記述するのに苦労しています。1 つには、ディメンション テーブルの PK を使用してファクト テーブルのキーを読み込む方法がわかりません。キーと必要なメジャーを取得するための一連の JOIN を持つクエリを作成しようとしましたが、ステートメントが複雑すぎて迷子になりました。

これは、私が作業しなければならないスター スキーマです。

http://i.imgur.com/C3DGj.png

私は何を間違っていますか？かなり基本的なものが欠けているような気がしますが、これにはかなり慣れていないため、オンラインで見つけた情報のほとんどは、インストールしていない SSIS の使用を扱っているようです。

どんな助けでも大歓迎です。

開発中のスター スキーマの特定のディメンションに何を入れるべきか、ファクト テーブルに何を入れるべきかを判断するのに苦労しています。

例として、プロジェクトが不動産管理会社の住宅を追跡しているとしましょう。さまざまな日付、賃借人、契約などのディメンションはすべてかなり簡単です。家の場合、データがどこにあるかに関係なく、現在の所有者、現在の賃借人、現在の賃貸契約、および近隣、住所、現在の賃貸価格、現在の市場価値などを追跡する必要があります。 . 所有者、賃借人、および契約自体が次元であることに注意してください (また、近隣と住所も次元である可能性がありますが、私はそれらをあまり気にしません)。

家について保持されている多くのデータは、クエリのフィルター処理や、キューブの行ヘッダーと列ヘッダーに使用されます。その一部は、補助的な情報としてのみ必要であり、家ごとに見られますが、全体としては必要ありません.

データとそれをどうする必要があるかを考えると、(少なくとも) 3 つのオプションがあります。

• DimHouse: house テーブルはディメンションであり、ファクト テーブルの方が見栄えがするかもしれない多くの属性がありますが、それらは参照とフィルター処理に使用されるため、ここにある必要があります。現在の賃借人のような属性には、スノーフレーク/アウトリガーが必要になります。
• FactHouse: 他のファクト テーブルに結合されたハウス情報の累積スナップショットを持ちます。おそらく、トリミングされた DimHouse をブリッジとして使用します。これは私には奇妙に思えますが、事実のように見えるものを事実テーブルに入れます。
  • 現在の所有者、現在の賃借人などを関連するファクト テーブルに入れ、それらの事実を所有者/賃借人/その他として最新の状態に保ちます。変更します (これも奇妙ですが、私たちをスター スキーマの土地にとどめます)。

ということで、次元ルートを下ってきました。胸焼けしますが、目標を達成します。データを整理するためのより良い方法があるかどうかを知りたいだけです。冗長性 (類似したデータを持つファクト テーブルとディメンション テーブルを使用するなど) やスノーフレークは、それらが意味を成し、物事を行うための最良の方法 (「最善」の値の場合) であれば気にしません。