html文档半结构化数据,半结构化数据

和普通纯文本相比，半结构化数据具有一定的结构性，OEM(Object exchange Model)是一种典型的半结构化数据模型。

中文名

半结构化数据

外文名

semi-structured data特    点

具有一定的结构性

类    型

数据库

半结构化数据概念

编辑

半结构化数据(semi-structured data)。在做一个信息系统设计时肯定会涉及到数据的存储，一般我们都会将系统信息保存在某个指定的关系数据库中。我们会将数据按业务分类，并设计相应的表，然后将对应的信息保存到相应的表中。比如我们做一个业务系统，要保存员工基本信息：工号、姓名、性别、出生日期等等；我们就会建立一个对应的staff表。

但不是系统中所有信息都可以这样简单的用一个表中的字段就能对应的。

半结构化数据地位

半结构化数据(semi-structured data)模型在数据库系统中有着独特的地位：

(1)它是一种适于数据库集成的数据模型，也就是说，适于描述包含在两个或多个数据库(这些数据库含有不同模式的相似数据)中的数据。

(2)它是一种标记服务的基础模型，用于Web上共享信息。[1]

半结构化数据必要性

E/R、UML、关系模型、ODL，每个都是以模式开始。模式是一种放置数据的严格框架。这种严格性提供了某些优点。特别的，关系模型的成功在于它的高效实现。这种高效性来自于关系数据库中的数据必须符合其模式并且该模式为查询处理器所知这一事实。[1]

另一方面，对半结构化数据模型感兴趣的动机主要是它的灵活性。特别的，半结构化数据是“无模式”的。更准确地说，其数据是自描述的。它携带了关于其模式的信息，并且这样的模式可以随时间在单一数据库内任意改变。[1]

人们可能很自然地想知道无模式地创建数据库是否存在优点，在这样的数据库中，可以随意的输入数据，并且访问该数据时你感觉到的模式信息就是适合它的模式。实际上有一些小规模的信息系统，如Lotos Notes，它们就采用了自描述数据的方法。这种灵活性可能使查询处理更加困难，但它给用户提供了显著地优势。例如，可以在半结构化模型中维护一个电影数据库，并且能如用户所愿地添加类似“我喜欢看此部电影吗？”这样的新属性。这些属性不需要所有电影都有值，或者甚至不需要多于一个电影有值。同样的，可以添加类似“homage to”这样的联系而不需要改变模式，或者甚至表示不止一对的电影间的联系。[1]

半结构化数据数据分类

编辑

结构化数据

就像上面举的例子。这种类别的数据最好处理，只要简单的建立一个对应的表就可以了。

非结构化数据

像图片、声音、视频等等。这类信息我们通常无法直接知道他的内容，数据库也只能将它保存在一个BLOB字段中，对以后检索非常麻烦。一般的做法是，建立一个包含三个字段的表(编号 number、内容描述 varchar(1024)、内容 blob)。引用通过编号，检索通过内容描述。还有很多非结构化数据的处理工具，市面上常见的内容管理器就是其中的一种。

半结构化数据

这样的数据和上面两种类别都不一样，它是结构化的数据，但是结构变化很大。因为我们要了解数据的细节所以不能将数据简单的组织成一个文件按照非结构化数据处理，由于结构变化很大也不能够简单的建立一个表和他对应。本文主要讨论针对半结构化数据存储常用的两种方式。

先举一个半结构化的数据的例子，比如存储员工的简历。不像员工基本信息那样一致每个员工的简历大不相同。有的员工的简历很简单，比如只包括教育情况；有的员工的简历却很复杂，比如包括工作情况、婚姻情况、出入境情况、户口迁移情况、党籍情况、技术技能等等。还有可能有一些我们没有预料的信息。通常我们要完整的保存这些信息并不是很容易的，因为我们不会希望系统中的表的结构在系统的运行期间进行变更。

半结构化数据储存方式

编辑

化解为结构化数据

