我们的情况是我们将开始构建数据仓库。如果我们要做正确的话，数据仓库将需要一些时间。它将根据各个流程建立并从那里发展。
我们只有三个数据库，我们将从中提取数据。所有三个数据库都包含不同的信息（财务信息，日程安排和患者信息 - 访问，诊断等）。
我正在考虑使用仪表板/报告工具（例如）http://www.jedox.com/en/或http://www.board.com/us/来向业务显示信息。它将慢慢开始运行DW，因为它是beind设计并推向生产。
毕竟我的问题：在后端向应用程序（仪表板/记者）提供数据的最佳方法是什么，这种方法效率很高，但在我所在的地方并不耗费时间而是建立数据仓库？ IE浏览器。视图，物化视图，包含来自主DB的子集数据的小型单独DB等？
答案 0 :(得分：2)
这可能不是直接回答你的问题，而是找到一个临时的解决方案，我会更快地建立你的仓库。
首先，如果您可以快速构建它，那么您不需要临时的;如果你不能快速构建它，那么你也无法快速构建临时解决方案。你甚至提到开发一个“包含子集数据的小型独立数据库”;这正是一个报告数据库！
其次，任何临时解决方案都必须得到维护和支持：如果它太有用，那么你的临时解决方案无论如何都将成为你的永久解决方案。这实际上可能是一件好事，因为如果“临时”解决方案满足您的要求那么为什么不保留它呢？
无论如何，我首先会确定一个或两个对您的用户具有高价值的关键报告，并承诺在2个月内交付它们（1个月会更好）。开发最基本的，最小的数据库和ETL /报告流程，以便提供这些报告，即使它看起来像一个可怕的，黑客攻击的混乱。确保报告是内部报告，没有人会发送给外部客户;这意味着你可以避免花时间让它们漂亮。
在您发布这些报告后，您现在可以退后一步，看看您做了什么。希望你会发现自己处于以下位置：
如果＃1和＃2都是真的，那么您将快速提供大量业务价值，同时还设置用户期望正确通常比漂亮更有价值（这对报告项目非常有帮助）。如果＃3和＃4都是真的那么你的第二次迭代将是第一次迭代的一个很大的改进，即使你发现自己处于必须从头开始重新开发整个事情的最坏情况，你会更快地完成它更好，因为你学到了很多东西。
当然，这只是敏捷开发：没有理由不能在数据仓库项目中使用快速原型设计和增量交付。与任何IT解决方案一样，仓库将不断增长并随着时间的推移进行维护，因此绝对没有理由在第一个版本中尝试使所有内容完整和正确。您的用户很可能甚至不知道他们想要什么（详细信息），因此这种方法也有助于更快地阐明他们的期望和要求。