为什么需要数据库设计

1. 我们在设计数据表的时候要考虑很多问题问题，比如：

用户都需要什么数据？需要在数据表中保存哪些数据？
如果保证数据表中数据的正确性，当插入、删除、更新的时候该进行怎么样的约束检查？
如何降低数据表的数据冗余，保证数据表不会因为用户量的增长而迅速扩张？
如何让负责数据库维护的人员更方便使用数据库？
使用数据库的应用场景各不相同，可以说针对不同的情况设计出来的数据表可能千差万别。

2. 现实情况中面临的场景

当数据库运行一段时间之后我们才发现数据表设计有问题。重新调整数据表结构就需要做数据的迁移，还有可能影响程序的业务逻辑，以及网站的正常访问。

3. 如果是糟糕的数据库设计可能会造成以下问题

数据冗余、信息重复、存储空间浪费
数据更新、插入、删除异常
无法正确表示信息
丢失有效信息
程序性能差

4. 良好的数据库设计则有以下优点：

节省数据的存储空间
能够保证数据的完整性
方便进行数据库应用系统的开发

总之，开始设置数据库的时候我们需要重视数据表的设计。为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。

范式

范式简介

在关系型数据库中，关于数据表设计的基本原则、规范就成为范式。可以理解为，一张数据表的设计结构需要满足的某种设计标准的级别。要想设计一个结构合理的关系型数据库，必须满足一定的范式。
范式的英文名称是Normal Form，简称NF。它是英国人在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。

范式包含哪些

目前关系型数据库优六种常见范式，按照范式级别，从低到高分别是第一范式、第二范式、第三范式、巴斯-科德范式、第四范式和第五范式（又称完美范式）。
数据库的范式设计越高阶，冗余度就越低，同时高阶的范式一定符合低阶范式的要求，满足最低要求的范式是第一范式。在第一范式的基础上进一步满足更多规范要求的称为第二范式，其余以此类推。
一般来说，在关系型数据库设计中，最高也就遵循到巴斯范式，普遍是第三范式。但也不是绝对的，有时候为了提高某些查询性能，我们还需要破坏范式规则，也就是反范式化。

键和属性的概念

范式的定义会使用到主键和候选键，数据库中的键（key）由一个或多个属性组成。数据表中常用的几种键和属性的定义：

超键：能唯一标识元组（记录）的属性集叫做超键。
候选键：如果超键不包括多余的属性，那么这个超键就是候选键。
主键：用户可以从候选键中选择一个作为主键。
外键：如果数据表R1中的某属性集不是R1的主键，而是另一个表R2的主键，那么这个属性集就是数据表R1的外键。
主属性：包含在任一候选键中的属性称为主属性。
非主属性：与主属性相对，指的是不包含在任何一个候选键中的属性。
通常，我们可将候选键称之为“码”，把主键称为“主码”。因为键可能是有多个属性组成，针对单个属性我们还可以用主属性和非主属性来进行区分。

举例

这里有两个表：
球员表（player）：球员编号 | 姓名 |　身份证号　｜年龄　｜球队编号
球队表：（ｔｅａｍ）：球队编号｜主教练｜球队所在地

超键：对于球员表来说，超键就是包括球员编号或身份证号的任意组合，比如球员编号，球员编号和姓名，身份证号和年龄等。
候选键：就是最小的超键，对于球员表来说，候选键就是球员编号或者身份证号
主键：我们自己选定，也就是从候选键中选择一个，比如球员编号。
外键：球员表中的球队编号。
主属性、非主属性：在球员表中，主属性就是球员编号　身份证号，其他属性姓名　年龄　球队编号都是非主属性。

第一范式（1NF）

第一范式主要是确保数据表中每个字段的值必须具有原子性，也就是说数据表中每个字段的值为不可再拆分的最小数据单元。
我们在设计某个字段的时候，对于字段x来说，不能把字段x拆分成字段x1和字段x2.事实上，任何dbms都会满足第一范式的要求，不会将字段进行拆分。

举例1

假设一家公司要存储员工的姓名和练习方式，它创建一个如下的表

