分层数据格式的数据库模型 【技术领域】
本发明涉及将分层数据格式映射到关系数据库管理系统的方法。并且，本发明还涉及利用这样方法的数据库模型和读写记录媒体的设备。
背景技术
未来数字记录的特征在于，准备，展示和归档数据服务，即，例如，像DVR(数字录像机)那样的记录器将存储和处理像广播电台或特殊服务那样的内容提供者传送，或甚至用户自身收集的附加信息的额外值。生成额外值(元数据)是为了进一步将信息给予用户。例如，额外值可以是说明故事的电影简介、演员表等。此外，提供便于电影内的导航的附加信息也构成额外值。例如，可以将电影构造成每一个都有独立标题和可能进一步包括有用信息的段、子段等。
为了提供结构信息和为了传输像视频流或音频流那样的多媒体对象的其它元数据，一般使用分层数据格式。众所周知的和广泛接受的分层数据格式是可扩充标记语言XML。XML是定义用于传送有格式数据的专用标记语言的系统。因此，它也被称为元语言，即，用于创建其它专用语言的语言。XML数据由以多个描述符的形式组织起来的文本组成。文本本身包含元素、属性和内容，即，其余文本。除了用于多媒体对象之外，XML的许多其它应用也是已知地。
可以预期，在不远的将来，数字记录器将在关系数据库中以XML或其它分层数据格式存储相当大量的数据，因为这些数据库被广泛使用并相当复杂。但是，对于存储，存在着必须将分层数据格式映射到关系数据库管理系统(RDBMS)的问题。对于XML，人们已经提出了许多数据库模型。例如，参见Rahayu等人：Representation of multilevel composite objects in relationaldatabases.OOIS′98，Proceedings of the 1998 International Conference on ObjectOriented Information Systems，pp221-238)，或Zhang等人：On SupportingContainment Queries in Relational Database Management Systems，ACM.Sigmod Record，vol.30，no.2(2001)，pp425-36。但是，对于插入描述符、读取部分描述符、读取全部描述符、和进行快速文本查询，还不知道有什么数据库模型能够以快速方式处理各种类型的描述符。
【发明内容】
因此，本发明的一个目的是提供将包括描述符的分层数据格式映射到关系数据库管理系统的方法。本发明的另一个目的是提供利用这样方法的数据库模型和读写记录媒体的设备。
根据本发明，描述符被分离成存储在关系数据库中的关系中的公用格式的部分。该方法具有与所存储描述符的结构无关的优点。对于存储所有类型的描述符格式，只需要有限数量的公用格式。公用格式包括，例如，元素、属性、文本等。这样，每个描述符被逐字分析，被分离成它的不同成分，和被存储在最好是表格的关系中。
该方法可以通过为公用格式提供独立关系得到进一步改善。每次查询只使用这些关系。例如，第一关系只包含文本，而第二关系包含元素等。这样，由于关系数有限，使查询快速简单。如果，例如，必须进行文本查询，只需搜索包含文本的关系。虽然为所有公用格式提供独立关系是优选的，但同样也可以将一种关系用于多于一种的公用格式。例如，可以将元素和属性一起存储在第一关系中，而将文本存储在第二关系中。
根据本发明的改进，本发明进一步包括将使描述符结构得到恢复的信息存储在关系中的步骤。当只将查询传送到单个数据库入口时，可以恢复属于特定数据库入口的描述符的整个结构。
优选地，使描述符结构得到恢复的信息包括描述符号和描述符内公用格式的部分的相对和/或绝对位置。利用这个信息，可以从数据库中收集适当值和以有用方式分类这些值。每当将描述符存储在数据库中时，它接收单义的描述符号。另外，为描述符的公用格式的每个部分导出描述符内的相对位置和/或关系内的绝对位置。将描述符号和相对和/或绝对位置与公用格式的部分一起存储在关系中。
优先地，使描述符结构得到恢复的信息进一步包括描述符内公用格式的部分的次高分层的指示符。这有助于通过从描述符的任何部分开始往回(层取向)到描述符的头部，快速重构描述符部分。当，例如，作为查询结果，只知道公用格式的部分的相对或绝对字位置时，次高分层是重构描述符部分的有用信息。
根据本发明的另一个方面，该方法进一步包括将描述符索引存储在关系数据库中的步骤。这样的描述符索引允许为每个描述符存储附加信息和在数据库中容易找到特定描述符。
优选地，描述符索引至少包括描述符号、关系内的绝对位置和/或描述符的唯一标识符。将这个信息存储在描述符索引中使快速访问关系中的特定描述符成为可能。关系内描述符的绝对位置被优先定义为它的公用格式的第一部分的绝对位置。由于经常需要唯一标识符，通过将唯一标识符存储在描述符索引中提供了对这种类型数据的更快速访问。除了提到的信息之外，其它类型的信息也可以存储在描述符索引中，例如，描述符的层数或其它有用数据。
优先地，包括描述符的分层数据格式对应于可扩充标记语言。由于XML得到广泛使用和良好接受，这使本发明的方法得到广泛应用成为可能。
根据本发明，公用格式至少包括元素、属性和文本。公用格式的这些类型对于许多应用足够了。虽然文本主要用于结构描述符，但文本包含在查询中通常搜索的信息。属性大多用于表示元素的特征。
优先地，公用格式文本被进一步划分成串值和整数值。这样，由于为了查询而必须搜索的关系变得更少了，可以实现更快速的搜索。例如，对串值的查询是在比包含串值和整数值两者的关系包含更少元素、只包含串值的关系中进行的。
优选地，公用格式进一步包括名称空间信息。这个特征对于XML尤其重要，并且，当打算用于一个文档的标记使用与用于不同用途的另一个文档相同的元素类型或属性名称时，使避免不同文档之间的冲突成为可能。
优先地，将包括描述符的分层数据格式映射到关系数据库管理系统的数据库模型使用根据本发明的方法。这样的数据库模型能够实现简单快速的查询、各种各样描述符格式的灵活管理、描述符的简单快速重构、和描述符的简单快速插入。另外，这样的数据库模型可以容易地借助于现有关系数据库管理系统来实现。
优选地，读写记录媒体的设备使用根据本发明的将包括描述符的分层数据格式映射到关系数据库管理系统的方法或数据库模型。这样的设备允许将额外值信息存储在现在关系数据库中。设备的用户可以容易地使用和/或编码额外值信息。
【附图说明】
为了更好地理解本发明，在将XML用作分层数据格式的例子、参照附图的优选实施例的如下描述中将详细说明示范性实施例。不言而喻，本发明不局限于这些示范性实施例，并且，也可以方便地对详细说明的特征加以组合和/或修改，而不偏离本发明的范围。在附图中：
图1a和1b示出了简化XML描述符和它作为XML树的表示；
图2示出了根据本发明的利用单个关系的数据库模型；
图3示出了像图2中那样的数据库模型，但其中存储有关描述符结构的附加信息；
图4a和4b示出了像图1中那样的XML描述符的表示，但其中文本包括串值和整数值；
图5示出了与图2相似的数据库模型，但其中元素、属性、整数值、和串值被分离成不同关系；
图6示出了与图3相似的数据库模型，但其中通过提供附加关系，消除了关系内的重复；
图7示出了包括名称空间信息、唯一标识符、和与其它元数据描述符的链接的典型元数据描述符；
图8示出了包括多个元数据描述符的元数据流；和
图9示出了包括描述符索引、根据图6的数据库模型。
【具体实施方式】
图1在a)部分中示出了XML描述符10的简化例子和在b)部分中示出了作为XML树的相应表示。从图中可以看出，示范性描述符10包括每一个都有标题的段、子段、和孙段(sub-subsaction)。孙段的标题具有值为“down”的属性“arrow”。描述符10总共由17个字组成，其中，每个标题的文本作为单个字来计数，与实际字数无关。例如，“Leonardo is swimming”是单个“逻辑”字，尽管它包括三个“实际”字。该图的a)部分中描述符10的每行给出的数字是描述符10内每行的第一字的相对字位置。从该图的b)部分的相应树结构中可以看出，描述符10有5个层，即，层0到层4。树结构是例示描述符10的不同字之间的分层关系的有用工具。
在图2中，示出了根据本发明的数据库模型，其中使用了单个关系20。关系20用表格表示。第1列“值”表示存储部分本身(XML字符串)。第2列“Descr#”表示数据库管理系统内的单义(univocal)描述符号。列“字位置”包含特定描述符10内存储部分的相对位置。放在一起的“Descr#”和“字位置”是关系20的主关键字，使描述符10可以完全得到恢复。每个XML字符串的类型内含地存储在关系20中的列“类型”中。在本例中，类型包括“元素”、“属性”和“文本”。最后一列“层”包含如图1b所示的每个XML字符串的分层。可以看出，并非描述符10的所有字都存储在关系20中。像</title>和</section>那样的“关闭”字不包含附加信息，和未必是恢复描述符10所需要的。因此，它们没有存储在数据库中。当然，如有必要，也可以存储这些字。
图3示出了与图2相似的数据库模型，但其中附加列“次高分层字位置”包括在关系20中，“次高分层字位置”包含特定描述符10内XML字符串的次高分层字的指示符。例如，作为查询结果，当只知道公用格式的部分的字位置时，这是用于恢复构描述符部分的有用信息。
在图4中，示出了与图1中的那个相似的另一个简化描述符11。但是，在本例中，文本由串值和整数值组成。从图的b)部分可以看出，串值和整数值是分离的，并且作为不同“逻辑”字来计数。
图5描绘了与图2所示的那一个相似的数据库模型。但是，在本例中，XML字符串被分离成元素、属性、串值和整数值，并且存储在不同关系22、23、24、和25中。这允许关系22、23、24、和25内进行更快速搜索。由于描述符号和字位置，仍然可以从不同关系22、23、24、和25中恢复整个描述符11。在这个实施例中，值“类型”不是必需的，因为每个关系22、23、24、和25只包含特定类型。
在图6中，示出了根据本发明的数据库模型的进一步改进。数据库模型与如图3所示的那一个相似，但是，消除了关系31内的重复。这是通过为元素、串和整数值、和属性提供附加关系32、33、34、和35(“次要关系”)实现的。对于每个XML字符串，值“类型”和相应描述符关键字“Descr.Key”包括在“主”关系31中。描述符关键字为特定类型的XML字符串指示附加关系32、33、34、和35中的相应条目(entry)。放在一起的列“类型”和“描述符关键字”可以当作次关键字，因为它们将主关键字指定的每个XML字符串与特定值链接。
图7示出了典型元数据描述符1。元数据描述符的实际内容包含在core 6中。另外，元数据描述符1包括名称空间说明2、唯一标识符4、和到其它元数据描述符的链接5。因为经常需要它们，所以名称空间说明2和唯一标识符4被存储在数据库管理系统内的特殊空间中。目的是提供对这种类型数据的快速访问。名称空间说明2只对特定元数据描述符1有效。唯一标识符4使元数据描述符1得到明确标识。
图8描绘了包括多个像如图7所示的那个那样的元数据描述符1的元数据流7。另外，元数据流7包括对特定元数据流7内的所有元数据描述符1有效的名称空间说明2。
在图9中，示出了描述符索引40的使用。对于存储在数据库中的每个描述符，描述符索引40包含描述符号、描述符层数(“Max Level”)、它的唯一标识符(“UUID”)、和它在关系41内的绝对位置(“Abs.Pos.”)。相应关系41与如图6所示的那个相似。但是，它进一步包括每个XML字符串的绝对位置和名称空间说明。为了简单起见，未示出通过次关键字寻址的、包含元素、串值、整数值等的附加关系。
如图所示的数据库模型存在多个优点，譬如：
-通过将输入XML流分离成公用格式，存储各种类型的描述符的灵活性。
-由于有限关系数造成的快速查询。例如，只需在像“串值”或“元素”那样的少量关系中，即，只在存储字符串那样的关系中进行文本查询。
-由于有限关系数，这样的数据库模型到数据库管理系统的快速实现。其它数据库模型对于每种描述符类型，至少需要一个关系。
-由于数据库的特定模型化，即，通过使用属性“Descr#”和“字位置”，描述符回到XML格式的快速恢复。
-通过提供附加信息“次高字位置”，描述符部分的快速恢复。当从描述符的任何部分开始往回(层取向)到描述符的头部时，这是有用的。