数据库数据《Expert MySQL》翻译——chapter2.解剖数据库系统(3) 数据库数据

近最研究数据库数据,稍微总结一下,以后继续补充:

 接上文

MySQL是一个系关型数据库系统吗?
    很多数据库专家都市跟你说这个世界上只有极少数的真正的系关型数据库系统。他们同时也会指出你须要的功能在多大程度上够能被数据库系统持支。他们并不会跟你说这个数据库有多符合Codd提出的系关模型。
    从一个纯市场的角度说来,MySQL供给了很多系关型数据库所应该持支的功能。它们括包通过外键使表与表之间建立系关,以及基于系关算法的询查机制,还有在数据库中应用索引和缓存机制等。很明显,MySQL供给的功能还不止这些。
    那么MySQL是底到个系关型数据库吗?呵呵,这就取决于你对系关的定义了。如果你从应用演变的角度上看,MySQL还确实是个正儿八经的系关型数据库。但是呢,如果你格严按照Codd的系关模型去比对的话,你就会现发MySQL并没有全完实现Codd提出的模型中的有所功能。而且一些其他的系关型数据库也并没有真正全完地实现了Codd提出的系关模型。
系关型数据库系统架构

     系关型数据库是个庞杂的系统,它由很多组件成构,这些组件是为理处有所有关存储和索检所必须的功能而特殊计划的。一个系关型数据库系统的架构经常被拿来和操纵系统的架构做比拟。你想一想系关型数据库的应用场所,尤其是作为服务端向客户端供给服务的时候,你会现发它和通普的操纵系统有很多雷同之处。比如说,在多客户端的场所下,就求要系统必须持支多请求理处,这些请求可能致导系统对统一条数据同时做读写操纵,也有是能可针对统一区域(也就是表)中的数据同时做读写操纵。因此,系关型数据库必须持支发并才能高效运作。类似的,它也须要持支个一每客户端对数据的高速拜访。这都须要合理地应用件文缓存术技来证保近最或经常应用的数据够能驻留内存来实现高效拜访。发并术技也须要类似于操纵系统中的虚拟内存机制来在数据库中对内存行进管理。其他类似的方面也括包供给操纵系统那样的络网连接持支和针对高提询查语句执行率效的优化算法。

    我会从用户应用询查语句来索检数据的角度开始我们的数据库架构摸索之路。接下来的大节你可以挑你感兴趣的分部看,如果你对某分部大节及涉的术技很熟悉,那就跳过。不过我还是望希你够能全部都看一轮,这些大节供给了一个型典系关型数据库是如何架构的细节。

    客户端应用

    大分部系关型数据库的客户端应用都是可立独执行的序程,他们通过某些式方(比如说基于套接字的络网连接,或者管道等)来与数据库交流。有些情况是直接在序程中拜访数据库的,这时候数据库就属于这个客户端应用的一分部。在这类情况下,我们称之为嵌入式数据库。第六章分析了更多有关嵌入式数据库的息信。

    对于哪些通过某些渠道来与数据库交换息信的应用,大分部链接都建立在数据库连接器(database connectors)供给的协议上。大分部数据库连接器都是基于开放数据库连互(Open DataBase Connectivity,ODBC)模型的。MySQL也持支基于java和.NET的数据库连互。大分部基于开放数据库连互模型的数据库连接器也持支通过络网协议来连接数据库。

ODBC是什么?
    ODBC是一种应用序程口接(API),ODBC被计划用于析解SQL语句来使服务端去索检数据,并且也将服务端返回的数据现展给客户端。一个ODBC的实现括包通过应用API用调ODBC库函数来表演中间人的功能,以及一个针对特定数据库计划的数据库驱动。我们从字面上可以将ODBC解理成一个供给用户拜访,应用序程口接以及数据库驱动的一个连接器。因此,一个ODBC连接器表演了服务端和客户端之间的翻译人的角色。ODBC差不多已经成为了有所系关型数据库的准标,并且在现也有各种持支一大堆不同类型的客户端和不同类型的服务端的连接器。
