主持人：留下来请IBM的专家刘晶炜先生给我们做一个主题发言。

刘晶炜：各位好，我想在切入正题以前，说一下刚才那个问题，满有意思的，卢总也提到了，我想今天的题目不光是讲技术，更多是围绕创新来讲，大家反思一下我们的IT，大多数DBA，从CEO角度来讲是怎么看待DBA，你是业务核心吗？能够为业务带来什么。我们大多数人，DBA的日常规律在做什么，我相信维护、备份都非常重要，但是07年全球有一个CIO的论坛，CIO对公司的作用是什么，过去把我们看成一个支撑的角色，不出问题的角色。

我自己去年，从06年下半年开始接触XML，我自己亲自拜访过两百个客户，下面把我自己的体验跟各位交流一下，我觉得这个技术不是一个支持技术，它是一个创新技术，IT能不能对业务的运作有一个价值。

第一个行业，也算是一个行业，医疗行业，医疗行业从哪进去呢？为什么这个行业需要呢？各位你去看各家医院，你们自己去医院看病提高的病例是什么形式的，有没有人想过把这个东西做成电子化的，我介入这个行业以后，过去六年国内很多医院想做电子版的，而且医改方案也出来了，从技术层面看，这里面的障碍有什么。

你们自己想想，你自己去医院做体检某种病的描述，或者同一种病不同的人也不一样，第一件事情就是如何建模，这容易吗？第二个问题，为什么有时候数据库要加字段呢，不同的人做血常规类型也是不一样的，过去这几年跑了国内的二三十家，电子病例就是医生写个word文章，所有的精确性的东西无法做到。

第二种呢，在2003年2004年叫做结构化电子病例概念，一个科室一个科室做，刚开始几十张表就能完成，后来太复杂了，而且不同医院需求不同，你做出来的东西适应性很差。我们大家搞数据搞了那么多年，我们有信心说我们是了解数据的专家吗？这是看哪个角度，我们做业务需求的时候最大的难点在哪？沟通啊，业务人员能有多大程度上的差异呢，今天设计屏障之高，已经成为很大的问题。

今天在架构层面上有没有容纳的空间，我们很多的变化是业务来导致的，而不是IT产生的。

下面我们看看做了什么， 我们搞IT的人很容易画一个流程，几个大的环节可以很好地归纳下来，但是具体的东西，开什么内容，是你自己花两个星期做调研呢，还是给他一张表格让他填，后台如果两三百张表谁看得懂，怎么进去怎么出来，出去换一种别的用法怎么办呢？大量的程序编制要完成，另外不同的客户一定会有数据内容的差别吧，比如说我是这家医院的，我有自己的需求。会不会影响到结构，影响到以后我们怎么办？这是我们最开始切入的领域，这个问题只是医疗有吗？还是因为它结构复杂，我们每个行业都在复杂性的层面逐渐地走，这一点浓缩过来，我认为今天的数据库层面上面。每个行业的数据库都是几十张表，几百张表。如果数据库发展到五十万张表以后我们的方式还是这样吗，另外我们业务的灵活性是在增长还是降低，。频率是越来越慢还是越来越快呢，第三点有没有很多业务部门说你收了那么多数我用不起来，瓶颈在哪呢？是数据不可理解，大家都很难用，只有少数的专家能用，这个是现实。

下面我们就会看到，这个过程中我自己深刻地体会到了，真正地冲击到了数据库的核心点，也就是我们今天回头思考一下，关系型数据库解决什么问题，当年奠定关系性数据库的两个巨头有一个已经过世了，去年我们把第二个请过来了，他98年决定做XDM，今天我们数据库是不是只为交易服务呢，以前交易相对是固定的。

我们如果从IT的基石来看，就像修楼房一样，最早是木头结构、接着是砖瓦结构，要盖一百层的，必须换成钢筋水泥，有了数据库已经支撑了三十年，如果再往后思考未来十年，我们的信息系统会以什么样的复杂度来扩展，你觉得这个结构还再支撑增长十倍吗？未来方向在哪里，究竟技术鸿沟和业务鸿沟越来越大还是越来越小。这一点他就带来了XML的灵活性。

