我们刚刚开始组建一个数据仓库，它将对我们的报告要求有用，将不同的数据源整合在一起。
一起回顾数据的潜在用途，我们发现了一些潜在的场景，我们的一些事务处理系统可以以有用的方式引用这些数据。显然数据会过时，并且针对读取进行了优化，但是在某些情况下，这对于应用程序目的来说是好的，并且会减少核心服务器上的负载。
我的问题是：交易系统访问存储在数据仓库中的数据是否被认为是一种糟糕的设计？显然，我们仓库的主要目的是报告，这让我质疑我们是否应该允许其他非报告系统读取数据。我的直觉引导我远离允许应用程序读取和显示数据，有什么好的理由来听它们吗？！
让仓库成为应用程序数据消费者和分析数据消费者的中心从根本上没有错。不过，这里有一些需要考虑的地方。
您将需要一个技术解决方案来支持两种工作负载所需的可用性、事务隔离和一致性级别。例如，您能否确保应用程序不会饿死资源的分析查询，反之亦然？即使在仓库装载期间，您能否以一致且及时的方式向应用程序提供数据？假设您总是能够在下班后装载仓库是不明智的 - 即使您认为您今天可以做到这一点。
确保你的仓库是正常化的（至少意味着 Boyce-Codd / 5th Normal Form 或接近它的东西）。这对任何仓库来说都是一个很好的建议，但尤其是在您需要支持非分析查询的情况下。
您的应用程序需要更新仓库吗？如果是这样，那么您需要考虑它如何与 ETL 流程的其余部分集成。
考虑是否为应用程序提供自己的数据集市。这可能是最安全的选择。
让您的 OLTP 系统访问 DW 数据并没有错，事实上，随着系统的发展，您会发现事务系统和信息系统之间的界限变得模糊。
我也不会太担心数据结构，只要你想出一些有用的东西。3 NF 可能是答案，但从多维数据库访问高度汇总的数据也可能是一个很好的解决方案 - 取决于您要解决的问题。
最后要考虑的一件事是您试图从数据仓库中取出的数据类型。它是汇总交易（例如平均销售额）还是更像共享维度数据（例如客户姓名和地址）？如果是后者，您可能需要考虑将主数据管理策略与数据仓库策略相结合。
最后一件事，试着弄清楚为什么你不愿意在这些数据库之间共享数据。是你可以指手画脚的事情，还是真的只是因为你已经接受了我们行业的培训，认为他们需要分开？请记住，归根结底，我们的工作并不是真正构建数据仓库和商业智能系统。他们将以可靠、务实、具有成本效益的方式解决业务问题。