数据库学习

刚入职不到一周，刚好赶上了公司的一起内部培训——牛计划，主题是实用数据模型设计，大概记录下笔记并配上培训后试题的答案。

引入

案例1

问题:这个数据库表存在多少问题？

1. 主键问题
2. 大小写问题
3. 命名问题
4. 类型问题
5. 长度问题
6. 密码问题
7. 关键字问题
8. 约束问题
9. 存储问题
10. 业务问题
11. 优化等其它问题

案例2

规范化与三范式

关系数据库之父(艾德拉考特)：

Each non-primary key value MUST be dependent on the key(1NF), the whole key(2NF), and nothing but the key(3NF) 每一个非键值属性必须依赖于键，依赖于整个键而不是键的一部分，并且不依赖于其它非键属性。

第一范式(1NF)

原子性，没有重复列，列不可再分，也没有重复性。

1. 首先将数据规整成二维表格
2. 确保每一列表达的同一含义/格式的数据
3. 去掉多值属性，拆成多列
4. 去掉重复组，挪到新表
5. 确保行列的原子性并确定主键

第二范式(2NF)

非主键属性依赖于整个键，而不是其中一部分。

1. 首先得满足第一范式
2. 如果非主键属性只依赖于主键的一部分，则移出创建新表

第三范式(3NF)

非主键属性只依赖于键，不能依赖于其它非主键属性。

1. 首先得满足第二范式
2. 如果非主键属性还依赖于其它非主属性，则要移出创建新表

实体(Entity)

通常是名词，即”人”，”事”等的抽象化对象

比如：员工，公司等等

实体，就是你想要在数据库里存储的所有信息

实体对应数据库就是表，实体中的实例就是一行行的数据

分类方式

5W1H

IBM

属性

关系(Relationship)

通常是动词，如老师教课程

用于表示实体和实体之间的关系

在概念模型层级，存在1:N,0:N,1:1,0:1,M:N几种情况

在逻辑模型和物理模型层级,则需要消除M:N的情况

通过E-R图来理清关系

如何开始

概念模型

1. 与客户一致的商业语言
2. 尽量一页纸描述清楚整个模型
3. 通常用实体关系型图表示，但不需添加实体的属性
4. 允许多对多的关系存在

比如： 聚集：人-头. 手. 脚……..

分类：男人-张三. 李四. 王五……

概括：人-好人. 坏人

逻辑模型

物理模型

低质量数据模型

高质量数据模型

一些建议

技能储备

1. 理解业务知识和用户需求
2. 了解数据模型设计的模式
3. 清楚理想化模型和现实应用的分界线
4. 知道什么时候停止，不要过度设计
5. 对数据库知识的了解
6. 文档的技巧和能力
7. 语言沟通能力
8. 维度建模知识的掌握
9. 关系型模型规范化的知识
10. 非传统数据存储的知识（也就是NOSQL DB)
11. 知道怎么在敏捷开发模式下和团队合作。

关键点

1. 键的设计、字段设计
2. OLTP or OLAP
3. 索引、分区、删除字段4、性能与规范取舍
4. 场景应对策略
5. 升级与维护

培训后考核

1.各举一个不满足第一范式、第二范式、第三范式的简单例子。（30）

【不满足第一范式】：1.主键重复。2. StuInfo字段可以再分 |StuId(主键学号)| StuName (姓名)| StuInfo(学生信息)| |:–:|:–:|:–:| |S001| 张三| 信息学院 大三| |S001| 李四| 商学院 大二|

【不满足第二范式】：课程名称不完全依赖于主键，容易产生冗余信息 |CNo(课程编号)| CSchool(授课学院)| CTeacher(授课老师)| |:–:|:–:|:–:| |C002| 信息学院| 王五|

【不满足第三范式】：课程名称不依赖于主键，而是依赖于课程编号 |StuId(主键学号)| CNo(课程编号)| CName(课程名称)| |:–:|:–:|:–:| |S001| C002| 计算机基础|

2.举一个以上实际工作中碰到的数据库设计不合理的例子，并给出分析。（30）

例如：XXXXXX的XXXX功能，在进行已完成的项目筛选时，需要进行一次LEFTJOIN 来排除掉上一步流程由自己完成而目前处于待办的业务，因为数据库字段没有设计字段来保存当前流程的经办人及其状态，导致需要多进行一次查询。可以考虑新增字段来标记状态，从而优化查询的效率和速度。

3.就你用到的公司产品有关数据库方面给出自己的改进建议。（40）

数据命名方面：以xxxx为例，数据库表命名比较混乱，部分字段使用的英文和英文简写，部分字段使用的则是拼音简写，还有部分字段有拼音和英文混写，而且大小写混乱。可以考虑制定一个统一的命名规范文档，所有数据库都按照规范来进行设计，这样在其他人接手和理解上能有一定的帮助，而不是完全依赖字段描述。

数据库结构：很多业务流程的查询需要进行大量的跨表查询，后续项目或许可以考虑根据实际的业务逻辑，对数据库的结构进行设计。