一文了解数据仓库( 三 ) _数据仓库

数据集市数据集市可以理解为是一种"小型数据仓库"，它只包含单个主题，且关注范围也非全局.数据集市可以分为两种，一种是独立数据集市(independent data mart)，这类数据集市有自己的源数据库和ETL架构；另一种是非独立数据集市(dependent data mart)，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的"子集" 。
数据集市：部门级别的数据仓库，能为某个局部范围内的管理人员提供服务。
数据仓库：企业级别的数据仓库，能为企业各个部门的运行提供决策支持。
建模的基本概念

文章插图
关系建模
上图为web应用中的一个建模片段，遵循三范式建模，可以看出，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要应用与 OLTP 系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。
维度建模维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法

文章插图
维度建模
上图为维度模型建模片段，主要应用于 OLAP 系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。
关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种
维度建模的三种模式

文章插图
星形模式
星形模式(Star Schema)是最常用的维度建模方式可以看出，星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：维表只和事实表关联，维表之间没有关联；每个维表的主码为单列，且该主码放置在事实表中，作为两边连接的逻辑外键；以事实表为核心，维表围绕核心呈星形分布.

文章插图
雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展，每个维表可继续向外连接多个子维表。(三范式代表作)
星形模式中的维表相对雪花模式来说要大，而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表，满足了规范化设计。然而这种模式在实际应用中很少见，因为这样做会导致开发难度增大，而数据冗余问题在数据仓库里并不严重.

文章插图
星座模式
星座模式(Fact Constellations Schema)也是星型模式的扩展。
前面两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，星座模式将作为最主要的维度建模。
维度表和事实表维度表(dimension)表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包" 。那么以购买为主题进行分析，可从这段信息中提取三个维度：时间维度(昨天早上)，地点维度(京东), 商品维度(皮包) 。通常来说维度表信息比较固定，且数据量小。维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。例如：用户、商品、日期、地区等。常用于一个客观世界的维度描述，往往列比较多。审视数据的角度维表的特征：维表的范围很宽（具有多个属性、列比较多）跟事实表相比，行数相对较小：通常< 10 万条静态表示的，名词性质的表
事实表(fact table)表示对分析主题的度量。比如上面那个例子中，200元就是事实信息。事实表包含了与各维度表相关联的逻辑外键，并通过JOIN方式与维度表关联。事实表的度量通常是数值类型，且记录数会不断增加，表规模迅速增长。事实表的特征：非常的大内容相对的窄：列数较少经常发生变化，每天会新增加很多动态表示的，动词性质的表事务型事实表(每天导入新增)以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新周期型快照事实表(每日全量)周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等