数据仓库的星型模型和雪花模型

星型模型

星型模型是维度模型最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。
星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模 式这个名字的由来

星型模型将业务流程分为事实和维度。
事实包含业务的度量,是定量的数据,如销售的价格、销售的数量、距离,速度,重量等是事实。
维度是对事务数据属性的描述，如日期、产品、客户、地理位置等是维度。
一个含有很多维度的星型模式有时也被称为蜈蚣模型，显然这个名字也是因其形状而得来的。蜈蚣模型的维表往往只有很少的几个属性，这样可以简化对维表的维护，但查询数据时会有更多的表连接，严重时会使模型难以使用，因此在设计星型模式的时候要避免蜈蚣模型

优点：

星型模型是非规范化的，在星型模型的设计开发过程中，不受应用于事务型关系数据库的范式规则的约束。星型模式的优点：

• 简化查询：查询数据时，星型模型的连接逻辑比较简单，而从高规规范化的事务模型查数据时，往往需要更多的表连接
• 简化业务报表逻辑：与高规范化的事务模型相比较，由于查询简单，因此星型模型简化了普通的业务报表逻辑
• 获得查询性能：星型模型可以提升只读报表类应用的性能
• 快速聚合：基于星型模型的简单查询能够提高聚合操作的性能
• 便于向立方体提供数据：星型模型被广泛用于高效地建立OLAP立方体，几乎所有的OLAP系统都提供POLAP（关系型OLAP），它可以直接将星型模型的数据当作数据源，而不用单独建立立方体结构

缺点

星星模型的主要缺点是不能保证数据的完整性。一次性地插入或者更新操作可能会造成数据异常，而这种情况在规范化模型是可以避免的。星型模型的数据装载一般都是以高度受控制的方式，用批处理或准实时过程执行的，以此来抵消数据保护方面的不足

星型模型的另一缺点是对于分析需求来说不够灵活。它更偏向于特定目的建造数据视图，因此实际上很难进行全面的数据分析。星型模型不能自然的支持业务实体化多对多的关系，需要在维度表和事实表之间建立额外的桥接表

事实表

事实表记录了特定事件的数字化考量，一般由数据值和指向维度表的外键组成。通常会把事实表的粒度级别设计得比较低，使得事实表可以记录很原始的操作性事件，但这样做的负面影响是累加大量记录可能会耗时。事实表有以下三种类型：

1. 事务事实表：记录特定事件的事实，如销售
2. 快照事实表：记录给定时间点的事实，如月底账户余额
3. 累计事实表：记录给定时间点的聚合事实，如当月的累计销售额。一般需要给事实表设计一个代理键作为每行记录的唯一标识。代理键是由系统生成的主键，它们不是应用数据，没有业务含义，对用户来说是透明的

维度表

维度表的记录数通常比事实表要少，但每条记录包含有大量用于描述事实数据的属性字段。维度表可以定义各种各样的特性，以下是几种最常用的维度表：

1. 时间维度表：描述星型模型中记录的事件所发生的时间，具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合，需要记录数据的历史，因此每个数据仓库需要一个时间维度表。
2. 地理维度表：描述位置信息的数据，如国家、省份、城市、区县、邮编等。
3. 产品维度表：描述产品以及属性。
4. 人员维度表：描述人员相关的信息，如销售人员、市场人员、开发人员等。
5. 范围维度表：描述分段数据的信息，如高级、中级、低级。

实例

现在有一个连锁店的销售数据仓库，记录销售相关的日期，商品，和产品

Face_Sales是唯一的事实表，Dim_Store,Dim_Date,Dim_Produce是三个维度表.每个维度表的ID字段是它们的主键。事实表的Date_id、Store_Id、Product_Id三个字段构成了事实表的联合主键，同时这三个字段也是外键，分别引用对应的三个维度表的主键。Unist_Sold是事实表的唯一一个非主键列，代表销售量，是用于计算和分析的度量值。维度表的非主键列表示维度的附加属性。下面的查询可以回答2016年各个城市的手机销售量是多少

