设计基于文档的数据管理（第二周）
目标：
l 理解与基于XML文档的数据库管理的相关问题
l 理解以数据为中心设计和以文档为中心设计的不同指出
l 理解Glushko和McGrath’s的文档引擎方法
以数据为中心
以数据为中心的文档设计，其内部具有基本的逻辑结构，为应用程序使用进行优化，而非为人类使用而优化。它具有最小化或者专有的表现项目。例如：
学生ID 姓名 性别 生日 地址
111111 哈哈 男 1, Jun blah blah blah。。。
以文档为中心
以文档为中心的设计本身内部无规则结构。它是为了在线或者印刷出版物而优化的，为人类阅读放彼岸而存在。它对信息和其表现形式的区分不是很清楚。
三层ANSI-SPARC架构
顶层是外部层（External level）拥有多个用户每个用户的视图是不完全一样的，这一层是逻辑数据独立的
概念层（Conceptual Level），有概念模式（conceptual schema），属于物理数据独立
内部曾（Internal Level），有内部模式。
最底层是物理数据组织，一般是数据库担当。
以上模型映射到关系数据库的结果就是（以数据为中心的映射）
外部层à视图
概念层àER图
内部曾à关系模型
数据库à各数据库表
但是，如何将其映射到以文档为中心的模型呢？那就需要使用文档引擎。
文档引擎（文档工程）
找到某些样例文档中样式重复或者反复出现的特征。
样式可以是：
l 内容样式（什么信息？）
l 结构化的组件（内容的范围，它在哪里？）
l 表示组件（格式化文本和结构的组件，它看起来想什么？）
分析这些样式，并且识别文档中有意义的组件，并将这些组件组装为最小冗余和最多重用的组件。
建模活动
收集组件（Harvesting Component）
从其物理构成中提取出底层语义组件。例如一个unit guide可以包含：姓、名、课程标题、课程号、课程讲师、辅导员、上课地点、摘要、学习提纲、雇员等级、电话、邮件等等。
归并组件（Consolidating Component）
保证所有的组件是唯一的或者说是语义上彼此不同的。主要过程有如下：
1. 合并同义词（surname和lastname，unit和subject）
2. 重命名同源意义词（name –-> unit name, person name；unit –>subject, unit of mesure）
组装文档组件
组装文档组建的过程就是文档建模。文档组件模型包含其他组件，可以是相关的也可以是关联的。可以通过ER图来表示，它作为文档组件模型的概念表示。概念模型应该最大化重用性和最小化冗余。
组装文档
文档通常来说不会被表现为一个树状或者体系型的结构。文档可以通过把文档组件组装到不同的体系结构中来创建文档。每个结构叫做文档组装模型或者是文档类型。
最终的ANSI-SPARC对文档为中心的映射
外部层à发行(印刷)文档
概念层à文档组件模型
内部层à文档组装模型
数据库à文档实例
例子:课程信息
l 发行文档: 在文档内部的表现形式(unit guide, hand book entry, unit planning document)
l 文档组件模型:一个ＥＲ图，表述诸如课程名称,讲师等等的信息是如何表示的.
l 文档组装模型:一个xml schema用来定义逻辑文档的结构和内容的规则.
l 数据库: XML实例文件和xml模式
注意
在设计基于文档的解决方案时,很多出版文档需要你去做严格的定义,以防止产生歧义. 规则可以使用XML Schema来定义,但是这个schema不是文档组装模型!!(就是用来定义你如何定义文档元素之类的规则,这个时你自己的逻辑,但是它不用来指导文档组装).因为文档组装模型时在数据库中表现形式的规则,而为印刷出版物定制的XML schema时要表示对此出版物预期产出内容的规则.具体还不明白的话,看看上面文档组装模型的图.印刷出版物的内容来源于数据库,使用诸如XSLT的查询语言.
392
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
