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

【问题标题】：Database Abstraction in a Reporting Application报告应用程序中的数据库抽象
【发布时间】：2008-12-20 23:46:46
【问题描述】：

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

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

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

【问题讨论】：

标签： wcf architecture reporting-services reporting abstraction

【解决方案1】：

在一般情况下，很难以一种千篇一律的方式做这种事情，但您可以尝试以下方法之一：

在数据库架构上构建一些视图并写报告的sprocs反对那些。这意味着您在底层数据库架构中具有一定的灵活性，并且可以将视图用作抽象层。
构建某种数据仓库平台并编写ETL流程从各种数据源填充它。这更灵活，但构建起来更费力，它只能在定期刷新时工作。如果您的应用程序可以接受这种程度的延迟，那么我建议数据仓库系统是更好的方法。

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

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

如果您需要低延迟提要，另一种方法是研究一种称为 Enterprise Information Integration 的工具类型。也许可以做到这一点的最广泛可用的工具是SSIS 中的Data Source View，它确实为您提供了将任意数据源映射到一致模式的一些灵活性。它不像最好的 EII 工具那样复杂，但如果您需要进一步转换数据，您可以将 SSIS 包放在上面，并将它们用作报告的数据源。

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

如果您想调查市场上的其他 EII 系统，This link 是关于 EII 和其他一些 EII 工具供应商的各种文章的目录。

【讨论】：

【解决方案2】：

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

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

因此，您需要使用这种方法执行 ETL - 一种选择是执行某种形式的 ROLAP，但在实践中，我发现编写 ETL 脚本和哄骗良好的性能一样容易的 ROLAP 设置。

【讨论】：

另外，星型模式可以很好地容忍源数据的确切基数。它们非常扁平，因此很容易将任意关系和层次结构映射到一组明智选择的维度。

【解决方案3】：

我认为通常会在后面咬你的答案，但我认识的其他人喜欢的答案是从每个数据库生成数据作为 XML。这以大多数产品可以轻松处理的形式为您提供了一组一致的数据。

如果您这样做，请确保您将在其上运行的 XPath 查询速度很快。

【讨论】：