Download PDF version of this article PDF

为什么你的数据无法混合

新的工具和技术可以帮助缓解协调模式的痛苦。

ALON HALEVY，华盛顿大学

当独立的各方为同一领域开发数据库模式时，它们几乎总是彼此截然不同。这些差异被称为语义异构性，它也出现在多个 XML 文档、Web 服务和本体中——或者更广泛地说，只要存在多种结构化数据体的方式时就会出现。半结构化数据的出现加剧了语义异构性，因为半结构化模式一开始就更加灵活。为了使多个数据系统相互协作，它们必须理解彼此的模式。如果没有这种理解，大量的数据源就相当于数字版的巴别塔。

本文首先回顾了在构建数据共享应用程序中，解决语义异构性至关重要的几个常见场景。然后，我们解释了为什么解决语义异构性很困难，并回顾了解决该问题的一些最新研究和商业进展。最后，我们指出了该领域的关键问题和机遇。

语义异构性的场景

企业信息集成。 如今，企业正日益面临数据管理挑战，这些挑战涉及访问和分析驻留在多个来源的数据，例如数据库系统、遗留系统、ERP 系统以及 XML 文件和提要。例如，为了使企业获得“客户的单一视图”，它必须接入多个数据库。同样，为了呈现其数据的统一外部视图，无论是与第三方合作还是创建面向外部的网站，企业都必须访问多个来源。随着电子市场的日益普及，这些挑战正成为许多组织中的瓶颈。

企业数据以看似随意的方式驻留在多个来源中，原因有很多。首先，许多数据系统是为满足特定的业务需求而独立开发的，但是当业务需求发生变化时，需要在组织的不同部分之间共享数据。其次，企业通过合并和收购获得许多数据源。

多年来，已经有多种方法来解决 EII（企业信息集成）挑战。直到 20 世纪 90 年代末，两种主要方法是数据仓库和构建自定义解决方案。数据仓库解决方案的缺点是在许多情况下访问的是过时的数据，并且无法跨企业边界工作。自定义代码解决方案昂贵、难以维护且通常不可扩展。

在 90 年代后期，一些公司提供了实时查询多个数据源的解决方案。事实上，术语 EII 通常指的是这些解决方案。虽然这些系统的用户仍然看到单个模式（无论是关系型还是 XML），但查询会动态地转换为对各个数据源的适当查询，并且结果会从源获得的局部结果中适当地组合。因此，返回给用户的答案始终基于最新数据。有趣的是，这些公司中的几家都在 XML 平台上构建了他们的产品，因为 XML 的灵活性（以及更广泛的半结构化数据）使其更适合数据集成应用程序。最近的一篇文章调查了该行业面临的一些挑战。1 最近的研究提出了用于共享具有丰富结构和语义的数据的对等架构。2

在任何这些数据共享架构中，协调语义异构性都是关键。无论查询是动态发出、数据加载到数据仓库中，还是通过 Web 服务或以对等方式共享数据，都需要协调数据源之间的语义差异。通常，这些差异通过语义映射来协调。这些表达式指定如何将数据从一个数据源转换为另一个数据源，以保留数据的语义，或者可替代地，将在一个源上提出的查询重新表述为对另一个源的查询。语义映射可以使用多种机制来指定，包括 SQL 查询、XQuery 表达式、XSLT 脚本或 Java 代码。

在实践中，关键问题是指定语义映射所需的工作量。在典型的数据集成场景中，超过一半的工作量（有时高达 80%）花费在创建映射上，并且该过程是劳动密集型且容易出错的。如今，大多数 EII 产品都附带一些用于指定这些映射的工具，但这些工具完全是手动的——专家需要指定两个模式之间的确切映射。

查询和索引深层网络。 深层网络指的是驻留在数据库中并通过表单访问的 Web 内容。搜索引擎通常不索引深层网络内容，因为这些引擎使用的爬虫无法通过表单。从某种意义上说，表单可以被视为（通常很小的）模式，除非爬虫能够理解表单中字段的含义，否则它就会卡在那里。

深层网络内容的数量和价值令人叹为观止。据一些估计，深层网络上的内容比表层网络上的内容多一到两个数量级。此类内容的示例范围从全球数千家报纸的分类广告，到政府数据库、产品数据库、大学知识库等等。

