掌桥专利:专业的专利平台
掌桥专利
首页

计算机实现文档的基于关系显示

文献发布时间:2024-04-18 20:02:18


计算机实现文档的基于关系显示

背景技术

计算机正被用于越来越复杂的任务,包括在没有计算机帮助的情况下即使不是不可能也很困难的任务。例如,软件应用允许用户创建、编辑、查看文档,以及以其他方式与文档交互。文档可以是与一个或多个数据源相关联的数据集合,诸如关系数据库系统中的一个或更多表或视图。

通常,文档具有顺序关系,诸如时间顺序。此外,文档可以与其他文档的关系超出简单的时间顺序。例如,一个文档可能会影响另一文档的状态,可以是创建或编辑状态,也可以更改指示文档在工作流或其他处理中的状态的某些值。然而,当所分析的文档数量的增加时,按时间顺序显示文档视图可能会使人难以理解数据的含义,诸如用户界面中提供的结果,包括确定文档中是否存在错误,或者文档相关联的处理是否有问题。因此,仍有改进的余地。

附图说明

图1是示出与驾驶员事故历史记录相关的数据模式的示例实体关系(ER)类型图;

图2是示出数据库模式的元素以及它们如何相互关联的图;

图3示出具有数据字典的数据库环境;

图4示出元数据模型的定义;

图5示出元数据模型如何依赖于其他元数据模型;

图6示出可实现所公开技术的示例计算环境;

图7是示例逻辑数据对象模式的示意图;

图8示意性地描绘了两个星型模式;

图9示出数据库环境的示例;

图10示出相关文档随时间的显示;

图11A示出如何关联文档;

图11B示出文档如何与多个其他文档相关,包括具有不同关系类型的文档;

图12是列出不同类型关系的表,包括从给定关系中的两个文档的角度来看;

图13A和图13B是相关文档的层级列表(诸如树状层级);

图14示出用于识别指定文档上游的文档的处理;

图15示出用于定位给定文档下游的文档的下游搜索处理;

图16示出搜索给定文档的上游和下游两个文档的处理;

图17示出用于获取关于给定源文档的两个系统的层级的示例处理;

图18示出与图17中的处理类似的处理,但也包括识别和处理根文档的组合上游/下游搜索;

图19示出用于确定特定单据是否已“清除”的流程图;

图20A和图20B分别示出可用于实现下游搜索处理和组合上游和下游搜索处理的示例代码;

图21是允许用户查看、定义、更新或删除关系类型的示例用户界面屏幕;

图22示出与之相关联的示例关系类型和示例关系优先级值;

图23A是使用文档0100000177作为起点的示例上游搜索结果;

图23B是使用文档180000260作为起点的示例下游搜索结果;

图23C是使用文档1400000044作为起点的上游和下游搜索结果的组合示例;

图24A-图24R提供了公开技术的特定实现的示例实现细节;

图25描绘了可实现所述创新的合适计算系统的一般示例;以及

图26描述示例云计算环境,其中可以实现所述技术。

具体实施方式

示例1-概述

本公开提供识别文档之间关系的技术,并可用于向用户提供报告或其他数据可视化,使用户能够更好地了解文档是如何关联的,包括它们如何与特定处理或子处理关联。在某些情况下,文档之间的关系可用于过滤相关结果,以便向用户提供更小、更相关的数据集。除了识别文档和可选地显示文档之间的关系之外,可以显示关于文档的信息,以帮助用户了解处理是如何发生的以及任何错误的可能来源。例如,显示可以包括各种文档属性(或字段,可以对应于关系数据库表中的属性或字段)的数据。文档信息还可以包括文档类型或关于文档状态的信息,包括基于该文档与其他文档的关系的信息。

在某些情况下,文档可能具有相互关系。例如,可以复制特定文档。原始文档可以与副本具有“复制到”关系,而副本文档可以与原始文档具有“被复制自”关系。这些关系可用于多种用途,包括找到给定文档的“上游”或“下游”文档。对于原始文档和副本文档,可以将副本视为原始文档的下游,而将原始文档视为副本的上游。

在各种情况下,知道哪些文档是给定文档的上游、下游或上游和下游两者是有用的。用户或处理可以指定特定搜索类型,特定启动文档以及可选地,文档识别处理的其他处理。例如,用户可以选择是否或在多大程度上遵循文档树的“分支”。在一个示例中,用户可以指定搜索给定文档的上游和下游二者的搜索,诸如识别给定文档上游的“根”文档,然后查看从根下游的文档,即使这些文档与给定文档不在同一分支上。

示例2-9示出系统中可能存在的各种软件/数据层,诸如从存储数据的级别(诸如关系数据库表)到上层,其中用户更有可能与基础数据进行交互。例如,用户通常不会直接访问数据库表,而是可以通过更高级别的计算对象(诸如引用数据源(诸如关系数据库)的虚拟数据模型中的对象)或逻辑数据对象(诸如在德国Walldorf的SAP SE提供的技术中实现的BusinessObject)访问数据。示例10描述了可以与公开技术一起使用的示例数据库环境。例如,文档信息可以存储在数据库中,以及用于识别和遵循文档关系的信息,以及获得有关文档属性、文档类型或文档状态信息的信息。示例11-17示出用于识别相关文档并向用户提供此类信息的创新技术。

示例2-具有技术关系的示例数据库架构

图1是示出与驾驶员事故历史记录相关的数据模式100的示例实体关系(ER)类型图。模式100(可以是更大模式的一部分,图1中未显示的其他组件)可以包括与许可证持有人相关的表108(例如,具有驾驶执照的个人)、与许可证相关联的表112表示事故历史记录的表116以及表示汽车(或其他车辆)的表120。

表108、112、116、120中的每一个可以包括多个字段124。每个字段124可以与技术信息相关联,诸如名称或标识符126,Datatype(数据类型)128和指示字段是否表示主键的标志或状态指示器130,指示与另一表的外键关系,或指示与另一表的另一类型技术关系。标志130表示可以用于链接两个或多个表的技术信息,包括链接特定表格的特定字段124。状态指示器130可以是两个表之间的固有关系的指示器(或更一般而言,两个数据库对象之间)。

带有技术信息的模式信息通常被维护在数据库层中,诸如与维护表值的位置相关联的软件层(例如,在RDBMS中),并且通常包括表108、112、116、120的标识符及其相关字段124的名称126和数据类型128。模式信息还可以包括使用标志130可传送的至少一些信息,诸如字段是否与主键相关联,或者指示外键关系。然而,其他关系,包括更多非正式关联,可能不包括在与数据库层相关的模式中(例如,PostgreSQL的INFORMATION_SCHEMA)。

数据库层模式信息通常不包括语义信息。尽管在显示的特定示例中,字段124具有至少暗示其内容含义的名称126,但在许多数据库模式中,这些字段没有传达字段含义的名称。无论如何,具有相同语义信息的字段124,或至少具有一些共同的语义信息可能具有不同的技术信息。例如,字段124a具有为“Plate Number”的名称126a,其语义含义可能与具有“License Plate”的名称124b的字段124b的语义含义相同或不同。在数据库中搜索关于“License Plate”的信息可能会检索与名称126b相关联的记录,但可能会错过具有名称126a的记录。反之亦然,搜索“License Plate”可能会从两个表中检索记录,即使该术语在两个字段中具有不同的语义。也就是说,两个字段可能会因巧合而同名(或者通过根本不关心此类冗余的设计)。

