問題タブ [fact-table]

投稿されたフォーム データを分析するためのスター スキーマに取り組んでいます。フォーム データが投稿されるサイトは、実際にはフォームをホストするサイトの外部にあるため、フォーム内のデータのみが利用可能になります。非表示のフィールド、元のリファラー、セッション ID などの追加の有用な情報を含めるオプションを提供します。

正規表現を使用して特定のデータ型に一致させ、郵便番号などの特定の次元に引き出すことができます。

次元の恣意的な性質に対処するための解決策があります。それは素晴らしいものではありませんが、うまくいくでしょう。

私が抱えている問題は、ファクト テーブルに何が入るかわからないことです。集計できる適切な数値があるわけではありません。これらの基準を満たす「はい、フォーム投稿があります」という事実は別として。

私はこれに正しい方法でアプローチしているかどうか疑問に思っていますか？仕事に間違ったツールを使用していませんか? それとも、何かが足りないのですか？

サイモン。

詳細:

機能には 2 つの領域があり、2 つのタイムスタンプなどの条件に基づいてフォーム投稿をフィルタリングします。しかし、フィルタリングに関しては、ほとんど何でも手に入れることができます。選択したフォーム投稿は、エクスポート用の csv ファイルを生成するために使用されます。

もう 1 つの主な分野は分析です。広告費から顧客へのリードへの変換を研究することは、当然の出発点です。また、多少オープンエンドであり、フォームデータに依存します。

私は、ユーザーが一連のファクト テーブルに対して任意にクエリを実行できるようにするレポート システムに取り組んでおり、ファクト テーブルごとに複数のディメンション テーブルを制限しています。制約パラメーターに基づいてすべての正しい結合とサブクエリを自動的にアセンブルするクエリ ビルダー クラスを作成しましたが、すべてが設計どおりに機能します。

しかし、私は最も効率的なクエリを生成していないと感じています。数百万件のレコードを含む一連のテーブルでは、これらのクエリの実行に約 10 秒かかります。1 秒未満の範囲に収まるようにしたいと考えています。サブクエリを取り除くことができれば、結果ははるかに効率的になると感じています。

実際のスキーマ (はるかに複雑です) を示すのではなく、アプリケーションとデータ モデル全体を説明することなく、要点を説明する類似の例を示します。

アーティストと会場を含むコンサート情報のデータベースがあるとします。ユーザーは、アーティストと会場を任意にタグ付けできます。したがって、スキーマは次のようになります。

ものすごく単純。

ここで、今日から 1 か月以内に開催されるすべてのコンサート、「cheap-beer」および「great-mosh-pits」タグでコンサートに出演する「テクノ」および「トロンボーン」タグを持つすべてのアーティストについて、データベースにクエリを実行するとします。 .

私が思いついた最高のクエリは次のようになります。

クエリは機能しますが、これらの複数のサブクエリを使用するのは本当に好きではありません。純粋に JOIN ロジックを使用して同じロジックを実現できれば、パフォーマンスが大幅に向上すると感じています。

完璧な世界では、実際の OLAP サーバーを使用することになります。しかし、私の顧客は MySQL、MSSQL、または Postgres にデプロイする予定であり、互換性のある OLAP エンジンが利用できるとは保証できません。そのため、スター スキーマを持つ通常の RDBMS を使用することに行き詰まっています。

この例の詳細にあまりこだわらないでください (私の実際のアプリケーションは音楽とは何の関係もありませんが、ここで示したものと類似した関係を持つ複数のファクト テーブルがあります)。このモデルでは、「artist_tag」テーブルと「venue_tag」テーブルがファクト テーブルとして機能し、それ以外はすべてディメンションです。

この例では、ユーザーが単一の artist_tag またはvenue_tag 値に対してのみ制約できるようにすると、クエリの記述がはるかに簡単になることに注意することが重要です。複数の異なるタグを必要とする AND ロジックをクエリに含めることを許可する場合にのみ、非常に扱いにくくなります。

私の質問は、複数のファクト テーブルに対して効率的なクエリを作成するための、あなたが知っている最良の手法は何ですか?

キューブで使用されているファクト テーブルが実際にはビューであることに気付きました。実際、それらはファクト テーブルのテンプレートでした (ファクト ビューに "where 1=2" が使用されていることがスクリプトでわかりました)。

そのため、テンプレートを使用すると、ビューにデータが表示されることはありません (ビューに挿入権限がないため、ビューに挿入できるかどうかはわかりません)。

ですから、私の質問は次のとおりです。立方体に見るべきものが欠けていますか? キューブは非常に経験豊富な開発者によって設計されており、私は単なる QA です。キューブ設計ペインは、テンプレートを使用していることを明確に示しています (DSV デザイナーの各長方形オブジェクトの黄色のヘッダーに示されているように)。ヘッダーに表示されているものとは対照的に、他のテーブル/ビューを参照できますか?

ファクト テーブルには 16 個のパーティションがあります。16 個すべてが同じ構造を持ち、同じ集約スキームを持っています。それらの 15 にはデータが含まれており、16 番目にはデータが含まれていません。

では、DSV デザイナーのファクト テーブルはそれらのパーティションの 1 つにすぎないのでしょうか? (ただし、ヘッダーの名前はパーティションの 1 つと一致します)

