0

IT マネージャーから、同じデータが古いものに応じて異なる粒度で保存される SSAS 環境を構築するように依頼されました。

たとえば、エンジニアが完了したプロジェクトの数と種類によって決定されるポイント システムがあります。このデータは、前月に獲得したポイントについては 1 週間、前四半期に獲得したポイントについては 1 か月、過去 3 年間に獲得したポイントについては 1 四半期の粒度で保存および処理する必要があります。これにより、キューブの処理に伴う作業負荷が軽減されるという考えです。

これは単一のキューブ内でも可能ですか? 私の調査によると、そうではないようです。当社の IT 部門の責任者は、前の会社ではそのような方針に沿って何かを行うことができたと言いますが、彼は過度に技術的ではないため、舞台裏で何が起こっていたのかを誤解している可能性があります. これは私たちの会社が生産用に構築した最初のキューブであり、これまでに誰もやったことがありませんが、若いキャリアの開発のためのテーマに興味があり、リードしています. 私の考えでは、単一のキューブ内でそれが不可能な場合、複数のキューブを維持すると、実際には開発者の作業が増え、サーバーの作業も増えます。ユーザーにとっての追加の複雑さは言うまでもありません。

では、単一のキューブ内で可能ですか? そうでない場合、複数のキューブで実装する利点はありますか、それとも忘れるべきですか (私が返したい答えではありませんが、それが何であるかです)。現在 2008R2 を実行していますが、間もなく 2014 にアップグレードします。この点で多次元モデルと表形式モデルに違いはありますか?

4

2 に答える 2

0

次の行に沿って何かを行うことができます。

年 - 四半期 - 月 - 週の時間階層を想定すると (そして、週を月に集約する正確なルールを定義するという、わずかに無関係な問題を無視して)、次のように時間階層を設定できます。

    week       month   quarter  year
(2012)      (2012)     (2012)   2012
(Q1/2013)   (Q1/2013)  Q1/2013  2013
(Q2/2013)   (Q2/2013)  Q2/2013  2013
(Q3/2013)   (Q3/2013)  Q3/2013  2013
(Q4/2013)   (Q4/2013)  Q4/2013  2013
(Jan 2014)  Jan 2014   Q1/2014  2014
(Feb 2014)  Feb 2014   Q1/2014  2014
(Mar 2014)  Mar 2014   Q1/2014  2014
(Apr 2014)  Apr 2014   Q2/2014  2014
w18/2014    May 2014   Q2/2014  2014
w19/2014    May 2014   Q2/2014  2014
w20/2014    May 2014   Q2/2014  2014

つまり、列の名前が示すほど詳細ではない人工的な週、月、および四半期メンバーを作成するだけです (これを示すために、それらが一致する期間の名前を括弧内に使用しました。

ただし、これが実際に問題になるほどキューブが大きいとは思いません (何億人もの開発者がいるとは想像できません)。したがって、「週」などの一般的な粒度を 1 つだけ維持することをお勧めします。これにより、ユーザビリティが大幅に向上します。処理時間に問題がある場合、それは開発者に関するデータを含むキューブのサイズが原因ではないと思います。

于 2014-05-07T16:33:49.830 に答える