当前位置： 数据库原理与应用论文-应用t检方法进行数据统计分析研究的论文
刚刚接触数据库的时候，我也有和你一样的困惑。现在想起来，主要还是因为教学模式存在一定的问题，没有把来龙去脉讲清楚，没头没脑的灌输知识，最后不知为何而学，没动力，学着也痛苦。
很多老师也没有想清楚这一点，照本宣科罢了。毕业几年之后，现在我也算是个数据库领域的工程师，来分享我个人的一点见解，结合我个人学习的经验和现在的理解谈谈为什么要学习数据库。
简而言之，因为你学的是《数据库系统原理》，而不是《数据库系统应用》，更不是《SQL从入门到精通》，只有掌握了原理，才能了解当前的数据库是如何实现的，存在哪些问题，进而不断优化，突破当前数据库系统的局限性，做出更优秀的数据库。
下面的内容会比较长，我会利用一些比较基础地例子和常见事物的类比，给你一个从感性到理性的认识，了解引入这些概念带来的优势以及这些概念的局限性。其中也包含很多我个人的理解，不一定对，权当抛砖引玉，是希望能够对你有所帮助。
什么叫数据库？
常说，要“知其然还要知其所以然”。从你的提问来看，你已经初步做到了“知其然”，对数据库的功能有了一个初步的了解，知道数据库的基本功能就是“增删改查”。但是你要知道，关系型数据库只是数据库中的一种。广义上，任何能够满足对数据进行“增删改查”功能的程序，都叫数据库。这世界上就有很多数据库不是关系型数据库，你一定听说过『NoSQL』这个概念. 搜索引擎文档的存储、多媒体和地理信息的数据库，往往都不是使用关系型数据库。另外，最近正逐渐流行的图数据库，也是另一个门类。
这里插播几个趣闻吧，远在计算机庞大而夸张，数据库理论尚未普及的年代，就有了一些充满智慧的数据库技术的应用。下面举两个令我惊叹的例子。
在刘慈欣的小说《三体》中，有一段非常经典的人列计算机描写：
下面，贯穿人列计算机的系统总线上的轻转兵快速运动起来，总线立刻变成了一条湍急的河流．这河流沿途又分成无数条细小的支流，渗入到各个模块阵列之中。很快，黑白旗的涟漪演化成汹涌的浪潮，激荡在整块主板上。中央的CPU区激荡最为剧烈，像一片燃烧的火药。突然，仿佛火药燃尽，CPU区的扰动渐渐平静下来，最后竟完全静止了，以它为圆心，这静止向各个方向飞快扩散开来，像快速封冻的海面，最后整块主板大部分静止了，其间只有一些零星的死循环在以不变的节奏没有生气地闪动着，显示阵列中出现了闪动的红色。
——《三体》·刘慈欣
书中的描写通过形象地对计算机系统微观世界的类比，展示了一个宏大的场面。但是实际上，小说中用三千万人打造的人列计算机实在太浪费资源了，总共三千万士兵，一个人只表示一个比特位。实际上，以人的智商完全可以执行更复杂的指令，让这套系统的运转更加高效。
先来看一张图吧，估计第一眼大家一定不知道这个图是干什么的——这是1920年代的美国指纹数据库：美国“指纹工厂”：2万人管理着全国7000万指纹(组图)。
没错，现在我们去美国领事馆签证，或者入境美国的时候摁的指纹信息，早在100年前美国就开始收集了。这是现实版的人列计算机啊！
严格来说， 这个数据库不叫关系型数据库——至少，你不能简单地用MySQL去替代人力的查询。至于什么是关系型数据库，我们稍后再说。
下面来讲另一个，一个叫Calvin Mooers的计算机科学家，这个Mooers跟那个提出摩尔定律的 Moore不是一个摩尔。早在二战期间，电子计算机还有两层楼那么大的时候，他就发明了一套编码系统叫做Zatocoding，用来索引海量的文档——而且是纸质文档。
怎么做的呢？它先把相关文档的边缘统一打上洞：
每一个孔代表的是一个布尔表达式，也就是一个答案为『是』或者『否』的问题。举个例子，这些文档是关于某些天天气状况的，那么每个孔的对应如下问题：
是否下雨
气温是否大于30℃
气温是否小于0℃
……
以此类推，然后，对于每一个答案为『否』的孔，将其剪掉：
最后把所有文档用线串起来，有孔的穿孔，没孔的穿洞，就像这样（示意图并没有画全）：
最后这所有文档将被40条线串起来。然后，当需要查找某个问题为『是』的文档，只需要将其对应的绳子给提起来即可（因为回答为否的洞已经被剪开，提绳子的时候会掉下去），这样绳子上挂着的就都是相关的文档了。同时，这个索引还支持逻辑或运算。利用布尔运算的定律，支持逻辑与运算也是非常简单的。
大名鼎鼎的bloom filter就是对这个原理的总结提炼。
由此可见，支持增删改查的数据库未必都有表数据库原理与应用论文，未必都是关系型数据。
关系型数据库为什么入选计算机科学与技术的基础课程？
因为它“科学”，换句话说，理论发展得比较完善。尚处在发展中，有大量未知问题的领域不太适合作本科基础教学，那种感觉就像高中学物理和学化学的一样，物理把为数不多的几个定理和数据组合一下总能得到结果，而化学感觉是一堆『拍脑袋想出来的规则』加一堆『被疯狂打脸的例外』……这里不是我故意要『黑』一下化学，大神Matrix67也有同样的感觉：
之所以在高中时选择学文科，是因为他对化学“很不认同”。高一分专业考试时，他的化学不及格，为了进实验班，只好学了文科。“化学这门学科实在是太不科学了，缺乏内在美。”一提起化学，他总是不住地摇头。
感兴趣的可以看看这个帖子里化学大神们的讨论：为什么中学化学给人一种不严谨的感觉？
注意我这里并不是要否定化学的科学性，因为即便是物理在深入到尚未完善的领域之后依然是一对规则加一堆例外——二十世纪初当人们一度认为物理学已经完备的时候，天空飘来了两朵乌云，然后引起了物理理论的一场革命。我这里只是想用两个学科学习的直观感受来说明从关系型数据库入手对学生来说更容易。
另一方面，教学配套材料很多，对于学生入门和老师教学来说非常方便，可以让教学更关注于本质——数据库系统的构建思想。我以为，数据库原理课程的精髓，应当是数据库构建的过程，而数据库本身的使用反而是最不重要的一环。
我曾经在知乎上讨论过另一个问题：大学编程入门为什么不以C#作为首选？其实和这个问题有点类似。你说用C#来教操作系统我支不支持，如果有好的配套材料，比如用C#写好的教学操作系统，我当然支持。但是，现在绝大部分的操作系统底层无一例外是C写的，绝大部分操作系统课的课程作业也是C语言，工业界绝大部分系统级底层应用也是用C写的，而且操作系统课程的核心恰恰不是语言，而是架构的设计——既然如此，何必舍本逐末，舍近求远，把目光放在C还是C#上呢？
那么回到这个问题，同样的，学习数据库原理的目的是什么，是怎么使用吗？一部分目的是，学会了原理能够更好的使用；但是，另一个更重要的目的，是在现有的数据库解决方案不能满足需求的时候，如何利用在构建关系型数据库过程中积累的方法经验，开发在特定场景下更好的数据库应用。
先看看关系型数据库是什么——它是对一类数据库设计经验的总结和设计方法的抽象，以期得到一个通用的数据库的解决方法。
打个比方，小学奥数题鸡兔同笼问题：
有若干只鸡兔同在一个笼子里，从上面数，有35个头，从下面数，有94只脚。问笼中各有多少只鸡和兔？
小学的解法有很多种：
假设法
假设全是鸡：2×35=70（只）
鸡脚比总脚数少：94－70=24 （只）
兔子比鸡多的脚数：4-2=2（只）
兔子的只数：24÷2=12 （只）
鸡的只数：35－12=23（只）
假设全是兔子：4×35=140（只）
兔子脚比总数多：140-94=46（只）
兔子比鸡多的脚数：4-2=2（只）
鸡的只数：46÷2=23（只）
兔子的只数=35-23=12（只）
抬腿法一
假如让鸡抬起一只脚，兔子抬起2只脚，还有94÷2=47（只）脚。笼子里的兔就比鸡的脚数多1，这时，脚与头的总数之差47-35=12，就是兔子的只数。
抬腿法二、抬腿法三……
你看，同一个问题，张三有张三的解法，李四有李四的解法。于是聪明的王五在观察所有方法之后，做了一个总结，解决这个问题我们可以使用一元一次方程：
解：设兔有x只，则鸡有(35-x）只。
4x+2(35-x)=94
解得 x=12
又进一步，有人发现，牛吃草问题也可以用方程解，于是在这基础上发展了二元一次方程，甚至N元一次方程。进一步，当研究到更复杂的问题的时候，比如抛物线，行星轨道，发现一次方程不够用了，于是又进一步扩展出了高次方程……
于是，我们的代数系统渐渐发展，变成了如今这样庞大的体系，也足够应付相当一部分应用场景：小商小贩的价格计算、金融模型、天梯轨迹的预测……
数据库也是类似的发展轨迹。
@wivwiv
在回答里提到这样一个例子：
去年作为大三学生去旁听毕业答辩，某同学作品是一个安卓端的英汉词典，支支吾吾吞吞吐吐说不清他数据的存储方式，老师只好降低难度让他把 Apple 的中文改为 梨。
他一番摸索，工程下找到了一个 txt 文件，ctrl + f 来把这个翻译对照改了。懂行的憋住笑，不懂行的觉得没毛病，答辩老师一致拍案叫绝，遂过。
不懂基本的数据库，你以后得工程要存数据是不是也这样?
其实，这个同学的英汉词典采用这样的存储方式并没有太大的不妥，这恰恰是数据库的某种意义上的基本形态——二维表，也就是关系数据库中的『关系』，应付这种场景足矣。
那么我们先来看看关系型数据库到底试图解决一个什么样的问题？ACID：
这里我就不详细展开了，需要了解的去看课本。在这其中，『一致性』是重中之重。
为什么要学范式？
在你困惑的那些概念中，各种所谓的『范式』很大程度上就是为一致性提供服务的。
就拿1NF（关系中的每个属性都不可再分）来说吧，乍看好像没什么用，但是上次我看到这个问题的讨论就忍俊不禁：如何劝说后端开发不要拿变量命名 JSON 的key值？
@max poon
的回答：
问问他数据库原理与应用论文，如果以后需要加多一个author属性，他准备如何拓展。
@Axetroy
上一篇 
