〈什么时候用到数据库〉数据库什么时候用到索引…

/ CHAPEAU/

前言

▼

写这篇文章的出发点有二：

其一，目前地产业或者制造业正处于信息化、智能化的转型期，大家都逐渐意识到，在大部分情况下，用数据代替经验，是提升执行效率和决策精准度的关键。

数据库作为信息的载体，了解其发展可以加速数据化、信息化在传统行业的推广；

其二，对于数据分析人员来说，掌握数据的存储和读取，可以说是必修课之一，但很多人觉得了解理论，在实际工作中没有用处，笔者觉得这是极大的误区。“theory is practical”，我想应该是这个道理。

作为入门（毕竟笔者也讲不了太高深的，而且显得意义也不大），笔者将以地产行业的例子，来讲讲数据库的发展简史，希望对大家理解数据库有一点帮助。

01

层级模型

假设A房企是一家布局全国的地产企业，因为体量较大，需要一个数据库来管理记录其开发经营情况。

下图代表一种数据库的架构设计：

首选考虑将地域作为规划的起点，接下来按业务种类，设计这套系统的下一层级。

类似于这套架构的数据存储示意图如下所示：

我们看到，这套数据库系统，将先按照所属区域，设计一个作为“起始点”的细项表（实际上并非表，只是为了利于表述）。

后面根据这“起始点”表中的城市，分别设计属于每个城市拿地细项表和经营细项表。

这种层级区分明显的数据库模型被称作“层级模型”，这种设计架构在专业术语上被称作“树”结构，“起始点”被称作“树根”，而拿地细项表和经营细项表则是这棵树的“枝”。

因为这棵树比较短，只有两层，作为最后一层，所以也可以说这两张细项表是树的“叶”，实际上如果涉及到的数据种类比较庞大的情况下，按照层级模型的设计，这棵树会有多层的树枝。

那么，为什么要将数据库设计成“层级模型”呢？

因为”树“这种结构，与冯诺依曼型计算机分而治之的递归设计思想天然吻合。换句话说，采用“树”结构，能够让机器更加明白它需要做什么。

以所属区域和经营细项的关系为例，它们在机器里面的存储，实际上有可能是这样的：

数据之间通过“指针”进行连接，如果对于这套系统中的数据进行增删改查，对于非专业人士来说无疑是困难的。

以上述存储方式为例，倘若数据库管理员，想要在扬州市的经营细项中，添加新的项目信息，那他必须知道该经营细项的存储路径，并进行树的层序遍历定位到该位置……

或许这就是这种数据库难以推广的原因吧，让人类懂机器语言，成本无疑太高了。

02

网状模型

其实不仅仅是学习成本的问题，“层级模型”在表示数据间的复杂关系时，也显得捉襟见肘。

上述的例子还不够复杂，城市作为上一层级，和下一层级的项目情况是典型的“一对多”的关系，即一个市可以有很多的经营、拿地项目，但一个经营、拿地项目却只能对应一个市。

但是现实中，事物和事物之间的关系，往往是典型的“多对多”，比如“父母”对“子女”是培养的关系，但“子女”对“父母”也存在赡养的关系，房企中数据关系也绝非全部都是“一对多”。

一个典型的例子就是，对于经营的项目来说，其实也分很多种类，大类上来说，有“普通住宅”、“别墅”、“商用”等类型。

某些开发商为了便于管理和分析，还分了很多细项类别，比如会在“普通住宅”中细分“刚需”、“改善”等等。

那么问题来了，“项目分类”和“区域划分”是什么关系？

每个城市中，可能有许多项目分类，每种项目类型也可能存在许多城市之中，所以这是典型的“多对多”的关系。

此时，如果继续用层状模型来存储，其实也不是不行，但是会有太多冗余的信息。

为了更好的解决这个问题，“网状模型”诞生了，“网状模型”所依赖的架构结构不是“树”，而是“有向图”。

“有向图”和“树”之间的差异在于：“树”的枝叶只能严格对应其上一层级中某一节点，但“有向图“宽泛的多，没有严格定义的层级。“树”只能有一个根，但“有向图”可以有很多。

如果这样表述不够直观的话，我们将“经营类别”加入之前的架构中，如下所示：

按照“树“逻辑，这个架构绝非一棵树，但是按照”树“的抽象，它可以说是一个森林，有两个树根，分别是“经营类别”和“所属区域”。

并且枝叶“经营细项”对应上一层级中的经营类别”和“所属区域”，而不是只对应一个。

数据按照此架构的存储示意图如下所示：

由上图可知，“有向图“将”所属区域“和”经营类别“这种”多对多“的关系，拆解成了”经营类别-经营细项“和”所属区域-经营细项“两个”一对多“的关系，从而更好地解决了数据间复杂关系的问题。

但是图的数据结构比树更加复杂，所以还是回到了刚开始那个无法回避的问题。

以上两种架构都太底层，抽象程度较低，学习成本太高，不利于其推广，自然也就不具备太高的实用价值和商业价值。

03

关系模型

可是随着信息时代的不断发展，对于数据或者量化的需求越来越多，就越来越需要一种能让普罗大众接受，并使用的数据库来解决此类问题。

