利用万能数据结构表存储多源异构数据

简介：多源异构问题是现有技术无法解决的大难题，原因在于数据共享交换的应用场景与当前的信息系统中的数据的应用场景完全不同，关系数据库已不能有效地处理数据共享交换中的数据。万能数据结构表是一张通用的表，可以用一张万能数据结构表而存储关系数据库中各种各样的表中的数据，可以有效地解决全球范围内数据共享交换时所产生的多源异构问题，功能非常强大，刚开始使用时会感到不适应，需要熟悉一段时间才知其奥妙所在。

1. 软件系统的两种不同的应用场景及数据的生存环境

数据共享交换之所以是一个难题，是因为当前的软件系统的设计模式是“以我为中心”的软件设计模式，以这种模式设计的软件系统百分之百是孤岛型系统，而数据共享交换是众多软件系统之间的“无中心”的数据处理模式。

现有的软件系统只处理“我的系统”中的数据，不处理你的数据，也不处理他的数据。数据共享交换所处理的是软件系统之间的“数据”，包括“我的数据、你的数据、他的数据、大家的数据”。

当前的所有软件系统中的所有数据，包括关系数据库中的所有数据，都是自定义的数据，即所有软件系统都是只能处理自己已定义的数据，不能处理未定义的数据。然而，在共享交换中，随时都会接收到未在自己的软件系统中定义的数据。因为接收到的数据未在自己的系统中进行定义，因此，数据接收方的软件系统无法处理。

1. “以我为中心”的孤岛型系统的特点

“以我为中心”的孤岛型系统的特点：只考虑我的软件系统之内的数据的存储、处理；只考虑我的用户，要成为我的用户，必须先在我的系统内注册，经我审核后才能成为我的用户；若向外界提供数据，则需要通过我的点对点数据接口才能实现，要用我的数据接口也必须先在我的系统中注册用户。孤岛型系统是“以我为中心”的，即软件系统的所有用户都是以我的软件系统为中心，我只存储处理我的数据，不存储处理你的数据，也不存储处理他的数据。

当前的“以我为中心”的软件系统中的结构化数据的生存环境及特点：

1. 当前的各种软件系统具有比较明确的应用范围，例如ERP、OA、财务管理系统、电子病历系统，其应用范围一般只是某个机构内部的某种业务；

1. 各软件系统各自定义自己的数据；

1. 系统中的表的数量一般只是100张表左中，很少不超过1000张表；

1. 系统中的表的数量及结构很少变动，各表的各字段的数据类型都是已知的、（基本上是）固定不变的。

1. 在设计软件系统之前就事先知道需要处理哪些数据，表的结构及数据的内容也是可确定的；

1. 系统的特点：以我为中心的孤岛型系统，我只处理我的数据，不处理你的数据，也不处理他的数据，因为我的系统中未定义你的数据和他的数据；

1. 对数据的查询、统计分析也是可预知的，在设计软件系统时就已知该哪些表的哪些字段进行查询、统计分析；

1. 系统既要处理数据，也实现一些功能（例如画图、播放音乐）。

1. 数据共享交换属于众多软件系统之间的“无中心”的数据互联互通

数据共享交换中的数据生存环境与当前软件系统中的数据的生存环境完全不同，数据共享交换所处理的数据是两个或两个以上的软件系统之间共享交换的数据，甚至是全球范围内的各种软件系统之间共享交换的数据，属于“无中心”的环境，相应的数据及用户的特点：

1. 数据共享交换的数据是全球范围内的数千万个以上软件系统之间的各种各样的结构化数据，数据结构的种类无穷无尽；

1. 数据共享交换中的用户不是某个软件系统内部的用户，而是软件系统之间的用户，是无限的，有可能涉及到全球数亿法人用户、数十亿自然人用户；

1. 数据的接收方有可能会接收到数万、数十万种结构各不相同的异构的结构化数据，面对如此众多的多源异构数据，利用关系数据库已很难处理，例如，要从这么多的异构数据中查询某个数据，需要编写很大的应用程序；

1. 数据接收方所接收到的很多数据未在数据接收方的软件系统中定义；

1. 在数据共享交换中，随时都会接收到全新结构的表，谁也无法预测下一张表会是什么样的结构，所接收到的表的数量、表的结构、各表的各字段的数据类型都是未知的，针对这种情况该如何编写查询程序？例如，要对一万张表中的数据进行查询，需要编写多少行的查询软件？成本是多少？

