医疗大数据解决方案

医疗大数据解决方案 与信息系统的耦合度为零的数据才是合格的大数据 全国97.8万家医疗机构的信息系统基本上都是用关系数据库而建立的，然而要对关系数据库中的数据进行挖掘非常困难。大数据并不是小数据之和，关系数据库系统不适合处理大数据。发明专利技术（发明申请号201310495041.8）《医学信息的结构化存贮方法》非常适合处理医疗大数据。

目 录 医疗大数据解决方案 1 第1章 概要 4 1.1 名词定义 5 第2章 医疗大数据面临的挑战 7 2.1 医疗大数据与医院信息系统之间的具有本质的差异 7 2.1.1 小问题放大万倍就会大的吓人 9 2.2 医疗大数据面临八大难题 10 2.3 国家大数据标准工程堪比“两弹一星” 14 2.4 医疗行业的信息系统顶层设计为何难产 15 2.5 大数据挖掘中的问题：大数据的关键不在于大而在于如何挖掘 16 2.5.1 我国医疗行业每年产生多少数据 16 2.5.2 挖掘关系数据库系统所产生的医疗数据非常困难 17 2.5.3 仅患者与数据的对应关系就是一个大问题 18 2.6 关系数据库理论的致命伤 19 2.6.1 关系数据库中的数据在大数据环境中为何变成无意义的数据 19 2.6.2 关系数据库系统是一种完全封闭的系统：外来数据无法入住 22 2.6.3 关系数据库中的数据与数据系统密不可分 22 2.6.4 关系数据库中的数据与数据结构密不可分 23 2.6.5 关系数据库中的数据与应用程序密不可分 23 2.6.6 关系数据库中的数据一旦脱离相应的系统就成了无意义的数据 24 2.6.7 关系数据库无法实现病历信息的结构化存贮 24 2.6.8 关系数据库中的数据都是“方言”，大数据需要的是“普通话” 24 2.7 关系数据库如何处理国家医疗大数据中数万个数据库、数千万张表 25 2.8 大数据之梦十年后成真 26 2.8.1 信息化社会由概念到比较成熟用了30多年时间 27 2.8.2 千年虫问题的启示 27 2.8.3 大数据工程远比千年虫问题复杂 28 2.8.4 五年之内（2020年前）医疗大数据只是纸上谈兵 29 2.9 必须开发新型的软件工具才能对医疗大数据进行高效挖掘 29 第3章 发明专利：医学信息的结构化存贮方法 30 3.1 在了解医学信息的结构化存贮方法时的注意事项 31 3.2 医学信息的结构化存贮方法 32 3.3 数据的完整性是大数据的根本 38 3.3.1 大数据的策略：以适当的数据冗余而使数据易识别 38 3.3.2 一个事物的数据 40 3.3.3 事物分类 40 3.3.4 关系数据库的缺陷：关系 42 3.3.5 数据的可识别性 46 3.3.6 数据的多样性 48 3.3.7 元数据及国际元数据标准非常重要 48 3.3.8 大数据的关键：让数据自己说话 49 3.3.9 大数据的策略：用数据代替程序 51 3.4 与信息系统的耦合度为零的数据才是合格的大数据 52 3.5 医学信息的结构化存贮方法与关系数据库的对比 55 3.6 应用医学信息的结构化存贮方法的注意事项 55 3.7 超大表化问题：分为多张表 56 3.8 关系数据库中的二维表是数据不具独立性的一个根本原因 56 3.9 “万能数据结构表”存放病历信息的例子 56 3.10 医学信息的结构化存贮方法实现互联互通非常简单 58 3.11 结构化录入病历信息的例子：症状的结构化 58 第4章 独立数据库在医疗大数据方面的优势 61 4.1 大数据中最重要的就是查询 61 4.2 超大表问题 61 4.2.1 自动调整表的长度 62 4.2.2 自动查询多张表 62 4.3 用独立数据库实现国家医疗大数据的存贮处理 63 4.3.1 独立数据库如何处理国家医疗大数据中数十万个数据库、数千万张表 63 4.3.2 疾病、症状的相关数据 65 第1章 概要 关系数据库理论存在很多很严重的问题，例如，用关系数据库系统所设计出的信息系统都是孤岛型系统，难以实现系统之间的互联互通；
在大数据时代，人们发现，对全国97.8万家医疗机构所产生的医疗数据进行挖掘非常困难，当前的大多数医疗信息系统都是用关系数据库系统而设计的。

用关系数据库系统所设计出的信息系统之所以难以互联互通，孤岛问题严重，根本原因在于“异构数据”。《医学信息的结构化存贮方法》中的“万能数据结构表 ”可以存贮各种各样的数据，也可说用《医学信息的结构化存贮方法》所设计出的信息系统所产生的数据都是“同构”的，不存在“异构数据”的问题。关系数据库理论先天不足，不可能解决“异构数据”问题。

医院信息系统所处理的数据只是某家医院所产生的某些特定的数据（可称作小数据）。医疗大数据所要处理的数据是全国97.8万家医疗机构所拥有的数十万个医疗信息系统所产生的数据，这些数据存贮在数千万张表中，这些系统由不同的开发商所开发，各系统的数据结构各不相同。每家医院的信息化工作都涉及几十个厂家，每个厂家的数据、标准、采集、存储都不一样。因此，即便是在一家医院，都会出现很多孤岛，整个医疗行业的信息孤岛问题更严重。各家医院信息系统的标准、接口都不同，这成为利用率低、共享难的原因之一。不仅如此，数据种类的多样化也为数据标准的制定和应用带来了挑战。

小数据的特点是数据的类型和数据都是有限的，在处理数据前能事先确定数据的类型。而大数据的数据特点是 “多样性 (Variety)”，在处理数据时很难先事先确定数据的类型，甚至不能确定数据的类型。目前关系数据库在数据处理中占据统治地位，而关系数据库在处理数据时事先要确定数据的类型，因此，在处理数据类型不能事先确定的大数据时，关系数据库就遇到了难以逾越的障碍。

医疗大数据与医院信息系统所产生的数据具有本质的差别。现有的各种信息系统所处理的数据都是小数据。目前人们只是认识到大数据重要性，大数据还只是处于概念阶段。大数据梦想将在10年后梦想成真，5年之内，难有突破性进展。

国家医疗大数据所面临的最大难题：当前的医疗信息系统不能适应医疗大数据的实际需求，需要对现有的信息系统进行彻底的改造才能适应大数据时代的潮流。然而，要彻底改造全国现的医疗信息系统，所花费的代价是非常高昂的！ 关键词：数据与系统的耦合度、万能数据结构表、独立数据库、医疗大数据、数据的独立性、数据的完整性、数据的可识别性、事物分类。

联系人：樊梦真 136 6086 7965 QQ：269779216 269779216@qq.com 1.1 名词定义 l 数据与系统的耦合度：数据与系统的耦合度越高，数据对系统的依赖程度就越高。当数据对系统的依赖程度比较高时，数据一旦脱离了原有的系统就变成了无意义的数据。大数据的数据来源于成千上万家单位的系统，因此，大数居中的数据应该是与系统的耦合度为零的数据，否则就需要很多的应用程度来解读数据，这会增加数据处理的难度、成本。

l 万能数据结构表：由发明专利技术“医学信息的结构化存贮方法”在模仿大脑记忆、联想的基础上而所提出的一种新型数据结构，可以在同一张表中存贮各种各样的数据。

l 独立数据库：由发明专利技术“医学信息的结构化存贮方法”而建立的数据库即可称为独立数据库。独立数据库与关系数据库有本质的差异。

l 数据的独立性：数据的独立性是由发明专利技术“医学信息的结构化存贮方法”所提出的概念，是指数据不信依靠数据库系统、不依靠数据结构、不依靠注释、不依靠应用程序而独立地表达出某种含义。关系数据库中的数据不具有独立性，需要借助于注释、数据结构、应用程序才能解读数据的含义。

l 数据的完整性：数据的完整生是由发明专利技术“医学信息的结构化存贮方法”所提出的概念，是指数据不信依靠数据库系统、不依靠数据结构、不依靠注释、不依靠应用程序而完整地表达出某种含义。关系数据库中的数据不具有完整性，需要借助于注释、数据结构、应用程序才能解读数据的含义。

l 数据的可识别性：在班、组这样的小环境中可以用每个人的姓名而区分出每一个人，然而在全国范围内，由于人数太多，很多姓名都有重名现象，因此仅靠姓名就不能准确无误地识别出每一个人。大数据时代以前的关系数据库中的数据只是应用于某个机构内部，因此各个数据就容易识别，然而如果把关系数据库中的数据放到大数据环境中，那么这些数据就成了不可识别的数据。在大数据时代，需要通过数据的独立性、数据的完整性而确保每一个数据都是可识别的。

l 在医疗大数据中，各个医疗数据分别由各家医疗机构所产生、拥有。

l 事物分类：事物分类是由发明专利技术“医学信息的结构化存贮方法”所提出的概念。大数据时代以前的信息系统的最终用户是通过应用程序而看到各种数据，最终用户并不直接与数据库中的数据打交道，数据库中的数据需要通过应用程序解读后最终用户才能读懂。在大数据时代，大数据中包含成千上万家机构的数据，因此，大数据中的每一个数据库是由哪家机构所产生，数据库中各表中所存贮的数据是什么等等都是非常重要的信息，只有搞清楚这些信息，才能正常解读各数据的真实含义。在“万能数据结构表”中，“信息系统的名称、数据库的名称、表名”是以“事物分类”的形式存贮在表中，其目的是让数据具体独立性、完整性，以此确保各数据在大数据中具有可识别性。

第2章 医疗大数据面临的挑战 本章内容提要：大数据并不是小数据之和，大数据与小数据有本质的差异。关系数据库只适合于处理小数据而不适合处理大数据。用关系数据库来处理大数据时会遇到很多难以克服的困难。五年之内（2020年前）大数据难以取得根本性突破，大数据之梦十年之后才能梦想成真。维基百科关于大数据的定义也明确指出当前的主流软件工具不能高效地处理大数据，要高效处理大数据必须开发新的软件工具。目前的大多数信息系统所产生的数据都存贮在关系数据库系统中。关系数据库中的数据的一大特点（或者说一大问题）就是“数据严重依赖于数据库系统及应用程序”，当关系数据库系统中的数据脱离了相应的数据库系统及应用程序后，这些数据基本上就成了难以阅读的无用数据。

2.1 医疗大数据与医院信息系统之间的具有本质的差异 如果把全国各家医院所产生的数据全部集中上传到国家医疗大数据中心，这些数据的数据量一定会非常庞大，这些数据能不能称为国家医疗大数据？ 按维基百科对大数据的定义：“大数据是指所涉及的数据量规模巨大到无法通过目前主流软件工具，在合理时间内达到获取、处理的数据。”这些数据可以称为国家医疗大数据。

维基百科的定义也明确地说明了把全国各家医院全部集中起来的“数据量规模巨大到无法通过目前主流软件工具，在合理时间内达到获取、处理”。为什么不能处理呢？ 例如，患者就医时，医生非常关心患者的病史。医生能否从国家医疗大数据中心获得患者在全国任意一家医院就医时的所有病历呢？假设全国各家医院的所有信息系统所产生的数据都已全部集中在国家医疗大数据中心，而且医生具有获得这些数据的权限。

截至2014年3月底，全国医疗卫生机构数达97.8万个，其中：医院2.5万个，基层医疗卫生机构91.8万个，专业公共卫生机构3.2万个，其他机构0.3万个。

全国按2.5万家医院计算，一家医院按4个信息系统计算，全国共有10万个医院信息系统，这些信息系统所产生的数据存贮在数千万张表中。

医疗大数据应该说是永久有用的，可用来研究人类疾病的历史变化情况。因此，国家医疗大数据应是整个国家数年内、数十年内所产生的全部数据的总和，甚至需要存贮数百年、数千年。国家医疗大数据所涉及的信息量是一般的医院信息系统的数据量的数万倍、数十万倍以上。

医生要想获得患者以往的病史数据，就必须从数据千万张表中查询患者的病史数据。了解关系数据库理论者都知道，如果说仅有表中的数据，没有相应的软件工具，那么，从数千万张表中查询数据，即使最优秀的程序员，在目前的技术条件下，一周的时间内肯定查不出来患者的所有病史数据。因为程序员在查询数据前，首先要搞清楚如下问题：
1、 这些数据分别是哪家医院所产生的？ 2、 这些数据分别是什么样的数据库系统产生的？ 3、 这些数据分别存贮在哪些表中？ 4、 各张表的结构是什么？ 5、 表中会含有大量的代码，各个代码的含义是什么？ 6、 同一数据库中会有多张表，这些表之间的关系是什么？ 7、 各张表中所存贮的是什么数据？数据的类型是什么？ 国家医疗大数据文件中含有数千万张表，一张表详细情况说明基本上要用一页复印的信息量来描述，共需数千万页复印纸才能描述清楚全部表的基本情况。

面对全国97.8万家医疗机构，2万多家有一定规模的医院，数万个医院信息系统，数千万张表，程序员在一周的时间内肯定搞不清楚上述问题。

从理论上而言，只要有数据，程序员可以查询到任何需要信息，然而由于国家医疗大数据的数据量太大，数据关系太复杂，数据结构太多、数据类型太多、不标准的数据太多，结果是太难太难。

处理小数据时并未感到关系数据库有什么不足之处，在大数据时代人们已认识到关系数据库系统不适合处理大数据。

2.1.1 小问题放大万倍就会大的吓人 国家医疗大数据并不是把全国各家医院所产生的数据全部集中在一起就可以称作是合格的医疗大数据。如果仅是把全国各家医院所产生的数据全部集中在一起，而没有处理这些数据的应用程序，那么，这些数据也没什么用处。

目前不是没有大数据，而是有很多大数据，然而人们不能高效地对这些数据进行处理。

到目前为止，还没有成功处理上万家医疗机构所产生的医疗大数据的成功案例。

大数据比小数据大多少倍？目前没有明确的定义，应该说真正的大数据要比小数据大一万倍以上，最少也应大一百倍以上。

大数据的大表现在：一是数据量大（是小数据“万倍以上”），二是数据类型多（是小数据“万倍以上”），三是所涉及到的单位多（是小数据“万倍以上”），四是所涉及到的用户多种多样（是小数据“万倍以上”），五是对数据的需求多种多样而且不确定（是小数据“万倍以上”）。

在处理大数据时，会有很多的“万倍以上”的问题。

3岁小朋友都可以数清楚自已家里有几口人，然而全国有多少人？由于人数十分庞大，全国人口普查就成了一项十分艰巨的大工程。自有人类以来，还无人能够数百之百准确地数清楚全球在某段时间内的人数。大家都认为当今的计算机技术已非常先进，然而时至今日，全球、全国的人口普查都做不到百分之百准确。我国历次人口普查都要花费大量的人力、物力。

