MySQL数据库复制的几个常用拓扑结构

可以通过以下sql实现

sql：insert into tablename1（filename3，filename4） as select filename1, filename2 from tablename2

解释：从tablename2表中读取出filename1和filename2字段插入到tablename1表中的

filename3和filename4字段中。

备注：插入表的字段顺序和查询表的字段顺序必须保持一致。

英文

topology

的音译.

拓扑学就是以空间几何的形式来表现事物内部的结构,原理,工作状况等.

比如你的计算机吧,学过搜索算法吧(广度优先(breath-first)和深度优先(depth-first,

不知道中文译的对不对)算法).你在分析的时候不是把所有的状态画成一个树状表,然后来看一步步怎样查找的么.这就是运用拓扑逻辑的方法.

当然,从这里你就可以看到,拓扑都在处理离散的状态.

说白了,系统逻辑流程图也是拓扑图.

听起很深奥,很玄,其实常常用到

两种典型的GIS数据模型

1、拓扑关系数据模型

拓扑关系数据模型以拓扑关系为基础组织和存储各个几何要素，其特点是以点、线、面间的拓扑连接关系为中心，它们的坐标存贮具有依赖关系。该模型的主要优点是数据结构紧凑，拓扑关系明晰，系统中预先存储的拓扑关系可以有效提高系统在拓扑查询和网络分析方面的效率，但也有不足：

对单个地理实体的 *** 作效率不高。由于拓扑数据模型面向的是整个空间区域，强调的是各几何要素之间的连接关系，在另一方面对具有完整、独立意义的地理实体作为个体存在的事实没有足够的重视，因此增加、删除、修改某一地理实体时，将会牵涉到一系列文件和关系数据库表格，这样不仅使程序管理工作变得复杂，而且会降低系统的执行效率。

难以表达复杂的地理实体。由于拓扑关系组织的要求，一个完整的简单实体在拓扑关系模型中有时需要被分解为多个几何要素（比如一条公路本是一个完整的实体，但为了记录其拓扑邻接信息，只有对其在与其它公路实体邻接的地方进行分段，这样一个完整的实体就被分成多个几何要素。所有的实体都进行如此处理，所以我们说拓扑数据模型是面向整个区域、面向不被分割的几何要素的，而不是面向用户眼中的地理实体）。复杂地理实体由多个简单实体组合而成，自然也常常被分解，拓扑数据模型的整体组织特性注定了它不可能有效地表达这一由多个独立实体构成的有机集合体。

难以实现快速查询和复杂的空间分析。由于在拓扑数据模型中，地理实体被分解为点、线、面基本几何要素存储在不同的文件和关系表中，因而凡涉及到独立地理实体的 *** 作、查询和分析都将花费较多的CPU时间，在大区域的复杂空间分析方面表现尤为明显。

局部更新困难，系统难于维护与扩充。由于地理空间的数据组织和存储是以基本几何要素（点、弧段和多边形）为单元进行的，系统中存储的复杂拓扑关系是GIS工作的数据基础，当局部一些实体发生变动时，整层拓扑关系将不得不随之重建，这样的系统牵一发而动全身，在维护和扩充方面需要更多的精力，并且容易出错。

值得说明的是，拓扑关系数据模型也能以面向对象的方式实现，但此时面向的对象是不被其它要素从中间分割的几何要素，往往是一个独立地理实体的一部分，而不是一个完整的、独立的地理实体。这一点是拓扑关系数据模型与下一节面向实体数据模型本质不同的重要表现之一。

2、面向实体的数据模型

里称为“面向实体”，是为了强调这种数据模型是以单个空间地理实体为数据组织和存储的基本单位的。

与上述拓扑模型相反，该模型以独立、完整、具有地理意义的实体为基本单位对地理空间进行表达。在具体组织和存储时，可将实体的坐标数据和属性数据（如建立了部分拓扑，拓扑关系也放在表中保存）分别存放在文件系统和关系数据库中，也可以将二者统一存放在关系数据库中（可以将坐标数据和属性数据放在同一个表中，也可以将二者分成两个表，ESRI公司SDE的存贮模式是分成四个表格，它还增加了一个Layers表和一个空间索引表。Layers表位于服务器端，用于层的管理和维护；空间索引表（服务器端）采用网格索引，用于实体的快速搜索）。

