数据库逻辑设计mysql_数据库设计（一）分析及逻辑设计
作为一个后端开发者，数据库设计是我们避不开的课题，不管是面试的时候，还是在真实工作的情境下，我们的工作不仅仅是将代码开发出来，根据开发的项目，设计出支撑项目的数据库，也是一个合格的开发者所应该具备的技能之一，这里我将数据库设计分成几个重要的部分，以下是我做数据库设计时的步骤。
数据库设计步骤
需求分析
需求分析相信大家都知道，我们在做开发之前先做需求分析，能让我们的开发更加顺畅，它是我们开发的指南针，好的需求分析能让我们明确开发的需求，避开不需要做的功能需求，减少不必要的时间，而在数据库设计当中，需求分析也同样重要，当然它不需要结成像是需求文档一样的东西，首先要搞清楚为什么要做需求分析。需要存储哪些数据。
数据的特点，其中最重要的就是数据的时效性，在项目不断壮大的情况下，我们存储的数据会越来越多，这些数据是否能够清理，还是应该归档，这都是在确定数据时效性之后才明确的。
数据的生命周期。这个和数据的特点有些类似，像是增长快、量大、但又非必要的数据，我们可以考虑是否选择将这样的数据存入数据库，如果一定要存数据库，也可以提早确定分表的规则或者是清理的规则，如果等到数据变得十分庞大后再去考虑这些问题会影响到业务的正常进行，这些事情在需求分析就能确定下来是最好不过的。
而经过需求分析，我们也有需要搞清楚的事情，这也是需求分析的目的。首先是项目会涉及到的实体，像是在一个电商项目中，商品就是其中一个实体，一般情况下，我们可以将一个实体设计成一个表，当然这个不是一定的，需要根据实际情况设计。其次，也是我认为十分重要的一个步骤，即确定实体之间的关系，也就是我们常说的一对一，一对多以及多对多。只要确定了这个关系，我认为就能设计出一个业务逻辑上不会出错的数据库。
通常情况下，一对一的表将其中一个表的主键作为另一个表的外键，一对多的情况将“一”对应的那个表的主键作为“多”的那个表的主键，多对多的情况就设计一个关联表，将两表的主键存在关联表中做关联关系，这个方法在大部分项目中都能够直接使用，很大程度上减少我设计数据库的时间，如果时间紧急，可以采取这种方式设计后再做验证，时间充足的化还是希望大家按照一定的规范设计数据库。
最后，确定实体的属性，像是商品这个实体中，有商品名，价格等属性。
逻辑设计
以上就是需求分析应该做的事情，分析之后，就是做设计了，这里涉及到的内容就比较理论化，但是前人为我们总结了设计的规范，让我们可以比较简单的做逻辑设计。其中使用到的工具就是 ER 图。
er图
ER 图由矩形、菱形、椭圆形和线段组成，使我们可以将需求分析出来的实体、属性、实体间的关系由图体现出来，让人更加方便看懂理解。
将 ER 图画出来后，就是使用设计范式去做更详细的设计了。范式是关系型数据库的理论基础，是我们在设计数据库结构过程中所要遵循的规则和指导方法，经过设计范式的指导设计，我们就可以得到一个十分完善，逻辑清晰的数据库设计了。其中，我们主要遵循第一范式、第二范式、第三范式和BC范式，各种范式呈递次规范，越高的范式数据库冗余越小，即满足第三范式则一定满足第一第二范式，满足第二范式一定满足第一范式。
第一范式：确定表中的每一个字段都不能再分。下面这张图就是违反了第一范式，因为其中的用户信息字段还可以再分。
第一范式
第二范式：一个表是复合主键时(多个键组成唯一识别)，其中一个候选关键字存在决定非关键字的情况时，就不符合第二范式了，如下图。
第二范式
所以，如果是非复合主键则一定符合第二范式。
第三范式：不能存在传递函数关系。
第三范式
如上图，商品名称和分类在同一表内，但分类又可以决定分类描述，这就是传递函数关系，这时候，将分类和分类关系拆出来放到另一个表就可以达成第三范式了。
第三范式完善
以上就是数据库需求分析和逻辑设计的内容，这里比较偏向理论，好好的理解这些方法和设计范式就能设计出项目对应的数据库，能让我们如善应对工作中需要做的数据库设计相关的工作了，希望这篇文章能给大家带来帮助，下一篇文章会讲到物理设计和数据库维护相关的内容，因为一个数据库设计仅仅是满足于业务逻辑是不够的，随着业务的壮大，合理的物理设计和维护十分必要。这里给关注公众号的读者一个小小的资源，请在后台回复【数据库】获取。
日常发布初出茅庐程序员一些胡言乱语以及编程资源，漫漫编程路，希望我们一起进步！