宇宙之中有多少个星球体？谁也数不清，因为整个宇宙实在是太大了，宇宙中的星球数量实在是太多了，谁也数不清，永远也数不清。

事物的数量大到一定程度后一项非常简单的工作就会变成一项非常艰巨的大工程。

小数据所处理的数据犹如小朋友数家里的人数，大数据所处理的数据犹如全国人口普查。

大数据的特点：小数据中的小问题一旦放大万倍就会大的吓人！在大数据处理中，会遇到数量众多的小问题。

当前的绝大多数信息系统都是用关系数据库系统而建立的。在设计数据库系统时，设计人员习惯于用代码来表示各种数据，例如一些设计人员人用数字“0”来代表女性、用“1”代表男性），有的用“M”来代表男性、“F”来代表女性。全国各行各业拥有数千万个信息系统，其中的数千万张表中拥有人的性别这种字段。在当前的情况下，人们是用数据抽取的方法来而使性别这种字段中的数据全部转换为统一的、标准的数据，例如统一为“男”、“女”。要把全国数千万张表中的性别数据全部转换为统一的数据，就是一项非常艰巨的系统工程。

要真正建立起国家医疗大数据，要解决很多个数量十分庞大的小问题。

大数据一般比小数据大数万倍、数十万倍，小数据中的小问题一旦放大数万倍、数十万倍就会大的吓人！ 在小数据时代，人们所设计的信息系统只是用来处理某个机构、某个部门内部的某个局部问题进行统计、分析，一个信息系统中只有几张表、几十张表。

在大数据时代，人们更关注全国，甚至全球范围内的对所有事物进行统计、分析，涉及到数百万、数千万个信息系统、数亿张表。

小数据是为机构内部的人员所使用，是从机构的角度看问题，而大数据而是从全国，甚至全球来考虑问题。

对医疗行业而言，全国拥有近97.8万家医疗机构，数百万从业人员，为全国13亿人服务。

目前商业智能所处理的还只是一家企业内部的数据，人们已感到对企业内部的数十个信息系统中的数据进行处理已非常困难，而大数据所要处理的是整个行业的数据，比商业智能复杂数万倍。

l 大数据=价值大=困难大=问题大=代价大 2.2 医疗大数据面临八大难题 当前国内的各家医院的各种信息系统都是为了满足自己的需求而开发的，可以比较好地满足各家医院自己的各种需求，并发挥出了重要的作用。然而，当人们从国家医疗大数据的角度来考虑问题时，就会发现要从全国的所有医疗机构的所有信息系统中挖掘出有价值的信息实在是大难了！主要有下述八大难题。

1、 各自为政：各家医疗机构各自为政，都想要别人的的数据，都不希望自己的数据共享给他人。到目前为止，医疗数据都存贮在各家医疗机构内部，从各家医疗机构获得数据非常难。

2、 数据不标准：医疗行业还未建立全国统一的、标准化、规范的数据，各家医院的医疗数据各不相同。数据不标准问题是影响大数据处理的一个重大问题，在大数据时代，各行各业的数据标准化工作是大数据的一项非常重要的基础工作，这项基础工作搞不好，大数据挖掘工作不可能搞好。医疗行业的数据标准化工作也是一项工程量巨大的系统工程，需要大量的医务人员共同参与才能完成。国内还未做好这项基础工作。数据不标准、不规范，会严重影响数据挖掘的结果。【数据不一致可以有多种情况，如数据类型不一致，随意缩写造成的不一致，计量单位不一致等。当从多个不同的数据源整合数据时，由于定义的不同，更容易产生数据不一致问题。在不同的数据源中，相同类型的信息可能表现为不同的格式。例如，电话号码通常定义为字符型数据，但在有些数据源中可能将定义数值型数据，因此应将其标准化。典型的例子是字段“性别”，一些人用数字“0”、“1”、“2”来表示“不清”、“男”、“女”。而在其它数据库中，可能直接用“不清”、“男”、“女”来描述。另一种情况是字段值在不同的数据源中不一致，如“出生地”可能分别使用“上海”、“沪”、“上海市”、“沪市”、“SHANGHAI”、“SH”等表示上海市出生的人。解决这一问题首先应该进行标准化，然后根据标准逐步消除数据不一致的问题。】 3、 业务及业务流程不标准：要对全国的某个行业的大数据进行分析统一，行业内的业务及业务流程的标准化工作也是一项非常重要的工作，否则，各个机构的数据也就会百花齐放、各不相同，不利于分析统计。

4、 数据多样性(Variety)【数据结构不标准、不统一】：全国有97.8万家医疗机构，这些机构的全部信息系统有数十万个，这些系统由不同的开发商所开发，各系统的数据结构不尽相同。【每家医院的信息化工作都涉及几十个厂家，每个厂家的数据、标准、采集、存储都不一样。因此，即便是在一家医院，都会出现很多孤岛，更别说整个医疗行业了。各家医院信息系统的标准、接口都不同，这成为利用率低、共享难的原因之一。】 5、 数据与数据库系统、应用系统密切不可分：关系数据库系统中的每一个数据都要先定义数据结构才能入住数据库。信息系统的最终用户所看到的数据都需要应用程序的解读，最终用户看不懂关系数据库中的数据。

6、 不能实现医学信息的结构化存贮：医学信息非常复杂，医务人员习惯于用自然语言编写各种医学档案，例如医生都是用自然语言编写病历。然而，计算机很笨，不能理解自然语言，因此只有把医学信息结构化之后进行存贮，才能用计算机进行处理。而当前的众多医学信息都未能很好地进行结构化存贮。

7、 信息孤岛：各家医院的各个信息系统不能实现全国互联互通。

8、 老系统升级改造难题：当前的信息系统都是小数据系统，不适应大数据时代的需求，然而要对现有的信息系统进行全面改造也是非常困难的，其代价也是非常高昂的。【为什么要升级改造？因为当前的各家医院的信息系统所产生的数据各不相同，数据不标准、不规范。要对大数据进行处理，必须确保全国各家医疗机构的信息系统所产生的数据是统一的、标准的、规范的医学标准数据。只有这样，才能高效处理大数据。】 从理论上而言，医疗大数据挖掘很简单，只要懂关系数据库，基本上就能对医疗大数据进行挖掘。然而，要想对全国近百万个医疗机构、数十万个信息系统的全部数据进行高效地挖掘，所面临的挑战是非常严重的。

如何解决八大难题? 1、 各自为政：这个问题必须国家卫生和计划生育委员会以行政命令的方式来解决，强制要求各医疗单位实时地把各种医疗信息上传到国家医疗大数据中心。若没有强制的行政命令，不可能建立起合格的国家医疗大数据。

2、 数据不标准难题：此难题涉及到的数据量太大、工程量太大。国家卫计委及很多人士虽说早就注意到此问题的存在，然而直到目前还未从根本上解决医疗行业的数据标准化问题。此问题不从根本上解决，那么医疗大数据的挖掘就等于说大话。医疗行业数据标准化工作是大数据挖掘的基础工作。此问题应该由国家卫计委组织业内外力量来解决，解决此问题需要3至5年的时间。有了国家医疗大数据标准之后，还需要用标准的医疗数据去代替现有的不标准的医疗数据，而此项工作的工作量也是非常巨大的。标准化工作是不赚钱的基础性工作，商业机构没有从事这项工作的动力，应该由国家卫计委来解决。

3、 业务、业务流程不标准：目前全国各医疗机构的业务及业务流程并不标准，因此，各医疗机构所产生的数据也各不一样。要建立国家医疗大数据，就必须道先对全国医疗机构的业务流程进行标准化处理，这也是一项工程量巨大的基础性系统工程。这项工作也应该由国家卫计委来解决。此项工作最快需要三至五年的时间才能完成。

l 只有解决了上述三项基础性问题，才能够建立起国家医疗大数据这个大厦的坚实地基，否则医疗大数据只能是空中楼阁。由于上述三个因素牵涉到全国各个医疗机构的方方面面，非常复杂，十年之内很难看到真正的国家医疗大数据的曙光。

下述4个问题属于技术问题，关系数据库理论解决不了这4个问题，可由发明专利技术“医学信息的结构化存贮方法”从技术上加以彻底解决：
4、 数据多样性(Variety)【数据结构不标准、不统一】：目前关系数据库占据统治地位，绝大多数信息系统都是用关系数据库而建立的。医院的各种信息系统中，多数也是用关系数据库系统而建立。例如，目前国内医疗行业的HIS系统是由多个开发商所开发，各家开发商所用的数据库系统不一样，所用的数据结构结构及数据类型也不一样。因此，如果要对全国各家医疗机构的HIS系统中的数据进行分析，那么首先就要把各种数据全部转换为同一的数据结构，然后才能对数据进行分析统计。然而要对全国近百万个医疗机构的数十万个、数百万个信息系统中的数据进行转换，也是一项工程量巨大的系统工程。另一外很重要的问题是，所有这些信息系统中的数据要转换为哪一种统一的、标准的数据结构，也是需要国家卫计委制定相应的标准、规范。

5、 数据与数据库系统、应用系统密不可分。

6、 不能实现医学信息的结构化存贮：医学信息非常复杂，用关系数据库不能实现病历信息的结构化存贮。有人用XML实现病历信息的结构化存贮，然而XML只适合处于少量数据，不适合对全国的病历信息的处理。

7、 信息孤岛。

8、 信息系统改造：现有的医疗信息系统就犹如广州的城中村，广州的城中村虽有一定的作用，然而城中村与广州这样的国际化大都市非常不协调。改造广州城中村的最佳方案就是推倒重建，局部的修补是没用的。然而要全部推倒重建，所花费的资金是非常巨大的。

2.3 国家大数据标准工程堪比“两弹一星” 大数据工程，标准先行。

国家大数据标准的工程的工程量要比“两弹一星”的工程量大。

国家大数据标准涉及到每一个行业，也涉及到各种各样的业务。大数据标准涉及数据的标准化、数据结构的标准化、业务的标准化、业务流程的标准化。

大数据标准化工作完成之后还要对现有的信息系统进行改造，这种改造的工程量及代价也是非常高昂的。目前的信息系统所产生的数据不适应大数据的需求。

历史对秦始皇统一文字、统一度量衡、统一货币的评价非常高：功惠千秋。大数据所面临的问题也犹如秦始皇时代所面临的“文字不统一、度量衡不统一、货币不统一”问题。因此，要解决大数据所面临的问题，也需要由秦国、秦始皇那样强大的机构、领袖人物以行政命令的形式强制推行，才能从根本上解决问题。

大数据八大难题中的五大难题（各自为政、数据不标准、业务流程不标准、数据多样性(Variety)【数据结构不标准、不统一】、信息孤岛）与秦始皇曾经遇到的问题有些类似。

为解决千年虫问题，全球花费了超千亿美元的资金。彻底砸烂小数据而建立大数据新环境的代价远远超过千年虫问题。千年虫只是解决一个时间数据的问题，而彻底砸烂小数据建立大数据新环境则涉及到几乎所有信息系统的所有数据！ 小数据：只要能满足自己需求，能解决自己的问题即可。

大数据：不只是满足自己的需求、解决自己的问题，还要考虑他人的需求。重点是如何让他人能够找到所需要的数据。

要让他人、大家找到所需要的数据，最重要的是大家都要遵循相同的标准，大家都讲普通话，而不是方言，这犹如泰始皇统一六国后的“书同文”的标准化改革。

当前在处理大数据时的首要工作就是数据抽取（ETL：
“Extract”、“ Transform” 、“Load”，“抽取”、“转换”、“装载”），其实数据抽取工作也类似“秦始皇的书同文”，只是数据抽取并未能真正象秦始那样从根本上解决书同文问题。要使大数据真正做到“书同文”，需要象秦始皇那样从根本上解决问题。而真正实现大数据“书同文”时，就不再需要数据抽取。

与当前人们所提到的大数据相比，关系数据库所处理的数据则是小数据。大数据中的数据是数万家、数十万家以上的各中机构中各种数据的总和。而关系数据库所处理的小数据则是一家机构或几家机构中的部分数据。

当我们面对数十万个、数百万个以上的信息系统中的数据（大数据）时，就会发现，我们面临很多挑战：“（维基百科对大数据的定义）无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理”。也就说明用关系数据库系统已“无法在可承受的时间范围内用常规软件工具进行捕捉、管理和处理”大数据。

在小数据时代，信息系统的用户是通过应用程序而查到自己所需要的数据，而信息系统对关系数据库中的数据进行处理后而以用户能够理解的形式展现给用户。然而，在大数据时代，这种方法行不通了。因为在小数据时代，我们所要处理的数据是有限的、可确定的，而在大数据时代，我们所要处理的数据是无限的，不确定的数据。

秦始皇之所以能使“书同文”成为现实，是因为他拥有至高无上的权威；
“两弹一星”之所以能成功，关键在于“两弹一星”关系到国家的生死存亡，国家大力支持。大数据的成败与国家的支持是分不开的。

2.4 医疗行业的信息系统顶层设计为何难产 国家卫生和计划生育委员会几年前就注意到了医疗行业信息系统顶层设计的重要性，并希望从根本上解决此问题，但至今未能从根本上实现医疗行业信息系统的顶层设计。

为什么要进行顶层设计？因为当前的各种医院信息系统存在严重的问题，信息孤岛问题严重，不能互联互通。

顶层设计建立在医疗数据标准化、医疗业务流程标准化的基础之上。而如今医疗数据标准化、医疗业务流程标准化这两个基础工作还未做好，因此顶层设计就不可能有结果。

技术上的原因：关系数据库理论的先天不足。

客观原因：问题非常复杂、牵涉面太广、所需资金非常巨大。

顶层设计非常难，比顶层设计更难的是有了顶层设计之后再对全国的医疗信息系统进行全面更新换代。

2.5 大数据挖掘中的问题：大数据的关键不在于大而在于如何挖掘 如果把全国97.8万个医疗卫生机构所产生的数据全部存贮到国家医疗大数据中心，这些数据可以称作是“国家医疗大数据”，然而这样的数据并不能称作是真正合格的“国家医疗大数据”，因为，对这样的数据的挖掘非常困难，从这些数据中挖掘出有用数据的代价非常高，犹如沙里淘金，大海捞针。

大数据不是小数据之和。大数据的关键不在于大，而在于挖掘。只有可以让大家高效挖掘、任意挖掘的大数据才是真正合格的大数据。

2.5.1 我国医疗行业每年产生多少数据 国家医疗大数据的概况：截至2014年3月底，全国医疗卫生机构数达97.8万个，其中：医院2.5万个，基层医疗卫生机构91.8万个，专业公共卫生机构3.2万个，其他机构0.3万个。

仅按全国拥有2.5万家医院、每家医院4个信息系统计算，全国约有10万个以上的医院信息系统，每个信息系统按20张表估算，全国共拥有200百万张表。

除了存贮在关系数据库系统中的数据外，还有其它类型的数据：XML、音像、文本等。

