報告應用程序中的數據庫抽象

Question

在報告應用程序中，是否可以抽象報告邏輯和數據庫模式詳細信息？

我有一個Reporting Services應用程序，它有相當複雜的報告邏輯，我試圖將應用程序遷移到其他數據庫。 （爲相同目的而構建，但由不同軟件公司開發的數據庫）

在中間使用Web服務/ WCF層是明智的決定嗎？還有什麼其他選擇可以考慮？

Answer 1

這將是很難做到這樣的事情在一個尺寸適合所有的方式在一般情況下，但你可以嘗試以下操作之一：

• 構建在數據庫模式的一些看法和 寫報告sprocs對 那些。這意味着您在底層數據庫模式中具有一定的靈活性，並可以將視圖用作抽象層。

• 構建某種數據倉庫 平臺並寫入ETL過程到 從各種數據源填充它。這更加靈活，但更加努力構建，並且只能通過定期刷新工作。如果這種程度的延遲對於您的應用程序是可接受的，那麼我會建議數據倉庫系統是更好的方法。

  數據倉庫的關鍵優勢在於它針對報表進行了優化，並且在所有數據源中具有一致的接口 - 您可以使用一種模式將它們合併到一個數據庫中。報告是針對該模式制定的。通過編寫ETL流程來填充倉庫來實現添加新系統;無論數據來源如何，報告都可以繼續工作。

WCF是一種網絡通信系統。您會發現很難讓這種體系結構在事務處理的基礎上處理大量數據 - 批處理ETL過程會更有效率。但是，如果您需要實時Feed（可能用於交易大廳系統），則可以使用類似的方法來完成此操作。

如果您需要低延遲饋送，另一種方法是調查名爲Enterprise Information Integration的工具類型。也許可以做到這一點的最廣泛的工具是SSIS中的Data Source View，這爲您提供了將任意數據源映射到一致模式的一些靈活性。它不像最好的EII工具那麼複雜，但是如果您需要進一步轉換數據，您可以將SSIS包放在它的頂部，並將它們用作報告的數據源。

但是，我從來沒有構建過這樣的系統，所以我不能真正證明它在實踐中工作的效果。我猜測它會非常脆弱，很難分解成可以進行單元測試的部分，因此開發和維護對於非平凡複雜的系統來說是相當耗時的。

如果您想調查市場上的其他EII系統This link是關於EII和其他一些EII工具供應商的各種文章的目錄。

Answer 2

我同意NXC的數據倉庫的建議：

• 如果這是一個一次性的工作，沒有，但因爲它是一個「報告應用程序」，極有可能是你的很多報告將適合納入OLAP範例。
• 這顯然是做能的任務，因爲目前市場上提供了許多成功的OLAP查詢工具，具有複雜性的不同輩分
• OLAP模式，例如，標準star schema，是設計爲易於查詢。它們本質上是平坦的，事實表以簡單的方式使用簡單的鍵連接到一個或多個維度表。
• 人們想要對報告進行操作的類型是可預測的：過濾，排序，分組，添加或刪除列，導出爲CSV等。
• 您將獲得良好的靈活性與報告生成的能力 - 探索各種關係數據的能力是非常容易上癮的
• 一旦你寫了查詢工具，它是可移植的與任何其他星型模式重用 - 不錯！
• 「是否可以抽象報告邏輯和數據庫模式細節？」 - 是的，OLAP模式正是爲了這一點 - 它們使所有數據符合標準化模式。當然這會將業務邏輯移入ETL層，但我認爲這就是它所屬的地方。

所以，你做ETL這種方法需要 - 一個選擇是做某種形式的ROLAP，但在實踐中，我發現它是那麼容易編寫ETL腳本，因爲它是哄着性能好脫離ROLAP設置。

Answer 3

，我認爲一般會回來咬你在後方，但其他人我知道就好，是生產數據從每個數據庫中的XML答案。這爲您提供了大多數產品可以輕鬆處理的形式的一組一致數據。

如果你這樣做，確保XPath查詢你將運行它會很快。