数据库设计

概念

数据库设计是将数据库中的数据实体以及这些数据实体之间的关系，进行规划和结构化的过程

重要性

1. 提高增删改查，数据操作的效率
2. 当项目中的业务逻辑变更的时候，便于修改，扩展性强
3. 设计合理，业务逻辑处理更简单，使得应用开发更容易

设计数据库的步骤

收集信息–标识实体–标识每个实体的属性–标识实体之间的关系

1. 需求设计阶段：分析客户的业务和数据处理要求
2. 概要设计阶段：根据需求绘制数据库的E-R图
3. 详细设计阶段：应用数据库的三大范式进行审核数据库的结构

学会绘制E-R图

学会绘制E-R图，首先要了解什么是实体，什么是属性，什么是联系

1. 实体，是指现实世界中具有区分其他事物的特征或特性与其他实体有联系的实体，针对于数据库中的表而言，实体是指表中一行行特定的数据，但我们在实际开发中，也常常把整个表称为一个实体，具体符号用矩形表示
2. 属性，可以看作为实体的特征，针对于数据库中的表而言实体是指表中的列，用椭圆表示
3. 联系，是指多个实体之间的联系关系，用菱形表示

请见下图的列子：

绘制数据库模型图

三大范式

1. 第一范式，目标是确保每列的原子性.如果每列都是不可再分的最小数据单元,则满足第一范式.
2. 第二范式，在第一范式的基础上更进一层,其目标是确保表中的每列都和主键相关,也就是说在一个数据库表中，一个表中只能保存一种数据，不可以把多种数据保存在同一张数据库表中.如果一个关系满足第一范式,并且除了主键以外的其他列都依赖与该主键.则满足第二范式.
3. 第三范式，在第二范式的基础上更进一层,第三范式的目标是确保每列都和主键列直接相关,而不是间接相关.如果一个关系满足第二范式,并且除了主键以外的其他列都这能依赖于主键列,列和列之间不存在相互依赖关系,则满足第三范式.

通俗地理解：

1. 第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解;
2. 第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性;
3. 第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

基本表，中间表，临时表和视图

基本表有四个特性：

1. 原子性，基本表中的字段是不可再分解的
2. 原始性，基本表中的记录是原始数据(基础数据)的记录
3. 演绎性，由基本表与代码表中的数据，可以派生出所有的输出数据
4. 稳定性，基本表的结构是相对稳定的，表中的记录是要长期保存的

中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。

临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。

视图是一种虚表，与基本表、代码表、中间表不同，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。

对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么?

“三少原则”

(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E–R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计;

(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间;

(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。

　　数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E–R图，肯定比二百个实体(共二千个属性)的E–R图，要好得多。

　　提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。

　　提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。

　　“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。

映射基数

数据库实体间有三种对应关系：一对一，一对多，多对多
拿学生，班级，课程举例，学生与班级的关系，一个班级可以有多个学生，一个学生只能属于一个班级，显然是一对多的关系，在数据库设计表的时候，在学生表中可以添加一个字段（班级号的id ），作为学生表的外键，通过主外键来表示这样的关系；而学生与课程的关系，一个学生可以选多门课程，一门课程可以被多名学生选修；这显然是一种多对多关系，这个时候在学生表中添加一个字段就行不通了，可以考虑建立关系表，学生表，课程表，关系表；在关系表中，将学生号，课程号作为字段，填进去就可以了；
注意：多对多表建立主外键之后，删除的时候要先删除关系表内容再删除主表的数据