2

レポート アプリケーションで、レポート ロジックとデータベース スキーマの詳細を抽象化することは可能ですか?

かなり複雑なレポート ロジックを持つ Reporting Services アプリケーションがあり、そのアプリケーションを他のデータベースに移行しようとしています。(同じ目的のために構築されているが、異なるソフトウェア会社によって開発されているデータベース。)

中間で Web サービス / WCF レイヤーを使用するのは賢明な決定ですか? 他にどのようなオプションが考えられますか?

4

3 に答える 3

3

NXCのデータウェアハウスの提案に同意します。

  • それが1回限りの仕事だった場合は、いいえ。ただし、これは「レポートアプリケーション」であるため、レポートの多くがOLAPパラダイムに適合する可能性が高くなります。
  • 市場には多くの成功したOLAPクエリツールがあり、複雑さの程度はさまざまであるため、これは明らかに実行可能なタスクです。
  • 標準のスタースキーマなどのOLAPスキーマは、クエリを簡単に実行できるように設計されています。それらは本質的にフラットであり、ファクトテーブルは非常に簡単な方法で単純なキーを使用して1つ以上のディメンションテーブルに結合されます。
  • レポートで実行する操作の種類は予測可能です。フィルター、並べ替え、グループ化、列の追加または削除、CSVへのエクスポートなどです。
  • 生成されるレポートで十分なレベルの柔軟性が得られます-さまざまな関係のデータを探索する機能は非常に中毒性があります
  • クエリツールを作成すると、他のスタースキーマで再利用できるように移植できます。悪くはありません。
  • 「レポートロジックとデータベーススキーマの詳細を抽象化することは可能ですか？」-はい、OLAPスキーマはまさにこのためのものです-すべてのデータを標準化されたスキーマに準拠させます。もちろん、これによりビジネスロジックがETLレイヤーに移動しますが、それが属する場所であると私は主張します。

したがって、このアプローチでETLを実行する必要があります。1つのオプションは何らかの形式のROLAPを実行することですが、実際には、ROLAPセットアップから優れたパフォーマンスを引き出すのと同じくらい簡単にETLスクリプトを記述できることがわかりました。

于 2008-12-21T16:00:24.500 に答える
3

一般的なケースでは、この種のことを万能の方法で行うのは難しいでしょうが、次のいずれかを試すことができます。

  • データベース スキーマに対していくつかのビューを作成し、それらに対してレポート sproc を記述します。これは、基礎となるデータベース スキーマにある程度の柔軟性があり、ビューを抽象化レイヤーとして使用できることを意味します。

  • ある種のデータ ウェアハウス プラットフォームを構築し、ETL プロセスを記述して、さまざまなデータ ソースからデータを取り込みます。これはより柔軟ですが、構築するのにより多くの労力がかかり、定期的な更新からのみ機能します。その程度のレイテンシがアプリケーションで許容できる場合は、データ ウェアハウス システムの方が優れたアプローチであることをお勧めします。

    データ ウェアハウスの主な利点は、レポート用に最適化されており、すべてのデータ ソースにわたって一貫したインターフェイスを備えていることです。それらを 1 つのスキーマを持つ単一のデータベースに統合します。レポートは、そのスキーマに対して作成されます。新しいシステムの追加は、ETL プロセスを記述してウェアハウスに入力することによって実現されます。データ ソースに関係なく、レポートは引き続き機能します。

WCF はネットワーク通信システムです。この種のアーキテクチャでトランザクションごとに大量のデータを処理するのは難しいことに気付くでしょう。ETL プロセスをバッチでロードする方がはるかに効率的です。ただし、リアルタイム フィードが必要な場合 (おそらくトレーディング フロア システム用)、このようなもので実現できる可能性があります。

低遅延フィードが必要な場合は、エンタープライズ情報統合と呼ばれるツールのジャンルを調査する別のアプローチがあります。おそらく、これを行うことができる最も広く利用可能なツールは、SSIS のデータソースビューです。これにより、任意のデータ ソースを一貫したスキーマにマッピングする柔軟性が得られます。最高の組み合わせの EII ツールほど洗練されていませんが、SSIS パッケージをその上に置き、データをさらに変換する必要がある場合は、それらをレポートのデータ ソースとして使用できます。

ただし、このような構造のシステムを構築したことがないため、実際にどれだけうまく機能するかは保証できません。単体テスト可能なパーツに分解するのは非常に壊れやすく、難しいと思います。そのため、自明ではない複雑なシステムの開発と保守にはかなりの時間がかかります。

市場に出回っている他の EII システムを調べたい場合このリンクは、EII およびその他の EII ツール ベンダーに関するさまざまな記事のディレクトリです。

于 2008-12-21T00:28:26.830 に答える
0

一般的には後回しにされてしまうと思いますが、私が知っている他の回答者は、各データベースからデータを XML として生成するというものです。これにより、ほとんどの製品で簡単に処理できる形式で、一貫したデータ セットが得られます。

これを行う場合は、実行する XPath クエリが高速であることを確認してください。

于 2011-02-23T00:40:12.830 に答える