以太坊环境下智能合约开发，最重要的特点便是安全：像余额这类的信息，是直接关系到钱的。第二个特点便是：不太适合做大型的、高复杂度合约系统。

原因有以下几个：


1 . 调试困难。虽然有truffle这种利器，让发布合约、测试合约能够用js脚本自动运行，但是出错了排查问题依然是一件非常麻烦的事情，尤其是当合约变多、合约间的调用变多，调试、排错难度急剧增长。
2 . 代码越多隐藏的bug越多。尤其是合约间的相互调用、权限处理。
3 .  合约个数增多，升级合约时所需处理的细节越复杂、易出错。


假如我们非要逆势而为，必须对上述几个问题给出良好的解决方案。

我们在项目中使用了一种以数据为中心的合约结构，并设一白名单控制该数据合约的访问权限（只对set类方法设防，get类不做限制）。改数据合约在整个项目的生存期中，是不可升级的。


为了让DataContract能够存放足够的数据，我们可以为各个数据类中声明一个mapping，如
mapping（uint => uint） m_uintMapUint;

便可以存放任意多的uint变量，只要各个合约之间事先定好index的含义即可。为了方便值的取用，建议使用bytes32做mapping的key：
mapping（bytes32 => uint） m_uintMap;
m_uintMap["varA"] = 10;


一般来说，一个特定的工程当中用的数据类型就那么几种，多生名几个mapping便可满足需求了。

接下来是要解决数据合约的访问权限控制。可以使用一个（address => bool）的mapping记录一个白名单，然后还需要一个modifier来放在数据合约中每个set类方法的后面。最终的DataContract是这个样子的：
contract MyDataContract{
   mapping (bytes32 => uint256) public m_byte32_uint256;
   mapping (bytes32 => address) public m_byte32_address;
   mapping (bytes32 => mapping (address => uint256)) public m_byte32_address_uint256;
   
   mapping (address => bool) public m_whiteList;
   address public m_manager;
   modifier onlyManager{
       require(msg.sender == m_manager);
       _;
   }
    modifier isLegalCall{
       require(m_whiteList[msg.sender]);
       _;
   }
   
   constructor(){
       m_manager = msg.sender;
   }
   
   function addToWhiteList(address _addr)public onlyManager{
        m_whiteList[_addr] = true;
   }
   function removeFromWhiteList(address _addr)public onlyManager{
        m_whiteList[_addr] = false;
   }
   
   function set_byte32_uint256(bytes32 _index, uint256 _val)public isLegalCall{
       m_byte32_uint256[_index] = _val;
   }
}

接下来是控制合约的结构。控制合约一般会有多个，用来实现具体业务逻辑，并且需要能够升级（用来修复bug）。控制合约除了依赖data合约之外，也可能相互依赖。假设B合约依赖A合约的某个方法，则B合约中必然有个变量保存有A合约的地址，升级控制合约A时，一并升级B合约中A的地址信息即可。

大型网站及其架构演进过程
——你的网站现在哪个阶段？
本章首先介绍了大型网站的特征：海量数据、高并发的访问量、网站本身业务和系统的复杂度。基于这些特点，可以确定大型网站必然是一种很常见的分布式系统，而本书重点要介绍的中间件系统也是在大型网站的架构变化中出现并发展的。
然后透过透过一个交易网站的架构演进史来形象反应了大型网站的架构演进过程。
大型网站中，其实最核心的功能就是计算和存储。一个网站从小到大的演进可以说都是在围绕着这两个方面进行处理。
通常我们会选择一个开源的Server作为容器，直接使用JSP/Servlet等技术或者使用一些开源框架来构建我们的应用，选择一个数据库管理系统来存储数据，通过JDBC进行数据库的连接和操作。
2.2.1 用Java技术和单机来构建的网站。如图2-3


图2-3 技术单机构建的网站
2.2.2 从一个单机的交易网站开始：我们重点关注的是随着数据量、访问量提升，网站结构发生的变化。

  图2-4 基于Java技术用单机构建的交易网站
    各个功能模块之间是通过JVM内部的方法调用来交互，而应用和数据库之间是通过JDBC访问。
2.2.3 单机负载告警，数据库与应用分离
    随着服务器的负载持续升高，把数据库与应用从一台机器分到两台机器，调整以后我们能够缓解当前的系统压力。

 图2-5 应用与数据库分开的结构
2.2.4 应用服务器负载告警，如何让应用服务器走向集群。
    应用服务器压力变大时，把应用从单机变为集群。应用服务器从一台变为了两台，用户对两个应用服务器访问的选择问题：可以通过DNS来解决，也可以通过在应用服务器集群前增加负载均衡设备来解决。

 图2-6 应用服务器集群
