构建数据仓库时的临时仪表板/报告解决方案

Posted 2023-03-29

【中文标题】构建数据仓库时的临时仪表板/报告解决方案

【英文标题】：Temporary Dashboard/Reporting Solution while Building a Data Warehouse

【发布时间】：2014-10-23 16:33:55

【问题描述】：

我们的情况是我们要开始建一个数据仓库了。如果我们要做好的话，数据仓库将需要一些时间。它将着眼于各个流程并从那里发展起来。

我们只有三个要从中提取数据的数据库。所有三个数据库都包含不同的信息（财务信息、日程安排和患者信息 - 就诊、诊断等）。

我正在考虑使用仪表板/报告工具（例如）http://www.jedox.com/en/ 或http://www.board.com/us/ 向企业显示信息。当 DW 正在设计并投入生产时，它将慢慢开始与 DW 结合使用。

我的问题毕竟是：在后端向应用程序（仪表板/报告器）呈现数据的最佳方式是什么，既高效又不耗时而是建立数据仓库？ IE。视图、物化视图、包含来自主数据库的子集数据的小型独立数据库等？

【问题讨论】：

您使用的是什么数据库平台？ Oracle、SQL Server、DB2 等

我将从在数据源中构建非规范化视图开始。我还会考虑使用 Reporting Services 而不是您提到的其他工具。如果您使用 SharePoint，还有 PerformancePoint 用于仪表板。

【参考方案1】：

这可能不会直接回答您的问题，但与其寻找临时解决方案，我只想更快地建立您的仓库。

首先，如果您可以快速构建它，那么您不需要临时的；如果您不能快速构建它，那么您也无法快速构建临时解决方案。您甚至提到开发“包含子集数据的小型独立数据库”；这正是报告数据库！

其次，任何临时解决方案也必须得到维护和支持：如果它太有用，那么您的临时解决方案无论如何都会成为您的永久解决方案。这实际上可能是一件好事，因为如果“临时”解决方案满足您的要求，那么为什么不保留它呢？

无论如何，我会首先确定一两个对您的用户具有高价值的关键报告，并承诺在 2 个月内交付它们（1 个月会更好）。开发最基本的、最小的数据库和 ETL/报告流程来提供这些报告，即使它看起来像一个可怕的、被黑客攻击的混乱。确保报告是内部报告，没有人会发送给外部客户；这意味着您可以避免花时间让它们变得漂亮。

在您提交了这些报告后，您现在可以退后一步，看看您做了什么。希望您会发现自己处于以下位置：

您的用户很快就得到了一些有用的报告 报告很难看，但数字是正确的 您已经了解了很多关于用户需求以及他们如何解释和使用数据的知识 您的技术实现一团糟，但您知道这一点，也知道如何改进它

如果 #1 和 #2 为真，那么您将快速交付大量业务价值，同时让用户期望正确通常比漂亮更有价值（这对报告项目非常有用）。如果 #3 和 #4 为真，那么您的第二次迭代将比第一次迭代有很大的改进，即使您发现自己处于必须从头开始重新开发整个事物的最坏情况下，您也会做得更快更好，因为你学到了很多东西。

当然，这只是敏捷开发：您没有理由不能在数据仓库项目中使用快速原型设计和增量交付。与任何 IT 解决方案一样，仓库将随着时间的推移不断增长和维护，因此绝对没有理由尝试在第一个版本中使所有内容都完整和正确。您的用户很可能甚至不知道他们想要什么（详细），因此这种方法也有助于更快地阐明他们的期望和要求。