Database design OLTP应用程序读取数据仓库数据设计

我们刚刚开始构建一个数据仓库，它将有助于满足我们的报告需求，将不同的数据源整合在一起

我们一起回顾了这些数据的潜在用途，发现了一些潜在的场景，其中一些事务处理系统可以以有用的方式引用这些数据。显然，数据将过时，并针对读取进行了优化，但是在某些情况下，这对于应用程序来说是很好的，并将减少核心服务器上的负载

---

我的问题是：对于事务系统来说，访问存储在数据仓库中的数据是否被认为是一种糟糕的设计？显然，我们仓库的主要目的是报告，这让我怀疑我们是否应该允许其他非报告系统读取数据。我的直觉引导我远离允许应用程序读取和显示数据，有什么好的理由听它们吗

让仓库成为应用程序数据消费者和分析数据消费者的中心，从根本上说没有什么错。不过，这里有几点需要考虑

您需要一个支持两种工作负载所需的可用性、事务隔离和一致性级别的技术解决方案。例如，您能否确保应用程序不会耗尽分析查询的资源，反之亦然？即使在仓库装载期间，您是否能够以一致和及时的方式向应用程序提供数据？假设你总是能够在几个小时之外装载仓库是不明智的——即使你认为你今天可以这样做

确保仓库正常化（至少指Boyce Codd/5th标准格式或类似格式）。对于任何仓库来说，这都是一个很好的建议，尤其是当您需要支持非分析性查询时

您的应用程序是否需要更新仓库？如果是这样，那么您需要考虑如何与ETL过程的其余部分集成。

---

考虑是否为应用程序提供自己的数据集市。这可能是开始时最安全的选择。

让您的OLTP系统访问DW数据没有错，事实上，随着系统的发展，您将看到事务系统和信息系统之间的界限变得模糊

一、 另外，只要你能想出一些有效的方法，就不用太担心数据结构。3 NF可能是答案，但从多维数据库访问高度汇总的数据也可能是一个很好的解决方案-取决于您试图解决的问题

最后要考虑的是您试图从数据仓库中获取的数据类型。它是汇总交易（如平均销售额）还是更像共享维度数据（如客户名称和地址）？如果是后者，您可能需要考虑将主数据管理策略与数据仓库策略相结合。 还有最后一件事，试着找出为什么在这些数据库之间共享数据时犹豫不决。这是一件你可以指指点点的事情，还是仅仅因为你接受了我们行业的培训，认为它们需要分开？记住，归根结底，我们的工作并不是真正建立数据仓库和商业智能系统；他们将以可靠、务实、经济高效的方式解决业务问题