数据库结构设计

数据库结构的优化,要贯穿数据库结构设计的始终,所以我们先要了解一下,数据库设计的步骤都包括哪些,简单来说呢,

数据库设计的步骤,是随着产品需求的不断变更,而循环往复的,主要是由以下4个步骤来组成的,首先数据库的设计呢,

根本上来说是软件系统的设计,所以和所有的软件工程是一样的,我们要对产品的实际需求进行分析,形成需求分析

文档,这一步是非常重要的,是否能够设计出符合实际需求的高效的数据库需求,很多存在数据库性能的数据库呢,

都是由于一开始,没有做好需求分析,所造成的,可以想象一下,如果我们的需求分析呢,做的不全面,就一定会造成产品

上线后,频繁的修改数据库结构,这样的问题,这样就会变成原本很高效的数据库呢,在多次修改后,就变成难以使用了,

严重的情况下呢,上面提到的数据冗余啊,维护异常,这样的问题,在需求分析阶段呢,主要工作就是要全面了解产品设计

对数据库设计的存储需求,调查,收集,和分析所要开发的产品,在数据库中,存储需求,以及数据的处理需求,而数据的

安全性和完整性,数据存储需求显而易见,是指数据库要存储什么样的数据,对于数据会有什么样的特点,而数据处理

需求呢,是指我们如何对数据库进行读取,或者修改以完成产品的功能,以及对数据处理的响应时间又什么样的要求,

处理的方式是批量处理呢,另外就是对数据的安全性和完整性,有什么样的需求,还包括数据的生命周期等信息,以上就是我们

要求的需求分析阶段所要完成的工作,说起来很简单,但是从事过实际工作的人都知道,需求分析阶段,有时是很难的一个阶段,

因为需求提出的业务人员呢,通常对技术并不了解,所以有时候很难知道技术方案是什么,而技术人员对业务可能不太了解,

所以工作起来很费劲,所以这就要求我们在这一阶段呢,多做很多的工作,要反复的跟业务人员沟通,确认需求的真正内容

是什么,如果我们顺利的完成了需求分析,我们就可以进入数据库的第二个阶段

也就是逻辑设计阶段,在这个阶段我们不用关心我们所使用的是什么数据库,什么存储引擎,等于在这个阶段呢,

要做的就是搞清楚,数据实体之间的逻辑关系,要解决数据冗余和数据维护异常的话,重点是在这个阶段,所以这个阶段呢,

我们想要做的工作呢,不但重要,而且会直接影响以后的数据处理和数据存储方式,解决了数据冗余和数据维护异常,且高效的

数据库逻辑设计呢,并不容易,不过好在这个阶段呢,我们有些秘籍可以参考,这些秘籍呢,就是所谓的数据库的三大范式,也提到过,

按照要求来进行数据库的设计呢,可以最大程度的解决数据库的冗余,和维护异常,这样的问题,对于什么是数据库的三大范式呢,

相信大家多少有些了解,如果还不了解的话,也不用着急,我们下面马上就回提到,完成了第二阶段的工作呢,现在我们就要考虑我们的

业务所使用的数据库类型

这个就代表了我们要进入物理设计阶段,在这个阶段呢,我们要做的就是要根据我们使用数据库的特点,进行表结构的设计,

目前我们使用数据库的种类呢,有很多,常见的关系型数据库有ORALCE,SQLServer,MYSQL,等等,而非关系型数据库呢,选择的

就更多了,比如大家知道的mongo,redis,hadoop等等,不过说实话,大多数情况下呢,由于开发人员绝对使用什么样的数据库的

情况并不多,特别是回到我们课程中来说,我们只能使用MYSQL,不过对于MYSQL来说呢,有很多的需要我们选择的东西,比如使用

什么样的存储引擎,表中的类使用什么样的数据类型,这个都是要在物理设计阶段来决定,特别是存储引擎和列的数据类型的选择呢,