1. 应该对哪些表的哪些字段进行统计分析也是未知的；

1. “无中心”模式只是在系统之间实现数据共享交换，不包括“功能”（或由数据接收方根据接收到的数据而实现各种“功能”）。

1. 总结

当前的“以我为中心”的软件系统只能对“有限的用户”提供“有限的数据”的数据服务。“有限的用户”是指在我的系统中注册的用户，不对未注册的用户提供服务。“有限的数据”是指在我的系统中已定义的数据；我的系统不处理（不能处理、也处理不了）未在我的系统中定义的数据。在“以我为中心”的软件系统中，所有用户、所用数据都以我为主，都要受我控制。当前的数据共享交换平台也是属于“以我为中心”的软件系统。

“无中心”的数据共享交换的特点：用户和数据是软件系统之间的；面临大量的未注册的用户、未定义的数据；是“无限的系统、无限的用户、无限的数据”之间的共享交换。由于数据共享交换中的用户和数据与当前的软件系统中的用户和数据都发生了本质的变化，因此，需要建立新的软件设计理论体系才能高效地实现数据共享交换。数据共享交换属于“无中心”的通信，需要采用犹如电子邮件、手机那样的“无中心”数据流通方法和工具。

1. 万能数据结构表

万能数据结构表是一种万能的表，可以用一张表存储各种各样的结构化数据。

关系数据库以“横向”的N个字段存贮一个事物的信息：

“万能数据结构表”以“纵向”的N（或N+X）条记录存贮一个事物的信息：

上表称作“万能数据结构表”，因为该表可以存贮各种各样的结构化数据，可以实现万能查询。

“万能数据结构表”可用一张表存贮各种各样的数据，从根本上解决了互操作中的数据多源异构问题，例如下表就存贮了“销售订单表、销售订单明细表、患者基本情况表、住院病历表、动物档案表、员工身高体重表、通信录表、医疗费用表”的数据，这是关系数据库中的二维表所做不到的。

万能数据结构表可存贮各种各样的结构化数据

“万能数据结构表”的数据结构与关系数据库中的表的数据结构有本质的区别，可采用关系数据库系统ORACAL 、DB2、SQL SERVER、Access等建立“万能数据结构表”。

“万能数据结构表”在SQL SERVER中的结构形式：

“万能数据结构表”中各字段的含义：

1. “id”为每个记录的ID。

1. “事物代号”为各事物的代号，每个事物拥有唯一的“事物代号”。关系数据库中的一个完整的数据是记录，万能数据结构表中一个完整的数据是“事物”，一个“事物”的信息由若干条拥有相同“事物代号”的记录组成。

1. “事物属性”的含义为事物的特征、属性。

1. “事物属性值”的含义为事物的特征值、属性值。

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

1. “单位”字段代表事物属性值的单位（次、米、吨等）。

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

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

万能数据结构表的规定：

1. 数据结构必须统一化、标准化，不能作任何改变。这是确保信息系统互联互通的基础。

1. 同一张表中的同一事物拥有一个唯一的事物代号，不同的事物不能拥有相同的事物代号，不同的事物代号代表不同的事物。

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

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

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

如何证明万能数据结构表是万能的？一张万能数据结构表可以存贮各种关系数据库中各种各样的表中的任何数据，下面用一个比较简单的方法来证明。下面的表是关系数据库中的表：

下面用一种简单的形式来证明如何把上面的各个表中的内容转换到万能数据结构表中。把上表逐一向上移，让上表变成如下形式：

然后再将上表逆时针转90度，则成下表形式：

仔细观察下表，就会发现下表的数据结构全是相同的！都只有两列。

上面的方法可以非常简单地证明关系数据库中的各种数据都可以转换成相同的数据结构。如果你感觉那张表中的数据不能存贮到万能数据结构表中，那么，你只要把表反时针转90度，只看原来的“表头及第一行数据”就会发现，这张表是可以转换到万能数据结构表中的。

上面的方法证明了万能数据结构表可以存贮关系数据库中的各种数据，所以是万能的。

1. 用数据集装箱存储共享交换中的数据

为了从根本上解决数据共享交换中的多源异构数据问题，用数据集装箱（如图3、图4、图5所示）来存储共享交换的数据。数据集装箱采用万能数据结构表存储数据。

在关系数据库中，数据的最基本的单位是记录，利用一条或若干条记录而表达一种完整的事件。

在数据共享交换中，每次共享交换的所有数据都用一个数据集装箱存储。

