Joe*_*eky 6 schema data-warehouse database-design
几年过去了……但我遇到了一个问题集，它让我想起了模式设计模式，我正在努力回忆细节。
本质上，该模式由一个为所有插入、更新和删除提供服务的3 NF（或其他）数据库组成。在某些定期或事件驱动的基础上，它会将其全部（或部分）状态发布到另一个针对高性能只读访问进行了优化的数据库。本质上，发布通常针对完全不同或非规范化的模式。
问题是……这是众所周知的模式吗？如果是，它叫什么，除了相同状态的重复存储之外还有什么陷阱。
Joe*_*own 11
你所描述的是一个数据仓库。实时、规范化的读写系统是 OLTP（在线事务处理），非规范化的只读快照是数据仓库。数据仓库的结构可以是Star Schema，尤其是在高度非规范化的情况下。除了非规范化之外，数据仓库通常还有汇总。在不同维度和/或时间范围内汇总的相同数据可以有多个副本。
这种技术的缺点是快照通常不是 100% 最新的，你必须非常小心你的快照是如何拍摄的，否则你实际上可能会在数据仓库中引入除及时性之外的差异。另一个可能的问题是，由于您在将详细信息汇总到汇总表中时所做的选择，您可能难以从数据仓库中执行某些类型的报告。此外，例如，如果您的数据仓库在不同的时间范围内有多个摘要，您必须小心地使这些摘要相互一致。
特别是时效性问题是您必须小心的问题。我见过用户对他们的在线系统进行了更改，然后因为它没有立即出现在针对数据仓库运行的报告中而感到愤怒。用户往往不知道或不关心报告系统的变幻莫测。
Con*_*lls 10
乔尔·布朗已经总结出了一个数据仓库的性质。我将在此处添加有关报告要求的内容。
数据仓库有什么用
数据仓库非常适合用于计算大量数据的聚合、趋势或其他统计或财务指标的分析报告。通常，周期性负载最适合此类应用。数据仓库的近实时加载有两个主要缺点：
它们的实现要复杂得多。
拥有随时变化的财务数据可能会产生一整类虚假的和解混战。除非您确实需要实时数据（见下文），否则通常最好有一个系统可以报告不会产生任何歧义的固定 as-at 位置。
运营报告与分析报告
如果您有真正的实时需求，那么您就需要一份运营报告。通常，具有真正实时要求的报告本质上不是分析性的。通常，它们是已完成工作的日志、异常报告或待办事项列表，用户需要能够在系统上做一些工作并定期重新运行报告以查看他们是否还有需要注意的未完成事项。通常，它们还与特定操作系统上的特定进程相关联。
通常，这种类型的报告可以脱离基本系统或复制副本运行，并且往往不涉及大量数据。在大多数情况下，此类报告最好作为操作系统或从该系统复制的系统运行。
实时汇总报告
有时，人们确实对低延迟（近实时）数据的分析有真正的要求。该系统的一些要求示例如下：
市场数据分析，您将代码数据直接加载到交易大厅系统。
账户报告系统，用户需要记录一个条目，然后立即报告
Web 服务器日志分析。
对于典型的企业数据仓库应用程序，近实时馈送几乎总是一种反模式，因为它们极大地增加了复杂性，生成了用于协调的移动目标并且实际上并不能满足真正的要求。在这种情况下，批量加载通常是可行的方法。
在实时系统上发现的一个特征是报告的数据几乎总是非常简单（市场数据馈送、会计日志、网络服务器日志条目）。这种简单性使得实时报告变得可行。试图变得聪明并在企业范围内做到这一点将使您陷入痛苦的世界，以实现几乎可以肯定不是真正需要的东西。
单独的操作和分析报告要求
运营和分析报告要求几乎总是相互直接冲突，您几乎总是最好分开管理它们。运行生产数据库复制副本的操作报告，并将数据仓库用于分析报告。
除非您真正需要近实时分析，否则这是迄今为止最好的方法。