2017-05-07 3 views
0

データウェアハウスに2つのテーブル、balancesdatesがあります。 Balancesは、以下の構造を有する:where句でINTとDATEを使用

Surrogate Key Date | Date  | Account | Balance 
1     | 2017-02-01 | 100  | 1234 
1     | 2017-02-01 | 200  | 5151 
2     | 2017-02-02 | 100  | 5123 
2     | 2017-02-02 | 200  | 8234 

そしてdatesは、以下の構造を有する:

Surrogate Key Date | Date  | Weekday | Week in Year | ... other columns 
1     | 2017-02-01 | Wed  | 5   | 
2     | 2017-02-02 | Thu  | 5   | 

Surrogate Key DateカラムがINT型であり、Dateカラムが両方のテーブルにDATE型です。

balancesテーブルの代理キーは、OLAPクエリで使用され、日付は通常のレポートに使用されます。

ここでは、データベースを集中的に使用するプログラム(バッチプロセス)を開発する必要があり、日付列を通じてバランステーブルを繰り返しアクセスする必要があります。このプロセスで、代理キー日付列または日付列を使用する必要がありますか?私は日付でフィルタリングする必要があります。 where句のINTアクセスはDATEアクセスより効率的ですか? OLAPを使用しないときにSurrogate Key Date列を無視する必要がありますか?

答えて

1

パフォーマンス面では、SAP HANAではまったく問題はありません。一般に、HANAは、ジョインおよび結果セットを計算するときに内部参照IDを使用して実際のデータ型では機能しません。

実際には、1:1をDateの列にマッピングすると、最初はサロゲートキーを持っているという理由はありません。また、重複を許可するように見えるので、キーではありません。わからない、このモデルの同じ日付の特定のレコードに対処する方法。

+0

'balances'テーブルのキーは'代理キー日付+アカウント番号 'です。重複は許可されません。 OLAPを実行するには代理キー日付が必要で、レポートを実行するには 'Date'列が必要です(サロゲートキー日付はレポートを作成するエンドユーザーには意味がありません) – ps0604

+0

私はよく見ていますが、その場合でも、最初にサロゲートキーを使用する利点はありません。 'DATE'と' Account number'に基づいて複合主キーを作成し、それを使用します。 HANAは内部的にこの連結のために隠しコラムを作成し、複合キーのすべての処理はその単一の列で行われます。主な欠点は明らかに追加のスペース要件ですが、代理キーも使用することになります。 –