改变就不符合1NF，因为规则说表的每个属性必须是原子值，lisi和zhaoliu员工的emp_mobile值违反了改规则。为了使表符合1NF，我们应该用如下表：

举例2

有一个user表

其不符合第一范式。其中user_info字段为用户信息，可以进一步拆分成更小粒度字段。将user_info拆分后如下

举例3

属性的原子性是主管的。* 例如employees*表中雇员姓名应当使用1个（fullname）、2个（firstname，lastname）还是3个（fistname，middlename，和lastname）属性表示呢？答案取决于应用程序。如果程序需要分别处理雇员的姓名部分（如：用于搜索目的），则有必要把它们分开。否则，不需要。

第二范式（2NF）

第二范式要求在满足第一范式的基础上，还要满足数据表里的每一条记录都是可唯一标识的。而且所有非主键字段，都必须完全依赖于主键，不能之依赖主键部分。如果知道主键的所有属性的值，就可以检索到任何行的任何属性的任何值。（要求中的主键，可以拓展替换为候选键）。

举例1

成绩表（学号、课程号、成绩）关系中，（学号，课程号）可以决定成绩，但是学号不能决定成绩，课程号也不能决定成绩。所以（学号，课程号）–》成绩就是完全依赖关系。

举例2

比赛表player_game里包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性。这里候选键和主键都为（球员编号，比赛编号），我们可以通过主键来决定如下的关系：
(球员编号，比赛编号)-----》(姓名，年龄，比赛时间，场地，得分)
但是这个表不满足第二范式，因为表中字段还存在如下关系：
（球员编号）—》（姓名，年龄）
（比赛编号）—》（比赛时间，比赛场地）
对于非主属性来说，并非完全依赖候主键。这样会产生怎么样的问题呢？

数据冗余，如果一个球员可以参加m场比赛，那么球员的姓名和年龄就要重复m-1次。一个比赛可能会有n个球员参加，比赛时间和场地就重复了n-1次。
插入异常，如果我们想要添加一场新的比赛，但是这时还没有确定参加的球员有谁，那么就无法插入。
删除异常，如果我要删除某个球员编号，如果没有单独保存比赛表的话，就会同时把比赛信息删除。
更新异常，如果我们调整了某个比赛时间，那么表中所有这个比赛时间都需要调整，否则就会出现一场比赛时间不同的情况。
为了避免出现上述的情况，我们可以把球员比赛表设计为下面三张表

这样的话，每张数据表都符合第二范式，也就避免了异常情况的发生。

1NF告诉我们字段属性需要是原子性，而2NF告诉我们一张表就是一个独立的对象，一张表只表达一个意思

举例3

定义了一个名为Orders的关系，表示订单和订单行的信息

违反了第二范式，因为有非主属性依赖于候选键（或主键）的一部分。例如，可以通过orderid找到订单的orderdate，以及customerid和companyname而没有必要再去使用productid
修改：
Orders表和OrderDetails表如下，此时符合第二范式。

小结：第二范式要求实体的属性完全依赖于主键字段。如果存在不完全依赖，那么这个属性和主键字段的一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多关系

第三范式（3NF）

第三范式是在第二范式的基础上，确保数据表中的每一个非主键字段都和主键字段直接相关，也就是说，要求数据表中的所有非主键字段不能依赖于其他非主键字段。即为不存在非主属性A依赖于非主属性B，非主属性B依赖于主键C的情况。通俗说，改规则的意思是所有非主属性之间不能有依赖关系，必须相互独立。
这里的主键可以拓展为候选键。

举例1

部门信息表：每个部门有部门编号、部门名称、部门简介等信息。
员工信息表：每个员工有员工编号、姓名、部门编号。列出部门编号就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据3NF也应该构建它，否则就会又大量的数据冗余。

举例2

商品类别名称依赖于商品类别id不符合3NF
修改：
表1 符合3NF的商品类别表的设计

表2 符合3NF的商品表的设计

商品表goods通过商品类别id字段与商品类别表进行关联。

2NF和3NF通常以这句话概括“每个非键属性依赖于键，依赖于整个键，并且除了键别无他物”

小结

关于数据表的设计，有三个范式要遵循。