当我们提到客户端应用时,我们只是普各处假设它仅仅是从服务器索检数据或者让服务器存储数据的序程。但是,我们用来设置/维护服务器的序程也算客户端序程。大分部这些序程跟数据库应用应用雷同的交流渠道来连接服务器。有些应用ODBC连接器,也有些应用其基于JAVA的变体(JDBC)来连接数据库。其中有些用来管理服务器的特殊协议是基于一些特殊的管理需求而计划的。其他的一些比如说phpMyAdmin就应用端口或者套接字。

    先不管他们怎么实现的,总之客户端应用通过给服务端发送命令来索检这些命令指向的数据,并且翻译和理处这些数据以后再返回给用户。准标的命令语句就是SQL。客户端通过应用SQL命令,经过连接器的翻译,以及连接器维护的基于数据库驱动的络网链接来达传给数据库并从中得获数据。图2-1述描了这一程流。

    数据库数据《Expert MySQL》翻译——chapter2.解剖数据库系统(3) 数据库数据_第1张图片

    询查口接

    每日一道理
正所谓“学海无涯”。我们正像一群群鱼儿在茫茫的知识之海中跳跃、 嬉戏,在知识之海中出生、成长、生活。我们离不开这维持生活的“海水”,如果跳出这个“海洋”,到“陆地”上去生活,我们就会被无情的“太阳”晒死。

    询查言语,比如说SQL,是一种可被用来向数据库提交请求的言语(因为它有自己的法语和语义)。事实上,在数据库中应用SQL被认为是数据库够能功成的重要原因之一。询查言语通过一些语句集合奠基了够能方便应用数据库的础基。数据述描言语(Data Definition Language, DDL)被用来创建和管理数据库,它的务任括包转变表构结,定义索引,和管理约束。数据操纵言语(Data Manipulation Language, DML)可被用来询查和更新数据库中的数据,它的务任括包添加,询查,和改修数据。这两种言语集合成构了数据库够能持支的重要命令。

    SQL命令应用特殊的法语。上面表现的是SQL中SELECT语句的法语。

SELECT [DISTINCT] listofcolumns
FROM listoftables
[WHERE expression (predicates in CNF)]
[GROUP BY listofcolumns]
[HAVING expression]
[ORDER BY listof columns];
这条指令的语义是这样:
  1.在FROM语句中成构表的笛卡尔积,从而形成了那些在其他语句中所须要的照参。(Form the Cartesian product of the tables in the FROM clause, thus forming a projection of only those references that appear in other clauses.)

  2.如果WHERE语句存在的话,应用这些表达式来给出照参表。(If a WHERE clause exists, apply all expressions for the given tables referenced.)

  3.如果GROUP BY语句存在的话,根据GROUP BY语句供给的属性来给询查结果组分。

  4.如果HAVING语句存在的话,针对这组数据行进过滤。

  5.如果ORDER BY语句存在的话,就对询查结果行进排序。

  6.如果DISTINCT语句存在的话,就从询查结果中去除雷同的素元。
上面的码代例样展示了大分部SQL命令的素元,有所的这类命令都有其需必的分部,和有些基于关键字的可选分部。

    一旦这些命令被传送到了服务器,数据库服务器立马就开始析解并执行这些命令。从这点上看,询查语句之所以被简略地被称为询查,是因为它将问题述描提交给服务器,然后服务器基于这些述描来返回一个谜底。在接下来的大节中,我们假设“询查”就类似于SELECT语句这样,是有数据返回的。事实上,任何询查不论是数据操纵还是数据定义,都是跟上面的程流一样地去执行。从这一点上讲,我们可以认为是服务端自己执行了这些程流。程流的第一步就是去析解客户端须要的是什么,也就是说,询查语句须要从法语上分析这些语句,并且将语句分割成够能立独执行的小分部。

 

    (未完待续)

文章结束给大家分享下程序员的一些笑话语录: 腾讯的动作好快,2010年3月5日19时28分58秒,QQ同时在线人数1亿!刚刚看到编辑发布的文章,相差才2分钟,然后连专题页面都做出来了,他们早就预料到了吧?(其实,每人赠送10Q币,轻轻松松上两亿!)


你可能感兴趣的:(数据库数据《Expert MySQL》翻译——chapter2.解剖数据库系统(3) 数据库数据)