在这块我只讲我们的定位，需求之初我们就思考那些东西应该用XML，这就是说我们为什么认为这是对IT大的改变，这种改变会在哪发生呢，任何一次大型的变化绝对不是今天占据领先地位的行业，所以我们回避了金融、电信业，我们转向大家可能认为很复杂的医疗业，像社保等领域，这个点上面，我们会看到既有关系型，也有XML。关系型的东西多少能够变成XML，能够带来什么价值。

技术上面来说我们从九版本出来以后，四大方面，二十多个专利搞了五年，春粗、索引、查询和处理、数据标准化这块，我们定位是到复杂的交易，性能提高了2.5倍。

下面讲几个例子，医疗记录里面，最直接的模式，现在国家都要去做了，今年北京市要求所有的每个常住人口，要为每个人简历健康档案，人出生到死亡每个信息都要建立下来，这里面会涉及到多少复杂信息。它有XML文档，一块一块切开。我们注意看一下，这里面大片的东西都是XML设计，这是它的主述信息，每个里面多个层级，以前设计的时候，是不是要把需求调研得很清楚，里边的每个关系都要浓缩成ER模型展开，今天细节的事情可以交给业务人员做，也可以容纳对这种方式的标准型管理，有很多很多的环节可以用这样的方式设计和思考。

但是对我冲击最大的还不仅仅是这种简单的改变，下面再改变一下我们如何来认识数据，这就是我刚才提到的，谁是真正了解数据的人，过去相当长的一段时间我们认为我们是，但是在这个行业里面率先碰到了瓶颈，一个大夫需要七年才能上岗，这些知识怎么可能在半年左右的需求调研中很清楚地拿出来，这是极为困难的事情，所以我碰到好几家医疗公司的技术负责人是医生转过来的，它的设计思路给我很大的冲击，首先他想到的不是见面，而是从他自己的业务知识库里面应该有什么数据，症状，症状怎么描述，部位怎么描述，这些信息能不能能够从他的思维逻辑的时候，在做任何一件事情把这些元素拼在一起，浓缩成一些复杂的组建，当我和业余流程挂挂钩的时候形成一个模板。

这里大家看一下，比如说我去调研一个需求，见面设计表怎么设计，大多数是这样的，这是一个病例的录入过程，比如说耳科，耳科里面有很多的病，比如极性支气管炎，有很多的信息，这个好像跟我们的word非常相像，医生做这个的时候，这是由大夫自己定义的，整个见面由大夫自己进行定义，这个部分包括什么原件。一般到一个医院做的时候，是一个科室的医生审核这些模板，做出来之后可以再去运用。

现在比如说西医包括中医，同时在一家医院设计出来的模板，换到另外一家医院，缩短了业务人员交流上的鸿沟，适应变化，这块我们做了简单的对比，如果我们只采用关系型的体系进行思考，我们见到的数据就是这样，如果开使用XML的方式以后，哪个更标准化一点，你的表结构设计，系统没有做出来以前是没有办法审核的，一些懂业务的专家是有机会能够参与的，能够看得懂这些信息，左侧我们是单纯的数据管理，右侧我们想到什么，这个知识沉淀下来而且不断地扩充，新项目上的时候能够以多快的速度利用原有的知识，而不是把整个的数据库表拿过去。

在查询方面，今天所有人都在用电脑，每个人都有资料库，数据库只是相对专业的资料，文件系统用什么方式解决呢？怎么样培训我们的人使用呢，XML的路径不像我们拉平了，二维的关系，需要一系列的关系，只要你数据摆在那儿，只要给他一个路径，业务人员就可以去查，我们的运用体系上面能不能够相对灵活地把供应点用好。我们以前全文检索大家都觉得非结构化的来做。

今天我们讲百度、google那种搜索，但是搬到企业上更精确，大概什么时间服过什么药，曾经出现什么症状，你是希望医生对结构了如指掌还是希望他有灵活性，我们用XML体系可以找到一个平衡点。

第二块是在政府领域里面，都会涉及表单问题，今天大部分的系统，如果表单特别多，三千六百多的税单，数据模式的多样性，弥散的数据，业务的变化，表的格式发生变化，你的底层的数据就要变化。今天我们普遍百万的是什么方法来实现的呢，这边可能后台是很多很多张表，每张表几十个字段都有可能有，我做的过程是什么呢？在界面输入出来的值，要把数据库的数据展现成表的结构给别人看的时候，每次变化给大家带来的变化是多大，大家可以体会一下。纽约税务换了个思路，既然表单是一个完整的整体，为什么要把它拆开呢，一类表单只是一类对象而已，一张表里面可能有多类，第二数据库里面适应灵活性不外乎两种方法，一个是笼统地放进去，冗余的方式，这种方式肯定会有一些大家都有的信息。