这种方法通常是对现有的简历中的信息进行粗略的统计整理，总结出简历中信息所有的类别同时考虑系统真正关心的信息。对每一类别建立一个子表，比如上例中我们可以建立教育情况子表、工作情况子表、党籍情况子表等等，并在主表中加入一个备注字段，将其它系统不关心的信息和一开始没有考虑到的信息保存在备注中。

优点：查询统计比较方便。

缺点：不能适应数据的扩展，不能对扩展的信息进行检索，对项目设计阶段没有考虑到的同时又是系统关心的信息的存储不能很好的处理。

用XML格式来组织并保存到CLOB字段中

XML可能是最适合存储半结构化的数据了。将不同类别的信息保存在XML的不同的节点中就可以了。

优点：能够灵活的进行扩展，信息进行扩展式只要更改对应的DTD或者XSD就可以了。

缺点：查询效率比较低，要借助XPATH来完成查询统计，随着数据库对XML的支持的提升性能问题有望能够很好的解决。

半结构化数据特征

编辑

半结构化数据中结构模式附着或相融与数据本身，数据自身就描述了其相应结构模式。具体来说，半结构化数据具有下述特征：

(1)数据结构自描述性。结构与数据相交融，在研究和应用中不需要区分“元数据”和“一般数据”(两者合二为一)。

(2)数据结构描述的复杂性。结构难以纳入现有的各种描述框架，实际应用中不易进行清晰的理解与把握。

(3)数据结构描述的动态性。数据变化通常会导致结构模式变化，整体上具有动态得结构模式。[2]

常规的数据模型例如E-R模型、关系模型和对象模型恰恰与上述特点相反，因此可以成为结构化数据模型。而相对于结构化数据，半结构化数据的构成更为复杂和不确定，从而也具有更高的灵活性，能够适应更为广泛的应用需求。[2]

半结构化数据表示

编辑

半结构化数据的数据库是节点的集合，每个节点都是一个叶子节点或者一个内部节点。叶子节点与数据相关，数据的类型可以是任意原子类型，如数字和字符串。每个内部节点至少有一条外向的弧。每条弧都有一个标签，该标签指明弧开始处的节点与弧末端的节点之间的关系。一个名为根的内部节点没有进入的弧，它代表整个数据库。每个节点都从根可达，尽管这个图结构未必是一棵树。[1]

半结构化数据通常是由一个由节点集合和弧段集合组成的具根有向图结构。有向图中节点集合元素分为三类：

(1)叶结点。此类节点没有由其出发的弧段，其语义表示与实际数据相关，相应数据取值类型可以是任意原子类型(数值型或字符串型)。

(2)内部节点。此类节点既有由其出发又有由其终止的弧段。

(3)根节点。此节点唯一，其特征是只作为一个或多个弧段的始点，其语义是整个数据文件。[2]

半结构化数据模型

编辑

半结构化数据模型允许那些相同类型的数据项有不同的属性集的数据规格说明。这和早先提到的数据模型形成了对比：那些数据模型中某种特定类型的所有数据必须有相同的属性集。[3]

对象交换模型是一个半结构化数据模型。对象由一个三元组表示，包括标记、类型和对象的值。在对象交换模型中，对象具有唯一的标识。由于模型中对象的标识可以看做关系模型中的属性名，对象的类型可以看做关系模型中的属性类型，所以对象交换模型基本上是自描述的。对象交换模型中的标记尽可能地详尽，因为标记除了能够表达对象的含义外，还可以用来确定特定的对象。[4]

参考资料

1.

(美)JEFFREYD.ULLMAN，JENNIFERWIDOM编著．数据库系统基础教程．北京：由机械工业出版社，2009：289-295

2.

叶小平，汤庸，汤娜，潘明编著．数据库系统教程 第2版．北京：清华大学出版社，2012：314-317

3.

(美)西尔伯沙茨(Silberschatz,A.)，(美)克尔斯(Korth,H.F.)，(美)苏达山(Sudarshan,H.)著 杨冬青等译．数据库系统概念 第5版．北京：机械工业出版社，2006：12-12

4.

[美]罗摩克希纳 [美]格尔克著．数据库管理系统(第2版)．北京：清华大学出版社，2002：497-498