第4章-3 其他数据模型.ppt

* DTD引用示例 引用上例的DTD必须增加的内容： 属性standalone= “no”表示使用了DTD 当不想为文档指定DTD时，将这个属性设置为“yes” DTD文件的位置在!DOCTYPE子句中给出，保留字SYSTEM后面的文件名就是DTD的位置信息。 * 属性列表 XML文档与半结构化数据之间有密切联系 从XML到半结构化数据：假设对于文档中的标签对T/T创建一个节点n，而对于嵌在T/T中的标签对S/S（S和T之间没有其他嵌套层次），画一条标签为S的从节点n到S标签对的弧，可得到一个本质上与文档结构一致的半结构化数据。 从半结构化数据到XML ：仅用目前介绍的XML知识无法实现 * 从半结构化数据→XML的问题 如果半结构化数据中有多条弧同时指向一个节点，那么这个节点的标签对需要同时嵌套在这些弧的起始标签对中。已经介绍的XML知识实现不了 * 问题的解决 可以使用XML的其他特性来实现：标签内的属性、标识符ID和标识符引用IDREF来共同实现这种复杂嵌套 !ATTLIST 元素名 属性名 类型 !ATTLIST声明了节点元素的属性列表 ID类型的属性为节点提供了唯一的名字，便于引用 IDREF类型的属性是与本节点元素表示内容相关的其它节点元素的ID列表 给标签实例E一个值为v的ID属性，给另一个标签示例F一个值为v的IDREF属性，就可有效地给出一个从E出发到F结束的弧 * 使用属性列表的DTD示例 * 引用DTD的XML示例 ID类型的属性starID IDREFS类型的属性列表starredIn,其值为该影星出演电影的ID列表 本 章 结 束 ！ * (3)方法 ODL中有给出方法的声明 对象关系模型不强调但也为任何类声明及定义方法的能力 * (4)类型系统 面向对象模型和对象关系模型的类型系统相当相似：它们都是在基于原子类型基础上使用结构、集合类型构建器来创建新类型。 集合类型的可选部分可能有些不同，但所有变化都至少包含集合和包。 而且，结构类型的集合(或者包)在两个模型中都扮演着特殊的角色，那就是它们是ODL中的类和对象关系模型中的关系类型。 * (5)引用和对象标识 一个纯粹的面向对象模型使用一个完全对用户隐藏的对象标识，因此该标识不可见并且不能被查询到。 对象关系模型允许类型中包含引用，所以，在有些情况下用户可以见到这些值，甚至可以记住这些值以便在以后使用。 这种情况是好是坏，不能一概而论。在实际中，两个模型基本上没有差别。 * (6)向下兼容性 既然两种模型的差别微乎其微，为什么市场上是对象关系模型而不是纯粹的面向对象的系统占主导地位呢? 原因可能在于，当关系DBMS发展为对象关系DBMS时，开发商总是特别注意向下兼容性。 另一个原因还在于，将一个系统转化为纯面向对象DBMS的工作量巨大。 所以，尽管面向对象系统在技术上更有优势，但还不足以使开发商将大量已有的数据库转换到纯粹面向对象数据库系统上。 * ODL设计到对象关系设计的转化 ODL有很丰富的建模方式：非原子属性类型、联系和方法，因此转化为传统关系模型比较困难，但转化为对象关系模型，某些难点已经不存在： (1)针对不同的对象关系模型，可以将大部分非原子类型转化微一种对应的对象关系类型，如结构、集合、包、链表以及数组。如果一个ODL设计中的类型在对象关系模型中没有对应的类型，则可以使用4.4.2-4.4.4节介绍的技巧进行转化 (2)对象关系模型中的联系的表示方式基本与关系模型中的一样(只是人们更习惯于使用引用，而不是键) (3)对象关系模型大多数也支持方法 * 主要内容 4.1 对象定义语言ODL简介 4.2 从ODL设计到关系设计 4.3 对象关系模型 4.5 半结构化数据 4.6 XML及其数据模型 * 半结构化数据 (1)是一种适于数据库集成的数据模型，也就是说，适于描述包含在两个或多个数据库中的数据(这些数据库含有不同模式的相似数据) 。 (2)是一种标记服务的基础模型，用于在Web上共享信息。 * 回顾 到目前为止所见到的模型(E/R、UML、关系模型、ODL)都是有模式的。模式是一种放置数据的严格框架。这种严格性提供了某些优点。 例如：关系模型的成功在于它的高效实现。 无论是实体集还是联系，在关系数据库中只用关系这一种数据类型来表示，而关系数据库中的数据必须符合其模式。固定模式可以使数据组织成能支持有效查询响应的数据结构。 * 半结构化模型的优点 半结构化模型是无模式的，也只使用一种数据类型，其优点主要在于灵活性：确切地说半结构化数据本身就指明了模式，且易于改变。 这种灵活性可能使查询处理更加困难，但它给用户提供了显著的优势。 * 半结构化数据示例 数据库入口 中心对象(实体) 标签cf代表Carri Fisher