对数据库新能的影响是很大的,存储引擎已经反复提到了多次了,这里还是要再强调一下,大家使用innodb存储引擎,而表中对于

数据类型是如何选择的呢,放到下面来进行讲解,完成了数据库的物理设计,实际上呢我们就已经完成了现阶段数据库设计的工作了,

不过后续的工作中呢,我们还要不断地对数据库结构进行调整,维护,和优化

以及数据字典维护这种工作,最主要的可能就是对索引进行优化和维护了,这些内容可能在后面的内容呢,都会

有所涉及,所以呢还是把具体的内容,到后面来说,前面提到了很多次数据库设计的范式,下面我们就给大家来讲一下

什么是数据库设计范式,所谓的数据库设计范式呢,说白了就是我们在进行数据库设计时,所遵循的一些规范,只要我们

按照规范的要求呢进行设计,就可以设计出没有数据冗余,和维护异常的数据库的结构,当然了,关于数据库设计的规范

有很多,不过通常来说呢,数据库规范又称之为数据库三大范式,当然呢还存在其他的范式,但是在一般情况下,你只要做到

满足,前三个范式的要求就可以设计出,符合我们使用的数据库了,大家要注意,这里呢,这里只说符合需求的设计,并不是说

性能最好的设计,是因为呢,我们也不能完全按照范式呢,来进行设计,因为我们在设计数据库时呢,还要考虑业务的实际使用的情况,

所以有时候也要做一些,违反范式的设计,不过我们还是先来看一看,数据库的三大范式,首先我们先来看第一大范式,第一范式

呢,最基本的数据库设计范式,基本上所有数据库设计呢,都是符合第一范式要求的,符合第一范式设计的表呢,有以下的特点,

首先,数据库中表中所有字段,都具有单一的属性,也就是说,不能再进行分解,并且这些单一属性的列呢,是由基本的数据类型,

比如整形啊,浮点型啊,字符型啊,这些数据类型所构成的,最后一点就更简单了,就是我们所设计出来的表呢,都应该是简单的

二维表,以上三点呢,基本上是所有数据库设计,都可以满足的,然后我们演示来说吧,我们可以看一下

在我们的selectcourse选课表中,这张表就是符合第一范式的表,因为完全符合以下三点的要求,首先,

这个表每一列都是不可拆分的,其次呢,这个表中所有列呢都是由最基本的数据类型所构成的,最后呢,这张表是

一张二维表,第一范式的要求也说过了,这张表还是存在数据冗余,和数据维护异常这样的问题,所以只满足第一范式

的设计呢,还是不够的,所以我们要继续看看第二范式,数据库设计的第二范式,是在第一范式基础之上定义的,也就是

说,符合第二范式要求的表呢,首先要满足第一范式的要求,第二范式呢,要求一个表中,只具有一个业务主键,也就是说

符合第二范式的表中呢,不能存在非主键列,只对部分主键的依赖关系,当然呢非主键列呢,只对部分主键有依赖的这种

情况呢,只能出现主键是复合主键的时候,如果我们的主键是单一主键,那么这个表的设计呢,就一定是满足第二范式要求的,

我们还是以学习讲课表为例,来为大家演示一下,如何改进才能把这个表设计的符合第二范式要求

首先我们来看目前我们的selectcourse表的主键是一个复合主键

show create table selectcourse;

大家可以看到,这里是学号,和课程名两列组成的复合主键,所以是不满足第二范式要求的,我们再看学分这一列,

实际上只和课程名称是有关系的,所以这样看来,就出现上面所说的,非主键列值,和部分主键存在依赖关系,所以我们

说这个表是不符合第二范式要求的,所以我们可以对这个表进行拆分,使其符合第二范式的要求,我们这里可以把这张表

拆分为三张表,分别是学生表,课程表,和学生课程选课关系表,可以看到,selectcourse拆分为三张表,包括学生表

