扫码获取 VIP 码
添加管理员微信获取 VIP 码
在数据库概念结构设计中，E-R图（实体联系图）的合并是承上启下的关键步骤。当一个信息系统的规模较大时，通常会按照不同的业务子系统分别进行局部E-R图设计——人力资源部门设计员工相关的局部视图，财务部门设计薪资相关的局部视图，生产部门设计物料相关的局部视图。不同部门的局部E-R图完成后，必须整合为一张全局E-R图，这个整合过程就叫做E-R图合并，也叫视图集成。合并的结果直接决定了后续逻辑结构设计（即关系模式设计）的质量。
然而，由于不同的局部E-R图分别由不同的人员、从不同的业务视角独立设计，它们在集成时必然会产生冲突。软考数据库系统工程师和系统架构设计师的考纲中将冲突归纳为三大类：属性冲突、命名冲突和结构冲突。这三类冲突的定义在官方教材中非常明确——属性冲突指同一个属性在不同局部视图中的数据类型、取值范围或度量单位不一致；命名冲突指同一个概念在不同局部视图中使用了不同的名字，或者不同的概念使用了相同的名字；结构冲突指同一个对象在不同局部视图中被抽象为不同的结构层次——在一个视图中是实体，在另一个视图中是属性，或者在两个视图中实体间的联系类型不一致。这三种冲突的识别和解决，是软考E-R图设计类题目的核心得分点。
从工程实践的角度来看，E-R图合并冲突的本质是语义不一致问题。不同部门对同一业务概念的认知边界不同——人资部门关注"员工"的人事属性，培训部门关注"培训师"的专业属性，而培训师实际上是员工的子集，这就产生了结构冲突。如果数据库设计者没有在合并阶段识别并消解这类冲突，直接在逻辑设计阶段将冲突带入关系模式，就可能导致数据冗余、更新异常、甚至语义矛盾——同一事实在数据库中有两套不同的表示方式，哪个才是真相无从判断。因此，E-R图合并不是简单的"把两张图画到一起"，而是一次系统性的语义对齐过程。
属性冲突是最直观也最容易在早期发现的一类冲突。它的根因是不同业务子系统对同一属性的度量标准不一致。典型案例是生产部门用"厘米"记录零件尺寸，而仓储部门用"米"记录库存占用空间，在合并全局视图时，同一属性"尺寸"有了两套数值体系，如果不统一单位，后续的库存容量计算必然出错。另一种常见的属性冲突是数据类型不一致——人事系统中"工号"被定义为字符串类型以支持字母前缀，而考勤系统中"工号"被定义为整数类型以方便排序，合并时这种不一致会导致连接查询失败或隐式类型转换带来的性能问题。
属性冲突的消解方法相对确定：由全局数据库设计者召集各子系统的需求负责人，逐字段比对和统一度量标准和数据类型。技术上通常采用全局数据字典来记录每一个属性的统一定义——包括属性名、业务含义、数据类型、长度、值域、默认值和计量单位。所有局部视图的设计都必须遵守全局数据字典的规定，这就是所谓的"以全局字典仲裁局部差异"。软考的选择题和案例分析题在涉及属性冲突时，通常会考察考生是否能从题目描述中识别出"单位不一致"或"数据类型不一致"是属性冲突而非其他类型冲突。
命名冲突又细分为两个子类：同名异义和同义异名。同名异义指不同的业务概念在各自的局部视图中使用了相同的名称。例如销售部门将"客户联系人"命名为"联系人"，而采购部门将"供应商接洽人"也命名为"联系人"，两者虽然名字相同，但语义完全不同——前者关联的是客户实体，后者关联的是供应商实体。如果在全局视图中不加区分地合并，就会产生语义混乱。同义异名则是相反的场景——同一个概念在不同的局部视图中被赋予了不同的名称。比如财务部门叫"员工编号"，人事部门叫"职工代码"，行政部门叫"人员ID"，但它们指向的是完全相同的业务实体属性。
命名冲突的消解比属性冲突更需要业务领域的深度参与，因为它涉及的是语义层面而非技术层面的不一致。通常的消解方法是建立全局命名规范，在合并过程中进行重命名。对于同义异名，选择最能表达业务含义且最简洁的名称作为全局统一名称，其余废弃或作为别名保留；对于同名异义，则需要通过添加前缀或限定词来区分——例如将"联系人"分别改为"客户联系人"和"供应商联系人"。软考命题人特别喜欢在案例题中设置同义异名陷阱——题目会在不同段落的局部视图描述中使用不同的名称指代同一事物，考生如果没有在合并阶段识别出来，后续的关系模式设计就会出现多余的关系表，从而被扣分。
结构冲突是三种冲突中最复杂也最具设计深度的一类。它的表现形式主要有三种：同一对象在一个视图中被建模为实体，在另一个视图中被建模为属性；同一实体在不同视图中的属性组成不一致；实体之间的联系类型在不同视图中不一致。
以软考真题中的经典案例为例：人力资源部门在设计员工管理子系统时，将"部门"作为员工实体的一个属性——员工实体包含员工号、姓名、性别和部门名称。而行政管理部门在设计办公资源管理子系统时，将"部门"作为一个独立实体——部门实体包含部门编号、部门名称、办公地点和负责人。合并时，"部门"在一个视图中是属性，在另一个视图中是实体，这就是典型的"实体与属性的冲突"。解决这个冲突不能简单地二选一，需要评估部门这个对象是否具有需要独立描述的属性——部门有编号、地点和负责人，显然它具备了独立实体的特征，因此最终应当建模为实体。将部门提升为实体后，员工与部门之间的隶属关系自然形成了两实体间的一对多联系。
这种"先属性后实体"的升级在数据库设计中有一个判断标准：如果一个对象除了名称之外还有其他需要记录的属性，或者它需要参与与其他实体的联系，那么它应当被抽象为实体而非属性。反过来，如果一个对象在当前业务范围内除了充当其他实体的描述特征之外没有独立存在的价值，它可以被建模为属性。这个判断标准在软考的案例分析题中反复出现，是考察考生数据库设计素养的核心指标。此外还需特别留意联系类型不一致这种结构冲突。例如，在销售部门的局部视图中，客户与订单是一对多联系；而在物流部门的局部视图中，客户与订单被建模为多对多联系（因为一个订单可能由多个客户联合采购）。合并时，两个视图中同一对实体之间的联系类型不一致，这同样属于结构冲突。消解方法是根据完整业务语义重新确定正确的联系类型——在通常情况下，客户与订单确实存在多对多场景，应取多对多作为全局视图中的联系类型。
在工程实践中，E-R图的合并通常遵循一套称为"视图集成"的系统化方法，这套方法的步骤与软考考纲高度对应。第一步是选择集成起点——通常选择规模最大、涉及实体最多的局部视图作为基础视图，因为它包含最多的语义信息。第二步是逐一合并——每次集成一个新的局部视图，识别并消解三种冲突后，将新的实体、属性和联系加入到全局视图中。第三步是消除冗余——检查全局视图中是否存在可以从其他数据推导出来的冗余属性或冗余联系，例如总金额可以通过单价乘以数量计算得到，如果两个字段都在全局视图中出现，就构成了冗余数据。
视图集成的策略有两种：一次集成法和逐步集成法。一次集成法是将所有局部视图同时对照、一次性合并为全局视图。这种方法理论效率最高，但要求设计者对全部局部视图都有完整的理解，当子系统数量超过五个时，人的认知负荷就难以支撑。逐步集成法是将局部视图两两合并，每次只处理两个视图之间的冲突，逐步滚动到全部视图集成完毕。逐步集成法的优势在于每次集成的冲突数量可控，更容易保证
本篇完！