4

2 つの考え方があります。

  1. できれば次の形式の代理キーを使用してください: YYYYMMDD は常にシーケンシャルであるためです。

  2. 日付ディメンションの代理キーを削除し、代わりに実際の日付を使用してください。

次元モデリングの専門家への私の質問は次のとおりです。

1> Which design would you prefer and why?

2> How should we handle unknown values in each of the cases, Can we simply place 
   NULL in Fact table for unknown dates as Foreign Key can be NULL (if not why)?

3> If we need to partition fact table on date column, how would we achieve that 
   in case 1.

実際の日付を使用し、ファクト テーブルで不明な日付を表すために NULL を使用する傾向があります。これは、ディメンション テーブルを参照する必要なく、ファクトの日付関連の検証を実行できるためです。

4

3 に答える 3

4

あなたが尋ねるために：

  1. キンボールは日付の代理キーについて前髪をつけていますが、私はまだそれをこのようにすることを支持する説得力のある技術的な議論を見ていません。YYYYMMDD形式に変換すると、日付を変換するか、日付ディメンションに対して結合して日付演算を実行する必要があります。これらは両方とも、によってクエリプランをねじ込むことができるさまざまな方法があります。
    日時はSQLServerでは8バイト、Oracleでは（IIRC）7バイトであるため、整数サロゲートよりも少し広いですが、データ量が非常に多い場合を除いて、この引数にメリットはありません。オプティマイザーは、日付を舞台裏の数値として扱うだけです。

  2. あるタイプまたは別のタイプの「特別な」値に対する要件がありました。並べ替え方法に応じて、さまざまな値を使用できます。過去に、私はこのスキームを何度も使用しました。

    • 'previous'の場合​​は1800-01-01。これより前の日付が必要でない限り、これは最初にソートされます。
    • '進行中'の場合は9000-01-01。これは最後にソートされます。
    • 'unknown'の場合は9100-01-01。これは最後にソートされます。
    • 'エラー'の場合は9200-01-01。これは最後にソートされます。

  3. それをサポートするDBMSプラットフォーム（ほとんどすべての主流のRDBMSプラットフォームを含む）での範囲分割は、日付または整数のパーティションキーで問題なく機能します。

データを使用するには外部結合が必要になるため、データウェアハウスの不明な値にNULLを使用することはお勧めしません。これはクエリプランの効率に影響を与え、経験の浅いプレーヤーのデータに罠を仕掛けます。データウェアハウスのNULLキーは、かなりの数の点で悪いモジョです。

NULLキー値に関する別の問題は、ほとんどのアドホックレポートツールが結合内のnullキーでうまく機能しないことです。通常、これらは内部結合を使用するため、キー列にNULLが含まれる行は壊れます。

他のほとんどのディメンションでは、サロゲートを使用します。これにより、ディメンションがソースデータから切り離され、既存のデータを中断することなく、新しいデータソースをシステムに取り込むことができます。

場合によっては、ディメンションキーとして自然キーを使用すると便利な場合があります。この例としては、ISO通貨コードやアカウント番号があります。前者の場合、3文字のコードは十分に小さいため、キーとして使用するオーバーヘッドは最小限であり、コーディングスキームは（通常）すべてのデータソースに共通です。後者の場合、コードは多くの場合数値であり、とにかく整数に収まるほど短く、通常は組織全体で普遍的です。

これを行うことの主な利点は、レポートスペシャリストが独自のクエリを使用してデータを操作できることです。これにより、データを直接操作する人にとってテーブルが少し読みやすくなります。

于 2012-08-31T13:30:22.453 に答える
4

Oracle は、Date データ型に時間が含まれているという点で珍しく、7 バイトかかります。他のプラットフォームは通常、生の日付に対して独立したデータ型を持っています。SQL Server の日付は 3 バイト、PostgreSQL の日付は 4 バイト、DB2 の日付は 4 バイトです (私はそう思います)。

YYYYMMDD 形式の整数を使用する場合、値が有効な日付であることを確認するために、どこかに追加のコードを記述する必要があります。20121332 は有効な整数ですが、有効な日付を表していません。日付データ型の場合、そのような検証コードを記述する必要はありません。

欠落している情報を 1 つの列に記録する場合、2 つの選択肢に大きな違いはありません。他の日付の意味を意味しない日付を使用するか、他の整数の意味を意味しない整数を使用します。たとえば、「1」は「まだ提供されていない」ことを意味する場合がありますが、理由を少数でエンコードすると、有効な日付整数である値と同じ列に有効な日付整数ではない値を格納する必要があることを意味します。

しかし、一部のデータが欠落しているという事実と、データが欠落している理由を分けた方が理にかなっていると思います。これは、より多くのデータを保存することを意味し、一部の人々はより多くのデータを保存することに消極的です.

これら 2 つの IBM Redbook は、データ ウェアハウスの設計に役立つことがわかりました。

アンカー モデリングは、最近開発されたものです。このように設計されたスキーマ内のテーブルのほとんどは6NFになります。

于 2012-08-31T12:14:45.493 に答える
0

1.サロゲート キーは常に YYYYMMDD の形式で使用することをお勧めします。これは常に連続するためです。

2.日付ディメンションの代理キーを削除し、代わりに実際の日付を使用します。

最初のオプションを使用します。実際の日付を使用すると、より多くのディスクが使用され、インデックス作成の効率が低下し、結合の効率が低下します。また、日付タイプを使用する場合、「不明な日付」、「日付はまだ利用できません」、「カレンダーの日付範囲より前の日付」、「カレンダーの日付範囲より後の日付」をどのように表しますか?

カレンダー ディメンションのこれらすべての異なる「不明」タイプのメンバーに対して「01-01-1900」を使用することはできません。理想的には、すべての代理キーは無意味である必要があります。そうしないと、レポート ユーザーがディメンションを無視したくなる可能性があります。ディメンションは、カレンダー ディメンション、その日が属する週、月、年、曜日名などのディメンションに豊富さを追加します。レポーターは、代理キーを匿名化することによってディメンションを使用するように強制する必要があります。

ファクトとディメンション間の左外部結合を強制的に実行するため、データ ウェアハウスのプレゼンテーション レイヤーに null を含めないでください。スター スキーマの要点は、クエリのパフォーマンスを向上させることです。外部結合を行うことは、この原則に直接反します。null は常に -1、-2 などの未知のメンバー キーに置き換えてください (「実際の」メンバー キーが 1 から始まり、そこから順番に上がると仮定します)。

キャットコールの編集

カレンダーの最も早い日付がキー 1 を取得し、次の日付がキー 2 を取得するなど、代理キーを使用することをお勧めします。スター スキーマでは、ファクトは代理キー (すべて小さい整数またはメジャー) で構成されます。日付 1 が何を表しているかを確認するには、ディメンションに参加する必要があります。サロゲートはどれも何の意味もありません。それがデータマートを構築する方法です。ユーザーは、「01-01-1900」が「日付が利用できない」を意味し、「01-01-1901」が「不明」を意味し、「01-01-1902」が早い日付などを意味することをどのように確認する必要がありますか? これらのキャプションを次元に格納し、事実にサロゲート -3、-2、-1 を持たせたほうがよいのではないでしょうか。その後、レポートに「不明」または「早期日付」というキャプションが表示されます。代理キーとして日付型を使用するのは単純な間違いであり、有用性が制限されます。ソリューションの効率と柔軟性。私はこれを経験を通して知っています。

于 2012-08-31T09:37:21.000 に答える