同样，这里的挑战也源于 Web 站点设计人员对给定领域各方面进行建模的方式非常多样化。因此，Web 爬虫的设计人员不可能在爬网时假设某些标准表单字段名称和结构。即使在搜索二手车这样的简单领域中，表单的异构性也令人惊叹。当然，主要挑战来自问题的规模。例如，网站 www.everyclassified.com 是第一个聚合来自数千个基于表单的来源的内容的网站，它在分类广告的常见类别中包含 5,000 多个 Web 表单的语义映射。在本文的后面，我们将描述使该网站成为可能的想法。

重要的是要强调，对于内容提供商而言，访问深层网络甚至比对于搜索引擎而言更具挑战性。内容提供商靠吸引用户的注意力而蓬勃发展。在万维网的早期，任何好的数据库都会立即为人所知（例如，IMDb 用于电影）。然而，如今此类数据库的数量巨大（估计有数十万个），人们对此一无所知。相反，人们的搜索从他们最喜欢的引擎的搜索框开始，而这些引擎在索引深层网络内容方面做得不好。因此，如果我创建一个关于中东食谱的优秀数据库并将其放在 Web 上，放在表单后面，它可能会仍然不可见。具有讽刺意味的是，我最好创建一组包含我的食谱内容的网页，而不是创建一个易于搜索的数据库。最后，应该注意的是，企业搜索也面临着类似的问题：企业内许多有趣的数据源都在数据库中，即使提供对此内容的简单关键字搜索也具有挑战性。

商家目录映射。 语义异构性的一个例子发生在聚合产品目录中。以亚马逊 (Amazon.com) 等在线零售商为例。此类零售商接受来自数千家商家的产品提要，每家商家都试图在线销售其商品。为了聚合大量提要，在线零售商规定了一个模式：产品及其相关属性的层次结构。为了在线销售他们的产品，商家需要发送符合规定模式的提要。然而，在后端，商家的数据存储在本地模式中，该模式可能与零售商规定的模式有很大不同（并且通常只涵盖该模式的一小部分）。因此，问题是在数千家商家和越来越多的公认在线零售商（此时在美国大约有 10 家）之间创建映射。

关于此场景，需要注意的一个有趣的点是，从商家的模式到零售商的模式不一定存在唯一的正确语义映射。相反，由于产品类别之间存在细微的差异，并且产品通常可以映射到多个类别，因此可能存在多个有意义的映射——而最好的映射是最终销售更多产品的映射。

模式与数据异构性。 异构性不仅发生在模式中，而且发生在实际数据值本身中。例如，可能有多种方式引用同一产品。因此，即使你被告知商家数据中的特定字段映射到 ProductName，这可能不足以解决对单个产品的多个引用。作为其他常见示例，通常有多种方式引用公司（例如，IBM 与 International Business Machines）、人名（通常不完整）和地址。为了完全集成来自多个来源的数据，需要处理语义级别和数据级别的异构性。通常，不同的产品分别解决了这两个部分的问题。作为一个例子，一些用于“全球支出分析”的产品专注于数据级别的异构性。本文主要关注模式异构性。

模式异构性和半结构化数据。 当我们处理半结构化数据时，语义异构性问题会加剧，原因有几个。首先，涉及半结构化数据的应用程序通常是在多个参与方之间共享数据的应用程序；因此，语义异构性从一开始就是问题的一部分。其次，半结构化数据的模式更加灵活，因此我们更有可能看到模式的变化。最后，半结构化数据的主要优势在于可以随意将属性添加到数据中（甚至只是从检查数据本身中派生出来），并且一旦这种灵活性到位，我们看到的附加属性的数量就非常可观，并且理解它们的确切含义变得至关重要。另一方面，在许多涉及半结构化数据的应用程序中，仅需协调一组特定的属性就足够了，而我们仍然可以操作和显示任何其他属性。具体而言，我们只需要协调那些将用于跨多个来源等同数据的属性。

为什么如此困难？

协调模式异构性的问题已经成为数十年的研究课题，但解决方案很少。使语义异构性如此困难的根本原因是数据集是独立开发的，因此使用了不同的结构来表示相同或重叠的概念。在许多情况下，我们试图集成为略有（或大相径庭）不同的业务需求而开发的数据系统。因此，即使它们对重叠领域进行建模，它们也会以不同的方式对其进行建模。不同的结构是人性的副产品——即使面对相同的建模目标，人们也会彼此不同地思考。作为一个简单的说明，我在我的高年级数据库课程中给出的作业之一是根据关于其应涵盖内容的单页英语描述设计库存模式。我从学生那里获得的模式总是截然不同。3

