数据库设计基础总结

骑猪看日落 2022-10-02 04:56 191阅读 0赞

前段时间自己尝试做了一个app，对于数据库设计方面稍有学习。在这里进行总结，以备后期更改和查阅。

## 一：数据库设计的重要性 ##

随着业务的开展，数据库中的数据会非常庞大。如果数据库设计良好，比如选择合适的数据类型，他会极大的减小数据存储的空间。同时良好的范式标准也可以避免数据维护异常（增删改查）。同时合理的违反范式规则有助于高效的数据库访问。  
同时项目之后的拓展，数据库也不会出现大改的情况。

## 二：数据库设计的步骤 ##

**1:需求分析  
2:逻辑设计  
3:物理设计  
4:维护和优化**

## 三：需求分析 ##

在这一步要明白数据是什么，数据有哪些属性，以及数据和属性的各自特点是什么。  
将所需要的功能模块都列出来了，将每一个独立的实体对象（一般是名词）划分为单独的模块，例如用户模块。需要将这个模块中的涉及的属性列举出来，并选择可选唯一标识属性，最后确定他数据的存储特点。  
就拿用户模块举个例子：  
1属性：用户ID，用户名，球衣号码，球员头像，个性签名，邮箱，密码  
2可选唯一标识属性：用户ID，邮箱  
3存储特点：随着系统上线的时间，业务的拓展，模块中的数据会越来越多，而且用户模块中的数据不需要做数据删除归档存储，需要进行永久存储。  
**存储特点：**  
确定存储规则的前提就是需要明白数据的  
1）：对于一些重要数据，例如用户模块：是进行永久存储的不建议进行数据删除和归档存储。  
2）：对于一些过期的信息，例如商城软件的下线商品，可以进行归档处理（归档存储），迁移到别的表中，而且也不能进行删除这些商品，因为有些订单是和他们相关联的。  
通过迁移归档，来保持商品表的小数量级。  
3）：对于一些用户随时调用的数据，需要永久存储不能删除，但是随着业务的开展，数据量会越来越大，此时需要进行分表分库存储。  
其他还有很多定义的存储规则，但目前还是初始入门，先列出上述。

## 四：逻辑设计 ##

逻辑设计的主要目的是将需求转化为数据库的逻辑模型，可以简单的理解为将一个抽象的文字描述，转换为一个更具体的关系模型。  
在逻辑设计中ER图就是逻辑设计的展示形式。  
**基本概念**  
1关系：每一个就是一个关系，一个关系就是对应一个表  
2元组：表中的一行就是一个元组，更现实一点就是需求分析中的每一个实体都是一个元组  
3属性：表中的每一列都是一个属性  
4候选码：表中的一个属性或者是一组属性他可以唯一确定一个元组，那么这个属性或者一组属性被称为候选码。  
5主码：从候选码里选择出一个作为主码  
6作用域：属性的取值范围  
7分量：即元组中的一个属性值，并要求不可再分。例如分组中的一个属性为工资，但他的属性值有基本工资和加班工资等多种，此时的数据库设计就是不合格的  
8矩形：表示实体集例如用户，场地  
9菱形：菱形表示关系集，也就是实体之间的关系，他的重要作用就是将多对多的关系转换成1对多的关系  
10椭圆：表示实体的属性  
11线段：将属性连接到实体集或者将实体集连接到关系集  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bl9Eb25nTGlhbmc_size_16_color_FFFFFF_t_70]  
在关系型数据库中，关系是要满足不同程度要求的，而这不同程度的要求就是不同的范式，范式越高规范化程度就越高。而符合规范的设计可以防止数据库的CURD出现异常，也可以最大程度的防止出现数据冗余。可以通过模式分解将低级范式关系模型转换成高级范式关系模型，同时这个过程也被称为规范化。  
**第一范式（1NF）**  
第一范式的要求是数据库中所有的字段都是单一的属性，不可再分。例如前面所提到的工资属性，他可以被分为基本工资加班工资等多种子属性，这是不被允许的，违反了第一范式。  
**第二范式（2NF）**  
1:无部分函数依赖； 2:无组合关键字  
如一张表中有如下属性：

1.  商品名称
2.  供应商名称
3.  价格
4.  重量
5.  供应商电话