国家医疗大数据的数据量估算：南京军区南京总医院目前拥有5台存储设备，2台专用于PACS，其中HIS、LIS、EMR等数据3T，病案缩微数据12T，PACS数据120T左右，每个月的数据增长为2T左右，每年产生的数据量：24T/年。国家医疗大数据的数据量估算=2.5万家（未计小医疗机构的数据）*24T/年=60万T/年。

国家医疗大数据的数据量估算：6万T/年至100万T/年。

2.5.2 挖掘关系数据库系统所产生的医疗数据非常困难 如果全国97.8万家医疗机构以镜像的方式把所有数据都上传到国家医疗大数据中心，那么该如何对这些数据进行挖掘？ 全国共有97.8万家医疗机构，这些医疗机构所拥有的信息系统有10万个以上，这些医疗机构所拥有的数据库有10万个以上，这些数据库中的表有200万张以上。这些医疗机构的数据存贮在数十万个以上的文件夹中（存贮XML、音像、文本等数据）。患者病史可能是患者自出生以来的所有情况，病史数据可能存贮在几十年的数据中，并不仅是一年的数据中。

当前的大多数医疗数据都是存贮在关系数据库中，关系数据库中的数据与数据库系统密切相关、与数据结构密切相关、与应用程序密切相关、数据不标准。如果只是以镜像的方式把全国97.8万家医疗机构的数据全部上传到国家医疗大数据中心，要从这些数据中挖掘数据，也是非常困难的。要从国家医疗大数据中查询患者病历数据，必要首先搞清楚如下情况：
l 10万个以上的数据库各用什么数据库系统？ l 10万个以上的数据库的数据存贮在哪里？IP？如何访问数据库（帐号）？ l 100万张以上的表中的每张表的数据结构 l 100万张以上的表中各表之间的关系 l 100万张以上的表中的各个数据代码的含义 l 10万个以上的文件夹中存贮什么样的数据 基础医疗数据大多存在于HIS、LIS、PACS、EMR、手术麻醉、体检、心电等多个子系统中。各系统来源于不同的生产厂商，数据存放在不同的数据库，数据多而散，数据库的设计缺乏标准化，不同数据库中的数据靠患者主索引等进行关联，关联关系相当复杂。各自厂家研发人员除了对自家系统的数据结构非常了解之外，缺乏对其他系统数据结构的了解，整体数据分析能力较差。

专业做数据分析及整合的公司，缺乏对医院实际操作流程的深入了解，导致对数据流向及关联关系的分析不够准确，且很难准确的拿到各子系统的基础数据，最终未必能做到数据全面、准确。

2.5.3 仅患者与数据的对应关系就是一个大问题 如果说要从国家医疗大数据中查询患者影像数据，那么，该如何实现？ 在当前的医疗信息系统中，关于患者的编码并不是唯一的，也不是全国统一的。

要查询某个患者的医疗数据，最理想的查询方式就是以患者的身份证号作为查询条件而查询相关数据。由于目前国内的各种医疗信息系统中的各个表中并不一定拥有患者身份证这一字段，从而使查询变得非常繁琐。

例如：下面的表中的数据是一个PACS系统中的数据。此表中并没有包含可以直接识别患者身份的数据。因为由下表中的“姓名”及“门诊及住院号”并不能准确地识别出是哪一个患者。国内同名的人非常多，仅由姓名查义患者的数据是不行的。“门诊及住院号”只是各家医院自己的编号，也不能把“门诊及住院号”作为查询条件。

在上面的PACS系统表中未包含患者身份证数据。因此，需要从HIS系统中根据患者身份证号而查出患者的“门诊或住院号”，再根据“门诊或住院号”而从PACS系统表中查出PACS影像数据。

“患者与数据的对应关系”这样的问题其实是大数据中的一个非常突出的问题。为了查询的方便，一定要把数据的最主要的特征在数据中表现出来。但关系数据库理论未考虑此问题。在大数据挖掘中，仅是确定患者的身份就是一项艰巨的工程。对小数据而言，程序员知道相关的数据存贮在哪个表中，但在大数据环境中，程序员不知道想要查询的数据存贮在哪里。

2.6 关系数据库理论的致命伤 关系数据库系统只适合于处理小数据，而不适合处理大数据，其根本原因在于关系数据库理论的先天不足。

2.6.1 关系数据库中的数据在大数据环境中为何变成无意义的数据 如果在国家医疗大数据中心查询到下表的数据，谁能看懂？ 该表中的数据是某家医院的信息系统中的关系数据库中的数据，普通人看不懂，医生也只能靠猜测才能猜出部分内容。

下面的两张表中的数据也是关系数据库中的数据，这两张表中的数据也是普通人难以看懂的：
ID XM XB NL TZ SG 1 张三 男 56 72 180 ID XM XB ZYF XYF QTFY 2146 张三 男 56 72 180 上面两表中的数据的实际含义如下：
ID 姓名 性别 所龄 体重 身高 1 张三 男 56 72 180 ID 姓名 性别 中药费 西药费 其它费用 2146 张三 男 56 72 180 下表是用发明专利技术“医学信息的结构化存贮方法”而设计的表，该表中的数据无论是谁，只要懂汉语，就可以看懂表中内容：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 100 280 事物分类 体育管理系统 2014.3.2 101 280 事物分类 教练信息 　 　 　 2014.3.2 102 280 事物分类 教练基本情况 　 　 　 2014.3.2 103 280 身份证号 XXXXXXXXXX       2014.3.2 105 280 姓名 张三 　 　 　 2014.3.2 106 280 性别 男 　 　 　 2014.3.2 107 280 年龄 56 　 　 　 2014.3.2 108 280 体重 72   KG   2014.3.2 109 280 身高 180 　 CM 　 2014.3.2 1100 1280 事物分类 病历 2014.5.3 1101 1280 事物分类 住院病历 　 　 　 2014.5.3 1102 1280 事物分类 医疗费用 　 　 　 2014.5.3 1103 1280 身份证号 XXXXXXXXXX       2014.5.3 1104 1280 住院号 XXXXXXXXXX       2014.5.3 1105 1280 姓名 张三 　 　 　 2014.5.3 1106 1280 性别 男 　 　 　 2014.5.3 1107 1280 中药费 56 　 元 　 2014.5.3 1108 1280 西药费 72   元   2014.5.3 1109 1280 其它费用 180 　 元 　 2014.5.3 相对大数据而言，关系数据库理论是小数据时代的产物，只适合处理小数据，而不适合处理大数据。

关系数据库中的数据基本上都是不合格的失真数据，因为关系数据库系统所面对的用户只是熟悉关系数据库理论的设计人员，而不是最终的用户。关系数据库的最终用户所看到的数据是设计人员利用应用程序对关系数据库中的数据进行解读之后的数据，最终用户并不是直接阅读关系数据库中的数据。最终用户也看不懂关系数据库中的数据。

关系数据库理论非常注重数据的冗余，用关系数据库所建立的信息系统所产生的数据所占用的存贮空间比较小，但关系数据库在减少数据冗余的同时也导致关系数据库中的数据只有通过应用程序的解读才能让最终用户读懂数据的含义。

关系数据理论的一个致命伤就是由设计人员随意定义数据结构（表结构），关系数据库理论中没有定义数据结构的国际标准。由此而带来的严重问题就是不同的设计者所设计出的数据结构各不相同，每一个信息系统只认识自己所定义的数据，而不认识其它信息系统所定义的数据。系统与系统之间不能互联互通，用关系数据库理论所设计出的信息系统都是孤岛型信息系统。

在小数据环境中，可由应用程序来解读数据的真实含义。然而在大数据环境中，面对数百万张以上的表，就是灾难。

数据犹如语言，数据互联互通、信息共享的基础就是大家都讲“普通话”。而用关系数据库理论所设计的每一个信息系统都有自己独特的“方言”，任何两个信息系统之间谁也听不懂对方的“方言”。关系数据库理论中根本就没有“普通话”的概念。

在小数据时代，一个信息系统只应用于一个单位，甚至只应用于某个部门，例如医院的HIS系统、PACS系统、LIS系统。

在互联网时代、大数据时代，人们逐步发现信息系统之间的互联互通、信息共享，以及处理数百万家单位的全部数据具有更大的价值。此时人们才发现原来用关系数据库理论所设计的信息系统不能互联互通，用关系数据库理论不能处理数百万家单位所产生的大数据。

关系数据库理论是单机时代时代的产物。在创立关系数据理论之初根本就没有考虑系统之间的互联互通、信息共享、大数据问题。关系数据库理论只适用于一个单位内部，不适合于处理单位之间数据互联互通。

关系数据库理论于1970年的6月由IBM公司的研究员埃德加.考特 （Edgar Frank Codd）创立【 论文名称为《大型共享数据库数据的关系模型》（A Relational Model of Data for Large Shared Data Banks）】。ORACLE诞生于1979年。

关系数据库是信息化社会的功臣，也是当今严重的信息孤岛的罪魁祸首！ 关系数据库理论是单机时代、局域网时代的产物，是一种以自我为“中心”的孤岛型理论，没有与外界进行数据交换及数据共享的概念，也没有数据接口及互联互通的概念。而当今的互联网是一种没有中心的网络，系统之间的互联互通是重中之重。用关系数据库理论所建立的信息系统都是孤岛型的，不能互联互通。

关系数据库的特点是：鸡犬之声相闻，老死不相往来。我只处理我的系统中的数据，我不处理你的系统中的数据，你也不能处理我的系统中的数据。我不管你的数据，你也别想管我的数据。我的就是我的，你的就是你的，你我之间没关系。你的数据来到我的系统中是无意义的数据，我的数据到了你的系统中也是意义的数据。我的数据只能在我的系统中生存，你的数据只能在你的系统中生存。正因如此，用关系数据库理论所设计出的信息系统全都是孤岛型信息系统。

2.6.2 关系数据库系统是一种完全封闭的系统：外来数据无法入住 关系数据库系统犹如私人住宅，只有家庭成员才能入住，外人莫入。

大数据所需要的是旅馆。旅馆向所有人开放，谁来了都可以入住，只要有房间。

关系数据库系统中并没有现成的位置供数据入住到数据库中，数据要入住关系数据库系统中，首先必须先为其定义数据结构，或者说只有已定义数据结构的数据入能入住到数据库中，而绝大多数外来数据都未经过定义，因此，外来数据都不能入住到数据库系统中。

2.6.3 关系数据库中的数据与数据系统密不可分 关系数据库有多种（ORACLE、SQLSERVER、DB2、ACCESS等等），每一种数据库都有自己的特点，各种数据库系统只能处理自己的数据，不能处理其它系统的数据，例如由ORACLE所产生的数据只能由ORACLE系统处理，SQLSERVER处理不了ORACLE所产生的数据。

关系数据库中的数据在相应的数据库系统中才是有意义的，一旦脱离了相应的数据库系统就成了无意义的数据。

2.6.4 关系数据库中的数据与数据结构密不可分 关系数据库中的每一个数据都是有数据结构的，一旦失去相应的数据结构，就成了无意义的数据。

对小数据而言，一个信息系统只有几张表、几十张表，多的也只有几百张表。而对大数据而言，例如国家医疗大数据，就会涉及到数十万个信息系统中的数百万张表。而现有的信息系统都只是小数据信息系统，只能认识自己的系统中的数据，都不认识其它系统的数据，都不能处理其它系统的数据。

对关系数据库而言，它只能处理特定的数据，所谓特定的数据就是只有事先在关系数据库定义了结构的数据关系数据库才能处理，不能处理事先未定义结构的数据。而大数据所面临的数据以不确定，或不好确定为特点，面对不确定的数据、不确定的数据结构，关系数据库无能为力。大数据的特点：大数据所面临的是无穷的数据、无穷的数据结构，这是关系数据库所不能解决的。因此，要处理大数据，必须从根本上解决大数据所涉及到的“无穷的数据、无穷的数据结构”问题。例如，真正合格的大数据处理软件工具，不但能够处理国家医疗大数据，也应该能够其它各行各业的数据。

2.6.5 关系数据库中的数据与应用程序密不可分 目前的信息系统都是通过应用程序来解读关系数据库中的数据，而每个应用程序只能解读自己的系统中的数据而无法解读其它系统中的数据。

关系数据库中的数据不具独立性、完整性，数据一旦脱离相应的数据库系统及相应的应用程序就变成了无意义的数据。例如，程序员在设计信息系统时习惯用代码来表达数据，例如有的用“1”代表男性，用“0”代表女生，而另一些人则用“M”代表男性，用“W”代表女性。在医院信息系统中，各个信息系统可由应用程序来解读各个代码，然而，在医疗大数据挖掘中，这种不规范、不标准、不统一的代码带给数据挖掘人员的将是灾难！因为医疗大数据挖掘人员所面临的是全国数万家医院的数十万个信息系统。若要对数十万个信息系统的数据中的代码进行分析、转换，将是一项工程量非常巨在的工程。因此，对大数据而言，尽量不要在数据库中采用代码。

例如下表中的“性别码”、“婚否码”：
2.6.6 关系数据库中的数据一旦脱离相应的系统就成了无意义的数据 关系数据库中的数据只有在某个特定的系统中才有意义，一旦脱离了这个系统就成了无意义的数据。正因如此。也可以认为关系数据库中所存贮的根本就不是最终用户所能读懂的数据，而是只是专业的设计人员自己才能懂的“代码”。

2.6.7 关系数据库无法实现病历信息的结构化存贮 结构化电子病历系统是医院信息系统的核心，这是国际上公认的。

关系数据库可以应用于各行各业，然而在医疗行业关系数据库遇到了巨大挑战，准确地说是束手无策，医学信息非常复杂，用关系数据库不能实现病历信息的结构化存贮。

XML虽说可以实现病历信息的结构化，然而要从全国每年所产生的几十亿份电子病历中查询信息是非常困难的，查询速度非常低。

用医学信息的结构化存贮方法可以在关系数据库中实现电子病历信息及医学知识库信息的结构化存贮，查询速度远远超过从XML电子病历中查询信息的速度。医学信息的结构化存贮方法可用于各行各业，最突出的应用则是在医疗行业。

2.6.8 关系数据库中的数据都是“方言”，大数据需要的是“普通话” 用关系数据库所设计出的每一个信息系统都有自己特定的“方言”。关系数据库理论中没有“普通话”的概念，每设计一种信息系统，就产生一种方言。系统之间谁也听不懂对方所讲的话，必须翻译才行。

医疗行业的现状：相当于每个医疗信息系统讲一种方言，各医院之间不能互联互通，甚至同一家医院内部的信息系统之间也不能互联互通。

在小数据时代，数据只是在一个单位内部使用，甚至只是在一个单位的某个部门使用。

在大数据时代，最需要的是各个机构之间、各个系统之间的数据的互联互通，数据不只是在单位内部使用，也要供单位外的人使用。

小数据系统只处理自己的数据，大数据系统要可以处理来自各种各样的小数据系统中的所有数据。