交通运输行业是通过如下方式而运输货物：1、货物装入集装箱；2、运输货物；3、接收货物；4、拆箱取货。在数据共享交换中，数据集装箱只是为了在数据发件箱和数据收件箱存贮结构化数据，在数据的传输环节不使用数据集装箱；普通用户所看到的是数据发件箱及数据收件箱中的结构化数据，数据的收发过程是普通用户看不到的，用户在数据收件箱和数据发件箱中看到的是数据集装箱中的内容，因此对普通用户而言数据通犹如是以集装箱的形式传输的。

数据集装箱中的数据分为“数据封面、发送者身份、数据流通状态、数据内容”4个组成部分，同一数据集装箱中的数据全部存入同一张表中。

数据发件箱中的数据集装箱的数据结构和数据内容如表4所示：

表4：数据集装箱、数据发件箱中的数据的数据结构示例

在数据流通系统（简称数据通）中，每个用户拥有一个数据发件箱，每个用户的数据发件箱中的全部结构化数据全部存贮到一个指定的表中,该表由系统自动生成。数据通每发送一个邮件，邮件中的数据都存贮到一个数据集装箱中，数据集装箱的数据结构如表4所示。在数据发件箱中，每一个数据集装箱都有一个唯一的数据集装箱编号。数据集装箱的编号由数据通统一编码，数据集装箱编号一般可设置为发件流水号。在数据发件箱中，数据集装箱的数据分为“数据封面、发送者身份、数据流通状态、数据内容”4个组成部分。

数据发件箱中的数据集装箱的数据封面的数据内容为：数据集装箱编号、数据分类（注：数据分类对应的数据为“数据封面”）、收件人地址、邮件标题、邮件内容。

发送者身份数据的内容为：数据集装箱编号、数据分类（注：数据分类对应的数据为“发送者身份”）、发送者姓名、发送者单位、数据发送者的职责权限等内容。若发送者为自然人用户则发送者身份数据中可不包括“发送者单位、数据发送者的职责权限”。数据发送者身份数据由用户设置，用户可设置为对方提供哪些身份数据；身份数据的内容是由数据通根据用户身份管理系统中的数据而生成。

数据流通状态的内容为：数据集装箱编号、数据分类（注：数据分类对应的数据为“数据流通状态”）、数据流通状态、撤回、发送数据的时间、接收数据的时间、回复数据的时间。数据流通状态数据由数据通自动生成。“数据集装箱编号”是当前的数据通所发送的数据及相关内容的数据集装箱编号；“数据流通状态”表明数据是否已发送到对方的数据通中、对方是否已接收到数据（由数据接收方的数据通反馈过来）；“撤回”是撤回当前发送的数据，若对方已接收数据，则不可撤回；“接收数据的时间”由数据接收方的数据通反馈过来。“数据流通状态”的内容由数据通系统自动生成。

数据内容中的相关数据项为：数据集装箱编号、数据分类（注：数据分类对应的数据为“数据内容”）、相关的结构化数据的内容。数据通只负责收发结构化数据，不对收发的数据的内容进行限定，发送什么样的数据完全由发送者自己决定。数据通只负责原样传输数据，不对数据的真实性负责，数据的发送者需要对发送的数据承担相应的法律责任。

数据收件箱中的数据集装箱的数据结构及数据内容如表5所示：

表5：数据集装箱、数据收件箱中的数据及数据结构示例

在数据通中，每个用户拥有一个数据收件箱，每个用户的数据收件箱中的全部结构化数据全部存贮到一个指定的表中，该表由系统自动生成。在数据收件箱中，每一个数据集装箱都有一个唯一的数据集装箱编号。数据集装箱的编号由数据通统一编码，数据集装箱编号一般可设置为收件流水号，数据收件箱中的数据集装箱编号与数据发件箱中的数据集箱编号不是同一个编号。数据通每接收一个邮件，邮件中的数据都存贮到一个数据集装箱中，数据集装箱的数据结构如表5所示。在数据收件箱中，数据集装箱的数据为“数据封面、发送者身份、数据流通状态、数据内容”4个组成部分。

数据封面的数据内容为：数据集装箱编号、数据分类（注：对应的数据为“数据封面”）、发件人地址、邮件标题、邮件内容。

发送者身份的数据内容为：数据集装箱编号、数据分类（注：对应的数据为“发送者身份”）、发送者姓名、发送者单位、数据发送者的职责权限等，若发送者为自然人用户则发送者身份数据中可不包括“发送者单位、数据发送者的职责权限”。发送者身份数据由发送者所用的契约流通系统根据发送者身份数据及发送者自己的设置而生成的。

