前言

时间:2018年3月11日 13:30-16:30
地点:北京工业大学第三教学楼412教室

2018年3月11日笔者开始了在职研究生第一课，第一门课程是《高级数据库系统》。中午十二点开始报道，忙完相关入学事宜，一点半王冠老师开始讲课。按照正常的上课时间是13:30-17:00四节课，每节课 45 分钟，中间休息时间应当是是半小时。实际上课时间13:30 -16:30，中间只休息了 7 分钟。第一天上课，总的来说还算满意，老师也很负责，短暂的三小时学习也算收获满满。

接下来的文章内容中，笔者会先来说说对在职研究生的认识和看法，然后再将三小时的课程整理成笔记。

一、在职研究生值不值得上

事实上可能有人对在职研究生会存在偏见，认为在职研究生没有全日制研究生权威，没与全日制研究生好，认为只是花钱买一个学位而已，比如读MBA主要就是为了结交更多的人。但笔者认为在职研究生值得上。我是去年年底报的北京工业大学计算机相关专业的在职研究生的，坦白说刚了解在职研究生的时候也是存在一些质疑的，但是又非常想提高自己的能力。于是，当时就联系了身边的不少读研的朋友问问他们的了解。其中还咨询过大学母校两位老师的意见，两位老师对我的想法还是很支持的。其中一位老师属于治学和科研态度非常严谨的人，接触的所有老师中没有任何一个可以像他那般严谨，按照他的建议在职研究生同全日制相比，肯定没有全日制学习时间那样充足，但是所接受的教学、拿到的学位证同全日制学生相比基本没有差别的；另外一位老师，三十岁拿到博士学位，行政上也即将到达正处级别，也是对此非常赞同我去读的。至今还引以为傲的是大学期间帮助这帮老师写过一部分博士论文，并协助其写科研基金申请论文拿到二十多万元的科研经费，虽然这些都只是和化学相关。

注意:以下相关理由主要是站在技术相关工作人员角度思考问题。在研究生值得上的理由，主要如下：

• 1、学的东西并不比全日制研究生少。
  在职研究生也是要修够一定的学分，课程安排同全日制基本一样。如果按照每周两天的课程计算，修够学分也需要将近一年半的时间。且师资待遇同全日制无区别，课程的授课老师均是教授或者研究生、博士生导师。

• 2、学习和工作实践相结合，学习的同时同样能积累工作经验。

• 3、在职研究生并非只是花钱就能考过，需要参加国家五月联考。
  学校各课程考试可能不会卡主你，但是要想拿到学位证，要参加国家的五月联考。一门专业课和一门英语，其中英语的难度相当于国家英语四级的难度。

• 4、学习课程可以指导自己成长的方向。
  工作中想提高自己，如果单单是自学，没有方向，可能会迷茫。笔者之前就是这样，感觉有很多东西要学，但是很迷茫，没方向。相信以后在相关课程作指导下，自己会有更明确的学习目标。

• 5、学习过程会比较艰苦，因为艰苦，所以可以成长。
  听之前的在职研究生师兄师姐说，上一年他们是周六周日两天满满的课程，有时为了赶进度偶尔还会在晚上加课；另外，北京工业大学早上上课时间是8:00，对于帝都的上班族而言一个多小时的上班时间再正常不过了。拿笔者来说，八点上课的话，大概一小时十分钟的车程，那么早晨六点左右就要起床；再来看看课表笔者课表上的一句话："节假日正常上课"。

  
  上课时间

• 6、在职研究生毕业后所获得的硕士学位证书，与统招研究生硕士学位证书一样，都是国家承认、社会认可的。如果是将后想继续读博士，也是完全可以的。

• 7、这个社会上，学生可能是最廉价的劳动力。有些研究生虽然整日忙绿，但做的更多的是一些重复性的工作。学生没有踏入社会，思想较为单纯。但是社会是残酷的，从老师的角度上来讲，老师同一般的社会工作人员相比，并无太大区别，所以很多人说校园比较单纯，但其实老师并不单纯。

• 8、工作中需要更多的规范，在职研究生可以为你带来更多规范。
  工作以来，笔者去过大公司也去过小公司。但从来没有认为接触的哪一个项目做到了规范，即使是现在所在的公司(公司上万人，规模不算小)，一个面向百万用户的App距离规范也很遥远。笔者认为这种规范有两种类型的人可能可以做到带头牵引的作用，一种是经验比较丰富的专家级别开发者，另一种是接受过高等教育。后者虽然没有专家级别开发者经验，但是却从相关课程中学到不少规范，这种规范或许可以应用到实际工作。再者，那些博士或接受过更教育的人，学术上本身就要求他们要做到严谨和规范，这种严谨和规范当然也可能会被带到工作中。笔者本科期间接触过博士论文写作，对其中的严谨自然是感悟不少。

