数据仓库建模，星型模型大致理解，就是事实表对应很多维度表；我不太理解雪花模型

星型模式vs雪花模式的多维数据建模以直观的方式组织数据，支持高性能的数据访问。每个多维数据模型由多个多维数据模式表示，每个多维数据模式由一个事实表和一组维度表组成。最常见的多维模型是星形模式。星型模式下，事实表居中，多个维度表呈放射状分布在其周围，并与事实表相连。在星形的基础上，发展出雪花图案。我们来比较一下两者的特点。星形中心带星形图案的实体是指标实体，是用户最关心的基本实体，是查询活动的中心，为数据仓库的查询活动提供量化数据。每个指标实体代表一系列相关的事实，并完成特定的功能。位于星图星角的实体是维度实体，其作用是限制用户的查询结果，过滤数据，使索引实体查询返回的行数更少，从而缩小访问范围。每个维度表都有自己的属性，维度表和事实表通过关键字关联。虽然星形模式是一个关系模型，但它不是一个标准化的模型。在星型模式下，维度表被故意反规范化，这是OLTP系统中星型模式和关系型模式的基本区别。使用星型模式主要有两个原因:提高查询效率。用星型模式设计的数据仓库的优点是数据组织经过了预处理，主要数据在庞大的事实表中，所以你可以通过扫描事实表进行查询，不需要连接多个庞大的表，查询访问效率高。同时，由于维度表一般比较小，甚至可以放在缓存中，与事实表连接时速度更快；便于用户理解。对于非计算机专业用户来说，星型模式比较直观，通过分析星型模式很容易组合各种查询。总结:非正常化；多维数据集中的每个维度都与事实表相连(通过主键和外键)；没有渐变维度；存在冗余数据；查询效率可能更高；没有过多考虑归一化因素，设计和维护相对简单。

在实际应用中，随着事实表和维度表的增加和变化，星型模型会产生很多衍生模型，包括星系模型、星座模型、二次元维度表、雪花模型等。雪花模式是星型模式维度表的进一步分层，将部分维度表扩展为事实表，这样不仅可以应对不同层级用户的查询，还可以通过层级之间的链接将源数据向上整合，最大限度地减少数据存储量，从而提高查询功能。雪花图案的维度表是基于范式理论，所以是介于第三范式和星形图案之间的一种设计图案。通常有些数据组织采用第三范式的规范结构，有些数据组织采用星型模式的事实表和维度表结构。在某些情况下，雪花模式的形成是由于在星型模式组织数据时，为了减少维度表的层次结构，处理多对多的关系，对数据表进行了标准化。雪花模式的优点是:一定程度上减少了存储空间；规范化的结构更容易更新和维护。同样，雪花模式也有很多缺点:雪花模式复杂，用户难以理解；浏览内容相对困难；额外的连接会降低查询性能。在数据仓库中，通常不建议使用“雪花”。因为在数据仓库中，查询性能比OLTP系统更受重视，雪花模式会降低数据仓库系统的性能。总结:正常化；数据冗余少；有些数据需要连接才能获取，可能效率不高；标准化操作复杂，导致设计和后期维护复杂；在实际应用中，可以采用上述两种模型的混合:比如中间层采用雪花结构减少数据冗余，数据集市部分采用星形便于数据提取和分析。

有时候标准化和效率是一对矛盾。一般我们会为了性能好而牺牲空间(归一化)，在一个“大表”中存储尽可能多的维度信息是最快的。通常视情况采取折中策略。

明星有时候会造成大量的数据冗余，很有可能事实表会变得极其臃肿(百万数据×数百维)。

每次需要更新维度成员时，事实表也必须更新。

雪花类型有时只需要更新雪花维度中的一个层，而不需要更改庞大的事实表。

具体问题具体分析，比如时间维度，年份，季节，不需要做雪花，但是涉及到产品和产品的分类。如果分类信息也是我们需要分析的信息，那么我一定会建立一个关于分类的查找表，也就是使用雪花模式。

雪花结构是一种规范化的结构，从数据仓库中去除冗余数据。例如，有一个销售事实表，然后有一个产品维度表与其连接，然后有一个产品类别维度表与产品维度表连接。这种结构就是雪花结构。雪花结构除了数据冗余，还需要连接起来生成一些统计量，所以效率不一定有星型结构那么高。规范化也是一个复杂的过程，相应的数据库结构设计、数据ETL、后期维护都比较复杂。

星型模式是一种非正式的结构。多维数据集中的每个维度都与事实表相连，没有渐变维度，所以数据是冗余的。由于数据的冗余性，很多统计查询不需要外部连接，所以效率一般比雪花高。星型结构不需要考虑很多归一化因素，设计和实现相对简单。

虽然两种结构有一些区别，但我个人认为没有好坏之分。最重要的是看项目的需求和业务逻辑。