6（第五章，数据建模与设计）

最新推荐文章于 2024-05-26 18:10:17 发布

承缘丶

最新推荐文章于 2024-05-26 18:10:17 发布

阅读量719

点赞数 26

分类专栏：数据管理文章标签： DAMA 数据建模

本文链接：https://blog.csdn.net/qq_30168227/article/details/138156886

版权

数据管理专栏收录该内容

22 篇文章 0 订阅

订阅专栏

概述

数据建模就是建表，然后存数据。我们常说的存储成本、性能好坏就是收到建模好坏的影响。

数据建模最常见的6种方式是：关系模式、多维模式、面向对象模式、事实模式、时间序列模式、NoSQL模式。

每种模式又分为3层模型：概念模型、逻辑模型、物理模型。这三层模型，概念模型和逻辑模型是业务的，包括下面所说的实体有什么，一个实体有哪些属性，这些如果要盘的话，是需要业务方来回答的，物理模型是技术的；概念和逻辑模型是数据架构的产物，而物理模型是数据建模的产物。

每种模型都包含一系列的组件：实体、关系、事实、键、属性、域。

基本概念

数据模型组件

实体

在数据建模之外的概念中，实体（Entity）的定义是有别于其他事物的一个事物。在数据建模概念里，实体是一个组织收集信息的载体。实体有时被称为组织的一组名词。一个实体可以被认为是一些基本问题的答案一谁、什么、何时、何地、为什么、怎么办或这些问题的综合。下表定义并给出了常用实体类别的例子：

关系与关系的基数

关系是实体之间的关联，关系捕获概念实体之间的高级别交互、逻辑实体之间的详细交互以及物理实体之间的约束。

关系的基数：在两个实体之间的关系中，基数说明了一个实体（实体实例）和其他实体参与建立关系的数量。对于基数而言，只能选择0、1、多（“多”的意思是超过“1”个）。

属性与标识符

属性是一种定义、描述或者度量实体某方面的性质，属性可能包含域。

上面的解释其实不好理解，例如“姓名”，其实就是两个属性，一个是“姓”，一个是“名”，因为属性需要原子性。

标识符：也成为键，是唯一标识实体实例的一个或多个属性的集合。其实也不好理解，其实就是例如主键，更规范些其实按照结构和功能来分，搞过数仓的应该都很清晰。

按结构分：单一键、组合键、复合键、代理键。

按功能分：候选键、主键、备用键。

比较常用的备注：自然键：指有业务意义的唯一ID，例如用户ID、身份证号等。代理键：可以简单理解为该表的自增ID值或者例如UUID。

域

域代表了某一属性被赋予的全部可能取值。之前文章SQL基础那块，有说过域的具体使用。

域提供了一种将属性特征标准化的方法，例如日期域，包含所有的可能的日期，可以适用于任何逻辑数据模型或者物理数据模型中日期属性，例如课程开始的日期、收到订单的日期等。

域中所有的值都是有效的值，不在域中的值被称为无效的值，其实具体应用例如数据库的Check。

域的定义方式：

数据建模的方法

上面说了6中常用的数据建模方法，每种建模方法都有特定的表示法能进行表达：

其中我们来看看我们有一个方案中的图：

维度建模-SCD缓慢变化维

在实际数仓建设中，维度建模用的还是很多的，下来可以具体了解了解，这里重点说下SCD（Slow Changing Dimension），即缓慢变化维的解决办法，书上是这样的：

我们展开来看看：

什么是维度与什么是SCD

要清楚什么是SCD，要先清楚什么是维度。

在数据仓库的DW层中，表根据用途往往会分为2个类型：事实表和维度表。
书上解释的也比较“让人不想去细看”，我们这里举一个例子，如果我们要描述一个销售过程：
小王在2024年4月24日下午2点在上海林肯卖了两辆车，每辆车30万人民币，总60万人民币。
这里面事实有：这个销售过程、单价、数量、总价；
维度有：人（小王）、卖出去的时间日期、店的区域地址、车类型、货币类型等。
即时间地点是维度，卖了什么多西多少钱是事实。

缓慢变化维：
正如上述，我们将分析的各种角度，存放在维度表中。但是也很好想象，维度里的数据是肯定发生一些变化，尽管可能时间跨越很久。例如：