• 9、一些原理性东西需要掌握。
  一些原理性的东西在实际写代码的过程中，可能用的不多。但是当遇到一些特殊难题或需要知道相关原理的情况，这时才能体现一个开发者的水平。笔者之前在一家创业公司开发的一个项目，数据量非常大，开始是无从下手。数据结构相关知识可能实际开发中很少用到，但笔者最后主要就是从数据结构相关基础知识解决的。

小结

笔者身边的一些全日制的研究生朋友，有非常忙碌的，也有比大学还悠哉的。比如我女朋友天天快要忙成，基本快全年无休了；我一大学隔壁同班同学以及一个学长，他们简直比大学还逍遥快活。无论是全日制还是在职，在两者为你提供基本一样的课程和教学的条件下，到底能学多少东西，真正关键的在于自己。所以，今后学到的研究生相关课程内容，笔者打算尽可能的抽出一些时间将所学的东西以博客文章的形式记录。接下来，总结第一次三小时课程学习到的大概内容。

二、一些基本概念

这里就先说一些最基本概念相关的东西。

数据库系统:（Database System, DBS）是一个综合的系统，一般有数据库(Database,DB)、数据库管理系统(Database Manager System,DBMS)及其开发工具、应用系统、数据管理员（DataBase Administrator, DBA）组成。其中BDMS是数据库系统中的一组软件。

数据库管理系统:数据库的核心是数据库管理系统(DBMS)的重要程度相当于操作系统(OS)，价值操作操作系统，往往比操作系统还要复杂很多。

三、分布式数据库

分布式数据库的重要意义就不多说。现在很火的区块链技术，其实和分布式数据库有不浅的关系，这里有篇文章你可以看看。

3.1 概念

分布式数据库系统：(Distributed Database System,DDBS) 是面向地理上分散，但管理上需要不同程度的企业或组织提供数据库管理的管理信息系统。比如一个学校的多个校区学生信息管理或一些跨国企业、连锁店等数据信息管理。
分布式数据管理系统DDBMS:同DBMS对应的是分布式数据管理系统DDBMS (Distributed Database Manager System)，它是数据库系统中的一组软件，负责管 理分布环境下逻辑集成数据的存取、 控制、数据转换、通信。

另外还要知道，传统的数据库称为集中式数据库。国内研究始于80年代初期，相对比较完备的有中科院研发的C-POREL系统、武汉大学的WDDBS & WOODDBS的系统、东北大学 DMU/FO系统。

3.2 分布式数据库系统结构

分布式数据库系统结构

从上图中可以看出，分布式数据库中包含全局数据库系统和局部数据库系统。与之对应的分别是全局数据库管理系统GDBMS和局部数据库管理系统LDBMS。另外，一个用户或一个应用如果只访问他注册的那个站点上的数据则称为本地用户/局部用户/局部应用；如果访问两个或两个以上站点中的数据，称为全局用户或全局应用。ps:上图中的电脑样式就是对应的三个站点。

3.3分布式数据库系统特点

• 1、物理分布性
  数据不是存储在一个站点上，而是分散存储在多个站点，且用户是感觉不到这种分布特性。
• 2、逻辑整体性
  五；上数据是分散在不同站点上，但是这些分散的数据在逻辑上却是一个整体，他们被分布式数据系统所有用户(全局用户)共享，并由一个分布式数据库管理系统管理。
• 3、站点自治性
  即各站点数据由本地DBMS管理，具有自治处理能力，完成本站点的应用(局部应用)。

基于以上三点可以推到出另外几个特点：

• 4、数据分布透明性
  分布式数据库系统中，数据的独立性有数据的逻辑独立性、数据物理独立性以及数据分布独立性，其中数据分布独立性也称为数据分布透明性。数据分布透明性是指用户不用关心数据是如何被逻辑分片的(数据分片透明性)，不必关心数据及其端是否被复制或复制副本的个数(数据复制透明性)，也不必关心局部场地上数据库支持哪些数据模型等。
• 5、集中与自治相结合的控制机制
• 6、存在适当的数据冗余度
  传统的数据库系统即集中式数据库系统，减少冗余度是其目标，因为冗余数据会浪费空间，且容易造成数据副本之间的不一致性。但分布式数据库系统中，通过冗余数据可以提高系统的可靠性、可用性以及改善性能，增加冗余度可以方便检索，提高系统的查询速度，但不利于数据的更新，会增加系统维护的成本。
• 7、事务管理的分布性
  大型数据库分布在多个站点上，数据的分布性必然会造成事务执行和管理的分布性，即一个全局事务的执行可分解为在若干个站点上执行的子事务(局部事务)。关于事务的概念，如下。

