业务术语表比较简单的方面是术语的物理方面，也就是数据类型定义、约束等等。这方面的信息经常被忽略，但是很容易获得。值得注意的是，根据术语的不同，物理结构可能不是必需收集的信息，可以以后在开发数据模型时再确定。即使这些信息是在以后添加的，在业务术语表中维护这些信息仍然是有意义的。可以手工添加这些信息，也可以使用市场上的自动化信息分析工具。这些工具有助于了解术语的物理性质，对于评估现有信息的质量非常有帮助。

　　3.构建术语表

　　维持术语表的完整性和规范化是很重要的。允许术语表有组织地增长可能会导致业务术语出现大量重叠，这会加剧术语方面的混乱，而消除混乱正是术语表的目标。在业务术语表中添加术语时，应该检查术语，判断它们与现有术语的重叠之处，并通过适当的调整避免术语表中出现重复或其他冲突。但是，可以作为公认术语的别名保留这些冲突。在这样做时，应该注明别名的上下文，也就是记录允许使用它的范围。这样，即使某些用户坚持采用他们的局部用法，也不会造成混乱。

　　4.检验

　　有许多现象可以表明业务术语表已经接近完整了。例如，术语开始收敛了 —— 跨新领域识别出的新术语越来越少了。第二个迹象是，所有关键的参与人员已经检验了用来构建业务术语定义的数据源的完整性，而且他们的所有术语都已经按照业务概念成功地分类了。业务定义的质量也是一个重要的指标。业务相关人员应该能够确认术语对于业务是有意义的，分类是适当的，并具有适当的上下文。

　　良好的业务术语表可以为规范化数据建模活动提供有价值的输入，提供在这些模型中创建实体和关系所需的核心定义。尽管业务术语表是规范化数据建模活动的输入，但是一定要认识到，业务术语表并不能替代规范化数据模型。这两者在详细程度、规范化程度和结构方面有显著差异。业务术语表的作用是提供清晰的业务术语。逻辑数据模型在此基础上更进一步，分析数据的详细结构，包括关系、子类型、属性和包含关系。

　　更新业务术语表

　　业务术语表并不是编写好之后就不再修改的静态文档。相反，业务术语表是动态的需要反复修改的工件。无论是文档形式的术语表，还是在 WebSphere Business Glossary 等工具中维护的术语表，都是不断修订、逐渐成熟的工件。

　　从最初的探索阶段直到以后的阶段，术语表越来越成熟，用户也越来越多地引用其中的业务术语。无论这个工件是采用文档形式，还是在一个工具中维护，它们的基本物理结构是不变的。

　　示例

　　下面的示例取自一个以开户(account-opening)过程为中心的业务术语表。根据现有定义的成熟程度不同(例如，在识别阶段的早期，定义可能还不成熟)，术语可能有完整的定义和值，也可能不完整。通过各个开发阶段，术语表会随着项目一起成熟。随着对业务术语了解的深入，应该不断更新业务术语表中的信息。

　　结束语

　　业务术语表是一个权威性的工件，它控制并定义常用的词汇、术语的语义和相关的分类法。对于数据集成和 SOA 来说，它是一个重要的起点。业务术语表可以确保组织中不同角色的业务人员和 IT 人员对术语的含义有相同的理解，并在 SOA 上下文中用术语组合成可重用的信息结构。如果弄不清楚提供什么信息以及这些信息的含义，就不可能提供可信的信息。