如果在数据层上面能够提供一定的灵活性，应用层能 提供灵活性呢，这边我们就跟国内一些做税务的软件厂商直接来交流了，举个例子来说今天中国的国税登记表，下面支撑的二十多张表，去年前面国家从六类登记表转变成32个登革表，现在我们不外乎就是登记信息、税种信息、变更历史。我们不需要二十张表了，只需要二十张表，在里面不同企业登记记录，如果能够做到这一点，我们再下来看一下整个软件体系里面，一个运用究竟怎么造成的，有界面、业务逻辑、数据层，我们基本上已经考虑用XML，底层很少去考虑，只是碰到问题再去改，从来没有主动考虑过，对应带来的问题就是整个架构，不光是SOA这个框架。业务一变化，这个体系就要发生变化。就要做很多的处理，如果我们能够融入XML，把一些可能会变的变成XML体系的话，我们的流程引擎做的是类似的事情，在这个层次上大家可以去考虑一下，医疗的业务应用也是做了这层，可以由业务人员自己参与设计，可以直接进行参与。

这一点我们也在不同地方尝试过补充模式，原来一张大表，很多字段，即使做得再多可能还是不够，比较简单的方法是应该保留的还是关系型的。第二种叫主从模式，第三种就是关联扩展。演化出一张关系表，如果结构一样一张关系表就够了，如果不同的关系是不同的东西呢？是不是要演化很多张表呢，出去用XML进行设计的话，首先业务人员能不能参与，在哪些层面上能够参与，以后的管理和维护、适应性能不能提高？当然在这里面还包括自循环，我们今天一个数型结构以后，不外乎编码，第二个是这个字段里面的值到另外一个字段，在同一张表里面一张张去做。

这是我们社保领域做的，每个地区都有不同的扩展，每个地区扩展由这个地区自主完成，当然你如果能够预见到，也可以来做的，但是这个我们来看它的成本，以及可维护性，除了这个以外我们在另外一个行业还发现一些很有意思的事情，就是XML带有标签，使得数据可理解，就成为一个上下文的概念，数据有上下文以后就可以被越来越多的普通业务人员使用，如果我们只是看到一个阿拉伯数字，这个数据没有什么意义，大家理解不了，但是如果我们把它存在的位置，前后背景都能够联系在一起的时候，你会对整个数据的理解是不一样的，我们来看这个点在一些行业里面起什么作用。

这个是公安行业，商务智能除了在管理上给领导做报告以外，或者海量的数据放在这儿，出来的结果是什么？是花哨的图，大量的一线人员要信息的时候不要做什么汇总，他能够看到完整的信息，今天怎么实现呢，只有自己写代码去实现，公安领域可能吗，所有每个警察破案的思路一样吗，每个人都可能不一样，人口信息、旅馆信息，坐飞机的记录，在逃人员的记录很多，最重要的是根据一把小刀的特点找到在哪个地方用过，这个人有什么网络，跟他认识的是谁，跟他同时住过一个地点的是哪些人，这里对一线员工最有价值，对公安、银行都是这样，而今天在这一点来说很难实现，你不可能利用其中的每一个需求。

今天互联网的数据比任何一个行业都多，但是大家用互联网的时候没有困难呢，为什么互联网数十亿的网页大家都访问得很方便呢，因为你看得懂，点这个网页就可以过许，那能不能今天的数据库里面，已经收集的信息，这些信息没有意义吗，它能不能够让业务人员更自主地用这个信息。这个点的内容我举个简单的例子，假设系统里面有两条记录，今天在数据库里面存成关系型，但是当它出现第三条系统的时候，警察最关心的章三是张四的驾驶证是一样的，而李四和张四的电话号码是一样的，这就意味着这三个人也许是一个人，这种联系的可能性是在哪联系的呢？这个个案是通过驾驶号来关联的，这是非常多的点，你能不能总结出来，花多大的力气能开放完，这就展现出数据可被理解和不可被理解会有多大理解。数据如果本身就是XML的话，你就只需要有一个框架，帮助业务人员自己去找链接，然后自己去完成。这一类的业务运用，我们在现实场景里面，公安领域里面，包括构建社区网络。我们希望做到的是能够把数据库里面的信息标记完了之后呢，这是一个人，这个人所关联的所有信息，这个人联到不同的人，而且这里面业务系统会产生很大的代价吗，如果要做到这一步，必须要对整体上的原数据有一个管理和运用，但是它的价值是多大呢？就相当于零售行业，以前客户到后台找一个东西。现在超市怎么做的呢，各个地方，每种类型的商品分门别类，自己走进去拿东西，数据库能不能让用户走进去拿东西呢，就是要让客户进去。

