订单表里已经有了customer_id，在erwin Data Modeler中补画客户与订单的关系后，订单表却多出了一个从客户表迁移过来的id。这时可以给迁移的外键设置角色名，让它与已有列同名，再处理重名提示。角色名也能用来区分两条指向同一张表的关系，例如把订单的创建人和审核人分成两个字段。两种场景用的是同一个设置入口，填写时要看子表里的列各自代表什么。

　　一、erwin外键角色名怎么设

　　外键角色名描述的是父键迁移到子表后承担的业务角色。以下用erwin Data Modeler英文界面的关系属性说明，以父表主键迁移到子表的场景为例。

　　1、在关系属性中填写角色名

　　假设客户表的主键叫id，订单表希望用customer_id表示下单客户。角色名应设置在客户与订单的这条关系上。

　　①在物理模型中找到【customer】和【orders】之间的关系线，右击该线并选择【Properties】。

　　②切换到【Role Name】选项卡，找到父表主键【id】对应的迁移列，将角色名填为【customer_id】。

　　③确认修改后，回到模型图或子表的列列表，核对【orders】中的外键名称。若弹出同名列处理向导，按下一节的方法判断是否替换。

　　2、给指向同一父表的外键分别命名

　　①分别打开【employee】到【orders】的创建人关系和审核人关系，在各自的【Properties】中进入【Role Name】。

　　②将父键【id】在两条关系上的角色名分别设为【created_by_id】和【approved_by_id】，确认后查看子表。

　　③在【orders】中核对两列及其对应的关系，确认创建人和审核人各自引用员工表的主键。

　　两列都引用员工编号，但各自保存的员工可以不同。单独命名能避免erwin把来自同一基础键的两次迁移统一为一列。如果使用逻辑与物理组合模型，并希望物理列名继续继承逻辑属性名，可在逻辑侧设置角色名，再核对物理侧的命名结果。

　　二、erwin怎么用外键角色名复用已有列

　　已有列能否接上外键，取决于它是否存放同一个业务标识。以orders.customer_id为例，确认它存的是customer.id后，再把迁移过来的外键角色名设成customer_id，并在向导中选择替换。

　　1、核对现有列和父键的含义

　　①在物理模型中打开【customer】的列属性，确认【id】是关系要引用的主键，记下它的数据类型和长度。

　　②打开【orders】的列属性，核对【customer_id】的定义、数据类型和可空性，确认它用于记录下单客户。

　　③若【customer_id】已经参与索引、键或其他关系，记下对应对象，留待替换后检查。

　　列名相同只是模型中触发重名处理的条件。比如子表中已有的customer_id如果实际保存外部系统的客户编码，就应先确认它与本地客户主键的对应方式。直接合并会让同一列承担两种含义。

　　2、让角色名匹配已有列并选择替换

　　①建立【customer】到【orders】的关系。如果关系已存在，右击关系线并打开【Properties】。

　　②在【Role Name】中找到从【customer.id】迁移的外键，把角色名设为与已有列完全一致的【customer_id】。

　　③出现重名处理向导时，选择【Replace】，即用迁移的外键属性替换子表中的同名自有属性，完成向导。

　　④回到【orders】的列列表，确认原先为这条关系迁移的【id】已归入名为【customer_id】的外键列，并检查该列是否只出现一次。

　　3、确认替换后的列定义

　　选择替换后，模型中的结果是一列由关系迁移的外键。原来的独立列会与迁移列统一，因此原列的类型、可空性及相关定义都值得核对。

　　①打开【orders.customer_id】的列属性，对照替换前的记录，核对类型、长度、可空性、默认值和列注释。

　　②打开相关键和索引的属性，检查其成员是否仍包含预期的【customer_id】。

　　③若业务需要两列分别存在，在重名处理时选择【Rename】并给原有列取一个不同的名称，再核对两列各自的用途。

　　三、erwin复用外键列后怎么检查模型

　　图上只显示一个列名，还要确认关系实际引用了这列。模型已经对应现有数据库时，也要区分当前模型的建表预览与面向现有库生成的变更脚本。

　　1、检查外键两端的列映射

　　①右击关系线，打开【Properties】→【Role Name】，核对父表键【id】与子表外键【customer_id】的对应关系。

　　②如果父键由多列组成，按父键成员顺序逐项核对子表列，确认每一列都对应正确的业务字段。

　　③回到子表的键和列列表，检查【customer_id】是否按设计参与子表主键，并核对是否允许为空。

　　业务上可选的关系与必填的关系，对列可空性的要求可能不同。若同时把关系类型从非标识关系改成标识关系，还要检查子表主键的构成，因为这会影响模型中如何标识一条记录。

　　2、通过脚本预览确认外键定义

　　①切换到物理模型，从【Actions】打开【Schema】。在正向工程向导中选择需要检查的表，并在【Option Selection】中包含外键生成选项。

　　②打开【Preview】，在生成的脚本中查找【FOREIGN KEY】和【REFERENCES】，核对外键是否由【orders.customer_id】指向【customer.id】。

　　③若目标是给现有数据库补约束，再检查模型比较后生成的变更脚本，确认脚本是给已有列添加外键，还是同时包含改列、删列等操作。

　　选择替换后，删掉模型中的关系，也可能连带移除已经统一的外键列。后续拆除关系或重新建模时，先看列和索引会受到哪些影响，能避免在变更脚本里带入原本没有计划的列调整。

　　总结

　　外键角色名能让模型表达同一个父键在不同关系中承担的职责。给现有表补关系时，列名匹配可以帮助定位要复用的列，业务含义和列定义则决定能否合并。把这两点区分清楚，再核对生成的外键定义，交给同事评审时就能明确说明这条关系引用哪一列，以及数据库实际需要做什么改动。