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