数据仓库重点

1.什么是数据仓库？

     数据仓库是决策支持系统（dss）和联机分析应用数据源的结构化数据环境。数据仓库研究和解决从数据库中获取信息的问题。

     数据仓库的特征在于面向主题、集成性、稳定性和时变性，用于支撑管理决策。

     数据仓库存在的意义在于对企业的所有数据进行汇总，为企业各个部门提供统一的、规范的数据出口。

     其中的面向主题指的是：数据仓库中的数据是按照一定的主题域进行组织的，每一个主题对应一个宏观的分析领域。数据仓库排除对于决策无用的数据，提供特定主题的简明视图。

    集成的：企业内不同业务部门数据的完整集成。对于企业内所有数据的集成要注意一致性（假设财务系统中对于性别使用F/M，而OA系统对性别使用A/B，这是数据不一致，如果想搭建企业级别的数据仓库，需要数据具有一致性）。

   稳定的：数据仓库里不存在数据的更新和删除操作。

   变化的：数据仓库里会有完整的记录某一个对象在一段时间内的变化情况。

数据仓库的目标是实现集成、稳定、反映历史变化有组织有结构的存储数据的集合。

2.OLTP和OLAP

   操作型处理，叫联机事务处理OLTP（其全拼是：On-Line Transaction Processing），也可以称为面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。

   分析型处理，叫联机分析处理OLAP（其全拼是：On-Line Analytical Processing），一般针对某些主题的历史数据进行分析，支持管理决策。

OLTP与OLAP的异同之处：

操作型处理	分析型处理
细节的	综合的/提炼的
实体-关系（ER）模型	星型/雪花模型
存储瞬间的数据	存储历史数据，不包括最近的数据
可更新的	只读，只追加
一次操作一个单元	一次操作一个集合
性能要求高，响应时间短	性能要求宽松
面向事务	面向分析
一次操作数据量小	一次操作数据量大
支持日常操作	支持决策需求
数据量小	数据量大
客户订单、库存水平和银行账户等	客户收益分析、市场细分等

3. 星型模式、雪花模式与星座模式

 ①星型模式

 

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

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

②雪花模式

 

   雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。

   与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓的“雪花化”就是将行星模型中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为

中心的雪花型结构，即雪花模式。将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如主键列具有唯一值， 所以有最高的基数，而像性别这样的列基数就很低。

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

 ③星座模式

     数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式。

4.数据仓库分层理论

   CIF层次架构

     CIF层次架构（信息工厂）通过分层将不同的建模方案引入到不同的层次中，CIF 将数据仓库分为四层。

    如图所示：

维度建模	DM
维度建模	DWS
维度建模ER	DWD
ER	ODS

ODS（其全拼是：Operational Data Store）：操作数据存储层，往往是业务数据库表格的一对一映射，将业务数据库中的表格在 ODS 重新建立，数据完全一致。

DWD（其全拼是：Data Warehouse Detail）：数据明细层，在 DWD 进行数据的清洗、脱敏、统一化等操作，DWD 层的数据是干净并且具有良好一致性的数据。

DWS（其全拼是：Data Warehouse Service）：服务数据层（公共汇总层），在 DWS 层进行轻度汇总，为 DM 层中的不同主题提供公用的汇总数据。

DM（其全拼是：Data Market）：数据集市层，DM 层针对不同的主题进行统计报表的成。​​​​​

1.ODS（原始数据层）（Operational Data Store）

      ODS 层中的数据全部来自于业务数据库，ODS 层的表格与业务数据库中的表格一一对应，就是将业务数据库中的表格在数据仓库的底层重新建立一次，数据与结构完全一致。  ODS_WEBLOG

由于业务数据库（OLTP）基本按照 ER 实体模型建模，因此 ODS 层中的建模方式也是ER 实体模型。

2.DWD（数据ETL层）

      DWD 层要做的就是将数据清理、整合、规范化，脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。DWD 层应该是覆盖所有系统的、完整的、干净的、具有一致性的数据层。

     在 DWD 可能会用到 ER 或者维度模型。在 DWD 层会抽取出公共维度，例如区域等。也就是说 DWD 层是一个非常规范的，高质量的，可信的数据明细层。

3.DWS（数据汇总层）（点击数据《--》用户数据）

      DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，会针对度量值进行汇总，目的是避免重复计算。往往在 DWS 层建立宽表，例如订单总金额，可能在原始数据中没有这个数据，进入 DWS 层后可以统计出订单总金额，避免重复地拿订单明细数据去计算。DWS 层建议使用维度建模，因为数据仓库的主要应用是进行数据分析。

