数据库作为使用频率最广的中间件,作为一个IT工程师,就算不打算从事数据库开发或者做DBA,也应该掌握其基础的知识、原理与基本的使用。
成都创新互联公司提供网站建设、网站设计、网页设计,品牌网站建设,1元广告等致力于企业网站建设与公司网站制作,十年的网站开发和建站经验,助力企业信息化建设,成功案例突破千余家,是您实现网站建设的好选择.为此,本篇开始,尝试对数据库的基本知识与原理进行讲解。
数据库的类型
关系型数据库:以前,市面上最常见,使用最广泛的数据库,叫做关系型数据库,例如大名鼎鼎的Oracle、SQL Server(微软的,也叫MSSQL)、Mysql、DB2(IBM的),都是关系型的数据库。由于它使用最广泛、最常见,每个入门的人员都必须要掌握,因此接下来的几篇《数据库基本知识与原理》都会围绕关系型数据库先展开叙说,后面有机会再介绍No SQL的数据库。
非关系型数据库:叫作No SQL数据库,其实只是个统称,有各种的列式数据库,KEY VALUE值的数据库。
什么是关系型数据库?
关系型数据库的本质就是一张张有关联关系的二维表。
二维表意思就是有行与列组成的表格,与EXCEL表里面的单个工作表(sheet)是一个意思。与EXCEL表里面每个独立的工作表唯一的不同,是关系型数据库中的表格,都是有关联关系的。
假设你的EXCEL表里面有3个工作表分别叫A、B、C,如果表A有A1、A2、A3列且有内容,B表里面有B1、B2、B3列且有内容、C也有C1、C2、C3列且有内容,而B2的每个单元格其实是从A2列对应行的单元格里面引用过来的,而C3的单元格也是从B3里面引用过来的,那么其实A、B、C三个表格就有关联关系了。那么这样的EXCEL表就更加接近关系型数据库里面的表了。
只不过,数据库里面的,没有规定B2的某个单元格一定要引用A2里面对应行的单元格,可以是任意一行的单元格的值。
为什么要用数据库?
为什么要用数据库而不用EXCEL表?这是一个重要的问题。如果都不知道一个东西有什么用,能解决什么问题,那么花时间学习一个新东西干嘛?
首先,在数据量很少的情况下,直接用EXCEL表格也是没有问题的。
但是当数据有2万行左右的时候,发觉一台K22的联想笔记本用EXCEL来打开,可能都要7~8秒才能打开了,这基本上已经到达了用户可以忍受的延迟时间的极限了,如果一个用户打开一个网页,7~8秒都打不开的话,估计他会选择叉掉这个网页,然后去其他网站去了。
因此,当数据量很大的时候,我们发觉EXCEL已经无法满足我们的性能需求了,因此需要使用数据库。
除了性能之外,使用普通的二维表,还有以下几个问题:
数据冗余:大量同样的数据重复存储,我们以下面一张很简单的学生选课记录表为例。
序号 | 学号 | 学生姓名 | 性别 | 联系电话 | 课程名称 | 授课老师 |
1 | 2019063001 | 张三 | 男 | 13900000001 | 语文 | 孙七 |
2 | 2019063001 | 张三 | 男 | 13900000001 | 数学 | 周八 |
3 | 2019063001 | 张三 | 男 | 13900000001 | 英语 | 吴九 |
4 | 2019063002 | 李四 | 男 | 13900000002 | 语文 | 孙七 |
5 | 2019063002 | 李四 | 男 | 13900000002 | 数学 | 周八 |
6 | 2019063003 | 王五 | 女 | 13900000003 | 数学 | 周八 |
7 | 2019063003 | 王五 | 女 | 13900000003 | 英语 | 吴九 |
8 | 2019063004 | 赵六 | 女 | 13900000004 | 体育 | 郑十 |
看到“张三”选了“语文、数学、英语”3门课程,但是“张三”每选修一门课程,他的“学号”、“性别”、“联系电话”等数据就会被重复存储1次,如果有100条关于他的记录,这些数据就会被重复100次。这样的数据冗余会带来如下问题:
1)浪费存储空间。
2)导致增加了检索有效数据的时长(因为数据总量增多了,搜索的时候遍历的数据增多了)。
删除异常:想删除1个数据,结果会导致不想删的数据也被删除了。(依然以上述例子为例)
序号 | 学号 | 学生姓名 | 性别 | 联系电话 | 课程名称 | 授课老师 |
8 | 2019063004 | 赵六 | 女 | 13900000004 | 体育 | 郑十 |
如果“赵六”退学了,我们想要删除赵六的数据,但是我们会发现只有“赵六”选修了体育课。
这时候一旦删除了“赵六”,“体育”的课程,“郑十”这位授课老师,都会无故从这个表格被删掉,这就叫删除异常。
修改异常:修改一个数据,却需要修改多次,并且如果修改不安全,会导致数据不一致。
序号 | 学号 | 学生姓名 | 性别 | 联系电话 | 课程名称 | 授课老师 |
1 | 2019063001 | 张三 | 男 | 13900000001 | 语文 | 孙七 |
2 | 2019063001 | 张三 | 男 | 13900000001 | 数学 | 周八 |
3 | 2019063001 | 张三 | 男 | 13900000001 | 英语 | 吴九 |
如果“张三”更换了手机,修改手机号,张三有多少条记录就需要修改多少次,写入操作的开销是大于读操作的,会带了额外增加的开销,并且如果修改不完全,会导致表格中“张三”的联系电话不一致。
插入异常:应该插入的数据无法插入。
序号 | 学号 | 学生姓名 | 性别 | 联系电话 | 课程名称 | 授课老师 |
生物 | 张强 |
数据库是怎样处理上面数据的?
数据库会将上面的一张二维表,拆分为多张具有关联关系的二维表进行存储。注意关键词有2个,1是多张,2是有关联关系。如下:
1)先将1张二维表拆分为多张二维表
学生表 | ||||
序号 | 学号 | 学生姓名 | 性别 | 联系电话 |
1 | 2019063001 | 张三 | 男 | 13900000001 |
2 | 2019063002 | 李四 | 男 | 13900000002 |
3 | 2019063003 | 王五 | 女 | 13900000003 |
4 | 2019063004 | 赵六 | 女 | 13900000004 |
课程表 | ||
序号 | 课程ID | 课程名称 |
1 | 0001 | 语文 |
2 | 0002 | 数学 |
3 | 0003 | 英语 |
4 | 0004 | 体育 |
老师表 | ||
序号 | 老师ID | 老师姓名 |
1 | T0001 | 孙七 |
2 | T0002 | 周八 |
3 | T0003 | 吴九 |
4 | T0004 | 郑十 |
2)为上面独立的表格,创建关联关系,使得他们之间关联起来
选课记录表 | ||
序号 | 学号 | 课程ID |
1 | 13900000001 | 0001 |
2 | 13900000001 | 0002 |
3 | 13900000001 | 0003 |
4 | 13900000002 | 0001 |
5 | 13900000002 | 0002 |
6 | 13900000003 | 0002 |
7 | 13900000003 | 0003 |
8 | 13900000004 | 0004 |
授课记录表 | ||
序号 | 学号 | 课程ID |
1 | 0001 | T0001 |
2 | 0002 | T0002 |
3 | 0003 | T0003 |
4 | 0004 | T0004 |
按照上述处理,有什么效果?
1张表,拆成了上面的5张表,好像把简单的问题复杂化了。弄这么复杂,到底有什么作用呢?解决了什么问题?
1、解决数据冗余:
再看一下学生表,同一个学生的信息只存储了一次,节省了空间、提升了查找性能,解决了数据冗余的问题。
2、解决删除异常:
再看一下学生表,如果此时“赵六”退学,需要删除“学生表”的“赵六”数据,此外,与“学生表”的“学号”字段有关联关系的“选课记录表”,会自动删除“赵六”学号(2019063004)的行,即第8行,就完成操作了。而“体育课”与体育课的授课老师“郑十”数据会完整保留在“课程表”与“老师表”中,不会被异常删除,解决了删除异常的问题。
3、解决修改异常:
现在“赵六”更换了手机,只需要在学生表中,更新“赵六”-“联系电话”的字段,其他表格根本没有保存这个信息,也就是说只需要进行一次的写操作就完成了,不会出现数据不一致或者多次写操作,解决了修改异常。
4、解决插入异常:
如果现在新增了“政治课”,没有授课老师与选修的学生,只需要在课程表里面增加一行记录“政治课”就可以了,其他表格需要写入。不会出现像之前没有授课老师或者没有选修学生,连新增的课程都无法插入的问题,解决了插入异常。
综上,我们需要使用数据库,来解决上面几个普通二维表无法解决的问题。
上面说的,大部分都是功能上需要使用数据库的原因,下一篇我们再来讨论一下从性能上,为啥要使用数据库。
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。
网站栏目:【理论研究】数据库基本知识与原理系列01-数据库的基本原理与-创新互联
当前地址:http://lswzjz.com/article/iddgs.html