数据建模大概分为三个阶段，概念建模，逻辑建模和物理建模，其中概念和逻辑建模与数据库没关系，物理建模与数据库有关系。
1.概念建模
概念建模主要做三件事：

1.客户交流

2.理解需求

3，形成实体
2.逻辑建模
对实体进行细化，细化成具体的表，同时丰富表结构，这个阶段的产物是可以在数据库中生成具体的表及其他数据库对象（包括主键、外键、属性列、索引、约束甚至是试图以及存储过程）。实际项目中，除了主外键之外，其他的数据库对象在 物理建模 阶段建立，因为其他数据库对象更贴近于开发，需要结合开一起做。
3.物理建模
将在逻辑建模阶段创建的各种数据库生成为相对应的sql代码，运行来创建相应具体数据库对象，但是这个阶段我们不仅仅创建数据库对象，针对业务需要，我们也可能做数据拆分
实体-关系图
也称为E-R图，提供了表示实体、属性和关系的方法，用来描述现实世界的概念模型

构成E-R图的基本要素是实体、属性和关系

数据建模应用
一、为什么要数据建模
二、数据建模种类
1、关系建模（3NF）
2、维度建模
三、3NF数据建模
1、范式介绍
2、3NF建模实战
四、维度建模
1、维度和指标的概念
2、星型模型
3、雪花模型
4、星型与雪花模型对比
5、维度建模测试案例
五、3NF建模与维度建模的区别
六、指标和维度建模步骤
1、业务需求转化为数据接口
2、维度梳理
3、指标梳理和确认
4、一致性分析矩阵

一、为什么要数据建模
判断一个年轻人有没有潜力，很重要的标准，就是看他如何对待一项从来没有做过的事情。我们常常会引入“体系感”来描述这个学习和上手的过程。所谓体系，就是将做事的方法、步骤和流程，通过拆分与组合，构建出一条达到目标的路径图。无论是交代下来的新任务，还是处理一件很棘手的新事情，它们背后或多或少都一定有一套体系方法存在。它既是做事诀窍，也是避坑指南，更是帮助我们快速高效达到目标的行动指引。
然而很少有人在做事之前，会去考虑这些东西。大多数人往往是“直觉型”选手。布置下来事情了，什么都不多问，什么也不多想，不管三七二十一凭感觉吭哧吭哧去干。如果没有一个有经验的人全程监督带着你，一定会走许多冤枉路，做许多无用功。这反映在老板眼里，就是一个效率低下的印象。普通人是先干再想，出了问题再回头去琢磨原因；聪明人是先想再干，把可能出现的错误减少到最低，最大程度避免弯路出现。这中间的区别，就是体系感（如下图）：


图中的小编号就是做事的步骤。这种体系流程化的思维一旦变成习惯，能够极大提升工作效率。
“You might put up a camping tent without assembly instructions，but would you really try to build your corporate headquarters without a documented blueprint ?”

在建房子的时候我们也需要图纸。如果没有图纸的规划，可想而知建成的房子既丑陋又不结实。

我们通过“体系感”来把控自己，通过图纸来建立高楼大厦。同样，我们可以通过“数据模型”来管理我们的数据。
数据模型就是数据的组织和存储方法，它强调了从业务、数据存取和使用角度合理存储数据、有了适合业务和基础数据存储环境的模型，那么大数据就会获得以下好处：
性能
良好的数据模型你帮助我们快速查询所需要的数据，减少数据的IO吞吐。

成本
良好的数据模型能极大地减少不必要的数据冗余，也能实现计算结果复用，
极大地降低大数据系统中的存储和计算成本。

效率
良好的数据模型能极大地改善用户使用数据的体验，提高使用数据的效率。

质量
良好的数据模型能改善数据统计口径的不一致性，减少计算错误的可能下。

