文章目录
- 一、什么是数据仓库模型？
- 二、数据仓库模型的类型
- 2.1、星型模型
- 2.1.1、星型模型的特点
- 2.2、雪花模型
- 2.3、星座模型（事实星座模型）
- 2.3.1、如何创建 星座模型？
- 2.3.3、Galaxy Schema 的优缺点
- 2.3.3.1、优点：
- 2.3.3.2、缺点：
- 2.4、对比
- 2.4.1、雪花 vs 星型
- 2.4.2、星型 vs 星座、雪花
- 2.4.3、星型 vs 雪花 vs 星座
- 二、模型的选择
- 2.1、数据优化
- 2.2、业务模型
- 2.3、性能
- 2.4、ETL
- 三、总结
- 关注我的公众号【宝哥大数据】，更多干货
一、什么是数据仓库模型？
数据仓库模型是一种合理定义数据仓库内容的结构，方便对数据仓库进行的操作和数据仓库系统的维护，通常包括对数据库、表、视图、索引和数据，使用预定义的设计类型进行定期结构化，例如 Star Schema、Snowflake Schema、Galaxy Schema（也称为 Fact Constellation Schema）。
模型是描述整个数据库的逻辑描述。在数据仓库中，包括记录的名称和描述。它具有所有数据项以及与数据关联的不同聚合。就像数据库有一个模式一样，它也需要为数据仓库维护一个模式。根据数据仓库中维护的设置和数据，有不同的模式。
二、数据仓库模型的类型
事实表和维度表 构成了数据仓库中任何模型的基础，这些表和维度表对于理解很重要。
- 事实表应该具有与任何业务流程对应的数据。每行代表可以与任何进程关联的任何事件。它存储用于分析的定量信息。
- 维度表存储有关如何分析事实表中的数据的数据。它们有助于事实表收集有关将要采取的措施的不同维度。
2.1、星型模型
当所有维表都直接连接到 “事实表” 上时，整个图解就像星星一样，故将该模型称为星型模型，如图 1 。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。
如： 在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余。
图1. 销售数据仓库中的星型模型
2.1.1、星型模型的特点
- 在星型模式中，一个事实表和若干的维度表连接，这种结构类似于星形，因此被称为星形模式。
- 这里的事实表由数据仓库中的主要信息组成。它围绕较小的维度查找表，这些表将包含不同事实表的详细信息。每个维度中存在的主键与事实表中存在的外键相关。
- 事实表有两种类型的列，这些列包含维度表的外键和事实表的属性。在星的中心，有一个事实表，星的点是维度表。
- 事实表采用
3NF形式，维度表采用非规范化形式。星型模式中的每个维度都应该由唯一的维度表表示。维度表应该连接到一个事实表。事实表应该有一个键和属性。
2.2、雪花模型
当有一个或多个维度表没有直接连接到事实表上，而是通过其他维度表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为更小小的维度表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。
如图 2，将地域维表又分解为国家，省份，城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能。雪花型结构去除了数据冗余。
图 2. 销售数据仓库中的雪花型模型
星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。
2.3、星座模型（事实星座模型）
星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型
从本质上讲
- 可以将 Galaxy 模型拆分为相互关联且完全标准化的星型模型的集合，以避免数据的冗余和不准确。
- 也可以是雪花模型与星型模型的关联，两个模型的事实表相连接。根据需要连接两种结构的维度表。由此产生的系统在结构中看起来像一个星座，其中事实表是这里的星星。这解释了名称 Galaxy 模型。这种类型的模型也称为“事实星座”模型，因为它有多个事实表。
由于其中可以同时包含星型和雪花模式，因此 Galaxy Schema 已完全标准化。标准化只不过是将信息分解为更多的层次，以促进事实表和维表之间的有意义的关系。这可确保系统中的数据准确、有组织且定义明确。
2.3.1、如何创建 星座模型？
当系统由连接到维度表 C、D、E、F、G、H、I 的事实表 A 和 B 组成时，可以构建 Galaxy Schema。根据规则，事实表可以相互连接，维度表可以与系统内部的任何事实表和维度表连接，下面的示例将有助于更好地理解Galaxy Schema的底层概念。
在这个例子中，学生数据库有两个事实表——学生和教职员工。两个事实表都可以有共同的维度——专业课程、艺术与科学，基于各自的部门。此外，从学生维度来看，标准化适用于获得合作社和校外工作。这可以进一步细分以提及经验类型和实习。
另一方面，教学人员会给学生布置作业。并且，这些分配维度表可以进一步规范化以定义评估细节。所有这些维度表都可以根据项目提供给设计团队的信息的局限性进一步规范化。
2.3.3、Galaxy Schema 的优缺点
2.3.3.1、优点：
- 它的多维特性有助于有效地构建复杂的数据库系统。
- 作为标准化的结果，最小或没有冗余。
- 考虑到系统的复杂性，这是一个灵活的模式。
- 数据质量会很好，因为规范化为定义明确的表/数据格式提供了优势。
- 使用 Joins 查询时，可以提取清晰准确的数据。
- 高数据质量和准确性有助于创建出色的报告和分析结果。
2.3.3.2、缺点：
- Galaxy 模型在结构上可能很复杂。
- 处理这个模型是乏味的，因为模型和数据库系统的复杂性使它变得更加复杂。
- 数据检索是通过结合条件表达式的多级连接完成的。
- 预期的标准化级别数取决于给定数据库的深度。
- 由于 Galaxy 模型应用于具有复杂结构的大型数据库系统，因此维护和支持任务变得困难。
- 其较大的设计布置和详细的查询过程需要较大的存储空间。
- 分析变得困难，因为它对可以拥有的事实表和维度表的数量没有限制。
当为项目团队提供多个事实表，而不是单独连接的维度和事实表之间共享的维度时，Galaxy Schema 可以是一个组织良好的解决方案。大多数高级应用程序可能需要多个事实表来共享维度表，而在这种情况下，Galaxy Schema 是一个给定的方法。如果要求同意更多的存储空间、接受低性能、具有多个事实表和多个维度表的结构、规范化的时间和空间，那么 Galaxy Schema 将是该特定数据库系统的最佳解决方案。
2.4、对比
2.4.1、雪花 vs 星型
维度的层级，标准的星型模型的维度层级只有一层， 而雪花星型的维度可能涉及多层。
2.4.2、星型 vs 星座、雪花
星座模型 基本上是很多数据仓库的常态，因为很多数据仓库都是多个事实表的。所以星座不星座只反映是否有多事实表，他们之间是否共享一些维度表。
星座模型区别于前两种，也是基于多个事实表
2.4.3、星型 vs 雪花 vs 星座
特征 | 星型架构 | 雪花架构 | 星座模型 |
维护/更改 | 它有更多的冗余数据，因此更难更改或维护 | 由于冗余较少，此模式更易于更改和维护 | 冗余哨，但是架构复杂，难以实现 |
易懂 | 查询的复杂度较低，因此很容易理解 | 应用的查询更复杂，因此难以理解 | 复杂 |
查询执行时间 | 它有更少的外键，因此查询执行速度更快，花费的时间更少。 | 由于外键较多，查询执行时间较多，或者查询执行速度较慢。 | |
数据仓库类型 | 更适合具有单一关系的数据集市，即一对一或一对多 | 更适合复杂的关系，即多对多关系 | 复杂的应用程序 |
连接数 | 它有更多的连接数 | 它的连接数量较少 | 多 |
维度表 | 每个维度只有一个维度表 | 单个维度有一个或多个维度表 | |
可用性 | 如果维度表的大小较小，即行数较少，则首选星型模式。 | 当维度表的大小较大时很好用 | |
规范化和非规范化 | 事实表和维度表都是非规范化的。 | 事实表是非规范化的，而维度表是规范化的 | 复杂 |
数据模型 | 它遵循自上而下的方法 | 它遵循自下而上的方法 |
二、模型的选择
首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。
星型还是雪花，取决于性能优先，还是避免冗余、灵活更优先。
目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是 hadoop 体系，减少 join 就是减少 shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）
2.1、数据优化
雪花模型使用的是规范化数据，也就是说数据在数据库内部是组织好的，以便消除冗余，因此它能够有效地减少数据量。通过引用完整性，其业务层级和维度都将存储在数据模型之中。
相比较而言，星形模型使用的是反规范化数据。在星形模型中，维度直接指的是事实表，业务层级不会通过维度之间的参照完整性来部署。
2.2、业务模型
主键是一个单独的唯一键(数据属性)，为特殊数据所选择。在上面的例子中，Advertiser_ID 就将是一个主键。外键(参考属性)仅仅是一个表中的字段，用来匹配其他维度表中的主键。在我们所引用的例子中，Advertiser_ID 将是 Account_dimension 的一个外键。
在雪花模型中，数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。而在星形模型中，所有必要的维度表在事实表中都只拥有外键。
2.3、性能
第三个区别在于性能的不同。雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低。举个例子，如果你想要知道Advertiser 的详细信息，雪花模型就会请求许多信息，比如Advertiser Name、ID以及那些广告主和客户表的地址需要连接起来，然后再与事实表连接。
而星形模型的连接就少的多，在这个模型中，如果你需要上述信息，你只要将Advertiser的维度表和事实表连接即可。
2.4、ETL
雪花模型加载数据集市，因此 ETL 操作在设计上更加复杂，而且由于附属模型的限制，不能并行化。
星形模型加载维度表，不需要再维度之间添加附属模型，因此ETL就相对简单，而且可以实现高度的并行化。
三、总结
雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”
星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”
事实星座模式是数据仓库最长使用的数据模式，尤其是企业级数据仓库（EDW）。这也是数据仓库区别于数据集市的一个典型的特征，从根本上而言，数据仓库数据模型的模式更多是为了避免冗余和数据复用，套用现成的模式，是设计数据仓库最合理的选择。当然大数据技术体系下，数据仓库数据模型的设计，还是一个盲点，探索中