数据流通状态的数据内容为：数据集装箱编号、数据分类（注：对应的数据为“数据流通状态”）、数据流通状态、发送数据的时间、接收数据的时间、回复数据的时间。数据流通状态数据由数据通自动生成。此处的“数据分类”为“数据流通状态”；“数据流通状态”为“未回复、已回复”，“数据流通状态”的内容由数据通系统自动生成。

数据内容中的相关数据项为：数据集装箱编号、数据分类（注：对应的数据为“数据内容”）、相关的结构化数据内容。

接收数据时数据处理系统处理数据的步骤：步骤a、接收邮件中的数据；步骤b：从邮件内容中截取与数据结构相关的编码；步骤c、根据数据编码把接收到的XML文件解码成结构化数据；步骤d、把“发件人邮件地址、邮件标题、邮件内容”、数据流通状态及解码后的数据存入数据集装箱；步骤e、把数据集装箱中的数据存入数据收件箱中。

数据收件箱、数据发件箱是关系数据库中的表，该表可以设置为数据流通服务机构的关系数据库中的表；也可设置为用户方局域网中的关系数据库中的表，这样就可以使用户在本地的数据库中处理收发的结构化数据。

为了方便普通用户使用数据通，数据通在展示数据的形式上与电子邮件类似，数据通自动地把接收到的数据转换为结构化数据。对普通用户而言，接收、浏览各种结构化数据犹如电子邮件那样简单，这是现有技术未做到的，目前也没有这样的产品。数据通可以接收各种信息系统发来的各种各样的结构化数据，例如水电费、银行流水、电子商务等方面的结构化数据。

与普通电子邮件所不同的是：普通用户在数据通所看到的是结构化数据，电子邮件中的数据是非结构化数据。

1. 关系数据库理论在实现软件互操作时的致命缺陷

全球无数事实已表明凡是用关系数据库理论所开发出的信息系统肯定百分之百是孤岛型的，还无人能用关系数据库理论根除信息孤岛。关系数据库产生信息孤岛的根本原因在于关系数据库的“关系”，由于关系数据库中的数据与表结构、应用程序“关系”密切、紧密耦合，因此，当关系数据库中的数据脱离了原来的生存环境而发送到其它信息系统之后，由于接收数据的信息系统中与接收到的数据之间没有相应的表结构，也没有相应的耦合“关系”，数据就成了无意义的。关系数据库理论是信息孤岛的发源地，要根除信息孤岛的就必须根除“关系”，让数据不依靠任何“关系”而在各个系统中都能独立地表达出完整的含义。

1. 信息孤岛为什么得不到根治

为了解决信息孤岛问题，人们发明了EDI、ETL、ESB、EAI、BI等技术，然而全球的无数事实表明，用这些技术也不能从根本上解决信息孤岛问题。

从技术上而言，当前的信息孤岛是由于各个信息系统的数据结构各不相同而引起的，当系统A把结构化数据D发送给系统B时，由于系统B中没有结构化数据D的数据结构，系统B需要采用转换数据结构和数据内容的方式，或重新设计新的数据结构表的方式，才能把结构化数据D存贮到自己的系统中。

全球信息系统的数量超过千万，全球所产生的数据超过数万亿条，这些数据的结构各不相同。

两个系统之间的互联互通约需要1个人月的工程量。

三个系统之间的互联互通约需要：（3-1）*（3-2）=3个人月。

四个系统之间的互联互通约需要：（4-1）*（4-2）*（4-3）=6个人月。

N个系统之间的互联互通约需要：（N-1）*(N-2)*(N-3)*……*3*2*1个人月。

上述计算表明，随着信息系统的数量的增加，要实现各个信息系统之间的数据的互联互通，所付出的代价非常高，不可承受！这也表明，当前的信息孤岛是不治之症。EDI、ETL、ESB、EAI、BI这类技术只能在局部缓解信息孤岛问题，却不能从整体上根除信息孤岛问题。

1. 问题之一：异构数据是信息孤岛的根源，二维表是异构数据的根源

异构数据是信息孤岛的根源，关系数据库中的二维表则是异构数据的根源。关系数据库是利用二维表来存贮数据，要存贮不同的数据，要用不同结构的表，其结果就是随着信息系统的数量的增加，会产生无穷无尽的结构各不相同的表，也会产生无穷无尽的异构数据。下图就说明了关系数据库中的二维表是如何产生信息孤岛的。

