1

ディメンション モデリングのコンテキストでは、典型的なケースとして、行の変更を追跡するためにディメンション テーブルに代理キーがあると便利です ( http://www.kimballgroup.com/2006/07/design-tip-81-fact-テーブル代理キー/ )。

代理キーを実現するには、3 つの一般的な方法があります。1) シーケンス番号 2) バージョン番号 3) ハッシュ キー (データ ボールトで使用)

私の質問は、私が見たほとんどの次元モデリングでシーケンス番号が好まれる理由です。

どうもありがとう

4

1 に答える 1

3

シーケンス番号が一般的に使用される理由はいくつかあると思いますが、すべての状況で明らかに優れた方法だとは思いません。

シーケンス番号

長所

  • シーケンス番号は簡単です。それらはとてつもなく簡単なので、ほとんどの場合、他のことを考えるのは時間の無駄です。これが私たちがそれを使用する理由ではないことを誰にも言わせないでください.
  • シーケンス番号は一意であることが保証されています。
  • シーケンス番号は可能な限り小さい (狭い) ものです。
  • シーケンス番号は情報をエンコードしないため、内容が変更されても、ディメンションの粒度が変更されても、事実がわかっている限り問題ありません。次元の粒度は簡単に変化する可能性があるため、これは重要です。そのため、意味のあるデータで代理キーを使用するべきではありません(少なくともキンボール DW では、代理キーのポイントのようなものです)。

短所

  • シーケンス番号は本質的にスペースの無駄です。これに情報をエンコードできれば、より大きな列にすることによってもスペースを節約できます。ただし、上記の長所を参照してください...
  • ページのロックが原因で書き込みパフォーマンスが低下することがあるシーケンス番号に関する投稿を見たのを覚えていますが、今は見つかりません。これにより、読み込みが遅くなる場合があります。

バージョンナンバー

私は前にこれの例を見たことがありません、そしてそれについてグーグルで調べると、この質問とそれを既存のフィールドに追加することへのいくつかの参照が見つかるようです.ハッシュ、またはその他の識別子。

長所

  • データのバージョン番号にアクセスできます
  • これは、DW ディメンション キーとして使用できるように、自然キーを一意化する方法である可能性があります。

短所

  • 最大の短所は、キーから削除しないとこのデータにアクセスできないことです。別の列としてそれを持たないのはなぜですか？
  • 通常、自然キーは DW では悪い習慣です。そのため、それが動機である場合は、アプローチを再考することをお勧めします。

ハッシュ

シーケンス番号を使用しない場合は、おそらくこれが私の好みのオプションです。私は思うが、いくつかのかなり特定の状況が必要です

長所

  • タイプ 2 の緩やかに変化するディメンションに最適 - ハッシュを別の列に保存する必要がないため、スペースを節約できます

  • 代理キーに情報をコーディングすることは、将来の開発のために足を踏み入れることを意味しない数少ないケースの 1 つです。

    短所

  • タイプ 1 のゆっくりと変化する寸法を使用している場合は、自分の足を突き刺しただけです。属性を更新しましたか? データベースの半分を削除せずに主キーを更新してみて、どこまで到達するかを確認してください。

  • 大きいです。これによりファクト テーブルが大きくなり、データベースが大きくなります。列ベースの圧縮を使用している場合、これは皮肉なことに、ディメンションが大きくなるほど大きな問題になります (ある程度...)

結論

したがって、状況によって異なりますが、シーケンス番号は実装が非常に簡単で、ほとんどすべての状況で短所はほとんど無視できるため、快適なデフォルトとして使用できます。したがって、別のオプションを選択することは、通常、「なぜそれを行ったかを説明する必要がある」カテゴリに分類されます。

于 2016-04-21T23:23:55.623 に答える