6

これはすでに尋ねられています(データウェアハウス/ BIについてはほとんどわかっていないが、キーワードを習得していない)。データ集計 - 毎日のSQLスクリプトとデータウェアハウス

1日あたり100,000行以上成長するテーブルがあり、各行にタイムスタンプと項目に関する複数の情報(次元、重み、色など)があります。個々のデータは、集計にのみ関心があるこの期間の約1ヶ月間は役に立ちます。私は個々の行をより詳細に視覚化し、主にレポートのニーズにPowerPivotを使用する専用ソフトウェアを用意しています。

毎日新しいテーブルを埋めるSQLクエリが出てくるかもしれません: 各時間/アイテム/バッチごとに行があり、情報(合計/平均/標準偏差/など)を要約します。 )

私のスクリプトが実行されていて、この新しいテーブルに対してpowerpivotを使うことができました。これは私が快適な場所に留まっている間:普通の古いSQLです。

私がDataWarehouseとBIについて読むことを集めた少数の情報から、私がしようとしていることは、次元と事実の作成のようなものです。したがって、私の質問は、その方向性(BI)をさらに調査する価値があるのですか、あるいは私の問題は比較的単純なので、私はリレーショナルデータベースの方が良いでしょう。

N.B.作成されているレポートは通常、別のデータベースとリンクしてより意味のある情報を生成します。 Powerpivotで非常に優れた作業です。

答えて

3

データウェアハウスは通常、リレーショナルデータベースに実装されているため、既存のスキルは引き続き使用できます。

  • 日付倉庫ツールキット(キンボール、ロス)
  • はあなたがdatawarehousingへの寸法/ファクトテーブルのアプローチに関心を表明していることを考えると、このアプローチの標準的な本は通常であると考えられています

  • 日倉庫ライフサイクルツールキット(キンブル、ロス、Thornthwaite、マンディ、ベッカー)

(後者は、より広いライフサイクル管理の視点から被写体に接近しながら、前者は、技術的な焦点の多くを有する。)

DWHの実装には時間がかかることがあるので、DWHを構築することを決定しても、既存のアプローチを続行する価値があります。

+0

すべての回答を受け入れることができれば、彼らはすべて私が決定を下すのを助けたさまざまな側面を持ち出したからです(今は単純にしておきましょう)。しかし、この1つでは、もう少し読書に向けて私に指摘したので、私は先に進んでこれを受け入れます。ありがとう – Benoittr

1

最も効果的なソリューションは、既存のニーズを満たし、利用可能なスキルセット内にとどまるために単純で適切なソリューションです。

私は、この方法が、あなたが必要とするレポートと情報をこのように開始する価値があるという状況に適していることに同意します。より複雑な機能が必要な場合は、後で複雑なBIに進むことができます。

2

良いニュース:既にデータウェアハウスがあるようです。 「データウェアハウス」は非常に一般的な用語であり、実際の正式な定義はありません。

一般的に受け入れられている特性は、次のとおりです。

  • データ・ウェアハウスは、
  • データウェアハウス・スキーマを照会するために最適化されている、「正規形」準拠のため
  • データウェアハウスは、によって移入されていない運用データベース上で実行されません。 「抽出、変換、ロード」処理(ETL)。

既にすべてのことをしているようです。変更する必要のあるビジネス要件がない場合は、そのまま残しておきます。ビジネスユーザーがさまざまなレベルの集約、フィルタリング、または細分化を使用して独自のクエリを作成するよう要求している場合は、スタースキーマが使用できます。

関連する問題