面向实体的数据模型在具体实现时采用的是完全面向对象的软件开发方法，每个对象（独立的地理实体）不仅具有自己独立的属性（含坐标数据），而且具有自己的行为（ *** 作），能够自己完成一些 *** 作。虽然面向实体的数据模型在内部组织上可以按照拓扑关系进行，但是作者这里所说的模型强调对象的坐标存贮之间（尤其是面与线的坐标存贮）不具有依赖关系，这是它与拓扑关系模型的本质不同点。该模型能够很好地克服拓扑关系数据模型的几个缺点，具有实体管理、修改方便，查询检索、空间分析容易的优点，更重要的是它能够方便地构造用户需要的任何复杂地理实体，而且这种模式符合人们看待客观世界的思维习惯，便于用户理解和接受。同时，面向实体的数据模型自然地具有系统维护和扩充方便的优点。

这种模型是当今流行GIS软件采用的最新数据模型，但也有一些缺点：

拓扑关系需临时构建。由于面向实体的数据模型是以地理实体为中心的，并未以拓扑关系为基础组织、存储地理实体，表达地理空间，因此拓扑关系并不是一开始就存在，而是在需要时才临时导出各种拓扑关系，这需要消耗一定的系统资源。也许有观点认为，以实体为单位组织数据时，也可以将拓扑关系一开始就保存在实体的属性表中，拓扑关系并不一定是临时构建出来的。但仔细分析便可发现，这种方案对由多个几何要素组成的实体（如一条组成要素不同的河流）不可行，因为拓扑关系不能有效准确地记录。实际上这种方案只对由一个几何要素组成的实体适用，但其本质上仍是拓扑关系数据模型，其缺点表征与上面2.1节描述的完全相同，因而不是真正的面向实体数据模型。

动态分段、网络分析效率降低。在结点---弧段---多边形拓扑关系链中，显式的拓扑表有四个：结点---弧段表，弧段---结点表，弧段---多边形表和多边形---弧段表。有了这四个关系表，我们就能直接查找任意结点、弧段和多边形的拓扑属性，便于进行动态分段和网络分析等其它与拓扑关系有关的拓扑分析，基于拓扑数据模型的GIS可以很方便地做到这一点。但由于将四个拓扑表全部存贮会使系统的空间开销成倍增大，因此一些软件只存贮其中2个（如早期的System 9版本）或将弧段—结点、弧段—多边形表合二为一（Arc/Info 8.0以前版本），被隐含的表可由显示存在的表导出。即便这样，基于拓扑数据模型的GIS在涉及拓扑关系的查询和分析上仍然有较高的效率，而面向实体的数据模型由于要根据需要临时构建拓扑关系，自然会使拓扑查询和分析的效率降低。当然构建好的拓扑关系可存放起来，供以后使用。

实体间的公共点和公共边重复存贮。由于面向实体的数据模型是以地理实体为基本单位进行数据组织和空间表达的，对每一个地理实体都进行完整存贮（存贮到点一级），在存贮坐标时是各对象独立存贮，不再依赖其它对象，那么就必然会导致实体间共有的公共点和公共边重复存贮。

难以将管理、分析和处理定位到几何要素一级。几何要素是指点、弧段和多边形等简单图形，有时构成同一实体的各个几何要素之属性差别较大（例如组成一块宗地的各边之面积不一样，某一交通闭合环路的组成道路类型不一样等），需要在地理实体的下一级---几何要素一级上进行处理，拓扑数据模型可以直接进行处理，而面向实体的数据模型则需要首先对相关地理实体进行定位、分解，因而降低系统在这方面的性能。从本质上分析，我们不难得到，由于该种模型认为组成同一实体的几何要素之属性相同，因而忽略了几何要素间的属性差异，从而导致在系统存贮和处理机制上难以定位到几何要素一级。

难以实现跨图层的拓扑查询和分析。如果这个问题放在拓扑关系模型中，则比较容易解决，因为各个要素的邻接要素已事先存在，不仅已经是分层的，而且具有实际的地理属性，因此只要顺藤摸瓜查找邻接要素并取得其地理属性即可。但对于面向实体的数据模型，则不能有效地解决，因为临时生成拓扑关系时其中的几何要素一般属于同一层，不可能自动生成跨图层的地理属性，必须做进一步的处理方才有可能解决。显然，这种方法的效率不高。

---