从实践的角度来看，模式异构性困难且耗时的原因之一是它既需要领域专业知识又需要技术专业知识：你需要了解要协调的每个模式的业务含义的人员，以及精通编写转换（例如，SQL 或 XQuery 专家）的人员。

虽然模式异构性对人类来说具有挑战性，但对程序来说却更具挑战性。程序仅获得要协调的两个模式，但这些模式仅仅是符号。它们没有捕捉到模式的全部含义或意图——这些只存在于设计者的脑海中。

图 1 说明了解决语义异构性的一些挑战。该图显示了一个典型的手动模式匹配工具，设计人员需要在两个模式的匹配属性之间绘制线条。正如在示例中可以看到的那样，模式之间存在几种语义差异：1. 两个模式中的相同模式元素被赋予不同的名称（例如，IssueDate 和 OrderIssueDate）；2. 模式中的属性以不同的方式分组到表结构（或 XML 嵌套）中（例如，考虑两个模式中 BuyerParty 元素的子树）；以及 3. 一个模式可能涵盖另一个模式未涵盖的领域方面（例如，左侧模式没有任何类似于右侧模式中的 OrderSummary 的内容）。

当协调来自数千个 Web 表单的异构性时，还存在其他异构性来源。某些表单已经专门用于特定领域（二手车、职位），而在其他表单中，用户需要在输入其他属性之前选择一个类别。在某些情况下，位置已经隐含在表单中（例如，使用某些隐藏字段），而在其他情况下，用户需要选择城市和州或邮政编码。

有些人认为解决语义异构性的方法是通过标准模式。然而，经验表明，标准化的成功有限，并且仅在就标准达成一致的激励非常强烈的领域中才取得成功。即使这样，正如在线零售商示例所示，虽然数据提供商可能会使用标准共享其数据，但他们自己的数据系统仍然使用其原始模式（并且更改这些系统的成本高昂）。因此，需要在数据提供商向其同行公开数据的步骤中解决语义异构性。

当考虑解决模式异构性时，重要的是要注意问题的几个常见实例，这些实例可能会阐明手头的具体问题

现有技术水平

解决模式异构性本质上是一个启发式、人工辅助的过程。除非对你要协调的两个模式彼此不同的方式有非常强的约束，否则不应期望完全自动化的解决方案。目标是减少人类专家在模式对之间创建映射所需的时间，并使他们能够专注于映射中最困难和最模糊的部分。例如，使 www.everyclassified.com 网站得以构建的工具要求我们能够平均在一分钟内将 Web 表单的字段映射到我们自己的模式。

正如预期的那样，人们尝试通过使用各种启发式方法来构建半自动化的模式匹配系统。4 协调语义异构性的过程通常涉及两个步骤。第一步称为模式匹配，我们找到两个模式的元素对（或更大的集合）之间的对应关系，这些元素对指的是现实世界中相同的概念或对象。在第二步中，我们基于这些对应关系来创建实际的模式映射表达式。IBM Almaden 的 Clio 项目是构建映射表达式工作的典范。5

以下几类启发式方法已用于模式匹配

新兴的解决方案：利用过去的经验

此处描述的模式匹配解决方案脆弱的根本原因之一是它们仅利用存在于正在匹配的两个模式中的证据，而忽略了过去的经验。这些模式通常缺乏足够的证据来发现匹配项。然而，更仔细地观察模式匹配任务，很明显这些任务通常是重复性的。具体而言，我们经常发现我们反复将同一领域中的模式映射到公共的调解模式中。例如，在 www.everyclassified.com 上创建引擎涉及将同一领域中的数千个 Web 表单映射到公共模式，即引擎本身向用户公开的模式。人类专家在看到特定领域中的许多模式后，能够更快地映射模式，因为他们已经看到了该领域中的概念如何在模式中表示的许多变体。

因此，挑战在于赋予模式匹配器相同的功能：利用过去的经验。例如，一旦系统获得了二手车领域中的几个映射，它就应该能够预测它以前未见过的模式的映射。随着它在特定领域中看到更多模式，它的预测应该变得更准确，并且在存在变化的情况下应该更健壮。