同样数据交换体系里面，这也是在去年很多领域进展比较多的，越来越多的政府部门需要做数据交换，比较方便，但是会涉及到两个方面，在这种复杂的形成下，一个通才会越来越少，一个行业的应用我可能还说我是这个行业的大佬，我拿出来的90%是准的，但是现在这种情况下必须要自主参与，而且往往在政府的这种业务过程中，要交换的数据每年在变。这个是我们跟杭州一家挺大的公司做的合作。后台通过业务复制往中心送。

在美国现在已经开始推行XML的标准，如果传统技术做的时候要分拆成不同的关系型的表，如果这些数据都能被理解的话，维度就是对数据的分类，指标、产品等是不同的维度，定义数据标准的时候，如果这个数据能够以相对原样的方式保存，这个时候维度又可以拖拽。唯一考虑的就是数据和效益的问题，如果数据量不是太大，那我是不是可以做成一个虚拟的。

今天比较难的是做出一个系统能适应不同的需求。我们看到更多的一些变化是今天IT层面上的，其实我跟银行的人都做过探讨，今天IT尤其在数据层上面产生非常多的挑战，涉及到架构层上的挑战，过去十年二十年我们是以一个固定的业务需求，固定的业务需求直接推到固定的业务逻辑，这种逻辑套过来是一个一个单独的业务系统，数据库并不重要，只是保证系统稳定运行就好了，效率不好了我加台机器，这是我们过去关注的重点，今天碰到的很大问题在哪，数据有了之后，要开始发生交互了。但是这种运用越做越多后发现数据的规划不合理，因为你这些数据应该不应该归属于你这个业务系统，开始只是在业务功能上思考这个问题，国外也是这个思路，走到一定程度发现，以前每个城市都是一个一个自己的房子建起来，建起来之后发现供暖、供电不应该由自己来管理，IT结构也是这样，在数据层上一些大的企业认识到必须提到整体平台上。

这是中国移动的IT咨询架构里面的一张图，这就是我们今天看到的核心业务里面的，ADB，但是这种模式发展到后面，在上层有非常多的交互，一个业务运用必须有很多的流程，现在最理想的是走这种模式，今天大家都在讲以客户为中心提供服务，但是客户信息分得很散。但是你在整个架构上面在不断地同步，整个架构缺失，国外很多大型的行业都逐渐认识到这个问题了，我们数据层要促进业务的发展。

业务应用里面的专有的数据还是相关的，但是共享的信息因此剥离出来独立完成，SOA必须从表层走向流程，再走向数据，一层层深入，才能真正做到业务的星火。我们希望未来的数据，银行开户这个动作，在网上可能开户、开信用卡可能开户，很多环节可以开户，但是今天开户的行为被封装在某个业务模型中，处理的逻辑、数据也不一致，这个剥离出来以后，对数据不需要人为干预的一些操作浓缩成为业务服务，来给各个功能系统服务，这块会一层层，从底层的服务，这种概念已经谈了好几年了，这种服务的时候整个的思考逻辑是一种对象化的思考，在每个层级你会看到，它的接口衔接都基本上已经开始XML，这样的大势情况下，有什么理由我们数据库组织不应该改变。这也是带来一个深层次的变化。

我们看一下今天的信息系统发展的轨迹，最早的是1884年，当时是MIT的一个教授，面临的困难是美国的人口统计局统计人口，十年一次，但是困难是十年周期还处理不完，他发明了打孔机，然后把打孔的信息放在磁带上面，最后磁盘，随机读写，这个时候才慢慢产生数据管理，数据库的概念。最早的是网状的，数据和业务逻辑没有很好地分离，1970年有了关系型的理论，77年的时候到后来交易的概念，今天从理论层面上我们看到，这条线已经支撑了将近三十年的历史，另外一条线现在大家用的互联网最早追溯的源头，当时是罗斯福总统的技术顾问，他当时并不是一个技术人员，他想的是给总统提供的资讯合不到一起，他后来想到了在非结构化层面上用到了鼠标的概念，使我们人类访问信息的方式产生了质变，我们可以按照我们的思路跳转，不断地去改变，最重要的是不在于他创造了互联网，它早就有，但是只在技术圈用，没有普通人去做网页，他最大的改变就是让大多数的普通人能够参与，使得全世界互联网的参与的人高了。

