1

これを間違った場所に投稿した場合はお詫び申し上げます。変数が多すぎるため、これは答えるのが非常に難しい質問ですが、アドバイスや指針をいただければ幸いです。

信じられないほど大きく、扱いにくく、デザインの悪い立方体があります。以下に示すように、それは恐ろしい「1 つのキューブですべてを支配する」タイプです。私の勤務先などを裏切るような名前のディメンションは難読化されていることに注意してください。

私が感じようとしているのは、一般的な経験則として、キューブが保持できるデータの量です。私 (および私がその 1 人であると主張していない複数の専門家) は経営陣に、現在のレベルでキューブにデータ (および属性) を追加し続けると失敗するだろうと述べています。私たちが望んでいるのは、これが今年なのか、来年なのか、今月なのかなどを判断する方法です...そして、はい、これが正確な公式の答えを持っていないことはわかっています. オンラインで見つけることができないため、ガイドラインは非常に役立ちます。ビルドのベストプラクティスのみであり、これがそれに準拠していないことは既にわかっています! 私はそれを再設計するために予算の承認を得ようとしているので、質問...

23 のディメンション、KPI なし、4 つの計算メジャー、および 46 のその他のメジャー

[Dim 1] - 11 attributes
    no hierarchies
    4 address lines, email address, full name, postcode, text provider type
[Area Detail] - 21 attributes
    no hierarchies
    2 address lines, postcode, various name and code fields (string)
[Area Main 1 Month Prior] - 5 attributes
    2 hierarchies
[Area Main 4 Months Prior] - 5 attributes
    2 hierarchies
[Area Main Dimension] - 5 attributes
    2 hierarchies
[Type Dim 1] - 1 attributes
    no hierarchies
[Date Dimension] - 36 attributes
    4 hierarchies
[Event Dimension] - 29 attributes
    no hierarchies
    includes 5 dates which are not linked to date dimension but actually entered
[Event Rank Dimension] - 18 attributes
    no hierarchies
[Event Track Dimension] - 21 attributes
    no hierarchies
    14 date fields
    7 comment fields (freetext)
[History Date Dimension] - 4 attributes
    no hierarchies
    all date data
[Dim 2] - 5 attributes
    no hierarchies
    all freetext fields apart from code
[Official Date Dimension] - 9 attributes
    no hierarchies
    Date field and data about the date
[Previous Dim 2 Dimension] - 4 attributes
    no hierarchies
[xxx Current Record Dimension] - 1 attribute
    no hierarchies
[xxx Dimension] - 102 attributes
    no hierarchies
    4 address fields, postcode, 2 email fields, website
[xxx Dimension 1 Month Prior] - as above
[xxx Dimension 4 Months Prior] - as above
[Dim 3] - 12 attributes
    no hierarchies
[Question Dimension] - 11 attributes
    1 hierarchy
    4 large text fields
[yyy Combination Dimension] - 1 attribute
    no hierarchies
[yyy Current Record Dimension] - 1 attribute
    no hierarchies
[yyy Status Dimension] - 3 attributes
    no hierarchies
[Response Dimension] - 4 attributes
    no hierarchies
    2 large text fields
[zzz Area Dimension] - 4 attributes
    no hierarchies
    2 text fields
[zzz Type Dimension] - 1 attribute
    no hierarchies

これが理にかなっていることを願っていますが、喜んで詳細を提供/明確化します。

4

1 に答える 1

3

私の経験から、あなたが投稿したメトリックは主に使いやすさに関連しています。ディメンションとメジャーを追加しても、キューブが「失敗」することはありません。私は、より多くのディメンションとメジャー (2 倍以上など) を持つ安定したキューブを成功させました。

「すべてを支配する 1 つのキューブ」は、SQL 2005 で導入されたアーキテクチャ上の進歩です。これにより、ビルド時間、ストレージ、およびクエリ パフォーマンスが最適化されます。SQL Enterprise Edition を使用すると、そのスライスを「視点」として提示できますが、私はファンではありません。ほとんどのクライアント ツールはこれらのオブジェクトをアルファベット順にソートするため、慎重に計画されたディメンションとメジャーの命名に従うことを好みます。

キューブが苦労し、最終的に "失敗" する可能性があるのは、より大きなディメンションとメジャー グループのデータ量です。1m 列未満の寸法は、通常、ドラマではありません。1 億行未満のメジャー グループも、通常、いくつかの基本的な集計で問題ありません。それより大きいと、設計により多くの作業を加える必要がある場合があります。Excel 2010+ などの単純なエンドユーザー ツールを使用して、クエリの 95% で 5 秒未満の応答時間を目指しています。

于 2013-03-01T02:39:12.700 に答える