事务：数据库操作的最小单位，事务是一组操作的集合，要保证整个数据库的一致性，事务中的操作要么都操作，要么都不操作，不存在一组操作中一部分执行一部分不执行的情况。比如银行转账，A转给B一千元则会分两步进行：第一步A的账户减去1000，第二步B的账户加上1000，两个步骤要么都操作，要么都不操作。如果只执行第一步，那么A来说是一种损失；如果只执行第二步，那么对银行来说是一种损失。

3.4分布式数据库系统分类

有两个分类标准，一种是按照构成分布式数据库系统的局部数据库管理系统的数据模型，另一种是按照分布式数据库的全局控制系统类型。

按照构成分布式数据库系统的局部数据库管理系统的数据模型分类:

• 同构型
  如果各个站点上的数据库的数据模型都是同一数据模型(如关系模型)，则称该数据库系统是同构型。但是具有相同类型的数据模型若为不同公司的产品，其性质(如数据表示的格式)也不尽相同。因此DDBS又可以分为同构同质和同构异质两种。关于数据模型，该节(3.4 节)后面会提到一点。
• 异构型
  如果各站点上数据库的数据模型的类型是各不相同的，则称该分部式数据库系统是异构DDBS。

按照分布式数据库的全局控制系统类型分类:

• 全局控制集中型DDBS
• 全局控制分散性DDBS
• 全局控制可变型DDBS

补充:关系模型概念

常见的数据模型有关系模型、网状模型、层次模型等，其中关系模型最为常见。关系模型可以理解为一组关系，其中的每一个关系的数据结构都是一张规范化的二维表。关系模型要求关系是规范化，规范化的最基本条件就是关系的每一个分量都必须是不可再分的数据项，通俗的说法就是不存在大表中嵌套小表。如图所示的表格就不符合关系模型的基本要求。

不符合关系模型

另外，要知道支持关系模型的数据库就是关系数据库。

3.4分布式数据库系统中数据的分片与分布

3.4.1 数据的分片

数据的分片也成数据分割，是分布式数据库的特征之一。全局数据库是有各个局部数据库逻辑组合而成；反之，各个局部数据库由全局数据库的魔种逻辑分割而得。可以想象一份学生名单，第一行分别是学号、姓名、性别、出生年月等。接下来的若干行就是具体的学生信息。在关系型数据库中，就有三种分片方式。即水平分片、垂直分片、混合分片。水平分片即按照若干行划分，如学号小于10的化为一组，其他化为一组；垂直分片可以想象成将学生的姓名和学号独立出来，其他信息再独立成一部分；混合分片就是水平分片和垂直分片两种方式结合。
之所以存在数据分布一说，是因为应有的需要。关系型数据库中不同站点的用户需要该关系中的元组(一组集合，集合中的元素类型可以不相同)可能不同。比如，某个关系中的元组和地区有关，上海站点的用户需要的是包含''上海''的那些元组，而北京站点的用户需要的是包含''北京''的那些元组等。

3.4.2 数据的分布

数据分布是指数据库中的数据不是存储在一个站点的计算机存储设备上，而是根据需要将数据划分成逻辑片段，按照某种策略将这些片段分散在各个站点上。通常有四种分布策略：集中式、分割式、复制式、混合式。

• 集中式:所有数据都放在一个站点上。这样对数据的控制管理比较溶质，数据的一致性可以得到保证。但由于所有数据放在一个站点，所以站点负担较重，加入站点故障，则整个系统直接崩溃。
• 分割式:所有数据只有一份，被分割成若干逻辑片段，每个逻辑片段指派到特定的站点。该方式可以充分利用各个站点的存储设备且数据存储量大。如果某个站点出现故障，系统仍能运行。但是对于去哪聚的查询和修改会比较耗时。
• 复制式:全局数据由多个副本，每个站点都有一个完整副本。该方式可靠性高，响应速度快，数据库的恢复也比较容易。但是要保证各个站点数据的同步修改，将要付出高昂的代价。
• 混合式:兼顾分割师和复制式的做法。

四、传统数据库(集中型数据库)模式结构

集中型数据库有三级模式和两级映像。三级模式即外模式、模式(或概念模式)、内模式。两级映像即外模式/模式映像和模式/内模式映像。

4.1 三级模式

• 外模式
  外模式（亦称子模式或者用户模式），是数据库用户能够看到和使用的局部数据的逻辑结构和特征的描述。外模式保证了数据库的安全性，每个用户只能看到和访问对应外模式中的数据，数据库的其他数据对该用户均不可见。通常情况下来说，1、外模式是模式的的子集，一个数据库可以有多个外模式。2、一个外模式可以被多个应用程序所使用，一个应用程序只能使用一个外模式。