大数据最需要的就是普通话，一种可以让各个信息系统都能听懂的语言。

2.7 关系数据库如何处理国家医疗大数据中数万个数据库、数千万张表 例子：如果说全国的各家医疗机构的数据以镜像的方式全部上传到国家医疗大数据中心，那么，国家医疗大数据中就拥有10万个以上的医疗信息系统所产生的数据库，这些数据库中共含有数千万张表，该如何编写一个通用的查询患者病史的通用应用软件？ 患者病史数据有可能包含在10万个以上的数据库中的数千万张以上的表中，所有数据库、所有表中的数据都有可能涉及到。要在国家医疗大数据中查询患者的病史数据，需要查询全国数十年内所产生的国家医疗大数据。

首先需要搞清楚国家医疗大数据中的10万个以上的信息系统所产生的数据存贮在哪些数据库中，这些数据库的地址、是什么数据库系统所产生的数据，各数据库中含有哪些表，这些表（数千万张表）的数据结构是什么、这些表之间的关系。

其次是数据抽取（ETL），然而要对数十万个数据库中的数千万张表中的数据进行抽取的确是一项工程量浩大的工程。

l 为了说明问题的简单化，下面以查询PACS中的数据为例来说明问题。

查询患者的病史应该以患者的身份证号作为查询条件，而不能以患者的姓名作为查询条件，因为国内有很多同名同姓者。

如果某些医疗信息系统中未能使用患者的身份证号，那么，在大数据环境中，患者的病史数据基本上是查不到的，或者说查起来非常困难。

查询过程如下：
1、 以身份证号为查询条件而查询患者曾经在哪家医院就医。一般是从HIS系统查询患者身份证号。面对数万个HIS系统，各由不同的开发商所开发，数据结构各不相同。要搞清楚对应的数据库及对应的表，也是一项大工程。

2、 从数万个HIS系统中的数十万个表中查询是否有对应的身份证号 3、 再以身份证号从数万个HIS系统中查询出相应的住院号、门诊号 4、 以住院号、门诊号而从数万个PACS系统中查询相应PACS数据。

如果说哪家医院的信息系统的数据结构有变化，那么相关的程序都要进行修改。这就是关系数据库的先天不足。而医院的信息系统的升级改造是非常普遍的。这种升级改造对国家医疗大数据的通用查询软件工具也是一项大考验。

上述例子表明，查询任何一个病史数据都要编写大量的程序。如果对全国每年的某种疾病进行统计，那么会因为各家医疗机构的信息系统所用的疾病名不标准、不规范、不统一而带来很大的麻烦。

病历数据存贮在XML文件中。全年每年产生76亿份病历，从76亿份病因中快速地查询数据也是很困难的。

结论：处理数十万个关系数据库系统所产生的大数据是非常困难的！ 2.8 大数据之梦十年后成真 由于医疗大数据面临八大难题以及对全国各家医疗医疗机构现有的信息系统进行全面改造非常困难，国家医疗大数据之梦十年后才能成真。

大数据不仅仅是数据问题，而是非常复杂的综合问题。国家医疗大数据并不是把各家医疗机构的数据全部存贮到一个云平台就能称作是合格的国家医疗大数据。要建立合格的国家医疗大数据，需要对原有数据进行抽取，更需要对全国各家医疗机构现有的信息系统进行全面整改。

2.8.1 信息化社会由概念到比较成熟用了30多年时间 “信息化”的概念是上世纪60年代初提出的。在80年代，关于“信息社会”的较为流行的说法是“3C”社会（通讯化、计算机化和自动控制化），“3A”社会（工厂自动化、办公室自动化、家庭自动化）和“4A”社会（“3A”加农业自动化）。到了90年代，关于信息社会的说法又加上多媒体技术和信息高速公路。“信息化社会”的概念从提出到比效成熟用了30多年，而时至今日，“信化社会”之梦还没有全部成真。

大数据的概念是2012年提出的，根据以往的经验，要创造一个时代，最起码以也十年以上的时间。

2.8.2 千年虫问题的启示 计算机2000年问题，又叫做“千年虫”、“电脑千禧年千年虫问题”或“千年危机”。缩写为“Y2K”。是指在某些使用了计算机程序的智能系统（包括计算机系统、自动控制芯片等）中，由于其中的年份只使用两位十进制数来表示，因此当系统进行（或涉及到）跨世纪的日期处理运 算时（如多个日期之间的计算或比较等），就会出现错误的结果，进而引发各种各样的系统功 能紊乱甚至崩溃。因此从根本上说千年虫是一种程序处理日期上的BUG，而非病毒。

“千年虫”问题的根源始于60年代。当时计算机存储器的成本很高，如果用四位数字表示年份，就要多占用存储器空间，就会使成本增加，因此为了节省存储空间，计算机系统的编程人员采用两位数字表示年份。随着计算机技术的迅猛发展，虽然后来存储器的价格降低了，但在计算机系统中使用两位数字来表示年份的做法却由于思维上的惯性势力而被沿袭下来，年复一年，直到新世纪即将来临之际，大家才突然意识到用两位数字表示年份将无法正确辨识公元2000年及其以后的年份。1997年，信息界开始拉起了“千年虫”警钟，并很快引起了全球关注。

“千年虫”是人类不经意造成的失误，为了抓住这只“虫”，全球至少已花费2000亿美元（有的媒体报道为3000亿美元，有的为6000亿美元）。

新年伊始，联合国“国际2000年问题协调中心”、美国的“国际‘千年虫’监控中心”等机构先后宣布，133个国家的能源、通讯等十几个对“千年虫”敏感行业都顺利过渡，仅十多个国家出现一些轻微案例，但均及时纠正，未造成严重后果。

全球唯一受“千年虫”严重影响的国家只有非洲的赞比亚，其政府、金融、电力、航空、服务一片混乱。政府宣布放假3日，避免社会功能瘫痪殃及其他系统。

有人称“千年虫”工程是人类最大的信息工程、人类最庞大的抢救工程。

2.8.3 大数据工程远比千年虫问题复杂 若用当前的技术如何处理国家医疗大数据？ 首先是制订数据标准、数据结构标准，以及业务和业务流程的标准：这些工作的工程量非常大，需要五年左右的时间才能完成。目前虽说大家已认识到了标准化工作的重要性，但在实际行动上的力度还不够。

其次是数据抽取：对原有的数据进行抽取。若要对全国97.8万家医疗机构所产生的所有数据进行抽取，其工程量也是非常巨大的。这个抽取工作需要以国家医疗数据标准为基础。

第三是对现有信息系统的改造：只有对现有的信息系统进行彻底改造才能产生标准化的数据，这样才能适应大数据的需要。然而对全国各家医院的信息系统进行全面改造，所花费的代价是非常高的。到目前为止，各行各业的信息系统基本上都不标准，都不适应大数据的需求，对现有信息系统的改造的代价远远超对千年虫问题的处理。

第四是数据同步：对现有信息系统进行改造之后，数据要实时地同步到国家医疗大数据中心。

2.8.4 五年之内（2020年前）医疗大数据只是纸上谈兵 五年之内，医疗大数据还只是处于探索阶段、发展阶段。五年之后医疗大数据才能逐步变成现实。从某种方面而言，五年之内（2020年前）中国没有真正合格的国家医疗大数据。真正的合格的国家医疗大数据是可以进行高效挖掘的数据，并不是把所有的数据堆集在一起就能称为医疗大数据。不能进行高效处理、挖掘的数据只能称为“数据垃圾”，五年之后才能将“数据垃圾”变成宝。

2.9 必须开发新型的软件工具才能对医疗大数据进行高效挖掘 维基百科对大数据的定义：“大数据是指所涉及的数据量规模巨大到无法通过目前主流软件工具，在合理时间内达到获取、处理的数据。” 维基百科对大数据的定义也意味着当前的主流软件工具已不能满足时代发展的要求，需要开发新软件工具来处理大数据，也意味着当前的医疗信息系统不能适应医疗大数据的实际需求，需要对现有的信息系统进行彻底的改造才能适应大数据时代的潮流。

第3章 发明专利：医学信息的结构化存贮方法 维基百科关于大数据的定义已明确指出，目前的主流软件工具已不适合处理大数据，其言外之意就是要高效处理大数据，必须创造发明新的软件工具。

人的大脑才是最好的数据处理工具。最好的大数据的处理工具应该在模仿大脑的记忆、思维方式的基础上而开发出来的软件工具。

在大数据的4V特性中，最关键的问题就是数据类型的“多样性(Variety)”。人的大脑是如何处理数据的多样性的？对人的大脑而言，没有数据类型的概念。人的大脑通过视觉、听觉、触觉、嗅觉、味觉、痛觉等感觉器官而接收信号。对于同一感觉器官所接收的信号而言，它们的类型都是一样的。如果说大脑中的数据有数据类型，也只有六种类型（视觉型、听觉型、触觉型、嗅觉型、味觉型、痛觉型）。从某种方面而言，大脑中的数据只有一种类型，即模拟型数据。

大脑通过联想而实现对信号的处理。联想共有三种：同时联想、相似联想、接近联想。

同时联想：在同一时间内由不同的感觉器官所接收的信号同时输入大脑时，这些信号之间就可以形成联想关系。

相似联想：同一感觉器官所接收到的信号相似时就可以形成联想关系。

接近联想：在空间和时间上相互接近的事物的信号输入到大脑之中时，这些事物之间可以开成联想关系。

大脑是以“穿糖葫芦”的形式存贮信号：当人的大脑接收第一个视觉信号时，大脑是从最接近视觉的存贮区域开始存贮信号，并以“穿糖葫芦”的形式逐一存贮所接收到的视觉信号。

大脑是以六列的二维表的形式来存贮信号。

对于同一存贮区域的信号，例如视觉存贮区域的信号，大脑是以相似联想、接近联想的形式而处理信号。

对于不同存贮区载的信号，例如视觉存贮区域的信号与听觉存贮区域的信号，大脑是以同时联想的形式处理信号。

大脑以同时联想、相似联想、接近联想的方式就可以联想（犹如计算机中的查询、检索）到大脑中的所有信号。

人的大脑只用“一张表“就可以存贮所有的信号，只用识别和联想即可处理所有的信号。

医学信息的结构化存贮方法就是在模仿大脑的上述记忆、联想形式的基础上而发明出的一种新型的数据结构，这种数据结构类似大脑记忆信息的结构，所以具有非常强大的功能。

3.1 在了解医学信息的结构化存贮方法时的注意事项 医学信息的结构化存贮方法的数据结构是一种与关系数据库中的二维数据结构完全不同的一种新型数据结构。正因如此，它拥有很多优异的功能、特性，而这些功能、特性是关系数据库及XML不可能实现的。医学信息的结构化存贮方法的一个最突出的特性就是非常适合处理病历信息，可以使电子病历完全结构化，也可以很容易地解决信息孤岛问题，也非常适合大数据存贮、挖掘。然而医学信息的结构化存贮方法是关系数据库理论的异类，与关系数据库理论格格不入，医学信息的结构化存贮方法在存贮和处理数据时也与关系数据库理论完全不同。

用关系数据库理论的方法在进行大数据挖掘时会遇到很多困难，用医学信息的结构化存贮方法进行大数据挖掘时会使原来非常困难的问题变得非常简单。

对于了解关系数据库理论者而言，在阅读医学信息的结构化存贮方法的相关内容之前，需要先忘掉关系数据库理论，不要在一开始就拿关系数据库与医学信息的结构化存贮方法相比较。要想真正理解医学信息的结构化存贮方法，需要先了解它真正优于关系数据库的地方，即医学信息的结构化存贮方法非常适合处理病历信息，可以使病历信息结构化，也可以很容易地解决信息孤岛实现互联互通，而关系数据库则无法使病历信息结构化，也不能有效地解决信息孤岛问题。

学习关系数据理论基本上需要一个月的时间，“医学信息的结构化存贮方法”也是一种新型的数据库理论，因此，需要花一定的时间才能真正理解其内容，刚开始时肯定会遇到一些问题，这很正常。

金庸的小说描写到：游坦之之所以能练成易筋经是因为他原来什么武功都不会。武功非常高强的鸠摩智为什么练不成易筋经？在少林寺藏经阁中的扫地僧说“鸠摩智练了少林派的七十二绝技之后，又去强练甚么《易筋经》”，又说他“次序颠倒，大难已在旦夕之间”。说道修炼少林诸门绝技，倘若心中不存慈悲之念，戾气所钟，奇祸难测。这般修炼上乘武功而走火入魔，最是厉害不过。

学习“医学信息的结构化存贮方法”犹如修炼易筋经，不懂关系数据库理论的人反而更容易接受，而关系数据库高手、专家反而比较难接受。

金庸的小说虽说是虚假的，但也有一定的哲理。小孩子之所以容易接受新理论、新观念，就是因为他们的大脑中没有旧观念的束缚，就像一张白纸，你想在上面画什么都可以。成年人则因为在长期的生活中已形成自己的世界观，所以对新的理论、观念就会产生抗拒之心，成年人接受新理论、新观念就慢，甚至完全不能接受。例如年轻人容易受西方的那种今天花明天的钱的超前消费观念，但上年纪的人却无论如何也接受不了超前消费的观念，无论钱多钱少，总要先存一些钱。

3.2 医学信息的结构化存贮方法 医学信息的结构化存贮方法中所用的表的结构是一种新型的数据结构，这种数据结构与XML中的数据有点相似。医学信息的结构化存贮方法中所用的表简称为“万能数据结构表”。“万能数据结构表”的数据结构与关系数据库中的表的数据结构有本质的区别。要用医学信息的结构化存贮方法而开发出一种概念全新的数据库系统是非常困难的，所需的投资非常大，因此，目前可采用关系数据库系统 ORACAL 、DB2、SQL SERVER、Access等来实现医学信息的结构化存贮。