去年我们在市场上取得了一系列的突破，我看了一下你们的报告，跟我们的数据非常不一样，我们去年的业务成长了100%以上，在中国的业务，我相信这个仅仅是开始，我接到很多的业务。深刻的变革才慢慢开始。

谢谢各位！

主持人：感谢刘晶炜先生给我们带来的激情澎湃的演讲，大家有什么问题可以提出来。

提问：我从您那个表上看到，如果有一个全文检索的需求，从语句来讲怎么实现这个东西。

刘晶炜：我调一篇给你看一下。

刘晶炜：在数据的组织方式，XML的组织方式，每一种技术都有它适合的领域，也有它的极限性，我们的根本的组织数据逻辑的思路改变了，以前关系型是把同类数据放在一起，XML是把有关系的数据放在一起，你这个人相关的数据存在一块，这种方式天然来说有个缺陷，缺陷就是刚才你说到的，我也不想回避，在我做统计的时候，我的数据不像在数据仓库里面，我要拿它的时候，不需要把整个都拿出来，但是还是要点一点过去，这个是不可能做到跟传统的数据仓库的性能，这个我们跟国内的用户也探讨过，在哪个领域使用，如果是几亿条记录，而且这几亿条结构也没什么变化，你为什么要用XML呢？有变化的信息，本来联系到一起了也可以用。

提问：我想知道我在设计数据库的时候我怎么知道这个字段是放在XML里面还是外面。

刘晶炜：我们现在呢有几种情况，我接触了很多行业，他比较早地采用XML设计了，第二种政府我们做的方法是这样，原来已经有了很多设计体系，我们在做新系统的时候，去参照你的业务的属性有没有变化的可能性以及以后会怎么样去用它，我们一般来讲会把需要索引，大家关联性比较强的数据保留关系性数据库。应该来说这种设计理念和这个模式我们在全球才推出来，还在摸索的过程中，我不认为有一个特别成熟的体系。

提问：你前面说到，数据建模的建立，可以分散给各个熟悉业务的人去做，就是我们可以把任务分散开来，不是我们自己做，分散必然导致大家之间不知道别人干什么。

刘晶炜：可能是我讲得不是特别清楚，我们讲分的时候是提供了，以前的是基本所有的事情是我们做，今天我们分的时候是要看什么东西应该分出去，跟性能相关的我们应该分出去吗，索引的构建可能还是由IT完成，分的不能是更好地大家协作，数据库构建国家中需要业务人员参与的时候是对模型的构建，这个地方需求调研的时候，把这个部分的数据模型交给业务人员参与，我们真正去实现的时候不一定按照这个模式，但是作为DBA的责任是什么？是按照一个大树存呢还是两三个下树拼起来存呢。那是DBA的责任。

提问：我们以前用关系性数据库的时候，和XML的开发体系有没有改变。

刘晶炜：我认为一定会有改变的，我不是这方面的专家，以前就是把表结构设计完了交付，现在等于是表结构里面宏观的设计完成了，但是微观的设计可能分出去，不一定是完全直接采用它，那过来以后很容易理解它的需求，这个对软件的生命周期有一些微调，不会有根本的改变。

主持人：我们现在请刘晶炜先生入坐，刚才卢东明也回来了，大家有问题可以再问。

提问：你相当于业务人员把数据定义好之后，你这样会造成沟通的问题，现在我们所从事的开发，开始DBA是技术支持，不受企业的重视，我们通常也是应用推动技术，然后再返回到我刚才的所说，这个模式合适吗？

刘晶炜：我觉得你说的问题去年我拜访非常多的用户，基本上从技术人员、业务人员都提到类似的考虑，而且在现实的情况下面，从业务的需求处理，首先我们讲在需求的沟通上面，这种方式大家更容易协作，在管理层面上碰到一些新问题。

主持人：下面我们分开来讨论一下，再次感谢三位嘉宾。