关系数据库中的二维表虽说具有很多的优点，然而二维表却会产生致命的无穷无尽的异构数据问题，也会因此而产生信息孤岛问题。

关系数据库中的数据必须以特定的数据结构表为基础才能生存，即数据必须依靠特定的表的“关系”才是有意义的。这种数据与表的密切耦合关系在众多的信息系统之间进行数据共享、交换、挖掘时就会产生严重的问题。

结论：只要利用关系数据库理论设计信息系统，肯定会用到结构各不相同的二维表，并因此而不可避免地产生异构数据问题、信息孤岛问题。

1. 问题之二：数据与表结构及应用程序密切耦合

关系数据库理论之所以称作是关系数据库，就是因为关系数据库是以“关系”为基础的，“关系”是关系数据库最为自豪的。然而由于关系数据库中的每一条数据都是与特定的数据结构密切耦合的，而且与信息系统也是密切耦合的，因此，当关系数据库中的某条数据一旦脱离了原来的生存环境而发送到其它的信息系统之后，由于接收数据的信息系统中没有相应的数据结构，也没有相应的应用程序来解读接收到的数据，数据就变成了无意义的数据。

结论：关系数据库中的数据与表结构及应用程序密切耦合是导致数据在众多的系统之间难以共享交换的一个根本原因。

1. 问题之三：关系数据库中大量使用代码而导致数据在共享交换时失真

在利用关系数据库理论设计信息系统时大量使用代码也是产生信息孤岛的一个重要原因。例如，对关系数据库而言，下面的两张表是合格的，然而由于这两张表的表头使用的是代码，除了设计人员外，人们就看不懂表中内容的实际含义。

上述形式的数据是关系数据中经典的结构形式。其实“字段名”也是很重要的信息，用代码来表示字段名会导致数据失真，这样的数据在数据共享、交换、挖掘时就会出问题，需要编写大量的程序来解读表中的数据的实际含义。上述两张表的实际含义为：

关系数据库的技术人员已习惯用代码来表达数据库中的数据，例如有的用“1”表示男性，“0”表示女性，有的用“M”表未男性，用“W”表示女性。在单个信息系统中，可以通过程序来解读数据。然而在软件互操作时，所面临的是数百万个信息系统中的数千万个结构各不相同的表，相应的数据量超过数千亿条，要对如此之多的数据进行查询、挖掘，需要编写海量的程序才能解读关系数据库中的每一条数据的含义。

关系数据库理论诞生于1970年的单机时代。关系数据库的创始人在创立关系数据库理论时所考虑的只是如何让自己的系统存贮、识别数据，没有考虑如何让他人的系统也能存贮、识别数据，未考虑结构化数据在各个系统中的互联互通的问题。凡是用关系数据库理论所设计出的信息系统，其中的数据肯定都是与系统密切耦合的，只有自己的数据库系统、只有自己的应用系统才能存贮、识别。关系数据库理论的创始人在创立关系数据库理论时没有考虑数据脱离了原系统之后如何让其它系统也能存贮、识别的问题。这就是用关系数据库理论所设计出的信息系统都是信息孤岛的根本原因。然而在大数据时代，人们更希望数据能够在各个系统之间互联互通、共享交换，希望结构化数据成为大家的系统都可以存贮、识别的数据。

在大数据时代，人们不只是关注单个系统中的数据，更关注由数百万个信息系统所组成的系统群之间的数据共享交换、互联互通，相关数据多达数万亿条以上，数据来自数百万个以上的、不同行业、不同单位、不同信息系统。如果各个系统中的数据都是与系统密切耦合的，脱离了原系统之后就变成了无意义的数据，那么要对由数百万个系统所组成的系统群中的数万亿条数据进行交换、查询、挖掘，工程量将是非常大的，不可承受！由于关系数据库中的数据与数据库中表表结构及应用程序密切相关，因此而导致数据只能某个特定的环境中才是有意义的，一旦脱离了原来的生存环境，就成了无意义的数据，在数据共享、交换、挖掘时就需要编写大量的程序。每一张表中的数据都要编写100行左右的应用程序才能解读其中的数据。当面临数百万以上的表时，就要编写数亿行的应用程序。

1. 问题之四：只能处理自定义数据，不能处理未定义的数据

