标签：收藏   性能   现在   重叠   border   多对一   开发   软件开发   entity   

1.     数据库设计的概述

1.1.   数据库设计是什么

　　所谓的数据库设计就是根据需求文档的描述将需求转成数据库的存储结构的过程.

　　在数据库设计的流程上,我们通常根据需求,画出数据的ER图.然后在通过ER图生成数据库的建库脚本.（Entity Relational）

ER图，所谓的ER图就是数据库关系图

为什么我们使用ER图来实现数据库设计的设计呢?

1.可见即可得.使用ER图可以通过图形的方式展示表与表直接的关系

2.可以根据设置的数据库,方便生成不同的数据库的SQL建库脚本

3.可以快速的生成数据库文档

1.2.   为什么需要数据库设计

软件开发都是分别从页面设计和数据库设计开始的.

创建项目的数据库是项目开发必须的阶段.

2.     数据库设计基础理论（重点）

2.1.   数据库设计的步骤

数据库设计的步骤是根据需求的描述:

第一步：标识表

第二步：标识表的字段

第三步：标识表与表之间的关系

2.2.   标识表注意事项

我们在标识表的时候,可以将表分为实体表和业务表.

所谓的实体表:就是记录需求中描述为一个对象（名词）的表.如:用户,商品,订单,管理员,角色等

所谓的业务表:就是记录在需求中描述为一个业务行为的表:收藏,关注,等 （大部分是中间表）

虽然没有强制的规定先标识实体表还是业务表,但我们通常在标识表时会先标识实体表,再标识业务表.

因为业务表一般是用于标识实体表与另一个实体的多对多的关系的.

2.3.   标识字段注意事项

标识字段,在数据库设计中,尽量符合数据库设计的三大范式原则.

--三大范式，就是用于数据库设计，标识字段的时候使用的！！！。

2.3.1.    三大范式

1.第一范式：确保标识的字段的原子性，字段的概念分得不能再分。如：姓名可以分为姓和名。

--所谓的概述分的不能再分，就是说这个概念会在出现两种以上的情况的了。因为，姓名，中国人的姓名是 ：姓+名，外国有些国家：名 + 姓。意味着姓名这个概念有两种情况，所以可以在分成姓和名。所以违反三大范式！！

2.第二范式：确保标识的字段与表有依赖的关系，在用户表定义一个商品价格

--所谓的字段与表有依赖关系，必须字段是表概述的属性。 表概念的XXX

3.第三方范式：确保标识的字段与表有直接依赖的关系，用户表，用户类型的名称

数学上：A依赖B，B依赖于C，我们认为A依赖于C。但在数据库设计里面，如果出现这种情况就违反了第三范式了！

三大范式解决了什么问题呢?

使用三大范式的原则标识的数据库字段,保证了字段在数据库表中的唯一性.从而避免了数据库的数据的冗余.

--user表

--usertype表

--需求查询用户以及类型，程序员不知道以哪个类型字段为准！！

数据冗余会导致，数据增删改查都有可能出现数据异常。

是否数据库字段的标识就一定要完成符合三大范式呢?

其实数据库设计,只是为了不要出现过多的数据库冗余的数据,建议尽量在数据库设计的时候符合三大范式..

但在系统实现中：根据性能的要求和业务逻辑的要求,是可以出现少量的数据冗余的。但记得在数据库设计文档说明原因！！！

2.3.2.    示例-性能的要求出现的冗余数据

我们很多系统都要记录日志.而日志里面,必须要包括用户的信息.如果严格按照三大方式.日志的用户信息必须是从用户表中获得，日志每天都会出现巨量的数据。如果关联用户表查询，整理日志，会导致用户表的访问大大被拖慢。

所以，我们会将用户的信息直接写在日志表里面。在日志表中写用户的的信息,明显违反了第二范式，基于查询的性能的需要，一般日志表的用户信息是冗余。

2.3.3.    示例-业务逻辑的要求出现的冗余数据

我们在订单中有一个商品的价格.而这个商品的价格直接就是订单的字段.并不是商品表里面商品的价格.明显违反了第三范式.

但业务上,由于订单的商品的价格不能随着着商家修改了商品价格而修改.所以像这种需求下,必须要给订单表一个冗余的商品价格字段。

2.4.   标识表与表之间的关系

2.4.1.    表与表之间的关系

表与表之间的关系包括有：

1.一对一

2.一对多

3.多对一

4.多对多

数据库表与表的关系，就是也需求描述的从属关系。

问题：表与表之间的关系，是谁决定的？

答：需求决定的！！！

如： 板块与版主的关系是什么？

答：表与表之间的关系是由需求的决定的。板块与版主的关系，在没有确定需求之前是无法确定的。

2.4.2.    一对一

　　一对一的关系，一般出现在，主表和从表之间记录是一一对应的情况。

　　如再设计中，有一个学生表和学生身份表，需求上一个学生只有一个身份。意味着一个学生对应一个身份，所以是一对一关系。

　　当两个表的关系是一对一的时候,外键可以在两个表的任何一方都可以实现连接表找到对应的数据.但是实际设计中一般遵守现实逻辑中的从属关系来定表的从属关系..

　　如: 用户表和用户详细信息表的关系是一对一的关系. 现实逻辑中,我们认为用户的信息是属于用户的. 所以用户表为主表, 用户信息是外键表.

　　一对一的表设计特征：外键表的主键就是关联表的外键！外键表的主键和外键是重叠的！！

2.4.3.    一对多/多对一

　　两个表的一对多的关系:

　　主键表为一的一方,外键表为多的一方.

　　表的主从关系是通过由需求本身决定的.

2.4.4.    多对多

　　表的多对多的关系，在关系型数据库中,表是不支持一个字段存储一个集合的值的。

　　所以关系型数据库本身表之间是没有多对多的关系的，多对多的关系是业务逻辑的要求。

　　数据库设计遇到表之间多对多的关系会使用是一个中间表来记录两个表多对多的关系.

　　注意：如果遇到多对多，必须拆分一个中间表！！！！

3.     小结（重点）

1. 数据库设计就是建立项目的表结构
2. 基于数据的复杂性，一般数据库数据库是先画ER图的。
3. 数据库设计的步骤是：标识表，标识字段，标识表与表之间关系

　　标识表，先标识实体表，在标识业务表

　　实体表（名词，没有行为）

　　业务表（包括业务动作，一般就是一个中间表）

　　标识字段，必须要求理解三大范式

　　为什么需要三大范式，避免数据的冗余，导致数据的异常。

　　数据库设计总体上要符合三大范式，但是基于业务需求和性能要求，有时候可以有少许的冗余

　　数据设计冗余，设计者必须要说明原因

　　标识表与表之间的关系

1. 有哪些表与表之间关系，一对多，多对一，一对一，多对多
2. 表与表之间的关系是由需求决定，讨论表之间的关系前，必须要先确定需求
3. 关系数据库是不能直接支持多对多的业务关系的，如果出现多对多必须要拆分一个中间表，原因是数据库里面的字段不能存储一个集合数据。

数据库设计---入门

标签：收藏   性能   现在   重叠   border   多对一   开发   软件开发   entity   

原文地址：https://www.cnblogs.com/maigy/p/10798560.html