个人理解：只看某个业务过程，比如订单收货，数据按订单收货时间来切分，周期可以为每天、每月等。
- 1.3 累积快照事实
用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点；当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改；
个人理解：要看整个生命周期的多个业务过程，比如：创建订单 → 买家付款 → 卖家发货 → 买家确认收货。粒度是一个订单一行数据，创建订单时间，付款时间，发货时间，收货时间，分别作为一个字段，便于计算不同业务过程的时间间隔。
2、三种事实表对比
事务事实表 | 周期快照事实表 | 累积快照事实表 | |
时期/时间 | 离散事务时间点 | 以有规律的、可预测的 | 用于时间跨度不确定的不断变化的工作流 |
日期维度 | 事务日期 | 快照日期 | 相关业务过程涉及的多个日期 |
粒度 | 每行代表实体的一个事务 | 每行代表某时间周期的一个实体 | 每行代表一个实体的生命周期 |
事实 | 事务事实 | 累积事实 | 相关业务过程事实和时间间隔事实 |
事实表加载 | 插入 | 插入 | 插入与更新 |
事实表更新 | 不更新 | 不更新 | 业务过程变更时更新 |
3、事实表设计 8 大原则
-
原则 1**：尽可能包含所有与业务过程相关的事实**
-
分析哪些事实与业务过程相关，是设计过程中非常重要的关注点；
-
在事实表中，尽量包含所有与业务过程相关的事实，即使存在冗余，由于事实通常是数字型，存储开销不会太大；
-
原则 2**：只选择与业务过程相关的事实**
-
如，订单的下单这个业务过程，事实表中不应该存在支付金额这个表示支付业务过程的事实；
-
原则 3**：分解不可加性事实为可加的组件**
-
如，订单的优惠率，应分解为订单原价金额与订单优惠金额两个事实存储在事实表中；
-
原则 4**：在选择维度和事实之前必须先声明粒度**
-
因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求；
-
粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性；
-
每个维度和事实必须与所定义的粒度保持一致；
-
设计事实表时，粒度定义越细越好，一般从最低级别的原子粒度开始；
-
原则 5**：在同一个事实表中不能有多种不同粒度的事实**
-
粒度为票一级；（实际业务中，一个订单可以同时支付多张票）
-
票支付金额和票折扣金额，两个事实的粒度为 “票级”，与定义的粒度一致；
-
订单支付金额和订单票数，两个事实的粒度为 “订单级”，属于上一层订单级数据，与 “票级” 事实表的粒度不一致，且不能进行汇总；
-
如果，以订单金额和订单票数这两个维度汇总总金额和总票数，会造成大量的重复计算；
-
疑问：怎么判断不同事实的粒度是否相同？
-
原则 6**：事实的单位要保持一致**
-
如，订单金额、订单优惠金额、订单运费这 3 个事实，应该采用统一的计量单位，统一为元或者分，以方便使用；
-
原则 7**：对事实的** null 值要处理
-
原因：在数据库中，null 值对常用数字型字段的 SQL 过滤条件都不生效；如，大于、小于、等于、大于或等于、小于或等于；
-
处理：用 0 代替 null ；
-
原则 8**：使用退化维度提高事实表的易用性**
-
易用性：对事实表，更较少关联操作、过滤查询、控制聚合层次、排序数据、定义主从关系等；
-
- 事实表中存储各种类型的常用维度信息，较少下游用户使用时关联多个表的操作；
-
通过退化维度，可以实现对事实表的过滤查询、控制聚合层次、排序数据、定义主从关系等；
-
在 Kimball 的维度建模中，通常按照星形模型的方式设计，通过事实表的外键关联专门的维表，这种方式来获取维度，谨慎使用退化维表；这与大数据领域的事实表设计不一样；
-
思路：通过增加冗余存储，减少计算开销，提高使用效率；
4、事实表设计方法
Kimball 的维度模型设计 4 步法：选择业务过程、声明粒度、确定维度、确定事实；
当前的互联网大数据环境，维度模型的设计，是基于 Kimball 的四步维度建模方法进行了更进一步的改进：
-
第一步：选择业务过程及确定事实表类型
-
如淘宝的一个交易订单，选择 “买家付款” 这个业务过程，则事实表类型应为只包含买家付款这一个业务过程的 “单事务事实表”；
-
如选择了所有 4 个业务过程，并且需要分享各业务过程的时间间隔，则事实表类型应为包含了所有 4 个业务过程的 “累积快照事实表”；
-
如是选择 “买家付款” 这个业务过程，还是选择 “创建订单” 和 “买家付款” 这两个业务过程，具体根据业务情况来定；
-
思路：详细分析需求，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程；
-
以实例说明：如何选择业务过程？如何确定事实表类型？
-
- 分析业务的生命周期，业务过程通常使用行为动词表示业务执行的活动；
-
明确关键的业务步骤：该订单流转的业务过程有 4 个：创建订单 → 买家付款 → 卖家发货 → 买家确认收货；
-
根据业务需求，选择与维度建模有关的业务过程；
-
根据所选的业务过程确定事实表类型；
-
第二步：声明粒度
-
粒度的作用：
-
粒度的选择：尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性；
-
- 灵活性：支持无法预期的各种细节层次的用户需求；
-
对于订单级别，粒度可以定义为最细的订单级别；（如，父子订单，事实表的粒度可以定 “子订单级别” ；）
-
粒度的声明，意味着精确定义事实表的每一行所表示的业务含义；
-
明确的粒度能够确保对实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录；
-
第三步：确定维度
-
如，淘宝订单 “付款事务事实表” 中，粒度为 “子订单”，相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等；
-
完成了粒度声明，就意味着确定了主键，对应的维度组合以及相关的维度字段也可以确定了；
-
选择维度的原则：应该选择能够描述清楚业务过程所处的环境的维度信息；
-
第四步：确定事实
-
确定原则：选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致；
-
思路：可以通过回答 “过程的度量是什么” 来确定；
-
注意：将不可加性事实分解为可加的组件；（分解的原则：可以通过分解后的可加的属性值，计算得到不可加性事实）
四、多维体系结构
在Kimball的维度建模的数据仓库中，关于多维体系结构（MD）有三个关键性概念：总线架构（Bus Architecture），一致性维度（Conformed Dimension）和一致性事实（Conformed Fact）。
1、总线架构
多维体系结构(总线架构) 数据仓库领域里，有一种构建数据仓库的架构，叫Multidimensional Architecture（MD），中文一般翻译为“多维体系结构”，也称为“总线架构”（Bus Architecture）。
多维体系结构的创始人是数据仓库领域中最有实践经验的Kimball博士。多维体系结构主要包括后台（Back Room）和前台（Front Room）两部分。后台也称为数据准备区（Staging Area），是MD架构的最为核心的部件。在后台，是一致性维度的产生、保存和分发的场所。同时，代理键也在后台产生。前台是MD架构对外的接口，包括两种主要的数据集市，一种是原子数据集市，另一种是聚集数据集市。
原子数据集市保存着最低粒度的细节数据，数据以星型结构来进行数据存储。聚集数据集市的粒度通常比原子数据集市要高，和原子数据集市一样，聚集数据集市也是以星型结构来进行数据存储。前台还包括像查询管理、活动监控等为了提供数据仓库的性能和质量的服务。在多维体系结构中，所有的这些基于星型机构来建立的数据集市可以在物理上存在于一个数据库实例中，也可以分散在不同的机器上，而所有这些数据集市的集合组成的分布式的数据仓库。
2、一致性维度
在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。
一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。 一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。
在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。
在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。
例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。
3、一致性事实
在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。
为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点：**第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。**如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。
这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。
小遍有话
-
总线矩阵：业务过程和维度的交点；
-
一致性维度：同一集市的维度表，内容相同或包含；
-
一致性事实：不同集市的同一事实，需保证口径一致，单位统一。
追求一致性必然会增加开发工作量，但长期来说，使用方便、运维简单；一致性和性能之间，需要平衡。
五、数据仓库规范设计
1、为什么要进行规范设计
无规矩、不方圆。规范设计是在具体开发工作之前制定的，过程中不断进行完善。目的在于约束 N 个人对齐认知，按照一个标准或流程进行开发，以保证数据一致性，流程清晰且稳定。
一个良好的规范设计，应当起到以下作用：提高开发效率，提升质量，降低沟通对齐成本，降低运维成本等。
下面西红柿🍅将带领大家盘一盘数据仓库有哪些规范，从中挑选几个重点细说：
- 设计规范
逻辑架构、技术架构、分层设计、主题划分、方法论
- 命名规范
各层级命名、任务命名、表命名、字段命名、指标命名等
- 模型规范
建模方法、建模工具、血缘关系、维度退化、一致性维度、元数据管理
- 开发规范
脚本注释、字段别名、编码规范、脚本格式、数据类型、缩写规范
- 流程规范
需求流程、工程流程、上线流程、调度流、调度和表生命周期管理
2、设计规范 - 指标
- Step1**：面向主题域管理**
为了提高指标管理的效率，你需要按照业务线、主题域和业务过程三级目录方式管理指标。
- Step2**：划分原子指标和派生指标**
原子指标 + 原子指标 = 派生指标
- Step3**：进行指标命名规范**
需要遵循两个原则：易懂与统一
-
易懂，就是看到指标的名称，就可以基本判断这个指标归属于哪个业务过程；
-
统一，就是要确保派生指标和它继承的原子指标命名是一致的。
对于原子指标，标名称适合用“动作 + 度量”的命名方式（比如注册用户数、购买用户数）
对于派生指标，应该严格遵循“时间周期 + 统计粒度 + 修饰词 + 原子指标”的命名方式。（比如30天内黑卡会员购买用户数）
- Step4**：分级管理**
指标确实是多，如果一视同仁去管理其实很难，所以可以按照下面的原则进行等级划分：
-
一级指标：数据中台直接产出，核心指标（提供给公司高层看的）、原子指标以及跨部门的派生指标。
-
二级指标：基于中台提供的原子指标，业务部门创建的派生指标。
3、命名规范 - 表命名
3.1 常规表
常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去完善的表。
规范：分层前缀**[dwd|dws|ads|bi]_业务域_主题域_XXX_更新频率|全量/**增量。
业务域、主题域我们都可以用词根的方式枚举清楚，不断完善，粒度也是同样的，主要的是时间粒度、日、月、年、周等，使用词根定义好简称。
建议格式： dwd_xxx_xxx_da
-
di ：每日增量
-
da：每日全量
-
mi：每月增量
-
ma：每月全量
3.2 中间表
中间表一般出现在Job中，是Job中临时存储的中间数据的表，中间表的作用域只限于当前Job执行过程中，Job一旦执行完成，该中间表的使命就完成了，是可以删除的（按照自己公司的场景自由选择，以前公司会保留几天的中间表数据，用来排查问题）。
**建议格式：**mid_table_name_[0~9]
table_name是我们任务中目标表的名字，通常来说一个任务只有一个目标表。这里加上表名，是为了防止自由发挥的时候表名冲突，而末尾大家可以选择自由发挥，起一些有意义的名字，或者简单粗暴，使用数字代替，各有优劣吧，谨慎选择。
3.3 临时表
临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表。
**建议格式：**tmp_xxx
只要加上tmp开头即可，其他名字随意，注意tmp开头的表不要用来实际使用，只是测试验证而已。
3.4 维度表
维度表是基于底层数据，抽象出来的描述类的表。维度表可以自动从底层表抽象出来，也可以手工来维护。
**建议格式：**dim_xxx
维度表，统一以dim开头，后面加上，对该指标的描述，可以自由发挥。
4、开发规范
1 | 表和列的注释释是否有缺失，复杂计算逻辑是否有注释释 |
2 | 任务是否支持多次重跑而输出不变，不能有insert into语句 |
3 | 分区表是否使用分区键过滤并且有有效裁剪 |
4 | 外连接的过逑条件是否使用正确，例如在左连接的where语句存在右表的过滤条件 |
5 | 关联小表，是否使用/*+ map join * / hint |
6 | 不允许引用别的计算任务临时表 |
7 | 原则上不允许存在一个任务更新多个目标表 |
8 | 是否存在笞、迪卡尔积 |
9 | 禁止在代码里面使用drop 111ble、creat它111ble、renaiue 111ble、chan零column等ddl语句 |
10 | 使用动态分区时，有没有检查分区键值为NULL的情况 |
11 | DQC质量监控规则是否配置，严禁棵奔 |
12 | 代码中有没有进行适当的规避数据倾斜语句 |
13 | Where条件中is null语句有没有进行空字符串处理 |
5、流程规范
根据阿里流程规范，本文将数据仓库研发流程抽象为如下几点：
-
需求阶段：数据产品经理应如何应对不断变化的业务需求。
-
设计阶段：数据产品经理、数据开发者应如何综合性能、成本、效率、质量等因素，更好地组织与存储数据。
-
开发阶段：数据研发者如何高效、规范地进行编码工作。
-
测试阶段：测试人员应如何准确地暴露代码问题与项目风险，提升产出质量。
-
发布阶段：如何将具备发布条件的程序平稳地发布到线上稳定产出。
-
运维阶段：运维人员应如何保障数据产出的时效性和稳定性。
六、元数据管理
1、业务元数据
-
描述 ”数据”背后的业务含义
-
主题定义：每段 ETL、表背后的归属业务主题。
-
业务描述：每段代码实现的具体业务逻辑。
-
标准指标：类似于 BI 中的语义层、数仓中的一致性事实；将分析中的指标进行规范化。
-
标准维度：同标准指标，对分析的各维度定义实现规范化、标准化。
-
不断的进行维护且与业务方进行沟通确认。
2、技术元数据
-
数据源元数据
-
例如：数据源的 IP、端口、数据库类型；数据获取的方式；数据存储的结构；原数据各列的定义及 key 指对应的值。
-
ETL 元数据
-
根据 ETL 目的的不同，可以分为两类：数据清洗元数据；数据处理元数据。
-
数据清洗，主要目的是为了解决掉脏数据及规范数据格式；因此此处元数据主要为：各表各列的"正确"数据规则；默认数据类型的"正确"规则。
-
数据处理，例如常见的表输入表输出；非结构化数据结构化；特殊字段的拆分等。源数据到数仓、数据集市层的各类规则。比如内容、清理、数据刷新规则。
-
数据仓库元数据
-
数据仓库结构的描述，包括仓库模式、视图、维、层次结构及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式等。
-
BI 元数据
-
汇总用的算法、包括各类度量和维度定义算法。数据粒度、主题领域、聚集、汇总、预定义的查询与报告。
3、管理元数据
管理领域相关，包括管理流程、人员组织、角色职责等。
4、小编有话
在日常工作中，元数据的管理主要体现在元数据的采集、存储、查询、应用几个方面。原则上应从规范化，到脚本化，到工具化的方向进行建设。
-
采集：元数据采集时尽可能详细，真实，可通过工具生成或者勾选，避免手动录入带来不规范等问题
-
存储：存储元数据要做到不失真，元数据变更时及时同步
-
查询：通过网页或库表等方式，方便快捷的看到元数据，辅助进行开发
-
应用：数据血缘、优化调度依赖、数据治理等
七、维度表
1、什么是维度表
维度是维度建模的基础和灵魂。在维度建模中，将度量称为“事实” ， 将环境描述为“维度”。
维度表包含了事实表中指定属性的相关详细信息，最常用的维度表有日期维度、城市维度等。
日期维表：
num | 字段名 | 字段中文名 | 描述 | 数据类型 |
1 | date | 日期 | 日期 yyyMMdd格式 | bigint |
2 | week | 星期，数字型 | 星期，数字型 0-6 | bigint |
3 | week_cn | 星期中文名 | 星期中文名 星期一…… | string |
4 | year_weeks | 一年中的第几周 | 一年中的第几周 1 2 3…… | bigint |
5 | mon_dt | 本周周一日期 | 本周周一日期 | bigint |
6 | sun_dt | 本周周日日期 | 本周周日日期 | bigint |
7 | month | 年月 | 年月，yyyyMM格式 | bigint |
8 | month_short | 月份简写 | 月份简写，MM格式1~12 | bigint |
9 | month_cn | 月份中文名 | 月份中文名 一月…… | string |
10 | quarter | 季度 | 季度，yyyyQ1\2\3\4 | string |
11 | quarter_short | 季度 数字型 | 季度 数字型 1-4 | bigint |
12 | quarter_cn | 季度中文名 | 季度中文名 第一季度…… | string |
13 | year | 年份 | 年份，yyyy格式 | bigint |
2、维度表设计原则
维度的作用一般是查询约束、分类汇总以及排序等，我们在进行维度表设计时，应当提前考虑：
（1）维度属性尽量丰富，为数据使用打下基础
比如淘宝商品维度有近百个维度属性，为下游的数据统计、分析、探查提供了良好的基础。
（2）给出详实的、富有意义的文字描述
属性不应该是编码，而应该是真正的文字。在间里巴巴维度建模中， 一般是编码和文字同时存在，比如商品维度中的商品 ID 和商品标题、 类目 ID 和 类目名称等。ID 一 般用于不同表之间的关联，而名称一般用 于报表标签
（3）区分数值型属性和事实
数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或分组统计，则是作为维度属性;如果通常 用于参与度量的计算， 则是作为事实。比如商品价格，可以用于查询约 束条件或统计价格区间 的商品数量，此时是作为维度属性使用的;也可 以用于统计某类目 下商品的平均价格，此时是作为事实使用的。另外， 如果数值型字段是离散值，则作为维度属性存在的可能性较大;如果数 值型宇段是连续值 ，则作为度量存在的可能性较大，但并不绝对，需要 同时参考宇段的具体用途。
（4）沉淀出通用的维度属性，为建立一致性维度做好铺垫
有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表 的不同宇段混合处理得到，或者通过对单表 的某个字段进行解析得到。此时，需要将尽可能多的通用的维度属性进 行沉淀。一方 面，可以提高下游使用的方便性，减少复杂度;另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不 一致。
（5）退化维度（Degenerate Dimension）
在维度类型中，有一种重要的维度称作为退化维度。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。
（6）缓慢变化维（Slowly Changing Dimensions）
维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD），缓慢变化维一般使用代理健作为维度表的主健。
推荐阅读**：**缓慢变化维度的10种处理方式****
缓慢变化维的三种常用处理方式：
① TYPE1 直接覆盖原值
适用于：不看历史数据，简单粗暴
② TYPE2 拉链表
需要在维度行再增加三列：有效日期、截止日期、行标识（可选）。
在旧的一行数据增加关链时间（end_date），新的一行数据增加开链时间和**关链时间，**多条数据加起来是一个完整的时间周期。
③ TYPE3 增加属性列
3、维度表设计方法
-
第一步：选择维度或新建维度。作为维度建模的核心，在企业级数 据仓库中必须保证维度的唯一性。以淘宝商品维度为例，有且只允许有 一个维度定义。
-
第二步：确定主维表。此处的主维表一般是 ODS 表，直接与业务 系统同步。以淘宝商品维度为例， s_auction_auctions 是与前台商品中心 系统同步的商品表，此表即是主维表。
-
第三步：确定相关维表。数据仓库是业务源系统的数据整合，不同业务系统或者同 一业务系统中的表之间存在 关联性。根据对业务的梳 理，确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。
-
第四步 ：确定维度属性 。本步骤主要 包括两个阶段，其中第 一 个阶 段是从主维表 中选择维度属性或生成新的维度属性;第 二个阶段是从相 关维表中选择维度属性或生成新 的维度属性。以淘宝商品维度为例，从 主维表 (s_auction_auctions)和类目、 SPU、卖家、店铺等相关维表中 选择维度属性或生成新 的维度属性。
八、三范式与反范式
范式是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。
关系数据库中的关系必须满足一定的要求，即满足不同的范式。大数据生态中，各类强大的查询引擎层出不穷，相对廉价的磁盘和分布式技术，也让数据冗余变得可接受甚至更加方便。
在创建一个数据库的过程中，范化是将其转化为一些表的过程，这种方法可以使从数据库得到的结果更加明确。这样可能使数据库产生重复数据，从而导致创建多余的表。范化是在识别数据库中的数据元素、关系以及定义所需的表和各表中的项目等这些初始工作之后的一个细化的过程。
1、第一范式
1NF****要求属性具有原子性，即列不可再分解；
表：字段1、 字段2(字段2.1、字段2.2)、字段3 …
如学生（学号，姓名，性别，出生年月日）
有些钢筋可能要问西红柿了，姓名可以拆成姓、名两列， “出生年月日” 也可以拆成年、月、日三个字段。所以就不满足第一范式了！！！这里再强调一下原子性，原子性是根据使用方便来自定义的最小单位。中国人一般姓名一起用，美国就习惯姓名分别存两字段。
2、第二范式
2NF****要求记录有惟一标识，即不存在部分依赖；
简单来说就是拆表，以人为粒度做一张明细表，以课程号为粒度做一张维度表，两表关联使用，消除了数据冗余
表：学号、课程号、姓名、学分;
这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖与学号，所以不符合二范式。
可能会存在问题：
-
数据冗余：每条记录都含有相同信息；
-
删除异常：删除所有学生成绩，就把课程信息全删除了；
-
插入异常：学生未选课，无法记录进数据库；
-
更新异常：调整课程学分，所有行都调整。
正确做法**😗*
学生：Student(学号, 姓名)；
课程：Course(课程号, 学分)；
选课关系：StudentCourse(学号, 课程号, 成绩)。
3、第三范式
3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；
表: 学号, 姓名, 年龄, 学院名称, 学院电话
因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。
可能会存在问题：
-
数据冗余:有重复值；
-
更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。
正确做法：
学生：(学号, 姓名, 年龄, 所在学院)；
学院：(学院, 电话)。
4、反范式化
一般说来，数据库只需满足第三范式（3NF）就行了。
没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。
〖例〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。
5、范式化设计和反范式化设计的优缺点
5.1 范式化 （时间换空间）
优点：
- 范式化的表减少了数据冗余，数据表更新操作快、占用存储空间少。
缺点：
-
查询时需要对多个表进行关联，查询性能降低。
-
更难进行索引优化
5.2 反范式化（空间换时间）
反范式的过程就是通过冗余数据来提高查询性能，但冗余数据会牺牲数据一致性
优点：
-
可以减少表关联
-
可以更好进行索引优化
缺点：
-
存在大量冗余数据
-
数据维护成本更高（删除异常，插入异常，更新异常）
6、OLAP和OLTP中范式设计
OLAP 一般冗余比较多，以查询分析为主，这种一般都是采用反范式设计，以提高查询效率。更新一般是定时大批量数据插入。
OLTP 则是尽可能消除冗余，以提高变更的效率。因为这种应用无时无刻不在频繁变化。
九、数据仓库架构-Lambda和Kappa
随着数据量的暴增和数据实时性要求越来越高，以及大数据技术的发展驱动企业不断升级迭代，数据仓库架构方面也在不断演进，分别经历了以下过程：早期经典数仓架构 > 离线大数据架构 > Lambda > Kappa > 混合架构。
|
架构
|
组成
|
特点
|
| — | — | — |
|
经典数仓架构
|
关系型数据库（mysql、oracle）为主
|
数据量小，实时性要求低
|
|
离线大数据架构
|
hive，spark为主
|
数据量大，实时性要求低
|
|
Lambda
|
hive，spark负责存量，strom/Flink负责实时计算
|
数据量大，实时性要求高
|
|
Kappa
|
kafka、strom、Flink
|
多业务，多数据源，事件型数据源
|
|
混合架构
| | |
_ps._西红柿的举例若有不当，欢迎指正
1、Lambda架构原理
Lambda架构的核心思想是把大数据系统拆分成三层：Batch Layer，Speed Layer和Serving Layer。其中，Batch Layer负责数据集存储以及全量数据集的预查询。
Speed Layer主要负责对增量数据进行计算，生成Realtime Views。Serving Layer用于响应用户的查询请求，它将Batch Views和Realtime Views的结果进行合并，得到最后的结果，返回给用户，如下图：
2、Lambda架构的缺点
Lambda架构解决了大数据量下实时计算的问题，但架构本身也存在一定缺点。
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。
深知大多数Python工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Python开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Python开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024c （备注Python）
最后
🍅 硬核资料：关注即可领取PPT模板、简历模板、行业经典书籍PDF。
🍅 技术互助：技术群大佬指点迷津，你的问题可能不是问题，求资源在群里喊一声。
🍅 面试题库：由技术群里的小伙伴们共同投稿，热乎的大厂面试真题，持续更新中。
🍅 知识体系：含编程语言、算法、大数据生态圈组件（Mysql、Hive、Spark、Flink）、数据仓库、Python、前端等等。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！**
因此收集整理了一份《2024年Python开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。
[外链图片转存中…(img-gjsMvjzC-1712530362843)]
[外链图片转存中…(img-yRRgrrOY-1712530362844)]
既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Python开发知识点，真正体系化！
由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新
如果你觉得这些内容对你有帮助，可以添加V获取：vip1024c （备注Python）
[外链图片转存中…(img-29FNZdSw-1712530362845)]
最后
🍅 硬核资料：关注即可领取PPT模板、简历模板、行业经典书籍PDF。
🍅 技术互助：技术群大佬指点迷津，你的问题可能不是问题，求资源在群里喊一声。
🍅 面试题库：由技术群里的小伙伴们共同投稿，热乎的大厂面试真题，持续更新中。
🍅 知识体系：含编程语言、算法、大数据生态圈组件（Mysql、Hive、Spark、Flink）、数据仓库、Python、前端等等。
一个人可以走的很快，但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎扫码加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
[外链图片转存中…(img-eRGsGSK3-1712530362846)]
432
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
