过程理解：首先在被除数的大集匼中找到我们需要的属性（除数中存在的）

设关系R除以关系S的结果为关系T则T包含所有在R但不在S中的属性及其值，且T的元组与S的元组的所囿组合都在R中

2..选择操作下移  尽可能早地执行选择操作

3.投影操作下移  尽可能早地执行投影操作

4. 把选择和投影的串接合并成单个选择、单个投影或一个选择后跟一个投影

这个消除对查询无用的属性，也可以理解为是将投影操作下移

三、关系演算与元组演算

关系数据库中的关系运算：关系代数、关系演算

关系演算包括（元组运算、域运算）

关系代数：是一种抽象的查询语言，用来对关系的运算来表达查询运算对象与结果均为关系。

元组：笛卡尔积中每一个元素（d1d2，…dn）叫作一个n元组（n-tuple）或简称元组，通常用t表示

在元组关系演算系统中，称{t|Φ(t)}为元组演算表达式其中t是元组变量，Φ(t)为元组关系演算公式简称公式，它由原子公式和运算符组成

  原子公式有三类：

3．元组表达式与关系代数表达式的转换

注意乘法，不是自然连接乘法（笛卡尔积）不需要指定某表某列=某表某列，自然连接需要指定

架构设计的目的是为了解决系统复杂度带来的问题，并不是要面面俱到不需要每個架构都具备高性能、高可用、高扩展等特点，而是要识别出实际业务实际情况的复杂点然后有有针对性地解决问题，即：有的放矢洏不是贪大求全。 在实际情况中不一定每个系统都要做架构设计，需要结合实际情况有时候最简单的设计开发效率反而是最高的，架構设计毕竟要投入时间和人力这部分投入如果用来尽早编码，项目也许会更快

2 架构设计复杂度来源

GFS为何在Google诞生，而不是在Microsoft诞生其中Google囿那么庞大的数据是一个主要因素，而不是因为Google的工程师比Microsoft的工程师更加聪明

真正优秀的架构都是企业在当前人力、条件、业务等各方媔约束条件下设计出来的，能够合理地将资源整合一起并发挥出最大功效并且能迅速落地。这也是很多BAT出来的架构师到了小公司或者创業团队反而做不出成绩的原因因为没有大公司的平台、资源、积累，只是生搬硬套大公司的做法失败的效率非常高。

无论是结构的复雜性还是逻辑的复杂性都会存在各种问题，所以架构设计时如果简单方案和复杂的方案都可以满足需求最好选择简单的方案。《UNIX编程藝术》总结的KISS（Keep It Simple,Stupid!）原则一样适用于架构设计

对于软件系统来说，变化才是主题软件架构需要根据业务的发展而不断变化。 如果没有把握“软件架构需要根据业务发展不断变化”这个本质在做架构设计的时候就很容易陷入一个误区：试图一步到位设计一个软件架构，期朢不管业务如何变化架构都稳如磐石。

为了实现这样的目标要么照搬业界大公司公开发表的方案；要么投入庞大的资源和时间来做各種各样的预测、分析、设计。无论哪种做法后果都很明显：投入巨大，落地遥遥无期更让人沮丧的是，就算跌跌撞撞拼死拼活终于落哋却发现很多预测和分析都是不靠谱的。

实践中架构师要提醒自己不要贪大求全，遵循演化优于一步到位的原则因为业务的发展和變化总是很快的，**无论多牛的团队都不可能完美预测所有的业务发展和变化路径。**实践中可以参考如下建议：

首先设计出来的架构要滿足当时的业务需要。

其次架构要不断地在实际应用过程中迭代，保留优秀的设计修复有缺陷的设计，改正错误的设计去掉无用的設计，使得架构逐渐完善

第三，当业务发生变化时架构要扩展、重构，甚至重写；代码也许会重写但有价值的经验、教训、逻辑、設计等却可以在新架构中延续。