关系数据库以“横向”的N个字段存贮一个事物的信息：
ID 姓名 性别 年龄 职业 298 张三 男 56 医生 “医学信息的结构化存贮方法”以“纵向”的N（或N+X）条记录存贮一个事物的信息：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 1201 280 事物分类 人事管理系统 1202 280 事物分类 员工信息 1203 280 姓名 张三 1204 280 性别 男 1205 280 年龄 56 1206 280 职业 医生 “万能数据结构表”在SQL SERVER中的结构形式：
列名 数据类型 Id bigint 事物代号 bigint 事物特征 nvarchar 事物特征值 nvarchar 超长特征值 ntext 单位 nvarchar 附件 image 时间 datatime “万能数据结构表”存贮数据的例子：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 28 事物分类 住院病历 28 事物分类 患者基本情况 28 病案号 19910819-2-215 28 身份证号 XXXXXXXXXXXXX 28 姓名 徐XX 28 工作单位 石化总厂 28 职务 机械工 28 地址 上海市南京路 28 年龄 43 28 入院日期 1991-8-19 28 婚否 已婚 28 病史采取日期 1991-8-19 28 籍贯 浙江省宁波市 28 病史记录日期 1991-8-19 28 民族 汉 28 病情陈述者 患者本人 29 事物分类 住院病历 29 事物分类 现病历 29 事物分类 症状 29 病案号 19910819-2-215 29 身份证号 XXXXXXXXXXXXX 29 症状 寒战 29 症状 腹泻 29 诱因 洗澡时着凉 29 症状开始时间 1991-8-16 32 病案号 19910819-2-215 32 身份证号 XXXXXXXXXXXXX 32 事物分类 住院病历 32 事物分类 现病历 32 事物分类 症状详情 32 症状 腹泻 32 开始时间 1991-8-16晚间 32 次数 3 次 32 粪便情况 水样便 502 病案号 19910626-2-218 502 身份证号 XXXXXXXXXXXX 502 事物分类 住院病历 502 事物分类 出院记录 502 事物分类 症状详情 502 症状 乳房肿块 502 肿块部位 左乳 502 肿块大小 5X4X4 CM 502 肿块硬度 质硬 502 肿块特点 不光滑 502 肿块特点 界限不清 502 肿块特点 活动欠佳 502 肿块特点 无触痛 502 肿块特点 与皮肤粘连 502 肿块特点 表面皮肤呈轻度“桔皮样”改变 医学信息的结构化存贮方法的规定：
1、 数据结构必须统一，不能作任何改变。这是确保信息系统互联互通的基础。

2、 同一事物拥有一个唯一的事物代号。不同的事物不能拥有相同的事物代号。不同的事物代号代表不同的事物。

3、 数据的独立性、数据的完整性、数据的可识别性：医学信息的结构化存贮方法要求数据与数据库系统及相应的应用程序的耦合度为零。要实现数据与数据库系统及相应的应用程序的耦合度为零，就必须完全让数据自己表达出应有的含义。这是实现互联互通的最重要的基础。

在关系数据库中实现医学信息的结构化存贮方法时，只要用“id、事物代号、事物特征、事物特征值、超长特征值、单位、附件、时间”8个字段的表就可以存贮各种各样的数据，对“事物代号、事物特征、事物特征值”字段建立索引以便查询；
当关系数据库中的数据转换到“万能数据结构表”中时，医学信息的结构化存贮方法把关系数据库表中的一条记录当作一个事物，并为该事物分配一个唯一的事物代号，关系数据库表的字段名转换为医学信息的结构化存贮方法所用的表中的“事物特征”，相应字段中的数据则转换为“事物特征值”，超过“事物特征值”字段长度的数据则存放在“超长特征值”字段中，图片、附件等信息量比较大的信息、不适合转换为字符型数据的数据则存放在“附件”字段中。

“万能数据结构表”中各字段的含义：
1. “id”为每个记录的ID。

2. “事物代号”为各事物的代号，每个事物拥有唯一的“事物代号”。关系数据库中的一个完整的数据是记录，“医学信息的结构化存贮方法”中一个完整的数据是“事物”，一个“事物”的信息由若干条拥有相同“事物代号”的记录组成。

3. “事物特征”的含义为事物的特征。

4. “事物特征值”的含义为事物的特征值。

5. “超长特征值”的含义也是事物特征值，用来存放超过“事物特征值”字段的长度的字符型数据。

6. “单位”字段代表事物特征值的单位（次、米、吨等）。

7. “附件”字段：用来存放图象、附件等信息量比较大的、不适合转换为字符型数据的数据。

8. “时间”字段：该字段为每一个事物的特征写入数据库时的时间，一般可由系统自动可生成。

关系数据库是以“横向”的一个记录中的N个字段来存贮一个事物的信息，在建立信息系统时，一般情况下，关系数据库都要用多个结构不同的表才能建立信息系统。医学信息的结构化存贮方法则是以“纵向”的N个记录，或（N+X）个记录存贮一个事物的信息，医学信息的结构化存贮方法只要一张“万能数据结构表”或若干张结构完全一样的“万能数据结构表”就可以建立各种信息系统。

概括而言，医学信息的结构化存贮方法是以纵向的方式存贮数据，关系数据库是以横向的方式存贮数据，这是医学信息的结构化存贮方法与关系数据库的最根本的不同。以纵向方式存贮数据使医学信息的结构化存贮方法拥有很多关系数据库所不具备的功能、特性。医学信息的结构化存贮方法的显著特点就是其表结构是统一的、标准的、通用的、万能的，可以存贮各种各样的数据；
用医学信息的结构化存贮方法所建立的信息系统的数据源都是相同的，不存在异构数据问题；
可以对复杂的医学信息进行结构化存贮。XML虽说也是以纵向的方式存贮数据，由于XML是以文本的形式存贮数据，当对数百万个、数据千万个XML文件进行查询处理时，查询处理数据的性能非常低。

若把关系数据库表中的一个记录内的N个字段中的数据转换到“万能数据结构表”中时，则转换为“万能数据结构表”中的“N个记录”；
若把关系数据库名及表名也转换到“万能数据结构表”中，则转换为“万能数据结构表”中的“N+2”个记录。“万能数据结构表”可以存贮任何关系数据库中所有表的各种信息。把关系数据库表中的一个记录中N个字段中的数据转换为“万能数据结构表”中的“N个记录”时，这“N个记录”组成一个事物，每一个事物拥有同一个事物代号，不同的事物拥有不同的事物代号，不同事物不能拥有相同的事物代号，拥有相同事物代号的记录则为同一事物的数据。

凡是用关系数据库所能实现的信息系统，医学信息的结构化存贮方法都能实现。而医学信息的结构化存贮方法所能实现的信息系统，用关系数据库系统的方法就不一定能实现，用医学信息的结构化存贮方法可以很容易地实现电子病历信息的结构化存贮，而用关系数据库的方法就不能实现电子病历信息的结构化存贮。

医学信息的结构化存贮方法可以很容易地实现医学信息的结构化，用医学信息的结构化存贮方法所建立的电子病历系统和医学知识库的存贮效果及查询速度都远远高于用关系数据库或用XML所建立的电子病历系统和医学知识库。

人们之所以要用计算机处理病历信息，一个重要的原因是因为全国的病历信息的数量十分庞大，人工已无法处理。计算机处理病历信息的比较高的目标是：可以对全国数十亿份以上的庞大数量的电子病历信息进行处理，而且查询、处理速度快。2014年全国诊疗量为78亿人次，若全用电子病历，全国每年产生78亿份电子病历。

当前的问题是病历信息十分复杂，人们用自然语言书写病历，而计算机不懂自然语言，只懂结构化的信息。目前绝大多数信息系统都是用关系数据库建立的，然而人们在实践中认识到，传统的关系数据库方法不适合用来处理病历信息。

一张“万能数据结构表”就可以存放各种关系数据库中的任意数据，为了提高系统性能等原因，可用多张“万能数据结构表”来存贮数据，但这些表的结构一定要完全相同，这样可确保各信息系统之间的互联互通和信息共享，在建立不同信息系统时也要采用结构完全相同的表。“万能数据结构表”是一种通用的、万能的表。用关系数据库系统之所以造成严重的信息孤岛问题，其根本原因就是要用不同结构的表来建立信息系统。

若把N个事物存贮到“万能数据结构表”中，这N个事物各自拥有一个各不相同的、唯一的事物代号，不同事物不能拥有相同的事物代号，拥有相同事物代号的记录则为同一事物的数据。关系数据库用一个记录来存贮一个事物的信息，同一个记录中的信息就是某个事物的信息，而医学信息的结构化存贮方法则是用若干条拥有同一个事物代号的记录来存贮一个事物的信息。在关系数据库中，同一类事物的信息存贮到一张表中，这些事物拥有相同的字段。医学信息的结构化存贮方法不要求同一类事物都要拥有相同的“字段”，此处的“字段”的含义为事物的特征。

用医学信息的结构化存贮方法所建立的各种信息系统的数据源都是相同的不存在异构数据源问题，可用医学信息的结构化存贮方法开发出通用的数据接口，医学信息的结构化存贮方法作为通用数据接口的应用可以接收和发送各种各样的数据并有效的地解决信息孤岛问题。这是因为“万能数据结构表”是一种通用的、万能的表，“万能数据结构表”可以存贮各种从关系数据系统所发过来的任意数据。当前的信息系统在实现不同的数据交换时，一般要开发出不同的数据交换接口，而用医学信息的结构化存贮方法所建立的信息系统中只要一个通用的接口就可以接收各种各样的数据，只要把所接收的数据转换为 “万能数据结构表”的格式进行存贮即可。

3.3 数据的完整性是大数据的根本 大数据与小数据具有本质的差异。关系数据库中的数据都是小数据，小数据一般都是某个单位内部所产生的信息，其用户也是单位内部的。大数据则是成千上万个单位所产生的数据，其用户也是来自五湖四海的。小数据中的数据一旦脱离了原来的小环境而到了大数据的大环境中就成了不可识别的数据，为了解决数据的可识别性（数据的可识别性是指可让各个数据都是大家都能理解的、可识别的特性），需要特别注重数据的独立性、数据的完整性。

3.3.1 大数据的策略：以适当的数据冗余而使数据易识别 关系数据库的一个策略是：尽量减少数据冗余。关系数据库在降低了数据冗余的同时却增加了阅读数据的难度。

大数据的策略与关系数据库正好相反。大数据的策略是以适当的冗余而使数据具有独立性、完整性、可识别性，从而使数据可以让每一个人都能读懂。

“数据的独立性、数据的完整性”是指数据可以不依靠其它注释、解释、翻译、加工处理而独立地、准确地、完整地表达出某种完整的含义。

“数据的可识别性”是指数据容易阅读理解、容易识别。

对大数据而言数据的独立性、数据的完整性是非常重要的。“数据的独立性、数据的完整性”是数据的“普通话”。

用关系数据库所建立的信息系统之所以会产生严重的信息孤岛问题，一个重要原因在于关系数据库中的数据是不完整的、不独立的、难以识别的。

关系数据库是用各种“关系”来表达各种事物间的关系。正如关系数据库名中的“关系”的含义：关系数据库中的数据与关系数据库系统、表结构以及相应的应用程序密不可分，一旦分开，关系数据库中的数据将会变成无意义的数据，正是这种“关系”导致关系数据库必然产生“信息孤岛”。

关系数据库中的数据：
ID 姓名 性别 年龄 体重 身高 1 张三 男 56 72 180 上面的数据去掉结构后就会失真：
1 张三 男 56 72 180 关系数据库中的数据：
ID 姓名 性别 中药费 西药费 其它费用 2146 张三 男 56 72 180 去掉结构后就会失真：
2146 张三 男 56 72 180 “万能数据结构表”中的数据与数据库系统、表结构及应用程序无关，可以完全脱离数据库系统、表结构及应用程序而独立地存在，这是医学信息的结构化存贮方法非常突出的特点。下表是“万能数据结构表”存贮信息的例子：
下面的数据即使脱离表结构也能表达出原来的含义：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 100 280 事物分类 病历 2014.3.2 101 280 事物分类 住院病历 　 　 　 2014.3.2 102 280 事物分类 患者基本情况 　 　 　 2014.3.2 103 280 身份证号 XXXXXXXXXX       2014.3.2 104 280 住院号 XXXXXXXXXX       2014.3.2 105 280 姓名 张三 　 　 　 2014.3.2 106 280 性别 男 　 　 　 2014.3.2 107 280 年龄 56 　 　 　 2014.3.2 108 280 体重 72   KG   2014.3.2 109 280 身高 180 　 CM 　 2014.3.2 上表中的数据去掉结构后也不失真：
280 事物分类 病历 2014.3.2 280 事物分类 住院病历 　 　 　 2014.3.2 280 事物分类 患者基本情况 　 　 　 2014.3.2 280 身份证号 XXXXXXXXXX       2014.3.2 280 住院号 XXXXXXXXXX       2014.3.2 280 姓名 张三 　 　 　 2014.3.2 280 性别 男 　 　 　 2014.3.2 280 年龄 56 　 　 　 2014.3.2 280 体重 72   KG   2014.3.2 280 身高 180 　 CM 　 2014.3.2 下面的数据即使脱离表结构也能表达出原来的含义：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 1100 1280 事物分类 病历 2014.5.3 1101 1280 事物分类 住院病历 　 　 　 2014.5.3 1102 1280 事物分类 医疗费用 　 　 　 2014.5.3 1103 1280 身份证号 XXXXXXXXXX       2014.5.3 1104 1280 住院号 XXXXXXXXXX       2014.5.3 1105 1280 姓名 张三 　 　 　 2014.5.3 1106 1280 性别 男 　 　 　 2014.5.3 1107 1280 中药费 56 　 元 　 2014.5.3 1108 1280 西药费 72   元   2014.5.3 1109 1280 其它费用 180 　 元 　 2014.5.3 上表中的数据取掉结构后也不失真：
1280 事物分类 病历 2014.5.3 1280 事物分类 住院病历 　 　 　 2014.5.3 1280 事物分类 医疗费用 　 　 　 2014.5.3 1280 身份证号 XXXXXXXXXX       2014.5.3 1280 住院号 XXXXXXXXXX       2014.5.3 1280 姓名 张三 　 　 　 2014.5.3 1280 性别 男 　 　 　 2014.5.3 1280 中药费 56 　 元 　 2014.5.3 1280 西药费 72   元   2014.5.3 1280 其它费用 180 　 元 　 2014.5.3 3.3.2 一个事物的数据 在关系数据库中一个事物的信息用一条记录来表示。

在“万能数据结构表”中“一个事物的数据”用很多条记录来表示。拥有相同的“事物代号”的记录都是同“一个事物的数据”。

3.3.3 事物分类 当前的大多数信息系统都是用关系数据库而设计的，系统的最终用户所看到的数据是经过应用程序“翻译”之后的数据。关系数据库中的数据只有数据库的设计者才能看懂，信息系统的最终用户、普通用户看不懂。

其实信息系统的名称、数据库的名称、表名都是非常重要的数据，都具有重要含义。关系数据库系统的设计人员习惯于用代码、英文缩写、汉语拼音缩写作为数据库名、表名。这就导致普通用户看不懂关系数据库中的数据。关系数据库忽视了这种信息，因为它所处理的是小数据，缺省之后人们还可以理解。在大数据环境中，这些信息就是非常重要的，不能缺省。

在独立数据库中，为了使数据具有独立性、完整性、可识别性，在每个数据中都增加了“信息系统的名称、数据库的名称、表名”，“信息系统的名称、数据库的名称、表名”实际上是事物的“分类”，或者说是事物的属性、特征。这种做法是关系数据高手所难以理解的、不可思议的，因为这种做法增加了大量的数据冗余。

独立数据库在“数据冗余”与“数据的独立性、数据的完整性、数据的可识别性、数据与系统的耦合度”之间选择后者。其目的是让不懂技术的普通人也能看懂数据的真实含义。

