数据库学习
刚入职不到一周，刚好赶上了公司的一起内部培训——牛计划，主题是实用数据模型设计，大概记录下笔记并配上培训后试题的答案。
引入
案例1
问题:这个数据库表存在多少问题？
- 主键问题
- 大小写问题
- 命名问题
- 类型问题
- 长度问题
- 密码问题
- 关键字问题
- 约束问题
- 存储问题
- 业务问题
- 优化等其它问题
案例2
规范化与三范式
关系数据库之父(艾德拉考特)：
Each non-primary key value MUST be dependent on the key(1NF), the whole key(2NF), and nothing but the key(3NF) 每一个非键值属性必须依赖于键，依赖于整个键而不是键的一部分，并且不依赖于其它非键属性。
第一范式(1NF)
原子性，没有重复列，列不可再分，也没有重复性。
- 首先将数据规整成二维表格
- 确保每一列表达的同一含义/格式的数据
- 去掉多值属性，拆成多列
- 去掉重复组，挪到新表
- 确保行列的原子性并确定主键
第二范式(2NF)
非主键属性依赖于整个键，而不是其中一部分。
- 首先得满足第一范式
- 如果非主键属性只依赖于主键的一部分，则移出创建新表
第三范式(3NF)
非主键属性只依赖于键，不能依赖于其它非主键属性。
- 首先得满足第二范式
- 如果非主键属性还依赖于其它非主属性，则要移出创建新表
实体(Entity)
通常是名词，即”人”，”事”等的抽象化对象
比如：员工，公司等等
实体，就是你想要在数据库里存储的所有信息
实体对应数据库就是表，实体中的实例就是一行行的数据
分类方式
5W1H
IBM
属性
关系(Relationship)
通常是动词，如老师教课程
用于表示实体和实体之间的关系
在概念模型层级，存在1:N,0:N,1:1,0:1,M:N几种情况
在逻辑模型和物理模型层级,则需要消除M:N的情况
通过E-R图来理清关系
如何开始
概念模型
- 与客户一致的商业语言
- 尽量一页纸描述清楚整个模型
- 通常用实体关系型图表示，但不需添加实体的属性
- 允许多对多的关系存在
比如： 聚集：人-头. 手. 脚……..
分类：男人-张三. 李四. 王五……
概括：人-好人. 坏人
逻辑模型
物理模型
低质量数据模型
高质量数据模型
一些建议
技能储备
- 理解业务知识和用户需求
- 了解数据模型设计的模式
- 清楚理想化模型和现实应用的分界线
- 知道什么时候停止，不要过度设计
- 对数据库知识的了解
- 文档的技巧和能力
- 语言沟通能力
- 维度建模知识的掌握
- 关系型模型规范化的知识
- 非传统数据存储的知识（也就是NOSQL DB)
- 知道怎么在敏捷开发模式下和团队合作。
关键点
- 键的设计、字段设计
- OLTP or OLAP
- 索引、分区、删除字段4、性能与规范取舍
- 场景应对策略
- 升级与维护
培训后考核
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为例，数据库表命名比较混乱，部分字段使用的英文和英文简写，部分字段使用的则是拼音简写，还有部分字段有拼音和英文混写，而且大小写混乱。可以考虑制定一个统一的命名规范文档，所有数据库都按照规范来进行设计，这样在其他人接手和理解上能有一定的帮助，而不是完全依赖字段描述。
数据库结构：很多业务流程的查询需要进行大量的跨表查询，后续项目或许可以考虑根据实际的业务逻辑，对数据库的结构进行设计。