本申请涉及采用语义和使用情况统计的多维查询扩展。
背景技术：
：除非本文另有说明，否则本节中所描述的方法不是本申请的权利要求的现有技术，而且不被承认是纳入本节的现有技术。随着存储在数据仓库中的数据的数量和复杂性不断增加，可能妨碍出于分析目的的数据探测（exploration）。对诸如AMAZONTM、NETFLIXTM及其他等网站，推荐系统（Recommendersystem,RS）在因特网上已经变得很普遍。这些系统帮助用户探测与他们当前正在查看的内容相关的可用内容。近来的系统考虑使用RS技术来建议（suggest）数据仓库查询，以帮助分析师继续进行他或她的探测。然而，需要更具选择性的方法来建立数据仓库的查询。本公开利用允许使用语义、用户简档和/或使用情况（usage）统计数据的个性化的多维查询扩展的系统和方法解决这个问题和其他问题。技术实现要素：实施例涉及采用个性化的查询扩展的系统和方法以建议允许在数据仓库上迭代构建一致查询的度量和维度。实施例可以充分利用（leverage）以下中的一个或多个：多维域模型中定义的语义、定义偏好的用户简档、以及从现有的业务智能（BI）文档（例如仪表板（dashboard）、报告）库推导的协同使用情况统计。实施例可以利用从用户简档推导的协作共生值或用户的社交网络信息。计算机实现的方法的实施例包括提供包括引擎的查询扩展系统，其与用户简档通信并与业务智能平台通信，业务智能平台包括数据仓库、多维域模型和文档库。使查询扩展系统接收由用户向业务智能平台提出的查询，该查询包括多维域模型的度量。使引擎基于文档库和用户简档中的偏好来确定用于数据仓库中的查询的共生值。使查询扩展系统向用户显示基于共生值的查询结果。非临时性计算机可读存储介质的实施例具体实施用于执行方法的计算机程序，该方法包括提供包括引擎的查询扩展系统，其与用户简档通信并与业务智能平台通信，业务智能平台包括数据仓库、多维域模型和文档库。查询扩展系统接收由用户向业务智能平台提出的查询，该查询包括多维域模型的度量。引擎基于文档库和用户简档中的偏好来确定用于数据仓库中的查询的共生值。查询扩展系统向用户显示基于共生值的查询结果。计算机系统的实施例包括一个或多个处理器以及软件程序，其可在所述计算机系统上运行。软件程序被配置为与包括引擎的查询扩展系统通信，该查询扩展系统与用户简档通信并与业务智能平台通信，业务智能平台包括数据仓库、多维域模型和文档库。软件程序被配置为使查询扩展系统接收由用户向业务智能平台提出的查询，该查询包括多维域模型的度量。软件程序被配置为使引擎基于文档库和用户简档中的偏好来确定用于数据仓库中的查询的共生值。软件程序被配置为使查询扩展系统向用户显示基于共生值的查询结果。在某些实施例中，确定共生值包括使第一引擎接收来自文档库的信息，以便确定用户专用的共生值。根据一些实施例，确定共生值包括使查询扩展系统的第二引擎接收来自用户简档的用户的社交网络信息，以便确定协作共生值。在特定实施例中，确定协作共生值包括基于社交网络信息中距用户的距离来应用权重。根据某些实施例，向用户呈现所述查询结果作为到多维域模型的第一维度的第一链接，以及到基于多维域模型的第二维度的第二查询结果的第二链接；以及用户通过激活第一链接来访问包括图表的所述查询结果。特定实施例可以通过定义Jaccard（杰卡德）指数来确定共生值。下面的详细描述和附图提供对各个实施例的本质和优点的更好的理解。附图说明图1示出用于多维模型的个性化的查询扩展系统的实施例的简化图。图1A示出了可以在图1的系统中呈现的各种形式的信息，其根据实施例可以充分用于查询扩展。图2是示出与度假胜地的市场信息有关的数据仓库中的度量之间的各种功能依赖的视图。图2A是图2的一部分的放大。图3示出了呈现使用情况统计的仪表板的图形表示。图3A是图3的一部分的放大。图4是示出其他员工的层次结构内的活跃用户的关系的简化视图。图5A至图5B示出交互查询设计器的实施例中使用的自动完成的截图。图5C示出可以利用图5A至图5B中形成的查询建立的样本可视化。图6A至图6B示出根据实施例的用于个性化的查询扩展系统的用户界面的屏幕的例子。图7示出专用计算机器的硬件，这种计算机器可以被配置为根据特定实施例执行查询扩展。图8示出计算机系统的例子。图9呈现根据实施例的查询定制的过程的简化流程图。具体实施方式下面描述的装置、方法和技术可以被实现为在一个或多个计算机上运行的计算机程序（软件）。计算机程序还可以被存储在计算机可读介质上。计算机可读介质可以包括用于执行以下描述的过程的指令。在下面的描述中，为了解释，示例和具体细节被阐述以提供对本发明的各种实施例的透彻理解。然而，对本领域技术人员将显而易见的是，由权利要求限定的本发明可以单独包括这些例子中的一些或所有特征，或者可以与下面描述的其它特征组合使用，并且还可以包括本文所描述的特征和构思的修改和等同物。数据仓库被设计为整合（integrate）和准备来自生产系统的数据-提取转换和加载（ETL）过程-以便利用BI工具进行分析。由于来自IT和领域专家对感兴趣的第一模型领域的显著成就，这些工具允许用户浏览和分析大量数据。然而，采用这些多维模型可能在生产系统的重要部署方面具有挑战。事实上，域模型可以发展为极其复杂，使用成千上万的BI实体、度量（measure）和维度（dimension），例如用于构建联机分析处理（OLAP）多维数据集（cube）。在报告和分析工具中，用户可以使用查询面板来设计数据查询。例如，用户可以拖放度量和维度以用于创建新的可视化（例如，显示按照“城市”合计的“销售收入”）。给出可用度量和维度的数量，期望帮助用户以迭代方式构建查询。查询扩展问题可以被定义为以用户u、当前查询q和附加参数params作为输入的函数QE。这个函数返回获得的（scored）的查询（qi，ri）的集合，从而对于从1到n的所有i，/qi/=/q/+1且QE:(u,q,params)→{(q1,r1);…,(qn,rn)}因此，挑战是识别与q最相关的候选度量和维度。为了迎接这一挑战，本文的实施例描述了交互的和个性化的查询设计器。实施例可以充分利用多维模型的语义、用户的偏好、和/或从BI文档库推导的协作使用情况统计来迭代地建议相关度量和维度。图1是示出根据实施例的个性化的查询扩展系统的架构的组件的简化图。个性化的查询扩展系统100被配置为与用户简档102和业务智能平台104两者进行交互。尤其是，个性化的查询扩展系统被配置为从BI平台中存在的（多个）数据仓库120、（多个）多维度域模型130和文档库140接收相关信息。查询扩展系统100包括第一引擎101，其被配置为基于用户简档中存在的用户专用信息确定共生（co-occurrence）值。这样的信息可以包括用户简档的偏好和评级信息108。下面详细讨论根据特定实施例确定用户专用的共生值。查询扩展系统100还包括第二引擎103，其被配置为考虑用户与另一实体（如另一用户）之间的关系确定协作共生值。这样的协作共生值可以基于来自用户简档的社交网络106的数据来确定。下面还详细讨论根据特定实施例确定协作共生值。多维域模型的语义BI平台可以包括一个或多个多维模型。用于DW的这样的多维模型利用关键指示符（度量）和分析轴（维度）来定义业务域的概念。度量包括可以对各种维度进行合计的数值事实。例如，度量“销售收入”可以在维度“国家”和“产品”上合计（例如来自单位销售交易）以便产生在不同国家出售的产品所产生的收入。业务域模型被用于查询实际数据的DW并用于执行计算。DW可以具体化为关系型数据库，而且因此，例如查询可以被表示为结构化查询语言（SQL）。从计算的角度来看，也可以构建多维度OLAP多维数据集。测量被聚合在按照多维形成的多维数据集的不同单元（cell）内。查询可以被表示在这些多维数据集上，例如，利用多维表达式（MDX）。除此之外，现代DW提供SQL/MDX生成算法，以使非专业用户能够制定即席（ad-hoc）查询。图1A示出了可以在图1的系统中呈现的各种形式的信息，其根据实施例可以充分用于查询扩展。例如，多维模型130可以被注释以包括维度类型132。多维域模型也可以定义层次结构134。图1A中所示的两种其他形式的信息（其根据实施例可以充分用于查询扩展）是共生136和功能依赖（度量和维度之间）138。如稍后在下面详细讨论的，可以从用户专用和/或协作角度来确定共生。关于功能依赖，如果一个对象确定另一对象，则这两个对象（度量或维度）可以被称为功能依赖。例如，知道“城市”就确定了相关“国家”。涉及度量和维度的另一个例子是由“客户”确定的“销售收入”。也就是说，可以从事实表（facttable）中的单位销售（unitsale）合计“销售收入”。功能依赖是传递的。也就是说，如果A确定B，B确定C，则A确定C。在简单的场景中，所有度量由所有维度确定。这是使用基本数据集时的情况，例如在星型模式中减少到具有多个维度的一个事实表。图2是示出与度假胜地（岛度假村）的市场信息有关的数据仓库中的度量之间的各种功能依赖的视图。图2A是图2的一部分的放大，其示出度量202之间的功能依赖200。功能依赖可以被考虑以组成有意义的查询。例如，功能依赖可以被用于确保建议的查询不包含阻止它们运行的不兼容对象。然而，业务域模型不一定捕捉和披露这个功能依赖信息。维度的层次结构更加常见，并且可以被用于报告和分析工具中以允许下钻（drill-down）操作。例如，如果“年-季度”层次结构被定义，则用户在“2010年”的下钻结果是利用“季度”维度对“年=2010”过滤的更细粒度的查询。如果维度的层次结构可以被用于确定最小依赖链，则技术可以帮助功能依赖的自动检测。例如，可以从概念模式和使用推理能力来创建域本体（domainontologies）。BI文档中的使用情况统计功能依赖和层次结构提供有关BI实体之间的关联的结构知识。在此之外，一些BI平台包括文档（例如，报告、仪表板）库，其可以被用于为度量和维度计算实际的使用情况统计。这些信息可以是有价值的，因为查询扩展意味着找到与度量和维度的给定集合关联的最佳候选。BI文档的结构可以被用于定义度量和维度之间的共生。例如，BI报告大致由段（section）组成，这些段可以包含图表、表格、注释的文字区域等。图表和表格定义潜在的重大意义单位。相同表格/图表中相关联的度量和维度可以是相关的，而且代表对用户的具体兴趣的分析。同样，仪表板可以由包括图表和表格的不同页面或视图组成。图3示出了呈现使用情况统计的仪表板的图形表示。图3A是图3的一部分的放大。具体地，这是仪表板“世界杯队伍统计2（WorldCupTeamSTATS2）”及其具有有关数据的关联图表的图形表示。图形表示300包括仪表板302和具有参考度量306和维度308的关联图表304。当然，实施例并不限于图3的具体例子。更一般地，参考度量和维度的任何BI文档可以被用于导出综合的共生或使用情况统计。如图1所示，个性化的查询扩展系统可以包括用于确定用户专用的共生值的引擎101、以及用于确定反映协作的共生值的引擎103。某些实施例可以利用个人共生值。BI平台为业务域模型和在它们之上建立的文档提供访问控制规则。因此，不同的用户可能无法访问相同的模型，或者以更细粒度的水平，可能无法访问相同的度量和维度。此外，库包括由系统的不同用户生成并在系统的不同用户之间的共享（或不共享）的文档。因此，本文所讨论的共生的值可以是固有的个性化的。例如，考虑用户u，利用occu(e1)表示对用户u可见的图表和表格的集合，参考BI实体e1、度量或维度。Jaccard指数是两个样本集合之间的相似性的、简单但常用的值。因此，两个实体e1和e2之间的共生可以被定义为集合occu(e1)和occu(e2)的Jaccard指数：某些实施例可以采用协作共生值。一个问题涉及冷启动用户和覆盖（coverage）。在推荐系统（RS）中，覆盖是实际上可以被推荐的项目的比例，类似于信息检索中召回的概念。公式（1）可以呈现冷启动用户（即，对系统而言他们是新的）的问题。事实上，这些用户可能没有保存文档，根据该文档可以计算共生。协作RS可以将其他用户的贡献引入项目计分函数（itemscoringfunction）中以改善系统的覆盖，并使能用户对先前未知的（或者未使用的）资源的探测。简单方法是使用用户专用值和一组用户的平均值的线性组合。实施例可以利用社会/信任网络以提供协作共生值。前面描述的简单方法利用具有相同权重的用户将协作贡献扩展到“整个世界（thewholeworld）”。基于信任的RS可以考虑用户的社交网络，例如靠近当前用户的有利用户。最接近的用户的协同贡献的这种缩小可以至少在两个层面上呈现好处。首先，结果可以被更精确地个性化。其次，潜在的预计算可以被减少。假设SN（u）表示u的社交网络中用户的集合，其可以被过滤以便只保留达到某一最大距离的用户。下面改进的共生值可以使用，其中α和β是将根据实验进行调整以使得α+β=1的正系数：这个值cooc（u;e1;e2）是对于通过访问控制规则暴露给用户u的实体e1和e2定义的。每个用户u’的贡献由距离d（u,u'）的倒数进行加权。用户之间的关系可以从各种源（包括网络上流行的社交网络）获得。但是，这可能不一定符合企业要求，因为系统的用户实际是相同公司的员工。在这种情况下，企业目录可以被用于提取，例如，员工之间的（分层）关系。图4是示出其他员工的层次结构402内的活跃用户400的关系的简化视图。也可以考虑从社交网络的结构所产生的其他类型的关系。例如，图4还示出在活跃用户400和第三方406之间存在业务接触404。根据某些实施例，个性化的查询扩展组件可以充分利用模型语义、共生和/或用户偏好。用户偏好可以是显式的（这里prefu,expl）或隐式的（这里prefu,impl）。对于给定的实体e，用户的偏好函数prefu被定义为两个偏好的线性组合，例如简单的：显式偏好是从用户接收到的反馈，例如，以分配给度量和维度的评级（rating）的形式（在[0，1]之中）。在这里，ru,e是由u给e的评级，而且是由u给出的平均评级。如果u已经对e评级，则我们定义prefu,expl(e)=ru,e，否则隐式偏好可以从各种源导出，例如，通过分析在用户的会话中执行的查询的日志。由用户操作的文档中出现的BI实体可以被认为是这种偏好的简单的指示符：实施例可以在查询设计阶段通过提供她可以用来探索数据的度量和维度的建议来帮助用户。当她选择测量或维度时，它可以被添加到正在构建的查询。建议被刷新以形成新的一致增加的查询。评级可以实现如下。为了完成具有附加度量或维度的给定查询q={e1,….,en}，候选实体被发现并评级。候选实体，cj,j=1...p，是在相同域中定义并与每个ei兼容的实体，而且使用功能依赖进行定义。下面的个性化的功能也可以被用于对每个候选cj评级：为了解决上面引入的查询扩展问题的符号，元素QE被定义如下：QE:(u,q,params)→{(q1,ranku(c1,q)),…,(qp,ranku(cp,q))}除了评级，查询扩展组件的建议可以使用各种参数进行微调。这样的参数的例子包括但不限于：●结果的最大数量；●建议的实体的类型可以被限制为度量和/或维度；●域可以被限制为接受的模型的列表；和/或●建议的维度可以按照一定层次结构分组并限制为一定层次结构。这可以用于减少建议的数量并鼓励用户探测分析的变化轴。例子：查询设计器中的自动完成下面描述从实施原型交互查询设计器得到的结果。这个例子向用户简单呈现了搜索文本框。当用户键入时，提出候选度量和维度作为自动完成建议。图5A至图5B是这个例子的交互查询设计器中使用的自动完成的截图。图5A示出当用户开始键入连续字符“sa”时建议的度量（来自不同的域模型）：“Salesrevenue（销售收入）”、“Avgofsavegoal（平均节省目标）”和“Keepersavegoal（保管员节省目标）”。图5B示出用户选择第一建议“Salesrevenue”，并继续键入字符“c”。系统建议两个维度“City(城市)”和“Category(类别)”。图5C示出可以利用查询“SalesrevenuebyCity（城市的销售收入）”建立的样本可视化。自动完成初始化可以需要用户大约知道要求被操纵的对象的名字。为了帮助用户开始并探测可用的数据，可以在键入开始之前向用户提供建议。例如，可以推荐以各种域模型的最常用的度量和维度开始。这个例子依赖于BI平台SAPBI4TM。为了报告和以仪表板显示解决方案，这个特定例子利用WebIntelligenceTM和SAPBusinessObjectsExplorerTM（或探测视图）。根据需要，使用通过SAPExplorerTM的示范帐户可访问的仪表板来计算共生。这个帐户暴露九（9）个仪表板，包含三十一（31）个图表。七（7）个基础的域模型定义了五十四（54）个维度和八十六（86）个度量。下表呈现命名为“销售收入”的给定度量的、具有最高共生的五（5）个维度。对于社交网络方面，这个具体的例子在原型社交网络分析器上建立。特别是，这个原型的应用程序接口（API）以两个深度暴露用户的社交图。根据某些实施例，查询扩展可以向用户提供有关共生信息的形式的建议。例如，下表分割信息的容器类型之间的共生（例如，是否以表格或图表的形式呈现）。鉴于此，用户希望通过“项目名称”制定用于“项目成本”的查询，以便以具有较高共生发生率的表格的形式进行显示。图6A至图6B示出根据实施例的用于个性化的查询扩展系统的用户界面的屏幕的例子。图6A示出了用户输入屏幕600，其中，用户已经选择度量“SalesRevenue（销售收入）”602，并被提供有一系列的链接604以及用于沿不同的维度606（例如，“Category（类别”、“State（国家）”、“State,Quarter（国家，季度）”、“City,(product)Lines（城市，（产品）线）”）显示执行查询的结果的缩略图。点击链接之一允许用户快速在仪表板上看到查询。例如，图6B显示了沿维度“（城市，（产品）线）”查询度量“销售收入”的结果的样本仪表板视图610。虽然这个仪表板以单一（条形）图612显示查询结果，但是在可替换的实施例中，信息可以以一种以上的形式（如条形图、饼图、数值图等）显示。仪表板还向用户提供菜单614以便以交互的方式通过选择特定的产品线进一步完善查询。总之，实施例包括个性化的查询扩展系统，其可以充分利用：多维域模型的语义、从BI文档库中度量和维度的（共同）发生导出的使用情况统计、和/或用户的偏好。交互查询设计器的原型被创建以利用自动完成建议帮助用户。在特定的实施例中，图5A至图6B的相似搜索界面可以被扩展。例如，图表-来自现有的报告和仪表板-可以利用类似的数据来检索。此外，用户偏好和（共同）发生可以被用于问题回答系统，例如，以帮助个性化的查询重写。一些实施例中可以在DW和BI平台的上下文中采用推荐，这从在RS区域中开发的技术受益。多维模型的特定语义的考虑可以被用于提供有关结构化的分析。总结来说，图9呈现根据实施例的查询定制的过程900的简化流程图。在第一步骤902中，包括第一引擎和第二引擎的查询扩展系统被提供以与用户简档通信并与业务智能平台通信，业务智能平台包括数据仓库和多维域模型。在第二步骤904中，用户将查询应用于（pose）业务智能平台，该查询包括多维域模型的度量和维度。在第三步骤906中，第一引擎基于用户简档的偏好和多维域模型确定用于查询的用户专用的共生值。在可选的第四步骤907中，个性化的查询扩展系统可以继续进行以向用户显示基于用户专用的共生值的查询结果。然而，在可选的第五步骤908中，第二引擎还可以基于用户简档的社交网络信息和多维域模型确定用于查询的协作共生值。因此，在可选的第六步骤910中，个性化的查询扩展系统可以向用户显示基于协作共生值的查询结果。图7示出专用计算机器的硬件。这种计算机器可以被配置为根据特定实施例实施查询扩展。特别是，计算机系统700包括处理器702，其与非临时性计算机可读存储介质703电通信。这种计算机可读存储介质具有存储在其上的代码705，其对应于负责确定个性化的查询扩展系统的用户专用的共生值的引擎。代码704对应于负责用于确定个性化的查询扩展系统的协作共生值的引擎。代码可以被配置为参考存储在非临时性计算机可读存储介质的数据库中的数据，例如可以位于远程数据库服务器中，或者可以存在于移动设备中。实施例可以与计算机系统配合运行，计算机系统可以包括软件服务器。许多软件服务器一起可以形成集群或利用软件程序编程的计算机系统的逻辑网络，其相互通信并一起工作以处理请求。图8示出了示例性计算机系统810。计算机系统810包括总线805或用于对信息进行通信的其他通信机制，以及与总线805耦合的、用于处理信息的处理器801。计算机系统810还包括耦合到总线805的存储器802，用于存储将被处理器801运行的信息和指令，例如包括用于执行上述技术的信息和指令。这个存储器还可以用于在将由处理器801运行的指令的执行过程中，存储变量或其它中间信息。这个存储器的可能实现方法可以是，但不限于，随机存取存储器（RAM）、只读存储器（ROM）、或两者。存储设备803还被提供以用于存储信息和指令。存储装置的常见形式包括，例如，硬盘驱动器、磁盘、光盘、CD-ROM、DVD、闪存、USB存储卡、或计算机可以读取的任何其它介质。例如，存储设备803可以包括用于执行上述技术的源代码、二进制代码或软件文件。存储装置和存储器二者都是计算机可读介质的示例。图8中描述的计算机系统一般包括至少图7中描述的那些属性。计算机系统810可以经由总线805耦合到显示器812，例如阴极射线管（CRT）或液晶显示器（LCD），用于将信息显示给计算机用户。诸如触摸屏的输入设备811被耦合到总线805，用于向处理器801通信从用户选择的信息和命令。这些组件的组合允许用户与系统通信。在一些系统中，总线805可以被划分为多个专用总线。计算机系统810还包括与总线805耦合的网络接口804。网络接口804可以在计算机系统810和本地网络820之间提供双向数据通信。网络接口804可以用于宽带无线接入（BWA）技术。在任何这样的实现中，网络接口804发送和接收携带表示各种类型的信息的数字数据流的电、电磁或光信号。计算机系统810可以通过网络接口804在本地网络820、内联网或互联网830上发送和接收包括消息或其他接口动作的信息。对于本地网络，计算机系统810可以与多个其他计算机机器（诸如服务器815）通信。因此，计算机系统810和由服务器815表示的服务器计算机系统可以形成云计算网络，其可以利用本文所描述的过程编程。在涉及互联网的例子中，软件组件或服务可以驻留在网络上的多个不同的计算机系统810或服务器831-835上。例如，上面描述的过程可以被实现在一个或多个服务器上。服务器831可以通过因特网830、本地网络820和网络接口804将动作或消息从一个组件发送到计算机系统810上的组件。例如，上述软件组件和过程可以在任何计算机系统上实现，并在网络上发送和/或接收信息。基于上述公开和下面的权利要求、其他安排、实施例、实现和等同物将对本领域技术人员而言是显而易见的，而且可以在不脱离由权利要求限定的本发明的精神和范围的情况下采用。当前第1页1 2 3