学生表

show create table student\G

课程表,这就是拆分后的两种表,大家可以看到

两个表都只有一个主键了,所以这两张表一定是符合第二范式要求的,而第三张表呢,selectcourse存在非主键,

所以也是符合第二范式要求的,我们现在来看看第三张表,这就是第三张表

show create table studycourse\G

学生和课程中的关系表,那么我们还来看看第三张表是否还存在数据冗余,和维护异常这种情况,我们可以看到,

对于course,和studycourse表已经解决数据冗余,维护异常的问题,如果我们增加新的课程,只要在course表中进行

增加,相应的记录就可以了,不用去管是否有学生来选了这门课程,但是对于study表存在一个问题,我们来看看study

表的具体内容是什么

select * from study;

大家可以看到,学院名称和学院电话,数据冗余的问题,现在这张表已经符合第二范式的需求了,所以我们就要继续

来看这张表符不符合第三范式的要求,那么所谓的第三范式呢,是指每一个非主的属性,不可部分依赖于,也不可传递依赖于

业务主键,也就是在第二范式的基础上,消除了非主属性对主键的传递依赖,这个定义并不是很容易理解,所以我们还是来

看一下实际的表,这样大家就可以明白,什么叫传递依赖关系了

前面在介绍第二范式的时候呢,我们已经说过了,selectcourse表拆分成三张表以后,课程表和学生选课关系表呢,

这两张表就已经解决数据冗余和数据维护异常问题,现在唯一存在数据冗余和数据维护异常的呢,就是学生表,所以我们看看

第三范式是否可以解决学生信息表所存在的一些问题,我们先来看学生信息表的表结构,上面我们已经查询过了,我们可以看到,

学生信息表中有一个组件是学号

所以这是符合第二范式的,但是同时这张表中呢存在上面的依赖关系,学号可以确定学生所在的学院,而学院的

地址呢,与学院又有依赖关系,那学院与学院地址呢对于学号来说,它是具有传递的依赖关系的,所以说学生信息表呢,

是不符合第三范式的要求,那么我们现在就要对这张表进行改造,符合第三范式的要求,所以依然要把这张表进行拆分,

这里我们就把学生信息表拆分成两张表,分别是学生信息表,与学院信息表,那么下面我们来看一看这两张表的表结构,

首先来看一下学生信息表的表结构,我们叫study_info,大家看,这张表我已经建好了,还没有建立,那我们自己建立吧,

我们要建立一个学生信息表,原来学生信息表的一部分信息,首先我们还是以学号来作为他的主键,下面我们还要包括学生

姓名这一列,这些都是在原来学生信息表存在的列,接下来就是生日列,以及学院名称,主键同样是学号,这里就完成学生信息

表的建立

create table study_inf(study_no int not null,study_name varchar(10),birth_date timstamp,

school_name varchar(20)),primary key(study_no);

同时我们还会把原来的学生信息表再拆分出一个表来,学院信息表,这里面的列比较简单,首先有学院的名称,

以及学院的电话,他的主键是学院名称,大家可以看到,经过这样拆分之后呢

create table school_inf(school_name varchar(20) not null,school_tel varchar(10),

primary key(school_name));

desc study_inf;

符合第三范式的需求了

desc school_inf;

首先这两张表呢都不会存在数据冗余,和数据维护异常,同时也就是说,我们对这些表应用到第三范式呢,

就基本上解决了数据冗余和数据维护异常的问题,通过以上的说明呢,相信大家对数据库三大范式有了一定的

认识,我们在数据库逻辑设计阶段呢,主要解决的问题呢,是要消除表中所存在的数据冗余和数据维护异常的问题,

为了让大家对数据库的设计有一定程度的了解,我们就一个实际的需求为例呢,来一起完成这个需求的逻辑设计和我

物理设计,这样大家呢对数据库表设计阶段就更加的清楚了

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值