当前的所有软件系统中的数据都是自定的数据，各软件系统只能处理自己定义的数据，而不能处理自己的系统未定义的数据。然而在数据共享交换中，软件系统所接收到的数据基本上都是未在系统中定义的，因此，软件系统处理不了这些数据。

1. 独立数据库：独立地表达完整的含义，拒绝关系

独立数据库是一种与关系数据库完全不同的新型数据库，以数据集装箱的形式存储数据，要求数据可以独立地表达出完整的含义，适用于众多软件之间的共享交换而产生的多源异构数据的存储处理；独立数据库可以在关系数据库中实现。独立数据库以数据集装箱作为存储软件互操作中的数据的最基本的单位；关系数据库是以一条记录作为最基本的存储单位。在独立数据库中有两种数据，一是用户发送的数据，存储在数据发件箱中；二是用户接收的数据，存储在数据收件箱中；每个用户拥有一个数据发件箱、一个数据收件箱。

1. 尽量避免代码，尽量用标准的自然语言

人的大脑可以理解同义词，但计算机就不能识别出同义词。因此，在大数据中一定要用标准规范的自然语言。例如，中国人都知道孔子、孔丘是同一个人，但计算机就没有此能力。

关系数据库的设计者习惯用代码来表示各种数据。例如，有的设计人员用“0”代表女性，用“1”代表男性，而有的设计人员用“W”代表女性，用“M”代表男性。面对成千上万的信息系统所产生的数据，这种不标准、不规范的代码就会为大数据挖掘带来巨大的灾难。

在软件互操作时，一定要在信息系统中采用全国统一的、标准的、规范的自然言，尽量避免用代码。这是确保数据独立性、数据的完整性和数据的可识别性，降低数据与系统的耦合度的必要措施。

关系数据库系统中用代码的根源之一在于80年代初期硬盘的容量非常低。数据库设计人员希望通过采用代码而减少数据所占用的存贮空间，其想法与“千年虫”是一样的。代码的危害犹如千年虫带给全世界的危害，全世界花费了几千亿美元才解决了千年虫问题。

1. “数据”与“代码”的区别

要真正了解什么是大数据，需要首先搞清楚什么是“数据”，什么是“代码”。

数据的定义：“能让相应专业的人员看懂的信息才称作是真正的数据。”例如，有关医疗的数据应该是相应的医学专业人员能直接看懂的数据，不需要其它注释、解释；有关化学的数据应该是化学专业的人员能看懂的数据，不需要其它注释、解释。

代码的定义：“相应专业的人员不能看懂的信息称作代码，相应的专业人员需要利用相应的应用程序、软件工具对代码进行翻译、解读、注释之后才能看懂代码真实含义。”

从严格意义上而言，计算机中所存贮的一切都是代码，都需要一定的软件工具对这些代码进行解读之后人们才能看懂。

根据上面的有关数据的定义，关系数据库中所存贮的并不是真正的数据，而是“代码”，这种代码需要编写相应的软件才能解读这些“代码”的含义。

目前的很多信息系统都是以关系数据库为基础而建立的，这些信息系统都分作两部分：一部分是关系数据库系统，另一部分是对关系数据库中的数据进行处理、解读、翻译的的应用软件系统。这些信息系统的最终用户都是通过“应用软件系统”而查询、处理关系数据库系统中的数据，最终用户并不是直接与关系数据库打交道，因为最终用户看不懂关系数据库中的“代码”。信息系统的最终用户并不是直接与关系数据库系统找交道，最终用户与关系数据库系统之间都需要有一个“翻译”（即相应的信息管理系统）。例如，医院的HIS系统的最终用户只是通过HIS信息管理系统而与相应的关系数据库系统打交道。HIS系统的最终用户所看到的数据并不是关系数据库系统所存贮的原始数据，而是经过HIS信息管理系统进行翻译之后的数据。

软件互操作中的数据是来源于成千上万家机构的海量数据，如果说软件互操作中的数据都与一定的信息系统有非常高的耦合度，那么要处理大数据，就需要编写数量庞大的应用程序。

1. 事物分类：信息系统名、数据库名、表名

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

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

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

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

对软件互操作而言每个数据都必须满足如下条件才能让各种上各样的用户都能看懂数据的真实含义：

首先需要标有“数据的拥有者”【例如：XXX医院】【关系数据库中根本不考虑此问题，“数据拥有者”是唯一的，用户都知道的。】

然后是该数据属于哪个信息系统【例如：电子病历系统，关系数据库中根本不考虑此问题】

