erwin当中的命名标准，应当如何去配置，以及这套标准应用之后，字段名称却仍旧不能统一，又该怎样去处理，这些是在数据库建模的过程当中，相当容易碰到的两个问题。不少团队，起初不过是希望把表名与字段名整理得稍稍整齐一些，真的动手去做的时候才会察觉，逻辑模型里的Attribute、物理模型里的Column，再加上词汇的缩写、大小写的规则，以及下划线的用法，全都互相牵扯在一起。erwin的命名标准，并不是一次简单的批量改名，而是要依靠命名规则和词汇表，把逻辑名称转换成更能满足数据库要求的物理名称。这些规则若是没有事先想明白，字段当中便很容易冒出同一个意思却有好几种写法的情况。

　　一、erwin命名标准如何配置

　　动手配置命名标准之前，需要先把逻辑名称和物理名称拆开来看。逻辑名称是给业务人员和建模人员看的，表达上可以更完整一些；物理名称则是最终要落到数据库里面的，这就需要去考虑缩写、长度、大小写、特殊字符，以及数据库平台本身的习惯。如果把这两个层面混在一起，命名标准表面上看好像已经生效，实际产生出来的效果往往并不稳定。

　　1、创建命名标准对象

　　打开【Model Explorer】之后，找到【Naming Standard】，用右键新建一个命名标准对象，再进到这个对象的属性窗口里面去配置。新建完成以后，应当去确认一下当前这套标准是不是已经被设成启用状态了。

　　erwin里面是可以同时保留多套命名标准的，假如模型实际启用的并不是刚刚才配好的这一套，那么后面新建出来的表和字段，就不会按照预期的设想进行转换。这个地方看起来不难，可是相当一部分字段不统一的问题，就是从这一步开始的。

　　2、配置逻辑命名规则

　　进到命名标准编辑窗口以后，在【Logical】页面上设置Entity、Attribute、Domain这些对象的逻辑名称，究竟是由哪些部分组成的。逻辑名称并不一定要强行去缩写，关键在于把业务的含义交代清楚。

　　像“客户编号”“订单创建时间”“产品分类代码”这一类的字段，在逻辑层可以保留比较完整的说法。往后物理名称要怎样缩写，再交给词汇表和名称映射去处理。这样做有一个好处，就是模型交到业务人员手上评审的时候，不至于只剩下一堆谁也看不明白的英文缩写。

　　3、配置物理命名与词汇表

　　切换到【Physical】和【Glossary】页面之后，去设置Table、Column等物理对象的命名规则，并且把那些常用的业务词汇、标准缩写，还有可以备选的缩写，一并维护起来。

　　比方说，Customer这个词统一缩写成cust，Amount统一缩写成amt，而Number究竟是用no还是用num，这些都需要提前定下来。同一个词，不能在这个字段里写了全称，换到另一个字段又用了缩写。词汇表越是随意，转换出来的字段名也就越是容易乱。

　　二、erwin命名标准应用后字段不统一怎么办

　　命名标准应用下去以后，字段名称还是做不到统一，这个时候先不要急着一个字段一个字段地去手动修改。手动改写，能对付眼前那么几个字段，却很可能把规则的来源搅得更乱。一个更靠得住的做法，是先去判断问题到底出在规则没有真正起效，是映射还没有执行，是词汇表本身不够完整，还是那些历史遗留的字段，压根就没有跟着规则重新生成过。

　　1、检查当前标准是否已经生效

　　沿着【Tools】→【Model Naming Options】这条路径，去检查当前模型里面的命名选项，确认一下是不是已经挂上了对应的命名标准。要是命名标准仅仅是建好了，却没有真正套用到当前模型上面去，新加进来的字段当然就不会自己变整齐。

　　还有一种情形，就是模型里面旧标准和新标准同时存在，建模的人以为自己改动的是当前规则，实际生成的时候，走的还是旧的那一套。碰上这种情况，就应当先把当前模型到底绑定了哪一套规则，弄得明明白白。

　　2、检查Name Mapping设置