除了错过某些具有重叠或相同语义的记录,或者检索具有不同语义的记录之外,还有一个问题,即应该如何定位潜在相关的表。如上所述,尤其是对于大型复杂数据库系统,任何特定用户都可能难以完全了解整个数据库模式。技术用户可能对数据库的技术性质有更好的了解,但可能缺乏对数据的含义或语义信息的见解,以便从数据库中检索适当的数据。同样,非技术用户可能会了解他们想要的信息,但不能了解如何获得信息,包括不了解数据库模式或查询语言。尽管有可能通过技术关系(诸如外键关系)找到一些语义上相关的表,但此类搜索可能无法找到一些相关的表。

图1包括表140。表140与图1中所示的模式100的一部分中的任何其他表没有技术关系。此外,字段124c-124e的名称不容易传达其含义或目的,或者指示它们是否具有与模式100中其他字段124相同的含义或目的。例如,字段124c可能具有含义与字段124a相同的语义,字段124d可能具有与字段124f相同的含义,字段124e可能具有与字段124g相同的含义。因此,对字段124d的搜索可能会错过表140的结果,因为可能不知道应搜索表140,并且,基于不同的字段名称126,即使搜索中包括表140,也会错过表140中的结果。

示例3–包括语义标识符的示例表元素

图2是示出数据库模式200的元素以及它们如何相互关联的图。至少在某些情况下,除了数据库系统的数据库层之外,可以维护数据库模式200。也就是说,例如,数据库模式200可以独立于底层数据库,包括用于底层数据库的模式。通常,数据库模式200被映射到数据库层的模式(例如,图1的模式100),这样可以通过数据库模式200检索记录或其部分(例如,特定字段的特定值)。

数据库模式200可以包括一个或多个包210。包210可以表示用于对模式200的其他元素进行归类或分类的组织组件。例如,包210可以复制或部署到各种数据库系统。包210还可用于实施安全限制,诸如通过限制特定用户或特定应用对特定模式元素的访问。

包210可以与一个或多个域214相关联(即,特定类型的语义标识符或语义信息)。进而,域214可以与一个或多个包210关联。例如,域1 214a仅与包210a关联,而域2 214b与包210a和包210b关联。至少在某些情况下,域214可以指定哪些包210可以使用该域。例如,与制造过程中使用的材料相关联的域214可以由过程控制应用使用,但不能由人力资源应用使用。域可以是,或可以识别,固有关系的类型。请注意,对于本公开,“固有”关系可以是技术关系,也可以是语义关系,只要它们是对象的定义方面即可。

至少在一些实现中,尽管多个包210可以访问域214(以及合并域的数据库对象),但域(以及可选的其他数据库对象,诸如表218、数据元素222和字段226,如下面更详细地描述)主要分配给一个包。将域214和其他数据库对象分配给唯一的包可以有助于在数据库对象之间创建逻辑(或语义)关系。在图2中,域214对包210的分配显示为实线,而访问权限显示为虚线。因此,域214a分配给包210a,域214分配给包210。包210a可以访问域214b,但包210b无法访问域214。

请注意,至少某些数据库对象(诸如表218)可以包括与多个包关联的数据库对象。例如,表218(表1)可能被分配给包A,并且具有被分配给了包A、包B和包C的字段。在表1中使用分配给包A、B和C的字段创建包A与包B和C之间的语义关系,如果字段与特定域214相关联,则可以进一步解释哪个语义关系(即,域可以为与另一包的对象相关联的数据库对象提供进一步的语义上下文,而不是被分配给公共包)。

正如将要更详细地解释的那样,域214可以表示最细粒度的单元,从中可以构造数据库表218或其他模式元素或对象。例如,域214至少可以与数据类型相关联。每个域214与唯一的名称或标识符相关联,并且通常与描述相关联,诸如提供域语义的人类可读文本描述(或可以与人类可读文本说明相关联的标识符)。例如,一个域214可以是表示电话号码的整数值,而另一域可以是表示部件号的整数值;而另一整数域可以表示社会保险号。因此,域214有助于在模式200中提供通用和一致的用法(例如语义)。也就是说,无论何时使用表示社会保险号的域,即使字段或数据元素对于不同的表具有不同的标识符或其他特征,也可以将相应的字段识别为具有此含义。

模式200可以包括一个或多个数据元素222。每个数据元素221通常与单个域214关联。然而,多个数据元素222可以与特定域214相关联。虽然未显示,但表218的多个元素可以与同一数据元素222相关联,或可以与具有相同域214的不同数据元素相关联。除其他外,数据元素222可用于允许为特定表218定制域214。因此,数据元素22可以为表218的元素提供附加语义信息。

表218包括一个或多个字段226,其中至少一部分映射到数据元素222。字段226可以映射到数据库层的模式,或者表218可以以另一种方式映射到数据库层。在任何情况下,在一些实施例中,字段226以某种方式映射到数据库层。或者,数据库模式可以包括相当于模式200元素的语义信息,包括域214。

在一些实施例中,一个或多个字段226未映射到域214。例如,字段226可以与原始数据分量(例如,原始数据类型,诸如整数、字符串、布尔值、字符数组等)相关联,其中原始数据分量不包括语义信息。或者,数据库系统可以包括一个或多个表218,这些表不包括与域214相关联的任何字段226。然而,所公开的技术可以包括模式200(可以与数据库模式分离,也可以合并到数据库模式中),包括具有直接或通过数据元素222与域214相关联的至少一个字段226的多个表218。

示例4–示例数据字典分量

模式信息,诸如与图2的模式200相关联的信息,可以被存储在存储库中,诸如数据字典。如上所述,至少在某些情况下,数据字典独立于底层关系数据库,但映射到底层关系数据库。这种独立性允许同一数据库模式200被映射到不同的底层数据库(例如,使用不同供应商的软件的数据库,或同一供应商的不同软件版本或产品)。数据字典可以持久化,诸如在存储表中维护,也可以在存储器中维护,可以是全部或部分。数据字典的存储器版本可以称为字典缓冲区。

图3示出具有数据字典304的数据库环境300,可以通过诸如映射来访问数据库层308。数据库层309可以包括模式312(例如,PostgreSQL中的INFORMATION_SCHEMA)和数据316,诸如与表318相关联的数据。模式312包括各种技术数据项/组件322,可以与字段320相关联,诸如字段名称322a(可能对应于也可能不对应于人们容易理解的字段用途描述,或者以其他方式明确描述该字段值的语义),字段数据类型322b(例如,整数、可变长字符串、字符串、布尔值),长度322c(例如,字段中的值允许的数字大小、字符串长度等),小数位数322d(对于合适的数据类型,诸如,对于长度为6的浮点,指定值是代表XX.XXXX还是XXX.XXX),位置322e(例如,表中应显示字段的位置,诸如第一显示字段、第二显示字段等),可选地,默认值322f(例如,“NULL”、“0”或其他值),NULL标志322g,表示字段是否允许NULL值,主键标志322h,表示字段是否是表的主键或用于表的主键,以及外键元素322i,可以指示字段320是否与另一个表的主键相关联,并且可选地,外键元素引用的表/字段的标识符。与图3所示相比,特定模式312可以包括更多、更少或不同的技术数据项322。

表318与一个或多个值326相关联。值326通常与使用一个或多个技术数据元素322定义的字段320相关联。也就是说,每行328通常表示唯一的元组或记录,每列330通常与特定字段320的定义相关联。表318通常被定义为字段320的集合,并被赋予唯一标识符。

