无论哪家公司，只要自开发的系统有一定的数量，都会有一套或简或繁的建模规范。通常，大家遵从就行了，也不去深究，但也有很多人对此不以为然。
这次正好仔细聊聊，这些为什么一些数据模型中的一些规范要求后面的原因。
本文基于ERwin和Oracle，对于其他工具可能有些叫法会有差异，自行换算。
1，模型命名不规范
ERwin的模型属性里面，有一个地方可以填写模型。假设一个系统叫IDS，那么在名称这个地方应该填写为IDS。
一般反向工程出来的，这个地方会是Model_n，n为数字。
为什么要对这个地方做规范性检查呢？不可以写成IDS_20150101、IDS V1.2这种吗？
a，用于标示系统名称
数据模型是数据库物理实现的一种“图纸”体现，好吧，简单点说，这玩意很重要，是数据架构中的一部分，会导入到企业资产平台中。而在搜索的时候，比如，按照字段名搜索，查出来的里面必然要包含系统名称、表名、字段名，这个系统名称从哪里来？
导入的时候是将ERwin里面的信息先导成excel再导入的，所以，这个模型名称是用于识别系统名称的。
所以，推荐做法，将版本信息体现在文件名中，而将在模型名称里面正确填入系统名称。
b，用于做Owner检查
数据库有schema/owner，如果表的owner设置错误这是致命的，如何进行检查？
比如，系统叫IDS，那么owner默认叫OWIDS，但模型里面有写成OWODS的。
是OW+系统名称作为owner名称，然后对表、视图等的owner进行识别。
2，没有建立主题域或主题域使用了默认名称
假设模型是房屋设计图纸，那一个主题域就相当于一个核心功能区的。
你是先看几室几厅、客厅南北朝向，还是直接研究浴缸东西朝向还是南北朝向？
如果给你一个400张表的模型，没有主题域的划分，只有一张大图，让你在2个小时内进行Review，并给出建设性意见，怎么办？
所以，模型Review中要求进行主题域的划分，是模型师体现自己对于整个系统完整理解的必要要求，同时对于模型的可阅读性、知识传递等都有着非常重大的意义。
至于使用了默认命名，举个例子，主题域名字叫PhysicalDiagram_n，n为数字，未免的太不专业了。
3，没有划分表空间
表空间这个东西很难一句话讲清楚，估计认为大家都知道这是个啥吧。
存储空间的使用应该是要有预先规划的，不设置表空间、不划分数据和索引表空间，全部使用当前schema的默认表空间，一是如果当前schema默认表空间设置不当，数据存储会将USER表空间撑爆，二是会存在性能问题。
4，表的前缀不规范
表名的前缀能很快标示出一个特定的群体，比如，TM，按照规范，表示的是主数据表。这样就有利于在我们要找主数据信息的时候更快速的定位。
就好比你加入了一个校友群，会让你改群名片 学院-年级-姓名，为啥？
表前缀同理。
5，表名术语不规范、没有备注
只有英文的甚至经过缩写后的表名，而这个英文名称识别率又不高的时候，怎么看？
比如，有人喜欢用汉语拼音做缩写，tt_jxslskc，来来来，告诉我这个是啥？你设计的时候知道，请问，后面看的人怎么知道？
TT_DLR_STK和TT_DLR_STK_HIS你感觉是否更好一点呢？通过规范的术语表可知道DLR是DEALER，STK是STOCK。
但如果HIS表没有备注，那当我想知道满足什么条件的数据进HIS？找谁问？
6，字段名不规范、没有备注
字段名不规范和表名不规范一样的，就不再赘诉了。
而对于字段备注，一个经销商类型，这个含义很广泛，国内/国外是一种，在建/营业/停业是一种，个人/集团又是一种，不在备注里面写一写，如何知识传递？要看的时候每次都到系统中去查？
暂时先写几个最常见的吧。