在过去的几年中，在几个学术研究环境中探索了这一想法9,10,11,12,13，并且最近首次由 www.everyclassified.com 的创建者 Transformic Inc. 在商业上应用。研究项目考虑使用机器学习作为一种机制，使模式匹配器能够利用以前的经验。在机器学习中，系统被提供一组训练示例，并使用它们来学习感兴趣领域的模型。在这种情况下，训练示例是由领域专家手动构建并提供给系统的模式映射。领域的模型使系统能够查看新模式并预测模式映射。例如，系统可以学习到关于房屋描述的属性通常涉及长文本，并且包括最高级词的频繁出现。此外，系统可以学习人们在实践中命名此字段的各种方式。

此想法的另一个应用是搜索 Web 服务，即定位与特定需求相关的 Web 服务（或其中的操作）。简单的关键字搜索是不够的，因为关键字（或参数名称）没有捕捉到 Web 服务的底层语义。Woogle 搜索引擎14（可在 www.cs.washington.edu/woogle 获得）基于分析大量的 Web 服务并将参数名称聚类为语义上有意义的概念。这些概念用于预测两个 Web 服务操作何时具有相似的功能。

你可以从过去学习到什么？从执行模式匹配任务的过去经验中学习的范例才刚刚起步。退后一步并考虑在这种情况下可以从过去学习到什么是很有趣的。

我们假设过去以特定领域中的模式集合、该集合中模式对之间的映射以及尽可能多的数据实例的形式提供给我们。模式可以来自任何地方，并且可以涉及密切相关的领域，而不必对相同的数据进行建模。在许多情况下，可以从 Web 或 xml.org 等资源中获得此类模式。在其他情况下，它们可能在整个企业中可用。这样的模式集合通常被称为语料库，类似于信息检索 (IR) 和 Web 搜索引擎中使用的文档语料库。当然，虽然 IR 中的语料库涉及单词集合，但在这里我们管理的是语义更丰富的元素，例如模式及其实例。

分析模式和映射语料库的目标是提供关于更深层领域概念和更精细粒度的提示。更仔细地查看该方法，以下是我们从语料库中学到的一些示例。

领域概念及其表示变体。 作为第一步，我们可以分析语料库以识别领域中的主要概念。例如，在书籍库存模式语料库中，我们可以识别书籍和仓库的概念以及与价格相关的元素集群。更重要的是，我们将发现如何表示这些概念的变体。变体可能在模式元素的命名、将属性分组到表中或对特定概念进行建模的粒度上有所不同。当我们匹配领域中的两个模式时，这些变体的知识将被利用。

概念之间的关系。 给定一组概念，我们可以发现它们之间的关系，以及这些关系在表示中体现的方式。例如，我们可以发现 Books 表通常包括 ISBN 列和到 Availability 表的外键，但 ISBN 从未出现在 Warehouse 表中。这些关系有助于修剪看起来不太可能的候选模式匹配项。它们也可以用于构建在设计新模式时提供建议的系统。

领域约束。 我们可以利用语料库来查找关于领域及其表示的完整性约束。例如，我们可以观察到 ISBN 是涉及书籍的多个表的外键，因此可能是书籍的标识符，或者发现某些字段的可能数据类型（例如，地址、价格）。约束可能与属性的排序有关。例如，在关于待售汽车的 Web 表单语料库中，我们可能会发现品牌属性始终位于型号和价格属性之前，但在新旧属性之后出现。通常，我们以这种方式发现的约束是软约束，因为它们有时会被违反，但仍然可以被视为关于该领域的经验法则。因此，它们在解决模棱两可的情况（例如，在几个候选模式匹配项之间进行选择）时非常有用。

展望未来

在企业内部和跨企业范围内，对灵活数据共享系统的需求才刚刚起步。我们今天拥有的工具远远落后于客户需求。更糟糕的是，我们需要管理的更多数据是半结构化的，并且通常是从非结构化数据中提取结构的结果。因此，我们需要管理值、属性名称和语义通常不确定的数据。

展望未来，存在两个主要的挑战领域：处理规模大得多的模式和处理复杂得多的数据共享环境。在这两个领域，我们可能都必须改变我们的思维方式。

更大的模式和模式搜索。 本文描述的技术处理中小型模式（包括多达数百个元素）。值得称赞的是，这些技术优雅地处理了大量此类模式。众所周知，许多真实世界的模式都有数千个模式元素（表和属性），SAP 模式就是一个典型的例子。创建模式映射的挑战在这里要困难得多：你甚至无法在一个屏幕或多个屏幕上查看整个模式。

