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