0

一般的な ETL フローでは、ソース (テーブル、ファイル、Web サービスなど) からデータマートにデータを選択しています。

行が変更されたかどうかを識別するために、MS-SQL hashbyte-function を使用しています。

たとえば、主キー = CountryCode および Zip を持つ CountryCode、Zip および CityName を持つ都市テーブルで

 SELECT CountryCode, Zip,  CityName, 
 CONVERT(VARCHAR(40), HASHBYTES('MD5', 
 (SELECT CityName FROM spo.City sub 
  WHERE sub.Zip = main.Zip  
    AND  sub.CountryCode = main.CountryCode  
    FOR XML RAW )), 2) AS SysCheckSumSCD1 
FROM spo.City main

私の問題は、ソースで主キーが重複している場合です

次に、HASHBYTES で使用される副選択には両方の列が含まれ、両方の行に同じハッシュキーが含まれます。したがって、データマートが正しく更新されません。さらに、ソースに重複があることは通知されません。

結果の例:

Zip     CountryCode     CityName        SysCheckSumSCD1
14600   FR              Honfleur        6D8EF511B35621FC0F5CC67AA6B98EEA
14600   FR              Equemauville    6D8EF511B35621FC0F5CC67AA6B98EEA

代わりに、呼び出しを失敗させたいと思います。

以前、実際の行を入力として取り、上記の例で失敗した CHECKSUM 関数を使用しました。しかし、残念ながら文字列のみを入力として受け取る HASHBYTES に変更する必要がありました。「FOR XML RAW」部分の理由はどれですか

有益な情報をいただければ幸いです。それは大規模な汎用ソリューションの一部であるため、上記の SQL ステートメントを変更するだけで実装できる望ましいものです。そして、私の手は少し縛られています。

エラーを強制するためにダミー集計関数を追加することを考えていました。しかし、それを行う方法を理解することができませんでした。

4

1 に答える 1

0

週末を終えてキーボードに戻ると、脳が充電されます。解決策は実際には非常に簡単であることに気づきました。

'SELECT () AS FOO' を追加して、HASHBYTES に渡されたステートメントをサブクエリにするだけです。:-|

したがって、ステートメントは次のようになります。

SELECT CountryCode, Zip,  CityName, 
CONVERT(VARCHAR(40), HASHBYTES('MD5', 
     (SELECT 
      (SELECT CityName 
      FROM spo.City sub 
      WHERE sub.Zip = main.Zip 
      AND  sub.CountryCode = main.CountryCode) AS FOO 
     FOR XML RAW )), 2) AS SysCheckSumSCD1 
FROM spo.City main
于 2015-01-12T10:04:13.350 に答える