文档管理数据库（共8篇）
文档管理数据库 篇1
什么是IT项目?IT项目管理是项目管理在IT领域的应用, 结合IT行业特点运用项目管理技术、理念和方法, 包括九大知识领域 (项目综合、范围、时间、成本、质量、人力资源、沟通、风险和采购管理) 以及启动、计划、实施、控制和收尾等过程组[1]36。
IT项目中, 由程序构成的软件产品本身就是文档, 而在其实施过程中则产生更多的诸如调研问卷、实施计划、变更计划、IT测试、项目培训等文档。对这些文档的有效管理有助于提高IT项目实施的成功率, 保证甲乙双方的项目顺利交接, 为IT项目后期的开发、维护和升级提供技术保障。
一、IT项目中数据文档建设和管理存在的问题
IT项目实施过程中的数据文档管理通常指除了程序之外的一切文档, 如需求文档、调研文档、培训计划等。但在IT项目实施过程中甲乙双方又容易重视程序文档而忽视其他文档, 这就容易产生以下问题: (1) IT需求文档缺失、不规范或维护不善。需求文档是IT项目中的核心文档, 是关于IT需求和建设的指南针。在IT项目建设中软件公司为了拿到项目在签约前给了用户很多承诺, 但在签约后则在需求文档撰写上采取符合其利益方式, 能规避的就规避, 能口头承诺的就不写入需求文档。甚至在需求文档完成之前就开始程序开发工作。这样的结果必然是与客户IT项目需求相差甚远, 最终可能导致项目反复修改, 既延误工期又浪费资源。另外IT需求文档的规范或维护不善主要体现在以下几个方面:项目变更后未及时更新需求文档或作备注说明;需求文档含糊其辞, 空话套话多;只注重宣传软件的长处而不告知客户可能存在的问题或风险等。需求文档中的这些问题需要客户本身加强对其的研究、判断, 特别是要紧密结合公司的实际需求。 (2) 技术文档缺失、不规范或维护不善。IT项目中甲乙双方的人员流动性一般都比较大, 技术文档的完整性直接关乎IT系统后期的开发和维护以及升级。但IT项目中的技术文档的最大特点就是版本和内容一成不变, 不能针对特定的IT项目及时制作出技术文档, 这样技术人员在理解和运用中费时费力, 而技术的复杂性、软件工具的不断升级又会导致技术文档的不断“过时”, 这可能给软件开发人员以错误的引导。另外, 技术文档不规范或维护不善 (如丢失) , 伴随核心员工的离职, 以前使用的方法和思想就难以成系统的保留下来, 这会大大提高后期的开发维护成本。 (3) 测试文档。IT系统的测试有着严格的制度和规范, 如需要遵循黑盒、白盒测试方法, 要设计测试案例、编写测试文档和测试说明。但在IT项目实施过程中, 测试文档一般都不健全, 如没有测试设计案例和计划、文档编写不规范、测试结果管理不善等。对测试文档进行有效管理能大大减轻测试工作量, 提高IT项目质量。 (4) 其他问题[2]13。如不能针对特定项目编写文档, 而是套用在其他项目中使用的模板, 生搬硬套, 既可能水土不服也可能内容上出现偏差。文档管理和规范没有规则和流程, 同样类型的文档多人编写, 格式和思路不一, 风格多样。另外就是文档具有生命周期, 其可能经过初始、修改、审定的循环过程, 谁修改、怎么修改应该有所记录, 以便追查和交流沟通。再者IT项目中的文档往往具有一定的关联性, 需要采用正确的目录方法进行保存和维护, 方便其他员工查看。
二、IT项目中数据文档建设和管理的改进
1. IT项目初期拟定详细的文档编写规划。
IT项目中的文档编写主要是确定谁在什么阶段编写出何种文档, 并对文档的修改、审定等作出说明。 (1) 编写什么文档。IT项目在前期调研、实施、测试、使用等各个阶段, 有不同的文档且有些文档必须出具。 (1) 前期的需求文档, 它是IT项目的核心文档, 需要非常明确地指出客户的需求, 不能套话、空话, 需求一定要落地, 否则最后会和客户需求出现差别并对IT项目实施造成风险。 (2) 设计文档, 特别是详细设计。该文档是需求文档如何落实需求的一种解释性说明, 并对资源要素提出要求, 对风险和困难提出应对方式。详细设计里面包含逻辑概念设计、物理结构设计、数据库设计等等, 这些设计文档主要用户甲乙双方实施IT项目过程中的技术规范和标准, 是实现客户项目需求的基础条件, 是甲方安排资源、实行资源调配的参照条件。 (3) 变更文档。项目实施过程中因为各种资源变化或客户需求变化, IT项目需求也会出现变化, 这种变化务必使用文档的形式进行固化, 作为甲乙双方合作的基础。 (4) 其他重要的文档还包括测试文档 (单元测试、集成测试、系统测试、测试案例和计划等等) 、培训文档、会议纪要等等。 (2) 确定文档的编写规则[3]75。IT项目中的文档众多, 必须遵循以下规则:命名规则 (如文档名称+编写日期+版本号) 、文档的存放路径, 以及文档编写格式和模板的存放路径等。在项目实施过程中, 所有文档编写的格式规范都需要遵循项目开始设定的这些规则, 这样才能保证风格如一, 保证文档的可阅读性、可查性。另外编写规则还必须确定:谁编写、修改后的版本规定以及修改信息的标注等。编写人一般由负责该部分的员工担任, 如需求分析可由项目负责人在搜集各个部门需求之后撰写, 设计文档由实施人员撰写, 测试案例由甲乙双方探讨后共同撰写等。文档修改后的版本号变化与修改信息也必须有明确的规范, 一般需要注明何人在何时修改的何内容, 并由撰写人根据修改内容确定版本号的修改。编写规则中还需要注明编写时机、完成时间要求、控制和维护规则等。
2. 对IT项目文档进行阶段性审查。
为保证IT项目实施过程中各类文档的有效编写和维护, 保证项目知识的有效传递和转移, 需要对文档进行阶段性审查, 这种审查既是项目沟通的必要, 也是项目文档质量保障的必要。 (1) 审查时间和审查人。不同文档的审查时间显然不一样。对于核心的需求文档, 需要甲乙项目负责人对其认真审查, 确保IT需求与企业要求一致, 否则会出现大的方向性的偏差。一般而言在大框架写完之后就需要进行第一次审查, 确保无问题之后再继续编写。而对于设计文档, 需要甲乙双方的负责人结合需求文档进行审核, 以确保软硬件条件能满足需求文档中的要求, 如对服务器环境、输入输出工具 (打印机、手持机、扫描仪等) 、电脑台数等的要求。设计文档的审查一般在项目开始之前进行, 并在项目需求或计划发生变更之后对其进行再次审查。至于测试文档、培训文档、维护文档等一般在IT系统使用之前进行, 参与人员可以扩大至甲方的业务人员, 这是由业务的复杂性所决定的, 而业务人员能根据各种情况列出测试案例, 从而保证IT项目的可用性。 (2) 审查内容。IT项目的不确定因素很多, 因此对文档内容的审查需要细致。对重要文档需要重点审核, 如测试文档中的案例是否足够?是否考虑到所有的逻辑情况?需求文档中的需求是否满足当前需要同时又考虑到足够的未来的业务需求?设计文档中关于硬件的采购是否考虑到资金压力, 服务器负载能力是否足够?另外, 涉及需求变更时, 相关联的文档也要一起审核, 如需求文档变动会引起设计文档的变动, 对后期的测试文档也有影响。再者需要审查文档是否合乎规范, 如文档名称、版本确定、文档修改是否有标注等。总体上看, IT项目文档的审查本质上也是一项沟通的工作, 使甲乙双方能对项目的细节了解更加清楚, 这更加有利于项目的推进, 也大大有利于后期IT的维护和管理。而且, 对于那些套用其他项目模板的IT文档, 审查显得尤为必要。
3. 借助各种工具实现对IT文档的管理。
IT项目中的文档内容纷呈, 形式多样, 样式复杂, 且各有自身其生命周期, 而且这些文档分散在甲乙双方不同员工的电脑里面, 员工都有对其进行修改和备注的能力与要求。因此在IT项目中统一、有效的管理各种文档并不容易。因此可以借用各种工具进行维护和控制。 (1) VSS文档管理工具。其主要用于版本控制, 该工具可以控制各种文档查看、修改、上传、保存等, 也能记录任何修改行为同时确保文件可以恢复到旧版本。当然VSS能通过树状目录方式指引使用者快速搜索、定位各种IT文档, 而且对文档类型 (二进制、图像、视频、声音文件等) 没有限制。考虑到项目中可能存在各个模块或小组, 可以通过组管理的方式保证这些文件的相互隔离性[4]53。 (2) 文档分类工具。严格意义上文档分类的工具来自于经验或一般意义上的要求。对IT项目中的文档进行分类是进行后续管理的前提。文档的分类方式多样, 按照提交方式可以分为常规文档和项目归档文档, 签字项目组成员可以相对自由地查看、修改, 但后者需要项目经理对其进行确认并归档。按文档的流程性可以分为日常管理文档和项目流程管理文档, 前者包括项目报告 (如个人或小组周报、项目周报、项目简报等) 、会议纪要、重大问题跟踪、项目管理模板、数据质量管理、问题反馈表等, 后者则与业务流程和项目流程紧密相关, 如关于业务流程改造的建议、流程调研文档、基础数据编码文档、项目确认书、实施报告等。对于甲方技术人员而言, 还必须关注项目开发、应用开发流程文档, 如项目计划、业务需求说明书、模块、应用开发文档、数据需求说明书、系统测试文档、详细设计文档、用户手册、上线文档、培训资料、系统运行维护日志等。
参考文献
[1]姚禾.组织级项目管理的有力工具—项目文档管理系统[J], 项目管理技术, 2009 (3) .
[2]郭树雄, 建设项目文档管理程序分析[J], 中国档案2011 (6) .
[3]李金峰, 项目文档管理纳入合同管理的思考与实践[J], 档案时空, 2012 (8) .
[4]孙彩光, 项目文档管理标准化实践[J], 黑龙江科技信息, 2011 (3) .
文档管理数据库 篇2
一、磁盘数据组织结构
在INFORMIX-OnLine的磁盘数据组织结构中的最上层为逻辑概念上的数据库空间dbspace,每一个数据库空间都有一个或若干个物理单位数据存储块chunk组成，镜像数据存储块mirror保证当根数据存储块故障时，OnLine能够继续工作。每一个数据存储块都有若干个数据页page组成，为了提高输入和输出效率，若干个连续的数据页组成数据连续页extent。用户的数据库database和数据表table存储在缺省的或者指定的数据库空间中，数据表的逻辑概念上的存储空间数据表空间tblspace有一个或若个安数据连续页extent组成，数据记录row存放在数据页page中。
为更好的的支持多媒体应用，多媒体数据可以存放在二进制大对象数据页Blobpage中，若干个二进制大对象数据页在此二进制大对象空间Blobspace。 OnLine使用逻辑日志Logicallog、物理日志Physicallog来管理数据库日志操作。
1.数据存储块chunk
INFORMIX-OnLine的数据存放在物理上连续的数据存储块chunk中，数据存储块是OnLine数据存储的最大的物理单位。数据存储块可以有两种构造方法，其一是直接构造在系统的物理磁盘上，其二是构造在操作系统的文件或者卷上。
在第一种情况下，在操作系统上仅仅定义了这个(块)磁盘但没有格式化这个(块)磁盘，因此在这上面的所有数据操作都有OnLine来完成，操作系统对它不存在任何管理，数据空间在物理磁盘上连续，这种数据的存储空间称为原始空间rawspace。
而在第二种情况下，操作系统不仅定义了这个数据存储空间(文件)，还管理这个数据存储空间(文件)，数据文件操作时的内存缓冲、输入与输出。数据空间的建立受操作系统的制约，在物理存储上不连续。我们称这种数据存储空间为非原始空间cookedspace。
比较这两种数据的存储空间，原始空间在磁盘上连续，没有操作系统的缓存和制约，非原始空间在磁盘上不连续，存在着操作系统的缓存和操作系统的输入/输出的制约，因此在实际应用中，采用原始空间效率高于非原始空间，由于原始空间与系统设备有关，同时不同操作系统对设备的定义的不一致性，定义非原始空间比定义原始空间来得简单。我们将原始空间所对应的磁盘称原始设备rawdevice，而将非原始空间所对应的操作系统文件称操作系统文件cookedfile。
为了进一步提高数据库运行的效率，我们通常选用字符设备作为存放实际的原始设备，这样在我们输入/输出数据时，可以充分发挥系统的DMA能力。当我们使用原始设备时，可以在同一个原始设备上建立多个数据存储块。通过对数据存储块的参数OFFSET和SIZE的定义，其单位为KB，我们可以定义多个数据存储块在同一个磁盘或磁盘块上，参数OFFSET定义数据存储块的起始位置，参数SIZE定义数据存储块的大小，用户在设置参数OFFSET和SIZE时必须保证在物理磁盘上没有相互覆盖。
在原始设备/dev/rdsk/c0t1d1s0上建立三个数据存储块chunk1、chunk2和chunk3，它们的大小分别为50MB、30MB和50MB，由于chunk的SIZE单位为KB，因此chunk1、chunk2和chunk3的SIZE分别为50000、30000和50000。在通常情况下,第一个数据存储块chunk1的OFFSET为0，这样第二个数据存储块chunk2的OFFSET应为第一个数据存储块chunk1的SIZE，而第三个数据存储块chunk3的OFFSET则为第二个数据存储块chunk2的OFFSET加上第二个数据存储块chunk2的SIZE。为保证在两个数据存储块的相邻边界处不发生重叠，可以将后一个数据存储块的起始位置稍微挪后一点。如果采用操作系统文件作为数据存储空间时，一般不在一个文件中建立多个数据存储块。一个文件中建立多个数据存储块，操作系统对文件中数据的定位时间将更长。
不管是原始设备还是非原始设备，OnLine的概念是一致的。在实际应用中，可以一部分数据存储块用原始设备而另一部分用非原始设备，只是原始设备采用OnLine的管理的I/O机制，而非原始设备采用操作系统unix的I/O机制。
2.数据页page
INFORMIX-OnLine在数据存储块中以数据页page为单位来组织存放数据，并以数据页为单位来输入输出数据，它的大小与数据在共享内存中数据缓冲区相一致，所以OnLine的数据页的大小是不可以改变的。数据页是OnLine组织存放数据的最小的物理单位。
根据不同从操作系统，OnLine的数据页的大小是不同的。例如在SCO、AT&T、UNISYS和HP等操作系统平台上，每一个数据页的大小为2KB，而在IBM和SEQUENT等操作系统平台上，每一个数据页的大小则为4KB。同时数据在共享内存中的缓冲区的大小也是根据操作系统的不同而不同，其值与数据页的大小一致。
3.数据连续页extent
为提高数据操作的效率，OnLine将若干个在物理磁盘上连续的数据页组成一个数据连续页extent。当用户创建一个数据表时，OnLine以数据连续页为单位在数据存储块中分配一块连续的空间，当用户的数据写满了这个数据连续页后，OnLine将以数据连续页为单位在数据存储块中申请一块连续空间，以存放更多的用户数据。在缺省情况下，初始化时第一个数据连续页为8个数据页。
数据连续页不能跨越数据存储块，当OnLine需要申请较多的数据页构成数据连续页时，如果OnLine找不到如数的在物理设备上连续的数据页时，OnLine将放弃这些不够构成一个数据连续页的数据页，OnLine将去下一个数据存储块去申请如数的在物理设备上连续的数据页。因此在实际系统中，过小的数据存储块将不利于数据操作性能和数据存取效率。
4.数据库空间dbspace
在INFORMIX-OnLine的磁盘数据组织中，数据库空间dbspace处于一个比较上层的位置。数据库空间是数据库在逻辑概念上的存储空间，一个或若干个数据库空间组成OnLine数据实体。在物理磁盘上，每一个数据库空间总对应于一个或几个数据存储块，在这些与数据库空间对应的数据存储块中，一定有一个数据存储块是根数据存储块，而其它的则是后继数据存储块。从功能上来看，根数据存储块除了具有后继数据存储块能够存储用户数据外，它还具有管理本数据库空间的功能;从数据存储块的保留页来看，根数据存储块具有56个保留页，而后继数据存储块仅有3个保留页。当然不同版本的OnLine在主、后继数据存储块的保留页的数量可能不同，但是根数据存储块需要更多的保留页来保存本数据库空间的定义。
在OnLine初始化后有一个称为根数据库空间rootdbs的数据库空间，它是OnLine系统的第一个数据库空间。当建立根数据库空间时，它的根数据存储块将被建立，所有数据库的日志和所有的定义信息都必须存放在该数据存储块中，它比所有其它根数据存储块的保留页更多。由于数据库日志定义的需要，因此对根数据库空间的根数据存储块的定义尤其重要，关于如何正确地定义根数据库空间的根数据存储块将在后面详细介绍，
为了提高数据库系统运行的效率，INFORMIX新的动态服务器OnLineDynamicServer7.1中引入了临时数据库空间的概念。在没有临时数据库空间的系统中，临时数据将建立的缺省的根数据库空间中，由于临时数据操作需要频繁的增加、删除，会给根数据库空间的数据存储块中造成很多碎片，将导致数据库操作效率的降低;另外当数据库备份时，那些临时数据也一起作备份，从而增加了数据备份量，降低了数据备份的效率。引入临时数据库空间后，用户的临时数据或者数据操作的中间结果将被存放在临时数据库空间中，同时当数据备份时临时数据库空间将不再被备份。
5.数据存储块镜像mirror
为提高OnLine运行时的数据高可靠性，OnLine在数据存储上引入了数据存储块镜像的机制。OnLine数据存储的镜像是对数据存储块而言的，但是其定义是对数据库空间的。当一个数据库空间被定义为镜像时，它下面的所有数据存储块全部镜像;当一个数据库空间被定义成没有镜像的时候，它下面的所有数据存储块全部没有镜像。
当OnLine在运行时，一旦数据存储块所在的物理磁盘发生读写故障，对于没有数据库空间没有镜像的系统，OnLine将自动关闭，并等待恢复。而对于具有镜像的数据库空间，OnLine将把存在读写故障的数据存储块标识为Down，同时OnLine将继续运行，用户完全可以根据需要，在适当的时候，恢复存在读写故障的数据存储块所在的磁盘，然后重构继续。因此一个具有镜像的数据库空间，其运行时的可靠性将大大高于不具有镜像的数据库空间。
6.数据表空间tblspace
在逻辑上，数据库存放在数据库空间dbspace中，数据表存放在数据表空间tblspace中。数据库空间是由数据存储块组成，数据表存在于这些数据存储块中，数据表空间是由连续存放该数据表记录的数据连续页组成。
二、共享内存数据组织结构
OnLine能高效地执行联机事务处理的第二个机制是数据库服务器系统的共享内存。在一些不使用共享内存的数据管理系统中，管理进程只能在需要数据的时候，将该记录和索引的最新值读入该进程所占有的私用数据缓存中进行操作，由于频繁的磁盘I/O，使系统的运行效率降低，同时由于那些管理进程都各占一份数据缓存，使得系统内存的有效使用率降低。因此使用共享内存会有以下三方面的好处：
(1)数据缓存不再属于某个进程，所有的数据库进程均共享这块内存，降低了磁盘的I/O;
(2)所有数据库进程访问相同的访问，它们的值和索引在内存中只有一份拷贝，提高了内存的有效使用率;
(3)操作的相关记录被预读进共享内存中，由于内存的I/O效率极高，因而系统并发除了数据的能力得到提高。
随着OnLine功能和性能的不断提高，OnLine的共享内存也有所不同。尤其是INFORMIX的动态服务器OnLineDynamicServer(ODS)在其共享内存的结构上增加了两个功能模块。在OnLine5中，其共享内存仅有一个区域，驻留区Residentportion;动态服务器ODS7.1除了驻留区Residentportion外还增加了虚拟区Virtualportion和通讯区Communicationportion。
1、操作系统参数对数据库服务器共享内存的影响
操作系统的共享内存参数对数据库服务器的共享内存的定义和建立会产生极大的影响。对INFORMIX来说，数据库服务器的共享内存绝对不能超过操作系统共享内存定义的允许范围。一个OnLine动态服务器7.1的共享内存不能超过操作系统所定义的一个UNIX进程所允许访问共享内存的极大值，由于操作系统对共享内存的定义往往不能满足OnLine动态服务器7.1的需要，因此，数据库管理员通常需要在建立其数据库应用系统以前，首先调谐操作系统的共享内存参数。
对于OnLine动态服务器7.1来说，操作系统的参数对它们的影响，在共享内存锁资源管理方面和虚拟处理器对共享内存访问操作方面是不全部相同的。它们对操作系统参数的要求也是不一样的，因此需要数据库管理员根据产品来决定操作系统的参数，在决定这些操作系统的参数前，请先阅读产品说明文件。例如OnLine动态服务器7.1的$INFORMIXDIR/release/ONLINE_7.1，在这个文件中它向数据库管理员阐述该INFORMIX产品在该机器平台上对操作系统参数的要求。同一种产品在不同的平台上，对该平台操作系统参数的要求非常有可能是不一样的;在同一平台上，同一产品的不同版本对操作系统参数也很有可能是不同的。
2、处理器资源组织结构
OnLine动态服务器7.1采用多进程Multi-processes多线索Multi-treads的数据库服务器机制，将每一个服务器进程根据用户定义分解成若干个线索，每一个线索响应一个用户的设计访问的请求。INFORMIX将每一个进程称作一个虚拟处理器Virtualprocess。
在以前的多处理器系统中，往往将用户的应用程序和系统的处理器CPU对应起来，每一个处理器都分别处理一个用户的应用程序;当应用程序数量多于处理器数目时，应用程序为争夺处理器资源CPU，而引起应用程序在运行时间上的不平衡;同时当应用程序的数量少于处理器数目时，由于一些处理器资源得不到运用而空闲，导致处理器资源运用上的不平衡。一种比较好的方法是将处理器与应用所需要的处理器分离开来，然后由数据库系统来平衡这种需求。在INFORMIX动态服务器中，用户应用程序发出的数据操作请求被称作虚拟处理器的服务器进程所接收，然后OnLine均匀地将这些服务器进程分配到系统实际的处理器CPU上。这样就较好地解决了上面所提到的两种不平衡状态。
在ODS7.1中每一个数据库服务器进程都称作一个虚拟处理器Virtualprocess，简称VP。若干个相同功能的虚拟处理器组成一个虚拟处理器类VirtualprocessClass，简称VPClass，每一个VPClass都表示一种功能的虚拟处理器。OnLine一共有七种虚拟处理器，它们是：
处理器虚拟处理器CPUVP，响应所有用户和OnLine系统对CPU资源的操作和协调。
磁盘输入输出虚拟处理器DiskI/OVP，响应用户和OnLine系统的磁盘输入输出请求，磁盘输入输出处理器分三种，异步输入输出AsynchronousI/O、物理日志输入输出Physical-logI/O和逻辑日志输入输出Logical-logI/O。
网络通讯虚拟处理器NetworkVP，响应用户的网络联接的请求。ODS的网络虚拟处理器有三种，它们分别用于管理tli、soc和ipc三种网络通讯接口。
系统管理虚拟处理器AdminstrationVP，运行OnLine系统管理程序和一些专职程序。
光盘虚拟处理器OpticalVP，当用户运行OnLine/Optical时管理光盘系统的运转。
审计虚拟处理器AuditVP，当用户系统需要一定的运行时数据安全性的时候，审计虚拟处理器在后台帮助检查每一个用户操作的合法性。
杂项管理虚拟处理器MiscellaneousVP，用于管理所有以上虚拟处理器不作的工作。
共5页: 1 [2] [3] [4] [5] 下一页
文档管理数据库 篇3
一、传统关系型数据模式及操作
(一) 系统的功能结构图 (图1) 。
文档的分类与文档的基本信息都存储于标准关系型数据库系统中 (例如SQL Server) 。二者通过关键字段进行关联。
(表1) 文档分类表字段设置
查询代码:
Select文档名称分类名称from表1 INNER JOIN表2 ON表1.分类索引号=表2.分类索引号
这种模式下, 如果文档的分类越来越多, 层次越来越深, 使用关系型数据库存储容量快速增加, 数据冗余大量出现, 严重影响查询速度。同时, 系统上分类界面的树型结构显示也变得十分复杂, 需要用多层循环的递归来实现, 这种设计方法降低了程序的高效性、健壮性与复用性, 严重地增加了程序编写的负担。
二、XML数据结构模式的特点
当今众多开发语都支持对XML文件与数据的操作。针对XML的特性, 定义了各种操作和应用, 使得对XML数据的操作与显示更加简洁与高效。在APS.net中, 不仅可以对XML文件进行读和写。而且对于XML数据中的节点的操作也是应有尽有。同时为了将XML数据快捷、有效地显示在网页或应用程序上, 将treeview、map、menu等控件紧密地绑定在一起, 程序员只需简单地设置几个参数即可, 大大降低了数据层到表现层的开发难度, 使程序员从繁琐的代码工作中解脱出来, 进行更高效的逻辑设计。
三、关系型数据模式与XML数据模式的结合
对数据进行合理的分类与分解, 分别存储于不同模式的数据模式中。
(一) 新型模式下的文档管理系统功能结构 (图2) 。
在对系统功能和数据结构详细设计与分析下, 对数据进行合理的分类与分解, 使得过去全部存储在关系型数据库下的数据分别存储于不同的模式下。在XML文件中存放文档的分类设置信息, 文档的基本信息存于关系型数据库中。
(二) XML数据模式下数据结构的实现 (文件名为XML-File.xml) 。
具体如下:
(三) XML数据表现层的数据存取的实现。
第一步:设置XML文件数据源。
第二步:建立XML对象, 将XML数据源中的数据导入对象中。
(四) XML数据表现层的实现, 即与树型结构控制tree view的绑定。
第一步:页面上Treeview控件的建立。
第二步:Treeview控件与XML对象的绑定。
四、结语
XML在软件开发中的应用, 增加了数据存储的灵活性与多样性, 使传统的关系型数据模式得到了更大的扩展;XML数据模式的简单性与易构性, 使其成为多种软件、系统之间的桥梁, 通过XML格式使数据更易在不同的软件间流转与共享;XML与HTML同为开放式的标记性语言, 与HTML一样使用HTTP协议进行传送, 不仅WEB应用开发更加简单, 而且数据结合更加紧密, 实现了XML数据与HTML页面的无缝契合, 由此WEB应用的响应速度提高了, 健壮性也有了很好的提升。综上所述, XML数据模式的应用是高校文档管理系统最佳、最优的选择。
摘要：传统关系型数据模式严重影响了查询速度, 增加了程序编写的负担。XML数据模式大大降低了数据层到表现层的开发难度, 使程序员从繁琐的代码工作中解脱出来, 进行更高效的逻辑设计, 是一种新型模式下的文档管理系统。
关键词：数据映射,数据模型,文档分类
参考文献
[1] .何中灵, 黄黎艳.浅谈XML数据管理技术[J].科技致富向导, 2012
文档管理数据库 篇4
1 实体识别算法
为了说明实体识别问题, 我们先定义标签树的一些相关概念。单个的标签树的公式为T= (V, E, r, µ) , 其中V={v1, v2, v3, …, vn}是节点集, E={u, v|u, v∈V}为边集, r∈V为根节点, µ映射在各个节点带一个有限制的标签集L={l1, l2, l3, …, lk}的标签函数。可定义为u的层次1 (u) 是从根节点通过指定路径发送至节点u处, 所经过的各个边的个数。若相邻的两个节点u, v若l (u) >l (v) , 则v可看作为u的子节点, u可看作为v的父系节点。没有子节点的节点被称为叶子节点, 其他节点均成为内部节点。相同父系节点生成的子节点可看作为兄弟节点。
2 实体识别算法在XML文档数据质量管理中的应用
2.1 树的精确匹配算法
在精确树的匹配上, 目标树T= (V1, E1, r1, µ1) 与模式P=T2= (V2, E2, r2, µ2) 是两个具有一定规律的标签树, 以下三种情况我们可认为T1与T2节点可与r1匹配符合。
(1) T2的树节点可映射在r1中。
(2) 如果v2∈V2映射至v1∈V1, 可认为µ1 (v1) =µ2 (v2) 。
(3) 如果v2∈V2映射至v1∈V1且v1不是叶子节点, 那么v2的每个子节点均可映射到v1的子节点。
图1展示了模式树P与目标树T匹配符合的例子, 并给出了精确树匹配算法。模式树P的体积为m, 目标树T的体积为n, 它们的匹配复杂度为可认为O (mn) , 算法的基本原理为先序遍历T中每个节点, 在每个节点V, 算法均实施递归调用, 知道无法检测出不匹配为止。在很多文献中都有改进算法提出, 改进算法可归纳两类, 分别是分解算法、遍历算法。
2.1.1 遍历算法
遍历算法是由霍夫曼提出, 其中包含两种遍历算法, 分别是自底向上匹配算法和自顶向下匹配算法。自底向上匹配算法是从叶子到根部的遍历树, 自顶向下匹配算法恰恰相反。在空间上而言自顶向下匹配算法是最适合的, 但在时间上却是非线性。这种的算法的原理是编码从根部到叶子的通道为字符串。以字符床模式匹配算法字目标树中寻找相似字符串进行匹配。
2.1.2 分解算法
2.2 近似匹配算法
2.2.1 树编辑距离
应用树结构对XML文档进行描述, 以树之间的相似特性来模式XML文档中的相似性。比较树之间的相似性最早应用的便是树编辑距离, 计算一棵树至另一棵树之间的距离值, 需要增加和删除的数量是多少。在这一问题上Tai等人给及了树编辑距离时间复杂度的计算公式O (n6) , 进而计算树编辑距离。
2.2.2 树对齐距离
树对齐是对一连串编辑距离的拓展和延伸, 树对齐距离是在特殊的状况下惊醒树编辑问题, 任何插入操作均需要在删除前实施。在T1和T2的标签树之间的队列为AL, 将空符号λ插入运算中得到两棵树使其成为同构, 再次复制操作拓展树。则每一对标签树在AL中均存在相对应的标签。匹配的主动计算就是通过最少的计算量获得最匹配的运算值。
3 结语
目前, XML数据在许多领域均有应用, 同时实体识别技术在XML数据中的应用也显得越发重要。XML数据与数据管理质量息息相关, 提高数据管理质量就需要强化XML数据的实体识别功能。文中所提出的各种与实体识别的匹配算法是业内承认的经典算法并可行性较强, 不过XML数据在实体识别中的研究还未发展成熟, 其中仍存在许多问题等待人们去解决。
参考文献
文档管理数据库 篇5
笔者所在单位欲建立一个能实现全文检索的文件共享系统, 需要将NSF数据库中的内容导出, 再导入到新的检索系统中。若手动逐个打开各文档对附件进行拆离, 不仅劳神费力, 而且容易出错。笔者分析了所用的Domino数据库的结构, 找出了一个将NSF数据内容导出到普通文件的解决方案。
笔者单位OA办公系统是在Lotus Notes/Domino4.6.5平台上开发的, 其功能模块有发文、收文、签报等, 下面以发文库为例, 说明如何将NSF文件内容导出。
一、确定需要导出的文档信息
在Notes界面打开发文库中的一个文档, 如图1所示。笔者欲导出每条文档的4项检索信息、发文内容和附件。检索信息包括流水号、拟文日期、发文字号、标题。为便于管理, 将4项检索信息合并储存在一个TXT文档中。发文的内容及附件则单独存盘, 将其保在“d:file发文”子目录下, 并为每一个月份建立一个子目录, 再在该子目录下为每个发文建立一个子目录, 该子目录以流水号命名, 在该子目录下储存“发文内容”和“附件”。例如图1所示文档储存于硬盘的“d:file发文200111383”子目录。文档中的“发文内容”是NSF文件的嵌入对象, 没有名字, 不妨以content命名, 而附件有自己的名字, 不用重新命名。
二、找出NSF库中的相关域名 (字段)
首先, 以管理员身份登录, 以确保接下来的操作都有权限。为查找数据库域名, 在“发文管理”界面选择任一文档, 右击鼠标, 在弹出的快捷菜单中选择“文档属性”, 再单击“域”选项。
本例中, “域”选项看不到任何东西, 这是因为程序开发者隐藏了设计。笔者找到了发文库的模板文件 (mbbfawen.ntf) , 该文件的域信息与发文库一致。打开该文件, 用上述办法可以看到域信息 (如图2所示) 。
根据域名的名称进行推理验证, 流水号、拟文日期、发文字号、标题、内容和附件等的域名分别是:lishuihao, niwenriqi, fn&fy&fl, shiyou, content和attachment (注意:发文字号实际包含3个域) 。当然, 也可通过查看表单获得域名。
三、设计代理 (即能自动运行的脚本程序)
打开发文库, 如图3所示, 点击“创建”-“代理”, 出现“未定义-代理”窗口。
在名称一栏, 给本代理命名为“uploadfawen”, 点击script左边的圆点 (如图中红色部分所示) , 然后在下边的大方框中输入如下代码。
‘将流水号、拟文日期、发文字号等内容储存于content.txt文件中。
‘本来拟文日期、流水号分别是日期型、数字型变量, 但在异常情况下会取不到值变成空的字符串, 导致后续错误, 下面两行用于消除异常 (不进行处理) 。
‘若原nsf文件中有文档被破坏, 即使在notes操作界面亦则无法正常打开,
‘为不影响程序正常运行, 以下错误处理语句用于跳过这些错误。
On Error Goto endofsave
‘先导入发文内容, 其域名为content
Set rtitem=doc.getfirstitem (“content”)
‘当rtitem为空时, 下面的forall会出错, 故先做如下测试。
If Isarray (rtitem.embeddedobjects) Then
Forall o In rtitem.embeddedobjects
‘对于嵌入对象和文件附件应使用不同的方法导出
‘对于嵌入链接则不予导出
‘再导入附件, 其域名为attachment
输入完毕, 按窗口右上角关闭按钮, 保存修改、退出即可。
四、运行
先在硬盘建好子目录“d:file发文”, 接着进入Notes界面, 打开发文数据库, 点击“操作”, 在下拉菜单中选择“uploadfawen”, 若无此选项, 可先点击“其他”选项, 然后找到“uploadfawen”, 再点击运行即可。
代理运行后生成的content.txt文档内容示例如下:
文档管理数据库 篇6
基于WEB的信息管理系统的发展, 使得网络中的分布式异构数据库的数据集成和互访成为研究热点之一。传统的关系数据库的安全性、完整性、多用户并发访问、数据恢复等突出优点成为绝大多数用户构建数据库的首选模式, 然而, 在实际的企业应用中, 由于各种历史和客观情况, 不同的企业构建应用平台所采取的数据库系统存储格式不一定相同, 这样导致大量的异构数据库的存在。当企业应用平台进行数据交换和集成时就会出现各种问题。
XML语言, 作为SGML语言的子集之一, 由于其定义严格、独立性、结构清晰、兼容性、灵活易懂等特点, 成为描述WEB应用中各种复杂数据的最适合的格式之一, 作为数据交换标准, 在各种应用平台, 尤其是基于WEB平台的EDI中发挥着重要的作用。因此, 研究传统数据库和XML数据库的结合, 实现两个数据库中的数据交换, 显得尤为迫切和重要。
2 XML文档向关系数据库的转换
XML文档转换为关系数据库, 一般采取模型和结构为中心的转化方法[1,2,3]。结构转化方法根据XML文档中固有的模式信息生成对应的关系模式, 然后对XML文档进行解析分解并存储于对应的关系 (即表) 中。例如利用Schema思想直接映射为关系模式, 采用混合内联法根据XML文档的语义信息, 实现从DTD映射为关系模式[4,5]。模型转化方法是指将所有的XML数据根据XML文档结构的方式存储于固定关系模式的数据库中, 然后提取对应的元素, 实现到关系模式的转化。例如利用四个固定格式的表来存储XML文档, 利用群模式的XML树方法来存储XML文档[6,7], 都是标识和提取XML文档中的元素, 然后以关系记录 (表) 的方式进行存储。
目前研究的大多数XML文档向关系数据库的转化都是基于Edge的映射算法[8], 其主要思路是把XML文档扫描成一棵带标记的树, 根据节点、边把树中所有的边都存储在关系表中。本着减少关系表连接数目, 提高查询效率的原则, 对Edge算法进行了改进。根据Edge的映射算法, 将XML文档进行抽象, 转化成一棵有向、有序的带标记的树。然后做如下定义:
定义1对任意节点m, 按照有向图的原则, 统计关于该节点m的度、入度、出度, 则节点m的度的总数应为以m为开始节点的出度和以m为终止节点的入度和之和。
定义2如果节点m的入度为0, 并且通过节点m可以浏览树中的所有节点, 则节点m必为根节点;如果节点m的入度为1, 并且节点m的出度为非0, 则节点m为元素节点;如果节点m的入度为1, 并且节点m的出度为0, 则节点m为值节点。
定义3关系数据表rel, 包含编号、父节点编号、节点名称三个字段。
算法描述:
(1) 对XML文档采用SAX的方式进行文档解析, 这种解析方法提供顺序访问机制, 把XML文档的元素作为对象处理, 占用内存少, 检测速度快。
(2) 根据Edge算法, 对要映射的XML文档进行深度优先扫描, 根据定义1的方式, 记录XML文档中任意两个节点之间的结构关系, 并对结构图中出现次数大于1的所有元素加上指定的特殊符号标记, 用于对元素进行检测重复元素的时候进行区分。根据定义2, 当一个任意节点第一次被遍历时, 加上已经访问标记, 当该节点下面的所有节点遍历完成时, 取消该节点的已经访问标记, 如果检测结束, 该节点仍然有已经访问标志, 则说明该元素必然有特殊符号标记, 存在重复访问的问题。
(3) 对于步骤2的检测结果分两种情况处理, 把所有带特殊符号标记的节点映射为单独的关系数据表;对于其它剩余的普通节点, 如果节点m为初始节点, 则关于该节点所能访问的下属节点作为属性, 存入一个关系数据表中。
(4) 根据定义3建立的节点之间的关系数据表, 保存处理过的XML文档中节点之间的关系, 然后重构XML文档数据库。
最后, 根据上述算法及处理结果, 采用Microsoft Visual Studio2003和C#语言在Windows内部组件之一的.NET Framework代码库中进行XML文档到SQL Server 2003关系数据库的转化。具体转换实例由于篇幅原因省略, 转换结果发现, 该算法生成的关系数据表比较简单, 表间关系相对比较清晰, 表内元素独立性相对较好。
3 关系数据库向XML文档的转换
关系数据库向XML文档的转换一般采用XML文档向关系数据库转化的逆过程的原理或者采用JDBC API的方式完成。逆过程一般流程是, 根据XML文档的要求对将要转化成的XML文档进行描述, 包括关系数据库中的每个表, 表中的字段名称, 表间的关系等都定义成元素或者子元素的形式, 然后设置XML文档格式中根元素的开始标记和结束标记, 接着从开始标记起对关系数据库中的表的所有记录以及表间关系进行扫描。这种逆向转化方式的缺点在于将XML文档转化成关系数据库后, 再将关系数据库转化为新的XML文档, 会导致新旧两个XML文档的数据不会完全相同, 这与映射算法存在关系, 从XML文档到关系数据库的映射过程中, 属性和子元素都映射到关系数据库表中的一个字段, 而且在映射的过程会遗弃本身既是属性又是子元素的信息。不过这对最终的结果影响不是太大, 不会影响Internet网中的数据传输和处理。
在实际的数据转化和处理过程中, JDBC API的方式简单且易操作, 所以采用其实现关系数据库到XML文档的转化。基本流程是, 利用Java API for XML Processing、SQL Server 2003、XML的文本编辑器等工具, 通过JDBC实现和即将转换的关系数据库建立连接, 定义并执行SQL语句中基本查询语句SELECT语句即将转换的数据库中的信息, 记录查询结果;然后利用API建立JDOM树, 将查询结果的记录添加到JDOM树中, 其中字段名和字段值分别对应于XML文档的子元素名称和子元素内容;然后根据XML文档的格式, 将JDOM树输出为XML格式的文档。
简要介绍一下具体操作实现过程。
(1) 建立JDBC和数据库的连接。在计算机上安装Java应用程序、创建好SQL Sever关系数据库及相关数据表、安装JDBC驱动程序, 然后装入数据库驱动程序, 设置Connection对象, 创建Statement和Result Set对象, 分别用于执行SQL语句和对查询结果进行检索。
(2) 在SQL Server中使用Select语句对关系数据库进行查询, 由Statement对象发起, 并由Result Set对象进行查询结果的存储。为第四步的XML文档转化做好合适的数据准备。
(3) 设置转换规则。这是关系数据库到XML文档转化的核心环节。利用Select语句的查询结果, 创建一个临时的类似XML结构的文档, 然后修改数据结构的形式符合XML文档的结构, 主要是对Date、Element、Root三种元素的形式、名称、内容的定义。
(4) 将前两步存储的数据转化成XML文档格式。对前面建立的临时文档进行检索, 主要检索Data元素中存储的Result Set中的Select中的查询结果内容, 根据XML文档的结构形式抽取数据, 然后利用API建立JDOM树, 设置JDOM树的根节点, 利用Document对象把检索到的元素内容依次存储, 多次循环处理初始数据, 根据需要向临时文档加入元素及其相关属性, 直到把所有的数据都分析完。最后将得到的JDOM树按照指定的格式输出为XML文档。当然格式不指定也可以, 指定格式的输出文档可读性比较好。
4 结论
WEB的飞速发展和广泛应用, 尤其是物联网技术的带动, 使得XML语言在Internet数据传输中牢牢占据了主动地位, 在关系数据库模式中迅速有效的存储和转化XML文档也成为很多专家学者的研究热点, 但由于XML文档非结构化和结构化的关系数据库存在结构不匹配的原因, 二者的数据互换或者交换问题一直没有完美的解决方案。本文中提出的XML文档向关系数据库转化的改进的Edge算法以及利用JDOM树进行关系数据库向XML文档的转化, 在上机实现上相对比较简单, 基本上实现了结构化和非结构化数据之间的互换。但没有考虑到表的数据完整性和表间的关系的约束、参照完整性问题, 需要在以后的研究中进行补充完善。
摘要：简要介绍了XML文档和关系数据库进行数据交换的必要性, 并讨论了XML文档数据库和关系数据库之间进行数据相互转换的算法, 并对计算机上机操作的实验流程进行了简要的描述。
关键词：XML,关系数据库,交换,映射
参考文献
[1]Kei Fujimoto, Dao Dinh Kha, Masatoshi Yoshikawa, ToshiyukiAmagasa, “A Mapping Scheme of XML Documents into RelationalDatabases using Schema-based Path Identi.ers, ”wiri, pp.82-90, International Workshop on Challenges in Web Information Retrievaland Integration, 2005[1]Kei Fujimoto, Dao Dinh Kha, Masatoshi Yoshikawa, ToshiyukiAmagasa, “A Mapping Scheme of XML Documents into RelationalDatabases using Schema-based Path Identi.ers, ”wiri, pp.82-90, International Workshop on Challenges in Web Information Retrievaland Integration, 2005
[2]Dweib I, Aeadi A, Elrhman S E F, et al.Schemaless Approachof Mapping XML Document into Relational Database[C]//Proc.ofthe 8th IEEE International Conference on Computer and Informa-tion Technology.Sydney, Australia:[s.n.], 2008:167-172.[2]Dweib I, Aeadi A, Elrhman S E F, et al.Schemaless Approachof Mapping XML Document into Relational Database[C]//Proc.ofthe 8th IEEE International Conference on Computer and Informa-tion Technology.Sydney, Australia:[s.n.], 2008:167-172.
[3][6]SOLTAN S, RAHGOZAR M.A.A clustering-based scheme forlabeling XML trees[J].International Journal of Computer Scienceand Network Security, 2006, 6 (9A) , 84-89.[3][6]SOLTAN S, RAHGOZAR M.A.A clustering-based scheme forlabeling XML trees[J].International Journal of Computer Scienceand Network Security, 2006, 6 (9A) , 84-89.
[4]LEE D, CHU W.CPI:constraint preserving inlining algorithm formapping XML to relational schema[J].Data and Knowledge Engi-neering, 2001, 39 (1) :3 25.[4]LEE D, CHU W.CPI:constraint preserving inlining algorithm formapping XML to relational schema[J].Data and Knowledge Engi-neering, 2001, 39 (1) :3 25.
[5]Bohannon.From XML schema to relations:a cost based ap-proach to XML storage[C]//Proc of the18th International Conferenceon Data Engineering.2002:64 75.[5]Bohannon.From XML schema to relations:a cost based ap-proach to XML storage[C]//Proc of the18th International Conferenceon Data Engineering.2002:64 75.
[6]M Yoshikawa, T Amagasa, T Uemura, Shimura.A path-basedapproach to storage and retrieval of XML documents usingRDBMS.[J].ACMTOIT, 2001, 1 (1) :110 141.[6]M Yoshikawa, T Amagasa, T Uemura, Shimura.A path-basedapproach to storage and retrieval of XML documents usingRDBMS.[J].ACMTOIT, 2001, 1 (1) :110 141.
文档管理数据库 篇7
关系型数据库是一种“纵向扩展”的技术，想要扩展容量（无论数据存储还是I/O），都需要更换更大的服务器。现代应用结构的解决却是使用“横向扩展”----无需新购买更大的服务器，只需要在负载均衡器下增加一般的服务器、虚拟机或是云服务器就可以实现扩展。此外，容量在不再需要的时候还可以轻易的缩减。事实上，“横向扩展”在应用逻辑层的使用已经很广泛了，只是数据库技术上刚刚赶上而已。
NoSQL“横向扩展”部署方案的优点已经受到了业界的注意，但是同时很多人忽略的是NoSQL数据管理的简洁，不需要很复杂的操作模式构建，这一点对于数据库的提升也和扩展模型一样重要。在使用传统关系数据库时，添加数据前，需要定义操作模式。之后每一条记录的加入都需要严格的按照定义的操作模式进行，比如固定的列数和数据类型。因此，改变那些分区关系型数据库的操作模式，会非常的麻烦。如果数据获取和数据管理需求经常变化，那这种严格的模式限制将会成为制约表现的屏障。NoSQL无论文档型、列式、K-V都是水平扩展的，它们都不需要预先定义操作模式、所以也不需要在需求改变时改变操作模式。使用SequoiaDB来介绍文档型NoSQL数据库技术。
SequoiaDB的数据模型就是以JSON格式存储的文档型模型，所以SequoiaDB具备了文档型和NoSQL数据库的数据灵活性和高可扩展性。SequoiaDB的文档型数据模型不仅简化了数据存取的过程，也大大的提升了数据的灵活性。在应用中不仅免去了设计模式这个麻烦的环节，还能很好的适应大数据时代高并发、实时性和分布式的要求。
XML文档在关系数据库中的存储 篇8
（一）用固定的RDB模式存储XML数据
把XML文档模型(图1)转化成一个有序的带标记的有向图(图2)。每个节点表示一个XML对象并赋予一个唯一标识，元素与子元素的关系用子元素的名字命名的有向边来表示，叶子节点表示属性值或元素值。
（二）从实例数据提取关系模式
分析和查询XML半结构化数据的方法主要是STORED (Semistructured To Relational Data)技术。STORED方法利用了一种启发式数据挖掘算法自动产生“好”的关系模式和STORED映射。这种映射是无损映射，部分不满足映射的数据会被存储在另外的一个溢出图中，也就是说STORED映射把半结构化的ML数据存储到由规则的关系模式和不规则的溢出模式组成的混合模式中。STORED语言的表达能力有限，它不能处理带有递归结构的XML文档。
（三）从文档模式中导出RDB模式
为了将XML文档存储到成熟的关系数据库中，就需要分别研究XML和关系数据库的数据模型，而DTD是XML已经被广泛使用的定义格式。把XML文档存储到关系数据库中最关键的一步是文档结构到关系模式的映射，因为这一步的好坏决定了映射是否无损、正确，同时也会制约查询处理的性能。
根据DTD图生成的关系模式是该DTD图中每一个元素所生成的关系模式的并集。为了说明如何生成一个元素的关系模式，需要引入元素图的概念。一个元素的元素图就是从该元素出发以深度优先遍历DTD图的过程中所生成的一棵树。根据DTD图生成关系模式的方法有：基本内联法、共享内联法和综合内联法。
1. 基本内联法：当我们为DTD中每个元素都创建了元素图之后，对于每一个命名为e的元素所对应的关系模式，可以它的元素图生成一个同名关系e，方法是把元素图中根节点e的后继节点均作为属性被包含到关系中，但有两种情况例外：(1)节点“*”的直接后继节点。这类节点将映射为独立的关系，因为它们代表了父节点的集合属性。(2)逆向边所指向的节点。这类节点也将映射为独立的关系，因为它们表示了DTD定义中的递归情况。
在生成的关系模式中，关系的属性是以从节点e到内联节点的路径来命名的;每一个关系需要有一个ID域来作为该关系的键;对于“*”或“+”节点的直接孩子节点以及带回路的节点，她们所生成的关系还需要有一个parentID域来作为该关系的外键。基本内联法将产生大量的关系，并且会产生大量的数据冗余，因此该方法基本上是不实用的。
2. 共享内联法：确保一个元素节点只在一个关系中出现。它按如下原则来判断哪些元素可以生成独立的关系：(1) DTD图中入度大于1或等于0的元素节点生成独立的关系模式;(2) DTD图中节点“*”或“+”的直接后继元素节点生成独立的关系模式;(3)互为递归的入度均为1的元素节点，其中之一 (有逆向边指向的) 生成独立的关系;(4)其余的节点均生成关系属性。
按上述规则确定哪些元素将生成独立的关系后，关系模式的构造是相对简单的。因为共享方法只选择部分元素生成独立的关系，所以共享方法的一个显著特点是关系的数量大大减少。
3. 综合内联法:在共享内联法的基础上，将所有入度大于1的元素节点也内联进入点所生成的关系中，但是带回路的节点以及“*”或“+”的直接后继节点除外。综合内联法和共享内联法相比是提高了查询的效率;和基本内联方法相比是大大减少了关系的数量，整体性能得到了提高。
（四）用户提供映射方法
用户提供映射方法基于RDBMS对XML的支持。主要的数据库管理系统也都不同程度的提供了对XML的支持。IBM DB2 XML Extender提供了DAD (Data Access Definition，数据访问定义) ，定义存储策略。要求用户去掌握DAD规范。
SQL Server的Open XML要求先将文档编译到一个内部的DOM表示，这些会限制其能力。因此，文档的大小就受内存大小的限制。
Oracle存储XML文档有多种方案，如大对象(LOB)存储：整个XML文档以字符大对象(CLOB)存储;BFILE存储：XML被存储在DBMS以外的地方(如文件系统);对象-关系存储(即用数据库中的表来存储XML文档);Oracle 9i增加了一个新的数据类型称作XML Type，允许把整个或部分XML文档存于数据库表中的被定义为XML Type类型的列。
尽管商业数据库中对XML的支持已经有了很大的发展，但是商业数据库中仍然存在一些实用性问题，包括它们的方案都是私有的、专门的方案，绑定到特定的后台数据库，缺少灵活性和可扩展能力。
（五）总结
本文主要讨论了在关系数据库中存储XML数据的方法，并指出了这些方法的不足。由于关系数据库的成熟性以及良好的处理大数据量的能力，目前关系数据库管理系统在各种应用中仍占主体地位，因此如何更加合理地将XML文档进行转换并存储到关系数据库中具有很大的研究价值。
摘要：文章介绍了XML数据在关系数据库中的存储方法, 并指出了各种方法的缺点和不足。
关键词：XML,关系数据库,DTD图,映射
参考文献
[1]王金玲.XML数据库的数据存储方法分析[J].赤峰学院学报, 2008, (1) .
[2]余贞斌, 王新伟.XML数据在关系数据库中的存储[J].微机发展, 2005, (11) .
[3]闫丽.基于DTD的XML关系存储策略研究[J].通化师范学院学报, 2007, (8) .