数据字典304包括一个或多个包334、一个或多个域338、一个或多个数据元素342和一个或多个表346,至少通常分别对应于图2中类似起标题的分量210、214、222、218。如图2的讨论中所解释的,包334包括一个或多个(通常是多个)域338。每个域338由多个域元素340定义。域元素340s可以包括一个或者多个名称340a。在某些情况下,名称340a用于唯一地标识特定域338。域338包括至少一个唯一名称340a,并且可能包括一个或多个可能唯一或不唯一的名称。名称可能是唯一的,也可能不是唯一的,可以包括域338的名称版本或描述,其长度或详细程度各不相同。例如,名称340a可以包括可用作域338标签的文本,也可以包括短、中、长版本,以及可以指定为标题的文本。或者,名称340a可以包括主名称或标识符以及简短的描述或字段标签,为域338提供人类可以理解的语义。

至少在某些情况下,数据字典304可以以多种语言存储名称340a的至少一部分,诸如具有可用于多种语言的域标签。在所公开技术的实施例中,当域信息用于识别表或其他数据库元素或对象之间的关系时,包括搜索特定值,可以搜索多种语言的信息,诸如名称340a。例如,如果指定“customer”,则可以搜索名称340a的德语和法语部分以及英语版本。

域元素340还可以包括至少与模式312中包含的信息类似的信息。例如,域元素340s可以包括数据类型340b、长度340c和与相关数据类型相关联的若干小数位340d,分别对应于技术数据元素322b、322c、322d。域元素340可以包括转换信息340e。转换信息340e可用于转换(或相互转换)为域338输入的值(可选地包括由数据元素342修改的值)。例如,转换信息340可以指定格式为XXXXXXXXX的数字应转换为XXX-XX-XXXX,或者数字应使用小数或逗号分隔不同的数字组(例如,将1234567格式化为1234567.00)。在某些情况下,多个域338的字段转换信息可以存储在存储库中,诸如字段目录。

域元素340可以包括一个或多个值限制340f。例如,值限制340f可以指定允许或不允许负值,或者指定域338可以接受的值的特定范围或阈值。在某些情况下,可以提供错误消息或类似指示,因为试图将值用于不符合值限制340f的域338。域元素340g可以指定允许使用域338的一个或多个包334。

域元素340h可以指定记录与域元素338相关联的创建或修改事件的元数据。例如,域元素340h可以记录上次修改域元素340h的用户或应用的身份,以及修改发生的时间。在某些情况下,域元素340h存储域338的创建和修改的更大历史记录,包括完整历史记录。

域元素340i可以指定与域338相关联的原始语言,包括名称340a。例如,当要确定名称340a是否应转换为另一种语言,或者如何完成这种转换时,域元素340i可能很有用。

数据元素342可以包括数据元素字段344,其中至少一些字段通常至少与域元素340相似。例如,数据元素字段344a可以对应于名称域元素340a的至少一部分,诸如是(或包括)特定数据元素342的唯一标识符。关于名称域元素340a描述的字段标签信息被显示为分为短描述标签344b、中等描述标签344c、长描述标签344m和标题描述344e。如名称域元素340a所述,标签和标题344b-344e可以用一种语言或多种语言维护。

数据元素字段344f可以指定与数据元素342一起使用的域338,从而将域元素340的特征合并到数据元素中。数据元素字段344g可以表示数据元素342的默认值,并且至少可以类似于模式312的默认值322f。创建/修改的数据元素字段344h至少可以大致类似于域元素340h。

表346可以包括一个或多个表元素348。表元素349的至少一部分可以至少与域元素340相似,诸如表元素348a至少大致类似于域元素340a,或者数据元素字段344a。描述表元素348b可以类似于结合域元素340a描述的描述和标题标签,或标签和标题数据元素字段344b-344e。表346可以使用表元素348c与类型相关联。示例表类型包括透明表、集群表和池表,诸如在德国Walldorf的SAP SE提供的数据库产品中使用。

表346可以包括一个或多个字段表元素348d。字段表元素348d可以定义特定数据库表的特定字段。每个字段表元素348d可以包括用于字段的特定数据元素342的标识符350a。标识符350b-350d可以指定字段是表的主键(标识符350b)还是主键的一部分,或者与另一数据库表的一个或多个字段有关系,诸如外键(标识符350c)或关联(标识符350d)。

创建/修改的表元素348e至少大致类似于域元素340h。

示例5–元数据模型示例

图4示出元数据模型400的定义。元数据模型400特别代表视图,诸如德国Walldorf的SAP SE的Core Data Services视图。元数据模型400可以包括各种不同的组件,其中至少一些可以被视为元数据模型。也就是说,元数据模型400可以是至少部分基于多个子模型的模型。子模型可以指定整个元数据模型400的特定方面。

元数据模型400可以选择性地包括一个或多个注释404。注释可以是可以添加到元数据模型的元数据组件。例如,提供者可能提供基本模型,个别用户或客户可能希望添加特定于其操作环境和用例的元数据。因此,添加注释的能力可以通过允许自定义元数据元素来增强可用性,而不会影响基本元数据模型的其他用户。可以为不同的软件层或框架指定注释。

在所示示例中,注释404可以表示为使用特定语法元素的注释,诸如在注释前面加上“@”符号。至少在某些情况下,注释404还可以通过将其放在元数据模型的适当部分来表示,诸如放在标题部分或为注释指定的另一部分中。在某些情况下,注释404可以引用其他元数据模型,诸如数据源的元数据模型,或者可以引用与元数据模型关联的数据源。无论哪种情况,这样的关联404都可以在元数据模型400和其他元数据模型/数据源之间创建依赖关系。

元数据模型400可以包括指令408,在这种情况下是SQL语句410,定义具有标识符412的核心元数据模型/对象(可以用于稍后访问或激活,诸如实例化元数据模型)。特别是,所示的说明408定义了视图。注释404进一步指定视图的属性,元数据模型400的其他部分也将进一步描述。

指令408可以指定一个或多个数据源416。数据源417可以定义元数据模型400的元数据的至少一部分将应用于的数据,并且还可以为元数据模型400提供额外的元数据。注意,元数据模型400在某种意义上可以依赖于引用的数据源416。例如,如果元数据模型400依赖于数据源416的特定期望数据或元数据,则元数据模型可能不可用,存在性能问题,或者如果所引用的数据源不包括期望数据或元数据,或者与数据源在元数据模型中的使用方式不一致,则提供不正确的结果。如图所示,数据源416包括两个表“vbak”和“vbkd”。这些表通常包括元数据功能,诸如一个或多个字段,其中每个字段与数据类型关联,主键的指定,以及可选的与其他数据库组件的关联,诸如与其他数据库表的关联或外键关系。

元数据模型400可以选择性地包括一个或多个关联420的规范。关联420可以定义与另一实体的关系。在使用元数据模型400期间,可以处理关联420,诸如将其转换为SQL表达式,诸如JOIN。与元数据模型400中包括的其他条件或元素不同,关联可以定义至少在某些情况下是可选的关系,诸如根据元数据模型的访问方式选择性激活。例如,关联420可以转换为JOIN条件,使用引用元数据模型400的SELECT语句中提供的表。

元数据模型400可以包括一个或多个组件422,用于指定如何处理使用元数据模型检索的数据,包括生成与元数据模型的其他元数据元素关联的值。处理可以包括计算值,诸如使用元数据模型400中指定或引用的公式。特别是,处理组件422可以指定将特定字段值视为元素424。因此,元数据模型400可以包括对元素定义方式的依赖关系,如果元素定义与元数据模型400中的使用方式和预期使用方式不匹配,则元数据模型400可能不准确或不可用。

