目录
数据仓库分层概念为什么要分层？
数据集市和数据仓库概念
数据仓库命名约定
表命名
Ø ODS层命名为ods_表名
Ø DWD层命名为/ name
Ø DWS层命名为 name
Ø DWT层命名为 cart
Ø ADS层命名为ads_表名
Ø 临时表命名为
Ø 用户行为表，后缀为log。
脚本命名
Ø 数据源/log.sh
Ø 用户行为脚本以log为后缀； 业务数据脚本以db为后缀。
1. 定义
范式可以理解为设计一个数据表的表结构，符合标准级别。 规格和要求
2、优点
在设计关系数据库时，遵循一定的规范要求，以减少数据冗余。
为什么要减少数据冗余？
(1)十多年前，磁盘非常昂贵，为了减少磁盘存储。
（2）以前没有分布式系统电商数据统计，都是单机的。 只能添加磁盘，且磁盘数量也有限制。
(3) 一次修改，需要修改多张表，难以保证数据一致性
3、缺点
范式的缺点是在获取数据时，需要通过Join来拼接出最终的数据。
4. 分类
当前的行业范式有：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、Bath-Codd范式（BCNF）、第四范式（4NF）和第五范式（5NF） 。
函数依赖
三种范式
关系建模与维度建模
如今的数据处理大致可以分为两类：在线事务处理OLTP（On-Line）、在线分析处理OLAP（On-Line）。 OLTP是传统关系型数据库的主要应用，主要用于基础的、日常的事务处理，比如银行交易。 OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重于决策支持，提供直观易懂的查询结果。 两者的主要区别如下表所示。
关系建模
如图所示，关系模型严格遵循第三范式（3NF）。 从图中可以看出，比较松散、碎片化，物理表数量较多，数据冗余度较低。 由于数据分布在很多表中，这些数据可以更灵活地应用，并且具有更强的功能。 关系模型主要应用于OLTP系统中。 为了保证数据的一致性，避免冗余，大多数业务系统中的表都遵循第三范式。
如图所示，维度模型主要应用于OLAP系统中。 通常以某个事实表为中心来组织表。 它主要是面向商业的。 特点是可能存在数据冗余，但数据容易获取。
关系模型虽然冗余度较小，但在大规模数据、跨表分析和统计查询过程中，会造成多表关联，从而大大降低执行效率。 因此，我们通常使用维度模型将相关表建模并组织为两种类型：事实表和维度表。
维度建模
在维度建模的基础上，分为星型模型、雪花模型、星座模型三种模型。
维度表：一般是事实的**描述性信息**。 每个维度表对应现实世界中的一个对象或概念。
例如：用户、产品、日期、地区等。
Ø 维度表范围广泛（具有多个属性和列）
Ø 与事实表相比，行数比较少：通常 Ø 内容相对固定：编码表
时间维度表：
概况介绍
事实表中的每一行数据代表一个业务事件（订单、付款、退款、审核等）。 术语“事实”是指业务事件的计量值（可计数次数、次数、件数、金额等），例如订单事件中的订单金额。
每个事实表的行包括：附加数值度量、连接到维度表的外键（通常具有两个或多个外键）以及维度表之间的外键。 一对多关系。
事实表的特点：
Ø 非常大
Ø 内容相对狭窄：栏目较少
Ø 变化频繁，每天都会增加很多新的。
(1)交易事实表
将每笔交易或事件作为一个单元**，比如一条销售订单记录、一条付款记录等，作为事实表中的一行数据。 一旦事务提交并插入事实表数据，数据将不再改变，更新方式为增量更新。
(2) 定期快照事实表
定期快照事实表不会保留所有数据电商数据统计，而只会保留固定时间间隔的数据，例如每日或每月的销售额，或每月的帐户余额。
(3)累积快照事实表
累积快照事实表用于跟踪业务事实的更改。 例如，数据仓库可能需要积累或存储订单从下单到订单打包、发货、签收的各个业务阶段的时间点数据，以跟踪订单的情况。订单申报周期的进度。 当这个业务流程进行时，事实表中的记录也在不断更新。
数据仓库建模（绝对焦点）ODS层
(1)保持数据原貌不做任何修改，起到备份数据的作用。
（2）数据经过压缩，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
（3）创建分区表，防止后续全表扫描
DWD层
DWD层需要建立维度模型，一般采用**星模型，呈现的状态一般是星座模型。
维度建模一般遵循以下四个步骤：
选择业务流程→申报粒度→确认维度→确认事实
(1)选择业务流程
在业务系统中选择我们感兴趣的业务线，比如下单业务、支付业务、退款业务、物流
对于业务来说，一条业务线对应一张事实表。
未经允许不得转载：新动力营销圈 » 电商数仓-(数仓分层概念+数仓理论)
