前言
说来惭愧,之前立下的flag,不出两月就破功了。一个是每天一篇强度大,常常立下的flag,不出两月就破功了。一个是每天一篇强度大,常常銮战到深夜,休息不好。另一个是感觉博客质量不高。现又跟小伙伴约一周3篇。希望这次不要断了。。要持续记录学习之路。管别人怎么看,加油!
数据库的历史
什么是数据库
- 数据库是一种组织化的数据集合,目的是为某种类型的组织或组织过程建模。
-
操作型数据库
主要用于联机事务处理(On-Line Transaction Processing OLTP),即需要手机、修改、和维护日常数据的情况。
操作型数据库中存储的数据呈现出动态性。即,不断变化且始终反映即时信息。 -
分析型数据库
主要用于联机分析处理(On-Line Analytical Processing OLAP),用来存储并跟踪历史性和时间性的数据。如果需要跟踪趋势,查看长期的统计数据,并制定战略性或战术性业务预测,分析型数据库一定不会让您失望。
-
两者的关系
通常,分析型数据库往往将操作型数据库的数据作为其主要的数据来源。
小结
1. 从以上描述可以看出,OLTP是绝大多数系统的应用场景,因此很多系统的数据库都是操作型数据库。
2. 而OLAP,更多的是大数据分析方面的需求,甚至机器学习、人工智能这类需要大量的历史数据进行分析的场景。这类的数据库就属于分析型数据库。
早期数据库类型
在关系型数据库模型出现之前,有两种通用数据模型,用于维护和操作数据:层次数据库模型和网状数据库模型
层次数据库模型 - 1990s
层次数据库中的关系有父/子代表。在这种关系中,父表可以与一个或多个子表相连。而子表只能与一个父表相连。这些表通过一个指针或表内记录的物理排列建立明确的联系。用户访问这个模型中的数据的方式就是从根表开始,一直沿着树状结构达到目标数据。这要求用户对数据库的结构非常熟悉。
优点:
- 用户可以快速检索到数据,因为表结构之间有明确的联系。
- 内嵌了参照完整性,并且是自动执行的。这确保了子表中的记录必须与父表中的已有记录具有联系。父表中删除记录后,子表中的相关记录也随之被0删除。
缺点:
- 访问数据要求用户非常熟悉数据库的结构。
- 存储一个与父表没有联系的子表记录,需要构建一个虚拟的父表记录,否则无法存储。造成数据库冗余。
对于其第2个缺点,虽然可以通过构建多个层次数据库的逻辑上的关联来表示。但是这破坏了原来层次数据库的结构,放弃了层次数据库的优点,同时将关系维护到系统层面,这对开发人员提出了更高的要求,这也使得表关系变得隐晦。
网状数据库模型
在很大程度上,网状数据库的开发就是为了解决层次数据库出现的一些问题。它使用术语:节点和集合结构 来表示。
与层次数据库有点相似,但又有所不同。它改进了层次数据库中强约束的父子关系。
一个节点表示一个集合记录,一个集合结构建立并表示网状数据库中的一种关系。这种结构使用一个节点作为系主,另一个节点作为成员,从而将一对节点联系起来。
集合机构支持一对多。成员节点中的记录只能与系主节点中的一个记录相关联。
成员节点的记录必须与系主节点关联,否则该记录不存在。
优点:
1. 可以快速访问数据库。相较于层次数据库,用户可以使用更为复杂的查询
缺点:
1. 用户必须熟悉数据库的结构,才能通过集合机构来访问。
2. 很难在不影响与之交互的应用程序的条件下,改变数据结构。
3. 如果要改变一个集合结构,就必须同时改变应用程序中所有对该结构的引用。因为在网状结构中,一种关系被明确定义为一个集合结构。
关系型数据库
不得不说的历史
作为目前使用最为广泛的数据库模型,它最早可以追溯到1960s,关系型数据库之父——埃德加.F.科德博士曾是IBM公司的研究员,思考如何运用数学原理和结构来解决诸如:数据冗余、数据完整性差,数据库结构过度依赖其物理实现等问题。
里程碑
1970年6月,科德博士在其题为“大型共享数据库的关系数据模型”作品中,正是提出了它的新式关系数据库模型。
新模型基于两个数学分支:集合论、一阶谓词逻辑。而模型本身的名称取自“关系”这个术语,而不是因为表可以彼此联系。
表示方式
关系型数据库将数据存储在关系中,即表(table)。每个关系由元祖(记录)以及属性(字段)组成。
记录或字段的物理顺序不重要,且表中每个记录由一个具备唯一值的字段进行识别。——这两种特征,使得数据能不依赖于它在物理存储方法而存在。
检索数据
使用结构化查询语言(SQL)
关系数据库的优势
与层次数据库、网格数据库相比,关系数据库拥有诸多优势
- 内置多层次完整性:
数据完整性被构建到模型中,
在表层次确保记录不被复制以及检测主键值的缺漏;
在关系层次确保两个表之间的关系有效;
在业务层次确保从业务本身而言数据准确无误。 - 数据在逻辑和物理上都独立于数据库应用:
无论是用户更改数据库逻辑设计,还是数据库软件供应商更改数据库的物理实现,都不会在该数据库上的应用程序带来不利影响。
- 确保数据一致性和准确性
由于施加于数据库各层次上的完整性,数据能保持一致且精准。
- 简便的数据检索
根据用户的命令,用户可以从数据库中的特定表或者许多相关联的表中检索数据。这使得用户可以以近乎无穷的方式查看数据信息。不像之前的数据库模型只能从父表开始。
缺点
- 模型引入辅助技术导致运行速度慢。
早期计算机处理速度、内存、外存不足导致。
总结
每一项技术的产生都是基于某种实际业务场景需要产生。然而每个原始的解决方案总是带有瑕疵的。因此了解技术产生原因和历史,有助于我们理解该技术的设计目标,进而更好的帮助我们理解其实现。
最近遇到些SQL性能方面的问题,因此想要了解数据库相关的东西。
PS: 本文主要从《自己动手设计数据库》中抄写下来的。有一丢丢自己的理解吧。当然并不是我真的想去设计数据,我只是想去了解个中原理。