2

4 つのディメンション テーブルと 1 つのファクト テーブルを含むデータ ウェアハウスの設計があります。

  • dimUser id、電子メール、firstName、lastName
  • dim住所 ID、都市
  • dimLanguage id、言語
  • dimDate id、startDate、endDate
  • factStatistic id、dimUserId、dimAddressId、dimLanguageId、dimDate、loginCount、pageCalledCount

私たちの問題は次のとおりです。統計の計算 (userId、日付範囲に応じて) と外部キーの入力を含むファクト テーブルを作成したいと考えています。

しかし、自然キーの使用方法を理解していないため、方法がわかりません (私たちが読んだ文献によると、これが問題の解決策のようです)。

自然キーは、ディメンション データを計算するすべての ETL ジョブで必要とされる userId になると思います。

しかし、多くの困難があります:

  • ETL ジョブ load() では、重複を削除するために INSERT IGNORE INTO を使用して一括挿入を行います => 生成された代理キーはわかりません
  • メタ データ (dimension_name、surrogate_key、natural_key のセットを含む) を作成すると、重複排除のために機能しません。

問題は、重複排除戦略にあるようです。より良いアプローチはありますか？

違いがある場合は、MySQL 5.1 を使用しています。

4

2 に答える 2

1

ファクトテーブルがユーザーごとのログインとページ呼び出しを追跡している場合は、これらを追跡する一連のソーステーブルが必要です。ここから、ファクトテーブルデータをロードします。私はおそらく、ユーザー/ログイン日ごとに1行の粒度でファクトテーブルを作成します。可能であれば、アトミックデータを永続化するためにさらに低くします。

ここで、ユーザーと日付の2つのディメンションを持つファクトテーブルが作成されます。住所と言語を事実の次元として保持することもできますが、これらは実際にはユーザーの属性にすぎません。

ディメンションには代理キーが必要ですが、ソースの「ビジネス」キーまたは「自然」キーも利用可能である必要があります。ディメンション自体の属性として、または同僚が提案したマッピングテーブルを介して使用できます。マッピングテーブルを使用することは「間違っている」わけではありません。複数のソースがある場合は、作業が簡単になります。

ビジネスキーをマッピングテーブルに保存するか、属性としてディメンションに保存する場合、ファクトでロードする各行について、代理キーを取得するためのdimまたはマッピングテーブルに対する単純なルックアップ（通常は結合を介して）です。ユーザーのために（そしてユーザーからユーザーの「現在の」アドレス/言語を取得して事実を維持するために）。日付ディメンションには通常、YYYYMMDDまたはその他の「自然な」形式で保存された代理キーがあります。これは、ファクトに読み込んでいるソースレコードの日付情報から生成できます。

于 2012-12-22T02:38:29.210 に答える
0

単一のクエリを強制せず、別々のクエリでデータをロードし、いくつかのプロバイダーでデータを混合してみてください...

于 2012-12-20T14:49:33.087 に答える