数据库设计开心讲义
1. 说在前面
项目开发的流程包括哪些环节
1. 需求调研【需求调研报告】-- 公司决策层
(1) 根据市场公司需求分析公司是否需要开发软件来辅助日常工作
(2) 公司高层市场考察，市场分析，决定做什么软件。
(3) 不懂技术的人想象软件应该有什么功能，长什么样子
2. 需求文档【功能列表】+原型 --- 公司产品经理（产品专员）。
(1) 根据领导的需求设计出产品的原型（图纸）
① 有具体的功能，功能之间可以跳转（静态跳转）
(2) 编写需求文档
① 对项目的详细介绍，每个功能能够完成具体哪些点，描述一清二楚
3. 美工通过原型设计UI。--> HTML网页
(1) 设计师，美工
(2) 目前纯粹的后台管理系统有成熟模板或者框架可选（BootStrap）
4. 后台开发，设计数据库（创建数据库结构）---技术经理+（若干开发人员3-5）
(1) 负责项目的架构技术选型等等，技术的全局把控- 技术经理
(2) 数据的设计
① 项目经理根据需求文档原型设计-居多
② 每个开发者根据自己的模块自己设计（分开设计，最后汇总）
(3) 项目模块代码的编写
(4) 后台开发，公共代码编写
(5) 功能编码
5. 测试
(1) 黑盒测试-
① 程序内部不可见-以特定的程序或者工具来测试软件
(2) 白盒测试
① 单元测试，程序软件直接通过代码测试
6. 上线运行
7. 后期的不断开发维护升级
8. 项目淘汰
2. 数据库设计的概述
2.1. 数据库设计是什么
所谓的数据库设计就是根据需求文档的描述将需求转成数据库的存储结构的过程.
在数据库设计的流程上,我们通常根据需求,画出数据的ER图.然后在通过ER图生成数据库的建库脚本. （Entity Relational）
ER图，所谓的ER图就是数据库关系图
为什么我们使用ER图来实现数据库设计的设计呢?
1.可见即可得.使用ER图可以通过图形的方式展示表与表直接的关系
2.可以根据设置的数据库,方便生成不同的数据库的SQL建库脚本
3.可以快速的生成数据库文档
小结：所谓的数据库设计，就是通过ER图，根据需求给数据库建表表结构！！！
2.2. 为什么需要数据库设计
软件开发都是分别从页面设计和数据库设计开始的.
创建项目的数据库是项目开发必须的阶段.
3. 数据库设计基础理论（重点）
3.1. 数据库设计的步骤
数据库设计的步骤是根据需求的描述:
第一步：标识表
第二步：标识表的字段
3.2. 标识表注意事项
所谓的标识表，就是根据需求将表创建！！
我们在标识表的时候,可以将表分为实体表和业务表.
所谓的实体表:就是记录需求中描述为一个对象（名词）的表.如:用户,商品,订单,管理员,角色等
所谓的业务表:就是记录在需求中描述为一个业务行为（动词）的表:收藏,关注,等 （大部分是中间表）
虽然没有强制的规定先标识实体表还是业务表,但我们通常在标识表时会先标识实体表,再标识业务表.
因为业务表一般是用于标识实体表与另一个实体的多对多的关系的.
3.3. 标识字段注意事项
标识字段,在数据库设计中,尽量符合数据库设计的三大范式原则.
--三大范式，就是用于数据库设计，标识字段的时候使用的！！！。
数据库表设计三大范式最终解决的是数据冗余问题
3.4. 三大范式
为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
在实际开发中最为常见的设计范式有三个
3.4.1. 第一范式(确保每列保持原子性)
第一范式是最基本的范式。如果数据库表中的所有字段值都是不可分解的原子值，就说明该数据库表满足了第一范式。
第一范式的合理遵循需要根据系统的实际需求来定。比如某些数据库系统中需要用到“地址”这个属性，本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储，这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式，如下表所示。
上表所示的用户信息遵循了第一范式的要求，这样在对用户使用城市进行分类的时候就非常方便，也提高了数据库的性能。
3.4.2. 第二范式(确保表中的每列都和主键相关)
非主键列必须依赖主键列存在
第二范式在第一范式的基础之上更进一层。第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中。
比如要设计一个订单信息表，因为订单中可能会有多种商品，所以要将订单编号和商品编号作为数据库表的联合主键，如下表所示。
订单信息表
这样就产生一个问题：这个表中是以订单编号和商品编号作为联合主键。这样在该表中商品名称、单位、商品价格等信息不与该表的主键相关，而仅仅是与商品编号相关。所以在这里违反了第二范式的设计原则。
而如果把这个订单信息表进行拆分，把商品信息分离到另一个表中，把订单项目表也分离到另一个表中，就非常完美了。如下所示。
这样设计，在很大程度上减小了数据库的冗余。如果要获取订单的商品信息，使用商品编号到商品信息表中查询即可。
3.4.3. 第三范式(确保每列都和主键列直接相关,而不是间接相关-在2NF基础上消除传递依赖)
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。比如在设计一个订单数据表的时候，可以将客户编号作为一个外键和订单表建立相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段。如下面这两个表所示的设计就是一个满足第三范式的数据库表。
这样在查询订单信息的时候，就可以使用客户编号来引用客户信息表中的记录，也不必在订单信息表中多次输入客户信息的内容，减小了数据冗余。
三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构（范式）。所以不能一味的去追求范式建立数据库。
3.5. 实际开发部符合三范式的场景
3.5.1. 示例-性能的要求出现的冗余数据
我们很多系统都要记录日志.而日志里面,必须要包括用户的信息.如果严格按照三大方式.日志的用户信息必须是从用户表中获得，日志每天都会出现巨量的数据。如果关联用户表查询，整理日志时会导致用户表的访问大大被拖慢。
所以，我们会将用户的信息直接写在日志表里面。在日志表中写用户的的信息,明显违反了第二范式，基于查询的性能的需要，一般日志表的用户信息是冗余。
3.5.2. 示例-业务逻辑的要求出现的冗余数据
我们在订单中有一个商品的价格、商品名字。而这个商品的价格直接就是订单的字段.并不是商品表里面商品的价格.明显违反了第三范式.
但业务上,由于订单的商品的价格不能随着着商家修改了商品价格而修改.所以像这种需求下,必须要给订单表一个冗余的商品价格字段。
3.6. 标识表与表之间的关系
表与表之间的关系包括有
3.6.1. 一对一
3.6.2. 一对多/多对一
3.6.3. 多对多
3.6.3.1. 遵循范式设计
3.6.3.2. 以实际需求为主的设计
数据库表与表的关系，就是也需求描述的从属关系。
问题：表与表之间的关系，是谁决定的？
答：需求决定的！！！
4. 小结（重点）
1. 数据库设计就是建立项目的表结构
2. 基于数据的复杂性，一般数据库是先画ER图的。
3. 数据库设计的步骤是：标识表，标识字段，标识表与表之间关系
标识表，先标识实体表，在标识业务表
实体表（名词，没有行为）
业务表（包括业务动作，一般就是一个中间表）
标识字段，必须要求理解三大范式
为什么需要三大范式，避免数据的冗余，导致数据的异常。
数据库设计总体上要符合三大范式，但是基于业务需求和性能要求，有时候可以有少许的冗余
数据设计冗余，设计者必须要说明原因(项目需求需要)
标识表与表之间的关系
1. 有哪些表与表之间关系，一对多，多对一，一对一，多对多
2. 表与表之间的关系是由需求决定，讨论表之间的关系前，必须要先确定需求
3. 关系数据库是不能直接支持多对多的业务关系的，如果出现多对多必须要拆分一个中间表，原因是数据库里面的字段不能存储一个集合数据。
5. ERMaster的使用
ERMaster 是集成到Eclipse开发工具的一个插件。
5.1. ERMaster安装
1. 复制到dropins文件夹，解压到当前文件夹
2. 打开eclipse。在新建的other里面有ermaster选项，表示成功
5.2. DDL导出
在工作区，右击
5.3. 导出文档
右击工作区，导出HTML
6. 综合案例-学生成绩管理系统
需求：设计一个学生成绩管理系统
1. 首先有学生，学生必须包括登录、禁用功能
2. 基于安全性的考虑，学生的身份信息要单独存储。
3. 一个学生有多门成绩
4. 一个学生可以有多个老师，一个老师也可以教多个学生
第一步：标识表，标识实体表。学生、学生身份、成绩、老师
第二步：标识字段
6.1. ER设计图
6.2. SQL语句
导出sql语句把逻辑名称作为注释
sql
7. 综合案例-CRM系统（作业）
Customer Relational Manager System (客户关系管理系统)
7.1. 客户调研
客户人员是一个不懂软件设计的人,它希望有一个可以做管理系统来管理他的员工.
描述如下:
7.2. 系统功能列表（需求文档的核心部分）
功能列表给到客户人员。给到开发人员，跟进需求文档设计数据库。
7.3. 数据库设计
根据功能列表与客户调研报告（需求文档），设计数据库。
第一步：RBAC系统的设计
Role based Access Control (基于角色的权限控制系统)；就是根据不同的用户，根据用于所属的角色不同而登录的界面就不同。
需求：一个管理员只有一个角色（单角色的设计），一个角色可以有多个管理员
一个就是可以有多个权限，一个权限也可以有在多个角色角色。
第二步：业务系统的设计（CRM）
1. 一个销售（用户），只能查看自己的客户
2. 客户是公司，有多个联系人 （客户主体公司）
3. 销售人员可以设置重点跟进客户,并且可以说明重点跟进客户的原因.
4. 销售人员离职时,可以禁用不让登录
5. 销售人员可以多次跟进同一个客户（骚扰）
6. 销售可以指定客户给另一个销售人员跟进
8. PowerDesigner数据设计工具
PowerDesigner是一个专业的数据库设计软件。现在市场主流的数据库设计工具！！
8.1. 使用步骤
8.1.1. 第一步：创建一个物理ER图
--不要创建逻辑ER图，逻辑ER图只能看，不能生成数据脚本。
8.1.2. 第二步：工具栏说明
1. 表示创建包
2. 表示创建表
3.表示创建表与表之间的关系
8.1.3. 第三步：取消Name To Code
8.1.4. 第三步：CRM系统的设计
问题：设计表的时候，发现没有ID自增长选项
答：是因为默认没有指定Mysql数据库。所以需要设计为MySQL数据库。
--修改后，发现多个一个Identity选项
设计图如下：
8.1.5. 第四步：导出SQL脚本
--设置导出的路径
--生成的SQL脚本
问题：如何显示注释字段？
9. RBAC系统数据库设计
RBAC （Role based Access Control） 基于角色的权限系统。
RBAC系统可以实现根据不同的用户，显示的权限（菜单-功能）就不一样。
1. 用户
2. 角色
3. 权限
1. 一个用户只要一个角色 （单角色的设计）
2. 一个角色可以有多个用户
3. 一个角色可以有多个权限
4. 一个权限可以属于多个角色