4.DM（数据集市）（交给使用数据的各个部门BI）

      DM 层为数据集市层，面向特定主题，例如订单主题、物流主题等。在 DM 完成报表或者指标的统计，DM 层已经不包含明细数据，是粗粒度的汇总数据，因此 DM 层会被当成 BI 或者 OLAP 的底层模型。

     在大数据数据仓库领域内，数据仓库是包括集市的，而且物理上是统一、非隔离的，集市的概念相较与传统数据仓库比较弱化，由于有底层明细数据、通用汇总数据的存在，数据集市一般位于上层。

     应用层面存在相应分析主题的概念，甚至很大程度上存在集市交叉的现象，所以如果是在大数据领域构建企业整体数据仓库，并且数据集市也一块规划，建议集市弱化，把它当作是梳理上层数据域的工具。

主题设计思路：

1. 按照使用部门划分集市主题
2. 按照业务模块划分集市主题

5.什么是数据库？

     数据库(Database)是按照数据结构来组织、存储和管理数据的建立在计算机存储设备上的仓库。

     数据库是长期储存在计算机内、有组织的、可共享的数据集合。数据库中的数据指的是以一定的数据模型组织、描述和储存在一起、具有尽可能小的冗余度、较高的数据独立性和易扩展性的特点并可在一定范围内为多个用户共享。

     常用的数据库有 MySQL、ORACLE、SQL Server 等。

6.数据仓库基本理论

 ①一范式：

     一范式（1NF）：域应该是原子性的，即数据库表的每一列都是不可分割的原子数据项。
     域：域就是列的取值范围，比如性别的域是（男，女）

    数据表中的所有列保持其原子性，不可再分。

下图所示：不符合一范式的表格设计：

ID	商品	商家	用户ID	产地
001	五台电脑	XXX旗舰店	00001	河北省石家庄市裕华区

很明显上图 所示的表格设计是不符合第一范式的，商品列中的数据不是原子数据项，是可以进行分割的，因此对表格进行修改，让表格符合第一范式的要求，修改结果如下图所示：

ID	商品	数量	商家ID	用户ID	省	市	区
001	电脑	5	00254	00001	河北	石家庄	裕华区

   实际上， 1NF   是所有关系型数据库的最基本要求， 你在关系型数据库管理系统（RDBMS），例如 SQL Server，Oracle，MySQL 中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在 RDBMS 中已经存在的数据表，一定是符合 1NF 的。

②二范式：

二范式（2NF）：在 1NF 的基础上，实体的属性完全函数依赖于主关键字（混合主键）， 不能存在部分函数依赖于主关键字（混合主键）。如果存在某些属性只依赖混合主键中的部分属性，那么不符合二范式

数据表中的所有列，必须依赖于唯一的一个主键。

下图所示不符合二范式表格设计：

学生ID	姓名	所属系	系主任	所修课程	分数
20170901075	王小强	计算机系	马小腾	00001	92
20170901075	王小强	计算机系	马小腾	00002	98

上述表格中是混合主键（学生 ID + 所修课程），但是所属系和系主任这两个属性只依赖于混合主键中的学生 ID 这一个属性，因此，不符合第二范式。

如果有一天学生的所属系要调整，那么所属系和系主任这两列都需要修改，如果这个学生修了多门课程，那么表中的多行数据都要修改，这是非常麻烦的，不符合第二范式。

为了消除这种部分依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表。

下图是符合二范式的表格设计：

学生ID	所修课程	分数
20170901075	00001	92
20170901075	00002	98

系ID	所属系	系主任
00001	计算机系	马小腾
00002	计算机系	马小腾

学生ID	姓名
20170901075	王小强
20170901075	王小强

通过上述的修改，当一个学生的所属系需要调整时，不管学生修了多少门课程，都只需要改变表 中的一行数据即可。

③三范式：

        3NF 在 2NF 的基础之上，消除了非主属性对于主键（复合主键）的传递依赖。

下图是不符合三范式的表格设计：

订单ID	商品ID	商品颜色	商品尺寸	商家ID	用户ID
001	0001	黄色	300*200*40	xxx旗舰店	00001

很明显上图中，商品颜色依赖于商品 ID，商品 ID 依赖于订单 ID，那么非主属性商品颜色就传递依赖于订单 ID，因此不符合三范式，解决方案是将大数据表拆分成两个或者更多个更小的数据表。

数据中只能有唯一的一个主键，外键不能传递依赖于主键。

下图是符合三范式的表格设计：

订单ID	商品ID	商家ID	用户ID
001	0001	xxx旗舰店	00001

商品ID	商品颜色	商品尺寸
300*200*40	xxx旗舰店	00001