1、客户的性别变更（系统数据录入方面的），可能在第一次登陆中，我们得到的信息是该客户性别为男。但在下一次客户再一次使用中，我们又得到该客户的性别为女。这就是维度值的一种变化可能，性别一般并不会改变，所以大概率是其中的一次数据有误。也有可能是做了变性手术。
2、雇员的部门更替，雇员小王从销售调岗，成为运营组的一员，title肯定会发生变化，这也是缓慢变化维的一种常见可能。

上面提到的这些数据变化，业务系统（CRM、OA等）一般不会保留历史数据。但在分析、审计角度，我们需要保留这些改变的过程。这种随着时间可能会缓慢变化的维度，就是缓慢变化维，也就是SCD（Slowly Changing Dimensions）。

SCD常见的处理方法

就是上面截图的，常用的三种解决方式，下面三种时常用、基本的方式，当然还会有其他的方式，有理论的一般是8种：

1、覆盖

类型1，即重写那条数据，与业务数据保持一致，直接update为最新的数据。
这种方法主要应用于以下两种情况：

数据必须正确——例如用户的身份证号，如需要更新则说明之前录入错误。
无需考虑历史变化的维度——例如用户的头像Url，这种数据往往并没有分析的价值，因此不做保留。

这种处理方式的优点：

简化了开发ETL，直接update即可。
节省了存储空间，另外几种方式都会额外占用一些空间。

缺点：

无法保留历史痕迹。

2、新行

类型2，即对这条数据增加一行，更新那条老数据的时间戳，新增新行记录新值。这种方法主要用于仅需要保存历史数据的业务场景，具体的ETL如下：

自然键第一次出现：
新增一行数据，created为业务系统的创建时间，updated为9999-12-31。

类型2的维度发生变化时，将自然键当前记录的updated由9999-12-31刷为当前时间，然后新增一行记录，记录最新的数据，created为最新时间，updated又搞为9999-12-31。

即由：

id    name    create_time    update_time
1    小王    2024-04-23    9999-12-31

变成了：

id    name    create_time    update_time
1    小王    2024-04-23    2024-04-24
1    小刘    2024-04-24    9999-12-31

这样一来，因为事实表存储的是维度表的代理键而非自然键，因此在历史数据的查询中会以历史的维度值进行计算。同时在维度值更新后的相关数据自然使用的是新的代理键。很好得解决了大部分缓慢变化维情况。

3、新列

类型3，即增加当前值的属性，在维度模式中，很多的源数据变化将同时产生类型1与类型2的变化。有时上面两种处理技术都无法满足需求，例如当需要分析所有伴随着新值或旧值的变化前后记录的事实时，需要采用类型3变化。

上面那段话其实有些拗口，无法理解，这里举一个无法用类型1和类型2处理的例子：

现在一家公司的销售是按照销售区域进行分组：

现在实行区域化运营，要变革，要精细化大区划分，将华东、华南重新划分为华东、华南、华中。其中销售人员是立刻使用了新的区域划分，但是我们需要暂时保留旧的，因为我要比较今年去年的业绩，即：

拥有使用新区域分析所有事实的能力，无论变化前还是变化后；
拥有使用旧区域分析所有事实的能力，无论变化前还是变化后。

第一个需求：新区域分析，维度表就是某个人的所属区域，例如小王华南，立即采用新的分组，所有历史订单都能分为华东、华南、华中新类别；

第二个需求：旧区域分析，维度表就是某个人的所属区域，能采用旧分组，所有的订单可以根据旧区域分组。

现在发生一些问题，无论是上面的类型1还是类型2，都不能同时满足这两个需求：

类型1可以满足第一种需求，使用新值写旧值。但显然它无法实现第二个需求；

类型2则不能满足任意一个需求，旧的事实和旧的维度相连；而新的维度值和以后的事实相连。它既不能分析旧数据、也不能分析新数据。其实这个地方要想解决，也能去解决，有点拉链表那种感觉，得不偿失。

此时引入类型3处理方法：新列，即新增字段同时储存新旧值。

例如由：

id    name    dept
1    小王    华南

转变为：

id    name    dept_old    dept_new
1    小王    华南        华中

如果又发生第二次变化，当前的dept_new去更新到dept_old中，新的变化值写到dept_new李，当然也可以再新增列，看分析需求，因为类型3处理方法不保存事实的历史内容，需要注意的是，类型3的改变往往并不是一个仅此一次的过程，它能发生1次就有可能发生2次甚至更多次。类型3变化只保护变化属性的一个旧版本，一旦发生第二次变化，第一次变化前的值就要被废弃了。如果想要用此方法来实现更多的版本，那增加更多的列来实现。