　　进到跟【Name Mapping】有关的设置里面，去查看一下，逻辑名称转换成物理名称的时候，词汇表是不是已经打开了，缩写的类型、前缀后缀、特殊字符的处理，还有大小写的转换，这些选项是不是都已经配好。

　　比如说，逻辑字段叫做Customer Number，按照规则本来应当生成cust_no，模型里却同时出现了customer_no、cust_num，还有customer_number，这种情况就要重点去翻查词汇表和映射规则。也有可能是，一部分字段是从逻辑层派生下来的，另一部分字段又是用户直接在物理层敲进去的，两条路子混着走，出来的结果自然就整齐不了。

　　3、检查历史字段与手动覆盖

　　对于那些已经存在一段时间的Column字段，需要看一看它们是不是曾经被人手动修改过物理名称，或者是通过反向工程从别的数据库结构里带进来的。命名标准，通常并不会把所有的历史字段，自动整肃成统一的风格。反向工程进来的那些表结构，往往还带着原来数据库里的命名习惯；手动改动过的字段，也可能仍然保留着旧的名称。可以先把字段清单导出来，拿逻辑名称、物理名称、所属的表，还有数据类型，横向对比一遍，然后再分成一批一批地去处置那些不正常的字段。不要一边看着图，一边零零散散地改，那样做，后面是很难回头追溯的。

　　三、erwin字段命名如何保持长期一致

　　字段命名这件事，并不是改完一回就可以宣告收工的。之后再去新增模型、复制表、合并模型、做反向工程，乃至生成DDL，都有机会把那些不一致的情形重新带回来。想要让命名标准在长时间里都能管用，就需要把规则、流程，还有检查的动作，一起固定下来。

　　1、建立常用词汇与缩写清单

　　把那些经常碰到的业务词汇、标准缩写，还有不推荐的写法，整理成一份清单，例如客户、订单、金额、日期、状态、编号、类型、代码这些词，到底应该写成什么样子。这份清单，要和erwin里面的Glossary保持对应。不能文档里面维护着一套说法，模型里面又维护着另外一套。字段命名闹出毛病的时候，很多情况并不是软件不会做转换，而是团队内部对同一个词，就没有形成一个统一的叫法。

　　2、统一新增字段的入口

　　新增字段的时候，应当尽量从逻辑属性那一端开始维护，然后再借助规则去生成物理列名。如果有的同事直接在物理模型里面添加Column，有的同事从逻辑模型派生字段，还有的同事是把旧表复制过来再改几个字，那字段的风格慢慢就会散掉。建模流程里面，可以明确一条：新加入的业务字段，先把逻辑名称和定义补全，再回过头来检查物理名称是不是按照规则生成的。这样去做，字段名称、字段含义，还有数据字典相互之间，就容易对得起来了。

　　3、定期检查异常命名

　　在模型评审，或者生成DDL之前，可以把字段清单导出来，检查一下大小写、下划线、缩写、长度这些地方，看看有没有重复字段，以及同义词混用的问题。比方说，create_time、created_time，还有creation_dt同时都存在，那就要去判断一下，它们几个指的到底是不是同一类含义；如果确实是的，那就应当回到命名规则里面，把它们统一起来。字段名称，不光光是给数据库看的，它还会牵涉到SQL开发、ETL处理、报表口径，以及日后的维护。前期多花一点时间检查一遍，后面就能省下许许多多解释的工夫。

　　总结

　　erwin命名标准应当如何配置，标准应用之后字段名称仍不统一又该怎样解决，这当中很关键的一步，是要把逻辑名称、物理名称、词汇表，还有Name Mapping，分开来，一样一样去理清。配置的时候，需要创建并且启用命名标准对象，分别去设置Logical、Physical，还有Glossary；等到发现字段还是不统一的时候，就要回过头去，查一查当前标准有没有真正生效，映射规则配得对不对，以及历史字段是不是被人手动改动过。要想真的把字段命名管住，绝不能只依赖某一次批量改名，还需要把常用词汇、缩写规则、新增字段的入口，连同命名检查这一整套动作，都固定下来。只有这样，erwin里面的表名和字段名，才不会随着模型一天一天地建下去，而变得越来越乱。