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