元数据模型400可以选择性地包括其他组件,诸如一个或多个条件428,或其他操作,诸如聚合、联合等,包括数据库查询语言通常支持的此类操作。除了实例化的工件外,关于工件的信息可以存储在持久性模型中,诸如一个或多个数据库表。2019年4月18日提交的美国专利申请No.16/387,983中公开了可与伪影一起使用的示例持续性模型,并通过引用将其并入本文。

示例6–元数据模型示例,包括与其他元数据模型的关系

图5示出元数据模型如何依赖于其他元数据模型。具体而言,图5示出视图元数据模型504,可以是图4的元数据模型400。图5还示出访问控制对象(诸如DCLS或数据控制语言源)的元数据模型508,元数据扩展对象(诸如DDLX或元数据扩展)的元数据模型512,以及扩展元素对象(诸如DDLS或数据定义语言源)的元数据模型516。

访问控制对象元数据模型508可用于限制对可使用视图元数据模型504检索的数据的访问。例如,当视图元数据模型504被激活时,可以一起处理视图元数据模型404和访问控制对象元数据模型508,诸如生成检索视图元数据模型数据的SQL命令,但是它们是基于访问控制对象元数据模型进行过滤或限制的。由于访问控制对象元数据模型508引用视图元数据模型504,因此访问控制对象元数据模型依赖于现有视图以及包含访问控制对象图元模型中指定的元素的视图。例如,访问控制对象元数据模型引用视图“I_SampleSalesOrder”的“SalesOrderType”元素和授权对象“V_VBAK_AAT”及其授权字段“AUART”。因此,如果视图元数据模型504中不存在对应元素,则第一元素将是未定义的或不可用的。

示例7–虚拟数据模型与数据库系统交互的计算环境示例

图6示出可实现所公开技术的示例计算环境600。在上层,计算环境600包括数据库系统604,可以与应用层或框架层608通信。数据库系统605包括可以由应用/框架层609或与应用/架构层通信的应用使用的数据。数据可以存储在数据库608的一个或多个表612中。数据可以由一个或更多视图616引用,这些视图可以是视图定义或物化视图(也可以对应于表612)。数据字典620可以存储关于表612和视图616的信息。

应用/框架层608包括虚拟数据模型630。虚拟数据模型630可以包括实体634和视图638,至少通常对应于数据库608的表612和视图616。然而,如上所述,与表612及视图616相比,虚拟数据模型630中的伪像通常与附加信息相关联,诸如对应于虚拟数据模型中的给定伪像的语义信息或可用于操作数据库608中一个或多个伪像中的数据的信息。虚拟数据模型630可以包括有关元素642的信息,可以对应于实体634和视图638中使用的属性或字段。至少一些元素642可以对应于数据库604中使用的字段,但会添加附加信息。有关实体634、视图638和元素642的信息可以存储在虚拟数据模型630的数据字典646中。

通常,如本公开中所使用的,数据伪像是指虚拟数据模型630中拟供用户或应用直接使用的伪像。数据伪像可以包括数据元素,包括那些引用存储在数据库604中的数据的元素。然而,数据伪像也可以包括元数据元素,可以描述数据元素,或者描述数据伪像的使用方式或处理方式。数据元素和元数据元素可以统称为伪像的分量。

示例8–示例逻辑数据对象模式

在本文描述的任何示例中,逻辑数据对象是面向对象编程方法中对象的特定示例。然而,除非上下文另有明确指示,否则本公开中关于逻辑数据对象的各方面可以应用于其他类型的对象或其他类型的数据集合。例如,数据库表或一组相关表可以具有类似于对象的数据成员的字段。可以定义与对象的成员函数相对应的函数来对表执行操作。

逻辑数据对象可以包含层级数据结构的定义,以及可以使用层级数据结构部分执行的一个或多个操作的定义。在某些情况下,逻辑数据对象可以被称为“业务对象”,可以采取多种形式,包括商业智能或性能管理组件,诸如SAP BusinessObjects、ORACLEHyperion、IBM Cognos等软件技术中实现的组件。然而,在计算机应用中使用逻辑数据对象并不限于“业务”场景。逻辑数据对象可用于定义特定应用和/或问题域空间。可以使用层级数据结构定义给定问题域的方面和伪像,这些方面和/或伪像的各个部分可以直接与相关逻辑操作的定义相关联。逻辑数据对象可以是虚拟数据模型的伪像,也可以参考虚拟数据模型的伪像来构造。进而,虚拟数据模型的组件可以映射到另一数据模型,诸如关系数据库系统的物理数据模型。

图7是示例逻辑数据对象模式700的示意图。节点710可以包含一个或多个数据元素720(即变量,诸如数据成员)。数据元素720可以包含标识符,诸如名称和关联值。例如,标识符可以与特定数据库表的字段相关联。在至少一些实施例中,数据元素720可以与限制和/或验证可以存储为数据元素720的值的数据的类型的数据类型相关联。

节点710可以包含一个或多个孩子节点725(也称为子节点),子节点本身可以包含附加数据元素720(以及其他节点组件,包括子节点725)。子节点725的组合可用于定义多个节点710的层级数据结构。在至少一些实施例中,层级数据结构可以包含没有父节点的根节点,并且可以用作遍历层级数据结构的入口点。

逻辑数据对象中的每个节点710可以与一个或多个动作730相关联。动作730可以包含可以使用与其关联的节点710执行的逻辑操作的定义。动作730可以包含标识符,用于调用操作的逻辑操作。逻辑数据对象中的每个节点710可以与一个或多个确定740相关联。确定740可以包含可以在满足触发条件时自动执行的逻辑操作的定义。示例触发条件可以包括修改关联节点710、修改关联节点的数据元素720、创建关联节点的数据库元素720等。由动作730或确定740定义的逻辑操作可以包括创建、更新、读取和/或删除一个或多个数据元素720和/或一个子节点725。在某些情况下,动作730或确定740可设置为在特定日期(例如,特定日期或特定日期的特定时间)发生时触发。

逻辑数据对象模式700中的每个节点710可以与一个或多个验证750相关联。验证750可以包含一个或多个数据完整性规则和/或检查的定义。创建、修改和/或删除关联节点710和/或关联节点的一个或多个数据元素720时,可以执行一个或多个数据完整性规则和/或检查。任何不满足一个或多个数据完整性规则和/或检查的操作都可以被拒绝。

逻辑数据对象模式700中的每个节点710可以通过一个或多个关联760与一个或多个其他逻辑数据对象(具有相同模式或不同模式)中的一个或多个节点关联。关联760可以包含与节点710相关联的另一逻辑数据对象中节点的标识符。关联766可以用于定义关系在各种逻辑数据对象的节点之间的关系。在至少一些实施例中,关联760包含关联类型指示符,用于识别节点710和其他逻辑数据对象中的节点之间的关联类型。

虽然动作730被定义并与节点710相关联,但当调用动作730时,它会指向与其关联的节点710的已标识实例。类似地,可以定义确定740和/或验证750,并将其与节点710相关联,但可以在调用关联节点710的实例时将其作为目标。可以独立创建和访问给定逻辑数据对象的多个实例。动作730、确定740或验证750可能对应于数据对象的成员函数,诸如在C++类中实现的函数。