select s.city as city, sum(f.units_sold) from fact_sales f inner join dim_date d on (f.date_id = d.id) inner join dim_store s on (f.store_id = s.id) inner join dim_product p on (f.product_id = p.id) where d.year = 2016 and p.product_category = 'mobile' group by s.city;

雪花模型

雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。
与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓 的“雪花化”就是将星型模式中的维度表进行规范化处理。当所有的维度表完成规范 化后，就形成了以事实表为中心的雪花型结构，即雪花模式。将维度表进行规范化 的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个 字段中不同值的个数，如主键列具有唯一值，所以有最高的基数，而像性别这样的列基数就很低。

在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表作为雪花模式里的子表，存在具有层次关系的多个父表。

星型模式和雪花模式都是建立维度数据仓库或数据集市的常用方式，适用于加快查询速度比高效维护数据的重要性更高的场景。这些模式中的表没有特别的规范化， 一般都被设计成一个低于第三范式的级别

优点

雪花模式是和星型模式类似的逻辑模型。实际上，星型模式是雪花模式的一个特例（维度没有多个层级）。某些条件下，雪花模式更具优势：

• 一些OLAP多维数据库建模工具专为雪花模型进行了优化。
• 规范化的维度属性节省存储空间。

缺点

雪花模型的主要缺点是维度属性规范化增加了查询的连接操作和复杂度。相对于平面化的单表维度，多表连接的查询性能会有所下降。但雪花模型的查询性能问题近

年来随着数据浏览工具的不断优化而得到缓解。 和具有更高规范化级别的事务型模式相比，雪花模式并不确保数据完整性。向雪花模式的表中装载数据时，一定要有严格的控制和管理，避免数据的异常插入或更新。

数据规范化与存储

规范化的过程就是将维度表中重复的组分离成一个新表，以减少数据冗余的过程。正因为如此，规范化不可避免地增加了表的数量。在执行查询的时候，不得不连接 更多的表。但是规范化减少了存储数据的空间需求，而且提高了数据更新的效率

从存储空间的角度看，典型的情况是维度表比事实表小很多。这就使得雪花化的维度表相对于星型模式来说，在存储空间上的优势没那么明显了。举例来说，假设在 220个区县的200个商场，共有100万条销售记录。星型模式的设计会产生1,000,200条记录，其中事实表1,000,000条记录，商场维度表有200条记录，每个区县信息作为商场 的一个属性，显式地出现在商场维度表中。在规范化的雪花模式中，会建立一个区县维度表，该表有220条记录，商场表引用区县表的主键，有200条记录，事实表没有变 化，还是1,000,000条记录，总的记录数是1,000,420（1,000,000+200+220）。在这种特殊情况（作为子表的商场记录数少于作为父表的区县记录数）下，星型模式所需的空 间反而比雪花模式要少。如果商场有10,000个，情况就不一样了，星型模式的记录数是1,010,000，雪花模式的记录数是1,010,220，从记录数上看，还是雪花模型多。但 是，星型模式的商场表中会有10,000个冗余的区县属性信息，而在雪花模式中，商场表中只有10,000个区县的主键，而需要存储的区县属性信息只有220个，当区县的属性 很多时，会大大减少数据存储占用的空间

有些数据库开发者采取一种折中的方式，底层使用雪花模型，上层用表连接建立视图模拟星型模式。这种方法既通过对维度的规范化节省了存储空间，同时又对用户 屏蔽了查询的复杂性。但是当外部的查询条件不需要连接整个维度表时，这种方法会带来性能损失。

实例

下面所示的查询语句的结果等价于前面星型模式的查询，可以明显看到此查询比星型模式的查询有更多的表连接。

select g.city,sum (f.units_sold) from fact_sales f inner join dim_date d on f.date_id = d.id inner join dim_store s on f.store_id = s.id inner join dim_geography g on s.geography_id = g.id inner join dim_product p on f.product_id = p.id inner join dim_product_category c on p.product_category_id = c.id where d.year = 2015 and c.product_category = 'mobile' group by g.city;