二、数据建模种类
1、关系建模（3NF）
定义：通过实体关系(E-R)体现企业经营活动的业务要素和业务规则，通过满足 3NF 设计消除数据冗余。
优点：模型稳定、灵活、扩展性强
缺点：牺牲一定数据访问的便利性和业务的可理解性
适用性：适用核心基础数据的组织和管理(ODS层)
应用行业：非互联网行业，如传统金融、证券行业、电信行业、零售、航空等
3NF核心表间关系：1-1；n-1；1-n；n-n；
数据库的设计：从事物出发、减少冗余；
数据的仓库：从分析出发
2、维度建模
定义：按照维度表、事实表构建数据模型，通过指标评价企业经营活动
优点：容易理解，可分析性高(DM层)
缺点：稳定性扩展性弱、数据冗余
适用性：从业务需求出发，为分析提供服务
适用行业：互联网行业
三、3NF数据建模
三范式设计可查看之前的博客：https://blog.csdn.net/weixin_45399233/article/details/95957046
1、范式介绍
1NF：属性原子不可分
2NF：满足 1NF，且表中的每一个非主属性，必须完全依赖于本表的主键
3NF：确保每列都和主键列直接相关,而不是间接相关
2、3NF建模实战
业务场景：某个同学在 XXX 银行的 XXX 支行的柜台新开了一个账户，并且存入了100人民币活期。
业务要素：客户信息、账户信息和交易信息等
3NF建模：


四、维度建模
1、维度和指标的概念
按照维度表、事实表构建数据模型，通过指标评价企业经营活动。
维度一般包括：地区、时间、部门、产品等等。
指标一般包括：销售数量、销售金额、平均销售金额等等。
2、星型模型
星型模是一种多维的数据关系，它由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用 hive 时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过 join 来组合数据，相对来说对OLAP 的分析比较方便。



星型模型以事实表为中心，周围可以有很多维度，这些维度只能有一级维度(维度下面不能有子维度)
3、雪花模型
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要 join 的表比较多所以其性能并不一定比星型模型高。



雪花模型以事实表为中心，周围可以有很多维度，维度下面可以有子维度
4、星型与雪花模型对比





查询速度
扩展性
冗余度
对事实表的情况
表个数




星型模型
快（一般2张表join）
扩展性比较弱
高
低
少


雪花模型
慢（一般多张表join）
扩展性比较强
增加宽度
字段比较少，冗余低
多


5、维度建模测试案例
业务需求：高层领导想看不同地区、不同时间、不同部门、不同产品的销售数量、销售金额和平均销售金额？
梳理维度和指标
维度包括：


地区


时间（每天、每周、每月）


时间是yyyy-mm-DD HH:mm:ss
基本维度：yyyy-mm-DD HH:mm:ss
衍生维度：day、week、month、quarter、year


部门


产品


指标包括：


基础指标
销售数量、销售金额


衍生指标
平均销售金额


业务系统里面有一张销售表：




saler_id
productName
date
amount
price
city




001
P30
2019-09-05 20:05:30
1
3000
北京


产品维度：




productId
productName




s001
iphoneX


s002
P30


s003
MI8


s004
R20


时间维度：




date
day
week
month
quarter
year




2019-09-05 20:05:30
20190905
36
201909
3
2019


地区维度：




area_id
cityName




010
北京


创建事实表（fact）：




saler_id
productId
date
area_id
count
price




01
P30
2019-09-05
010
1000
3000




分析指标：
  select p.productName,sum(price) from fact f join product p on f.productId = p.productId group by p.productName; 

五、3NF建模与维度建模的区别
业务场景：大家去超市买东西，付完钱会给你一张购物明细，同学们想一下，这张购物明细分别用3NF建模和维度建模，怎么做？
3NF建模如下：


维度建模如下：

六、指标和维度建模步骤
1、业务需求转化为数据接口
2、维度梳理
3、指标梳理和确认
指标分类：


可加：如金额、数量等


不可加：如折扣、汇率等


4、一致性分析矩阵




维度\指标
销售量
销售金额
平均销售金额




日期


√


时间
√




地区

√



商品
√

 

数据建模，通俗地说，就是通过建立数据科学模型的手段解决现实问题的过程。数据建模也可以称为数据科学项目的过程，并且这个过程是周期性循环的。

数据建模的具体过程可分为六大步骤，如下图所示：



一、制订目标

制订目标的前提是理解业务，明确要解决的商业现实问题是什么？

如：电商平台用户评价的情绪分类。

二、数据理解与准备

基于要解决的现实问题，理解和准备数据，一般需要解决以下问题：

需要哪些数据指标（特征提取）
	
数据指标的含义是什么？
	
数据的质量如何？（是否有缺失值）
	
数据能否满足需求？
	
数据还需要如何加工？（如：数据指标装换，标签化）
	
