第四课补充01——数据库系统的立体视图
数据库系统架构
一、数据库系统的分类：面向对象型、关系型、对象关系型
1、面向对象型数据库（OODBS）
（1）面向对象型数据库系统是一种持久的、可共享对象库的存储器和管理器；是基于OO的思想，因此这类数据库也有封装、类、类层次等概念
（2）目前流行的开源面向对象数据库：DB4O
2、关系型数据库（RDBMS）
（1）关系型数据库基于表的特性，方便用户使用查询语言SQL进行增删改查，目前流行的主流开源产品是MySQL
3、对象关系型数据库
（1）这个概念里保留了关系型数据库的结构，但允许关系表里中的列含有一个复杂的对象，这些对象能够捆绑处理复杂数据的处理过程（一种存储过程），并且SQL能够允许调用与关系型同等的“对象方法”。
（2）目前主流的数据库厂商或多或少都支持了部分面向对象的概念，在Mysql里也引入了OpenGIS（开放的地理数据互操作规范）的支持。
二、关系型数据库的系统架构
1、数据库管理系统和操作系统有很多类似的地方，例如：
（1）支持大量的用户同时读写一份数据（表），这需要合理的处理并发情况=====================》采用缓存技术（buffer）才能提供大并发量下的快速访问。并发访问要求数据库系统的内存管理系统采用类似操作系统的虚拟内存管理方式和算法。
（2）数据库管理系统的网络方面==========》网络协议被设计成能够高速解析客户端的查询
2、DBMS的基本功能模块
（1）网络客户端连接
（1.1）客户端连接到DBMS有两种方式，一种是通过通信方式，另一种是通过接口连接，接口方式连接到DBMS的，数据库系统已经成为应用系统一部分，即称为嵌入式数据库系统。
（1.2）网络通信方式连接到DBMS的，一般采用通用的连接器：例如，ODBC JDBC .NET等连接。
（1.3）不管是网络通信方式，还是接口直连内嵌式数据库系统，应用程序客户端都要发送SQL命令（查询语句或预处理语句）到数据库系统，获取命令的执行结果集，解析和处理结果集，最后展示给用户。
（2）SQL解析和优化（Parser+Optimizer）
（2.1）SQL接口——SQL处理——SQL优化——SQL执行
（2.2）查询接口也就是SQL接口（SQL Interface）,接收SQL语句
（2.3）SQL语句处理，包括：语句合法性检查——语义检查——获得对象解析锁——数据访问权限的核对，这四个步骤。其中：
（2.3.1）语句合法性检查：在高速缓存里找不到对应的SQL语句时，才开始检查SQL的合法性。语法检查的过程中，不会对SQL语句中包含 的表名、列表做解析，仅仅是语法上的检查；
（2.3.2）语义检查：SQL符合语法后，接着对语义检查，也就是对语句中的字段、表等内容做检查，确定字段、表是否在数据库里。如果语法和语义同时有错误，系统会先提示语法错误，等语法完全正确后再提示说列名或表名错误。
（2.3.3）获得对象解析锁：数据库的主要任务之一是：保证大量并发情况下的数据完整性，当语法和语义都正确后，系统会对我们需要查询的对象加锁，这主要是为了保证数据的一致性，防止查询过程中，其他用户对这个对象结构做改变。
（2.3.4）数据访问权限的核对：语法和语义检查后，服务器还会做权限核对，如果连接服务器的用户不具有数据库访问权限，客户端就不能够获取这些数据。需要注意：数据库服务器是先进行语法和语义检查，然后才检查访问权限。
（2.4）SQL优化：数据库查询优化器（Optimize）是RDBMS服务器的一个组成部分，查询优化器的任务是：通过产生可供选择的执行计划，找到最低估算开销的执行计划，来优化一条SQL语句。当一条SQL被送入RDBMS服务器后，将会别解析并提交给数据库查询优化器。查询优化器将会进行查询重写和表达式评估，以产生可供选择的执行计划。产生可供选择的执行计划的数量，取决于RDBMS中定义的计划空间的大小
（2.5）SQL执行：大部分关系型数据库服务器进程在接到客户端SQL后，不会直接去数据库查询，而是先在数据库的高速缓存中查找，是否存在相同语句的执行计划。如果在数据库高速缓存中，刚好有其他人使用这个查询语句的话，服务器进程会直接把这个数据传递给客户端，省去后续工作。
因此，采用高速数据缓存且命中率较高的情况下，可以提高SQL语句的查询效率，一方面是从内存中读取数据比从硬盘中的数据文件读取效率高；另一方面，也是因为这个语句解析的原因。
（3）存储引擎
三级结构对数据库的组织从内到外分三个层次描述：内模式、概念模式、外模式。内模式是真正存储数据的，概念模式和外模式仅是一种逻辑表示数据的方法，但却可以放心大胆使用它们，这是靠DBMS的映射功能实现的。
查询优化和查询解析实现了概念模式的功能，然而对数据库数据的访问归根到底是需要访问磁盘上的物理文件的。
MySQL数据库系统
在功能上，MySQL是基于组件的模块化设计，事实上，MySQL架构既不是严格基于组件也不是真正的模块化.。从严格意义上来说，MySQL系统是基于函数库和数据结构的方式来整合代码。
MySQL子系统和核心库
MySQL包含以下子系统和核心库：
——网络连接和网络通信协议子系统（TCP/IP协议，该子系统为其他子系统提供数据包的读 写 解析和发送）
——线程、进程和内存分配子系统（线程子系统跟踪各类线程以保证当客户端发送请求过来时，服务器拥有线程来处理它）
——查询解析和查询优化子系统
——存储引擎接口子系统
——各类存储引擎子系统
——安全管理子系统（数据库系统抵御外部攻击的第一防线，依赖用户验证和访问权限控制来保护服务器）
——日志子系统
——其他子系统，例如复制功能，错误处理等
——mysys核心库文件
（1）子系统之间的联系，例子：一个客户端通过网络连接MySQL服务器，做SQL查询操作等，子系统协作过程：
（1.1）网络连接子系统执行一系列与网络协议有关的底层任务；
（1.2）网络连接子系统调用线程子系统，线程系统提供一个线程来处理该连接，这个线程就称为连接线程（连接线程可能来自线程缓存thread cache，也可能是新创建的）；
（1.3）连接线程：
（1.3.1）首先调用安全管理子系统来验证用户访问的合法性（用户是否有权限访问数据库、密码是否正确等）：
（1.3.2）连接线程确认连接合法后，将获得的数据（SQL语句）根据情况做分发，如果查询和上次查询一模一样，直接从query cache中取值；如果不能直接利用缓存获取查询，则会调用解析子系统对SQL语句进行解析。同时，如果配置了日志功能，还会调用日志系统去记录此次信息（SQL语句、执行时间、执行的用户等）；
（1.3.3）解析子系统将解析结果传给优化子系统，优化SQL语句。同时，涉及到一个安全问题：用户是否有权访问特点的表？这里将再次调用安全管理子系统，确认权限后才可以对表进行操作。
（1.4）对表进行操作，将一系列请求发往存储引擎接口子系统。发往子系统的请求可以认为是增删改查等SQL操作
（1.4.1）存储引擎接口子系统将一系列请求自动转化为某个具体的存储引擎子系统方法（例如，innodb存储引擎子系统）。所谓自动，其实就是面向对象编程里的多态。简单来说，调用者感觉在和接口子系统互动，但实际上处理的却是某个具体存储子系统，例如innodb存储引擎子系统。
（1.4.2）顺利的话，响应存储子系统模块会把执行SQL的结果发往客户端；不顺利，则发送报错信息。最后，服务器将控制权交回给连接线程，连接线程做清理工作，并再次等待客户端的连接或其他查询，直到客户端输入quit命令为止，此次会话才算结束。
（1.5）补充-1：mysql日常90%的工作如上描述过程在运转，但有例外，例如：如果服务器扮演复制功能，则它的复制子系统还会不停读取二进制日志文件；如果服务器扮演的是从服务器角色，从服务器还将启动两个线程，分别是SQL线程和IO线程，它们共同接受主服务器传过来的语句并更新从服务器。
（1.6）补充-2：所有子系统的协作运行，都是核心库在默默提供支持。MySQL将一些常用且基础的API放在一起，形成核心库。
