3

私たちの組織は現在、新しいデータウェアハウスを構築中です。実際には、ETL処理など、DWコミュニティから借用したいくつかの手法を使用して、データの適合、「キンバル」スタイルの非正規化ディメンションなどを使用できます。全体として、データウェアハウジングは、組織にとってまだかなり新しいものですが、私たちが進むにつれて、概念を学んでいます。

問題：データのソースが複数あり、事実のソースが競合することがよくあります。たとえば、マスターパーソンインデックスがあります。このインデックスでは、ETL中にスコアベースのマッチングアルゴリズムを使用して、インバウンドの人を既存の人とマッチングします。これにより、インバウンドレコードが完全に一致しなくても、他のものに基づいてスコアを付けることができます。郵便番号の半径のように。

質問は次のとおりです。2つ以上のソースからのファクトの複数のバージョンを処理するための標準的な方法は何ですか？

データウェアハウスの主なアイデアの1つは、私たちが行っている事実の実行履歴を保持することであることを理解しています。あるインバウンドソースによってレコードが維持されている場合、それはすべて問題なくダンディです。私たちはその事実の履歴を長期にわたって保持します。この問題は、おそらく毎日更新される2つの異なるソースに2つの異なる事実がある場合に発生します。たとえば、ソースAは名前がメアリースミスであると言い、ソースBは名前がメアリージェーンであると言ってこの値を毎日変更します。マッチングアルゴリズムに基づいて、同じ人物であると確信していますが、履歴スタイルテーブルにより、各データソースから「変更」として名前を読み取っているため、基本的に毎日両方の名前を行き来し続けます。

表の例：

first_name  last_name    source    last_updated
Mary        Smith        A         5/2/12 1:00am
Mary        Jane         B         5/2/12 2:00am
Mary        Smith        A         5/3/12 1:00am
Mary        Jane         B         5/3/12 2:00am
Mary        Smith        A         5/4/12 1:00am
Mary        Jane         B         5/4/12 2:00am
...
4

2 に答える 2

4

外部データを格納するテーブルを 1 つ用意します。

 id | first_name | last_name | source | external_unique_id | import_date
----+------------+-----------+--------+--------------------+-------------
  1 | Mary       | Smith     |    A   |     abcdefg123     | 5/2/12 1:00am
  2 | Mary       | Jane      |    B   |     1234567abc     | 5/2/12 2:00am

次に、クリーニングされたデータを含む 2 番目のテーブルを用意します。

 id | first_name | last_name 
----+------------+-----------
  1 | Mary       | Jane-Smith     (or whatever)

次に、2 つの間のマッピング テーブルを作成します。

 local_person_id | foreign_person_id
-----------------+-------------------
       1         |        1 
       1         |        2

または、広く似たもの。


目的は、ソースからファクトを一度ロードして保持することです。

次に、ファジー ロジックを使用して、それらをどこかのマスター レコードに関連付けます。これは、新しいファクトが読み込まれたとき、または古いファクトが変更されたときにのみ行う必要があります。

それでも、何last_nameを使用するかを選択できます。しかし、決定的なデータがない場合、それはほとんど恣意的なものになる可能性があります。例：最近ロードされたファクトから姓を選択します。

マスターを子ファクト、そのソース、および対応するデータにすばやく簡単に関連付けることができます。しかし、倉庫には、これらの外部の事実を保持するための統一されたエンティティがあります。

于 2012-10-08T12:23:19.997 に答える
2

用語についての 1 つのこと - リストしたのは「事実」ではなく「属性」です。ファクトは、次元属性のセットに対して行う尺度です。(たとえば、この「人」が出した注文、またはこの顧客の最近の注文の金額など)。この場合、ディメンション属性の複数のソースがあり、それぞれが「同じ」と見なされます。

@Dems メソッドは、クリーニングされたデータをステージング/運用データ セットから分離しておくための 1 つの方法 (そして良い方法) です。

もう 1 つは、レポートで両方のデータ セットにアクセスする必要があり、「クリーン」なバージョンを維持する必要がある場合は、個人/顧客ディメンションにすべての属性を配置することです。

   FIRST_NAME
   LAST_NAME
   SOURCE1_FIRST_NAME
   SOURCE1_LAST_NAME
   SOURCE2_FIRST_NAME
   SOURCE2_LAST_NAME

ユーザー コミュニティがソース 2 からの名前を期待しているメジャーに関するレポートの場合、source2 属性を使用できます。ソース 1 を期待する人は、それを使用してください。名前に「一致する」処理の結果を探している人は、main 属性を使用します。

于 2012-10-08T13:44:00.307 に答える