SQL 数据库设计

数据库设计

数据建模

数据建模的过程

分四步：

理解和分析业务需求：与相关专家，业务参与方，终端客户，查看现有的表单，文档，应用程序，电子表格，数据库。

构建业务的概念模型：业务中的实体，事务或概念以及他们之间的联系。

构建数据模型/数据结构(逻辑模型)：更加细节了一些，我们需要问了迎合我们的数据库做出一些更规范的设计，比如选用MySQL数据库管理系统时，我们肯定要做一些更加细节的分工。数据库抽象的数据模型只需要展示表和列.

实体模型：确切的数据类型，列默认值，表主键以及其他对象如视图触发器等。

概念模型

在数据建模的第一阶段我们会对业务需求进行分析。从而获得概念模型中的实体，事务以及之间的关系。

比如我们想要做一个网站去对学生的成绩进行整理和统计。那么我们经过分析可以得到一些简单的实体与关系。

比如学生，课程，成绩。而他们之间的关系对于学生与课程来讲是多对多的关系，一个学生可以有好几门课程，一个课程也可以由好几个学生来上。我们可以通过实体关系图基本仅用于数据建模，UML图（标准建模语言图）来进行数据建模。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-R1DnUn61-1634907437388)(.\gn_model.png)]

注意此时我们更加管住实体的属性以及实体间的关系，但不对属性做具体的分析。

逻辑模型

逻辑模型在使用过程中主要增加了数据结构，包括表的设计。

还拿概念模型的例子，我们可能需要对我们的实体进行更细粒度的划分。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-T1H8vzkr-1634907437391)(.\lj_model.png)]

比如上边的图片，我们给每一个字段加上了数据类型，同时通过加了一个表的方式来进行解耦，从而帮助我们更好的管理数据。

实体模型

这时候就需要去创建数据库模型了，也就是说我们需要给每一个数据表设计字段以及他们的类型和长度。

我习惯性把数据表定义成复数比如学生表定义为students，而字段则多用单数。

常见的短字符串比如姓名，电话等我们通常设置为50；而对于中等长度的字符串如邮箱我通常设置为255.

这些要根据业务去进行沟通和定长度。

总之我们最好尽可能的去减少我们每一个字段占用的磁盘空间，当数据量够大的时候你就会知道这个决定到底有多么正确。

表设计

主键

我们需要有一个字段来代表一个表里的每一行，就比如我们每一个人上学的时候都有属于自己的唯一的代号。这个代号是不能没有的，不能重复的。当然最好是也不能频繁更改的属性，要想满足这些条件，其实我们最好的情况下就是额外再加一行作以编号的区分。

哦对了，记住一个数据只有一个主键。比较谁也不想别人没事给自己起了两个名字。

外键

如同我举得例子，学生和课程表中都有主键，但是连接表的主键其实是没有什么意义的。我们往往需要根据学生编号获取课程编号，课程编号获取学生编号。

这种将其他表的主键拿过来的方式，叫做外键。

有的时候我们也可以采用复合主键，比如我们将两个字段值进行组合形成主键，比如我们在此时将学生编号和课程编号来作为复合主键，因为主键不能重复，所以我们可以避免一个课程被同一个学生选了两次。但是也会遇到一些问题，比如我们如果有一个表与这个连接表有联系，那么我们可能会出现一个新的问题。新表与学生表和课程表也有了联系。所以给连接表额外加一个编号字段作为主键以及采取复合主键两种方式需要谨慎考虑。

外键约束

我们有时候会遇到一些问题，尽管我们并不想更改一个实体的主键，但是我们有时候需要这么做。

UPDATE操作后我们也可能希望我们的连接表中的外键也跟着变化，此时我们就需要更改外键的约束了，比如我们可以改为CASCADE来作为级联，此时便可以做到我们上述说的。RESTRICT拒绝更新,SET NULL设置空值。NO ACTION无操作，和拒绝更i性能一样。

DELETE操作中，当我们删除了一行数据，我们可能需要他在连接表中也删除。CASCADE可以删除数据，但是我们有时候并不想要丢失数据，NO ACTION可以帮你做到。

标准化

第一范式

第一范式要求，每一个字段都要有单一值，且不允许有重复列。

举个例子我们的课程，可能分为好多类，并且一个课程可能属于好几个类别。那么我们如果在字段中加入类别这个字段，我们可能会导致一些问题，比如我们对英语课的分类是语言类，外语类。可是对德语课做分类时取名叫语言类，德语类。这样会导致分类变多不容易做筛查和管理。

最好的办法是将课程种类建立一个表格，将该表与课程表关联起来。因此我们需要在建立一个课程类别与课程的关联表，他在一定程度上是复杂的，但是在实际的运维和操作过程中，随着数据量的增大，这么做的意义也越来越大。可以提高效率。

这样做的另外一个好处是如果他是作为一个属性存在，我们在更新标签的时候需要更改每一行数据，行级锁的存在让效率大大降低，而这种方式，我们只需要锁住课程种类表的其中一行即可。

第二范式

必须先遵循第一范式，不能有任何取决于这组关系任何后选键的任何真子集的非主属性。

也就是任何一个表要有其单一的目的，作为一个单一的实体。它的每一个字段都是为了描述它的属性。

在我们的设计中，课程表中的指导老师便是一个错误的例子，我们应该单独做一张老师表，并且做连接表，从而保证合乎第二范式。这么做也会对我们的很多CUD操作产生便捷。

第三范式

表中所有的属性，只能由后选键来决定。也就是说每一个属性不能够是被其他属性所影响的。比如我们有一个字段总支出，一个字段总收入，我们不能再加入一个净收入，净收入可以由前两个得到。

一些建议

不要过多关注于规则

实际的开发当中，只要注意减少冗余就可以了，没有人关注我们到底使用的是第几范式。

举个例子:我们有一个表，有姓名和收货地址，如果一个客户有多个收货地址，我们就需要一个方法去减少冗余了。我们会产生大量的冗余，我们可以单独建立一张地址表。这样的理解要比第几范式更好理解一点。

不要对什么都建模

我们的任何建模都是基于当前的业务需要来进行的。不要去对未来情况做预测。比如我们的用户表，可能会更改姓名，那么我们是否要把原来的名字做存储呢，除非很有必要，要不然最好不要这么做。

我们不可能对所有未来的情况做出预测并建立模型，针对当前问题，用合理而又简约的方式解决它，要比建模去解决更合适。

至于业务需求，应该是顾客和老板的意思。我们仅仅专注于眼下情况的实现即可。当然这需要我们更加慎重的对我们当前业务需求的理解和建模。

模型工程

正向工程:将我们的逻辑模型转化为我们的数据库。

逆向工程:将我们的数据库转化为逻辑模型。