关系数据库的数据冗余非常少，但其代价是，不懂技术的普通人看不懂关系数据库中的数据，关系数据库中的数据只能存贮在相应的数据库，一旦脱离了相应的数据库就变成了无意义的数据。关系数据库中的数据需要通过大量的应用程序的翻译才能让普通用户读懂。

对大数据而言每个数据都必须满足如下条件才能让各种上各样的用户都能看懂数据的真实含义：
然后是该数据属于哪个信息系统【例如：电子病历系统，关系数据库中根本不考虑此问题】 第三是：“表名”【例如：患者基本情况】【在关系数据库中基本上是以英文字母来表达，而不是准确的、标准的自然语言。】 在大数据环境中，系统名（例如电子病历系统、PACS系统）、数据库名、表名都是非常有用的数据，而在关系数据库中，这些数据都“缺省”了，或者是用代码来表达。

关系数据库一般是通过应用程序而使用户看到相应的信息，而对大数据而言，这种方法就行不通，因为大数据要面对数十万个数据库，若每一个数据都要用程序来解读，那么就需要编写规模非常庞大的程序。

在关系数据库中，同一类数据放在同一个数据库中、同一张表中。例如有关药物过敏的数据都放在同一张表中，以此来表明这些数据都是同一类数据。

在独立数据库中，是不是同一类数据，则是由“事物特征”和“事物特征值”而确定的，具有相同的“事物特征”和“事物特征值”的事物就是同一类事物。即使数据在数百万个信息系统中，只要具有同的“事物特征”和“事物特征值”的事物就是同一类事物。数据的分类完全是由事物本身的特征及特征值确定的，与数据库系统无关，与应用程序无关，与数据结构无关。

在独立数据库中，“信息系统的名称、数据库名称、表名”都是事物的特征、事物的分类。例如，下面的的表中数据为广州动物园的动物管理系统中动物档案表中的数据。信息系统名称“动物管理系统”则为“事物分类”，“动物档案表”也为“事物分类”。经过如此处理之后，下表中的数据无论在哪个环境中，只要懂汉语，都能看懂下表中的数据含义，不需要再编写程序而对数据进行解读。

ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 101 CHGDGZDWYQE0003 事物分类 动物管理系统 　 　 　 　 102 CHGDGZDWYQE0003 事物分类 企鹅 　 　 　 　 103 CHGDGZDWYQE0003 事物分类 帝企鹅 　 　 　 　 104 CHGDGZDWYQE0003 事物分类 动物档案 　 　 　 　 105 CHGDGZDWYQE0003 动物编号 GZQE0003 　 　 　 　 106 CHGDGZDWYQE0003 名字 汉武帝 　 　 　 　 107 CHGDGZDWYQE0003 购入日期 2013-3-21 　 　 　 108 CHGDGZDWYQE0003 身高 1.2 　 　m 　 　 109 CHGDGZDWYQE0003 体重 20 　 　kg 　 　 110 CHGDGZDWYQE0003 出生日期 2011-4-2 　 　 　 　 111 CHGDGZDWYQE0003 照片 　 　 　JPG 　 112 CHGDGZDWYQE0003 笼舍编号 098 　 　 　 　 113 CHGDGZDWYQE0003 管理员 张三 　 　 　 　 114 CHGDGZDWYQE0003 父 GZQE0001 　 　 　 　 115 CHGDGZDWYQE0003 母 GZQE0002 　 　 　 　 　 　 　 　 3.3.4 关系数据库的缺陷：关系 下面的表为“订单”管理系统中的两张表，“订单表”与“订单明细表”通过“订单ID”而发生联系。

对小数据而言，人可以通过推测而猜到两张表之间的关系。在大数据环境中，要处理数百万张以上结构各不相同的表，那么由于表的数量太多，类似上述的“订单表”与“订单明细表”通过“订单ID”而发生联系的这种情况就会造成灾难，要搞清楚各张表之间的关系所要花费的精力是非常巨大的。因为这需要由人工而确定数百万张表的各表之间、各数据之间的关系，而不能让计算机自己发现这种关系。

独立数据库是让各个数据自己通过数据的“事物特征”及“事物特征值”而自动建立关系，而不是人为地让数据产生关系。

下面将要描述的是如何用独立数据库的方法让各个数据自己自动地建立关系。

ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 101 21228 事物分类 产品销售系统 　 　 　 　 102 21228 事物分类 销售订单表 　 　 　 　 103 21228 订单ID 10248 　 　 　 　 104 21228 客户名称 山泰企业 　 　 　 　 105 21228 销售负责人 赵军 　 　 　 　 106 21228 订购日期 1996-7-4 　 　 　 　 107 21228 到货日期 1996-8-1 　 　 　 108 21228 发货日期 1996-7-16 　 　 　 109 21228 运货商 联邦货运 　 　 　 110 21228 运货费 32.38 　 　元 　 　 111 21228 货主名称 余小姐 　 　 　 　 112 21228 货主地址 光明北路124号 　 　 　 　 232 29813 事物分类 产品销售系统 233 29813 事物分类 销售订单明细表 234 29813 订单ID 10248 235 29813 产品名称 猪肉 237 29813 单位 14 元 238 29813 数量 12 Kg 239 29813 折扣 0 % 3216 32167 事物分类 产品销售系统 3217 32167 事物分类 销售订单明细表 3220 32167 订单ID 10248 3221 32167 产品名称 糙米 3222 32167 单价 9 元 3223 32167 数量 10 吨 3224 32167 折扣 0 % 9874 56789 事物分类 产品销售系统 9875 56789 事物分类 销售订单明细表 9876 56789 订单ID 10248 9877 56789 产品名称 酸奶酪 9878 56789 单价 34 元 9879 56789 数量 12 瓶 在下面的PACS系统表中只有门诊或住院号，没有患者身份证号，在大数据环境中，门诊或住院号是没有意义的，因为各家医院只是根据自己的情况而编写门诊或住院号，要在大数据环境中查询某个患者的PACS数据，就不能通过患者的门诊或住院号而查，只能通过患者的身份证号才能查到。针对下表的这种情况，就需要先从HIS系统中的患者基本信息表中查出患者的身份证号，然后再根据身份证号而查出门诊或住院号，再根据门诊或住院号而从PACS系统表中查出相应的PACS数据。这也是典型的“关系”，这种“关系”为大数据处理增加了很多麻烦。关系数据库的“关系”是大数据处理的麻烦制造者。

独立数据库的一项非常重要的任务就是坚决铲除关系数据库的各种“关系”，让数据自己独立地、完整地表达出其应有的含义，而不是靠复杂的关系来表达数据的含义。独立数据库在处理上面的PACS数据时，让每一个数据中都含有患者的身份证号。

独立数据库的一个原则、大数据的一个原则：让数据自己说话。不依靠任何数据库系统，不依靠任何数据结构，不依靠任可数据类型，不依靠任何应用程序，不依靠任何人为的关系。如果说数据之间有关系，则让数据本身的特征及特征值自己决定，让数据自己说话。因为数据一旦与数据库系统有关系、与数据结构有关系、与其它表有关系、与应用程序有关系，那么，这个数据就与系统具有高度的耦合度，这样的数据不能脱离这些关系而独立地、完整地表达出完整的含义。

为了与关系数据库进行区分，用“医学信息的结构化存贮方法”所设计出的数据库系统称为“独立数据库”。“独立数据库”的核心就是强调数据的独立性、数据的完整性、数据的可识别性，彻底根除数据之间由人为原因而建立的各种“关系”，让数据本身的特征及特征值而自动发生“关系”，或者说独立数据库中数据都能独立地表达出完整的含义。

上面的关系数据库系统中的“订单表”及“订单明细表”之间的关系是人为建立起来的。在独立数据库中，任何两张表之间是没有“关系”的，数据之间是否有“关系”不是由表之间的关系来确定，是由数据本身“事物特征”和“事物特征值”是否相同来决定，即数据之间是否有关系完全是由数据本身而决定的，而不是由表与表之间的关系来决定的。

关系数据库的“关系”：数据与数据库系统（ORACLE、SQLSERVER、DB2等）具有密不可分的关系，数据与表结构具有密不分的关系，数据与应用程序具有密不可分的关系，数据与数据库中的众多表之间具有密不可分的关系。这些“关系”在小数据环境中具有优越性，然而在大数据环境中，这些“关系”为大数据处理制造了很多麻烦！正是由于关系数据的“关系”而导致关系数据库中的“数据”只能在某个特定的环境中才是有意义的，一旦脱离了这个环境，数据就是无意义的。大数据中的数据都是脱离了相应的“小环境”的数据。

利用关系数据库系统所设计出的信息系统之所以都是孤岛型信息系统，系统之间不能互联互通，其根本原因就在于关系数据库的“关系”，因为关系数据库系统中的数据都靠特定的“关系”才具有意义，数据一旦脱离了原来的特定的小环境，就成了无意义的数据。

由发明专利技术《医学信息的结构化存贮方法》而建立的数据库之所以称作是“独立数据库”，就是为了与关系数据库有所区分，关系数据库强调的是“关系”，而“独立数据库”所强调的则是坚决铲除“关系”，让各个数据自己独立地、完整地表达出自己的含义。

关系数据库的“关系”是大数据的麻烦制造者。

3.3.5 数据的可识别性 下表中的数据为住院病历中的患者基本情况数据：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 101 1001 事物分类 病历 　 　 　 　 102 1001 事物分类 住院病历 　 　 　 　 103 1001 事物分类 入院病历 　 　 　 　 104 1001 事物分类 患者基本情况 　 　 　 　 105 1001 患者编号 SH10-19910430Z21 　 　 　 　 106 1001 健康卡号 XXXXXXXXXXXXX09 　 　 　 　 107 1001 身份证号 XXXXXXXXXXXXXXX 　 　 　 　 108 1001 姓名 胡风 　 　 　 　 109 1001 工作单位 上海橡胶厂 　 　 　 　 110 1001 职别 工人 　 　 　 　 111 1001 性别 女 　 　 　 　 112 1001 住址 上海市蒙古路20号 　 　 　 　 113 1001 年龄 32 　 　 　 　 114 1001 入院日期 1991/4/30 　 　 　 　 115 1001 婚否 已婚 　 　 　 　 116 1001 病史采取日期 1991-4-30 　 　 　 　 117 1001 民族 汉 　 　 　 　 118 1001 病情陈述者 本人 　 　 　 　 　 　 　 　 在关系数据库的设计人员看来上表中的如下数据都加了数据冗余。

ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 19879 事物分类 病历 19879 事物分类 住院病历 19879 患者编号 SH10-19910430Z21 　 　 　 　 19879 姓名 胡风 　 　 　 　 19879 健康卡号 XXXXXXXXXXXXXXX09 　 　 　 　 19879 身份证号 XXXXXXXXXXXXXXX 独立数据库中的数据冗余的目的是让每一个数据在任何环境中都具有可识别性，而不用注释，也不必再用程序来解读。

上表中在关系数据库高手看来的确是为数据库系统增加了大量的冗余。这是为了方便信息系统之间的互联互通、信息共享而采取“以空间换取使用方便”的策略！其目的是为了是以适当的数据冗余而使数据具有可识别性。

用关系数据库系统所实现的信息系统之所以都孤岛型信息系统，难以互联互通、信息共享，就是因为关系数据库系统中的数据是不完整的、不可识别的。当关系数据库中的一个事物的信息发送到其它信息系统时，该信息就会失真。

当前的硬盘的存贮容量与80年代初期相比，已提高了十万倍以上，因此，不必考虑多占用存贮空间的问题，只要使用方便即可。【80年代中期硬盘容量为10M，现在硬盘的容量已2T以上。2T=2000G=2000000M=20万个10M】 必须使数据自己能够说清楚自己是谁，这是建立大数据的数据库的一项重要工作。小数据只是在某个特定的局部发挥作用，它可以通过隐含的含义而表明自己是谁。大数据所涉及的范围大太，因此就必须准确说明，而不能以隐含的方式来表明数据是谁。

在前面的从国家医疗大数据中心查询患者的影像数据的例子中指出：由于当前的医疗信息系统中未使用患者的身份证号而导致查询患者的影像数据变得非常困难。这实际上就是因为关系数据库理论未考虑“数据的可识别性”。

在关系数据系统中，程序员总是通过应用程序来解读各个数据的含义。然而在大数据环境中，用应用程序来解读数据的含义就会变复非常复杂，代价非常高。因此，在大数据环境中，一定要使每一个数据在任何环境下让任何人都可以识别。

门诊号、住院号只是在某家医院内部可识别，在大数据环境中，门诊号、住院号就是不可识别的。为了使数据具有可识别性，有关患者的每一个数据中都要含有患者身份证号。

在独立数据库中，是以数据的独立性和数据的完整性而确保数据的可识别性。

在关系数据库中，是通过数据结构、表之间的关系、应用程序来确保数据的可识别性。在大数据环境中，一定要通过数据来确保数据的可识别性。在国家医疗大数据中，凡是有关患者的数据，就必须用全国统一的、标准的、规范的数据（例如身份证号）来确保每一个数据都是可识别的。在下面的PACS系统表中的数据，大数据环境中就成了不可识别的数据，或难以识别的数据。

在大数据环境中，数据的独立性、数据的完整性、数据的可识别性是非常重要的。在建立大数据时，一事实上要确保其中的每一个数据在全国范围内是可识别的，而不只是在某家医疗内部是可识别的。

3.3.6 数据的多样性 关系数据库让技术人员任意设计数据的结构、表结构，关系数据库理论对表结构几乎没有任何限制。针对同一数据，不同的设计者所设计出的数据结构是不一样的。由关系数据库而产生出来的数据结构有无穷多种，这为大数据处理增加了很多困难。

由于关系数据库理论的先天不足，用关系数据库理论无法从根本上解决数据的多样性问题。关系数据库是大数据中的“数据的多样性”问题的“麻烦制造者”。

独立数据库不让设计人员设计任何数据结构，独立数据库中只有一种数据结构，即“万能数据结构”。因此，对结构化数据而言，用独立数据库所设计的信息系统只有一种数据结构，这样做就从根本上解决了大数据中的数据的多样性问题。

3.3.7 元数据及国际元数据标准非常重要 对元数据的管理是关于数据的数据，元数据对于ETL来说尤其重要。ETL中大量的数据源定义、映射规则、转换规则、装载策略等都属于元数据范畴，如何妥善的存储这些信息不仅关系到ETL过程能否顺利完成而且影响到后期的使用和维护。任何业务逻辑的微小改变最终都落实为相应元数据的调整，初期没有一个完善的元数据管理功能后期作类似调整几乎是“不可完成的任务”。

基于元数据的重要性，国际组织提出一些统一的元数据存储标准，比较知名的如CWM等，这为不同厂商工具之间互操作提供了可能性。

针对ETL的元数据管理应包括：元数据存储的开放性；
元数据存储的可移植性；
提供多种方式访问元数据；
元数据的版本控制；
支持开放的元数据标准；
支持XML进行元数据交换；
支持分布式的元数据访问和管理；
生成元数据报表；
对于ETL过程的冲突分析；
基于元数据的查询功能；
元数据的广播和重用；
对于ETL过程的流程分析等。

