数据库系列-数据库的历史

前言

说来惭愧，之前立下的flag，不出两月就破功了。一个是每天一篇强度大，常常立下的flag，不出两月就破功了。一个是每天一篇强度大，常常銮战到深夜，休息不好。另一个是感觉博客质量不高。现又跟小伙伴约一周3篇。希望这次不要断了。。要持续记录学习之路。管别人怎么看，加油！

数据库的历史

什么是数据库

• 数据库是一种组织化的数据集合，目的是为某种类型的组织或组织过程建模。

1. 操作型数据库

   主要用于联机事务处理（On-Line Transaction Processing OLTP），即需要手机、修改、和维护日常数据的情况。
   操作型数据库中存储的数据呈现出动态性。即，不断变化且始终反映即时信息。

2. 分析型数据库

   主要用于联机分析处理（On-Line Analytical Processing OLAP），用来存储并跟踪历史性和时间性的数据。如果需要跟踪趋势，查看长期的统计数据，并制定战略性或战术性业务预测，分析型数据库一定不会让您失望。

3. 两者的关系

   通常，分析型数据库往往将操作型数据库的数据作为其主要的数据来源。

小结

1. 从以上描述可以看出，OLTP是绝大多数系统的应用场景，因此很多系统的数据库都是操作型数据库。
2. 而OLAP，更多的是大数据分析方面的需求，甚至机器学习、人工智能这类需要大量的历史数据进行分析的场景。这类的数据库就属于分析型数据库。

早期数据库类型

在关系型数据库模型出现之前，有两种通用数据模型，用于维护和操作数据：层次数据库模型和网状数据库模型

层次数据库模型 - 1990s

层次数据库中的关系有父/子代表。在这种关系中，父表可以与一个或多个子表相连。而子表只能与一个父表相连。这些表通过一个指针或表内记录的物理排列建立明确的联系。用户访问这个模型中的数据的方式就是从根表开始，一直沿着树状结构达到目标数据。这要求用户对数据库的结构非常熟悉。

优点：

1. 用户可以快速检索到数据，因为表结构之间有明确的联系。
2. 内嵌了参照完整性，并且是自动执行的。这确保了子表中的记录必须与父表中的已有记录具有联系。父表中删除记录后，子表中的相关记录也随之被0删除。

缺点：

1. 访问数据要求用户非常熟悉数据库的结构。
2. 存储一个与父表没有联系的子表记录，需要构建一个虚拟的父表记录，否则无法存储。造成数据库冗余。

对于其第2个缺点，虽然可以通过构建多个层次数据库的逻辑上的关联来表示。但是这破坏了原来层次数据库的结构，放弃了层次数据库的优点，同时将关系维护到系统层面，这对开发人员提出了更高的要求，这也使得表关系变得隐晦。

网状数据库模型

在很大程度上，网状数据库的开发就是为了解决层次数据库出现的一些问题。它使用术语：节点和集合结构 来表示。

与层次数据库有点相似，但又有所不同。它改进了层次数据库中强约束的父子关系。
一个节点表示一个集合记录，一个集合结构建立并表示网状数据库中的一种关系。这种结构使用一个节点作为系主，另一个节点作为成员，从而将一对节点联系起来。
集合机构支持一对多。成员节点中的记录只能与系主节点中的一个记录相关联。
成员节点的记录必须与系主节点关联，否则该记录不存在。

优点：

1. 可以快速访问数据库。相较于层次数据库，用户可以使用更为复杂的查询

缺点：

1. 用户必须熟悉数据库的结构，才能通过集合机构来访问。
2. 很难在不影响与之交互的应用程序的条件下，改变数据结构。
3. 如果要改变一个集合结构，就必须同时改变应用程序中所有对该结构的引用。因为在网状结构中，一种关系被明确定义为一个集合结构。

关系型数据库

不得不说的历史

作为目前使用最为广泛的数据库模型，它最早可以追溯到1960s，关系型数据库之父——埃德加.F.科德博士曾是IBM公司的研究员，思考如何运用数学原理和结构来解决诸如：数据冗余、数据完整性差，数据库结构过度依赖其物理实现等问题。

里程碑

1970年6月，科德博士在其题为“大型共享数据库的关系数据模型”作品中，正是提出了它的新式关系数据库模型。
新模型基于两个数学分支：集合论、一阶谓词逻辑。而模型本身的名称取自“关系”这个术语，而不是因为表可以彼此联系。

表示方式

关系型数据库将数据存储在关系中，即表（table）。每个关系由元祖（记录）以及属性（字段）组成。
记录或字段的物理顺序不重要，且表中每个记录由一个具备唯一值的字段进行识别。——这两种特征，使得数据能不依赖于它在物理存储方法而存在。

检索数据

使用结构化查询语言（SQL）

关系数据库的优势

与层次数据库、网格数据库相比，关系数据库拥有诸多优势

1. 内置多层次完整性：

   数据完整性被构建到模型中，
   在表层次确保记录不被复制以及检测主键值的缺漏；
   在关系层次确保两个表之间的关系有效；
   在业务层次确保从业务本身而言数据准确无误。

2. 数据在逻辑和物理上都独立于数据库应用：

   无论是用户更改数据库逻辑设计，还是数据库软件供应商更改数据库的物理实现，都不会在该数据库上的应用程序带来不利影响。

3. 确保数据一致性和准确性

   由于施加于数据库各层次上的完整性，数据能保持一致且精准。

4. 简便的数据检索

   根据用户的命令，用户可以从数据库中的特定表或者许多相关联的表中检索数据。这使得用户可以以近乎无穷的方式查看数据信息。不像之前的数据库模型只能从父表开始。

缺点

1. 模型引入辅助技术导致运行速度慢。

   早期计算机处理速度、内存、外存不足导致。

总结

每一项技术的产生都是基于某种实际业务场景需要产生。然而每个原始的解决方案总是带有瑕疵的。因此了解技术产生原因和历史，有助于我们理解该技术的设计目标，进而更好的帮助我们理解其实现。
最近遇到些SQL性能方面的问题，因此想要了解数据库相关的东西。

PS： 本文主要从《自己动手设计数据库》中抄写下来的。有一丢丢自己的理解吧。当然并不是我真的想去设计数据，我只是想去了解个中原理。