虽然逻辑数据对象的实例共享公共模式700,但是存储在相应节点实例和数据元素实例中的数据值可能不同,关联760相关联的逻辑数据对象实例也可能不同。另外地或可选地,关联760的实例可以识别另一逻辑数据对象实例中关联节点的特定实例。节点实例的标识符可以是唯一标识实例的字母数字字符串,至少在某些情况下,可以用于查找实例和/或检索与实例关联的数据。标识符的具体示例包括数值和通用唯一标识符。然而,也可以使用其他类型的标识符。

可以使用逻辑数据对象执行各种操作,包括创建、更新、删除、读取和查询操作。如果请求的操作是读取操作,则数据有效载荷可能包含与要检索的逻辑数据对象实例相关联的唯一标识符。处理读取操作请求可以包括搜索与数据存储中提供的唯一标识符相关联的逻辑数据对象的实例,以及从数据存储中检索匹配逻辑数据对象实例的全部或部分数据。如果请求的操作是更新操作,则数据有效载荷可能包含一个或多个要分配给现有逻辑数据对象实例的数据元素实例的值。数据有效载荷还可能包含与要更新的逻辑数据对象实例相关联的唯一标识符。处理更新操作请求可以包括在与提供的唯一标识符相关联的数据存储中搜索逻辑数据对象实例,并使用提供的数据值更新匹配的逻辑数据对象示例。

示例9–示例关系数据库模式

图8示意性地描绘了两个星型模式810、820。星型模式820包括中心事实表114和三维表818。星型模式820包括中央事实表824和四维表828。

为了从多个星型模式中获得数据,使用对两个事实表共同的维度表来桥接这两个模式。在某些情况下,如果一个维度表是其他维度表的子集(例如,一个表包含另一个表的所有属性,加上一个或多个附加属性),则可能会发生这种桥接。在其他情况下,只要两个星型模式之间至少有一个属性是共享的或一致的,就可以进行桥接。

例如,在图8中,维度表818a与维度表828a相同(除了可能的记录ID或其他识别不传递实质性信息的元组的方法)。或者,维度表818a和维度表828a可以是同一个表,而不是重复的表,但可以表示为多个星型模式的成员。维度表818a、828a中的每个属性都可以作为事实表814中事实和事实表824中事实之间的路径。然而,这些路径都是不同的,因为不同的属性链接在一起。使用哪些属性链接维度表818a和828a可能很重要。例如,实现路径的操作(例如,由SQL语句指定)可能不同。此外,有些路径可能使用索引属性,而其他路径则不使用,这可能会影响特定路径的执行速度。

在图8的示例场景中,从事实表814和824获取事实的另一种方法是通过使用维度表818b的属性840和维度表828b的属性844。然而,如图8所示,表818b包括比表818a更多的元组,这可能导致涉及表818b的路径比涉及表818a的路径具有更长的执行时间,并且需要更多的计算资源。

示例10–可用于实现公开创新的示例数据库系统

数据库系统通常使用在线事务处理(OLTP)工作负载(通常面向事务)或在线分析处理(OLAP)工作负载(通常涉及数据分析)进行操作。OLTP事务通常用于核心业务功能,诸如输入、操作或检索操作数据,用户通常希望事务或查询能够快速完成。例如,OLTP事务可以包括诸如INSERT、UPDATE和DELETE的操作,以及相对简单的查询。OLAP工作负载通常涉及用于企业资源规划和其他类型的商业智能的查询。OLAP工作负载通常很少(如果有的话)对数据库记录进行更新,相反,它们通常读取和分析过去的事务,通常数量很大,因为OLAP处理可能涉及对大量记录的复杂分析。

图9示出数据库环境900的示例。数据库环境900可以包括客户端904。尽管显示了单个客户端904,但客户端904可以表示多个客户端。客户端904可以是OLAP客户端、OLTP客户端或其组合。

客户端904与数据库服务器906通信。通过各种子组件,数据库服务器905可以处理数据库操作请求,诸如存储、读取或操作数据的请求。会话管理器组件908可以负责管理客户端904和数据库服务器906之间的连接,诸如客户端使用数据库编程接口与数据库服务器通信,诸如Java数据库连接(JDBC)、开放数据库连接(ODBC)或数据库共享库(DBSL)。通常,会话管理器908可以同时管理与多个客户端904的连接。会话管理器808可以执行诸如为客户端请求创建新会话、将客户端请求分配给现有会话以及验证对数据库服务器906的访问权等功能。对于每个会话,会话管理器908可以维护存储与会话相关的参数集合的上下文,诸如与提交数据库事务或事务隔离级别(诸如语句级隔离或事务级隔离)相关的设置。

对于其他类型的客户端904,诸如基于web的客户端(诸如使用HTTP协议或类似传输协议的客户端),客户端可以与应用管理器组件910交互。虽然显示为数据库服务器906的组件,但在其他实现中,应用管理程序910可以位于外部,但可以与通信,数据库服务器906。应用管理器910可以以与会话管理器908类似的方式启动与数据库服务器908的新数据库会话,并执行其他功能。

应用管理器910可以确定做出数据库操作请求的应用的类型,并在数据库服务器906处调解请求的执行,诸如通过调用或执行过程调用、生成查询语言语句或在客户端904和数据库服务器906可用的格式之间转换数据。在特定示例中,应用管理器910接收来自客户端904的数据库操作请求,但不存储与请求相关的信息,诸如状态信息。

一旦客户端904和数据库服务器906之间建立了连接,包括通过应用管理器910建立的连接,客户端请求的执行通常使用查询语言,诸如结构化查询语言(SQL)。在执行请求时,会话管理器908和应用管理器910可以与查询接口912通信。查询接口912可以负责创建与数据库服务器906的适当执行组件的连接。查询接口912还可以负责确定请求是否与先前缓存的语句或存储过程相关联,并调用存储过程或将以前缓存的语句与请求相关联。

至少某些类型的数据库操作请求(诸如用于写入数据或操作数据的查询语言中的语句)可以与事务上下文相关联。至少在一些实现中,每个新会话都可以分配给事务。事务管理器组件914可以管理事务。事务管理器组件914可以负责诸如协调事务、管理事务隔离、跟踪正在运行和关闭的事务以及管理事务的提交或回滚的操作。在执行这些操作时,事务管理器914可以与数据库服务器906的其他组件通信。

查询接口912可以与查询语言处理器916通信,诸如结构化查询语言处理器。例如,查询接口912可以向查询语言处理器916转发来自客户端904的查询语言语句或其他数据库操作请求。查询语言处理器916可以包括查询语言执行器920,诸如SQL执行器,可以包括线程池924。一些数据库操作请求或其组件,可以直接由查询语言处理器916执行。其他请求或其组件可以由查询语言处理程序916转发给数据库服务器906的另一组件。例如,事务控制语句(诸如提交或回滚操作)可以由查询语言处理器916转发到事务管理器914。至少在某些情况下,查询语言处理器916负责执行检索或操作数据的操作(例如,SELECT、UPDATE、DELETE)。其他类型的操作,诸如查询,可以由查询语言处理器916发送到数据库服务器906的其他组件。查询接口912和会话管理器908可以维护和管理与数据库操作请求相关联的上下文信息。在特定实现中,查询接口912可以维护和管理通过应用管理器910接收的请求的上下文信息。

当通过会话管理器908或应用管理器910在客户端904和数据库服务器906之间建立连接时,可以将客户端请求(诸如查询)分配给线程池924的线程,诸如使用查询接口912。在至少一个实现中,线程与用于执行处理活动的上下文相关联。线程可以由数据库服务器906的操作系统管理,或者由数据库服务器的另一组件管理,或者与数据库服务器的另一组件组合管理。通常,在任何时候,线程池924都包含多个线程。至少在某些情况下,线程池924中的线程数可以动态调整,诸如响应于数据库服务器906上的活动级别。在特别方面,线程池925的每个线程可以分配给多个不同会话。

