1. 范式建模(Inmon范式建模)
范式建模需要在理论上符合3NF : 原子性、唯一性、独立性
数据仓库的3NF和OLTP中的3NF还是有一定的区别的:
关系数据库
中的 3NF 是针对具体的业务流程的实体对象关系抽象
数据仓库
的 3NF 是站在企业角度面向主题的抽象。
接下来我们详细讲解一下三范式的含义和如何将一个不满足三范式的表转换成三范式。
1.1 原子性
定义:存储的数据具有"不可再分性",即不能出现id+name作为一个字段的情况。
学生 | 课程 | 学分 | 成绩 |
---|---|---|---|
张三,男,湖北武汉 | 语文 | 2 | 90 |
李四,女,北京 | 数学 | 4 | 100 |
张三,男,湖北武汉 | 数学 | 4 | 60 |
这里我们发现,在学生列中,可以拆分成三列,为姓名,性别,住址,所以并不满足3NF中的原子性。
解决方案:将学生列拆开成姓名,性别,住址直至不能拆分为止,拆分结果为
姓名 | 性别 | 住址 | 课程 | 学分 | 成绩 |
---|---|---|---|---|---|
张三 | 男 | 湖北武汉 | 语文 | 2 | 90 |
李四 | 女 | 北京 | 数学 | 4 | 100 |
张三 | 男 | 湖北武汉 | 数学 | 4 | 60 |
1.2 唯一性
定义:每一行数据都具有唯一可区分的特征,并不能有部分依赖关系,那么,什么是部分依赖关系呢?
什么是
依赖
?
如果确定一个表中的某个数据(A),则就可以确定该表中的其他另一个数据(B),则我们说:B依赖于A。
什么是部分依赖
?
如果表中有数据组合(A, B),则可确定该表中的其他另一个数据C,则可以说C依赖于(A, B) (此时A,B一般为主键)
但是如果只需要A就可以确定数据C的值,并不需要B的值,那么就可以说C部分依赖于(A, B)
这里举个例子来说明:
组合主键(学生 + 课程) | 学生 | 性别 | 住址 | 课程 | 学分 | 成绩 |
---|---|---|---|---|---|---|
张三-语文 | 张三 | 男 | 湖北武汉 | 语文 | 2 | 90 |
张三-数学 | 张三 | 男 | 湖北武汉 | 数学 | 4 | 100 |
李四-语文 | 李四 | 女 | 北京 | 语文 | 2 | 70 |
这里我们不难发现,学生的性别住址和所选的课程并没有关系,而学分只和课程有关,跟学生没有关系,所以他们部分依赖于主键,那么我们应该怎么让这个表变得满足3NF中的唯一性呢?
解决方案:拆,将只和某一个字段的列拆成另一张表存储,如该案例中,我们可以将性别和住址拆成学生表中,将学分拆成课程表中。(这里我们可以给学生附上一个id,因为数字消耗的存储空间远远小于汉字,这样可以减少资源消耗)
学生id | 学生 | 性别 | 住址 |
---|---|---|---|
1 | 张三 | 男 | 湖北武汉 |
2 | 李四 | 女 | 北京 |
课程id | 课程 | 学分 |
---|---|---|
1 | 语文 | 2 |
2 | 数学 | 4 |
学生id | 课程id | 成绩 |
---|---|---|
1 | 1 | 90 |
1 | 2 | 100 |
2 | 1 | 70 |
这样我们就将这个存在部分依赖的表拆成列三个不含部分依赖的表,这样就满足了3NF中的唯一性。
1.3 独立性
定义:非主键值不能依赖于另一个非主键值。
这里我们也是举个例子来讲解:
学生id | 学生 | 性别 | 住址 | 院系 | 院系电话 |
---|---|---|---|---|---|
1 | 张三 | 男 | 湖北武汉 | 计算机系 | 123 |
2 | 李四 | 女 | 北京 | 化工系 | 234 |
这里我们会发现,院系电话依赖于院系,所以不满足3NF中的独立性,那么,我们应该如何让它满足独立性呢?
解决方案:和唯一性解决方案相似,也是将一个表拆成多个表。
院系id | 院系 | 院系电话 |
---|---|---|
1 | 计算机系 | 123 |
2 | 化工系 | 234 |
学生id | 学生 | 性别 | 住址 | 院系id |
---|---|---|---|---|
1 | 张三 | 男 | 湖北武汉 | 1 |
2 | 李四 | 女 | 北京 | 2 |
至此,我们成功解决了将一个不满足3NF的表转换成多个满足3NF的表,该过程为范式建模的思想。
2. 维度建模(Kimball维度建模)
维度建模,简称DM(Dimensional modeling),数据仓库大师Kimball的观点:维度数据模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术
,是围绕性能和易理解性
构建的。维度模型是按照用户看待或分析数据的角度来组织数据。
对数据进行分析通常采取维度分析,比如:用户提出分析课程访问量的指标,为了满足不同的分析需求可以从时间维度分析课程访问量,分析每天、每小时的课程访问量;也可以从课程维度来分析课程访问量,分析每个课程、每个课程分类的访问量。
Kimball 模型从流程上看是自下而上的,即从数据集市-> 数据仓库 -> 分散异构的数据源。Kimball 是以最终任务为导向,将数据按照目标拆分出不同的表需求,数据会抽取为事实-维度模型,数据源经 ETL 转化为事实表和维度表导入数据集市,以星型模型或雪花模型等方式构建维度数据仓库,架构体系中,数据集市与数据仓库是紧密结合的,数据集市是数据仓库中一个逻辑上的主题域。
3. 范式建模和维度建模的相同点
- 均极力推崇数据仓库,认为从OLTP到BI分析之间建立数据仓库是很有必要的;
- 均认为数据仓库的建立需要从企业整体角度出发,迭代开发,尽量避免按部门建立独立的数据仓库;
- 数据进入数据仓库之前,需要经过ETL整合。
- 两者都强调数据质量的重要性,因为数据质量直接影响到决策分析的准确性。
4. 范式建模和维度建模的不同点
Inmon理论:
- 结构:也被称为企业数据仓库模式,自上而下按照主题建立数据仓库,主张首先构建一个集中化、标准化、集成化的企业级数据仓库,然后从这个企业数据仓库中提取数据生成各个部门所需的数据集市。如按照客户、供应商、产品等建立不同的主题。当建立的数据集市是跨多个主题的,需要以整合好的主题数据为基础。
- 实施步骤和时间:Inmon模式的实施通常需要比较长的时间,因为需要先创建企业数据仓库,然后再创建数据集市。
- 数据模型:倾向于使用第三范式的数据模型,以确保数据的一致性和减少数据冗余。
KimBall理论:
- 结构:自下而上,主张直接创建一个或多个针对特定业务过程的数据集市,这些数据集市可以独立存在,也可以通过共享一些维度数据而逻辑集成起来;
- 实施步骤和时间:倾向于迭代开发和快速交付,一次创建一个数据集市,逐步完善和集成。先按照业务主线建立最小粒度的事实表,再建立维度表,形成数据集市,通过“一致维度”能够共同查询不同数据集市的信息;
- 数据模型:倾向于使用星型模式或雪花模式,以优化查询性能。