最近，参与一个项目底层采用的是Oracle数据库数据仓库建设，在项目实施的过程中，与参与项目的同事共同对该数据仓库的数据模型进行了重构。本文针对于基于的数据仓库相关建模基础知识作重新的梳理，分享给大家。

Oracle是目前业务使用最为广泛的数据库类型，在现实应用中往往会有两种基本应用场景：

基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一。OLTP数据库主要考虑的是数据库的业务响应时间以及并发度。一个公司往往会使用并维护若干个数据库，这些数据库保存着公司的日常操作数据，比如商品购买、酒店预订、学生成绩录入等，票务交易系统是个典型的操作型系统。

OLAP使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。这里主要应用是的数据仓库，它是用于实时或离线数据分析。这类数据库作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析。它更关注于整个数据吞吐量而非单个查询的速度。

因此，这两种类型应用中的Oracle数据库，在数据建模有着非常明显的区别。

OLTP(业务)数据库的特点：

• 用于减少冗余和提高精度 。

• 适合于数据的写入和更新而不是数据的读取。

• 数据被细分为很多表(为了消除冗余)，大的查询执行起来比较慢。

OLAP数据仓库的特点：

• 通常使用星型和雪花型结构布局。所有事务型数据，大部分数值型数据存储在事实表中，所有的参考数据，例如产品信息等，存储在独立的维度表中。

• 星型结构数据库比完全标准化数据库含有的表少，查询性能更快。

• 部分表反范式化（如刻意增加冗余）提升查询和扫描性能

分析型数据仓库较多采用的是维度建模，数据冗余度较高，维护麻烦，但好处是便于二次计算，分析。下面我们将重点介绍分析型数据库（数据仓库模型）的详细内容。

维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

它本身属于一种关系建模方法，但和操作型数据库中的关系建模方法相比增加了几个概念：

维度是一个与业务相关的观察角度，依赖于数据的有效性和表达业务成效的关键性能指标。它表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包)。

可将业务的每个方面构造成一个维度，如时间维度可以由年、月、日、小时构成。一个维护下设有若干层，如地区维度有地域、国家、办事处、技术人员组成。

通常来说维度表信息比较固定，且数据量小。

表示对分析主题的度量。比如上面那个例子中，“某某在某个时间购买了多少的钱的某个东西” 这一连串的组合就是是事实信息。事实表包含了与各维度表相关联的外码，并通过JOIN方式与维度表关联。

事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。

在数据仓库中不需要严格遵守规范化设计原则，因为数据仓库少有更新，基本上大量的数据装载和查询。

在数据仓库的建设中，一般都会围绕着星型模型和雪花模型来设计表关系或者结构。下面我们先来理解这两种模型的概念。

星型模式(Star Schema)是最常用的维度建模方式，下图展示了使用星型模式进行维度建模的关系结构：

星型模型是一种多维的数据关系，它由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用数仓时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和若干相关度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。

所以，一般而言:

• 维表只和事实表关联，维表之间没有关联。

• 每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的外码。

• 以事实表为核心，维表围绕核心呈星型分布。

• 事实表与维度表之间并没有强制的外键约束。

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。

下图为使用雪花模式进行维度建模的关系结构：
 

雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。

星型模型的设计方式主要带来的好处是能够提升查询效率。生成的事实表已经经过预处理，主要的数据都在事实表里面，所以只要扫描事实表就能够进行大量的查询，而不必进行大量的join。另外，维表数据较少，即使进行join关联查询效率也相对较高，除此之外，星型模型的事实表可读性比较好，不用关联多个表就能获取大部分核心信息，设计维护相对比较简单。

雪花模型的设计方式主要带来的好处是数据冗余少，扩展性较星型模型要强，但是查询时涉及join关联的表要更多，效率较低。

星型模型和雪花模型两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。

星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式：
 

在进行维度建模前，首先要了解用户需求。假设经过多次的需求沟通确认得到以下ER图：
 

随后可利用建模工具将ER图直接映射到关系图。
 

需求搜集完毕后，便可进行维度建模了。本例采用星型模型维度建模。但不论采取何种模式，维度建模的关键在于明确下面四个问题：

本例中根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的。

1）维度PRODUCT可由关系PRODUCT，关系VENDOR，关系CATEGORY连接得到。

2）维度CUSTOMER和关系CUSTOMER相同。

3）维度STORE可由关系STROE和关系REGION连接得到。

4）维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到。

本例的主题是销售，而销量和销售额这两个指标最能直观反映销售情况。

销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA，关系PRODUCT连接得到；明确这四个问题后，便能完成维度建模：
 

这是个典型的星型模型结构，但仔细观察发现

• 维表不满足规范化设计(不满足3NF)。

• 事实表也不满足规范化设计(1NF都不满足)。

对于这两个问题，由于当前建模环境是数据仓库，较少或基本没有更新操作，所以不需要严格做规范化设计来消除冗余避免更新异常。

当然我们对维度表进行再细分，也可做出以雪花模型进行维度建模，如下所示：

但这样会加大查询人员负担：每次查询都涉及到太多表了。因此实际使用需要根据业务场景，避免遵从范式设计，导致查询性能下降。

假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品，那么此时不需要重新维度建模，只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下，这个就是一个星座模型结构了：
 

无论星型模型还是雪花模型，需要根据应用场景来确定。在数据仓库中雪花模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。