若要对多众的关系数据库所产生的数据进行处理，就离不开数据抽取“ETL”。而独立数据库在设计之初就非常关注元数据的标准化、规范化、统一化，因此，在一般情况下，在处理独立数据库中的数据时，不需要ETL。

3.3.8 大数据的关键：让数据自己说话 “让数据自已说话”的含义是：无论把一个数据放到任何地方、任何环境中都能独立地、完整地表达出同样的、完整的含义。在大数据时代，一个数据会出现在不同的信息系统中，因此，必须确保数据在不同的信息系统中、不同的环境中都有相同的含义。数据的独立性、数据的完整性、数据的可识别性的目的就是让数据自己说话。

关系数据库中的数据没有独立性，也没有完整性，关系数据库做不到“让数据自己说话”。关系数据库中的数据需要借助各种“关系”才能表达出完整的含义。

独立数据库中的数据可以自己说话，而关系数据库中的数据需要配备“七大姑八大姨”的“关系”才能准确地表达出相应的含义。

关系数据库的“七大姑八大姨”的“关系”：数据与数据库系统（ORACLE、SQLSERVER、DB2等）具有密不可分的关系，数据与表结构具有密不分的关系，数据与应用程序具有密不可分的关系，数据与数据库中的众多表之间具有密不可分的关系。

由独立数据库与关系数据库的对比可发现：只有让数据自己说话，才是真是的数据。关系数据库中的数据是失真数据。

关系数据库中的数据必须依靠关系数据库系统、数据结构、数据类型、应用程序才具有意义。当关系数据库系统中的数据脱离了相应的关系数据库系统、数据结构、数据类型、应用程序之后就变成了无意义的数据。当前的信息系统所存在的“信息孤岛问题、信息交换问题、数据接口问题、互联互通问题、系统的升级换代问题”等等，都是由于关系数据库系统中的数据不能自己说话而造成的。

用关系数据库系统在电子病历系统中记录“患者基本情况”时会采用如下形式：
ID HZXM GZDW ZB XB ZZ NL RQ HF BXRQ MZ CSZ 426 胡凤 上海橡胶厂 工人 0 上海市蒙古路20号 32 1991-4-30 已 1991-4-30 汉 本人 上述形式的数据是小数据时代的经典结构形式。其实“字段名”也是很重要的信息，必须用标准的、规范的自然语言来描述。

“患者基本情况”在“万能数据结构表”中的表达形式：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 101 1001 事物分类 病历 　 　 　 　 102 1001 事物分类 住院病历 　 　 　 　 103 1001 事物分类 入院病历 　 　 　 　 104 1001 事物分类 患者基本情况 　 　 　 　 105 1001 患者编号 SH10-19910430Z21 　 　 　 　 106 1001 健康卡号 XXXXXXXXXXXXX09 　 　 　 　 107 1001 身份证号 XXXXXXXXXXXXXXX 　 　 　 　 108 1001 姓名 胡风 　 　 　 　 109 1001 工作单位 上海橡胶厂 　 　 　 　 110 1001 职别 工人 　 　 　 　 111 1001 性别 女 　 　 　 　 112 1001 住址 上海市蒙古路20号 　 　 　 　 113 1001 年龄 32 　 　 　 　 114 1001 入院日期 1991/4/30 　 　 　 　 115 1001 婚否 已婚 　 　 　 　 116 1001 病史采取日期 1991-4-30 　 　 　 　 117 1001 民族 汉 　 　 　 　 118 1001 病情陈述者 本人 　 　 　 　 　 　 　 　 通过上述两张表的对比发现，用“万能数据结构表”所表达的信息是一种完全用自然语言所表达的不失真的信息，这种信息无论放在什么地方其含义都是一样的。这种信息的好处是：若所有的信息系统都是用“万能数据结构表”而建立，那么，在对数十万个信息系统中的数据进行处理时，根本不需要进行数据抽取。

从表面上看用“万能数据结构表”所存贮的信息会多占据一倍左右的存贮空间，但这样存贮数据可以减少很多复杂的数据抽取工作。

“万能数据结构表”中的信息是让“数据自己说话”，不依赖数据库系统、不依赖数据结构，不依赖数据类型，不依赖应用程序。

“万能数据结构表”的策略是“以空间换智能及使用方便”。与30年相比，目前硬盘的存贮容量已提高了10万倍以上，多占据一倍左右的存贮空间的代价很低，可以忽略不计。

“让数据自己说话”就是让数据犹如自然语言那样，能够自己能够准确、无误地表达应有的含义，不需要注释，也不需要应用程序的解读。

3.3.9 大数据的策略：用数据代替程序 在计算机中，有程序和数据之分。然而，对大脑而言，“程序就是数据，数据就是程序”，其含义是：大脑是一个通用的、万能的信息处理器，不需要编程序就可以处理任何信息。在设计计算机软件时也应该模仿大脑的这种功能。

关系数据库是一种“数据、数据结构、程序密不可分的数据库”。因为关系数据库中的数据脱离具体的表结构和程序以后就变成了无意义的数据，关系数据库中的数据只有在特定的表中才具有意义。

医学信息的结构化存贮方法是一种“数据与程序无关的数据结构”，或者说是一种“是什么就是什么，与程序无关”。因为医学信息的结构化存贮方法中的数据脱离其数据结构后，其数据的真实含义不变。

医学信息的结构化存贮方法表中的数据全部是用自然语言而表达的，只要懂自然语言，谁都可以看懂“万能数据结构表”中的数据的真实含义。

从表面上看，关系数据库减少了数据冗余，这是其一大优点。然而，这也是关系数据库的最大缺点之一。关系数据库在减少了数据冗余的同时，也导致了数据失真。数据失真的结果就导致：信息交换、信息孤岛、异构数据源等等问题。在关系数据库中，只有通过编写大量的程序，才能解决数据失真问题。无数事实表明，关系数据库因数据冗余问题而付出了非常高昂的代价。当“数据与程序密不可分”时，要存贮、读取、查询数据就必须编写大量的程序。当“数据与程序无关时（或关系很少时）”，只要编写一个通用的程序，其它人借助这个程序就可以非常方便地存贮、读取、查询数据，而不必每开发一个数据库都开发大量的软件。“万能数据结构表”实现了“程序就是数据，数据就是程序”。

医学信息的结构化存贮方法的一个原则、大数据原则：基本上不考虑数据冗余问题，以空间换取智能和使用方便，让数据自己说话，而不是让程序替数据说话。而关系数据则是通过数据结构、应用程序而代替数据说话。

用数据代替程序：宁愿增加大量的“冗余”，也要使数据具有独立性、完整性、可识别性。

在用关系数据库设计信息系统时，总是用程序来解读数据库中的数据。这种策略所带来的严重恶果就是在处理数据时需要编写大量的程序，不编写程序就无法处理数据。

3.4 与信息系统的耦合度为零的数据才是合格的大数据 如果说一个数据需要相应的信息系统的解读之后用户才能读懂，那么该数据就是与信息系统耦合度较高的数据。

如果说一个数据不需要任何信息系统的解读用户就能读懂，那么该数据与信息系统的耦合度为零。

人们用自然语言所编写的各种文章就是相应专业的人员可能直接读懂的，不需要任何的信息系统的解读，因此，这种数据与信息系统的耦合度为零。

大数据中的数据来源于成千上万个机构，合格的大数据应该是与信息系统的耦合度为零的数据。

关系数据库中的数据一种与信息系统的耦合度非常高的数据。因为关系数据库中的数据与数据库系统、与数据结构、与应用程序是密不可分的，关系数据库中的数据一旦脱离了原的信息系统而到了大数据环境中之后，就变成了无意义的数据。

独立数据库中的数据则是与信息系统的耦合度为零的数据。

在大数据中，其数据量数以千亿计，如果其中的每一个数据都与系统都有一定的耦合度，那么就需要编写海量的程序才能解读大数据。如果说大数据中的每一个数据都是与信息系统的耦合度为零的数据，那么在处理大数据时，就不必再编写任何程序对数据进行解读。

判断一个数据是否是合格的大数据的原则：与信息系统耦合度为零的数据才是合格的大数据。

独立数据库以适当的数据冗余而使数据具有独立性、完整性、可识别性，以数据的独立性、数据的完整性、数据的可识别性而确保独立数据库中的每一个数据都是与信息系统耦合度为零的数据。

建立大数据的原则：必须确保其中的每一个数据都是与信息系统耦合度为零的数据。

推论：由于关系数据库中的数据几乎全部都是与信息系统密切耦合的数据，所以关系数据库中的数据不是合格的大数据。

独立数据库是以一定量的数据冗余而实现“数据与信息系统的耦合度为零”。

医学信息的结构化存贮方法注重的是数据的完整性。医学信息的结构化存贮方法要求各个事物的数据要独立地、准确地、完整地表达出某种含义。在“万能数据结构表”中，事物之间的关系不是靠各种表来表达，而是靠各事物原来所具有的自然特征和特征值而自然地建立关系，各事物之间的关系与数据库系统以及应用系统无关，或者说各事物之间的关系完全独立于数据库系统及应用系统而独立地、准确地、完整地具有某种含义，这就可以确保一个事物的信息在任何信息系统中都有相同的含义。百分之百合格的“万能数据结构表”中的数据与数据库系统、表结构、应用系统的耦合度为零。

“万能数据结构表”中的数据与数据库系统及相应的应用程序是相互独立的，即“万能数据结构表”中的任一事物的数据都具有比较好的完整性、独立性，“万能数据结构表”中的数据脱离相应的数据库系统及应用程序后还能保持原来的意义，数据的完整性、独立性是确保信息系统之间可以互联互通和信息共享的基础。

“万能数据结构表”中的数据与“数据库系统、表结构及应用程序”无“关系”，可以完全脱离数据库系统、表结构、及应用程序而独立存在，所以用医学信息的结构化存贮方法所建立的信息系统实现互联互通非常容易，因为它的数据无论发送到什么地方，都能独立地、准确地、完整地表达出原有的含义。

数据完整性、独立性的重要意义：可以很容易地实现信息系统之间的互联互通，可以有效地解决当前的信息孤岛问题。当前之所以存在严重的信息孤岛问题，根本原因就在于各个信息系统中的数据不具完整性、独立性，数据与数据库系统、表结构、应用系统的“关系”密不可分。关系数据库的数据不具完整性、独立性，这是因为关系数据库中的数据离不开表的结构，离开了表结构，数据就失真，而带表结构进行交换时，接收数据的关系数据库中往往没有结构完全相同的表结构而不认识所接收到的数据。“万能数据结构表”中的数据本身就是完整的、自带结构的。

医学信息的结构化存贮方法提倡用自然语言，尽量避免用代码。为了实现数据的完整性、独立性，要尽量少用、甚至不用代码。因为代码会使数据变得难以理解，会使数据与应用程序的耦合度增高，使数据失去完整性、独立性。传统的数据库系统设计者爱使用代码，这样做的结果就使数据库系统中的数据与应用程序密不可分，需要由专用的应用程序才能正确解读数据的真实含义。这也是产生信息孤岛的一个重要原因。

对关系数据库而言，同一张表中的信息为同一类事物的信息，不同类的信息存贮在不同的表中，医学信息的结构化存贮方法则是由事物本身的特征及特征值而自然地确定各事物是不是同一类事物。拥有一个或若干个相同的特征及特征值的事物就是同一类事物，拥有一个或若干个相同特征的事物也可以认为是同一类事物。

从技术上而言“信息孤岛”问题是由“异构数据”而引起的，医学信息的结构化存贮方法巧妙地解决了“异构数据”问题，可以使所有的数据都有相同的结构。如果所有的信息系统都统一采用“万能数据结构表”来存放数据，那么信息孤岛问题就可以 得到有效解决！ 3.5 医学信息的结构化存贮方法与关系数据库的对比 医学信息的结构化存贮方法与关系数据库的对比 对比的内容 关系数据库 医学信息的结构化存贮方法 跨平台数据交换 跨平台数据交换非常困难，需要进行数据格式转换，具体表现是当数据交换的数量增大时，数据格式转换就成一件非常烦琐的工作。

跨平台数据交换非常简单，因为“万能数据结构表”是一张万能表，可以存放任意结构的数据。

数据结构 不同的表，其结构不一样。1000种表，就有1000种以上的结构。关系数据库是一种与数据结构密不可分的数据库，正因如此而导致了异构数据源、信息孤岛、信息交换问题。

无论有多少张表，其结构都是一样的，所有的数据都可以放到一个统一的表中。正因如此，用“万能数据结构表”而建立的数据库系统是一种基本上与数据结构无关的数据库。

异构数据 无法解决异构数据问题，甚至可以说关系数据库是异构数据的发源地。

不存在异构数据问题，所有的数据都是同构的。

数据结构的标准化 无法用关系数据库理论而设计出标准化的数据结构 “万能数据结构表”可当作标准化的数据结构 与数据结构的关系 关系数据库中的任何数据都与其数据结构密切相关，关系数据库不能存放无结构的数据，其中的数据也不能脱离相应的数据库而生存。正因如此，当关系数据库中的数据传送到其它地方时，就会因为没有对应的数据库和数据结构而无法生存。

“万能数据结构表”是一种万能的数据结构，可以存放所有关系数据库中的任何数据。正因如此可以认为它是一种与结构无关的数据结构，虽说它也有结构。“万能数据结构表”在任何数据库中的结构都相同。

数据的独立性 关系数据库中的数据不是独立数据，必须依赖其数据结构而存在，失去了数据结构，就会变成无意义的数据。

“万能数据结构表”表中的数据具有独立性，即可以独立地表达出某种含义。

数据的完整性 关系数据中的数据不是完整数据，因为它必须加上其数据结构信息才能成为完整的数据。

是完整数据。

3.6 应用医学信息的结构化存贮方法的注意事项 使用习惯问题：医学信息的结构化存贮方法与关系数据结构有着本质的不同，所以处理医学信息的结构化存贮方法中的数据与处理关系数据库中表中的数据的方法也有本质的不同。对于初学使用医学信息的结构化存贮方法者而言，会感到 “别扭”。此问题短期内还解决不了，使用时间长了，习惯了也就可以了。新生事物有其优点，也有其缺点。

3.7 超大表化问题：分为多张表 从理论上而言，医学信息的结构化存贮方法只要用一张表就可以存放各种各样的数据。由于当前的数据库系统在存放大量数据时会导致系统性能下降，为解决些问题，可以把表分为若干个表。

医学信息的结构化存贮方法强调的是所有表的结构都相同，并不限制在一个数据库中采用多少张表。然而，无论用多少张表，一定要使这些表的结构完全相同，只有这样，才能确保互联互通，确保数据可以随意地迁移到其它系统中。

