2

私は最終的にBIプロジェクトのデータウェアハウスとして使用されるいくつかのテーブルに取り組んでいます。これらのテーブルには、KPIを計算するために使用されるカウンタデータが格納されます。SQLデータを垂直に格納するとどんな利点がありますか?

ので、例えば、テーブルは現在、次のようになります。

DimCounter 
Counter  ParmId 
KpiStore  1  (used for Sales reports) 
KpiInventory 2  (used for Sales reports) 
Kpi3   3 
Kpi4   4 

とデータテーブルは次のようになります。

FactSales 
ParmId Value ProcDate ProcHour 
1  20  20160914 12 
2  40  20160914 12 
1  70  20160914 12 

だから、今我々はいくつかの売上レポートを持っていますこの形式ですごくうまくいった。データを垂直形式で作成することは問題にはなりません。しかし、私は多分それはちょうどそうのように、水平にデータを保存するために、より良いだと考えている:それは二つのカウンタを使用し、それはほとんどが加算/減算だから

FactSales 
ProcDate ProcHour KpiStore KpiInventory 
20160914 12   20   40 

売上レポートは、本当に簡単に、最も簡単なレポートです。しかし、はるかに複雑であり、いくつかの方法でグループ化する必要があるより多くのカウンターを使用するものがあります。

このようにデータを保存することに利点はありますか?具体的には、BIに使用されるデータウェアハウス用にデータを垂直に格納する利点はありますか?

元のソースデータは水平方向(1つのメトリックが1列あたり)で保存されていますが、ソースデータはデータウェアハウスには使用されていません。したがって、データウェアハウスの場合は、基本的に問題になります。

ありがとうございました。

+2

元の垂直構造はきれいで伸縮性があります。新しいメトリックを取得したときに何が起こるか自分に尋ねてください。 –

+0

データを水平に保存する際に見られる欠点の1つは、新しい「カウンタ」がある場合です。レポートを表示するためにテーブルを変更する必要があるかもしれません。 –

+0

最初の欠点オプションは値が固定型であるため、変更できません。 –

答えて

0

正規化の最大のメリットは、テーブル構造の変更と比べてテーブル挿入を行うだけで新しい値を追加できることにあります。さらに、さまざまなカウンタータイプに対して多くのヌル値を設定する可能性があります。たとえば:

FactSales 
ProcDate ProcHour KpiStore KpiInventory 
20160914 12   20   40 
20160915 11   30   NULL 

これはあなたの現在のデータ環境の場合ではないかもしれないが、あなたが代わりにそれらのフィールドをロックした場合、あなたは多くの柔軟性を失います。私は通常、新しいフィールドを追加してフィールドの変更(時にはヌルが未来にnullを持つことができなかったフィールド)を収容する将来的な柔軟性の可能性を一般に望んでいるため、通常より多くの正規化を行います。

関連する問題