したがって、Azure SQL Data Warehouse は ID 列をサポートしていないため、代理キーを処理するのは難しい..誰かがこれについて大胆な解決策を持っていますか?
これは私が見つけた中で最高のもので、かなり恐ろしいものです。
したがって、Azure SQL Data Warehouse は ID 列をサポートしていないため、代理キーを処理するのは難しい..誰かがこれについて大胆な解決策を持っていますか?
これは私が見つけた中で最高のもので、かなり恐ろしいものです。
これが最良の選択肢ですが、特定の値でソートする必要がないように OVER 句で定数値を使用でき、変数を使用する必要はありません。
INSERT INTO testTgtTable (SrgKey, colA, colB)
SELECT
ROW_NUMBER() OVER(ORDER BY (SELECT 1)) + (SELECT ISNULL(MAX(SrgKey),0) SK FROM dbo.testTgtTable) SK
, [colA]
, [colB]
FROM testSrcTable;
ファイルに行番号が存在する場合や、簡単に追加できる場合があります。存在する場合、これを利用して代理キー値を生成できます。それは多段階のプロセスです
コードは次のようになります。
DECLARE @max_count bigint
SET @max_count = (SELECT MAX(ID) FROM Fact)
...
CREATE TABLE Input_Load
WITH (DISTRIBUTION = ROUND_ROBIN
,CLUSTERED COLUMNSTORE INDEX
)
AS
SELECT @max_count + RowNumber
, ...
FROM dbo.stage_table
;
ハッシュベースの代理キーは、SMP から MPP データ ウェアハウスへの移行、および BI エコシステムへの Hadoop、NoSQL、およびその他のビッグ データ拡張機能の導入により、シーケンス ベースの代理キーを置き換えるのが理にかなっています。
シーケンスベースの代理キーよりもハッシュベースの代理キーを検討する理由はいくつかあります。
BI エコシステムのさまざまなプラットフォームで一貫した代理キー生成アプローチ。ETL ツール (SSIS、DataStage など)、NoSQL または MPP データベース、Hadoop 実装など、さまざまな環境で一貫性のあるハッシュベースのキーを個別に生成できます。
ハッシュ ロジック ベースの代理キーは、ETL とは対照的に、ELT 実装ではシーケンス ベースの代理キーよりも意味があります。「データをロードして処理する」(ELT) は、MPP および BigData ソリューションで推奨される方法です。ルックアップをハッシュ値計算に置き換えることで、データの読み込みと変換のプロセスが簡素化されます。結果として、これは I/O 集中型の操作 (ルックアップ) から CPU 集中型の操作 (ハッシュ生成) に移行します。
ハッシュベースの代理キーは一貫性があり、独立して生成できるため、テーブル間の依存関係を回避できるため、多くの場合、すべてのデータのロード/変換プロセスを完全に並行して実行できます。
多くの場合、リアルタイム/ほぼリアルタイムのデータ更新シナリオでは、ステージング領域をスキップしてファクト テーブルに直接挿入できる追加のルックアップを実行する必要がなくなるため、ハッシュ ベースの代理キーをオンザフライで生成できます。
開発、UAT、および本番環境全体で一貫した代理キー。
固定長のハッシュ キーでの結合は、ほとんどの MPP データ ウェアハウス プラットフォームで最適です。
以下にいくつかの提案を示します。
ディメンション テーブルの主キーのハッシュ関数への入力として、自然なビジネス キーを使用します。
ファクト テーブルのハッシュ関数への入力として、主キーを構成する連結された自然なビジネス キーを使用します。偶発的な衝突を避けるために、連結するビジネス キーを特定の文字 (| など) で区切ることを忘れないでください。
ファクト テーブル内のディメンションへのリンクのハッシュ関数への入力として、自然なビジネス キーを使用します。
ただし、いつものように、警告の言葉!ハッシュベースの代理キーは衝突を引き起こす可能性があります。つまり、2 つの異なる入力値が与えられた場合に同じハッシュ値が生成される可能性があります。詳細については、こちらとこちらをご覧ください。