第三是：“表名”【例如：患者基本情况】【在关系数据库中基本上是以英文字母来表达，而不是准确的、标准的自然语言。】

在软件互操作环境中，系统名（例如电子病历系统、PACS系统）、数据库名、表名都是非常有用的数据，而在关系数据库中，这些数据都“缺省”了，或者是用代码来表达。

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

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

在独立数据库中，是不是同一类数据，则是由“事物特征”和“事物特征值”而确定的，具有相同的“事物特征”和“事物特征值”的事物就是同一类事物。即使数据在数百万个信息系统中，只要具有同的“事物特征”和“事物特征值”的事物就是同一类事物。数据的分类完全是由事物本身的特征及特征值确定的，与数据库系统无关，与应用程序无关，与数据结构无关。这种观念来源于人的大脑的超级高保数据处理技术，这样做的目的也是为了实现“用数据来处理数据”。

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

1. 字段名：不用代码，用标准的自然语言

关系数据库的设计者在设计表的字段名时习惯于用英文缩写、汉语拼音缩写，由此而带来的恶果就是：表中的数据只有数据库的设计者才能看懂，不懂技术的普通用户看不懂。表中的数据需要通过大量的应用程序的翻译才能让普通用户看懂，这就是“用程序处理数据”带来的严重恶果。

为了使数据在任何环境中对任何人都是可理解的，独立数据库的策略是以适当的数据冗余为代价，使数据具有独立性、完整性、可识别性。独立数据库的这种策略就是为了实现“用数据处理数据”，从而实现大幅地减少编写程序数量的目的。

软件系统中的数据只是在某个单位内部使用。软件互操作中的数据则是供所有人、任何人使用。在软件系统中，用户都知道数据从何而来（都是本单位的数据，只有一个来源），在软件互操作环境中，数据的来源有成千上万个。在独立数据库中，每一个数据的“字段名”都“必须”用标准的自然语言来表达，一般情况下尽量避免使用代码。其目的就是让每一个数据在任何环境中让所有懂自然语言的人都可以读懂数据的真实含义。

下表中的数据是关系数据库系统中的一张表，由于字段名用的是代码，普通用户就看不懂下表中的数据。

下表中的数据为住院病历中的患者基本情况数据：

在关系数据库的设计人员看来上表中的如下数据都加了数据冗余。

独立数据库中的数据冗余的目的是让每一个数据在任何环境中都具有可识别性，而不用注释，也不必再用程序来解读。

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

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

当前的硬盘的存贮容量与80年代初期相比，已提高了十万倍以上，因此，不必考虑多占用存贮空间的问题，只要使用方便即可。【80年代初期硬盘容量为10M，现在硬盘的容量已2T以上。2T=2000G=2000000M=20万个10M】

1. 数据的独立性

是指数据不依靠数据库系统、不依靠数据结构、不依靠注释、不依靠应用程序而独立地表达出某种含义。关系数据库中的数据不具有独立性，需要借助于注释、数据结构、应用程序才能解读数据的含义。

1. 数据的完整性

是指数据不依靠数据库系统、不依靠数据结构、不依靠注释、不依靠应用程序而完整地表达出某种含义。关系数据库中的数据不具有完整性，需要借助于注释、数据结构、应用程序才能解读数据完整的含义。

1. 数据与系统的耦合度零、零耦合、零关系

数据与系统的耦合度越高，数据对系统的依赖程度就越高。当数据对系统的依赖程度比较高时，数据一旦脱离了原有的系统就变成了无意义的数据。软件互操作中的数据来源于成千上万家单位的系统，因此，软件互操作中的数据应该是与系统的耦合度为零的数据，否则就需要编写很多的应用程度来解读数据，这会增加数据处理的难度、成本。

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

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

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

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

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

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

下面的表为“订单”管理系统中的两张表，“订单表”与“订单明细表”通过“订单ID”而发生联系。

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

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

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

下面的万能数据结构表就是让数据自己通过自己的自然属性而自动地建立联系，而不是用两张表而人为地为数据建立关系。

在下面的PACS系统表中只有门诊或住院号，没有患者身份证号，在软件互操作环境中，门诊或住院号是没有意义的，因为各家医院只是根据自己的情况而编写门诊或住院号，要在软件互操作环境中查询某个患者的PACS数据，就不能通过患者的门诊或住院号而查，只能通过患者的身份证号才能查到。针对下表的这种情况，就需要先从HIS系统中的患者基本信息表中查出患者的身份证号，然后再根据身份证号而查出门诊或住院号，再根据门诊或住院号而从PACS系统表中查出相应的PACS数据。这也是典型的“关系”，这种“关系”为大数据处理增加了很多麻烦。

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

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

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

