在阅读了这样的问题后，我理解了数据仓库的概念：什么是数据仓库？. 我熟悉 OLAP 和 MDX（MDX 在有限的范围内）。
我有一个.NET 应用程序，它连接到大约十五个不同的数据库来搜索信息并管理信息，即它是一个连接到十五个基于 Oracle/SQL 的数据库的 Java 应用程序。我相信数据仓库会满足我的需求。我有两个关于数据仓库的问题：
数据仓库通常是用于快速访问的事务数据库的重新格式化版本，为最终用户（技术和非技术）提供业务洞察力。例如，Kimball 模型中的数据仓库是星型模式中事务数据库的非规范化（想想又高又瘦）版本。数据取自 OLTP 数据库，经过 ETL 流程（提取、转换、加载），然后可供业务用户使用（例如，用于查询业务对象的最终用户 UI）。
这有很多很多变化。看看一些关于基本 Kimball 风格的数据仓库的文章，你会得到很好的服务（我不想有偏见，这只是我过去使用过的）。如果您觉得需要实体书，亚马逊上有早期版本的使用 Kimball Warehousing 书籍只需几美分。
在规模的一端，您有一个“批量加载”的数据仓库，这意味着运行作业以加载数据。您可以利用这种专门的处理时间对数据进行建模并将其转换为易于分析的模式。数据仓库不仅仅是复制数据。
在规模的另一端是您现在正在做的事情 - 执行“联合”查询。
您需要研究每种方法的优缺点，并将它们与您的业务需求进行比较。您还需要考虑系统的未来状态，即您的程序可能现在可以工作，但是如果数据量增加或您突然需要访问另外五个系统会发生什么？
例如，如果您的用户拥有过期一天的数据（延迟），是否可以？这在5年后还会好吗？
在回答您的问题时：
1）您是否将做出决策所需的所有数据复制到数据仓库中？
如果您的用户可以忍受延迟，并且您有足够的磁盘空间和足够智能的复制（即 CDC），并且源系统的临时查询是一个问题，那么是的，您将复制所有数据。（变成通常称为 ODS 的东西）
2）您使用什么作为用户界面？
既然您已经提到了 SSIS（一个 MS 工具），请注意 MS 还附带 SSAS（一个多维数据集构建工具）、SSRS（一个 Web 报告工具）和 Excel（基本上是您的多维数据集客户端）。您可以将其包装在 Sharepoint 中，但这并非易事。
请注意，所有这些功能（ETL、Cubing、用户界面）也由许多其他供应商提供，但是在 MS 商店中，您基本上已经购买了 BI 工具，因此您可能希望从这些工具开始。
您可以使用 .Net 为自己构建一个更复杂的工具，但最好还是从现成的东西中获取。