• 模式或概念模式
  模式（亦称逻辑模式）是数据库全体数据的逻辑结构和特征描述，是所有用户的公共数据视图。是数据库系统结构的中间层，既不涉及数据的物理存储细节，也不涉及具体的应用程序、开发工具和语言。通常来说，模式是数据库在逻辑级的视图，一个数据库只有一个模式。

• 内模式
  一个数据库只有一个内模式（亦称存储模式），内模式是数据物理结构和存储方式的描述，是数据库中数据的内部表示方式。

4.2 两级映像

外模式/模式映像保证了数据和程序之间的逻辑独立性；模式/内模式映像保证了数据和程序之间的物理独立性。

• 外模式/模式映像
  模式描述数据的全局逻辑结构，外模式描述数据的局部逻辑结构，外模式是模式的子集。同一个模式可以有多个外模式，每一个外模式在数据库系统中都有一个对应外模式/模式映像。当模式改变时，数据库可以对各个外模式/模式映像做相应的改变，从而使外模式保持不变，，所以应用程序可以不修改。所以说外模式/模式映像保证了数据和程序之间的逻辑独立性。

• 模式/内模式映像
  模式和内模式有且只有一个。模式/内模式映像定义了数据全局逻辑结构与存储结构的对应关系。当数据库的存储方式发生变化时，模式/内模式映像做相应的改变，可使模式保持不变，进而使外模式也保持不变，最后可达到应用程序不变的目的。所以说模式/内模式映像保证了数据和程序之间的物理独立性。

五、分布式数据库模式结构

和集中型数据库不同，分布式数据库模式结构中有六级模式结构和五级映像，具体可以看下图。

分布式数据库模式结构

• 1、全局外模式
  全局外模式是全局应用的用户视图，所以也称为全局视图。同集中型数据库类似全局外模式是全局概念模式的子集。但和集中型数据库最大的不同点是：分布式数据库的全局视图数据不是从某一个站点数据库中抽取出来的，而是从一个逻辑集合(各局部数据库组成的逻辑集合)中抽取出的。
• 2、全局概念模式或全局模式
  全局概念模式主要描述分布式数据库中全局数据的逻辑结构和数据特性。和集中式数据库类似，全局概念模式是分布式数据的全局概念视图。
• 3、分片模式
  分布式数据库中，数据存储的单位是数据的逻辑片段。分片模式描述全局数据的逻辑划分，主要是描述数据分片以及全局关系与片段之前的影响。
• 4、分配模式
  分配模式就是根据选定的数据分配策略，定义各片段物理上存放的站点。
• 5、局部概念模式或局部模式
  局部概念模式是全局概念模式的子集。局部站点模式仅与站点相关，即局部概念模式''局限于''特定站点。
• 6、局部内模式
  局部内模式是分布式数据库中关于物理数据库的描述。类似于集中式数据库中的内模式。

六、总结

文章中的不少内容是笔者从书中提炼出来的，写出一篇文章出来，感觉对这些概念也清晰了很多。三个小时左右的课程大概是讲了这么多的东西，内容不是很多，但是也不少。主要涉及一些概念问题比较多，对于新手而言，还是要花上一些时间去了解的。下周的课程大概是要讲分布式数据库的设计，课程的PPT课件也已经下发，按照老师的意思大概是要提前了解关系代数、数据库事务相关的内容，才能保证跟的上下次课程的进度。

分布式数据库第二次课程补充 (2018年3月18日)

因为该篇文章在实际的课程大纲中算是第一章节，但是第一次三个小时的课程该章节中有部分知识点未涉及，补充的知识点是在第二次上课时所讲。所以这里就在之前写的文章中做些简单补充。后期的博客文章笔记整理应该是按照章节来发布，这样每篇文章就会相对比较系统些。

分布式数据库的分布透明性

分布式数据库的数据独立性也称分布透明性。用户或用户程序使用分布式数据库时，不必关心数据的分布情况，包括:全局数据的逻辑分片、 片段的物理位置分配、各站点数据库的数据模型。三者也即是分片透明性、位置透明性、局部数据模型透明性，说白了就是数据库每层的独立性，保证层级之间的低耦合。

• 分片透明性
  用户编写程序时要了解全局数据的分片情况(即下图的supplier)，但不必了解各逻辑片段的复制副本情况，也不必 关心各片段及其副本的站点位置分配情况。

  
  

• 位置透明性
  用户编写程序时要了解全局数据的分片情况、 各逻辑片段的复制副本情况(即下图的supplier1)，以及各片段和它们的副本的站点位置分配情况，但不必了解各站点上数据库的数据模型。

  
  

• 局部数据模型透明性
  用户编写程序时要了解全局数据的分片情况、 各逻辑片段的复制副本情况，以及各片段和它们 的副本的站点位置分配情况(即下图的supplier1 at site1,site1位具体的站点)，但不必了解各站点 上数据库的数据模型。