2.2.4.1 引入负载均衡设备

 图2-7 引入负载均衡设备的结构
2.2.4.2 解决应用服务器变为集群后的Session问题
    在会话开始时，分配一个唯一的会话标识（SessionId），通过Cookie把这个标识告诉浏览器，以后每次请求的时候，浏览器都会带上这个会话标识来告诉Web服务器请求是属于哪个会话的。在Web服务器上，各个会话有独立的存储，保存不同会话的信息。如果遇到禁用Cookie的情况，一般的做法就是把这个会话标识放到URL的参数中。

 图2-8 Session
    会话数据是需要保存在各台单机上的：

 图2-9 负载均衡、应用集群与Session
Session问题的几种解决方案
1．Session Sticky：保证同一个会话的请求都在同一个Web服务器上处理。这需要负载均衡器能够根据每次请求的会话标识来进行请求转发。

 图2-10 Session Sticky方式
    在负载均衡器上做了“手脚”。同时也带来了如下几个问题：
    1.1、如果有一台Web服务器宕机或者重启，那么这台机器上的会话数据会丢失；
    1.2、负载均衡器需要进行应用层（第7层）的解析，这个开销比第4层的交换要大。负载均衡器变为了一个有状态的节点；
    1.3、这种做法内存消耗会更大，容灾方面会更麻烦。
2．Session Replication：在每个服务器中存放一套Session数据

 图2-11 SessionReplication方式
    Web服务器之间则增加了会话数据的同步（Session复制）。这个方案本身也有问题，而且在一些场景下，问题非常严重。
    2.1、同步Session数据造成了网络带宽的开销；
    2.2、每台Web服务器都要保存所有的Session数据；
    2.3、这个方案不适合集群机器数多的场景。
3．Session数据集中存储：Web服务器之间没有了Session数据复制，并且Session数据也不是保存在本机了，而是放在了另一个集中存储的地方。

 图2-12 集中存储Session方式
    存在的问题：
    3.1、读写Session数据引入了网络操作
    3.2、如果集中存储Session的机器或者集群有问题
4．Cookie Based：Session数据放在Cookie中

 图2-13 CookieBased的方式
    存在的不足：
    4.1、Cookie长度的限制
    4.2、安全问题
    4.3、带宽消耗
    4.4、性能影响
2.2.4.3 Session问题小结
    对于大型网站来说，Session Sticky和Session数据集中存储是比较好的方案，而这两个方案又各有优劣，需要在具体的场景中做出选择和权衡。
2.2.5 数据读压力变大后，应用读写分离
2.2.5.1 采用数据库作为读库
    大型网站读多写少，增加一个读库

 图2-14 加入读库后的架构
    增加一个读库对结构的影响：写操作要走主库，事务中的读也要走主库，不同业务选择也会有差异。广义的读写分离可以扩展到更多的场景，实际上是增加了读“源”。
同时也带来两个问题：
    1、数据复制问题。
    2、应用对于数据源的选择问题。
    数据库系统方面的支持：
    1、一般都提供了数据复制的功能
    2、数据复制时延
    3、不同的数据库系统有不同的支持
    3.1、MySQL支持Master（主库）+Slave（备库）的结构，提供了数据复制的机制镜像方式的复制semi-sync
    3.2、Oracle，之前接触的主要是Data Guard方案。Oracle 10g以前物理备库是不可读的，逻辑备库可以提供读服务
2.2.5.2 增加搜索引擎（其实是一个读库）

 图2-15 引入搜索引擎的结构
    搜索集群（Search Cluster）的使用方式和读库的使用方式是一样的，把搜索引擎当成一个读库。
2.2.5.3 加速数据读取的利器——缓存
不管是数据缓存还是页面缓存，都需要考虑缓存命中率的问题。
1．数据缓存
    大型系统中的数据缓存主要用于分担数据库的读的压力，从目的上看，类似于我们前面提到的分库和搜索引擎。特点如下：
    1.1、缓存系统一般是用来保存和查询键值（Key-Value）对的
    1.2、“热”数据
    1.3、通过应用完成的
    1.4、最近不被访问的数据就被清除
    1.5、在数据库的数据发生变化后，主动把数据放入缓存系统中
    1.6、根据数据库记录的变化去更新缓存的代码要能够理解业务逻辑

 图2-16 加入缓存后的结构
2．页面缓存
    ESI就是针对这种情况的一个规范：可以采用ESI或者类似的思路来做，也可以把页面缓存与页面渲染放在一起处理
    对于ESI的处理是在Apache中进行

 图2-17 Apache中的ESI模块
    这样的做法更高效，它把渲染与缓存的工作结合在了一起，而且这种做法只是看起来没有前一种方式分工清晰而已

 图2-18 JBoss中的ESI功能