或者更贴切地说，机器能听懂的语言，咱人类很难听懂啊，我们需要机器按照我们人类的逻辑去思考，解决我们的问题。

伟大的天才Codd正是为解决这个问题而生。

Codd的一生充满了传奇色彩，他曾经作为一名英国皇家飞行员，参加过第二次世界大战。

后面他来到美国，在IBM公司工作，1981年，他凭借其在关系型数据库的贡献，获得了当年的图灵奖。

或许是因为忍受不了之前的数据库设计中指针混乱、地址泛滥等问题，亦或是无法接受数据库的使用，一直被束之高阁的态势。

他发出了振聋发聩的呼喊：请暂时远离指针和地址吧！我们现在只需要知道数据本身的关系！

Codd先后发表了两篇论文，以集合论为基本思想，并用逻辑谓词作为数据库的操作基础，一举奠定了关系型数据库的基石。

这时有个叫Larry Ellison聪明的年轻人，在阅读了论文之后，发现了此中的商机，创办了一家数据库软件公司，并在若干年后成为了硅谷首富，这家公司正是如今的甲骨文（Oracle）。

言归正传，那么关系型数据库，要如何组织地产公司的数据库架构呢？我们还是以“区域-经营“为例，给出数据库架构图：

数据存储的示意图：

这个数据库架构和存储示意图，相较于之前两种，最明显的区别，在于根本没有谁指向谁的路径。

那么，它们之间是如何联系的呢？答案是：“关系”。

细心的读者肯定发现了，数据存储中红色的那一列，彼此之间都是互不相同的，代表了这行条目的唯一性，维持了这张表作为“集合”的性质，术语上称之为“主键”。

蓝色的两列，分别代表了经营细项和经营类别、所属区域之间的联系，术语上称之为“外键”。

这时你肯定恍然大悟：是关系，是经营类别、所属区域两张表的“主键”，和经营细项表的“外键”之间的关系，建立了整体的联系！

下面我将简单描述一下“关系模型”，如何以“人”的思维来运作。

首先对于数据的量化这一点，人类的常用的工具是什么？

很显然，我们在用数据处理一个问题的时候，首先会对许多假设进行判断，并结合判断为正确的假设，再进行加减乘除的计算，来得到基于正确假设的结果。

其实这个两个过程，可以归纳为以谓词（谓词即为返回值为真值的函数，例如“是”、“≤”、“存在”等）逻辑为基础的代数运算过程。

有了这样一个归纳的前提后，我们来看一下“关系模型“是如何像人类一样思考问题：

1.添加新的数据。由于数量比较大，经营细项的数据，由两个人来整理，另一个人整理的经营细项的数据如下：

现在我们需要将这张表，添加到之前的经营细项中，其实就是将两张表“加”起来，同时维护集合的性质，去掉重复的数据。

2.找出经营细项中，尚未存在的项目小类类型。解决这个问题，需要建立“经营类别”和“经营细项”两张表的联系，然后用集合“减”法，得到最后的结果。

3.求普通住宅的销售套数总和。同样的，我们需要建立“经营类别”和“经营细项”两张表的联系，但是这次我们将（“刚需”，“改善”）这样一个集合，作为一个“乘法因子”用来“乘”以经营细项表中对应的套数，得到结果：

4.求包含所有普通住宅类型的城市。同上图一样，我们建立起两张表之间同样的联系。但是这次我们将（“刚需”，“改善”）当作“除数因子”，每个城市作为被除数，两者相“除”，求得商为正整数的城市：

关系模型真的做到了！它能够按照人类的逻辑去量化数据！

命题即是一种谓词逻辑判断，再加上集合的关系运算，能够轻松地得到我们想要的结果。这套数据库架构完美的符合人类的思维方式！

设计者们依据这一架构设计了一套封闭的语言体系——Structured Query Language（SQL），这一套查询语言因为其简单的可操作性，很快就占领了市场，甲骨文公司也因此赚得盆满钵满。

关系模型很好的解决了层级模型和网状模型的弊端。

但是天底下没有免费的午餐，关系模型在提高了数据库的抽象性的同时，也因为其封闭性、底层不对外可见，从而降低了数据查询的性能。

所以当数据的规模增大到一定程度，达到性能瓶颈时，关系模型数据库，有时也会显得力不从心，也就催生了后来的NoSQL和分布式存储技术的发展。

不过，相比于其对于信息时代的贡献来说，可以说是瑕不掩瑜。并且，笔者认为关系模型的设计思想至少从当前来说，还丝毫没有过时。

小结

本文主要介绍了数据库的发展简史，希望能对传统行业的从业人员了解其相关知识提供一点帮助。

其实笔者也曾在一家大型的制造型企业工作过两年，难以想象的是——

当前很多传统行业，虽然通过购买相关软件或者外包的形式，已经实现了流程管理的IT化，但是对于核心的产品和功能，还基本停留在经验和纸质版，或非标准化存储的阶段。

这对于开发和创新来说，无疑是非常低效的，期望以后会越来越好。

– TO BE COUTINUED –

若酱的算法科普小课堂

| 理性 | 严谨 | 认真 |

| 熵值法 | 最佳路径选择 | 文本信息匹配 |