**第二范式要求属性完全依赖于主键** 这一原则可以被拆分成两部分 1:无部分函数依赖； 2:无组合关键字。  
在这张表中有两个关键字：商品名称和供应商名称。其中价格重量分类是依赖于主键商品名称的；供应商电话是依赖于主键供应商名称的。这就违背了无部分函数依赖的原则。同时商品名称和供应商名称组成了组合关键字，这就违背了无组合关键字的原则。  
可以通过模式分解将这张表进行规范化，分成两张数据表  
表一： 商品名称，价格，重量。  
表二： 供应商名称，供应商电话。  
如果需要的话，可以增加一个关联关系表即可。  
**第三范式（3NF）**  
一直以来，第三范式都可以被理解为：**满足不存在传递函数依赖关系**，其实大部分时间我开始明白了这个概念但是一段时间后还是忘记了，不够通俗的解释。  
在前面的第二范式中学习到为了满足属性完全依赖主键，已经将一张表中的属性拆分成两张数据表，在保证满足第二范式之后才会去考虑是否满足第三范式。说到这里就可以直接概括为第三范式就是要求一个数据表中不允许包含已经在其他的表中已经包含的非主键属性。例如前面符合2NF的表一如果再添加上分类和分类描述这两个属性就是违背了第三范式的原则。  
**商品名称依赖于分类，分类依赖于分类描述**  
通过使用模式分解进行规范化，分解成两张数据表和一张关系表  
表一：商品表  
表二：分类表  
表三：商品分类关联信息表

**但有时为了性能和读取效率会适当的违反第三范式以空间换时间，允许存在一些冗余**

## 五：物理设计 ##

在之前完成逻辑设计之后开发人员会在这一步选择合适的数据库管理系统，并建立数据库的表结构，定义数据库的表以及字段的命名规范使其不需要查询数据字典就可以明白他的意义。并可以根据DBMS选择合适的字段类型。以及为了性能牺牲空间的反范式化设计。  
在实际开发学习中我只初步使用过PgSQL，太深的知识并没涉及过，水平有限在这里就不再详细描述了。  
**1:数据库表以及字段的命名规则**  
1）：可读性原则（驼峰法则）  
2）：表意性原则（从命名中就可以看出意义）  
**2:字段类型的选择**  
字段类型的选择影响了数据存储空间的开销，也影响了数据查询性能。因此字段类型的选择是很重要的。  
字段类型选择的优先级：  
1:数字类型  
2:日期或者二进制类型  
3:字符类型  
4:相同级别的应该考虑占用空间小的数据类型例如varchar和char  
5:其他的应该根据实际要求去设定例如decimal和float  
**3:反范式化设计**  
有时用户使用的某一处涉及到的数据库操作会涉及到很多的表，适当的违反一下第三范式的要求可以提高查询效率。  
反范式化的设计可以减少表的关联数量减少数据库的输入输出操作从而进一步提高数据的读取效率。  
但是为了将写操作异常控制在可控范围，反范式化一定要适度。

## 六：维护和优化 ##

**1:维护数据字典**  
1:用第三方工具维护数据字典  
2:使用表的comment注释表并将数据字典导出  
**2:维护索引**  
索引一般出现在`where， group by， order by`从句所在的列，要注意索引中不要包括太长的数据量；同时过多的索引会降低读写效率。  
**3:表结构维护**  
以MySQL为例在5.5为界限，之后版本的支持在线表结构的变更，在此之前要使用插件。  
要注意控制表的宽度和大小，超出界限需要进行拆分。  
**4:对表进行拆分**  
**垂直拆分：**  
为了控制表的宽度：当数据表的列太多时，需要将这些列进行拆分，此时需要将经常在一起查询的列放在一起将text等大字段拆分到附加表中，这样做的好处是可以不用做SQL关联操作，优化IO，减少表的复杂程度，提高效率。  
**水平拆分：**  
为了控制表的大小，将表的数据量进行拆分，此时每一个表的结构都是一样的。

## 最后的话 ##

上述内容是在进行个人项目之前对数据库设计的学习总结，学习资源来源于慕课网。  
对于数据库的初次尝试出现了很多的问题，但为了项目的长久发展，数据库的良好设计是非常重要的。之后了解深入之后会对项目的数据库进行进一步优化。  
有问题欢迎指出纠正。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3N1bl9Eb25nTGlhbmc_size_16_color_FFFFFF_t_70]: /images/20220113/81dd515d45ec4950ac5345cb594e3835.png