2.2.6 弥补关系型数据库的不足，引入分布式存储系统
    常见的分布式存储系统有分布式文件系统、分布式Key-Value系统和分布式数据库。文件系统是大家所熟知的，分布式文件系统就是在分布式环境中由多个节点组成的功能与单机文件系统一样的文件系统，它是弱格式的，内容的格式需要使用者自己来组织；而分布式Key-Value系统相对分布式文件系统会更加格式化一些；分布式数据库则是最格式化的方式。

 图2-19 引入分布式存储系统的结构
2.2.7 读写分离后，数据库又遇到瓶颈
    数据垂直拆分和水平拆分
2.2.7.1 专库专用，数据垂直拆分
    垂直拆分的意思是把数据库中不同的业务数据拆分到不同的数据库中

 图2-20 数据库垂直拆分后的结构
    如何处理原来单机中跨业务的事务。一种办法是使用分布式事务，其性能要明显低于之前的单机事务；而另一种办法就是去掉事务或者不去追求强事务支持，则原来在单库中可以使用的表关联的查询也就需要改变实现了。可以根据不同业务的特点进行更多优化。
2.2.7.2 垂直拆分后的单机遇到瓶颈，数据水平拆分
    数据水平拆分就是把同一个表的数据拆到两个数据库中。读写分离解决的是读压力大的问题，水平拆分是把同一个表拆到不同的数据库中。我们可以进一步把用户表拆分到两个数据库中，它们拥有结构一模一样的用户表，而且每个库中的用户表都只涵盖了一部分的用户，两个数据库的用户合在一起就相当于没有拆分之前的用户表。

 图2-21 数据水平拆分后的结构
2.2.8 数据库问题解决后，应用面对的新挑战
2.2.8.1 拆分应用
    第一种方式，根据业务的特性把应用拆开两个应用

 图2-22 根据功能拆分应用
    第二种方式，根据功能拆分成三个系统

 图2-23 按功能拆分后的结构
2.2.8.2 走服务化的路
    处于最上端的是Web系统，处于中间的是一些服务中心，处于下层的则是业务的数据库。

 图2-24 服务化结构
    首先，业务功能之间的访问不仅是单机内部的方法调用了，还引入了远程的服务调用。其次，共享的代码不再是散落在不同的应用中了，这些实现被放在了各个服务中心。第三，数据库的连接也发生了一些变化，我们把与数据库的交互工作放到了服务中心，连接数据库的任务交给相应的业务服务中心了，这样可以降低数据库的连接数。第四，通过服务化，无论是前端Web应用还是服务中心，都可以是由固定小团队来维护的系统，这样能够更好地保持稳定性，并能更好地控制系统本身的发展。
2.2.9 初识消息中间件
    消息中间件：面向消息的系统（消息中间件）是在分布式系统中完成消息的发送和接收的基础软件。优点：异步和解耦。

 图2-25 消息中间件
2.2.10 总结
    我们通过一张图来看看经过演进之后，我们的网站变成什么样子了

 图2-26 整体结构图
 
    后面关于Java中间件的实践部分（第3章）会继续讲解一些更细节的内容。
 

数据库系统概论（第5版）理论习题第一、二章答案
第一章绪论
1.试述数据、数据库、数据库管理系统、数据库系统的概念。
2.使用数据库系统有什么好处？
3.试述文件系统与数据库系统的区别和联系。
4.举出适合用文件系统而不是数据库系统的应用例子，以及适合用数据库系统的应用例子。
5.试述数据库系统的特点．
6.数据库管理系统的主要功能有哪些？
7.什么是概念模型？试述概念模型的作用。
8.定义并解释概念模型中以下术语：实体，实体型，实体集，实体之间的联系。
9.试述关系模型的概念，定义并解释以下术语：
( 1 ) 关系
( 2 ) 属性
(3) 域
(4) 元组
(5) 主码
(6) 分量
(7) 关系模式
10.定义并解释以下术语：
(1) 模式
(2) 外模式
(3) 内模式
(4) DDL
(5) DML
11.试述数据库系统的组成
第二章关系数据库
1.试述关系模型的三个组成部分。
2.简述关系数据语言的特点和分类。
3.定义并理解下列术语，说明它们之间的联系与区别：
(1) 域，笛卡儿积，关系，元组，属性：
(2) 主码，候选码，外部码
(3) 关系模式，关系，关系数据库
4.举例说明关系模式和关系的区别。
5.试述关系模型的完整性规则。在参照完整性中，什么情况下外码属性的值可以为空值？
6.试述等值连接与自然连接的区别和联系。
7.关系代数的基本运算有哪些？如何用这些基本运算来表示其他运算？

