为数据仓库或数据集市设计数据库与为传统OLTP系统设计数据库本质上是非常不同的。事实上，许多普遍接受的用于设计OLTP数据库的最佳实践可能被认为是这些纯分析系统的最差实践。因此，数据建模人员在设计数据仓库和数据集市时必须掌握一些新技能。尽管此处包含的某些建议可能与您所接受的相反，但请保持开放的心态。请记住，Seinfeld的GeorgeCostanza并没有在纽约洋基队找到他梦想的工作，直到他拥抱了他所想的一切，如下面的视频片段所示。因此，放弃任何旧的OLTP设计。云数据建模：良好的数据库设计意味着“正确调整规模”和节省开支正如本博客系列的第1部分中所述，云不是必杀技。是的，它提供了一种本质上可以无限扩展的资源。但是你必须付费才能使用它们。当您为部署到云的应用程序做出糟糕的数据库设计选择时，您的公司每月都会为所有不可避免的低效率付出代价。静态过度配置或动态扩展会迅速增加糟糕设计的每月云成本。因此，您真的应该熟悉云提供商规模和成本计算器。请参见下面的图1。它显示了一个只有4TB数据的数据仓库项目的定价，这在今天的标准下是很低的。我选择按需支持最多64个虚拟CPU和448GB内存，因为我希望这个数据仓库完全或至少大部分在内存中以实现闪电般的快速访问。因此，仅在云中运行这个数据仓库每年就花费136000美元。如果我能减少CPU和内存需求，我就能显着降低成本。所以，我不想为了安全而过度配置。我想从第一天起就将这种规模建立在良好的数据库设计之上，这种设计不会因低效设计而浪费资源。 图1：AWS中4TB数据仓库的定价现在，我们将介绍一些适用于本地或云端的数据建模基础知识。首先要认识和理解的也是最重要的事情是您现在正在为其设计数据模型的全新的、完全不同的目标环境。 图2：数据库设计特点主要的底层设计原则是用户运行相对较少的请求，相比之下OLTP系统在非常大的表中扫描数十万到数百万行，并应用聚合功能将数据汇总成一个少量的输出行。对于此目标环境，您不想像在OLTP系统中那样规范化数据。事实上，引用电影《年轻的弗兰肯斯坦》（小科学怪人）中的一句台词，让你的大脑“正常工作”对你有很大好处。星型模式：数据仓库和数据湖的数据建模和数据库设计范例RalphKimball为这种类型模式设计开发了一种称为维度建模和/或星型模式的数据建模和数据库设计范例。我第一次见到拉尔夫是在1990年代初期，当时我参加了他的一个研讨会。我当时在Irwin的老家LogicWorks工作，我向Ralph展示了数据建模工具如何利用他的理想。我在2003年出版了我的第一本书，展示了我如何使用Ralph的技术在Oracle数据库中创建大型数据仓库。星型模式设计其实很简单。只有两种类型的实体和/或表：维度：较小的非规范化表，带有用于最终用户查询的业务描述列事实：非常大的表，其主键由相关维度表外键列连接而成，非键列具有在最终用户查询期间为计算求和的数字让我们以一个简单的现有OLTP数据模型为例，看看如何将其转换为星型模式设计。 图3：OLTP销售点系统的数据模型这是OLTP便利店销售点和订购系统的数据模型。我将其调低了一点以使其足够简单以作为示例。请注意各种颜色，它们基本上代表该数据模型中相似实体的主题领域。因此，在第1步中，我们只需要确定所有维度和事实。黄色实体被扁平化为商店维度，洋红色实体被扁平化为产品维度。绿色实体根本没有纳入数据模型，白色实体成为事实。 图4：添加关系前的销售点系统逻辑数据模型那么期间实体和促销实体从何而来呢？嗯，在大多数数据仓库中，您需要一个时间维度，因为业务用户希望看到给定日期的数据。所以，你总是有一些时间维度。Promotions实体是新的，因为业务用户告诉我们，他们希望能够通过数据仓库看到的关键项目之一是他们的促销活动的效果如何。至于第2步，很简单-只需添加事实与其所有维度之间的关系。请注意，所有关系都已标识。看到星心事实了吗？因此名称星型模式。 图5：添加关系后销售点系统的逻辑数据模型如果幸运的话，您的数据建模工具将为星型模式设计提供图表支持。这里我们看到Owen提供了这样一个功能。但是，许多其他数据建模工具不提供此功能。 图6：销售点系统物理数据模型的星型模式显示格式现在剩下的就是将OLTP数据模型中的所有属性放入我们的维度或事实之一。你最终会得到一个看起来像这样的模型。 图7：放置OLTP系统的所有属性并创建一些新的聚合事实后的星型模式物理数据模型可以预扫描和预聚合数据以加快查询速度你是否注意到销售概念被打破了分解成三个独立的事实？在与业务用户交谈时，我们发现他们通常需要每周或每月的报告或分析。所以我们构建了一些事实，这些事实基本上是基本事实的聚合，所以我们基本上是预扫描和预聚合一些数据来加速这些查询。像这样创建合成事实是很正常的。它们不必像前面的示例中所示那样简单地基于时间。它可以按地区或时区，甚至按感兴趣的产品。比如这个例子中的便利店公司有一个德州总公司和一个啤酒总公司，如图所示，因为他们的总公司在德州，啤酒占所有利润的30%以上。事实上，“啤酒佬”是公司的第三任高管，所以他们当之无愧。 图8：创建一些新的、特定于业务的合理事实后的星型物理数据模型不要阻止优化器看到它是一个星型模式最后，在星型模式设计中要避免的事情一件事是雪花（它与Snowflake数据库无关）。许多数据库优化器识别星型模式并拥有按数量级优化其执行的代码。但是，您不能向图片添加任何会使优化器无法看到它是星型模式的东西，甚至不能使它复杂化。下面是添加到我们之前的星型模式模型中的雪花示例。 图9：雪花化示例阻止优化器将其视为星型模式虽然添加类别和子类别作为规范化工作可能有意义，但额外的关系层通常会使数据库优化器感到困惑，从而导致查询执行时间大大减少。所以请避免雪花。正如我们在此博客中看到的，数据仓库的数据建模与OLTP系统的数据建模有很大不同。然而，有些技术可以产生非常成功的数据仓库，并且有数据建模工具，例如erwin，旨在支持具有此类功能的建模。
