星型模型
看下图你就知道为啥叫星型模型了，就是抽象出来的样子像一颗星星。
如果你足够仔细，其实就能发现星型模型，乃至于维度模型的秘密。
在维度模型的设计理念中，数据工程师把所有的业务操作抽象成两类：
一类是业务操作时，需要的一些基础信息，也就是事实发生的前提。比如商品列表、商家信息等；一类是业务操作结果的记录，也就是当时事实的记录结果，所以叫事实，对应的表就叫事实表。比如上图中的订单事实表，就是记录了当时这个订单发生的所有事实，比如你买了几个东西，多少钱等。这两类信息必须关联起来，才能形成完整的交易链条。这两类信息画成图，就是中间是事实表，四周是维表，中间用代码连接。整个形状像是一个星星一样，所以叫星型模型。
雪花模型
我朋友圈里全是聪明人，所以不看图你也应该能猜到，雪花模型为啥叫这个名字了。是的，没错！
就是因为形状像雪花。
逻辑跟星型模型是一样的，事实表、维度表。
在关系型数据库中，那时候存储还比较贵，磁盘很小，所以每一份数据都要尽量少存一些，所以当时会严格按照三范式的要求，把每一个属性都单独抽成表。以全国的三级行政区划表为例，如果是一张表，三个列，就是省代码、省名称、市代码、市名称、县代码、县名称，省代码和省名称会重复非常多次。拆成三张表，就是一张省表、一张市表、一张县表，省表里有三十几条数据，市表里几百条数据；县表里就几千条数据。
另外一个好处就是表间关系就非常清晰，看到雪花模型图，一眼就能看明白整个架构有哪些内容，各自的关系是怎样的。
星系模型
雪花模型还有一个变种，叫做星系模型（星座模型），其实就是多个雪花模型连在一起。
如上表所示，上下是订单和营销两个雪花模型，两片雪花通过两个事实表连接在一起，形成一个星系。另外，在星系中还会对每个雪花中相同的维度进行抽象，比如地区维度，这时候星系就会很复杂，上图中为了保持简洁，并没有体现这种情况。
宽表模型
前面讲过三范式。严格按照三范式的规则设计出来的表就是窄表，每张表只说一件事情，如果顺带说了其他事情，就要拆表。相对于窄表来说，一张表中说了好几个事情，好几个概念，就是宽表了。宽表其实就是三范式的退化。宽表在关系型数据库中是异类，但是在NoSQL数据库中大行其道。
上图就是用三个窄表解决了订单业务数据存储。优点是关系非常清晰，一眼能看明白实体以及之间的关系。
上表就是一张大宽表，冗余了卖家和买家的信息。对开发、数据分析师非常友好，不用join，直接拖数据就好了。
