レポート アプリケーションでのデータベースの抽象化

Question

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

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

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

Answer 1

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

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

• 何らかのデータウェアハウスを構築する プラットフォームで、次のようなETLプロセスを作成する。 様々なデータソースからそれを入力する。これはより柔軟ですが、構築に手間がかかり、定期的に更新しないと機能しません。その程度の遅延がアプリケーションで許容できる場合は、データ ウェアハウス システムの方がより良いアプローチであることをお勧めします。

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

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

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

ただし、私はこのような構造のシステムを構築したことがないため、実際にどの程度うまく機能するかは保証できません。これは非常に壊れやすく、単体テストできる部分に分解するのが難しいため、複雑なシステムの開発とメンテナンスにはかなりの時間がかかると思います。

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

Answer 2

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

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

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

Answer 3

私は、一般的に後ろであなたを噛まないように戻ってくると思うが、他のことを、私はのように、各データベースからのデータをXMLとして作成することである知っている答え。それはあなたのほとんどの製品を簡単に扱うことができるという形でデータの一貫性のあるセットを与えます。

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