レポート モデルの設計に関するヒント:
1. データマートを構築する
Report Builder のようないくつかのツールがあります。Business Objects、Oracle Discoverer などがあります。それらにはすべて、エンドユーザー レポート ツールへの道のりの一部を提供するメタデータ レイヤーがありますが、効果的なソリューションを作成するには、適切な形式でデータをスプーン フィードする必要があります。これは、ある種のデータマートを構築するという観点からも本当に考える必要があることを意味します。
クリーンなデータがないと、ツールは本番データベースのすべての問題を明らかにするため、ユーザーは正しい結果を得るためにこれらを理解する必要があります。これは、レポートが実際にはクリーンなデータ ソースから生成される必要があることを意味します。
これらのツールが生成する SQL はほとんど制御できないため、実稼働データベースを破壊するクエリを生成する可能性は十分にあります。これは、レポートを別のサーバーで行う必要があることを意味します。アドホック ツールに適したスキーマ (スター スキーマなど) は、パフォーマンスに関する潜在的な問題の最悪の事態を軽減します。
2.データをきれいにする
アドホック ツールのループには開発者がいないため、ユーザーはデータの問題が何であるかを知らずに単純にツールを使用します。 不正確なクエリ結果は、常にツールの障害と見なされます。信頼性を確保するために、ツールの上流にあるデータ セットからこれらの落とし穴を排除する必要があります。
3. ナビゲーションを堅牢で馬鹿げたものにしない
レポート ビルダーは、あるエンティティから別のエンティティへの移動に対する制限を設定できます。これらがなければ、複数のテーブルを am:m の関係で結合することができます。これはファン トラップと呼ばれ、誤った合計を返します。個々のファクト テーブルが共通のディメンションで集計されるようにモデルを設定する必要があります。つまり、それらが結合される前にロールアップされます。これを正しく行うと、エラーのクラスがなくなります。ほとんどのツールには、これを防ぐための何らかのメカニズムがあります。
4.データを集計する
これは Business Objects から無料で入手できますが、Report Builder を使用して、各ベース メジャーに集計メジャーを明示的に配置する必要があります。ベース メジャーを非表示にして、集計を公開します。これは、システムがユーザーが選択したディメンションの粒度にデータをロールアップすることを意味します。
結論
運用データベースにアドホック ツールを直接配置しても、うまく機能しない可能性があります。データには多くの落とし穴があり、スキーマはレポートに適していません。これは、データ マートを構築してデータをスクラブし、ツール用に準備するという作業が必要であることを意味します。アドホック抽出の構築にかなりの時間を費やしている場合は、単に開発者の時間を節約できるビジネス ケースが存在する可能性があります。
編集:レポート モデル ウィザード (ほとんどのようなものと同様) を実行すると、かなり混乱します。無関係な集計の生成を制限するなど、設定を微調整する必要があります。過去に、合計を生成し、すべてのベース メジャーを非表示にして、ベース メジャーであるかのように集計を公開することで、非常に良い結果を得ました。これにより、Business Objects によく似た動作が得られました。特定のインスタンスでは、カウント、最小/最大、または平均も公開したい場合があります。
私が考えている特定のインスタンスは、約 1,500 フィールドを含む非常に大きなレポート モデルでした。そのため、ウィザードから生成された集計フェストは、合計 10,000 以上のフィールドで管理できませんでした。また、Analysis Services に少し似たフォルダー構造を設定し、これらを使用してフィールドを整理することもできます。最後に、フィールドに説明を入力すると、エンド ユーザー ツールでカーソルを合わせると、その説明がツールチップとして表示されます。