問題タブ [dimensional-modeling]

スター ダイアグラムで表されるリレーショナル データベースの関係とディメンションの違いは何ですか?

課題の一環として、リレーショナル データ ウェアハウスの設計を行っています。ほとんどのテーブルは、多対多、1 対 1、1 対多のリレーションシップ スキーマを使用して正規化されています (これは正しい用語だと思います。違う）。次のステップは、データ マイニング環境で使用できるスター ダイアグラムを描くことです。これは、さまざまな次元から描画されるファクト テーブルを意味すると思います...

1. 私が考えることができるデータ分析はリレーショナル データベースから取得できるため、ここで少し混乱しています。2. データを引き出したいテーブルの一部に外部キーが含まれている場合、それをどのようにディメンションに分割しますか。

例：私はこれらの関係を持っています：

コースの結果がモジュールの成績にどのように関係しているか知りたいです。リレーショナル データベースでは、学生情報を含むテーブルをモジュールの成績テーブルと結合するクエリを実行します。ディメンションとレポートに相当するものは何ですか? 特に、成績関係の主キーとして複数の列を使用しているため..

企業のマーケティング キャンペーンのコンバージョンを追跡する Analytics アプリケーションを構築しています。コンバージョンとは、スーパーマーケットに行って商品を購入することです。会社が Heinz の場合、さまざまな製品のキャンペーンを実行する可能性があるため、キャンペーンは次のようになります。

• ベイクドビーンズ
• トマトスープ
• ケチャップ

これらはオンライン キャンペーンであるため、次のようなさまざまなメディアを使用できます。

• Webサイト
• Facebookのページ
• Flash バナー広告
• モバイルアプリ広告

また、誰かが製品を購入する場合、次のようなスーパーマーケットを介して購入されます。

• ウォルマート
• アズダ
• 安全な方法
• クローガー

そして、これらすべてのコンバージョンを追跡しています。分析アプリケーションは、上記の任意の組み合わせのコンバージョン データを表示する必要があります。たとえば、コンバージョンを表示する必要があるかもしれません...

• ベイクドビーンズ用。
• ベイクドビーンズはFacebookページから。
• スーパーマーケットのウォルマート向けですが、すべてのキャンペーンとメディア向けです。
• Facebook ページから作成された Walmart 用ですが、すべてのキャンペーン用です。
• Flash バナー広告を介して作成されたケチャップと Safeway の場合。

分析を高速化するために、生データ (数百万のレコード) を処理することを避けていますが、1 日ごとに保存されたデータの集計バージョンを保存しています。9 月 12 日の例では、ベークド ビーンズで 12 回のコンバージョンがあり、ウェブサイト経由で 6 回 (すべての製品で)、ウォルマートで 8 回のコンバージョンがあり、これらは 3 つの個別のテーブル (キャンペーン、媒体、およびスーパーマーケット)。しかし、Facebook ページ経由で作成された Ketchup と Walmart のコンバージョンを知る必要がある場合、別々のテーブルに保存することは明らかに機能しません。

上記をサポートできるデータモデルを考え出すのに苦労しています。標準のリレーショナル データベース (MySQL) を使用しています。おそらく、これを処理するためのより良い戦略があります。

分析目的でビジネス プロセスのステータスを追跡する必要があります。時間/トランザクション タイプ/サービス センターに対してトランザクション ファクト テーブルのステータスを保持できること、および累積ファクト テーブルを使用してプロセス ラグを調査できることが言及されている投稿を見たことがあります。複数のステータスを持つトランザクションはほとんどないのでしょうか。 1 日ですべてのステータスをトランザクション ファクト テーブルに保存する必要がありますか? ここでは、ETL が営業日の終わりに完了したと仮定しています。

次に、すべてのキー ディメンション キーをトランザクション ファクト テーブルに保持する必要があります。この場合のキーは、Transaction Type、Department id、Service_type、Service_id、Submission Channel ですか、それとも複数のファクト テーブルに分割する必要がありますか?

3 番目に、どの部門が SLA を満たしているかを報告する必要がある場合、トランザクション ファクト テーブルで SLA 内と SLA 内外を計算して追跡する、または実行時にこの値を計算するのが最善の方法でしょうか?

ご協力いただきありがとうございます。

製品、場所、時間のディメンションに対応するいくつかの事実を保存するアプリケーションを構築しています。たとえば、特定の製品 P1 が特定の月 T1 に店舗 S1 で 10 個販売されたとします。すべてのディメンションには、それらの間に階層を持つレベルがあります。たとえば、時間ディメンションの場合は年/月/週/日です。各レベルのメンバー (メンバーという言葉が正しいかどうかはわかりません) にも、メンバー間に階層があります。他の次元についても同様です。この構造自体を実装することは、階層データを表現するためのオプションを考えると少し難しいです選択は、挿入/更新/削除するデータと選択するデータの頻度と量によって決まります。いくつかの調査を行い、自分のケースに最適なソリューションを選択できます。

しかし、私が現在直面している本当の困難は、事実データが存在する別の空間をモデル化することです。上記の例を参照して、P1 が階層Category/Subcategory/Articleの製品ディメンション レベル "Article" のメンバーであり、S1 が階層Country/City/Storeの store ディメンション レベル "Store" のメンバーであるとします。. ここで、ストア S1 がアイテム P1 を月 T1 に保管していないと仮定し、フラグ IS_ACTIVE を使用してこの決定を表します。つまり、IS_ACTIVE=N はファクトであり、そのコンテキストは {P1,S1,T1} です。また、IS_ACTIVE が属性であり、N がその値であることにも注意してください。ただし、このコンテキスト {P1,S1,T1} 自体は、メタ コンテキスト {Article, Store, Month} のインスタンスです。そして、このメタ コンテキストもアプリケーションに格納する必要があります。その理由は、メタ コンテキスト {Article, Store, Month} に対応する他の可能な属性 (REBATE_OFFERED_PERCENT など) のリストを取得する必要があるアプリケーション内の場所がある可能性があるためです。

私はこれらすべての正規化されたリレーショナル スキーマ設計を考え出しましたが、複雑すぎて、私の意見ではパフォーマンスが向上しません。ここにはいくつかの階層が含まれているため、私のニーズを満たすことができる NoSQL データベースのような代替ソリューションを探しています。または、問題のドメインはリレーショナル スキーマ設計により適していますか?

これは、複数のドメインで発生する標準的な問題のようですが、これに関する記事は見つかりませんでした。また、この問題に関連する抽象数学の分野はありますか? このような問題を説明する標準的な用語はありますか? 解決策を実装する前に、いくつかの理論を読んでみたいと思っています。

特に表形式モデルのコンテキストでは、日時を日と UTCtime の 2 つの次元に分けるのがベスト プラクティスですか? Google は多くの情報を提供しませんでした。

ありがとう。

フリー テキスト フィールドを使用して一部のデータをモデル化するための最良の方法についてアドバイスを求めています。以下は簡略化されていますが、通常、FactIncident テーブルと、DimPropertyType と呼ばれるディメンションがあります。Type1、Type2、および Type3 と呼ばれるプロパティ タイプを定義する実質的に 3 つのフィールドがあり、これらにはそれぞれ可能な 20 の値の 1 つが含まれます。最初にやりたかったことは、次のフィールドを持つ DimPropertype を単純に持つことでした:

PropertyTypeKey

タイプ1

タイプ2

タイプ3

ただし、プロパティ タイプ オプションの各セットのデータを見ると、「その他」というタイトルのオプションと、Type1OtherText、Type2OtherText、Type3OtherText という追加のフィールド セットがあります。データを調べたところ、これらの各フィールドの約 80% が「その他」に設定されており、それぞれの自由テキストが設定されています。ビジネス アナリストと話すと、彼らはこれらのフィールドを制約として使用する検索を行うため、どこかにいる必要があります。

この状況に対処する最善の方法について、誰かアドバイスはありますか? データを調べてみると、この問題はさまざまな次元で発生しているため、何度も対処する必要があります。

ありがとう。