探索数据中的规律和模式，进而形成假设。（模型选择）
需要注意的是，数据准备工作可能需要尝试多次。因为在复杂的大型数据中，较难发现数据中存在的模式，初步形成的假设可能会被很快推翻，这时一定要静心钻研，不断试错。

数据建模后需要评估模型的效果，因此一般需要将数据分为训练集和测试集。

三、建立模型

在准备好的数据基础上，建立数据模型，这种模型可能是机器学习模型，也可能不需要机器学习等高深的算法。选择什么样的模型，是根据要解决的问题（目标）确定的。

当然可以选择两个或以上的模型对比，并适当调整参数，使模型效果不断优化。

四、模型评估

模型效果的评估有两个方面：一是模型是否解决了需要解决的问题（是否还有没有注意和考虑到的潜在问题需要解决）；二是模型的精确性（误差率或者残差是否符合正态分布等）。

 

五、结果呈现

结果呈现主要关注以下三个方面：

模型解决了哪些问题？
	
解决效果如何？
	
如何解决问题？具体操作步骤是什么？
六、模型部署

通过大量数据解决了一个或多个重要的现实问题，需要将方案落实下去，一般情况下需要通过线上技术环境部署落实，从而为后面不断优化模型、更好地解决问题打下基础。

交由工程人员部署技术环境，需要数据建模团队撰写需求文档，并确保工程人员理解需求文档的内容，才能达到较好的模型部署效果。

 

一、数据库模简介
二、数据建模元素
1、表（Table）
2、表索引（Table Index）
3、表触发器（Table Trigger）
4、表约束（Table Constraint）
5、视图（View）
6、存储过程（Stored Procedure）
三、数据建模实例
四、总结


一、数据建模简介
数据建模不仅可以对象的属性建模（比如E-R图），也可以对数据的行为建模（比如触发器Trigger、存储过程Stored Procedure）.在进行数据库设计时，设计到如下几个概念：
模式 Schema、主键 Primary、外键 Foreign key、关系 Relationship、约束 constraint、索引 Index、触发器 Trigger、存储过程 Stored Procedure、视图 View。
二、数据建模元素
、表（Table）
表是关系数据库最基本的模型结构。如下图
 

 
表的主键：InventoryID
表的外键：WarehouseId，关联到表Warehouse的主键
可以设置Table的数据库类型，如下图
 

 
也可以设置表空间，如下图
 
 
 
、表索引（Table Index）
指按表文件中某个关键字段或表达式建立记录的逻辑顺序。它是由一系列记录号组成的一个列表，提供对数据的快速访问。索引不改变表中记录的物理顺序
、表触发器（Table Trigger）
当对某一表进行诸如UPDATE、 INSERT、 DELETE 这些操作时，SQL Server 就会自动执行触发器所定义的SQL 语句，从而确保对数据的处理必须符合由这些SQL 语句所定义的规则。


    触发器的主要作用就是其能够实现由主键和外键所不能保证的复杂的参照完整性和数据的一致性
、表约束（Table Constraint） 
通过对列的约束，保证数据的有效性。
 
 
 
、视图（View）
视图是从一个或多个表或视图中导出的表，其结构和数据是建立在对表的查询基础上的。如下图
 
 
、存储过程（Stored Procedure）
将常用的或很复杂的工作，预先用SQL语句写好并用一个指定的名称存储起来, 那么以后要叫数据库提供与已定义好的存储过程的功能相同的服务时,只需调用execute,即可自动完成命令。

 
 
 
 
三、数据建模实例

 

 
1、表有仓库Warehouse、库存Inventory以及书Book
2、主键分别为WarehouseID，InventoryID,ISBN
3、外键，表Iinventory的外键是WarehouseID，同时也是Warehouse的主键
   表Book的外键是InventoryID，同时也是Inventory的主键
4、关系，表Warehouse与表Inventory是一对多的关系
   Inventory与表Book是一对多的关系。
四、总结
本文主要介绍了数据库建模所涉及建模元素，主要包括模式 Schema、主键 Primary、外键 Foreign key、关系 Relationship、约束 constraint、索引 Index、触发器 Trigger、存储过程 Stored Procedure、视图 View等等，并配以实例加以说明。
本篇文章比较简单，也是《UML建模-面向对象技术》系列文章的最后一篇建模文章。对此系列文章，后期抽个时间再写个总结，使的UML建模系列文章知识性更连贯，内容更加清晰。