两个原则需要指导更大的模式的映射工作。首先，模式匹配工具需要结合先进的信息可视化方法。15 设计大规模模式的模式映射的大部分挑战在于确保设计人员的注意力始终 направлена 到正确的位置，他们可以查看假设的映射并轻松删除它们，并且他们可以有效地看到映射的一个片段如何影响其他片段。系统还应该能够解释为什么做出某些匹配预测。

第二个原则要求改变我们对模式匹配的看法。具体来说，我建议使用模式搜索引擎。该引擎包含特定模式（或模式集）的元素索引集。该引擎将模式元素（例如，表名、属性、XML 标记）、模式片段或模式片段和数据实例的组合作为输入。该引擎返回索引模式中作为候选匹配项的模式元素的排名列表。界面应该像我们今天在搜索引擎中看到的那样简单。这种工具的理由是模式映射中的大部分工作只是在庞大的模式中找到与当前正在考虑的模式部分相关的片段，或者在大型模式集合中找到相关的模式。因此，与其专注于解决整个问题但本质上很脆弱的工具，不如构建强大的工具，使用户更接近他们的需求。先前描述的 Woogle Web 服务搜索引擎就是这样一个引擎的示例，它搜索的是 Web 服务操作而不是模式及其片段。

管理数据空间。 数据管理社区面临的更大挑战是提高数据管理的抽象级别。如今，我们拥有强大的系统，可以在单个数据库系统（无论是关系型、XML 还是其他模型）的级别管理数据。然而，我们面临的数据管理挑战是在更高的级别：我们需要管理数据空间，而不是数据库。

数据空间由一组参与者和一组关系组成。参与者是各个数据源：关系数据库、XML 存储库、文本数据库、Web 服务、数据流系统、传感器部署或任何其他存储或传递数据的元素。一些参与者可能是透明的，具有用于提出查询的完整语言；传统的关系型 DBMS 就是一个典型的例子。其他参与者可能是不透明的——为提出查询提供有限的接口（通常由特定程序支持）；示例是 Web 服务、存储过程和其他软件包。此外，一些参与者的数据可能没有结构（例如，文本）或只有一些结构（例如，代码集合）。数据空间的示例包括：企业、桌面、图书馆、大型科学项目、智能家居或战场。

数据空间应该能够对两个（或多个）参与者之间的任何类型的关系进行建模。在极端情况下，关系是完整的模式映射，支持参与者之间的任意数据交换和查询重构。在其他情况下，关系可以表达简单的依赖关系，其中细节尚不清楚（例如，一个参与者是另一个参与者的演化版本）。关系可以具有时间方面（例如，数据交换的频率），或者具有一个是另一个的镜像或备份。

数据空间管理的关键区别特征在于，集成应该随着时间的推移和根据需要而发展，但数据应该从一开始就可以以某种形式访问。这意味着应该始终在数据空间中的每个参与者上支持简单的查询（例如，关键字查询），而无需任何努力。随着数据空间的所有者希望在源之间创建更紧密的集成并支持跨参与者的更复杂的查询，他们可以根据需要创建更详细的语义映射。此外，数据空间的管理应考虑数据的整个生命周期，包括其获取、管理、查询和更新、演变和分析。关于管理数据空间的初步想法16 才刚刚开始引起研究界的兴趣。到目前为止，从业者已经热情地接受了这个想法。

