2.不要了解你还不能了解的事情

　　为时过早的规范冻结

　　数据库范式中，一个真正的难题在于：它要求在你还未足够了解并有能力去确定数据的具体结构前，就去做这件事。因为它们忽视了一个生活中简单的事实：只有当用户看到他们不想看到的东西时，他们才知道其真正想要的是什么。

　　其工作原理是这样：一旦完成了数据结构的设计，任何后续修改都会引起杂乱的数据库转换，除此之外每个访问该数据库的系统也会改变。所有这些改变必须都协调好，当所有对数据库的操作都限制在单个系统时候，这种协调是很困难的，但如果有多个系统都在操作，那就更难了，尤其是：如果其中有些系统被不受你控制的参与方管理的时候。事实上，在系统开发阶段做这些更改就已经很成问题了。其后果是，数据库设计早在系统开发阶段就被冻结，然后数据分析师们再去竭力修正这些设计。

　　现在的问题是数据分析师们面临着不可能完成的工作。他们必须在用户理解这个设计(且不说赞赏这个设计实际应用如何)前就确定该设计。只有在过了很久之后——系统已经构建好之后——用户才能对该系统有所体会并对其是否满足自己的需求作出评估。如果此时发现数据结构上有任何大问题，要想修复就太晚了。

　　SOA原型法

　　你可能会问：“SOA是怎么个不同寻常呢?”说到底，难道SOA不像数据库范式那样一样需要结构化数据吗?这个问题的简单答案：不管请求数据时，被人工代理处理还是被自动化系统处理，SOA都是管用的，并且就算数据没有被最优结构化，人们还是可以解读它。比如说，用户可以判断信件是否正在被发送至另一个国家，无论信件的地址是用行一、行二、行三和行四来表示的，而信息系统需要至少“国家”来作为数据结构可识别的一部分。

　　仔细回答这个问题就包括了对SOA原型法的讨论，这种讨论包括以下几方面：

　　识别将被构建到系统中的元数据。把它放在主命名空间中，用传统方式根据其结构把数据存储到数据库管理系统(DBMS)。例如，用户信息，这个元数据可能由用户ID和用户名构成。因为这个元数据被构建到系统中，所以为了使用这些字段而把逻辑也构建到系统中是完全有可能的，比如通过用户ID检索记录并基于用户名排序和筛选记录。

　　对每一条数据库记录，把不包含在主命名空间的所有数据放到一个单独的XML字符串中，该字符串作为一个单独的字段添加到数据库记录中。对每个XML字符串，构建一个二级命名空间，开发XSD，同时添加一个单独数据项到主命名空间。对用户记录的初步实现来说，这个字符串可能包括地址行一、行二、行三和行四的元数据。用户记录本身的XSD将会包括三个字段的元数据：用户ID、用户名和以XML字符串包括的附加的用户相关数据。附加用户数据的XSD包括每条地址行的元数据。

　　使用基于XSD的逻辑来为数据库记录的各相关层次获取及展示所有数据，这可以通过给每个XML字符串(包含对主记录的字符串)增加一个标准验证服务来实现。如有可能，利用某种工具来产生使用XSD的接口而不要自己去编程。该工具必须使用二级XML字符串所包含的元数据来将其解包，并且必须同时使用主、次两级XSD的逻辑来获取新记录。其结果就是一个可运行的原型，用户可用以评估预期使用的系统。

　　要尽量适应和修改基于XSD的逻辑以及验证服务直到用户对系统满意为止。就拿用户记录来说，一个新的针对字符串的XSD可包括以下元数据：街道地址、邮编、县市、以及国家。使用旧XSD存储的数据仍会正确显示，所以无需立即将其转换。而使用新XSD将会获取新的记录。

　　一旦用户和你确信元数据已经稳定了，那么请考虑把数据迁移到传统的数据结构和主命名空间。

　　当然，SOA原型法并不总是必要的。当需求受限于如此多的不确定性时，请使用原型法，这样先做原型然后再将其稳定比较经济。但是请记住这个肯定要比数据库化原型法要简单的多。在数据库化的时代，原型法只是可有可无，但是在SOA的时代，它便是家常便饭。不要将设计细节固定，除非你确定它们是正确的;就是这么简单。