分层领域模型query对象_通过分层，关系和面向对象的模型将XML置于上下文中

分层领域模型query对象

XML是一种极其通用的数据传输格式，但是尽管人们对其寄予厚望，但XML作为一种数据存储和访问格式却平庸无奇。 现在不是时候抛弃您的（SQL）关系数据库，这些关系数据库已经过调整，可以快速，可靠地查询复杂数据。 那么，XML与关系数据模型之间的关系又是什么呢？ 更具体地说，对于同时使用XML和关系数据库的项目以及在两者之间进行数据转换的最佳设计方法是什么？ 本专栏讨论计算机科学家概念化的数据模型抽象理论如何帮助我们开发特定的多表示数据流。 以后的专栏文章将探讨有助于过渡的特定代码和工具； 本专栏讨论设计注意事项。

资料模型

通过讨论抽象数据模型，让我稍等一下。 在特定项目要求的级别上，许多工作涉及到良好数据库设计的细节。 我对比需求更通用的东西感兴趣：我对数据建模范例感兴趣。

在广泛的主题中，数据库管理系统（DBMS）历来属于三种类型：分层，关系和面向对象。 一般来说，分层数据库是在1960年代兴起的，当时是大型机数据处理技术。 网络数据库类似于分层数据库 ，但是它们允许多个父/子关系。 1970年代，EF Codd和其他人进行了严格的数学工作，创建了如今无处不在的关系数据库模型。 在1980年代-很大程度上是由于面向对象编程的日渐普及-对象数据库获得了一定程度的普及，特别是对诸如多媒体格式之类的所谓丰富数据进行建模时。

当前，关系数据库管理系统（RDMS）仍然是大型系统的主要数据存储技术。 层次数据库和对象数据库满足了细分市场的需求。 但是，多年来，许多流行的DBMS都是混合对象关系的。 因此，在实践中，数据模型范式之间的某些界限已经模糊。

层次模型

在分层数据库（HDBMS）中，从严格定义的数据节点树开始。 每个节点可以包含一些标识数据，以及一组特定子类型的子节点。 子节点的数量可以在同一级别的兄弟节点之间变化，但是所有“表兄弟”的类型相同。 图1说明了这些关系。

图1.假设的分层数据库模型

在分层数据库中，数据访问在结构上是完全可以预见的。 因此，DBMS可以高度优化检索和更新。 例如，在如图所示的模型中，您可以使用伪查询语法来确定特定书籍的发行人，其中包括：

Programming/C.J.Date/An Introduction to Database Systems/Publisher?

诸如清单1中的查询之类的任何查询都有到指定数据的精确路径，DBMS可以使用平衡树和字节偏移编码快速确定该数据。 您将以完全相同（唯一）的形式（关于类别，作者等）来查询关于任何书籍的出版商的信息。 为了继续假设的DBMS，您可以使用清单2中的类似Python的伪代码编写更通用的过程查询。

for book in get_children("Programming/C.J.Date"):
    print book.field("Title"), book.field("Publisher")

至此，XML程序员可能已经注意到伪查询语法看起来很像XPath（XML路径语言），而过程伪代码看起来也很像DOM（文档对象模型）。 在我带您介绍更多模型时，请记住这一点。

关系模型

关系数据库由一组表组成，其中每个表由固定的列集合（也称为字段 ）组成。 每个表中出现不确定数量的行 （或记录 ）。 但是，每一行必须具有唯一的主键 ，这是该特定数据束的一种名称。 图2说明了关系数据库的结构（与分层示例大致覆盖相同的数据）：

图2.假设的关系数据库模型

除了具有主键外，表通常还具有一些辅助键。 辅助键与其他表中的主键相对应。 例如，在图2中，BOOKS表具有辅助键AuthorID和PubID。 这些反过来又用作AUTHORS和PUBLISHERS表的主键。 这里的想法是，每个BOOKS行都有一个不同的ISBN值，每个AUTHORS都有一个唯一的AuthorID，每个PUBLISHERS都有一个唯一的PubID。

