新兴的NoSQL数据风格促使创新的应用程序快速发展，但NoSQL同时也带来了挑战。NoSQL系统能够快速投入生产，有时甚至根本不用创建任何的前期模式。然而，如果避开了基本的建模，对NoSQL系统输出的分析就会变得困难重重。Ted Hill认为，着手创建一个跨越SQL和NoSQL风格的建模符号时，可以更好地进行NoSQL数据建模。

作为一名在LexisNexis负责企业数据模型开发和治理的企业架构师，Hills已经努力将SQL和NoSQL的结构化和非结构化数据资产紧密结合在一起。在他名为《NoSQL和SQL数据建模》的新书中，Hills对Concept和Object Modeling Notation，以及COMN（与“common”发音相同）进行了描述，展示了如何将NoSQL与更大的建模技术相融合。

对于数据建模新符号的需求你是如何看待的？

Ted Hills：我在工作中主要使用实体关系（ER）建模，和统一建模语言（UML）来进行软件设计。我在试图建立一个元数据模型的时候发现的确很难用ER完成，因为ER的一个基本假设就是所有数据最终会置于表中。但是如果目标是一个NoSQL数据库的话，这将不再是目标所必须要具备的因素。

我发现有些东西是我无法仅仅通过对ER符号进行调整就能表现的。在物理层面上，ER无法表现的两样东西是数组和嵌套类型。在逻辑层面上，它则更为微妙。

接着我尝试了统一建模语言，然而它并不奏效。我尝试了基于事实的建模同样没有成功。这三种建模符号在基本层面上都存在问题。所以我决定通过开发自己的符号COMN来解决这些问题。如今，COMN是向其他方法开放的，因为你能够在COMN中使用ER，UML和基于事实的模型并表达它们。这是因为它涵盖了所有相同的概念，但它的涵盖性更为普遍。

有时候，是否有发觉急于追求NoSQL掩盖了对NoSQL数据建模的需求？

Hills：我们已经看到整个NoSQL世界正处于“疯狂状态”，而基于的事实是他们不必在数据开始存储之前告诉DBMS（数据库管理系统）数据模式是什么，这是很棒的。在你能够存储数据之前，你并不必花费数周或数月的时间来开发数据模型。你可以只存储数据，之后再进行建模。

但我们也看到很多人，尤其是那些只在软件开发环境中工作的人，由于过去从未从事过数据项目工作而犯下典型的错误。他们仅仅将数据扔进去，而不对其模式进行任何思考。找到之后他们的查询并未执行，导致数据丢失。

以数据模型开始的数据项目通常要比那些没有数据模型的项目要好。这在NoSQL世界依然成立。而NoSQL最大的不同在于，由于数据库并不会强迫你去做一个模型，因此开发人员很有可能就会只是将数据丢进去然后保持工作正常进行。

不过，你有说过NoSQL在某种程度上为应用程序的构建者扩展了工具箱，而且关系型DBMS有某些限制。

Hills：当然，如果你唯一的物理实现平台是一个RDBMS，那么就会有局限性。一是你会被迫在其自身的表中存储重复数据，而且无论是否具有逻辑意义你都必须给它一个关键值。但相对来说，数据的关系型模型是难以理解的，它关乎如何对数据进行思考，而不是如何存储数据。

当我们在阅读《NoSQL和SQL数据建模》这本书时，应该抱有哪些期待呢？我们为什么需要一个新的符号？

Hills：每个现有的符号都有内置假设，这使其很难考虑基本的数据问题，我认为我们必须从头开始。新模型可以让这些事情变得清晰，对关键值的决策有时是出于逻辑考虑，而有时是出于物理考量。当你必须对一个关键值做出决策的时候，要看该决策需要以逻辑模型还是物理模型来表达。在ER符号中，这通常是需要的，因为该模型不允许使用嵌套类型和数组。但有时你会因为逻辑原因而需要关键值，但其实属于逻辑模型。但没有其他的符号允许你在一个或是其他层面上使用关键值。这在COMN出现之前是不可能的。