第一章绪论
1.试述数据、数据库、数据库管理系统、数据库系统的概念。

(1) 数据(Data): 描述事物的符号记录称为数据。数据的种类有数字、文字、图形、图像、声音、正文等。数据与其语义是不可分的。

(2) 数据库(DataBase, 简称DB): 数据库是长期储存在计算机内的、有组织的、可共享的数据集合。数据库中的数据按一定的数据模型组织、描述和储存，具有较小的冗余度、较高的数据独立性和易扩展性，并可为各种用户共享。

(3) 数据库系统(DataBase Sytem, 简称DBS): 数据库系统是指在计算机系统中引入数据库后的系统构成，一般由数据库、数据库管理系统（及其开发工具）、应用系统、数据库管理员构成。

(4) 数据库管理系统(DataBase Management Sytem, 简称DBMS): 数据库管理系统是位千用户与操作系统之间的一层数据管理软件，用千科学地组织和存储数据、高效地获取和维护数据。DBMS 的主要功能包括数据定义功能、数据操纵功能、数据库的运行管理功能、数据库的建立和维护功能。

2.使用数据库系统有什么好处？

使用数据库系统的好处是由数据库管理系统的特点或优点决定的。使用数据库系统的好处很多，例如，可以大大提高应用开发的效率，方便用户的使用，减轻数据库系统管理人员维护的负担，等等。

使用数据库系统可以大大提高应用开发的效率。因为在数据库系统中应用程序不必考虑数据的定义、存储和数据存取的具体路径，这些工作都由DBMS 来完成。用一个通俗的比喻，使用了DBMS 就如有了－个好参谋、好助手，许多具体的技术工作都由这个助手来完成。开发人员就可以专注千应用逻辑的设计，而不必为数据管理的许许多多复杂的细节操心。

还有，当应用逻辑改变，数据的逻辑结构也需要改变时，由千数据库系统提供了数据与程序之间的独立性，数据逻辑结构的改变是DEA 的责任，开发人员不必修改应用程序，或者只需要修改很少的应用程序，从而既简化了应用程序的编制，又大大减少了应用程序的维护和修改。

使用数据库系统可以减轻数据库系统管理人员维护系统的负担。因为DBMS 在数据库建立、运用和维护时对数据库进行统一的管理和控制，包括数据的完整性、安全性、多用户并发控制、故障恢复等，都由DBMS 执行。

总之，使用数据库系统的优点是很多的，既便千数据的集中管理，控制数据冗余，提高数据的利用率和－致性，又有利千应用程序的开发和维护。读者可以在自已今后的工作中结合具体应用，认真加以体会和总结。

3.试述文件系统与数据库系统的区别和联系。

文件系统与数据库系统的区别是：文件系统面向某一应用程序，共享性差，冗余度大，数据独立性差，记录内有结构，整体无结构，由应用程序自己控制。数据库系统面向现实世界，共享性高，冗余度小，具有较高的物理独立性和一定的逻辑独立性，整体结构化，用数据模型描述，由数据库管理系统提供数据的安全性、完整性、并发控制和恢复能力。

文件系统与数据库系统的联系是：文件系统与数据库系统都是计算机系统中管理数据的软件。解析文件系统是操作系统的重要组成部分；而 DBMS 是独立于操作系统的软件。但是 DBMS 是在操作系统的基础上实现的；数据库中数据的组织和存储是通过操作系统中的文件系统来实现的。

4.举出适合用文件系统而不是数据库系统的应用例子，以及适合用数据库系统的应用例子。

