分布处理的方案

影响分布处理的体系结构的因素有许多。包括数据分布的类型，分布在许多节点的数据是否重复，因为没有重复就没有多重副本需要同步；数据的通讯，要在通讯费用和延迟之间作出折中，要在通信费用和处理费用之间进行权衡。此外，还有系统支持的数据模型和语言，应用的类型等，不同类型的问题需要不同类型的分布系统，这一点尤其要强调。

具有远程作业录入的集中式的处理和存储。计算机刚刚问世的时候，所有的处理、存储、输入和输出都必须在中心场地来完成。最初只是将打卡机和打印机加以分布，利用远程的作业录入在各个局部场地可以直接读取程序和数据，并传输到中心场地进行处理。然后，输出被直接送到各个局部场地。但作业的递交与完成仍然以批处理方式为基础。
具有联机终端的集中式处理和存储。对于这种事务处理系统，所有的处理和存储资源仍旧是集中式的，在任何位置的用户都能请求并引用中心场地的任何处理能力和资源。因为所有的数据和请求都要传送到中心场地，然后再将结果传送回来，所以通信费用是很高的。现在这种情况很少见了。
具有分布数据录入的集中式处理和存储。在前面方法的基础上，将终端改为具有一定处理能力的智能终端或微机。大多数数据录入和编辑由本地节点完成。当准备登录和加工时，才被送往中心场地并更新数据库或文件。在中心场地处理时，需要进一步的编辑，这类编辑有核查字段值的合理性，几个字段值的一致性，核查数据与数据库是否一致，比如，新顾客号码是否唯一。
具有中心数据库局部分隔的分布式数据录入和编辑。这种方法是前面的简单的扩充。在某个节点上提供附加的存储能力。所有的编辑工作在局部完成。推迟该节点与中心场地通信的时刻。这种方法，数据库的一部分仅仅因为编辑的目的而局部地存放。所有实际的处理和更新都仍然是在中心场地进行。局部副本只是特定时刻部分数据库的快照（快照是数据库部分数据的副本）。与中心数据库并不同步修改。
局部与中心场地链接的分布处理和存储。对上一种处理作一些改善，把局部副本作为某一时刻的快照对待，避免复杂的更新同步的问题，对某些应用来说，不需要副本的秒级同步。新方案是把数据库的一部分永久性地放在局部。这种情况，节点具有局部处理能力，有相当规模的次级存储，数据和程序均可以永久性地存储。仓库管理系统就是一个例子，每一个仓库都存储和维护自己的库存数据。按一定的周期把更新发送到中心场地，修改公司的记录。限制是任何通信都是在局部节点和中心之间进行的，节点之间没有通信。
局部节点互连的分布处理和存储。上一种方案的逻辑扩充就是允许

各个局部节点相互通信。例如，某仓库有一项订货要 100 件，库存只有 50

件，就要从另外的仓库调来 50 件。在前述系统中，要将请求发往中心，再转发给第二个仓库。允许局部场地之间通信，会有一些收益。在大多数情况下，用户必须知道数据存放在何处以及如何去存取它们。系统并不具有确定数据存放位置和自动存取它们的专门的支撑软件，这一层次的增加是属于将系统发展成为分布式数据库管理系统的一部分工作。在没有分布式数据库管理系统能力的情况下，用户必须一次一次分别向每一个仓库发出询问，查看是否有足够的存货，当用户找到一个具有足够熟练的仓库之后，就可以请求填写订货单了。

分布式数据库管理系统。这个方案需要有最大量的软件支持。用户应当能存取系统内任何地方的数据，而无需指定它们的位置。在前面的例子中，分布式数据库管理系统允许用户请求其库存至少有 100 件的仓库。系统向许多局部场地发出请求以便找到一个这样的仓库，并且请求那个仓库提供全部工具。系统作了大量的工作，而用户仅仅是发出了需要 100 件的请求。即使对于这种方案，系统对用户的支持也有着许多不同的层次。一个具体的分布式数据库管理系统的设计允许或不允许数据的重复，然而，一般都有重复，这就要求有许多处理来维护各个副本之间的一致性。下一节将详细介绍分布式数据库管理系统的一些概念。