背景知识:
哲学上有句话说:万事万物都是联系的。在GIS中也是一样,在一个数据集中,要素类与要素类是有关系的,要素类里面的要素之间也是有关系的,那么在我们的GIS实际应用过程中要素类与普通表是有关系的(我们可以使用关联、视图等方式解决),那么上面所说的要素类与要素类的关系我们只能使用关系类来进行管理了。
我们假定一个实际的虚拟场景,在国土行业有这么几个名词:
- 宗地:面状要素类(ZD)
- 房屋:面状要素类(FW)
- 登记卡:普通表(DJK),该表描述对宗地的说明
- 房屋权利人:普通表(FWQLR),该表是对房屋所有者的说明
在实际的业务需求中有这样的业务关系:
- 一个宗地对应一张地籍登记卡
- 一个宗地上面可以有多个房屋
- 一个权利人可以拥有多个房屋
- 一个房屋可以被多个权利人拥有
- 一个宗地的房屋数量是有限制的
那么我们就用关系类来一步步的解决这些业务关系,顺便也学习一下ArcGIS的关系类。
数据情况:

宗地信息ZD:
房屋信息FW:
其他两个普通表就不做例子了,主要是说明一下就可以了。
ArcGIS桌面创建关系类
步骤一:

ArcGIS的关系类都是存储在Geodatabase中,这个就不用解释,从上图可以看到我们需要填写一个关系类的名称(针对这个关系类的名称,其实还有很多小技巧,在我们后面介绍完所有的关系类元素后我们会说明的),这些参与创建的要素类可以是在数据集内,也可以是在数据集外,更重要的一点有一个叫源,有一个叫目的(我们再卖个关子,后面再说明)。
步骤二

我们需要选择这种关系类是简单关系还是复合关系。在说明简单关系和复合关系之前我们需要说说关系类的主键与外键。
在关系类中,源中的对象通过其键字段中的值匹配目标中的对象。
其实这个主键和外键的概念跟数据库的主键外键基本类似,但是关系类的主键不需要像数据库中表的主键一样有唯一值(比较ObjectID),那么大家看到我这个例子可能会纳闷,ArcGIS创建的要素类不是默认都有一个ObjectID,你为什么还要添加一个主键?这一点主要考虑到当用户对一个要素进行分割,那么ObjectID会保留原来的值,然后新建一个新的ObjectID的要素,这些ObjectID用户不能更改,因此,只有具有原始 ObjectID 的要素才会保持由 ObjectID 值决定的所有关系。
所以Esri建议不依赖 ObjectID 字段而是创建并使用自己的主键字段可能会更好。
简单关系
简单关系:在简单关系中,相关对象可以彼此独立存在。例如我们上面的例子所示,针对房屋与宗地的关系就是一个简单关系,如果房屋被删除了,宗地还在,只是房屋与宗地的关系不再了。
由上图我可以看到,如果将源数据的某一条记录删除掉,与此相关联的目的记录的主键设置为NULL状态,而保持原来的数据,因为他们之间可以彼此独立,不会因为一方的删除而联带删除。
复合关系
与此对应的复合关系是两者需要保持引用的完整性的。例如针对宗地与房屋的关系,如果我们删除某一条宗地的记录,那么在宗地上面的房屋必须删除掉,因为不可能出现没有宗地的房屋,那么这种关系就是复合关系。
在复合关系中,目标对象无法独立于源对象存在,因此在删除源对象时,也会在此过程中删除相关的目标对象,这称为级联删除。
从上面的例子我们看出都是房屋与宗地的例子,我们选择源和目的不同,结果是完全不一样的。所以我们看看源和目的的选择。
我们在讨论源与目的其实主要是针对简单关系来说的,从上面的图我们很容易看出:
Case1:我们删除源数据任一ID=2的数据,目标相应数据的外键设置为NULL,那么源数据其他ID=2的数据对应目标数据的关系就中断了,这样正式目标与源设置相反的问题。
Case2:我们设置目标数据任一ID=2的数据,源数据不会发生变化,目标数据的其他ID=2的数据仍然与源数据保持关系一致性。
步骤三

这一步是需要输入向前或者向后的标签(关系类有路径标签。向前和向后路径标签描述了从一个对象到另一个对象的关系。向前路径标签描述了从源类向目标类的关系。向后路径标签描述了目标类向源类的关系。例如在电线杆—变压器的关系中,从变压器到电线杆的方向看,关系路径标签是“is mounted on(已安装)”。同一关系当从电线杆到变压器方向看时,路径标签是“supports(支持)”),输入完标签还需要选择消息方向。
不论正在使用简单关系还是复合关系,都可能存在需要更新某一要素以触发其相关要素中更新的其他操作。此外,在一个方向、另一个方向或两个方向上均可能需要更新。
- 当移动或旋转要素时,需要相关要素与其一起移动或旋转。
- 当更新要素时,需要相关要素中的属性自动更新。
- 更新源对象可要求相关目标对象进行更新。
- 更新目标对象可要求相关源对象进行更新。
如果用户有上面的需求,那么就需要通过消息来进行相互通知,以便对对象进行相关的
更新。那么对消息方向的选择是
- 向前:如果更新源对象时要求对相关目标对象也进行更新
- 向后:如果更新目标对象时要求对相关源对象也进行更新
- 双向:如果以上两种情况都需要

性能考虑
在编辑具有消息关系的要素时,移动、旋转和删除等编辑操作和会通过关系类影响到相
关联的对象。当在这些关系类中导航时是有性能代价的。当关系类中的主键和外键有索引维护时,性能代价最小。当用ArcCatalog创建一个新的关系类时,如果它们还没有索引,主键和外键自动被索引。
步骤四

下面就是选择关系基数,其实对关系基数我们从看最上面的业务需求应该很容易理解选择什么样的关系基数,这里我就不再赘述了。
步骤五

任何关系类,不管是简单还是复杂关系类,也不管其相关度为多少,都可以有属性。具有属性的关系类存储在数据库的一个表中。该表至少包含一个源要素类或表的外键和一个目标要素类或表的外键。一个属性关系也可能包含任何其它属性。例如一个房子可能被多个人所拥有,那么每个人的分摊面积或者拥有比例不一,那么就可以使用关系属性表来说明。
步骤六

这一步就是选择源数据的主键和目的数据的主键。关于主键信息前面已经说明。
关系类名称
关于关系类名称的叫法,根据上面我们说明关系类的属性可以知道,我们的关系类包括源,目的,一对一,一对多,多对多,那么我们就可以在名称上做一些小技巧,是我们一看到名称就应该知道一些关系类的属性。
我们通常将源数据的要素类名称(简写)写在前面,中间以“TO”连接,后面为目的数据要素类名称,如果是一对一,就用名称单数,如果是多对多就用复数。
ZD_TO_FWS(源数据为ZD,目的数据为FW,一对多的关系)
关系规则

关系规则一般是拥有子类的,可以限制能够与目标中某种对象类型相关联的源中的对象数目和类型。比如说一般一个小区有建筑密度的限制,那么可能一块宗地所建的房屋有限制。
相关文档下载地址:http://wenku.baidu.com/view/2dc7e23083c4bb4cf7ecd168.html