作为对表之间关系的约束，您可以声明，例如，要使BOOKS中存在一行，则PUBLISHERS中必须存在一行，并且要在BOOKS中使用PubID。 如果一个出版商可以通过这种方式“拥有”多本图书，则称为一对多关系。 另一方面，如果一个作者可以有多本书，而一本书也可以有多位作者，则称为多对多关系。 为了解决问题，您还可以定义一对一关系，其中一个主键必须与一个辅助键完全匹配。 RDBMS的职责就是仅执行这些类型的规则。

在关系数据库中，表的设计可能非常复杂，涉及微妙的决策。 设计中的主要问题是表格的正确规范化 。 规范化的目标-浓缩规范化的第一个到第五个“形式”-消除数据存储方式中的所有冗余。 每个非关键数据应仅位于一个地方。 这个目标几乎可以在层次数据库中自动完成，但是需要在关系数据库中完成。 例如， 图2中所示的示例可能存在归一化问题。 如果书籍可以有多个作者，那么数据库可以在哪里存储第二个作者？ 唯一的实际选择是在BOOKS中创建一个额外的行。 但是，如果这样做，则需要重复相同的PubID，日期和标题，以提及第二个作者。 这不仅需要额外的存储空间，而且如果标题在行之间不完全匹配，则有可能引入错误。 为了解决这个问题，您需要重新考虑设计，这可能涉及创建更多的表和关系。

与分层模型相比，关系模型非常复杂。 但是随着复杂性的发展，功率的巨大增加。 基本上，您可以问任何有关RDBMS的问题，但是对于HDBMS，您只能问系统中设计的问题。 例如，假设您想知道什么作家出生于1970年以后。在如上所示的HDBMS中，唯一的发现方法是对每个书叶节点的搜索都非常昂贵。 通过RDBMS，您可以使用直接SQL查询，如清单3所示。

SELECT AuthorName FROM AUTHORS WHERE AuthorBDay > 1970

对于更复杂的问题，您必须连接多个表，但是规范化可以使您以复杂的方式进行操作。 例如，上面的通过Random House发表的作者可能会被询问为：

SELECT AuthorName
FROM AUTHORS a, BOOKS b, PUBLISHERS p
WHERE AuthorBDay > 1970
  AND a.AuthorID = b.AuthorID
  AND b.PubID = p.PubID
  AND p.Publisher = "Random House"

清单4中的查询说明了您想要保留的几个关系。 可以将其视为表上的筛选器，每个筛选器都会缩小搜索范围。 RDBMS可以根据需要在内部实现这些功能，但可以设想以下步骤（以与指定查询相反的顺序；但是查询条件可以按任何顺序发生）：

1. 将发布者缩小为仅“随机数屋”（公开ID 03-4472822）
2. 只考虑具有匹配PubID的BOOKS
3. 从这些认为的BOOKS行中获取AuthorID的列表
4. 在具有考虑到的AuthorID的AUTHORS行中，确定有多少行具有正确的AuthorBDay

清单4之类的查询的问题在于，它需要许多步骤，其中一些步骤可能会占用大量资源。 即使在HDBMS中容易完成的事情在RDBMS中也可能相对困难。 但是，在HDBMS中非常困难的事情（除了极少数情况之外，其他都很少）在RDBMS中只是中等难度。

对象数据库模型

对象数据库（ODBMS）在某些方面可以追溯到分层模型。 ODBMS中的对象（非常类似于面向对象的编程语言中的对象）是数据和行为的捆绑。 从这个意义上讲，对象类似于HDBMS的分支节点，它们同样包含一堆子节点。

对象数据库有两个独特的功能：

• 对象可以是异构的，并且每个对象包含不同的“拥有”数据集合
• 对象可以包含一些固有的“智能”

这些功能中的每一个都需要简要阐述。 与其他模型一样，请先看一下图（图3）。

图3.假设对象数据库的模型

ODBMS中的异构对象允许每个数据包包含所需的内容。 为了帮助您想象一下，请扩展示例数据库：现在，它不仅是图书馆的书籍记录。 图3描绘了一个实际的在线图书馆，其内容从数据库中传递出去。 不同的媒体（录音，电子文本，电影等）需要不同的描述性信息（并包含不同的内容比特流）。 已知的ObjectID指向每个对象，但是该对象没有像HDBMS那样具有严格统一的子节点集。

