database - 主キーと制約

Question

(もちろん) OLTP データベースから構築された新しいデータ ウェアハウスでは、すべての IDENTITY 列を削除し、それらを INT 列に変更しました。

特に倉庫が非正規化されているため、以下に関するベストプラクティスは何ですか:

1. 主キー
   -> 複数のテーブルが結合されているため、これは複合キーになっている可能性があります
   -> OLTP のキー構造に従う必要がありますか?
   
   
2. 制約
   -> ビット列のデフォルト値 (0) を持ついくつかの制約 (NOT NULL) があります
   

Answer 1

主キーには、代理キーまたは代替キーの使用を検討してください。ゆっくりと変化する次元に対応する必要があります。たとえば、過去 5 年間の既婚/未婚の販売員あたりの平均売上に関するレポートを作成している場合、誰かが 2 年間未婚だったという事実を登録する必要があります。最後の 3 人は既婚者です。これは、データ ウェアハウスに同じ人物のディメンション テーブルの行が 2 つあることを意味します。そのためのOLTP構造に従うのは難しいでしょう:)

制約はそれほど問題ではありません。DW は読み取り用に大幅に最適化されており (バッチとして入力している場合)、制約は実際には読み取り操作を考慮していません。通常、DW の入力ジョブで制約の問題を回避し、必要に応じてレポート ツールで null などを処理できます。既定値が概念的なデータ モデルに適合し、DW クライアント ツールで問題が発生しないようにすることがはるかに重要です。

Answer 2

ディメンションテーブルの場合:

• 日付ディメンションを除いて、サロゲート自動インクリメント (ID) PK を保持します (以下を参照)。
• ゆっくりと変化する次元 (タイプ 2) を可能にする代替の「自然キー」があることを確認します。
• ディメンション テーブルでは NULL を使用できません。詳細な「n/a、未入力、不明..」に置き換えてください。
• 可能であれば、ブール フラグ (1/0) を詳細な「はい、いいえ」に変更して、レポート/ビジネス ユーザーが使いやすいようにします。
• 計算フィールドを取り除き、それらを値に置き換えるか、少なくとも計算フィールドを永続化します-データベースに依存します。
• 可能であればスター スキーマを実装し、容量と引き換えに速度を上げます。必要な場合のみスノーフレーク。
• クエリを確認し、句に関数がある場合はWHERE、ディメンション テーブルに列を追加し、値を事前に計算します。
• PK が 20090619 のように見える場合、日付ディメンションを分割するのは簡単です。
• チェック制約とデフォルトを取り除き、ETL プロセスの適合フェーズに移動します。チェックとデフォルトはロードを遅くし、ロードが完了すると何の役割も果たしません。

ファクトテーブルの場合:

• 簡単なパーティショニングを可能にするために、サロゲート自動インクリメント (ID) PK を使用することを検討してください。複合 PK を使用する場合は、代わりに複合固有の非クラスター化を作成できます。

• 外部キーのスクリプトを安全な場所に保管してください。ロードを高速化するために、ファクト テーブルをロードする前にキーを削除するのが一般的な方法です。外部キーを「論理のみ」にして DW を実行する人もいますが、ロード後に「孤児を探す」クエリを使用します。

ETL

• ECCD (ETL) プロセスをすべての段階 (抽出、クリーニング、適合、配信) で設計します。
• 可能であれば、監査およびデバッグの目的で、各ステージの後に中間結果 (ファイル) を保持します。
• ETL を文書化し、スクリプトを使用する場合はバージョン管理を使用して、スクリプトのバージョンをアーカイブされた (中間) ファイルと一致させることができます。
• データ系統図を作成します。Excel は何もないよりはましです。バージョンも保持します。

Answer 3

私は2について言います.: ビット列 -> ブール列として機能 -> 1/0 (真/偽) のみ許可 -> 制約 OK