著名作家Steve Hoberman最近出版了他的新书Data Modeling for MongoDB: Building Well-Designed and Supportable MongoDB Databases。（了解更多作者介绍和书籍内容，请前往《书摘：数据建模对业务应用至关重要》

近日，Hoberman接受了TechTarget采访，在采访中，他介绍了企业在创建数据模型时普遍面临的问题，并分享了一些数据建模的技巧，帮助构建有益而且精确的运营和BI应用数据模型，其中包括运行在MongoDB这样的NoSQL数据库上的技巧。

TechTarget：数据模型有很多，企业该如何选择适合自己的模型呢？您提到数据模型的选择要以目标受众为基础，在这一点上您能不能扩展一下，比如什么样的模型适合于什么样的受众？

Steve Hoberman:在我的新书Data Modeling for MongoDB中，一个关键的主题思想之一就是建模人员要在模型的视觉形式上灵活一些，有时需要不用传统的数据模型概念建模。如果你面对的受众是应用开发人员，也就是职位名称上带有“数据”“开发者”“数据库”等字眼的人，你完全可以使用传统的数据建模符号（比如信息工程符号）和统一的建模语言。对这些受众，我通常在数据模型的三个层面——概念、逻辑和物理层——都是用符号。

但对于业务人员，就要首先考虑目标受众对传统数据建模符号的接受程度。有的业务用户、业务分析师等比较了解传统数据建模形式也愿意去学习，但对于大多数业务用户来说，传统数据建模符号还很陌生。建模人员最好用其他符号和形式替代，比如如果受众是财务人员的话，可以采用电子表格替代模型符号，或者用图片表示概念，比如用仓库的图片代表仓库。

TechTarget:企业在创建数据模型时遇到的最大困难是什么？您有什么建议帮助企业规避或者解决这些困难？

Hoberman：最大的困难在于如何正确了解数据模型的需求。企业通常会面临这样的情况：一个工程开始时，需求很模糊，甚至没有需求。但是数据模型一定要完整准确地呈现需求。从模糊到准确对建模人员来说是一个很大的挑战。在创建模型时，需要提出很多问题，并把结果记录在模型上，所问的问题会受到企业投入的时间和人员的专业知识的限制，很多工程没有时间，也没有专家，自然提不出好的问题。数据建模其实是一个了解业务的过程，需要时间，还会面临诸多挑战。

TechTarget：建模的应用正在发生改变，比如风险纾解和逆向工程等都很受欢迎，那么建模人员的应该做出哪些改变，以适应这种变化呢？

Hoberman：在逆向工程中，我们根据当代系统运行规律组织了属性和规则，而不是完全改头换面，从新系统需求中获取数据模型。因此，思想流程和传输变量都是古今相同的，只是起点变了。在风险纾解和逆向工程中，我们的角色更像是“数据考古学家”，使用侦测技巧挖掘现存系统领域和不同领域之间关系的价值。

TechTarget：如果定义或规范之间存在冲突，那么该如何确保模型的精确性？

Hoberman：有一些方法可以实现，我简单说两个我最喜欢的方法吧。我认识一个建模人员，她自己写了很多定义，她知道这些定义都是错的，然后把这些错的定义交给业务人员改正。她发现让业务人员改正一个定义比让他们从头创建一个定义要简单的多。还有一个建模人员，他坚持开发团队首先定义一个名词，然后再命名。要命名一个概念，我们首先要知道它是什么。所以先定义，再命名。

两种方法都很有效，都能实现精确的定义。

TechTarget：关系型数据库和NoSQL数据库中建模最大的不同是什么？

Hoberman：在关系型数据库管理系统中，数据库的结构和数据模型的结构是很类似的。二者的不同主要是由于性能改进或工具的影响。但是NoSQL数据库的结构和数据模型结构就相去甚远了。

TechTarget：NoSQL数据库无模式或者精简模式的本质如何影响数据建模流程？

Hoberman：所谓无模式或者精简模式是指NoSQL数据库中，我们在添加数据的同时可以添加新领域。这样我们就可以更容易地建造原型，采用迭代的方式构建数据库，而不是补充或者重新构建数据模型。数据库完成之后，再构建逻辑和概念，供文档和支持之用。无模式的环境让自下而上（从物理层开始）的方法成为了可能

TechTarget：通过创建数据模型，企业能获得哪些利益，或者避免哪些复杂的流程呢？

Hoberman：创建数据模型的潜在利益在于数据变得可理解了，人们可以阅读数据，学习数据。有了这些精确解释数据的文档在手，企业可以获得很多切实的利益，比如节省开发和支持的费用，构建能够满足需求、运行良好的高质量系统。