多年以来,数据库系统从早期的树形数据库系统发展到关系型数据库。成为最成熟的数据库实现模型,但是有很多数据却不是很适合用关系型结构来描述。例如在医疗行业中,从一个普通的病例中可以看出,其中包含了大量的信息。结构复杂,不便使用层次嵌套关系存储,模式繁多。即使是在同一个医院,在不同的科室,其病例模板也不同。不同医院之间的病例模板存在更大的差异。在这种情况下,XML具有的自我描述、格式灵活、扩展性强等特性,就可以充分发挥作用。
事实上,XML已经成为最适合存储病例数据的格式。通过把病例的不同信息映射到XML的不同节点上,一旦病例发生了变化,基于XML描述的病例只需要修改极少的节点,就可以适应新的变化。
管理新的数据形式常常要面对新的挑战。许多开发者发现在处理XML格式的数据时都会遇到这种情况。虽然使用XML描述医疗信息可以满足对数据灵活性和可扩展性的要求,但是传统关系型数据库对XML数据的存储和支持却不尽人意。
如果基于传统的关系型数据库实现,常常会有两种基本的数据库设计方案:将每个 XML 文档完整地存储为一个大型对象(BLOB);或者将它 “撕开”,分散存储在多个表的多个字段中。前者将XML以二进制的方式存储在一个字段中,那么当需要查询XML中的数据的时候,SQL本身的功能就无法发挥作用。必须通过将存储为一个大对象的XML数据从数据库记录中提取出来,转换为树形结构的XML对象,才能通过XQuery等传统XML访问方式查询XML节点的数据。
而后者的拆分映射方式,将结构化的XML数据强行转换为二维的关系型数据,这种方式下拆分的算法依赖于具体的数据结构,并且丢失了XML中的语义信息。一旦病例的XML模板发生了变化,那么拆分算法就无法适应新的变化,必须通过修改表结构设计来满足需求。这样原有由XML带来的灵活性的优势就在无形中消失了。这两种方式都会导致性能问题、管理困难、查询的复杂性增加和其他问题。
随着技术的发展,也出现了纯 XML的数据库系统,提供了一种新型的数据库模型,但是这种方案还没有经过考验,它的集成能力、需要的人员技能以及未来的生命力还不确定。
为了利用现有关系型数据库的优势,同时又能够通过数据库使用XML提供的灵活性,很多数据库厂商并非采用纯XML的数据库解决方案,而是提供了一种在现有关系型数据库上增加对XML数据支持的混合方案。包括Oracle、SQL Server、DB2等很多数据库厂商,都提供了对原生的XML数据的支持。
以IBM的DB2为例,从9.0 Viper开始提出了pureXML的技术与概念。通过对原生的XML数据类型提供支持,一改过去作法,直接保留原来树状结构的数据结构,同时也支持XML索引功能和 XQuery查询。以 XML 数据自身固有的分层格式存储和处理这些数据,避免因为将 XML 存储为 CLOB 中的文本或将它映射为关系表而导致的性能和灵活性限制。与仅使用XML的数据库不同,DB2 9还提供了关系型数据与 XML数据在数据库中的无缝集成 —— 甚至是表的某一行中的集成。DB2 9中的pureXML特性允许程序员直接在数据库查询中使用SQL或XQuery访问数据库中的XML数据。一方面,XML文档在数据库中作为一个整体存储;另一方面,程序员有可以轻易访问到每一个 XML文档的内部信息。这样的灵活性表现在语言支持中,使得可以访问关系型数据或XML数据,也可以同时访问这两种数据。
事实上就数据存储而言,关系型数据库已经是非常成熟的应用,基于字段的方式可以提供精确的数据定义和控制,但缺点在于其数据结构是相对固定的。一旦需要扩展数据结构,必须通过修改数据库表结构来实现,修改的范围可能会涉及到与其他表之间的关系和数据表中所有的数据。而XML是以层次化的树形结构作为存储架构,通过元素(Element)和属性(Attribute)来包含数据,再通过XML Schema来保证数据结构的正确性。这种方式其数据结构具有动态的特性,只要符合XML Schema的定义,XML节点随时可以变化。
在实际的应用中,采用关系型和XML的混合方案,通过关系型数据库的成熟度加上XML的层次性特性,使关系型数据库在处理数据时更为全面,同时仍旧可以享受到关系型数据库为XML带来的好处。