上面的关系数据库系统中的“订单表”及“订单明细表”之间的关系是人为建立起来的。在独立数据库中，任何表之间都是没有“关系”的，数据之间是否有“关系”不是由表之间的关系来确定，是由数据本身“事物特征”和“事物特征值”是否相同来决定，即数据之间是否有关系完全是由数据本身而决定的，而不是由表与表之间的关系来决定的。这与关系数据库正好相反，关系数据库之所以称作关系数据库就是以“关系”而自豪，而独立数据库就是要坚决地铲除“关系”。

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

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

关系数据库强调的是“关系”，而“独立数据库”所强调的则是坚决铲除“关系”，让各个数据自己独立地、完整地表达出自己的含义。

1. 独立数据库的策略：以数据冗余让数据独立地表达出完整的含义

关系数据库的一个策略是：尽量减少数据冗余。关系数据库在降低了数据冗余的同时却增加了阅读数据的难度。

千年虫就是过渡关注冗余的典型案例。原来人们关注数据冗余的一个原因是硬盘的容量非常低。

独立数据库的策略与关系数据库正好相反。

独立数据库的策略：以适当的冗余而使数据具有独立性、完整性、可识别性，从而使数据可以用它的人读懂，也让计算机能识别，减少编写程序的数量。用数据代替程序，宁愿用十行数据，不用一行程。

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

从表面上看，关系数据库减少了数据冗余，这是其一大优点。然而，这也是关系数据库的最大缺点之一。关系数据库在减少了数据冗余的同时，也导致了数据失真。数据失真的结果就导致：信息交换、信息孤岛、异构数据源等等问题。在关系数据库中，只有通过编写大量的程序，才能解决数据失真问题。

独立数据库的一个原则：基本上不考虑数据冗余问题，以空间换取智能和使用方便，让数据自己说话，而不是让程序替数据说话。

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

“让数据自己说话”就是让数据犹如自然语言那样，能够自己能够准确、无误地表达应有的含义，不需要注释，也不需要应用程序的解读。与30年相比，目前硬盘的存贮容量已提高了10万倍以上，多占据一倍左右的存贮空间的代价很低，可以忽略不计。

1. 超大表问题：分为多张表

从理论上而言，独立数据库只要用一张表就可以存放各种各样的数据。由于当前的数据库系统在存放大量数据时会导致系统性能下降，为解决这个问题，可以把表分为若干个表。

独立数据库并不限制在一个数据库中采用多少张表。然而，无论用多少张表，一定要使这些表的结构完全相同，只有这样，才能确保互联互通，确保数据可以随意地移植到其它系统中。

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

1. 集群：需要由多个系统所组成的集群共同发挥作用才能产生效果

当前的系统全都是孤岛系统。

在数据共享交换中，需要由多个系统所组成的集群（详情可百度“契约数据流通系统集群”）协同发挥作用才能产生效果，用户身份认证、数据流通痕迹都需要公证的第三方的参与才能实现。这是目前的孤岛型软件设计理论体系所不能实现的。

1. 万能查询

利用万能数据结构表存储数据的一个非常突出优势就是可以实现万能查询。只要对万能数据结构表中的“事物代号、事物属性、事物属性值、时间”进行索引，就可以实现万能查询，即可以编写出一种通用的查询程序而实现对数据中的除了“超长属性值、附件”之外的所有数据的精确查询，这是关系数据库所做不到的。

1. 总结

万能数据结构表可以有效地解决数据共享交换中多源异构数据问题。说可以在关系数据库以万能数据结构表实现独立数据库，但以万能数据结构表所存储的数据已不是关系数据库。独立数据为库中的数据的复杂程度要远高于关系数据库中的数据，具有很多与关系数据库完全不同新特性，这需要通过大量的实践才能体会到其奥妙。万能数据结构表、数据集装箱、独立数据库作为新生事物有其有利的一面，也会存在一定的问题，刚开始使用时肯定会有些不适应，这是正常的。

独立数据库是一门与关系数据库完全不同的新型数据库理论，适用于存储处理无限数量的软件系统、无限数量的用户、无限数量的结构化数据之间的共享交换。本文只是抛砖引玉地介绍了其中的部分功能，还有很多新的功能需要开发。

作者：269779216@qq.com