当接收到查询时,会话管理器908或应用管理器910可以确定查询的执行计划是否已经存在,诸如在计划缓存936中。如果存在查询执行计划,则可以检索缓存的执行计划并将其转发给查询语言执行器920,诸如使用查询接口912。例如,查询可以发送到由会话管理器908或应用管理器910确定的线程池924的执行线程。在特定示例中,查询计划被实现为抽象数据类型。

如果查询未与现有执行计划关联,则可以使用查询语言解析器928解析查询。例如,查询语言解析器928可以检查查询的查询语言语句,以确保它们具有正确的语法,并确认这些语句在其他方面是有效的。例如,查询语言解析器928可以检查在查询语言陈述中阐述的表和记录是否在数据库服务器906中定义。

还可以使用查询语言优化器932优化查询。查询语言优化器932可以操作查询语言语句的元素,以便更有效地处理查询。例如,查询语言优化器932可以执行一些操作,诸如取消查询或确定查询中各种操作的优化执行顺序,诸如语句中的操作。优化后,可以为查询生成或编译执行计划。至少在某些情况下,可以缓存执行计划,诸如在计划缓存936中,如果再次收到查询,可以被检索(诸如由会话管理器908或应用管理器910)。

在本公开中,查询语言优化器932可以执行的一项任务是确定应执行数据库操作请求或其一部分的位置。例如,可以提交从多个数据源读取数据的复杂查询。至少一个数据源可以是虚拟表,请求可以在锚节点上执行,诸如由实现数据库环境900的计算系统表示的节点,或另一节点,包括响应于数据库操作请求而动态创建的节点、另一数据库操作请求或者基于包括一个或多个节点的数据库系统的总体工作负载/性能(即,如果工作负载超过阈值,可以实例化非锚节点)。

一旦生成或接收到查询执行计划,查询语言执行器920就可以监督查询的执行计划的执行。例如,查询语言执行器920可以调用数据库服务器906的相应子组件。

在执行查询时,查询语言执行器920可以调用查询处理器940,可以包括一个或多个查询处理引擎。例如,查询处理引擎可以包括OLAP引擎942、联接引擎944、属性引擎946或计算引擎948。例如,OLAP引擎94可以应用规则为OLAP查询创建优化的执行计划。联接引擎944可用于实现关系运算符,通常用于非OLAP查询,诸如联接和聚合操作。在特定实现中,属性引擎946可以实现列数据结构和访问操作。例如,属性引擎946可以实现合并功能和查询处理功能,诸如扫描列。

在某些情况下,例如,如果查询涉及复杂或内部并行化的操作或子操作,则查询执行器920可以将查询的操作或子操作发送到作业执行器组件954,可以包括线程池956。查询的执行计划可以包括多个计划运算符。在特定实现中,作业执行线程池956的每个作业执行线程可以被分配给单个计划运算符。作业执行器组件954可用于并行执行查询的至少一部分运算符。在某些情况下,计划运算符可以被进一步划分和并行化,诸如让操作并发访问同一表的不同部分。使用作业执行器组件954可以增加数据库服务器906的一个或多个处理单元的负载,但可以改善查询的执行时间。

查询处理器940的查询处理引擎可以访问存储在数据库服务器906中的数据。数据可以以行存储962中的行格式存储,也可以以列存储964中的列格式存储。至少在某些情况下,数据可以在行格式和列格式之间转换。查询处理器940执行的特定操作可以访问或操作行存储962、列存储964中的数据,或者至少对于某些类型的操作(诸如联接、合并和子查询),行存储961和列存储962中的数据。至少在某些方面,行存储96 2和列存储96 4可以在主存储器中维护。

持久层968可以与行存储962和列存储964通信。持久层966可以负责诸如提交写入事务、存储重做日志条目、回滚事务以及定期将数据写入存储以提供持久化数据972等操作。

在执行数据库操作请求(诸如查询或事务)时,数据库服务器906可能需要访问存储在另一位置(诸如另一数据库服务器)的信息。数据库服务器906可以包括通信管理器980组件来管理此类通信。当应用管理器位于数据库服务器之外时,通信管理器980还可以调解数据库服务器906与客户端904或应用管理程序910之间的通信。

在某些情况下,数据库服务器906可以是包括多个数据库服务器的分布式数据库系统的一部分。至少一部分数据库服务器可能包括数据库服务器906的部分或全部组件。在某些情况下,数据库系统的数据库服务器可以存储多个数据副本。例如,可以在多个数据库服务器上复制表。此外,或可选地,数据库系统中的信息也可以在多个服务器之间分发。例如,第一数据库服务器可以保存第一个表的副本,第二数据库服务器可以保存第二表的副本。在进一步的实现中,信息可以在数据库服务器之间进行分区。例如,第一数据库服务器可以保存第一表的第一部分,第二数据库服务器可以存储第一表的第二部分。

在执行数据库操作请求时,数据库服务器906可能需要访问数据库系统内的其他数据库服务器或其他信息源。通信管理器980可用于调解此类通信。例如,通信管理器980可以接收和路由来自数据库服务器906组件(或其他数据库服务器)的信息请求,并接收和路由回复。

示例11–示例时间顺序文档显示

图10示出相关文档随时间的显示。可以看出,文档是按时间顺序排列的,并且文档是按树或层级结构排列的。然而,显示没有提供关于文档如何关联的信息。此外,虽然只显示少数文档,但在许多情况下,显示可能包含几十个具有更复杂层级结构的文档。

示例12–示例文档和文档关系

图11A示出如何关联文档。例如,文档A与文档B具有关系。在许多情况下,可以从任何一个文档的角度来查看关系。因此,文档B也显示为与文档A有关系。这些关系可以是彼此的反义词,包括其中一个关系被视为“主动”关系,而另一个关系则被认为是“被动”关系。例如,如果文档A被视为“复制到”文档B,则文档B可以被视为是“从”文档A复制而来的。或者,假设文档A对文档B执行动作,诸如反转文档B产生的效果。在这种情况下,文档A可以被认为是“撤销”文档B,文档B可被视为被文档A“撤销”。

图11B示出文档如何与多个其他文档相关,包括具有不同关系类型的文档。假设文档B被文档A清除。因此,文档A可以进入“清除”状态。但是,清除动作可能被文档C撤消。文档B和文档C之间的关系可以被视为“清除”或“重置”文档A对文档B原始清除。

示例13–示例关系类型

图12是列出不同类型关系的表,包括从给定关系中的两个文档的角度来看。关系的“主动”版本被显示在左栏中,而关系的“被动”版本则被显示在右栏中。这些关系的含义与德国Walldorf的SAP SE提供的产品相同,诸如S/4HANA(诸如财务功能)或SAP Centralfinance,后者可以合并来自多个财务软件实例的数据,包括SAP以外的公司的数据。

示例14–示例文档层级

图13A和图13B是相关文档的层级列表(诸如树状层级)。图13A表示源系统的层级,而图13B表示接收器系统的层级。特别是,图13A可以表示源财务系统中的数据,而图13B可以表示从源财务系统发送的数据,诸如被复制的数据。

图13A和图13B可以表示可提供给用户以帮助用户更好地理解文档之间关系的显示。例如,图13A和图13B呈现了根据文档之间的特定关系组织的文档,并且可以显示有关这些关系的信息,这可以帮助用户更好地理解文档是如何关联的以及包括这些文档的处理。