对医学信息的结构化存贮方法而言，无论数据库中拥有多少张万能数据结构表，由于这些表的结构都一样，所以只要编写一个通用的程序就可以对所有的表进行处理，而对于用户而言，就好象只有一张表。

3.8 关系数据库中的二维表是数据不具独立性的一个根本原因 在用关系数据库设计信息系统时，不同的设计者在设计同一张表时，所设计出的数据结构是不一样的：
l 用的数据库系统不一样 l 数据库名不一样 l 表名不一样 l 字段名不一样 l 字段的排列顺序不一样 l 各字段的长度不一样 l 各字段的数据类型不一样 由于上述原因，当两个系统交换数据时，一个系统就不认识另一个系统所发过来的数据。

3.9 “万能数据结构表”存放病历信息的例子 病历中的“患者基本情况”的信息为：
姓名 胡凤 工作单位 职别 上海橡胶8厂工人 性别 女 住址 上海市蒙古路20号 年龄 32岁 入院日期 1991-4-30 婚否 已 病史采取日期 1991-4-30 籍贯 江苏盐城县 病史记录日期 1991-4-30 民族 汉 病情陈述者 本人 “患者基本情况”在“万能数据结构表”中的表达形式：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 100 1001 事物属性 住院病历 101 1001 事物属性 入院病历 　 　 　 　 102 1001 事物属性 患者基本情况 　 　 　 　 103 1001 患者编号 SH10-19910430Z21 　 　 　 　 104 1001 姓名 胡风 　 　 　 　 105 1001 健康卡号 XXXXXXXXXXXXXXX09 　 　 　 　 106 1001 身份证号 XXXXXXXXXXXXXXX 　 　 　 　 107 1001 工作单位 上海橡胶8厂 　 　 　 　 108 1001 职别 工人 　 　 　 　 109 1001 性别 女 　 　 　 　 110 1001 年龄 32 　 　 　 　 111 1001 入院日期 1991/4/30 　 　 　 　 112 1001 民族 汉 　 　 　 　 113 1001 病情陈述者 本人 　 　 　 　 114 1002 事物属性 住院病历 115 1002 事物属性 入院病历 　 　 　 　 116 1002 患者编号 SH10-19910430Z21 　 　 　 　 117 1002 姓名 胡风 　 　 　 　 118 1002 健康卡号 XXXXXXXXXXXXXXXXXXXX 　 　 　 　 119 1002 身份证号 XXXXXXXXXXXXXXXXXXXX 　 　 　 　 120 1002 事物属性 主诉 　 　 　 　 121 1002 症状 怕热 　 　 　 　 122 1002 持续时间 5 　 年 　 　 123 1003 事物属性 住院病历 124 1003 事物属性 入院病历 　 　 　 　 125 1003 患者编号 SH10-19910430Z21 　 　 　 　 126 1003 姓名 胡风 　 　 　 　 127 1003 健康卡号 XXXXXXXXXXXXXXXXXXXX 　 　 　 　 128 1003 身份证号 XXXXXXXXXXXXXXXXXXXX 　 　 　 　 129 1003 事物属性 主诉 　 　 　 　 130 1003 症状 多汗 　 　 　 　 131 1003 持续时间 5 　 年 　 　 3.10 医学信息的结构化存贮方法实现互联互通非常简单 从技术上而言，信息孤岛问题，互联互通问题的根源在于异构数据。由于技术上的原因，用关系数据库所开发的信息系统的信息源基本上都是异构的，所以难以实现互联互通。

如果各个信息系统都用医学信息的结构化存贮方法来开发，那么这些信息系统都是同构的，因为用医学信息的结构化存贮方法所开发的信息系统的数据结构都是相同的，所用的都是结构完全一样的“万能数据结构表”。

用关系数据库所开发的信息系统在实现数据交换时，每实现一种数据交换就要一个接口，若与100个系统交换数据，最少要开发100个接口。

因为用医学信息的结构化存贮方法所开发出的信息系统的数据源都是同构的，所以只要开发出三个WebService（查询、发送数据、接收数据）即可很容易地实现与所有信息系统的信息共享、互联互通。

3.11 结构化录入病历信息的例子：症状的结构化 l 电子病历信息虽复杂也是有规律可循的，是可以结构化的。

l 《病历书写规范》：“2.主要症状特点及其发展变化情况：按发生的先后顺序描述主要症状的部位、性质、持续时间、程度、缓解或加剧因素，以及演变发展情况。” l 不同的症状可以制定不同的标准的、规范的模版供医生使用。这样可确保统计、分析。

l 手工病历是用自然语言所写，不标准、不规范，随意性很大，往往忽略了很多重要的信息。

一般情况下，症状的属性：
属性 属性值 症状名称 部位 范围 症状开始时间 持续时间 性质 程度 症状诱因 与活动的关系 与体位的关系 发作频度 缓解方式 放射部位 伴随症状 下面的症状结构化可供参考：
l 腹痛的结构化 病历信息：“男性，60岁，半年来经常便秘。三天前出现腹部持续疼痛，阵发性加剧，呕吐二次系胆汁性液体，约500ml。过去无类似发作史。查体腹胀BPl8／13kPa，体温：37.5℃，右下腹稍压痛，腹软，未触及肿块，肠鸣音亢进，白细胞9X109／L。” 上述病历信息中的“腹痛”的结构化：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 1009 事物分类 住院病历 1009 事物分类 入院病历 1009 事物分类 现病史 1009 患者编号 SH01-19950212Z231 1009 姓名 张三 1009 健康卡号 XXXXXXXXXXXXXXX 1009 身份证号 XXXXXXXXXXXXXXX 1009 症状 腹痛 1009 开始时间 3天前 1009 持续时间 3 天 1009 特点 阵发性加剧 1009 压痛位置 右下腹 1009 性质 1009 程度 剧烈 l 胸痛的结构化 ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 1109 事物分类 住院病历 1109 事物分类 入院病历 1109 事物分类 现病史 1109 患者编号 SH01-19950212Z231 1109 姓名 张三 1109 健康卡号 XXXXXXXXXXXXXXX 1109 身份证号 XXXXXXXXXXXXXXX 1109 症状名称 胸痛 1109 部位 胸部 1109 范围 胸骨后 1109 症状开始时间 3个月前 1109 持续时间 1 天 1109 性质 压榨性疼痛 1109 程度 剧烈 1109 症状诱因 无 1109 与活动的关系 卧床休息后症状缓解 1109 与体位的关系 1109 发作频度 1109 缓解方式 卧床休息后缓解 1109 放射部位 无 1109 伴随症状 右上肢乏力 1109 伴随症状 右上肢麻木 1109 伴随症状 气紧 1109 伴随症状 头昏 1109 伴随症状 四肢无力 1109 伴随症状 冷汗 第4章 独立数据库在医疗大数据方面的优势 用独立数据库所设计的信息系统具有如下特点：
l 所有的数据都具有相同的数据结构 l 不存在异构数据问题 l 不存在数据交换难题 l 不存在信息孤岛问题，只要管理人员充许两个系统互联互通即可。

l 不必进行ETL，节省了代价昂贵的ETL工作 l 数据挖掘非常容易 4.1 大数据中最重要的就是查询 在大数据中，最关键的问题就是如何从海量的数据中采集到所需要的数据，然后才是对大数据的分析，犹如Google、百度，Google、百度所做的所有工作只是为了用户能查询到自己所需的信息。

4.2 超大表问题 从理论上而言，在用独立数据库设计信息系统时，只要用一张表就可以存贮所有数据。要做到这一点，需要设计新的数据库系统。

由于目前是用关系数据库系统来实现独立数据库，而关系数据库在处理超大表时会出现性能下降的问题，因此，需要考虑超大表问题。

用独立数据库所建立的国家医疗大数据中一个最突出的问题就是超大表问题。国家医疗大数据中心的数据存贮在成千上万台服务器中，拥有数十万个数据库、数千万能张表。

产生超大表问题的原因：关系数据库用一条记录（含有N个字段）来表达一个事物的数据，而独立数据库至少要用（N+X）条记录才能表达一个事物的数据，所以用独立数据库所设计的信息系统所用的记录的数量是关系数据库的记录数的N倍以上，一般为关系数据库的记录数的十倍左右。因此，独立数据库更容易产生超大表问题。

4.2.1 自动调整表的长度 关系数据库高手非常关心独立数据库的超大表问题，他们认为把所有数据都存贮到一张表中，会导致表非常长，这会影响系统的性能。其实这个问题的处理很简单。关系数据库处理超大表时会把一张表分成几张表，独立数据库也可采用这种方法，例如当表的长度超过5000万条记录时，就由应用程序自动地生成新表，并把数据存贮到新的表中。这可以通过编写一个通用的超大表自动调整软件工具即可解决超大表问题，系统存贮数据时由软件工具自动调整表的长度，在用户看来就犹如所有数据都是存贮在一张超大的表中。这是 “医学信息结构化存贮方法”这项发明专利技术的关键，让用户不必关心表的大小问题，由系统自动调节表的大小，表中记录大到一定程度后系统就自动地把数据存贮到新的表中。

4.2.2 自动查询多张表 例如在某医疗的EMR系统中，所有数据都存贮在SQL SERVER数据库系统的EMRDB数据库中，EMRDB中共有N张“万能数据结构表”，依次为EMRDBtable1至EMRDBtableN。

由于独立数据库中的所有表的结构都是完全一样的，所以很容易设计出通用的自动查询软件工具。

医院所用的通用查询软件工具：
1、 登记数据库中有哪些万能数据结构表 2、 在查询数据时，自动查询所有的万能数据结构表，并把查询结果返回给用户，对使用户而言犹如从一张表中查询数据。

国家医疗大数据所用的通用查询软件工具：
1、 登记各家医疗机构上传到国家医疗机构的数据库（IP、连接字符串、表等）
2、 在查询数据时，自动查询所有万能数据结构表，并把查询结果返回给用户，对使用户而言犹如从一张表中查询数据。

3、 由于数据库及表的数量众多，在设计软件工具时可让国家医疗大数据中心的每台服务器分别各自查询，然后再由软件工具把结果汇总后提交给用户。

从国家医疗大数据中心查询某个人的病史所花费的时间其实是很短的，不超过10秒。若患者的病史数据量比较大，例如住院时间达半年以上，数据的传输时间会长一些，这取决于网络的速度，一般的查询都不会超过10秒钟。

与关系数据库系统相比，用“医学信息结构化存贮方法”所建立的信息系统的记录数多了10倍左右，这对当今的计算机技术而言根本不是问题，不必纠结这个问题。

“医学信息结构化存贮方法”会比关系数据库多用一倍左右的存贮空间，这也不是问题。

犹如GOOGLE那样，虽说拥有成千上万台服务器，但对用户而言就犹如所有数据都存贮在同一台服务器中。

当然，最好的方法就是开发新的数据库系统，减少表的数量，增加表的长度。从长远看，超大表问题是可以解决的。将来的独立数据库系统中只有一张表，表的长度取决于硬盘的容量。

l 在查询数据时，不必考虑数据存贮在哪个数据库，不必考虑数据存贮在哪张表中，也不必考虑表的结构。你只要描述清楚你想要什么样的数据即可。

4.3 用独立数据库实现国家医疗大数据的存贮处理 4.3.1 独立数据库如何处理国家医疗大数据中数十万个数据库、数千万张表 如果全国各家医疗机构的所有信息系统都是用独立数据库所开发。全国各家医疗机构也是以镜像方式把自己的各种数据实时地上传到国家医疗大数据中心。每家医疗机构有若干个数据库，一个数据库中有若干张表。医疗数据需要永久保存，因为医疗数据对研究人类疾病的演变是非常有用的。因此，国家医疗大数据中要保存很多年的数据。

针对上面所述的场景，查询患者的病史数据就非常简单。

l 假设国家医疗大数据全部存贮在SQLSERVER数据库中，共有10万个数据库，1000万张表，所有数据存贮在1万台数据库服务器中。由于所有表的结构都是相同的，只要知道这些表分别存贮在哪个数据库中即可通过技术处理而很容易地查询到患者的病史数据，就犹如所有数据都存贮在一张无比巨大的表中。

只要输入如下查询条件即可在国家医疗大数据中心查询到某个患者在全国各家医疗就医时的所有数据：
查询所有的病历数据 事物特征 事物特征值 身份证号 XXXXXXXXXX 事物分类 病历 因为患者所有的病历数据的数据量不是很大，所有也可以直接用患者的身份证号而查询到患者的所有数据：
事物特征 事物特征值 身份证号 XXXXXXXXXX 查询患者的PACS数据：
事物特征 事物特征值 身份证号 XXXXXXXXXX 事物分类 PACS系统 查询患者在某家医院就医时的PACS数据：
事物特征 事物特征值 身份证号 XXXXXXXXXX 事物分类 PACS系统 PACS系统中的数据在万能数据结构表中表现形式：
ID 事物代号 事物特征 事物特征值 超长特征值 单位 附件 时间 101 1001 事物分类 PACS系统 　 　 　 　 102 1001 事物分类 CT系统 　 　 　 　 103 1001 身份证号 410305195003XXXX 104 1001 健康卡号 XXXXXXXXXXXXX09 105 1001 门诊或住院号 00084274 　 　 　 　 106 1001 姓名 张XX 　 　 　 　 107 1001 年龄 17 　 　岁 　 　 108 1001 性别 男 　 　 　 　 109 1001 科室 感染科 　 　 　 　 110 1001 申请医生 谢XX 　 　 　 　 111 1001 申请时间 2015-6-18 　 　 　 　 112 1001 检查项目名称 CT检查-（门+住）胸部螺旋CT 　 　 　 　 113 1001 临床诊断 肺结核，痰镜检（+）
　 　 　 　 114 1001 影像诊断 1、请结合痰检）2、右侧胸腔积液引流术后 　 　 　 　 115 1001 影像 　 　 P1 　 116 1001 影像 　 　 P2 　 117 1001 影像 　 　 P3 　 118 1001 影像 　 　 P4 　 　 　 　 　 4.3.2 疾病、症状的相关数据 对某种疾病的科学研究：全国历年的发病总人数、男女比例、疾病与年纪的关系、与职业的关系、与地区的关系、平均治疗费用、误诊率等等。

仅对疾病、症状进行查询时所查出的数据量会非常庞大，需要对查询过程进行优化。在查询时可以分别从各家医院的数据中进行查询，然后再对数据进行汇总。

例如统计“缺铁性贫血”在2014年全年发病的总人数、男妇比例：
从住院病历中查询数据 事物特征 事物特征值 时间 疾病名 缺铁性贫血 2014年1月1日-2014年12月31日 事物分类 最后诊断 2014年1月1日-2014年12月31日 事物分类 住院病历 2014年1月1日-2014年12月31日 返回的数据：
从门诊病历中查询数据 事物特征 事物特征值 时间 疾病名 缺铁性贫血 2014年1月1日-2014年12月31日 事物分类 门诊病历 2014年1月1日-2014年12月31日 返回的数据：