第一范式，确保每列保持原子性
数据库每一列都是不可分割的原子数据项，不可再分的最小数据单元，而不能是集合、数组、记录等非原子数据项
第二范式，确保每列和主键完全依赖。尤其是在复合主键的情况下，非主键部分不应该依赖于部分主键。
第三范式，确保每列都和主键列直接相关，而不是间接相关。
**范式的优点：**数据的标准化有助于消除数据库中的数据冗余，3NF通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡。
**范式的缺点：**范式的使用，可能降低查询效率。因为范式等级越高，设计出来的数据表越多，越精细，数据的冗余度就越低，进行数据查询的时候就可能需要关联多张表，这不但代价昂贵，也可能使一些索引策略无效。
范式知识提出了设计的标准，实际上设计数据表时未必一定要符合这些标准。开发中我们会出现为了性能和读取效率违反范式化的原则，通过增加少量的冗余或重复的数据来提高数据库的读性能，减少关联查询，join表的次，实现空间换取时间的目的。因此在实际的设计过程中要理论结合实际，灵活运用。

范式本身没有优劣之分，只有适用场景不同。没有完美的设计，只有合适的设计，我们在数据表的设计中，还需要根据需求将范式和反范式混合使用。

数据库设计三范式详细介绍--数据库设计规范之数据库设计三范式相关推荐

数据库的锁的详细介绍
数据库的锁和索引的详细介绍数据库的锁的详细介绍全局锁表级锁表锁元数据锁意向锁行级锁行锁间隙锁临键锁数据库的锁的详细介绍最近看了一下数据库的锁和索引的相关知识,写个博客加深一下记 ...
数据库having的用法详细介绍
转自:微点阅读 https://www.weidianyuedu.com 数据库having的用法的用法你知道吗?下面微点阅读小编就跟你们详细介绍下数据库having的用法的用法,希望对你们有用. ...
喷雾干燥机设计计算机软件,喷雾干燥机的干燥塔原理与设计架构图详细介绍
历经长期的积累沉定,百度搜索针对喷雾干燥设备而言,很多年的制造工作经验在各个领域常有了非常好的发展,喷雾干燥设备也得到了大家较多的认同,大家针对喷雾干燥设备也大量的应用于各行各业,应对不一样的制造行业 ...
详细介绍什么是卡片式设计用户界面
作者:Nick Babich 日期:2016/10/11 原文链接:https://www.smashingmagazine.com/2016/10/designing-card-based-user ...
阿里云数据库POLARDB使用方法详细介绍
阿里云数据库POLARDB使用方法介绍 POLARDB是阿里云自研的下一代关系型云数据库,有三个独立的引擎,分别可以100%兼容MySQL.100%兼容PostgreSQL.高度兼容Oracle语法, ...
vs vb连接mysql_详细介绍VS2010 VB ACCESS数据库的连接（如有不对，敬请改正）
VS 首先添加引用尽量选最新的版本,这样可以向下兼容然后连接ACCESS数据库点击数据/添加新数据源第一次连接点新建连接点击更改选中ACCESS数据库点击浏览,选定数据库位置用户名密码 ...
Unity3d 引擎原理详细介绍、Unity3D引擎架构设计
体系结构为了更好地理解游戏的软件架构和对象模型,它获得更好的外观仅有一名Unity3D的游戏引擎和编辑器是非常有用的,它的主要原则. Unity3D 引擎 Unity3D的是一个屡获殊荣的工具,用于 ...
Unity3d 引擎原理详细介绍、Unity3D引擎架构设计 - zhibolife
时间 2014-03-24 11:18:00 博客园-所有随笔区原文 http://www.cnblogs.com/zhibolife/p/3620440.html 体系结构为了更好地理解游戏的 ...
Unity3d 引擎原理详细介绍、Unity3D引擎架构设计- zhibolife（转载分享）
体系结构为了更好地理解游戏的软件架构和对象模型,它获得更好的外观仅有一名Unity3D的游戏引擎和编辑器是非常有用的,它的主要原则. Unity3D 引擎 Unity3D的是一个屡获殊荣的工具,用于 ...

数据库设计三范式详细介绍--数据库设计规范之数据库设计三范式