在图13A中,考虑到文档D与文档C之后的日期相关联,并且文档C的日期在文档B之后。简单地按时间顺序显示文档可能会使理解文档A、文档B和文档D之间的关系更加困难,因为文档C将放在文档B和D之间。此外,图13A和图13B中的信息可以表示筛选的关系列表,其中,如果某些文档未包括在要分析的关系集合中,或者不满足层级生成规则,则可能根本不会显示这些文档。

示例15–示例文档搜索流程

图14示出用于识别指定文档上游的文档的处理。也就是说,图14的处理识别了在导致创建特定文档或将其链接到另一文档的序列中更早发生的文档,或与该序列相关联的整体序列/处理。

接收特定文档的标识符。文档可以有单独的值来标识该文档,或者文档的标识符可以由多个值的组合构成。在特定示例中,文档存储在一个或多个关系数据库表中,标识符是标识文档的键,可以由表的多个属性/列组成。

然后,流程在第一“关系级别”查找与指定文档相关的文档。关系级别可以表示间接程度或关系类型中的一个或两个。特别是,处理可以以第一间接程度分析一个或多个关系。如果找到文档,则会将其添加到前面的文档列表中。关系可以细化。如果存在前面的文档,可以通过循环处理来分析它们,以在下一个间接级别或下一个关系类型中查找其他前面的文档。程序可以继续,直到找不到更多之前的文档为止。

可以定义早期处理终止,也可以配置其他处理规则。在某些情况下,当达到最大间接级别(可以是常规阈值,也可以为特定初始文档或文档类型指定),或者遇到特定文档、文档类型或关系时,可以指示处理终止。处理配置可以包括指定要遵循的关系或分析关系的顺序。

图15示出用于定位给定文档下游的文档的下游搜索处理。虽然图14使用给定文档的“主动关系”,但图15使用“被动关系”。否则,图15的处理可以以与图14的处理描述的类似的方式实现。

图16示出搜索给定文档的上游和下游两个文档的处理。上游和下游搜索处理可以如图14和图15所示实现。通常,识别给定文档的上游文档。可以指示这些文档的全部或部分进行下游搜索,也可以可选地从给定文档直接下游搜索文档。在某些情况下,给定文档的一个或多个上游文档可以标识为“根”文档,然后可以对全部或部分根文档进行下游搜索。

根文档可以通过多种方式标识。在某种程度上,根文档被定义为不具有在先文档的文档。在其他场景中,根文档可以被定义为具有特定类型,或者从给定文档或给定文档上游(或可选下游)的另一文档起具有间接阈值数。

在某些情况下,比较两个系统的文档可能很有用。例如,如图13A和图13B所示,文档可以从源/发送方发送/复制到目标/接收方。比较两个系统的层级可能很有用,诸如确定系统是否具有相同的内容,或者系统之间的内容可能有所不同的方式。图17示出用于获取关于给定源文档的两个系统的层级的示例处理。

提供了文档键,并且文档的镜像可以在另一计算系统或数据存储库中找到。对于文档和镜像,可以找到在先文档、后续文档或它们的组合,例如使用图14、图15或图16的处理。

一旦获得数据,就可以呈现关于层级的信息。在某些情况下,程序可以类似于图13A和图13B,其中为每个起始文档/系统提供了单独的可视化。在其他情况下,两个源文档的信息可以在一个公共树中提供。如果发现两个源文档之间存在差异,则可以在可视化显示上指示这些差异。

图18示出与图17中的处理类似的处理,但也包括识别和处理根文档的组合上游/下游搜索。图18的处理可以类似于图14-图17中等描述的处理。注意,在图17和图18中,两个系统/存储库之间至少有一个链接,诸如发送/复制到目标系统的文档。

在某些情况下,可以构建初始树层级,然后用附加信息进行补充。特别是,可以为特定文档添加状态信息,包括与其他文档的链接/关系产生的信息。

假设已经获得了树层级,其中具有来自层级节点的文档。图19示出用于确定特定单据是否已“清除”的流程图。在金融交易处理上下文中,“清除”可以指发票和发票付款之间的链接。

可以逐步评估层级中的所有或部分节点,诸如评估具有可能状态为“已清除”/与其他文档具有“正在清除”关系的文档。如果发现第二文档与层级中的第一文档具有清除关系,则可以将第二文档添加到层级结构中,包括与第一文档的关系。

图20A和图20B分别示出可用于实现下游搜索处理和组合上游和下游搜索处理的示例代码。上游搜索处理可以以与图20A类似的方式实现,但与文档/关系分析的方向相反。

示例16–示例关系优化和示例文档关系显示

图21是允许用户查看、定义、更新或删除关系类型的示例用户界面屏幕。注意,以字母开头的值表示“主动”(上游)关系,而以数字开头的值则表示“被动”(下游)关系。

早期处理可以包括“细化关系”步骤。在一个方面,细化关系可以指在生成层级或其可视化时对关系进行优先级排序。图22示出与之相关联的示例关系类型和示例关系优先级值。

图23A-图23B是可以使用公开技术生成和显示的层级可视化的一部分。图23A是使用文档0100000177作为起点的示例上游搜索结果。图23B是使用文档180000260作为起点的示例下游搜索结果。注意,图23A中的关系用主动语态表示,而图23B中的关系则用被动语态表示。图23C是使用文档1400000044作为起点的上游和下游搜索结果的组合示例。图23C包括被动和主动关系描述符。注意,生成图23C的过程涉及识别根文档180000260,它列在层级结构的顶部,然后列出根文档和最初提供的文档标识符的下游文档。

图23A-图23C的显示提供了各种有用的信息。显示具有显示树层级信息的列,包括允许确定分支级别的方式。条目通常包括文档标识符和与文档标识符关联的关系描述。另一列提供相关文档的文档类型。在某些情况下,树中的文档可能与各种错误相关联,诸如两个相关文档之间的数据可能不匹配,系统之间的数据没有正确复制,或者因为预期的文档状态不存在。此信息可以在状态列中提供,其中可以包括颜色或符号以指示数据是否如预期或是否存在错误。为了帮助提供有关层级中文档的其他信息,显示可以包括有关给定文档的一个或多个属性的信息,诸如与文档关联的时间段、输入或创建文档的日期或发布日期。

示例17–示例实现

图24A-图24R提供了公开技术的特定实现的示例实现细节。实现细节包括可以被用于存储关于文档及其关系的信息的数据结构/数据对象类型、关于存储树层级信息的信息以及可用于实现本公开各个方面的示例类,包括用于“文档层级”的类层级和用于生成使用所公开技术的结果的用户界面显示的类。

示例18–计算系统

图25描绘了可实现所述创新的合适计算系统2500的一般示例。计算系统2500无意对本公开的使用范围或功能提出任何限制,因为这些创新可能在不同的通用或专用计算系统中实现。

参考图25,计算系统2500包括一个或多个处理单元2510、2515和内存2520、2525。在图25中,此基本配置2530包括在虚线中。处理单元2510、2515执行计算机可执行指令,诸如用于实现本公开的处理的组件。处理单元可以是通用中央处理单元(CPU)、专用集成电路(ASIC)中的处理器或任何其他类型的处理器。在多处理系统中,多个处理单元执行计算机可执行指令以提高处理能力。例如,图25显示了中央处理单元2510以及图形处理单元或协同处理单元2515。有形存储器2520、2525可以是易失性存储器(例如寄存器、高速缓存、RAM)、非易失性存储器(例如ROM、EEPROM、闪存等)或二者的某种组合,可由处理单元2510、2515访问。存储器2520、2525以适于处理单元2510、2515执行的计算机可执行指令的形式存储实现本文所述一个或多个创新的软件2580。存储器2520、2525还可以存储设置或设置特征、数据库、数据集、接口、显示器、对象实例或模型。