( 1）适用于文件系统而不是数据库系统的应用例子数据的备份、软件或应用程序使用过程中的临时数据存储一般使用文件比较合适。早期功能比较简单、比较固定的应用系统也适合用文件系统。

( 2 ）适用于数据库系统而非文件系统的应用例子目前，几乎所有企业或部门的信息系统都以数据库系统为基础，都使用数据库。例如，一个工厂的管理信息系统（其中会包括许多子系统，如库存管理系统、物资采购系统、作业调度系统、设备管理系统、人事管理系统等），学校的学生管理系统，人事管理系统，图书馆的图书管理系统，等等，都适合用数据库系统。

5.试述数据库系统的特点．

(1）数据结构化数据库系统实现整体数据的结构化，这是数据库的主要特征之一，也是数据库系统与文件系统的本质区别。

( 2 ）数据的共享性高，冗余度低，易扩充数据库的数据不再面向某个应用而是面向整个系统，因此可以被多个用户、多个应用以多种不同的语言共享使用。

( 3 ）数据独立性高数据独立性包括数据的物理独立性和数据的逻辑独立性。数据库管理系统的模式结构和二级映像功能保证了数据库中的数据具有很高的物理独立性和逻辑独立性。

( 4 ）数据由 DBMS 统一管理和控制数据库的共享是并发的共享，即多个用户可以同时存取数据库中的数据甚至可以同时存取数据库中同一个数据。

6.数据库管理系统的主要功能有哪些？

( 1 ）数据库定义功能；

( 2 ）数据存取功能；

( 3 ）数据库运行管理；

( 4 ）数据库的建立和维护功能。

7.什么是概念模型？试述概念模型的作用。

概念模型，也称信息模型，是按用户的观点来对数据和信息建模，主要用于数据库设计。

概念模型实际上是现实世界到机器世界的一个中间层次。概念模型用于信息世界的建模，是现实世界到信息世界的第一层抽象，是数据库设计人员进行数据库设计的有力工具，也是数据库设计人员和用户之间进行交流的语言。

8.定义并解释概念模型中以下术语：实体，实体型，实体集，实体之间的联系。

实体：客观存在并可以相互区分的事物叫实体。实体型：具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体，称为实体型。实体集：同型实体的集合称为实体集；实体之间的联系：通常是指不同实体型的实体集之间的联系，实体之间的联系有一对一，一对多和多对多等多种类型。

9.试述关系模型的概念，定义并解释以下术语：

关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在用户观点下，关系模型中数据的逻辑结构是一张二维表，它由行和列组成。

( 1 ) 关系

关系：一个关系对应通常说的一张表；

( 2 ) 属性

属性：表中的一列即为一个属性；

(3) 域

域：属性的取值范围；

(4) 元组

元组：表中的一行即为一个元组；

(5) 主码

主码：表中的某个属性组，它可以惟一确定一个元组；

(6) 分量

分量：元组中的一个属性值；

(7) 关系模式

关系模式：对关系的描述，一般表示为关系名（属性 1 ，属性 2 ， … ，属性 n )

10.定义并解释以下术语：

模式、外模式、内模式，亦称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。

(1) 模式

模式描述的是数据的全局逻辑结构。

(2) 外模式

外模式涉及的是数据的局部逻辑结构，通常是模式的子集。

(3) 内模式

内模式，亦称存储模式，是数据在数据库系统内部的表示，即对数据的物理结构和存储方式的描述。

(4) DDL

DDL ：数据定义语言，用来定义数据库模式、外模式、内模式的语言。

(5) DML

DML ：数据操纵语言，用来对数据库中的数据进行查询、插入、删除和修改的语句。

11.试述数据库系统的组成

数据库系统一般由数据库、数据库管理系统（及其开发工具）、应用系统、数据库管理员和用户构成。

第二章关系数据库
1.试述关系模型的三个组成部分。

关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。

2.简述关系数据语言的特点和分类。

关系模式:关系的描述称为关系模式(Relaionschcm)。它可以形式化地表

示为R(U,D,dom,F)其中R为关系名,U为组成该关系的属性名集合,D为属性组U中属性所来的域,dom为属性向域的映像集合,F为属性间数据的依赖关系集合.

关系:在域D1,D2,…,Dn上笛卡儿积D1xD2x…xDn的子集称为关系,

表示为R(D1,D2,…,Dn)

关系是关系模式在某一时刻的状态或内容。关系模式是静态的、稳定的;而关系是动态的随时间不断变化的,因为关系操作在不断更新着数据库中的数据。

关系数据库:关系数据库也有型和值之分。关系数据库的型也称为关系数

据库模式,是对关系数据库的描述,它包括若干域的定义以及在这些域上定义的,若干关系模式。关系数据库的值是这些关系模式在某一时刻对应的关系的集合,通常就称为关系数据库。

3.定义并理解下列术语，说明它们之间的联系与区别：
(1) 域，笛卡儿积，关系，元组，属性：

域：域是一组具有相同数据类型的值的集合。

笛卡儿积：给定一组域D1，D2, …， Dn, 这些域中可以有相同的。这组域的笛卡儿积为D1 ×D2 × … × Dn = {( d1,d2, …, dn) |di∈ Di, i = 1,2, …, n}其中每一个元素(d1,d2, …, dn) 叫做一个n 元组(n-tuple) 或简称元组(Tuple) 。元素中的每一个值di 叫做一个分量(Component) 。

关系：在域D1，D2, …， Dn 上笛卡儿积D1 ×D2 × … × Dn 的子集称为关系，表示为R(D1，D2, …， Dn)

元组：关系中的每个元素是关系中的元组。

属性：关系也是一个二维表，表的每行对应一个元组，表的每列对应一个域。由千域可以相同，为了加以区分，必须对每列起一个名字，称为属性(Attribute) 。

(2) 主码，候选码，外部码

候选码：若关系中的某－属性组的值能惟一地标识一个元组，则称该属性组为候选码(Candidate key) 。

主码：若一个关系有多个候选码，则选定其中一个为主码(Primary key) 。

外部码：设F 是基本关系R 的一个或－组属性，但不是关系R 的码，如果F与基本关系s 的主码Ks 相对应，则称F 是基本关系R 的外部码(Foreign key),简称外码。基本关系R 称为参照关系(Referencing relation), 基本关系S 称为被参照关系(Referenced relation) 或目标关系(Target relation) 。关系R 和S 可以是相同的关系。

(3) 关系模式，关系，关系数据库

关系模式：关系的描述称为关系模式(Relation Schema) 。它可以形式化地表示为R(U, D, dom, F)其中R 为关系名，U为组成该关系的属性名集合，D 为属性组U中属性所来自的域， dom 为属性向域的映像集合，F为属性间数据的依赖关系集合。

关系：在域D1，D2, …， Dn 上笛卡儿积D1 ×D2 × … × Dn 的子集称为关系，表示为R(D1，D2, …, Dn)

关系数据库：在关系模型中，实体以及实体间的联系都是用关系来表示的。例如导师实体、研究生实体、导师与研究生之间的的一对多联系都可以分别用一个关系来表示。在一个给定的应用领域中，所有关系的集合构成一个关系数据库。关系数据库也有型和值之分。关系数据库的型也称为关系数据库模式，是对关系数据库的描述，它包括若干域的定义以及在这些域上定义的若干关系模式。关系数据库的值是这些关系模式在某一时刻对应的关系的集合，通常就称为关系数据库。

4.举例说明关系模式和关系的区别。

关系是关系模式在某一时刻的状态或内容。关系模式是静态的、稳定的；而关系是动态的、随时间不断变化的，因为关系操作在不断更新着数据库中的数据。

5.试述关系模型的完整性规则。在参照完整性中，什么情况下外码属性的值可以为空值？

实体完整性规则是指若属性A是基本关系R的主属性，则属性A不能取空值。

若属性(或属性组)F是基本关系R的外码，它与基本关系S的主码Ks相对应(基本关系R和S不一定是不同的关系)，则对于R中每个元组在F上的值必须为：或者取空值(F的每个属性值均为空值)；或者等于S中某个元组的主码值。即属性F本身不是主属性，则可以取空值，否则不能取空值。

6.试述等值连接与自然连接的区别和联系。

连接运算符是“=”的连接运算称为等值连接。它是从关系R与S的广义笛卡尔积中选取A，B属性值相等的那些元组

自然连接是一种特殊的等值连接，它要求两个关系中进行比较的分量必须是相同的属性组，并且在结果中把重复的属性列去掉。

7.关系代数的基本运算有哪些？如何用这些基本运算来表示其他运算？

并、差、笛卡尔积、投影和选择5种运算为基本的运算。其他3种运算，即交、连接和除，均可以用这5种基本运算来表达。

文章目录
设计模式-创建型模式(二)
建造者模式
定义
特点
结构
实现
应用场景
扩展
原型模式
定义
结构
实现
应用场景

设计模式-创建型模式(二)
建造者模式
定义
将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示。它是将一个复杂的对象分解为多个简单对象，然后一步一步的构建而成。即产品的组成是不变的，但每一部分是可以灵活选择的。
特点
优点

各个具体的建造者相互独立，有利于系统的扩展
客户端不必知道产品的内部组成细节，便于控制细节风险

缺点

产品的组成部分必须相同，这限制了其使用范围
如果产品的内部变化复杂，该模式会增加很多的建造者类

结构
建造者模式的主要角色如下：

产品（Product)：它是一个复杂对象(由多个部件组成)，由具体建造者来创建其各个部件。
抽象建造者(Builder)：定义了创建产品各个子部件的抽象方法的接口，通常还包含一个返回复杂产品的方法build()。
具体建造者(Concrete Builder)：实现了抽象建造者定义的接口，完成对复杂产品各个部件的具体创建方法。
指挥者(Director)：它调用建造者对象中的部件构造与装配方法完成复杂对象的创建，在指挥者中不涉及具体产品的信息。



实现
案列：汽车生产是一个复杂过程，包含发动机、车门、方向盘等，这里通过建造者模式实现对复杂的汽车部件进行生产组装。
/**
 *1、定义汽车产品，（包含多个部件，由具体建造者来创建各个部件）
 */
public class Car {
    //车轮
    String tyre;
    //发动机
    String engine;
    //车门
    String door;
    //方向盘（如果没有则是自动驾驶汽车）
    String wheel;

    public void setTyre(String tyre) {this.tyre = tyre;}
    public void setEngine(String engine) {this.engine = engine;}
    public void setDoor(String door) {this.door = door;}
    public void setWheel(String wheel) {this.wheel = wheel;}
    public String getTyre() {return tyre;}
    public String getEngine() {return engine;}
    public String getDoor() {return door;}
    public String getWheel() {return wheel;}
    public void show() {
        String tyreStr = isNull(getTyre()) ? "无车轮" : "有车轮";
        String engineStr = isNull(getEngine()) ? "新能源" : "非新能源";
        String doorStr = isNull(getDoor()) ? "敞篷" : "非敞篷";
        String wheelStr = isNull(getWheel()) ? "自动驾驶" : "非自动驾驶";
        System.out.println("建造一辆" + tyreStr + engineStr + doorStr + wheelStr + "汽车");
    }
}

/**
 *2、定义抽象建造者类或接口(提供创建复杂对象部件的抽象方法，以及返回复杂产品的实例)
 */
public interface ICarBuilder {
    //创建轮胎
    void setTyre();

    //创建车门
    void setDoor();

    //创建发动机
    void setengine();

    //创建方向盘
    void setWheel();

    //返回一个复杂对象
    Car build();
}

/**
 *3、定义具体建造者，实现抽象建造者定义的抽象方法，完成对复杂对象部件的具体创建。
 */

//公共汽车建造者
public class BusBuilder implements ICarBuilder {
    
    @Override
    public void setTyre() {}

    @Override
    public void setDoor() {}

    @Override
    public void setengine() {}

    @Override
    public void setWheel() {}

    @Override
    public Car build() {
        System.out.print("公共汽车具体建造者——>");
        Car car = new Car();
        car.setTyre("有");
        car.setDoor("有");
        car.setEngine("有");
        car.setWheel("有");
        return car;
    }
}

//出租车建造者
public class TaxiBuilder implements ICarBuilder {
    
    @Override
    public void setTyre() {}

    @Override
    public void setDoor() {}

    @Override
    public void setengine() {}

    @Override
    public void setWheel() {}

    @Override
    public Car build() {
        System.out.print("出租车具体建造者——>");
        Car car = new Car();
        return car;
    }
}

/**
 *4、定义指挥者（调用具体建造者中部件构建与装配方法完成复杂对象创建）
 *   指挥者中不涉及具体产品信息
 */
 public class Director {

    ICarBuilder iCarBuilder;

    public Director(ICarBuilder iCarBuilder) {
        this.iCarBuilder = iCarBuilder;
    }

    public Car createCar() {
        return iCarBuilder.build();
    }
} 

//测试
public class Test {
    public static void main(String[] args) {
        ICarBuilder busBuilder = new BusBuilder();
        Director director = new Director(busBuilder);
        director.createCar().show();

        ICarBuilder taxiBuilder = new TaxiBuilder();
        Director director2 = new Director(taxiBuilder);
        director2.createCar().show();
    }
}
//输出
公共汽车具体建造者——>建造一辆有车轮非新能源非敞篷非自动驾驶汽车
出租车具体建造者——>建造一辆无车轮新能源敞篷自动驾驶汽车

应用场景
建造者(Builder)模式创建的对象是负责对象，某产品的各个部分经常面临剧烈变化，但将它们组合在一起的算法相对稳定，所以通常在如下场景使用：

创建的对象比较复杂，由多个部件构成，各部件面临复杂变化，但构建顺序是稳定的
创建复杂对象短发独立于该对象的组成部分以及它们的装配方式，即产品的构建过车和最终的表示是独立的。

扩展
建造者模式在应用过程中可以根据需要改变，如果创建的产品种类只有一种，只需要一个具体建造者，这时可以省略掉抽象建造者，甚至可以省略掉指挥者角色
/**
 *创建产品(通过静态内部类实现建造者模式)
 */
public class ExtCar {

    //车轮
    String tyre;
    //发动机
    String engine;
    //车门
    String door;
    //方向盘（如果没有则是自动驾驶汽车）
    String wheel;

    public void setTyre(String tyre) {this.tyre = tyre;}

    public void setEngine(String engine) {this.engine = engine;}

    public void setDoor(String door) {this.door = door;}

    public void setWheel(String wheel) {this.wheel = wheel;}

    public String getTyre() {return tyre;}

    public String getEngine() {return engine;}

    public String getDoor() {return door;}

    public String getWheel() {return wheel;}

    public void show() {
        String tyreStr = isNull(getTyre()) ? "无车轮" : "有车轮";
        String engineStr = isNull(getEngine()) ? "新能源" : "非新能源";
        String doorStr = isNull(getDoor()) ? "敞篷" : "非敞篷";
        String wheelStr = isNull(getWheel() ) ? "自动驾驶" : "非自动驾驶";
        System.out.println("建造一辆" + tyreStr + engineStr + doorStr + wheelStr + "汽车");
    }

    //静态内部类实现建造者模式
    public static class Builder {
        //车轮
        String tyre;
        //发动机
        String engine;
        //车门
        String door;
        //方向盘（如果没有则是自动驾驶汽车）
        String wheel;

        public Builder setTyre(String tyre) {
            this.tyre = tyre;
            return this;
        }

        public Builder setEngine(String engine) {
            this.engine = engine;
            return this;
        }

        public Builder setDoor(String door) {
            this.door = door;
            return this;
        }

        public Builder setWheel(String wheel) {
            this.wheel = wheel;
            return this;
        }

        public ExtCar build() {
            ExtCar extCar = new ExtCar();
            extCar.setTyre(tyre);
            extCar.setEngine(engine);
            extCar.setDoor(door);
            extCar.setWheel(wheel);
            return extCar;
        }
    }
}

//测试
public class Test {
    public static void main(String[] args) {
        //选择性构建部件
        ExtCar car1 = new ExtCar.Builder()
                .setTyre("有")
                .setEngine("有")
                .build();
        car1.show();
       //选择性构建部件，与car1构建过程一致，但最终表示不同
        ExtCar car2 = new ExtCar.Builder()
                .setDoor("有")
                .setWheel("有")
                .build();
        car2.show();
    }
}
//输出
建造一辆有车轮非新能源敞篷自动驾驶汽车
建造一辆无车轮新能源非敞篷非自动驾驶汽车

原型模式
定义
用一个已经创建的实例作为原型，通过复制该原型来创建一个和原型相同或相似的对象。在这里，原型实例指定了要创建的对象种类，用这种方式创建对象非常高效，根本无需知道对象的创建细节。
结构
原型模式包含一下角色

抽象原型类：规定了具体原型对象必须要实现的接口。
具体原型类：实现了抽象原型类的clone()方法，它是可以被复制的对象。
访问类：使用具体原型类中的clone()方法来复制新的对象的类。



实现
原型模式的克隆分为浅克隆和深克隆，Java 中的 Object 类提供了浅克隆的 clone() 方法，具体原型类只要实现 Cloneable 接口就可实现对象的浅克隆，这里的 Cloneable 接口就是抽象原型类。
用原型模式除了可以生成相同的对象，还可以生成相似(部分属性不同)对象。
案例：同一三好学生奖状除了人名不同，其他都相同，属于相似对象，可以通过原型模式实现，然后再做简单修改即可
/**
 *1、具体原型类(实现抽象原型类Cloneable接口的clone()方法)-奖状
 */
public class Citation implements Cloneable {

    String name;
    String info;

    public String getName() {return name;}

    public void setName(String name) {this.name = name;}

    public String getInfo() {return info;}

    public void setInfo(String info) {this.info = info;}

    public Citation(String name, String info) {
        this.name = name;
        this.info = info;
    }

    public void show() {System.out.println(getName() + getInfo());}

    //重写抽象原型类中的cone()方法
    @Override
    public Object clone() throws CloneNotSupportedException {
        return super.clone();
    }
}

//访问类
public class Test {
    public static void main(String[] args) {
         Citation zhangsan = new Citation("张三", "同学，在2019年第一学年度被评为三好学生,"+
                                          "特发此状以此鼓励！");
         zhangsan.show();
        try {
            //使用原型模式复创建新对象
            Citation lisi = (Citation) zhangsan.clone();
            //修改部分属性
            lisi.setName("李四");
            lisi.show();
        } catch (CloneNotSupportedException e) {
            e.printStackTrace();
        }
    }
}

//输出
张三同学，在2019年第一学年度被评为三好学生，特发此状以此鼓励！
李四同学，在2019年第一学年度被评为三好学生，特发此状以此鼓励！

应用场景
原型模式适用于以下场景

对象之间相同或相似，即只是个别的几个属性不同的时候。
对象的创建过程比较麻烦，但是复制比较简单的时候。

参考文献