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

Question

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

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

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

Answer 1

在一般情况下，以一刀切的方式做这类事很难，但你可以试试其中之一：

• 构建数据库模式的一些视图 写报告sprocs反对 那些。这意味着您在底层数据库模式中具有一定的灵活性，并可以将视图用作抽象层。

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

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

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

如果你有一个低延迟的饲料，另一种方法是调查一种名为Enterprise Information Integration的工具类型。也许可以做到这一点的最广泛使用的工具是Data Source View中的SSIS，它确实为您提供了将任意数据源映射到一致模式的灵活性。它不像最好的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查询速度很快。