报告应用程序中的数据库抽象

Question

在报告应用程序中，是否可以抽象报告逻辑和数据库架构详细信息？

我有一个具有相当复杂的报告逻辑的 Reporting Services 应用程序，我正在尝试将该应用程序迁移到其他一些数据库。（出于相同目的而构建但由不同软件公司开发的数据库。）

在中间使用 Web 服务/WCF 层是明智的决定吗？还可以考虑哪些选择？

Answer 1

在一般情况下，很难以一种一刀切的方式来做这种事情，但你可以尝试以下方法之一：

• 在数据库架构上构建一些视图，并针对这些架构编写报告Sprocs。这意味着您在底层数据库模式中有一定的灵活性，并且可以使用视图作为抽象层。

• 构建某种数据仓库平台，并编写一个ETL流程以从各种数据源中填充它。这更灵活，但需要更多的努力来构建，并且只能通过定期刷新来工作。如果您的应用程序可以接受这种程度的延迟，那么我建议数据仓库系统是更好的方法。

  数据仓库的主要优势在于，它针对报告进行了优化，并且在所有数据源之间具有一致的界面 - 您可以将它们合并到具有一种模式的单个数据库中。这些报告是根据该模式开发的。添加新系统是通过编写ETL流程来填充仓库来实现的；无论数据源如何，报告都将继续有效。

WCF是一个网络通信系统。您会发现很难让这种架构在逐个事务的基础上处理大量数据 - 批量加载 ETL 过程会更加高效。但是，如果您需要实时源（可能是交易大厅系统），您也许可以使用类似的方法来实现。

如果您需要低延迟源，另一种方法是研究一种称为 企业信息集成. 。也许可以做到这一点的最广泛使用的工具是 数据源视图 在 SSIS 这确实为您提供了将任意数据源映射到一致模式的灵活性。它不像最好的 EII 工具那么复杂，但如果您需要进一步转换数据，您可以将 SSIS 包放在其上并使用它们作为报告的数据源。

但是，我从未构建过这样的系统，因此我无法真正保证它在实践中的效果如何。我猜想它会非常脆弱并且很难分解成可以进行单元测试的部分，因此对于一个非常复杂的系统来说，开发和维护将非常耗时。

如果您想研究市场上的其他 EII 系统 这个链接 是有关 EII 和其他一些 EII 工具供应商的各种文章的目录。

Answer 2

我同意NXC的数据仓库建议：

• 如果它是一次性工作，则不会，但由于它是一个“报告应用程序”，因此您的许多报告很可能适合 OLAP 范例。
• 这显然是一项可行的任务，因为市场上有许多成功的 OLAP 查询工具，其复杂程度各不相同
• OLAP 模式，例如标准 星型模式, ， 是 设计的 以便于查询。它们本质上是扁平的，事实表以一种非常简单的方式使用简单的键连接到一个或多个维度表。
• 人们想要对报告执行的操作类型是可以预测的：过滤、排序、分组、添加或删除列、导出到 CSV 等。
• 您将通过生成的报告获得良好的灵活性 - 探索各种关系的数据的能力非常令人上瘾
• 一旦您编写了查询工具，它就可以移植并与任何其他星型模式一起重用 - 不错！
• “是否可以抽象报告逻辑和数据库架构详细信息？” - 是的，OLAP模式正是这样 - 它们使所有数据符合标准化的模式。当然，这会将业务逻辑移至 ETL 层，但我认为这才是它所属的地方。

因此，您需要使用这种方法进行 ETL - 一种选择是执行某种形式的 罗拉普, ，但在实践中我发现编写 ETL 脚本就像从 ROLAP 设置中获得良好的性能一样容易。

Answer 3

这是我认为一般会回来咬你在后方，但其他人我知道就好，是生产数据从每个数据库中的XML答案。这给你一个一致的数据集的形式，大部分产品都能应付自如。

如果你这样做，请确保XPath查询，您将在其上运行会快。