因为ODBMS中的对象可以包含各种属性和数据，所以查询对象通常是通过一组方法来执行的。 每个对象都以适合自己的方式实现这些方法。 在图3给出的示例中，两种方法可能是“汇总”和“运输”。 书的摘要可能是其摘要，而电影的摘要可能是预告片。 每个对象都有必要的智能才能知道哪种是总结自身的相关方法。 考虑对象“智能”的另一种方式是根据其携带的元数据。

在对象数据库管理组（ODMG）已经提出了ODBMSs的标准查询语言称为OQL（参见相关主题 ）。

那么XML适合哪里呢？

正如已经熟悉XML的读者会拼凑起来的那样，XML是一种混合形式。 XML可能与数据建模中的对象数据库最相似，因为它也由节点组成，并且节点可以包含异构数据。 另一方面，节点的异构程度很大程度上取决于用于定义XML文档结构的特定DTD或模式。 在XHTML或DocBook之类的东西中，几乎任何元素都几乎可以出现在任何地方都只是一点点夸张。 但是在更加面向数据记录的DTD中，XML文档可能像分层数据库一样严格。 作为一种传输格式，仅给定正确的DTD /模式，XML足够丰富，可以完全表示对象或层次结构。

XML在表示关系数据库方面不太自然。 但是，我应该对这里的“不太自然”一词保持精确。 XML当然能够充分表示RDBMS中的任何内容。 您可以直接表示每个表，尽管比实际的RDBMS更为冗长。 例如，您可能会建议清单5中的DTD代表示例数据库中的BOOKS表。

<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT BOOKS (BOOK*)>
<!ELEMENT BOOK (ISBN,AuthorID,PubID,Date,Title)>
<!ELEMENT ISBN (#PCDATA)>
<!ELEMENT AuthorID (#PCDATA)>
<!ELEMENT PubID (#PCDATA)>
<!ELEMENT Date (#PCDATA)>
<!ELEMENT Title (#PCDATA)>

您可以使用模式进行更丰富的键入，但要点是，将特定的RDBMS表表示为XML并不困难。

同样，您可以同样容易地用XML表示您可能执行的任何特定联接（如清单3和清单4中SQL示例所示 ）。 实际上，表示查询结果是RDBMS的XML的最大和最普遍的用法。 特定的联系人或请求者通常不需要整个数据集，而只需要其中的某些特定过滤和结构化部分。 与本专栏中的示例相比，SQL中的GROUP BY和SORT子句允许更多的结构化，但是XML节点层次结构也可以表示其结果。

对于许多无处不在的XML需求（和仅XML），问题在于RDBMS的核心是关系 ，尤其是表之间存在的一组约束。 强制约束是使RDBMS如此有用和强大的原因。 虽然可以肯定地用XML表示约束集以进行通信，但是XML没有内在的机制来执行这种约束（DTD和模式是另一种更为有限的约束）。 没有约束，您只有数据，而没有数据模型（稍微简化了事情）。

一些XML支持者主张将RDBMS类型的约束添加到XML中。 其他人建议以某种深入的方式将XML内置到RDBMS中。 我认为这些都是非常糟糕的想法，它们的产生主要源于“流行语顺从”的思维方式。 主要的RDBMS供应商花费了多年的精力来正确处理关系事务，尤其是以最大化性能的方式进行正确处理。 您不能仅对XML表示中的一组可靠且可靠的关系约束进行快速处理，而这些约束实际上更接近于不同的建模范例。 而且，从本质上讲，XML的冗长性和格式宽松性与RDBMS用来最大化性能（以及在较小程度上的可靠性）的策略相反，例如固定记录长度和紧凑存储格式。 换句话说，请继续对XML的通用数据传输机制的承诺感到兴奋，但是将后端数据保留在为它设计的东西上，例如DB2或Oracle（或者在较小规模的系统上在Postgres或MySQL上）。

---

翻译自: https://www.ibm.com/developerworks/xml/library/x-matters8/index.html

分层领域模型query对象