计算系统2500可以具有其他功能。例如,计算系统2500包括储存2540、一个或多个输入设备2550、一个或多个输出设备2560以及一个或多个通信连接2570。诸如总线、控制器或网络的互连机制(未示出)互连计算系统2500的组件。通常,操作系统软件(未示出)为在计算系统2500中执行的其他软件提供操作环境,并协调计算系统2500的组件的活动。

有形储存2540可以是可移动的或不可移动的,包括磁盘、磁带或盒式磁带、CD-ROM、DVD或任何其他可用于以非暂时方式存储信息并可在计算系统2500内访问的介质。储存2540存储软件2580的指令,实现本文所述的一个或多个创新。

输入设备2550可以是触摸输入设备,诸如键盘、鼠标、笔或轨迹球、语音输入设备、扫描设备或向计算系统2500提供输入的其他设备。输出设备2560可以是显示器、打印机、扬声器、CD刻录机或提供来自计算系统2500的输出的另一设备。

通信连接2570允许通过通信介质与另一计算实体通信。通信介质在调制数据信号中传输诸如计算机可执行指令、音频或视频输入或输出或其他数据等信息。调制数据信号是具有一个或多个特征设置或更改的信号,以编码信号中的信息的方式。例如,但不限于,通信媒体可以使用电气、光学、RF或其他载波。

这些创新可以在计算机可执行指令(诸如程序模块中包含的指令)的一般上下文中等描述,这些指令在目标真实或虚拟处理器上的计算系统中执行。通常,程序模块或组件包括执行特定任务或实现特定抽象数据类型的例程、程序、库、对象、类、组件、数据结构等。程序模块的功能可以根据不同实施例中的需要在程序模块之间组合或分割。程序模块的计算机可执行指令可以在本地或分布式计算系统中执行。

术语“系统”和“设备”在此可互换使用。除非上下文另有明确说明,否则这两个术语都不表示对某种类型的计算系统或计算设备有任何限制。通常,计算系统或计算设备可以是本地或分布式的,可以包括专用硬件和/或通用硬件与实现本文所述功能的软件的任何组合。

在本文描述的各种示例中,可以对模块(例如组件或引擎)进行“编码”以执行某些操作或提供某些功能,这表明可以执行模块的计算机可执行指令来执行这些操作,使得执行这些操作或以其他方式提供这些功能。尽管关于软件组件、模块或引擎的功能描述可以作为离散软件单元(例如程序、功能、类方法)执行,但它不需要作为离散单元执行。也就是说,功能可以合并到更大或更通用的程序中,诸如在更大型或通用程序中的一行或多行代码。

为了便于演示,详细描述使用了“确定”和“使用”等术语来描述计算系统中的计算机操作。这些术语是计算机执行操作的高级抽象,不应与人类执行的行为混淆。与这些术语相对应的实际计算机操作因实现而异。

示例19–云计算环境

图26描述示例云计算环境2600,其中可以实现所述技术。云计算环境2600包括云计算服务2610。云计算服务26010可以包括各种类型的云计算资源,诸如计算机服务器、数据存储库、网络资源等。云计算服务2610可以集中(例如,由企业或组织的数据中心提供)或分布式(例如,通过位于不同位置的各种计算资源提供,诸如不同的数据中心和/或位于不同的城市或国家)。

云计算服务2610由各种类型的计算设备(例如客户端计算设备)使用,诸如计算设备2620、2622和2624。例如,计算设备(例如2620、6222和2625)可以是计算机(例如台式机或笔记本电脑)、移动设备(例如平板电脑或智能手机)或其他类型的计算设备。例如,计算设备(例如2620、2622和2624)可以利用云计算服务2610来执行计算操作(例如,数据处理、数据存储等)。

示例20-实现

尽管为了方便呈现,以特定顺序描述了一些公开方法的操作,但应理解,这种描述方式包括重新排列,除非规定的特定语言要求特定的顺序。例如,在某些情况下,顺序描述的操作可能会被重新安排或并发执行。此外,为了简单起见,附图可能未显示所公开的方法可与其他方法结合使用的各种方式。

所公开的方法中的任何一种都可以实现为计算机可执行指令或计算机程序产品,存储在一个或多个计算机可读存储介质上,诸如有形的、非暂时的计算机可读存储媒体,并在计算设备上执行(例如,任何可用的计算设备,包括智能手机或包括计算硬件的其他移动设备)。有形计算机可读存储介质是可以在计算环境中访问的任何可用有形介质(例如,一个或多个光盘,诸如DVD或CD、易失性内存组件(诸如DRAM或SRAM)或非易失性存储组件(诸如闪存或硬盘驱动器))。举例来说,参考图25,计算机可读存储介质包括存储器2520和2525以及储存2540。术语计算机可读存储媒体不包括信号和载波。此外,术语计算机可读存储介质不包括通信连接(例如,2570)。

用于实现所公开技术的任何计算机可执行指令以及在实现所公开实施例期间创建和使用的任何数据都可以存储在一个或多个计算机可读存储介质上。计算机可执行指令可以是通过web浏览器或其他软件应用(诸如远程计算应用)访问或下载的专用软件应用或软件应用的一部分。例如,可以使用一台或多台网络计算机在单个本地计算机(例如,任何合适的商用计算机)或网络环境(例如,通过互联网、广域网、局域网、客户端-服务器网络(诸如云计算网络)或其他此类网络)中执行此类软件。

为了清楚起见,只描述了基于软件的实现的某些选定方面。应当理解,所公开的技术不限于任何特定的计算机语言或程序。例如,所公开的技术可以通过用C++、Java、Perl、JavaScript、Python、Ruby、ABAP、SQL、Adobe Flash或任何其他合适的编程语言编写的软件来实现,或者在某些示例中,可以通过标记语言(诸如html或XML)或合适的编程语言和标记语言的组合来实现。同样,所公开的技术不限于任何特定的计算机或硬件类型。

此外,可以通过合适的通信手段上传、下载或远程访问任何基于软件的实施例(例如,包括用于使计算机执行任何所公开方法的计算机可执行指令)。此类合适的通信手段包括,例如,互联网、万维网、内联网、软件应用、电缆(包括光缆)、磁性通信、电磁通信(包括射频、微波和红外通信)、电子通信或其他此类通信手段。

所公开的方法、装置和系统不应被解释为以任何方式限制。而是,本公开单独地以及以彼此的各种组合和子组合针对各种公开实施例的所有新颖和非显而易见的特征和方面。所公开的方法、装置和系统不限于任何特定方面或特征或其组合,所公开的实施例也不要求存在任何一个或多个特定优点,或解决的问题。

任何示例中的技术都可以与任何一个或多个其他示例中等描述的技术相结合。鉴于可应用所公开技术原理的许多可能实施例,应认识到所示实施例是所公开技术的示例,不应被视为对所公开技术范围的限制。相反,所公开技术的范围包括所附权利要求的范围和精神所涵盖的内容。

相关技术
  • 一种基于文档结构和外部知识的文档级实体关系抽取方法
  • 一种基于文档结构和外部知识的文档级实体关系抽取方法
技术分类

06120116585587