下载掌阅APP，畅读海量书库
立即打开
在1.1节中，瑟琳娜、奎妮和劳伦斯为大家介绍了3种关于SQL的理解，希望他们每个人的阐述都能为你提供多样化的启发。然而不得不说，SQL的主流定义依然是：一门用来与关系数据库沟通的计算机语言。正因如此，另一些具有讨论价值的问题也随之而来：究竟该如何理解数据库呢？除此以外，本书将着重介绍的MySQL扮演的又是什么角色呢？
对于如何理解数据库，在讨论这个问题之前，你们联想到了哪些关键词呢？
我能想到的关键词是“关系数据库”和“表”。
我联想到的关键词是“太平洋”、“捕捞”和“网”。
哦？“太平洋”、“捕捞”和“网”？这听起来可真是有趣！说实在的，数据库给我的印象就是一位头发稀少的中年男子，他不苟言笑，做事一板一眼，缺少幽默感，日常穿着除了这一件就是另一件……
哦，拜托，请大家千万不要把数据库的肖像想象成某位数学教师，我们可能都不太擅长和数学打交道，毕竟那些晦涩的计算规则会令人感到头大。可是你要知道，数据库存储的信息并不仅是用于加减乘除的数字。顾名思义，数据库（Database，DB）就是存储信息数据的集合。所以，从广义上讲，我认为只要符合该描述的都可以被视作一个数据库。
没错，比如一支清凉可口的炫彩冰激凌，它就可以被视为一个广义上的数据库。因为你送进嘴里的每一口都含有各种可食用成分，例如蜂蜜、奶油、果酱等。再比如一辆由各个零部件组成的小汽车，它为什么不可以被视为一个数据库呢？从最初的工业设计到装配流程和焊接工艺，再到耐久性测试，可以说它浑身上下都沾满了信息数据，只不过我们站在消费者的角度察觉不到罢了。
那么按照这种思路来看，我想广义上的数据库在我们的日常生活中随处可见：一只整装待发的行李箱、一份糟糕透顶的成绩单，以及一锅乱炖的黑暗料理。
没错，就连一根头发丝里都含有数不清的信息数据，我相信这正是劳伦斯的看法！不过话说回来，存在于生活中的广义数据库与大家将要接触到的关系数据库（Relational Database, RDB）之间的区别在哪里呢？我们不可能拿着鼠标和键盘对着一根头发丝进行操作吧？
当然不会。首先，关系数据库中含有的信息全部源于我们的生活，这就像餐桌上的饭菜全都源于大自然一样。然而没有人胃口好到可以咽下大自然的一切产物，比如火山灰和花岗岩。同样的道理，广义上的数据库含有的信息过于丰富，以至于超出了我们的需要。那么在这种情况下，我们就只会从中挑选有记录价值的信息。举例来讲，如果一家货运公司想要了解送货员的配送效率，那么时间和路线的选择才是关键。至于送货员在送货途中打了多少个喷嚏，发了几句牢骚，以及踩了多少脚油门和刹车，这些都是无关紧要的次要信息。这就好比渔民们只会在太平洋捕捞有经济价值的沙丁鱼和红鲷鱼一样。
除了选择性记录，记录形式也是关系数据库的一大特点。事实上，我们会对采集到的目标信息数据进行整理和分类，然后将它们“塞”进表（Table）中。没错，从这个角度来看，在关系数据库中，表才是信息数据最直接的载体。也就是说，关系数据库是通过表来间接存储信息数据的。
不好意思，我有一个疑问。有那么多种记录信息的方式可以选择，比如文本、图片、视频，甚至录音，为什么关系数据库偏偏要选用表来装载信息呢？
对于这个问题，只要你从侧面了解了表记录信息的优点，自然就会清楚其中的原因。现在请大家来观察这样一张简易表。
这张表看起来就像一张结构化的清单，它的显示布局就如同一张网：垂直分布的是列，水平分布的是行。
描述得非常贴切！用“表”这张网来捕捞数据的过程就是对广义数据库中的目标信息做表格化处理的过程。正如大家所见，列在纵向体现一组数据的分类归属，行在横向呈现一组数据的对应关系。事实上，正是由于具有分门别类记录信息的特点和优点，表才成了关系数据库中信息载体的不二选择。
正是这样。一方面，表可以让我们获得整洁的显示效果，另一方面，因为表的结构固定且单一，所以它为后续的数据调用和信息维护都提供了很大的便利。现在我们只需将这张表引入一个直角坐标系，大家就能清楚地感受到这一点。
这样一来，表中的每一项数据（单元格）都能通过横、纵坐标信息进行定位。例如“杨曼桢”就是（姓名，101），“C班”就是（班级，103）。事实上，大家在日后的实际操作中，无论是想要调取表中的数据，还是准备对表中的数据进行修改或者删除，都能通过类似的方式实现，也就是将目标数据对应的横、纵坐标当作查询条件，并将其嵌入固定的SQL语句。不妨举几个简单的小例子进行说明。
1. 如果想要查看学生表中所有学生的姓名信息，那么对应的SQL语句为：
2. 如果想要查看学号为102的、名叫何世钧的学生对应的一整行信息，对应的SQL语句可以是：
也可以是：
3. 如果想要单独查看何世钧对应的班级，那么班级就将成为一项追加条件被嵌入上述语句：
啊，原来就是这么简单的事呀！将已知信息变成查询条件，并将其嵌入SQL语句告知数据库，我们就能得到想要的结果了。
对比来看，如果记录信息的载体换成图片或者文本，那么当我们准备从中调取数据时，相应的指令可能就不太容易用简单且固定的语句进行描述了。我发现了，表的结构真的让它很适合担当此位！不过话说回来，既然表是信息数据最直接的载体，各类信息数据都是存储在表中的，那么为什么不直接称“表”为“数据库”呢？
这是一个好问题！我也有一个类似的问题要请教你。请问，詹姆士，既然地球才是我们人类赖以生存的家园，那为什么不说我们处在地球系，而要说我们处在太阳系呢？
哦？这是因为地球是属于太阳系的呀！除了地球，太阳系中还有其他7大行星在围绕太阳运转：水星、金星、火星、木星、土星、天王星和海王星，而冥王星在2006年被重新划为矮行星，我想我应该没有记错……
当然正确！我们都知道，包括地球在内的8大行星都拥有属于自己的运行轨道，这一方面是因为它们各自都与太阳之间存在万有引力（主要原因，太阳质量占整个太阳系总质量的98%），而另一方面也与它们彼此之间存在万有引力有关。同样的情况也适用于此。在日常操作中，为了用表来完整地记录某一事件产生的信息数据，我们可能要创建多张表才能满足记录需要。也就是说，如果我们将某一事件视为太阳，那么围绕这个中心主题而运转的表往往不唯一。另一方面，也正是因为各张表在合力记录这一事件产生的信息数据，所以它们彼此之间存在关联，这就好比8大行星之间也存在万有引力一样。
我想我明白了，这是因为各张表也需要一个共同的载体，这个载体就是关系数据库。不过抱歉，我还想知道为什么劳伦斯表示，往往要创建多张表才能满足记录需要？难道这是因为单张表的存储空间不够吗？
同样地，要想回答这个问题，我们还是先请大家来观察一张表。
我们对学生表中的数据进行了扩充，进而让它显示出了每位学生对应的学科和成绩。大家可以看到，由于每一位学生要学习的科目都不止一个，所以就出现了一对多的情况，以至于表中出现了大量的重复数据。
大家可以看到，如果将某一事件产生的所有信息数据都硬塞进一张表中，那么这张表在体积和呈现效果上都不会太理想。事实上，在日常操作中，如果我们想全面地记录某一事件产生的信息数据，往往需要创建多张表。原因是单张表一般难以处理好大量数据间的对应关系，以至于影响我们的使用和查看。因此，我们就需要对数据进行合理的拆分，将它们填充到不同的表中，就像这样——
啊，我瞧见了。这里又单独创建了一张表，它专门用来容纳学生们的考试成绩。我想我可以理解其中的奥妙——不要把所有的鸡蛋都放进同一个篮子。
因为数据的记录往往会随着事件的发展而不断增加，这不仅包括对已有信息的扩充，还包括增加新的信息类别。想象一下，学校的急性子校监在一开始认为学生表中只需要体现姓名、性别及班级等基础信息就可以，然而当他将学生表制作完成以后，校长却表示还要额外记录学生们的学习科目和考试成绩。没错，在这种情况下，如果校监想将这些信息填充进原有的学生表中，那么他的工作量将会很大，因为整张表的结构会发生变化，而且他还得将新信息一一录入其中，并附带着让旧信息重复出现。可如果他另起一张表来单独记录学科和成绩的话，那就是另外一回事了。毫无疑问，由于原学生表的结构和数据不会发生变化，所以校监的工作量也会大大降低。在实际操作中，我们也会遇到类似的情况。
正是如此，理解得非常到位。要知道，学习与实际运用是两码事。在学习阶段，由于大家操作的对象都是编排完善的表，而且这些表中的数据是为了掌握技能而设计的，因此同学们会认为这一切都是理所当然的。然而，在实际操作中并非如此，因为表和数据要客观体现事件的真实发展与变化，所以对表的设计及对数据的编排要尽可能地方便日常使用和维护。
通过以上的讨论，相信大家就会知道：在有些情况下，会创建多张表来共同记录数据信息，它们各司其职但又彼此关联，因此它们又被称为关联表。如果我们把一个数据库比作一家公司，那么关联表就是这家公司的各个部门。虽然具体分工不同，但它们都是为了公司的发展和壮大而存在的。
事实上，理解关系数据库的重点在于理解“关系”一词。这种关系主要是指对应关系。例如，狮子属于猫科，斑马属于马科，而海豚属于海豚科，但它们都属于哺乳纲。如果我们要把这些信息用表记录下来，那么在横向（行）上就需要对应准确。
除此以外，如果动物考察专家准备另起一张表，用来单独记录这3种动物的饮食习惯。毫无疑问，两张表含有的数据之间同样要遵循准确的对应关系。
不错，否则就可能出现张冠李戴的情况——狮子莫名其妙地在用锋利的牙齿啃食青草；斑马憋足了气潜入水中围捕沙丁鱼；而海豚却奔向草原追着瞪羚到处乱窜。
其实关系数据库就类似于一个社交平台，如果A表和B表是在合力记录同一个事件，且它们彼此关联，那么A、B两张表就能实现数据共享，从而提高信息的访问效率。事实上，大家在日后的学习中会逐渐发现，虽然表面上我们是在对表进行操作，但归根结底，我们操作的是表中的数据。
正是这样！表中的数据信息就像我们手中的面团，它们可以被任意揉捏并进行组合、拆分及变换，前提是遵循准确的对应关系。
这其实正是学习SQL的乐趣所在！因为我们可以根据实际需要，对表（一张或多张）中的数据进行重新编排，并组合出新的数据集。如果我们把一张表视为一幅画卷，那么我们不仅可以将这幅画卷分割，只展现出它的局部画面，还可以将这幅画卷与其他景色相宜的画卷合并。没错，关联表就是多张景色相宜的画卷，因为它们是在合力描绘一幅美景。
除了用表记录信息数据这一大特点，关系数据库还有另一个特点，那就是记录的内容大多为结构化数据，例如时间、姓名、地点等。而非结构化数据就类似于一篇文章、一段录音，或者一段影像。
糟糕！聊到这里我才意识到，我们之前的讨论可能会给读者们造成一种错觉，让他们误以为SQL是直接与数据库进行交流的。关于这个问题，我们请MagicSQL来解释一下吧！
MagicSQL：当然不是这样，亲爱的一年级新生。简单来讲，其实在你们和数据库之间，还存在一个类似于数据库管理员的角色，这个角色就是关系数据库管理系统，简称RDBMS（Relational Database Management System）。RDBMS会接收并阅读你们输入的SQL语句，然后负责对数据库执行相应的操作。
常用的RDBMS包括MySQL、SQL Server和Oracle Database等。不过在本书中，大家将要学习的是MySQL。它是一种开源的数据库管理系统，不仅易于安装和使用，而且免费。MySQL的Logo是一只可爱的蓝色海豚，相信它会隔着太平洋给我们带来好心情！
MagicSQL：没错，而我很高兴在本书中扮演MySQL的角色来对你们这群一年级新生“指指点点”！
到目前为止，相信同学们对相关术语已经有了一定的了解。概括来讲，SQL是一门用来与RDB（关系数据库）沟通的计算机语言，或者说是一个工具、一套书写系统。可是SQL并不直接与RDB取得联系，而是间接地通过RDBMS来完成访问。RDBMS是关系数据库管理系统，它就像数据库的小管家，会根据我们输入的SQL语句对数据库进行相应的操作，MySQL就是主流RDBMS中的一个。除此以外，由于RDB是通过装载表来间接容纳数据的，因此表才是数据最直接的载体，也是我们使用SQL的主要操作对象。
在本章中，我们感谢詹姆士、瑟琳娜、奎妮和劳伦斯的陪伴，他们将在后续的学习中一直陪伴在我们左右，为同学们解答疑惑和剖析原理。除此以外，可爱的汤姆和贝基也会加入这一队伍。
汤姆
贝基
当然，还有其他将会出现在故事情节里的伙伴们正等待着和大家见面。相信大家都能通过本书有所收获，下面就让我们开启一段精彩纷呈的数据库之旅吧！