そうであれば、別のパーティションを処理する必要があるときはいつでも、デザイナでファクト テーブルを置き換えて再処理するだけですか?

メジャー グループに 1 つのパーティションがあり、集計が 0% に設計され、パーティション テーブルが空のテーブル (テンプレート) として使用されている場合、キューブ ブラウザーはどのようにしてそのメジャー グループのメジャーのデータを表示しますか。

参考までに: パーティションは通常、vw_fact_patronrevenue_2007_1、vw_fact_patronrevenue_2007_2 などのように、データを含まないテンプレート (vw_fact_patronrevenue_template) と共に月単位で作成されます。

しかし、私が問題を抱えていた特定の測定では、パーティションは 1 つだけで、パーティション テーブル/ビューはテンプレートです。

ディメンション（SiteItem）には2つの重要な事実があります。

ただし、このディメンション内には、属性列に基づく値のグループ（AboveFoldItems、LeftNavItems、OnTheFlyItemsなどのグループを呼び出します）があり、それぞれにそのグループに固有のファクトがあります。

次のファクトテーブルスキーマは大丈夫ですか？

一部の列のみが一部のディメンションキーに関係しているため、少し無駄に思えます（無関係なファクトはNULLのままです）。しかし...これは一般的な問題のように思われるので、これには一般的な解決策があるはずですよね？

FactTableにディメンションテーブルへの12回のルックアップを入力してSKを取得しました。そのうち、6回は異なるDimテーブルへのルックアップで、残りの6回は同じ自然キーへのルックアップを行う同じDimTable（タイプII）へのルックアップです。

元：

PrimeObjectID=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

同じことをする他の列を取得しました

OtherObjectID1=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID2=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID3=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID4=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

OtherObjectID5=>DimObject.ObjectIDへのルックアップ=>ObjectSKを取得

このような複数のルックアップの場合、SSISパッケージでどのように処理する必要がありますか。

今のところ、lookup /unionallforeachルックアップを使用しています。これにもっと良い方法はありますか？

さて、ファクトテーブルでこの問題が発生しました。ファクトテーブルに外部キーを持つデータベース内の他のすべてのテーブルに新しいデータが入力されたときに、自動的に入力する必要があります。ストアドプロシージャで、持っているすべての挿入ステートメントをコンパイルし、最後にファクトテーブルも更新したいので、次のクエリを配置します。

ただし、次のメッセージでエラーが発生します。

誰か助けてくれませんか？どうもありがとう。:)

私の完全な手順：

私はデータ ウェアハウジングを初めて使用します。まず、The Data Warehouse Toolkit のコピーが私のメールボックスに届いていることを正確に伝えたいと思います (snail mail :P)。しかし、私はすでにネットで見つけたものでこれらすべてを研究しています.

ただし、ネット上で見つけられないのは、DW に複数の事実があると思われる場合の対処法です。私の場合 (保険)、不定期に発生する払い戻しがあります。1 人のクライアントが 3 か月間何も持たず、同じ月に 10 人も持つことができます。一方で、毎月または 3 か月ごとに発生する「サブスクリプション料金」 (正確な英語の用語はわかりませんが、要点はわかります) があります。それは明らかに 2 つの異なる事実のように思えます。

これら 2 つは、クライアントや「保険商品」など、いくつかの次元によって疎結合されています。これら 2 つの異なる倉庫で、2 つの異なるレポートを作成し、DW の外部でレポートを接続する必要がありますか? または、単一の降下 DW に適合するようにこれを設計する方法はありますか。それとも、これら 2 つの事実を 1 つにまとめる必要がありますか? その場合、おそらく払い戻しの粒度が失われるでしょう。

私が読んだブログで、DW には常に 1 つのファクト テーブルがあると書かれていました。他の人は、S を含むファクト テーブルとは何かを設計するステップについて言及していますが、それらの間にリンクがあるのか​​、それとも同じ DW プロジェクトの別個のコンポーネントにすぎないのかについての明確な指示はありません。

DW 設計の正確な部分に関する参考文献を知っている人はいますか?

PostgreSQL 9.0 で次の構造を持つテーブルを想像してください。

簡単にするために、1 つのテキスト列だけを取り上げますが、実際には 12 のテキスト列があります。このテーブルには 100 億行あり、各列には多くの重複があります。テーブルは、COPY FROM を使用してフラット ファイル (csv) から作成されます。

パフォーマンスを向上させるために、次のスター スキーマ構造に変換したいと考えています。

ファクト テーブルは、次のようなファクト テーブルに置き換えられます。

私の現在の方法は、基本的に次のクエリを実行してディメンション テーブルを作成することです。

次に、使用するディメンション テーブルを作成します。

その後、次のクエリを実行する必要があります。

すべての文字列を他のすべての文字列と数回比較することで得られる恐ろしいパフォーマンスを想像してみてください。

MySQL では、COPY FROM 中にストアド プロシージャを実行できました。これにより、文字列のハッシュが作成され、その後のすべての文字列比較は、長い生の文字列ではなくハッシュに対して行われます。これは PostgreSQL ではできないようですが、どうすればよいですか?

サンプル データは、次のようなものを含む CSV ファイルになります (整数と倍精度も引用符で囲みます)。