参考文献

  1. Halevy，A. Y.，Ashish，N.，Bitton，D.，Carey，M.，Draper，D.，Pollock，J.，Rosenthal，A.和Sikka，V.，2005。企业信息集成：成功、挑战和争议。在 SIGMOD 会议论文集中。
  2. Aberer，K. 2003。对等数据管理：特殊问题介绍。SIGMOD Record 32(3)。
  3. Halevy，A. 2003。从第一天起学习数据集成挑战。SIGMOD Record 32(3)：16-17。
  4. Rahm，E.和Bernstein，P.A. 2001。自动模式匹配方法调查。VLDB Journal 10(4)：334-350。
  5. Yan，L. L.，Miller，R. J.，Haas，L. M.和Fagin，R. 2001。数据驱动的模式映射理解和改进。在 SIGMOD 会议论文集中。
  6. Do，H.-H.和Rahm，E. 2002。COMA——用于灵活组合模式匹配方法的系统。在国际超大型数据库会议 (VLDB) 论文集中。
  7. Doan，A.，Domingos，P.和Halevy，A. 2001。协调不同数据源的模式：机器学习方法。在 SIGMOD 会议论文集中。
  8. Madhavan，J.，Bernstein，P.和Rahm，E.，2001。使用丘比特的通用模式匹配。在国际 VLDB 会议论文集中。
  9. 参见参考文献 7。
  10. Halevy，A.，Etzioni，O.，Doan，A.，Ives，Z.，Madhavan，J.，McDowell，L.和Tatarinov，I. 2003。跨越结构鸿沟。在第一届创新数据系统研究双年会议 (CIDR) 论文集中。
  11. He，B.和Chang，K. C.-C. 2003。跨深层网络的统计模式集成。在 SIGMOD 会议论文集中。
  12. Hess，A.和Kushmerick，N. 2003。学习将语义元数据附加到 Web 服务。在国际语义 Web 会议论文集中。
  13. Madhavan，J.，Bernstein，P.，Doan，A.和Halevy，A. 2005。基于语料库的模式匹配。在国际数据工程会议 (ICDE) 论文集中。
  14. Dong，X. L.，Halevy，A. Y.，Madhavan，J.，Nemes，E.和Zhang，J. 2004。Web 服务的相似性搜索。在国际 VLDB 会议论文集中。
  15. Robertson，G. G.，Czerwinski，M. P.和Churchill，J. E. 2005。模式之间映射的可视化。在 SIGCHI 人机交互系统会议论文集中。
  16. Franklin，M.，Halevy，A.和Widom，J. 2005。数据空间：数据管理的新抽象。

致谢

本文中阐述的想法得益于与我的同事和学生的讨论和辛勤工作。特别是，我要感谢 Phil Bernstein、Anhai Doan、Luna Dong、Dana Florescu、Zack Ives 和 Jayant Madhavan。数据空间的愿景是与 Mike Franklin、Dave Maier 和 Jennifer Widom 讨论的智力成果。

阿隆·哈勒维是华盛顿大学的计算机科学教授。他于 1993 年在斯坦福大学获得计算机科学博士学位。他的研究兴趣包括数据集成、语义异构性、个人信息管理、XML 数据管理、网站管理、对等数据管理系统以及数据库和人工智能技术的交叉领域。他是 XML-QL 的共同开发者之一，XML-QL 后来为查询 XML 数据的 XQuery 标准的开发做出了贡献。1999 年，哈勒维共同创立了 Nimble Technology 公司，该公司是企业信息集成领域的首批公司之一。2004 年，他创立了 Transformic Inc. 公司，该公司为深层网络创建搜索引擎。

acmqueue

最初发表于 Queue 杂志第 3 卷第 8 期—
在 数字图书馆 中评论这篇文章




更多相关文章

安德鲁·麦卡勒姆 - 信息抽取
2001 年，美国劳工部受命建立一个网站，以帮助人们查找全国社区学院、大学和组织的继续教育机会。该部门希望其网站支持对地点、日期、时间、先决条件、讲师、主题领域和课程描述进行字段布尔搜索。最终，它还对挖掘其新数据库以获取模式和教育趋势感兴趣。这是一个重要的数据集成项目，旨在每三个月自动从数万个独立机构收集详细的结构化信息。


纳塔莉亚·诺伊 - 从混乱中建立秩序
毫无疑问，过去十年在线信息量呈“爆炸式”增长，可供人类和机器处理。它促成的趋势（还有许多其他趋势）中有两个：第一，与以前存储大部分电子数据的传统集中式关系数据库相比，已经转向更灵活和流动的（半结构化）模型；第二，今天可供处理的信息实在太多了，我们需要机器的帮助。


C. M. Sperberg-McQueen - XML <和半结构化数据>
词汇表设计者可以要求 XML 数据完全规则，或者他们可以允许少量变化，或者大量变化。在极端情况下，XML 词汇表可以有效地表示，除了所有格式良好的 XML 所要求的规则之外，根本没有其他规则。由于 XML 语法仅记录存在的内容，而不是可能存在的所有内容，因此稀疏数据不会使 XML 表示显得笨拙；XML 存储系统通常构建为优雅地处理稀疏数据。


亚当·博斯沃思 - 从网络学习
在过去的十年中，我们看到了计算领域的一场革命，这场革命在范围和影响力方面超越了迄今为止的任何事物，而且也超越了我们对构成“好”和“坏”计算的思考方式。



© 版权所有。

© . All rights reserved.