clickhouse原理解析与开发实战 pdf_【实战演练】数据库基本知识与原理系列02-数据库设计与开发的范式...

#本文欢迎转载，转载请注明出处和作者。

上上篇，python+django网站开发，已经将静态页面的开发基本讲完了，要开发动态网页（用户与网站可以输入输出交互），就需要展示层（静态页面）->逻辑层（函数）->数据层（数据库）进行交互。

而如何在数据库、数据库表、字段、关联关系都清楚明了的情况下，在django创建数据库非常简单。

但是如果将系统需求收集、分析，然后设计出整套数据库的数据库表、字段、关联关系，则非常地困难。

上篇介绍了数据库的基本原理，聊到数据库，需要知道数据库的两种岗位：数据库管理员（DBA：运维），数据库设计/开发，

前者的主要工作内容，与之前介绍的高可用环境搭建的类似，包括而不限于数据库软件的安装，实例的构建，高可用/负载均衡集群环境的搭建，数据库的备份，SQL语句优化等。

繁星亮与鲍包包：【实战演练】Linux操作系统06-Mysql5.7安装​zhuanlan.zhihu.com

繁星亮与鲍包包：【实战演练】Linux操作系统20-MyCat实现Mysql数据库读写分离与自动切换​zhuanlan.zhihu.com

后者的工作内容，就是需要按照业务需求，将业务从真实世界抽象化，设计出一张张具有关联关系的二维表，并且规定里面的字段属性，并且这些二维表需要能够完整的代表所有业务流程。这就是数据库设计/开发的工作内容。

在数据库设计/开发阶段阶段，需要遵循数据库的三大范式来进行设计。

1、数据库设计三范式：

第一范式，数据不可分。

#可以理解为一个字段里面仅有一个数，例如一个字段不能既存放用户名与手机号码，如果要存，就拆开两个字段分别存。

第二范式，每个表格需要有个唯一性主键。

#因为关系型数据库是需要通过主键查找的，例如姓名这种可能有多个重名的张三，就不能拿来做主键，要用×××号。

第三范式，表里面不可以有数据对非主键的数据有依赖。

#例如一张表里面有×××号，姓名，电话号码，居住省，居住市这样4个字段，×××号确定，就一定可以确定姓名与电话号码，这叫“姓名”与“电话号码“唯一性依赖。而”居住省“，”居住市“这两个字段与”×××号“其实是没有必然的依赖关系的。本来也没有问题，但是明显”居住市“是对”居住省“有依赖的，例如广州市肯定是在广东省的前提下才能选择的。而”居住省“不是主键，所以叫做有数据对非主键有依赖。因此，违反第三范式，解决方法是应该将”居住省“”居住市“单独拆分到另外一张”居住地表“。

2、数据关联关系：

前面说过了，关系型数据库，就是一堆有关联关系的二维表，关联关系通常有3种情况。

一对一：直接用一张表，其他字段依赖于主键；

#例如一个学号，会对应一个学生姓名

一对多、多对一：在多的里面引用一的外键

#例如，假设一个老师仅能教一门课，而一门课可以多个老师授课。那么老师与课程的关系就是多对一，课程与老师的关系是一对多。

在数据库设计里面，应该在多者所在表（老师表）里面添加外键，引用一者（课程表）表里面的主键（课程ID）

#可以进行另外的假设，例如一个老师可以教多门课程，而一门课程仅能一个老师上课，那么老师与课程的关系就变为一对多，而课程与老师关系变为多对一。

数据库的设计，就变成了多者所在的表（课程表）添加外键，引用一者（老师表）的主键（可能是老师ID，员工工号之类）

所以可以看出，数据库表的设计不是一成不变的，是跟业务逻辑息息相关的，不同的业务逻辑情况下，设计出来的表格可能完全不一样。

多对多：这种情况无法在两张表之间直接建立关联关系，需要凭空建立一张中间表，作为连接。

#例如一个学生能够选修多门课程，一个课程可以给多个学生选修，关系则为多对多，这种无法通过在哪一边引入外键解决。

必须创建一张中间表，例如叫“选课表”，创建一个主键（例如序号/ID），然后外键引用学生表的主键、课程表的主键。将学生与课程关联起来。

3、数据库表设计实例

我们回顾一下python+django网站系统开发的需求：

繁星亮与鲍包包：【实战演练】Python+Django网站开发系列02-Django完整开发环境部署​zhuanlan.zhihu.com

我们会有学生、老师、课程这3大类的对象，先分析一下需求与关联关系。

假设我们系统要求每个学生可以最多选修2门课程，每个老师可以授课2门课程，每个课程仅能一名老师上课。那么在这样的需求下：

1）学生与课程之间关系是：多对多；

2）老师与课程之间关系是：一对多；

3）学生与老师之间关系是：没有直接关联关系，都是通过课程联系起来的；

因此，至少需要4张表，学生表、老师表、课程表、成绩表（学生与课程的中间表），而课程表（多）里面引用老师表（一）的主键为外键。

然后设计4张表的字段，思考一下需要什么信息才能满足我们的系统需求。（not null表示不能为空值）

这样，数据库的设计/开发就完成了。按照三大范式与关联关系检查一下，如果有违反的，就需要再次将违反范式的字段拆分出来，然后再视关联关系来看是否需要增加中间表。（以上只是很简单的案例，实际生产系统的数据库设计/开发比这个要困难很多，django网站开发后面的数据库后面还是用回这几个数据库表）