CN116955310A - 数据工件的扩展的传播 - Google Patents

Abstract

描述了用于传播数据工件的扩展的技术和解决方案，诸如定义物理或虚拟数据模型中的对象的数据工件。识别与第一数据工件相关的一个或多个数据工件。分析所述第一数据工件的一个或多个扩展元素以供传播到所述一个或多个数据工件中的至少一个数据工件。分析是否应该传播扩展元素可以包括分析该扩展元素的类型、使用该扩展元素的操作的类型或上下文、或所述至少一个数据工件如何引用、使用或合并所述第一数据工件，包括其特定元素。将分析结果与各种规则进行比较。自动传播扩展元素，或者在用户同意(例如，提供传播建议)时手动传播扩展元素，或者以半自动方式传播扩展元素。

Description

数据工件的扩展的传播

技术领域

本公开一般涉及数据工件，例如，诸如表格、视图或OLAP立方体的数据库工件，或可映射到这些数据库工件的工件，诸如虚拟数据模型中的工件。特定实施方式涉及确定是否应该将特定工件的扩展传播到其它工件，诸如合并或引用扩展工件的工件。

背景技术

用于多种用途的数据存储(诸如数据库)及其接口可能非常复杂。例如，数据源的物理或虚拟模型可以具有大量的数据工件，诸如表示表格和视图的数据工件。诸如视图的数据工件经常建立在其它数据工件上，并且数据工件之间的相互关系可能非常复杂。

在现代软件应用中，通常物理数据库级别的表格和视图与使用这些表格和视图中数据的应用之间具有语义层。在一些情况下，该语义层可以实施为虚拟数据模型。虚拟数据模型中的工件可以与物理数据库中的工件相关。虚拟数据模型的一个优点是，可以用来以更加用户友好的方式表达或描述数据工件并包含数据库中可能存储的信息之外的信息。虚拟数据模型还可以促进以多种方式使用相同的物理数据库工件，每种方式都适合于特定用例。

无论是在数据库本身还是虚拟数据模型中，以多种方式使用与数据库相关联的工件也都是很常见的。例如，软件提供商可以提供一套标准的表格、视图和其它工件，包括虚拟数据模型中的工件。然后，软件的用户可以针对其特定用例定制工件。定制可以采取各种形式，包括诸如向数据库表格添加列或更改向用户显示的描述列的文本之类的动作。

作为一个更具体的示例，软件公司可以提供用于人力资源管理的数据库模式。该模式下的表格和视图可以包括与“雇员”相关的列。一旦疫苗在COVID-19疫情期间变得可用，雇主可能会希望修改雇员的信息，其中一列指示雇员是否接种疫苗或者包括免疫接种日期和提供的免疫接种类型(例如，疫苗生产商)。

由于大规模软件开发的复杂性，软件公司最终可能会更新其模式以支持此类信息。然而，与此同时，软件的特定用户可能会选择修改或扩展相关工件以支持所需信息。

另一个可能出现的问题是用户有时会使用多个数据库平台。例如，使用特定软件解决方案的实体可能具有本地数据库系统和可用于云(超大规模)计算系统上的数据库系统。实体的修改不同系统上的数据工件的能力可能不相同。即使实体完全能够访问和修改合适的工件，将扩展从一个系统手动复制到另一个系统也可能是冗长且容易出错的。因此，还存在改进的空间。

发明内容

提供本发明内容是为了以简化的形式介绍在下面的具体实施方式中进一步描述的概念的选择。本发明内容不旨在标识所要求保护的主题的关键特征或必要特征，也不旨在用于限制所要求保护的主题的范围。

描述了用于传播数据工件的扩展的技术和解决方案，诸如定义物理或虚拟数据模型中的对象的数据工件。识别与第一数据工件相关的一个或多个数据工件。分析第一数据工件的一个或多个扩展元素以供传播到该一个或多个数据工件中的至少一个数据工件。分析是否应该传播扩展元素可以包括分析该扩展元素的类型、使用该扩展元素的操作的类型或上下文、或该至少一个数据工件如何引用、使用或合并第一数据工件，包括其特定元素。将分析结果与各种规则进行比较。自动传播扩展元素，或者在用户同意(例如，提供传播建议)时手动传播扩展元素，或者以半自动方式传播扩展元素。

在一个方面，提供了一种用于传播扩展元素的方法。接收第一数据工件。该第一数据工件包括多个基础元素和包括至少一个第一扩展元素的扩展。确定与第一数据工件相关的至少一个第二数据工件。分析该至少一个第一扩展元素以供传播到第二数据工件。确定应该将该至少一个第一扩展元素传播到第二数据工件。将该至少一个第一扩展工件传播到第二数据工件。

本公开还包括配置为执行或包括用于执行上述方法(或操作)的指令的计算系统和有形的非暂时性计算机可读存储介质。如本文所述的，可以根据需要将各种其它特征和优点结合到技术中。

附图说明

图1是图示可以实施所公开的技术的示例计算环境的示意图，其中源系统提供可由目标系统访问的工件展示服务，并且其中一个或多个计算系统可以存储不同版本的数据工件，包括与其它数据工件相比扩展了的数据工件。

图2是图示如何可以使数据工件层级相关、如何可以使数据工件在不同计算环境之间不同和如何可以对某些用户限制对数据工件分层结构的不同级别的访问的示意图。

图3是确定待传播的或推荐传播的扩展元素的方法的特定实施方式的流程图。

图4是将第一数据工件的扩展元素传播到相关数据工件的方法的流程图。

图5是示出模式中的至少一部分数据库表格之间的技术关系的数据库模式的示意图。

图6是图示可包括在数据字典中或用于定义数据库表格的表格元素之间的关系的示意图。

图7是图示数据字典的组件和数据库层的组件的示意图。

图8是用于数据库视图的示例工件定义的代码。

图9是用于数据库视图的示例工件定义和用于修改或引用这种示例工件定义的工件定义的代码。

图10是图示如何可以使工件定义相互关联和更新或移除(包括通过多个计算系统)的示意图。

图11A和图11B是图示如何可以以关系格式存储工件定义的示例表格。

图12是图示如何可以使工件定义相互关联并包括查询操作(诸如选择语句(select statement)、join条件和where条件)以及如何可以通过关联关系使数据库对象相关的示意图。

图13提供了图示如何可以以关系格式存储图13中呈现的工件定义信息的示例数据库表格。

图14是图示工件定义如何可以具有相对于其它工件定义而定义的字段的示意图。

图15提供了图示如何可以以关系格式存储图14中呈现的工件定义信息的示例数据库表格。

图16是图示如何可以使工件定义(包括具有注解的工件定义和注解其它工件定义的工件定义)相关的示意图。

图17和图18提供了图示如何可以以关系格式存储图16中呈现的工件定义信息的示例数据库表格。

图19图示了用于可以访问工件定义的持久性模型的数据访问服务的代码。

图20和图21呈现了可以用于执行通过提供对工件定义及其扩展的访问的数据访问服务来请求的操作的示例表格。

图22呈现了可以用于对显示工件定义信息的用户界面服务进行注解的示例代码。

图23是可以实施所描述的一些实施例的示例计算系统的示意图。

图24是可以与本文公开的技术结合使用的示例云计算环境。

具体实施方式

示例1——概述

用于多种用途的数据存储(诸如数据库)及其接口可能非常复杂。例如，数据源的物理或虚拟模型可以具有大量的数据工件，诸如表示表格和视图的数据工件。诸如视图的数据工件经常建立在其它数据工件上，并且数据工件之间的相互关系可能非常复杂。

在现代软件应用中，通常物理数据库级别的表格和视图与使用这些表格和视图中数据的应用之间具有语义层。在一些情况下，该语义层可以实施为虚拟数据模型。虚拟数据模型中的工件可以与物理数据库中的工件相关。虚拟数据模型的一个优点是，可以用来以更加用户友好的方式表达或描述数据工件并包含数据库中可能存储的信息之外的信息。虚拟数据模型还可以促进以多种方式使用相同的物理数据库工件，每种方式都适合于特定用例。

无论是在数据库本身还是虚拟数据模型中，以多种方式使用与数据库相关联的工件也都是很常见的。例如，软件提供商可以提供一套标准的表格、视图和其它工件，包括虚拟数据模型中的工件。然后，软件的用户可以针对特定用例定制工件。定制可以采取各种形式，包括诸如向数据库表格添加列或更改向用户显示的描述列的文本之类的动作。

作为一个更具体的示例，软件公司可以提供用于人力资源管理的数据库模式。该模式下的表格和视图可以包括与“雇员”相关的列。一旦疫苗在COVID-19疫情期间变得可用，雇主可能会希望修改雇员的信息，其中一列指示雇员是否接种疫苗或者包括免疫接种日期和提供的免疫接种类型(例如，疫苗生产商)。

由于大规模软件开发的复杂性，软件公司最终可能会更新其模式以支持此类信息。然而，与此同时，软件的特定用户可能会选择修改或扩展相关工件以支持所需信息。

另一个可能出现的问题是用户有时会使用多个数据库平台。例如，使用特定软件解决方案的实体可能具有本地数据库系统和可用于云(超大规模)计算系统上的数据库系统。实体的修改不同系统上的数据工件的能力可能不相同。即使实体完全能够访问和修改合适的工件，将扩展从一个系统手动复制到另一个系统也是冗长且容易出错的。因此，还存在改进的空间。

本公开提供了可用于将在一个环境中制作的数据工件的扩展传播到另一个环境的技术。这些环境可以在共同的计算基础设施上或者在不同的计算基础设施上。在一个特定示例中，将在本地系统处制作的扩展传播到云(或超大规模)系统(可以是主系统)。

如本文使用的，“传播”至少主要用于指代制作或评估是否制作工件的扩展的过程，与在环境(或系统，其中这些术语在不需要不同计算基础设施或系统的程度上可以互换使用)之间发送扩展的过程相反。换言之，“传播”是指将扩展从一个数据工件应用到一个或多个其它数据工件的过程，其中这些其它数据工件可以在相同或不同的系统上，并且其中至少在一些情况下，将扩展从一个数据工件传播到与正在传播扩展的数据工件具有层级关系的数据工件。

本公开不限于使扩展在应用该扩展或评估以确定是否应该或能够应用该扩展的系统处变得可用的任何特定手段。例如，扩展可以通过网络或使用计算机可读存储介质(例如，磁盘)以原本格式、串行化格式(例如，标准化/传输/交换格式，诸如CSN、JSON或XML)或一些其它格式来传输。在可从德国沃尔多夫的SAP SE获得的软件中使用的CSN(核心模式表示法)或CSON(核心模式对象表示法)可以视为是富含注解或语义信息的SQL语句。可以使用JSON、XML或其它格式来定义类似的数据工件。

在一个特定示例中，扩展(可以是元数据的形式)可以使用源系统(从其传输扩展的系统)处的展示服务来传输，包括如2021年9月22日提交的名称为“IDENTIFICATION ANDIMPORT OF METADATAγFOR EXTENSIONS TO DATABASE ARTIFACTS(用于数据库工件扩展的元数据的识别和导入)”的美国专利申请第17/448,514号所公开的，该专利申请在不与本公开相矛盾的程度上全部并入本文中。在特定实施方式中，扩展可以是如在可从德国沃尔多夫的SAP SE获得的软件中实施的扩展，诸如在ABAP或CSN(包括用于CDS、核心数据服务、数据工件，诸如CDS视图)中表达的对象/工件的扩展。

如上所述，可能希望评估是否应该将扩展应用于数据工件。特别是当软件自动重建或应用扩展时，可能很难确定数据工件的用户是否想要采取该动作。当多方的扩展可能发生冲突或重叠时，情况可能会变得特别复杂。例如，提供“基础”数据工件的软件公司也可能具有被期望应用于诸如特定用例的扩展。这些扩展可能会与使用公司软件的一方所做的扩展发生重叠或冲突。

因此，可以开发“规则”来评估是否应该将来自一个数据工件的特定扩展(诸如特定类型的扩展)应用到其它相关(或目标)数据工件。这些规则可以是相对简单的，诸如将会传播或不传播特定类型的所有扩展。或者，规则可以是较复杂的，诸如评估特定扩展的细节以确定是否应该将该扩展传播到相关数据工件。虽然规则的应用在一些情况下可以是自动的，但是在其它情况下，可以向用户或进程呈现规则的结果以确定是否要传播特定扩展。当特定规则或特定规则的应用没有提供明确的答案时，提示决定是否应该传播扩展可能是特别有用的。

可以证明所公开的创新有用的一个特定场景是，针对用户(实体)的扩展是在第一系统(诸如本地系统)上进行并且在第二系统(诸如基于云的系统)中评估以供传播，其中用户的访问或权限在系统之间存在差异。用户的访问或权限上的差异可能是由于安全问题，或者是因为允许用户访问或修改特定数据工件的功能尚未实现。

如上所述，包括扩展在内的数据工件可以位于模式(例如，数据库模式或虚拟数据模型的模式)的不同“层”，其中较低层或级别的工件用作较高级别的构建块，而那些较高级别的工件可以用作更高级别的工件的构建块。可能的是，在源系统中，用户有权访问所有层或至少比扩展待传播至的目标系统中更多数量的层。或者，不管用户可能有权访问的层数量，用户都可以有扩展源系统的比目标系统更低级别的工件的能力。因此，在用户在源系统处扩展了对象但是不能在目标系统处手动进行扩展的情况下，便会出现问题。事实上，如果用户无权访问数据工件的“堆栈”的较低级别(例如，虚拟数据模型中建立在彼此之上的视图堆栈)，则用户甚至不能“查看”扩展，以便手动地将扩展包括在他们有权访问的堆栈的更高级别中。因此，本文使用的“传播”可以包括利用来自较低级工件的扩展来扩展较高级工件，诸如从出现扩展元素的最低级别到堆栈的顶端，或至少到用户有权访问的级别(在某些情况下，可以是用户有权访问的堆栈的最低层)。

即使用户可以访问足够多的堆栈层以“查看”扩展，对于用户而言，手动地将扩展从较低堆栈级别传播到较高堆栈级别也可能是耗时、冗长且容易出错的。因此，所公开的技术可以包括自动或半自动功能来传播扩展，诸如使用“向导”，而不管用户是否可以访问向导所分析的一些级别。

在一些方面上，在源系统处的服务便于通过目标系统或代表目标系统的中间系统检索与数据工件及其扩展相关的信息。在源系统处的服务可以包括转换器，该转换器将源系统中用于数据工件的定义信息转换成用于促进系统之间内容共享的通用格式。

示例2-6描述了用于将扩展传播到数据工件(或在数据工件之间传播)的技术。示例7-16提供了可以与示例2-6中公开的创新一起使用的附加细节。例如，如上所述，规则(包括启发法)可以帮助确定是否应该进行或推荐特定传播。至少某些规则可以至少部分地基于关于特定扩展或其元素的信息，诸如数据类型、如何使用扩展/元素、以及使用为扩展/元素维持的语义信息。因此，这些信息的来源(诸如数据字典)可以用于帮助确定是否应该传播扩展。

不是所有的扩展都需要以相同的方式处理。例如，一组数据工件可以包括用户创建的数据工件(例如，客户创建的)和提供商创建的数据工件。对于用户创建的数据工件，可能不适合传播用户没有选择包括在源环境的更高级工件中的扩展。因此，在一些实施方式中，所公开的传播技术用于将扩展元素(诸如由用户创建的扩展元素)传播到提供商创建的数据工件，至少传播到目标环境中用户可访问的某些数据工件，而这种传播不是针对用户创建的数据工件的扩展来执行的。

同样地，当在提供商的不同“级别”(例如，基础软件与用于特定用例的专用软件)上创建了扩展时，将较低级工件的扩展传播到至少一些较高级工件可能是合适的。

示例2——具有数据工件及其扩展的示例计算环境

如在示例1中论述的，数据工件的扩展可以来自许多来源。例如，一组基础数据工件可以用于许多应用中，其中不同应用可以具有对基础数据工件的不同修改(扩展)，或者可以具有使用基础数据工件(包括引用或合并基础数据工件的元素)的不同数据工件。例如，可以定义一组基础数据工件来存储与业务运行相关的信息。然而，根据这些基础数据工件是用于生产计划软件应用还是人力资源软件应用，以不同的方式对基础工件进行扩展可能是有利的。同样地，使用基础工件或从基础工件衍生的专用工件的不同实体可以受益于扩展这些工件以更好地满足他们的需求。甚至实体内的单个用户或部门也可能希望扩展他们有权访问的数据工件。

图1图示了可以实施所公开的技术的计算环境100。图1可以表示数据库系统的不同用户(诸如基于云的数据库系统中的租户)有权访问标准内容并且至少一些租户具有标准或基础内容(例如，数据工件)的扩展的一种场景。然而，如上所述，除非另有说明，否则所公开的创新不限于任何特定用例。因此，结合图1描述的概念可以应用于其它用例。例如，可以对由软件提供商(可以与负责创建被扩展的“基础”数据工件的软件提供商相同或不同)创建的扩展进行评估以在不同的上下文(例如，不同的应用或操作环境，或者在不同的计算系统上，诸如当基于云的系统与本地系统一起使用或取代本地系统时)中传播。此外，虽然图1图示了与客户端系统通信的中央计算系统，其中中央计算系统具有多个租户，但是更一般地，相对于图1描述的技术可以使用源环境和目标环境来实施，更一般地，除非论述显然仅与不同的计算系统或具有多个租户的系统相关。

计算环境100包括中央数据库系统104，该中央数据库系统在一些实施方式中可以是基于云的数据库系统。中央数据库系统104可以包括标准内容108，诸如数据库工件112、114，其中这些数据库工件可以是表格或视图。标准内容108可以是例如与一个特定应用或一组应用相关联的内容，并且内容的全部或大部分通常与许多客户端相关。标准内容108可以从数据包118中安装，并且可以使用更新121(也可以实施为数据包)来更新或升级。例如，在安装或升级了标准数据库模式之后，可以从客户端的数据库系统中检索这个内容的扩展。

在一些情况下，客户端可以修改标准内容108的全部或一部分。在其它情况下，标准内容108受到保护以避免客户端修改，特别是如果标准内容由多个客户端共享或者如果标准内容的修改可能会引起应用功能的丢失。如果标准内容108不可由客户端修改，则在一些实施方式中可以由客户端扩展。也就是说，标准内容108的数据库工件可以是“锁定的”，但是客户端可以能够创建添加到或更改标准数据库工件的其它数据库工件。

图1将计算环境100示为包括租户126a、126b。在一些情况下，租户126a、126b经由共享容器130访问标准内容108，如针对租户126a所示的(其中租户容器没有示为包括工件112、114)。在其它情况下，租户容器可以包括标准内容108的工件，诸如针对租户126b所示的，该租户的容器包括工件112。

租户1261、126b的容器示为包括工件112的扩展134a、134b。扩展134a、134b可以对工件112进行各种修改，诸如添加、移除或更改工件的数据或元数据。作为对数据的更改的一个示例，扩展134a可以向由工件112表示的视图或表格中添加列。

举例来说，工件112可以表示雇员的数据，具有姓名、社会保险号、工作标识符、工资率等字段。鉴于COVID-19疫情以及2020-2021年引入的疫苗，雇主可能会希望跟踪雇员是否接种疫苗、雇员接种疫苗的日期等。由于各种原因，在经由标准内容108将指示雇员是否接种疫苗的标志引入工件112之前，可能需要时间。客户端(由租户126a、126b表示)可以包括将已接种疫苗标志添加到工件112的扩展134a、134b。在一些情况下，用于特定客户端或租户的工件是基于标准内容108和针对/由客户端定义的任何扩展来创建的。例如，工件142可以通过组合或合并工件112和扩展134a或134b来创建(例如，使用DDL语句)。

在一些实施方式中，用于扩展的数据从客户端系统150导入，并且存储在租户126a、126b的容器中或中央数据库系统104中。在其它情况下，数据存储在计算环境100的另一个组件中，或者作为工件创建过程的一部分从客户端系统150中获得，但是不会存储在客户端系统150之外。

用于扩展134a的数据可以使用基础设施152从相关客户端系统150中获得。在一个具体示例中，基础设施152可以是如2021年9月22日提交的名称为“IDENTIFICATION ANDIMPORT OF METADATAγFOR EXTENSIONS TO DATABASE ARTIFACTS(用于数据库工件扩展的元数据的识别和导入)”的美国专利申请第17/448,514号中描述的，该专利申请在不与本公开相矛盾的程度上通过引用并入本文。

客户端系统150可以包括数据工件定义154，该数据工件定义可以是数据工件112的定义170。通过将数据工件的定义和为了与该数据工件联用而创建的扩展进行组合或合并，至少可以产生或定义一些数据工件。也就是说，例如，中央数据库系统中的工件142可以通过组合数据工件的定义170和数据工件的扩展134a的定义180来产生。同样地，定义154、156可以用于定义其它数据工件，其中基础工件定义170的元素或其扩展定义180的元素用于至少部分地定义相关数据工件。

数据工件定义信息可以通过中央系统104或与中央系统通信的目标系统158(或直接与客户端系统150通信)从客户端系统150中检索。更新服务160可以用于确定应该发送哪些数据工件信息到另一个计算环境，这可以包括选择单个数据工件定义或分层多个数据工件定义的结果，或者通过将扩展定义应用到扩展数据工件的基础定义。

更新服务160可以应用各种规则162，这些规则可以包括确定是否应该传播扩展元素或确定修改或扩展了哪个数据工件的规则，包括从而可以确定是否应该传播扩展元素。客户端系统150可以包括日志记录组件164。日志记录组件164可以包括日志168，其中该日志可以指示传播或不传播什么扩展元素，或者记录在传播扩展元素时可能遇到的任何传播错误。虽然在客户端系统150处示出，但是扩展元素传播可以且经常在目标系统处执行，诸如在中央数据库系统104中(或者在与中央数据库系统通信的中间系统或环境处，诸如实施虚拟数据模型的系统或环境)。在这种情况下，更新服务160、日志记录组件164和日志168均可以包括在中央数据库系统104(或中间系统)中。

图1以工件112的内容170和扩展134a的内容180的形式图示了标准内容108和这种标准内容的扩展的示例。内容170包括数据选择172，包括元素174a、174b。数据选择172可以是查询，诸如SQL查询。内容170可以包括元素176a、176b，诸如提供关于元素174a、174b的语义信息的元素。内容170还可以包括注解178a、178b、178c，其中注解可以指示工件112的属性或控制工件的使用，诸如定义是否向终端用户展示该工件。

扩展134的内容180可以添加、移除或更改内容170的元素，并且可以添加或修改内容170的注解。如图所示，内容180包括修改注解178a的注解182a、将注解178c的值设置为NULL(空值)的注解182b、以及添加到内容170中的注解182c。因为没有移除或修改注解178b，所以当工件与工件扩展180合并时，该注解会存在于工件170中。

在至少一些情况下，可以以与注解类似的方式来处理元素。工件扩展180示出元素184a已经添加到内容170中，而元素176a已经通过使用元素184b将元素176b的值设置为NULL来移除。内容180可以包括附加元素或附加元素选择188，或者可以移除元素，诸如内容180中的将元素176a的值设置为NULL的语句190。

示例3——具有差异客户端访问的示例计算环境

图2图示了用于所公开的技术的特定用例的特定计算环境200，但是与图1一样，其中针对该用例实施的技术可以适用于需要传播扩展或至少评估扩展以供传播的其它用例。计算环境200进一步详细说明了如何可以扩展数据工件以及如何可以使数据工件层级相关。

计算环境200还示出了所公开的创新可能有用的特定场景。在该场景下，已经在客户端系统208处创建了数据工件的扩展216，具体为数据库视图212。视图212在提供商系统204处也是可用的(或者将变得可用)。如将进一步论述的，视图212由提供商系统204中的其它数据工件引用(也可以由客户端系统208中的其它数据工件引用或者引用客户端系统208中的其它数据工件，虽然为了简单起见在图2中未示出，但是在一个特定示例中，视图212可以以与视图212如何用于提供商系统204中类似的方式引用客户端系统中的一个或多个数据工件或者由客户端系统中的一个或多个数据工件引用)。然而，由于权限，或者由于提供商系统208的架构，客户端不能直接在客户端系统处访问视图212。为了解决这个问题，可以使用所公开的传播技术将扩展应用于更高级数据工件，使得扩展216在提供商系统204处客户端确实有权访问的建模级别上可用。

在计算环境200中，视图212引用表格220、222(或表示这些表格的数据工件)。例如，视图212可以选择表格220、222中的全部或部分数据。特别是当视图212定义在虚拟数据模型中时，视图可以具有附加信息，包括描述应该如何显示视图的元素、应该如何对来自表格220、222的数据执行计算、或者定义可以如何使用视图的信息，包括可用于确定什么用户能够访问视图的信息。因为视图212是相对于表格220、222定义的，所以该视图可以被称为处于数据工件214的分层结构中比表格220、222更高的层或级别。

以类似的方式，视图212可以由其它数据工件引用，包括在视图212的上一层的视图226、在视图226的上一层的视图230、在视图230的上一层的视图234和在视图230的上一层的立方体238。

计算系统200中的一个或多个数据工件可以与扩展相关联。除了扩展216之外，视图226、234还与相应扩展238、240、242相关联。需要注意的是，数据工件可以具有零个或更多个扩展，包括具有多个扩展，如针对具有其扩展240、242的视图234所示的。视图230提供了数据工件如何可以引用多个其它数据工件的另一个图示，其中视图230引用视图226和视图246(具有扩展250)以及表格252。视图246又引用视图254，而视图254引用表格256。一般而言，数据工件可以引用零个或更多个其它数据工件，包括引用两个以上的数据工件。

图2提供了相对简单的数据模型或模式，以便描述所公开的技术。实际上，用于企业级用途的数据模型可以具有相互关系复杂的数千个数据工件。因此，用户可能很难理解数据模型以获知应该传播什么扩展以及应该如何传播扩展，即使提供了对数据模型的相关级别的访问，也是如此。此外，传播扩展可能是耗时、冗长且容易出错的。这些问题都可以通过使用所公开的技术使传播过程自动化或半自动化来解决。

示例4——示例传播过程

图3图示了用于传播数据工件的扩展的方法300，包括确定是否应该传播特定扩展。方法300可以在图1的计算环境100或图2的计算环境200中实施。然而，更一般地，方法300可以在两个数据工件层级结构之间使用，其中对扩展进行评估以在层级结构之间传播。

在312处，接收扩展以供分析。例如，可以响应于在304处确定了对扩展的更改(诸如对扩展的修改或扩展的删除)或响应于在308处接收到的传播请求来接收扩展。在一个特定实施方式中，可以通过接收更改扩展或添加扩展的提交指令来触发在304处确定更改或修改后的扩展。或者，包含修改后的或新的扩展的消息可以导致在304处的确定。

在又一个示例中，可以定期分析诸如存储库中的扩展以确定是否添加或修改了扩展。分析存储库可以包括将一个数据工件(或扩展，诸如在扩展工件中，其中至少出于所论述的检测对扩展数据的更改或添加的目的，将数据工件、扩展和扩展工件一起处理，)的时间戳与另一个数据工件的时间戳进行比较。如果时间戳不同，则可以认为旧的数据工件与新的数据工件相比已经被更新。可以可选地维持旧版本的数据工件，因此一旦确定发生了更改，便可以比较扩展的两个或更多个版本以确定一个或多个更改的性质。

作为用于确定是否修改了数据工件的另一种技术，也可以计算并存储数据工件的哈希值。可以定期地重新计算哈希值，并且与存储的值进行比较。如果重新计算的值与相应存储值不匹配，则可以表明对数据工件的更改。

可以检索更新后的数据工件(或扩展)的定义以确定更新后的工件是否包含扩展，并且可以使用诸如文本比较的技术来确定添加的扩展元素的性质。在一些情况下，可以对数据工件进行标记(诸如用注解)以表明该数据工件是否是可扩展的。如果数据工件是不可扩展的，则无需进一步考虑。

在308处接收传播请求可以包括从用户或从另一个计算过程接收显式传播请求。例如，作为扩展创建或修改过程的一部分的或与将数据工件迁移到不同的计算系统或环境相关联的用户或过程可以请求传播扩展(或评估扩展以供传播)。

在316处，对一个或多个扩展的元素进行评估。在316处的评估可以包括确定扩展或扩展元素(为了便于解释，统称为“扩展元素”)的类型。评估还可以包括确定如何使用特定类型的特定扩展。如将进一步说明的，分析如何使用扩展可以帮助确定是否有益于用户(或过程)传播扩展元素。在一个特定示例中，如果考虑中的数据工件大量使用、引用或合并了扩展数据工件，则更有可能的是，来自扩展数据工件的扩展应该传播到考虑中的数据工件。因此，在316处的评估可以涉及咨询一组规则320。

至少部分地基于在316处的评估和规则320，在324处，确定是否应该将给定扩展元素传播到考虑中的特定数据工件(其中可以基于给定数据工件是否直接或间接使用、引用或合并由扩展元素扩展的数据工件来确定考虑中的数据工件)。如果确定应该传播或推荐传播扩展元素，则在326处，可以对扩展元素进行标记以供传播。如下面将进一步详细说明的，标记以供传播的元素最终可以在合适情况下自动传播，或者可以呈现给用户或过程以决定是否应该传播扩展。

在326处对扩展元素进行标记以供传播可以包括将扩展元素标记为待自动传播的或提供用于传播决定的元素。如果确定不应该传播(或不推荐传播)扩展元素，则方法300进行到328，其中确定扩展是否包含附加扩展元素。如果是，则方法300进行到316以评估扩展的另一个扩展元素。如果在328处确定扩展不包含附加扩展元素，则方法300进行到332，确定是否存在对于正在分析的扩展的扩展元素的传播应该考虑的附加相关数据工件。如果是，则方法300返回到316，相对于下一个考虑中的数据工件对扩展的扩展元素进行评估。

如已经描述的，“相关数据工件”可以包括在层级结构的不同级别上相关的数据工件，使得较高级数据工件建立在较低级数据工件之上。在一些情况下，方法300可以针对数据工件而继续进行，直到层级结构中的最高级别。然而，在其它情况下，方法300可以针对给定扩展元素而提前终止。例如，如相对于图2所述的，在一些情况下，可能希望将扩展传播到层级结构中特定用户有权访问具有扩展元素的数据工件的最低级别。此时，可以可选地让用户确定是否应该将扩展传播到更高级别。在又一个实施例中，可以自动进行传播直到达到层级结构中的特定级别，并且可以向用户呈现到达更高级别的传播作为选项，其中在用户同意时可以自动进行进一步传播。如将进一步描述的，诸如在340、344、352处，除了以半自动的方式进行传播的情况之外，也可以以全自动的方式进行传播，其中传播是在没有用户输入的情况下进行的或者是在需要用户或过程同意任何传播动作的过程中进行的(即所有传播分析都以“建议”的形式提供)。

如果在332处确定不考虑附加数据工件，则方法300进行到336，其中确定是否评估附加扩展。如果是，则方法返回到316，分析下一个扩展的元素。如果在336处确定不分析更多元素、数据工件或扩展，则方法进行到340，其中确定是否自动传播部分或全部扩展元素。

对于不自动传播的任何扩展元素，方法300进行到344，向用户显示扩展元素列表和传播信息(或者返回到可以代表或取代用户采取动作的过程)。例如，在334处显示扩展元素列表可以包括显示扩展的标识符、扩展元素的标识符、最初扩展的数据工件的标识符(可选地具有关于数据工件的信息，诸如数据工件的定义中的信息)、以及用户可能考虑利用扩展元素扩展的一个或多个数据工件的标识符(可选地具有关于这一个或多个数据工件的信息，诸如数据工件的定义中的信息)。其它信息可以可用于在344处显示，诸如其中使用相关扩展元素/数据工件的软件程序、与扩展/数据工件相关联的用户界面屏幕、或关于与扩展元素和数据工件相关联的计算系统的信息(例如，包括关于数据工件或扩展的源系统或环境的信息或者关于数据工件或扩展的目的地(或目标)系统或环境的信息)。

在348处，确定用户(或过程)是否选择了待传播到一个或多个数据工件的一个或多个扩展元素(或全部扩展)。如果是，则方法300在325处传播扩展元素。在352处传播扩展元素包括将扩展元素应用于数据工件，其中扩展元素可以包括在应用于扩展数据工件的单独数据工件(例如，表示扩展的数据工件)中或者可以直接包括在扩展数据工件的定义中。在352处的传播还可以包括将扩展元素(以及可选的数据工件)从源计算系统或环境发送到目的地(或目标)计算环境。然后，方法300可以在356处结束。

如果在340处确定自动传播一些扩展元素，则方法300可以进行到352。在一些实施方式中，一些扩展元素可以自动传播，而其它扩展元素可以首先在344处呈现给用户以供评估；而在其它实施方式中，所有扩展元素都自动传播或者由用户评估。虽然已经将方法300描述为具有自动传播的或响应于用户选择而传播的一些扩展元素，但是可能存在根据规则320没有扩展元素被识别为适合传播的情况，在这种情况下，方法300可以在356处结束，诸如在确定在340之前没有进一步的扩展元素、数据工件或扩展需要评估之后。

应该理解的是，可以对方法300进行各种修改，包括以不同于图3所示的顺序执行各种操作。例如，方法300设想在传播或推荐(或反对)传播元素之前分析所有扩展元素和数据工件。然而，在其它实施方式中，可以在分析其它扩展元素之前或之时传播或推荐扩展元素以供传播。同样地，分别在328、332、336处的分析附加元素、相关数据工件和附加扩展可以以不同于所述的顺序来执行。例如，可以在方法300进入分析其它数据工件之前分析特定数据工件的附加元素或扩展。

此外，可以对方法300添加附加动作。例如，方法300的执行可以产生更改日志，可以向用户提供该更改日志，使得用户可以理解采取(以及可选地不采取)哪些传播动作，包括使得用户可以进行进一步传播或可以回退(或更新)任何不期望的传播动作。同样地，如果在传播期间遇到错误，则可以记录这些错误以供用户或过程查看。

对扩展的更改可以包括修改、添加或删除。删除可以有两种——从扩展中删除元素或删除整个扩展工件。在删除扩展元素的情况下，在添加或不添加另一个扩展元素的情况下，将删除处理为对扩展的更改，并且可以如上所述进行传播(例如，在与传播新元素相同的条件下传播删除，并且对现有扩展元素的修改可以以类似的方式来处理)。如果删除了一个扩展元素并且该扩展元素是扩展工件的最后一个剩余扩展元素(包括可能在数据工件内定义的)，则如果将扩展保持为与其扩展的工件分开的单独工件，可以删除整个扩展工件；或者则如果扩展包括在扩展工件的定义中，则可以删除整个扩展部分。

当从另一个系统中检索工件信息时，则在一些情况下，所检索到的是数据工件的合并视图(consolidated view)。也就是说，数据工件可以包括“基础”数据工件、一个或多个扩展工件、以及通过引用其它数据工件而包括的组件。当检索到该数据工件时，来自该工件集合中的组件会合并在一起。当移除最后一个扩展组件时，该合并数据工件仍然维持其“原始的”非扩展状态。在其它情况下，导入数据工件集合，并且当移除扩展工件的最后一个扩展组件时，可以删除扩展工件。而且，当传播扩展组件时，在一些情况下创建了扩展工件，其中一旦/如果移除了最后一个扩展组件便可以移除该扩展工件。

示例5——传播扩展元素的示例考虑

如结合图3的方法300所述的，虽然在一些情况下可能存在将或不将所有扩展传播到所有或某些数据工件的情况，但是通常可能希望提供对应该传播或推荐传播什么扩展元素的更细致分析。本示例5提供了如何可以对与诸如SQL或其方言的查询语言的元素相关的数据工件的扩展元素进行分析以供传播的示例。然而，服务于类似目的但没有用查询语言表达的扩展元素可以以类似的方式进行处理。此外，更一般地，可以定义规则，使得某些扩展元素标记为总是被传播、从不被传播或在特定条件下被传播。

可以考虑用于传播的一种类型扩展元素是元素。元素可以对应文字、变量、表格中的字段(可以视为一种变量)、结构化、半结构化或非结构化的数据类型(其中数据类型例如也可以表示数据库表格的字段，因为列可以视为特定的简单数据类型的数组，诸如字符串、整数等)。文字和变量(或更复杂的数据类型的元素)可以是使用为数据工件(或扩展)定义的或为数据工件(或扩展)指定的其它元素来计算得出的值。在一个特定示例中，“元素”是“数据元素”，如在ABAP编程语言中使用的。

元素的扩展的传播可能是复杂的，因为可能并不清楚仅仅因为一个数据工件引用、使用或合并了另一个数据工件的一部分就传播元素的扩展是否是合适的。例如，可能希望仅创建两个数据工件之间的链接，在这种情况下，对于引用工件而言仅使用被引用对象的关键字(例如，主关键字、或关键值存储中的关键字)可能就足够了。另一方面，如果数据工件的其它属性(包括元素——引用数据工件实际上使用被引用数据工件的数据)由引用数据工件使用，则更有可能的是，数据工件的扩展元素在引用数据工件中也是有用的。因此，在一个特定实施方式中，与元素相关的扩展不会传播到仅引用另一个数据工件的数据工件，诸如当仅使用了被引用工件的主关键字时。如果被引用数据工件的其它组件或足够数量的组件由引用数据工件使用、引用或合并，则被引用数据工件的元素将会传播或推荐传播到目标数据工件。

在一些情况下，用户或过程可以忽略是否会传播特定扩展元素的假设。或者，可以选择不同的规则以应用于不同的数据工件、数据工件类型或者源或目的地计算环境等，其中不同的规则可以使传播扩展更容易或更难(或者可以指定不同的规则，其中这些规则不一定比其它规则更容易或更难)。

数据工件可以包括各种类型的注解，其中注解可以应用于数据工件的全部或一部分，包括特定元素。在一些情况下，注解可以从注解一个目标(例如，元素)变为注解另一个目标。如何处理这种注解可以取决于可用于处理注解的框架。在一些情况下，注解在首次更改实体或元素时进行复制，并且如果源数据工件具有更新的注解时也不会自动更新。在一些情况下，不会对注解进行分析以供传播，因为可能并不清楚注解的目的是什么、更改注解的原因或者是谁更改的。元素(或其它注解目标)在目标数据工件(包括通过使用所公开的技术传播)中可用就足够了，并且用户或过程可以选择让注解处于原始形式(当被复制/引用时)或者像在源数据工件中一样更新注解。

然而，在一些情况下，提醒用户或过程通过扩展添加的元素的注解不同于来自源数据工件中的注解的注解可能是有用的(包括因为源工件中的扩展元素的注解在源数据工件中被删除)。这样，可以提醒用户确认如何在目标数据工件中使用注解的正确性。在进一步的情况下，可以传播元素注解的全部或一部分。例如，在将进行传播或推荐传播的情况下，可以定义注解类型、带注解的元素或带注解的数据工件的列表。

如上所述，数据工件可以链接在一起，并且这些链接可以通过关联关系来定义(例如在CSN中)。除了确定是否应该将关联关系中的元素传播到其它数据工件之外，还可以分析关联关系的声明以供传播。这种分析可以以类似于针对元素描述的方式来进行。也就是说，如果关联关系仅引用了与扩展相关联的数据工件的关键字段，则不会将该关联关系传播到目标数据工件。如果关联关系使用了相关联的数据工件的其它元素或足够数量(或类型、或数量和类型的组合)的元素，则将该关联关系传播到目标数据工件。

记住关联关系可以服务于多种目的可能是有用的。也就是说，可以将关联关系用于确定“相关的”数据工件，其中目标数据工件可以基于其与源目标工件的关联关系来识别。然而，关联关系也可以是考虑传播到目标数据工件的扩展。

至少某些数据工件从其它数据工件中选择数据，在一个特定用例中，这些其它数据工件可以是虚拟数据模型中的其它数据工件或者可以是物理数据模型中的数据工件。在一些情况下，物理数据库模型中的表格表示为虚拟数据模型中的实体数据工件，因此数据工件可以以与如何可以使用诸如SQL的查询语言从数据库中检索数据类似的方式从虚拟数据模型中的实体数据工件中选择数据。

查询语言的不同类型的操作可以以不同的方式来处理。某些类型的操作可以视为具有更基本的性质，诸如影响获取什么数据(例如，WHERE、ON或HAVING操作(在哪里、基于或具有操作))或如何呈现数据(例如，GROUP BY或ORDER BY操作(分组或排序操作))。因此，传播扩展可以以组织或个体用户可能不期望的方式使用目标数据工件来限制什么数据是可用的。同样地，报告或其它软件功能可能期望数据以特定顺序呈现，并且如果传播了改变可用数据或如何呈现或排序数据的扩展，则这些报告或功能可能是不可用的或者不能如预期那样操作。因此，在至少一些情况下，不会传播限制(例如过滤)数据或改变如何提供数据的扩展。

扩展元素可以出现在数据工件的公式中。因为改变公式中的元素可能会影响公式的输出，所以公式的扩展元素通常以与WHERE语句类似的方式来处理。

然而，上述行为可以在其它用例中进行更改，包括可以覆盖的默认行为，其中覆盖的行为可以针对通常不传播的扩展或通常传播的扩展来指定。例如，数据工件、数据工件组件、扩展或扩展元素可以注解为指定不同于默认行为的行为，诸如指示将要传播某些扩展元素、将不会传播某些扩展元素或指定不同于默认传播规则的传播规则。或者，可以基于特定应用或基于特定源或目标计算环境，为特定扩展类型、特定扩展、特定源或目标数据工件指定不同的行为。

对于这些类型和其它类型的扩展，应该理解的是，通常不期望所公开的传播技术影响数据模型中显式包括有扩展元素的其它数据工件。也就是说，假设在源系统中存在较高级或较低级数据工件，并且两者都包括扩展。规则可以确定不将来自较低级数据工件的扩展传播到较高级数据工件。然而，如果较高级数据工件显式包括有该扩展，则该扩展通常在较高级数据工件中是可用的。

诸如AS操作的一些操作导致数据(例如，与扩展元素(诸如元素)相关联的)被重命名。此外，如上所述，扩展元素的传播可能会导致名称冲突——其中被传播的传播元素具有与目标数据工件中的扩展元素相同的名称。因此，当传播扩展元素时，可以检查扩展元素的名称(标识符)是否是唯一的(或者在整个模式中是唯一的，或在一系列相关数据工件中是唯一的，或至少相对于源数据工件和目标数据工件是唯一的)。

如果名称不是唯一的，则可以将其中一个扩展元素(例如，添加到目标数据工件的元素)进行重命名以避免名称冲突。可能希望将来自源数据工件的扩展元素的名称保持接近其原始名称，使得用户或过程可以更容易识别和理解扩展元素的目的。因此，重命名可以包括向扩展元素的名称添加计数器或类似扩展(例如，如果扩展和目标数据工件都包括“雇员(employee)”元素，则可以将来自扩展的元素作为“employee_1”或“exployee_ext1”传播到目标数据工件，其中“ext”可以指示通过扩展传播过程的重命名，并且“1”可以是如果需要将扩展更新附加次数以避免在又一个目标数据工件中的名称冲突时的可更新的计数器)。作为显式重命名的扩展(诸如AS操作)可以按照一般名称冲突的描述进行处理。也就是说，在与目标数据工件中的名称不冲突的程度上(并且，与其它类型的扩展元素一样，在没有以某种方式改变默认行为的程度上)，可以传播扩展元素。

如果扩展元素(诸如元素)包括在特定类型的操作(诸如UNION操作(联合操作))中，则可能会引起复杂情况。例如，考虑扩展为包括有附加元素的现有UNION操作。一般而言，与UNION操作相关联的扩展元素的传播以与处理别名/名称冲突类似的方式来处理。也就是说，会传播扩展元素，但是如果与目标数据工件中的名称发生冲突时则在目标实体处对扩展元素进行重命名。

当UNION可能涉及多个源实体时，可能会出现额外的复杂情况。为了实现经由UNION收集的数据工件之间的一致性，对UNION的源数据工件进行修改使其也包括通过扩展添加的元素可能是合适的。如果源数据工件不包含扩展元素(或者如果不清楚源数据工件中的元素是否与扩展工件相同)，则可以将扩展元素添加到源数据工件，但是设置为NULL值。

在一些情况下，可以包括更复杂的逻辑以帮助确定两个元素(扩展元素和数据对象的元素)是否相同。例如，元素是否共享相同的名称、类型或描述匹配可以用于帮助确定元素是否相同。可以从数据字段或类似信息源中检索信息，包括如示例7-16中描述的。甚至可以使用更复杂的技术，诸如分析如何在各种工作负载中使用元素，并且可以使用机器学习算法来分析相关数据以帮助确定两个元素相同的可能性。可以使用各种标准(诸如置信度)来确定两个元素是否足够相似以至于不需要重命名或添加。

在某些情况下，可以传播INTERSECT/EXCEPT操作(相交/例外操作)。这些操作通常需要具有结构上相似的输出的两个SELECT(选择)(或其它数据选择标准)，从而可以进行比较(例如，使用标准集逻辑)。为此，不可能只扩展INTERSECT操作中涉及的一个数据工件。然而，由于上面描述的在传播修改选择什么数据或如何呈现数据的扩展时的问题，可能不适合修改INTERSECT操作中的其它数据工件。然而，在某些情况下，可以传播与INTERSECT操作相关联的扩展元素，诸如当它们涉及公共源时。例如，如果所涉及的数据工件分别引用具有相关扩展的数据工件，则可以传播扩展元素。

示例6——示例传播操作

图4图示了可以用于传播扩展元素的方法400。该方法400可以在图1的计算环境100或图2的计算环境200中实施，并且可以表示结合图3的方法300描述的至少某些动作。更一般地，方法400可以在将扩展从一组数据工件传播到另一组数据工件时实施。

在410处，接收第一数据工件。第一数据工件包括多个基础元素和包括至少一个第一扩展元素的扩展。在420处，确定与第一数据工件相关的第二数据工件。在430处，分析该至少一个第一扩展元素以供传播到第二数据工件。在440处，确定应该将该至少一个第一扩展元素传播到第二数据工件。在450处，将该至少一个第一扩展元素传播到第二数据工件。

示例7——包括语义标识符的示例表格元素

数据库系统通常包括存储关于数据库模式的信息的信息存储库。例如，PostgreSQL包括INFORMATION_SCHEMA，该INFORMATION_SCHEMA包括关于数据库系统中的表格和某些表格组件的信息，诸如属性(或字段)及其相关联的数据类型(例如varchar、int、float(可变长字符串、整型、浮点型))。其它数据系统或查询语言包括类似概念。然而，这些类型的存储库通常仅存储关于数据库组件的技术信息，而不是语义信息。

使用数据层操作的其它数据库系统或应用或框架可以包括存储数据语义信息的存储库。例如，德国沃尔多夫的SAP SE提供了可与数据库系统结合使用的ABAP编程语言。ABAP提供了开发数据库应用的能力，这些数据库应用不知道底层关系数据库管理系统的性质，包括供应商。在某种程度上，这种能力是使用数据字典实现的，诸如对于虚拟数据模型。数据字典可以包括至少一些与信息模式中维持的信息类似的信息。然而，数据字典可以包括关于数据的语义信息、以及可选的附加技术信息。

此外，数据字典可以包括关于表格中的字段的文本信息，诸如字段的目的或用途的人类可读描述(有时采用不同的语言，诸如英语、法语或德语)。在至少某些情况下，文本信息可以用作对计算机的语义信息。然而，其它类型的语义信息不一定(至少容易地)是人类可理解的，但是可以是比解析主要供人类使用的文本信息更容易被计算机处理。数据字典还可以通过各种属性(可以反映在元数据中)来包含或表达数据字典对象(或工件)之间的关系，诸如使数据字典反映出字典对象被分配给数据包，从而通过数据包分配使彼此之间具有关系。

如本文所使用的，“技术信息”(或技术元数据)涉及将数据描述为数据的信息，该信息是可以用于解释数据的值的信息，诸如类型，并且可以影响如何处理数据。例如，值“6453”可以被解释(或投射)为整数、浮点数、字符串或字符数组等各种可能性。在某些情况下，可以对一个值进行不同地处理，这取决于该值是否是数字(诸如整数或浮点数)或者是否被视为字符的集合。同样，技术信息可以指定数据的可接受值，诸如允许的长度或小数位数。在不考虑数据表示什么或“意味着”什么的情况下，技术信息可以指定数据的属性。然而，数据库系统的设计者当然可以在本身知道数据的语义属性的情况下为特定的数据选择特定的技术属性——例如，“如果我想用一个值表示一个人的姓名，则我应该使用字符串或字符数组，而不是浮点数。”另一方面，在至少某些情况下，数据类型可能是数据库管理员或用户不期望的类型。例如，可能使用单独的数字或字母数字标识符，而不是使用一个人的姓名来标识与这个人相关联的数据，这可能与基于数据的“含义”的直觉相反(例如，“我不认为自己是一个数字”)。

如本文所使用的，“语义信息”(或语义元数据)涉及描述数据的含义或目的的信息，该含义或目的可以是针对人类或计算机过程的。作为一个示例，技术数据信息可以指定获得具有“XXX-XX-XXXX”格式的值的数据，其中X是0到9之间的整数。该技术信息可以用于确定应该如何处理数据或者特定值是否有效(例如，“111-11-1111”是有效的，而“1111-11-1111”不是有效的)，但是不会指示该值表示什么。与数据相关联的语义信息可以指示该值是否是社会保险号、电话号码、路由地址等。。

语义信息也可以描述如何处理或显示数据。例如，“知道”数据是电话号码可以使该值显示在GUI的一部分中，而不是GUI的另一部分中，或者可以调用或不调用特定处理规则，这取决于该规则对于“电话号码”是否有效。在至少一些情况下，“语义信息”可以包括可用于描述数据或应该如何使用或处理数据的其它类型的信息。在特定情况下，数据可以与标签(诸如数据的的人类可理解描述，例如“电话号码”)、文档(诸如在具有标签的字段中应该包括什么信息的描述，例如“输入包括区域码的11位电话号码”)或可在帮助屏中使用的信息(例如“在此输入您的家庭电话号码”)中的一个或多个相关联。

通常，必须为数据提供技术信息。在数据库表格的字段的情况下，例如，通常需要为字段和数据类型提供名称或标识符。字段的名称或标识符可能或可能不用来提供语义信息。也就是说，数据库设计者可能会选择“Employee_Name(雇员姓名)”、“EMPN”或“3152”的名称。然而，由于名称或标识符用于定位/区分该字段与另一个字段，因此在本公开的上下文中，将名称或标识符视为是技术信息，而不是语义信息，即使它可以容易地向人类传达含义。在至少一些实施方式中，使用语义信息是可选的。例如，即使使用数据字典，在不使用语义信息的情况下可以指定数据库对象中使用的一些字段(诸如表格，但也可能是其它对象，其中这些其它对象通常与底层关系数据库系统中的一个或多个表格相关联)，而其它字段与语义信息相关联。

图5是图示与驾驶员的事故历史相关的数据模式500或工件定义的示例实体-关系(ER)类型图。模式500(可以是更大模式的一部分，其它组件在图5中未示出)可以包括与执照持有者(例如，具有驾驶执照的个人)相关联的表格508、与执照相关联的表格512、表示事故历史的表格516和表示汽车(或其它车辆)的表格504。

表格504、508、512、516中的每一个都具有多个属性520(但是在某些情况下，一个表格可能只有一个属性)。对于特定表格504、508、512、516，一个或多个属性520可以用作主关键字——唯一标识元组中的特定记录并且被指定为访问表格中元组的主要方法。例如，在表格504中，Car_Serial_No(汽车序列号)属性520a用作主关键字。在表格516中，属性520b和520c的组合一起用作主关键字。

通过使用外来关键字，一个表格可以引用与另一个表格的主关键字相关联的记录。例如，执照号码表格516具有表格516中Car_Serial_No的属性520d，该属性是外来关键字并且与表格404的相应属性420a相关联。外来关键字的使用可以有多种目的。外来关键字可以链接不同表格中的特定元组。例如，属性520d的外来关键字值8888将会与表格504中具有属性520a的值的特定元组相关联。外来关键字也可以充当约束条件，其中不能创建具有(或更改为具有)在被引用表格中不作为主关键字值存在的外来关键字值的记录。外来关键字也可以用于维持数据库一致性，其中可以将对主关键字值的更改传播到属性是外来关键字的表格。

表格可以具有其它属性或属性的组合，这些属性用来唯一标识元组，但不是主关键字。例如，表格516具有由属性520c和属性520d组成的替换关键字。因此，可以使用主关键字(例如，作为另一个表格中的外来关键字)或通过与替换关键字的关联关系来访问表格516中的唯一元组。

模式信息通常维持在数据库层中，诸如与维持表格值的位置(例如，在RDBMS中)相关联的软件层，并且通常包括表格504、508、512、516的标识符以及它们相关联的属性520的名称526和数据类型528。模式信息还可以包括至少一些可使用标志530传达的信息，诸如字段是否与主关键字相关联，或指示外来关键字关系。然而，包括更多非正式关联关系的其它关系可以不包括在与数据库层相关联的模式(例如，PostgreSQL的INFORMATION_SCHEMA)中。

示例8——包括语义标识符的示例表格元素

图6是图示数据库模式600的元素以及如何可以使这些元素相互关联的示意图。在至少一些情况下，数据库模式600可以维持在除了数据库系统的数据库层之外。也就是说，例如，数据库模式600(或虚拟数据模型)可以独立于底层数据库，包括用于底层数据库的模式。通常，将数据库模式600映射到数据库层的模式(例如，图5的模式500)，使得可以通过数据库模式600检索记录或其部分(例如，特定字段的特定值)。

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

数据包610可以与一个或多个域614(例如，特定类型的语义标识符或语义信息)相关联。反过来，域614可以与一个或多个数据包610相关联。例如，域1(即域614a)仅与数据包610a相关联，而域2(即域614b)与数据包610a和数据包610b相关联。在至少一些情况下，域614可以指定哪些数据包610可以使用该域。例如，可能的是，与制造过程中使用的材料相关联的域614可以由过程控制应用使用，但是不能由人力资源应用使用。

在至少一些实施方式中，虽然多个数据包610可以访问域614(以及包含该域的数据库对象)，但是一个域(以及可选的其它数据库对象，诸如表格618、数据元素622和字段626，如下面更详细描述的)主要分配给一个数据包。将域614和其它数据库对象分配给唯一数据包可以有助于创建数据库对象之间的逻辑(或语义)关系。在图6中，将域614分配给数据包610图示为实线，而访问权限图示为虚线。因此，将域614a分配给数据包610a，而将域614b分配给数据包610b。数据包610a可以访问域614b，但是数据包610b不能访问域614a。

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

将更详细说明的，域614可以表示最小粒度单元，数据库表格618或其它模式元素或对象可以从该最小粒度单位构建。例如，域614可以至少与数据类型相关联。每个域614均与唯一名称或标识符相关联，并且通常与描述相关联，诸如提供该域的语义含义的人类可读文本描述(或者可以与人类可读文本描述相关的标识符)。例如，一个域614可以是表示电话号码的整数值，另一个域可以是表示零件号的整数值，而又一个整数域可以表示社会保险号。因此，域614可以帮助提供跨模式600的通用且一致的使用(例如，语义含义)。也就是说，例如，每当使用表示社会保险号的域时，即使字段或数据元素针对不同的表格具有不同的标识符或其它特征，也可以将相应字段识别为具有该含义。

模式600可以包括一个或多个数据元素622。每个数据元素622通常与单个域614相关联。然而，多个数据元素622可以与特定域614相关联。虽然未示出，但是表格618的多个元素可以与相同的数据元素622相关联，或者可以与具有相同域614的不同数据元素相关联。此外，数据元素622可以用于允许为特定表格618定制域614。因此，数据元素622可以为表格618的元素提供附加语义信息。

表格618包括一个或多个字段616，这些字段的至少一部分映射到数据元素622。字段626可以映射到数据库层的模式，或者表格618可以以另一种方式映射到数据库层。在任何情况下，在一些实施例中，字段626以某种方式映射到数据库层。或者，数据库模式可以包括等同于模式600的元素的语义信息，包括域614。

在一些实施例中，一个或多个字段626没有映射到域614。例如，字段626可以与基本数据组件(例如，基本数据类型，诸如整数、字符串、布尔值、字符数组等)相关联，其中基本数据组件不包括语义信息。或者，数据库系统可以包括一个或多个表格618，该一个或多个表格618不包括与域614相关联的任何字段626。然而，所公开的技术可以包括模式600(其可以与数据库模式分开或者合并到数据库模式中)，该模式600包括具有与域614直接相关联或通过数据元素622相关联的至少一个字段626的多个表格618。

示例9——示例数据字典组件

模式信息(诸如与图6的模式600相关联的信息)可以存储在存储库(诸如数据字典)中。在至少一些情况下，数据字典独立于(但不映射到)底层关系数据库。这种独立性可以允许将相同的数据库模式600映射到不同的底层数据库(例如，使用来自不同供应商的软件或来自同一供应商的不同软件版本或产品的数据库)。数据字典可以被持久化，诸如维持在所存储的表格中，并且可以整体或部分地维持在存储器中。数据字典的内存版本可以称为字典缓冲器。

图7图示了具有数据字典704的数据环境700，该数据字典704可以例如通过映射来访问数据库层708。数据库层708可以包括模式712(例如，如PostgreSQL中的INFORMATION_SCHEMA)和数据716(诸如与表格718相关联的数据)。模式712包括各种技术数据项目/组件722，这些技术数据项目/组件可以与字段720相关联，诸如字段名称722a(其可以或可以不对应该字段的目的的易于人类理解的描述，或者以其他方式显式地描述该字段的值的语义含义)、字段数据类型722b(例如，整型、可变长字符串、字符串、布尔值)、长度722c(例如，字段中的值所允许的数字的大小、字符串的长度等)、小数位数722d(可选地，对于合适的数据类型，诸如对于长度为6的浮点数，指定这些值是否表示XX.XXXX或XXX.XXX)、位置722e(例如，表格中应该显示字段的位置，诸如第一个显示的字段、第二个显示的字段等)、可选地，默认值722f(例如，“NULL”、“0”或某个其它值)、指示该字段是否允许NULL值的NULL标志722g、指示该字段是否是表格的主关键字或是否在表格的主关键字中使用的主关键字值标志722h、以及外来关键字元素722i(可以指示字段720是否与另一个表格的主关键字相关联以及可选地由外来关键字元素引用的表格/字段的标识符)。特定模式712可以包括比图7所示的更多、更少或不同的技术数据项目722。

表格718与一个或多个值726相关联。值726通常与使用一个或多个技术数据元素722定义的字段720相关联。也就是说，每行728通常表示唯一的元组或记录，并且每列730通常与特定字段720的定义相关联。表格718通常定义为字段720的集合，并且赋予了唯一标识符。

数据字典704包括一个或多个数据包734、一个或多个域738、一个或多个数据元素742和一个或多个表格746，它们通常可以至少分别对应图6的相似命名的组件610、614、622、618。如在图6的论述中所述的，数据包734包括一个或多个(通常多个)域738。每个域738由多个域元素740定义。域元素740可以包括一个或多个名称740a。名称740a用于标识(在一些情况下唯一标识)特定域738。域738包括至少一个唯一名称740a，并且可以包括可能是或可能不是唯一的一个或多个名称。可能是或可能不是唯一的名称可以包括不同长度或不同详细程度的域738的名称或描述的版本。例如，名称740a可以包括可用作域738的标签的文本，并且可以包括短、中和长版本以及可指定为报头的文本。或者，名称740a可以包括主名称或标识符、以及为域738提供人类可理解语义的短描述或字段标签。

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

域元素740还可以包括至少与可包括在模式712中的信息类似的信息。例如，域元素740可以包括与相关数据类型相关联的数据类型740b、长度740c和小数位数740d，它们可以分别对应技术数据元素722b、722c、722d。域元素740可以包括转换信息740e。转换信息740e可以用于转换(或相互转换)为域738输入的值(可选地，包括通过数据元素742修改的值)。例如，转换信息740e可以指定具有XXXXXXXXX形式的数字应该转换成XXX-XX-XXXX，或者数字应该具有分隔各组数字的小数或逗号(例如，将1234567格式化为1,234,567.00)。在一些情况下，多个域738的字段转换信息可以存储在存储库(诸如字段目录)中。

域元素740可以包括一个或多个值限制740f。例如，值限制740f可以指定允许或不允许负值，或者域738可接受的值的特定范围或阈值。在一些情况下，当试图将值与不符合值限制740f的域738一起使用时，可以提供错误消息或类似指示。域元素740g可以指定允许使用域738的一个或多个数据包734。

域元素740h可以指定记录与域元素738相关联的创建或修改事件的元数据。例如，域元素740h可以记录最后修改域元素740h的用户或应用的身份、以及修改发生的时间。在一些情况下，域元素740h存储域738的创建和修改的更多历史，包括完整历史。

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

数据元素742可以包括数据元素字段744，这些数据元素字段中的至少一些可以至少大体上与域元素740类似。例如，数据元素字段744a可以对应名称域元素740a的至少一部分，诸如是(或包括)特定数据元素742的唯一标识符。相对于名称域元素740a描述的字段标签信息被示为分成短描述标签744b、中描述标签744c、长描述标签744d和报头描述744e。如针对名称域元素740a所描述的，标签和报头744b-744e可以用一种语言或多种语言来维持。

数据元素字段744f可以指定与数据元素742一起使用的域738，从而将域元素740的特征合并到数据元素中。数据元素字段744g可以表示数据元素742的默认值，并且可以至少类同于模式712的默认值722f。创建/修改的数据元素字段744h可以至少大体上与域元素740h类似。

表格746可以包括一个或多个表格元素748。表格元素748的至少一部分可以至少与域元素740类似，诸如表格元素748a至少大体上与域元素740a或数据元素字段744a类似。描述表格元素748b可以类同于结合域元素740a所描述的描述和报头标签、或标签和报头数据元素字段744b-744e。表格746可以与使用表格元素748c的类型相关联。示例表格类型包括透明表格、集群表格和池化表格，如在可从德国沃尔多夫的SAP SE获得数据库产品中使用的。

表格746可以包括一个或多个字段表格元素748d。字段表格元素748d可以定义特定数据库表格的特定字段。每个字段表格元素748d可以包括用于该字段的特定数据元素742的标识符750a。标识符750b-750d可以指定该字段是表格的主关键字(标识符750b)还是表格的主关键字的一部分，或者与另一个数据库表格的一个或多个字段有关系，诸如是外来关键字(标识符750c)或关联关系(标识符750d)。

创建/修改的表格元素748e可以至少大体上与域元素740h类似。

示例10——示例工件定义

图8图示了工件定义800的定义。具体地，工件定义800表示视图，诸如德国沃尔多夫的SAP SE的Core Data Services(核心数据服务)视图，并且以诸如CSN的格式来表达。工件定义800可以包括各种不同的组件，这些组件中的至少一些可以被认为是工件定义。也就是说，工件定义800可以是至少部分地基于多个子模型的模型。子模型可以指定整个工件定义800的特定方面。

工件定义800可以可选地包括一个或多个注解804。注解可以是可添加到工件定义中的元数据组件。例如，提供商可能提供一个基础模型，并且个体用户或客户可能希望添加特定于其操作环境和用例的元数据。因此，添加注解的能力可以通过允许定制元数据元素来增强可用性，而不会影响基础工件定义的其它用户。注解可以针对不同的软件层或框架来指定。

在所示的示例中，可以将注解804指示为使用特定句法元素的注解，诸如通过在注解前面加上“@”符号。在至少一些情况下，注解804还可以通过将其放在工件定义的适当部分中(诸如放在报头部分或为注解指定的另一部分中)来指示。在一些情况下，注解804可以引用其它工件定义，诸如数据源的工件定义，或者可以引用与工件定义相关联的数据源。在任一种情况下，这种关联关系804均可以在工件定义800与其它工件定义/数据源之间创建依赖关系。

工件定义800可以包括指令808，在这种情况下是SQL语句810，其定义了具有标识符812的核心工件定义/对象(其可以用于例如稍后访问或激活(如实例化)工件定义)。具体地，所示的指令808定义了视图。注解804进一步指定视图的属性，如将进一步描述的工件定义800的其它部分那样。

指令808可以指定一个或多个数据源816。数据源816可以定义工件定义800的至少一部分元数据将要应用的数据，并且还可以为工件定义800提供附加元数据。需要注意的是，工件定义800至少在某种意义上可以依赖于所引用的数据源816。例如，如果工件定义800依赖于数据源816的特定期望数据或元数据，则如果所引用的数据源不包括期望数据或元数据或者与如何在工件定义中使用数据源不一致，则工件定义可能是不可用的，具有性能问题或提供不正确的结果。如图所示，数据源816包括两个表格，即“vbak”和“vbkd”。这些表格通常会包括元数据特征，诸如一个或多个字段，其中每个字段与数据类型、主关键字的指定、以及可选的与其它数据库组件的关联关系(诸如与其它数据库表格的关联关系或外来关键字关系)相关联。

工件定义800可以可选地包括一个或多个关联关系820的规范。关联关系820可以定义与另一个实体的关系。在工件定义800的使用期间可以对关联关系820进行处理，诸如转换成诸如JOIN的SQL表达。与工件定义800中包括的其它条件或元素不同，关联关系可以定义至少在一些情况下是可选的关系，诸如根据如何访问工件定义而选择性地激活。例如，可以将关联关系820转换成使用在引用工件定义800的SELECT语句中提供的表格的JOIN条件。

工件定义800可以包括一个或多个组件822，该一个或多个组件822指定应该如何处理使用工件定义检索到的数据，包括生成与工件定义的其它元数据元素相关联的值。处理可以包括计算值，诸如使用工件定义800指定或引用的公式。具体地，处理组件822可以指定特定字段值应该被视为元素824，其中元素可以如示例8和9中所描述的。因此，工件定义800可以包括对如何定义元素的依赖性，并且如果元素定义与在工件定义800中如何使用该元素以及打算如何使用该元素不匹配，则工件定义800可能是不准确或不可用的。

工件定义800可以可选地包括附加组件(诸如一个或多个条件828)或其它操作(诸如聚合、联合等)，包括通常由数据库查询语言支持的操作。

示例11——示例工件定义，包括与其它工件定义的关系

图9图示了工件定义如何可以具有对其它工件定义的依赖性。具体地，图9示出了视图工件定义904，其可以是图8的工件定义800。图9还图示了访问控制对象的工件定义908(诸如DCLS或数据控制语言源)、元数据扩展对象的工件定义912(诸如DDLX或元数据扩展)和扩展元素对象的工件定义916(诸如DDLS或数据定义语言源)。

访问控制对象工件定义908可以用于限制对可使用视图工件定义904检索的数据的访问。例如，当视图工件定义904被激活时，视图工件定义904和访问控制对象工件定义908可以被一起处理，以便生成检索视图工件定义的数据的SQL命令，但是基于访问控制对象工件定义对这些SQL命令进行过滤或限制。因为访问控制对象工件定义908引用视图工件定义904，所以访问控制对象工件定义依赖于现有的视图，并且依赖于包含访问控制对象工件定义中指定的元素的视图。例如，访问控制对象工件定义引用视图“I_SampleSalesOrder”的“SalesOrderType”元素和具有其授权字段“AUART”的授权对象“V_VBAK_AAT”。因此，如果在视图工件定义904中不存在对应的元素，则第一元素会是未定义的或不可用的。

元数据扩展对象工件定义912(向视图工件定义904添加注解)对视图工件定义具有类似的依赖性，如扩展元素对象工件定义916(其向视图工件定义添加附加元素)那样。

示例12——工件定义的示例关系模型

图10图示了如何可以使工件定义彼此依赖，并且随着时间改变，这可以影响依赖性工件定义的使用或有效性。在时间t₀处，提供工件定义的数据定义语言版本。工件定义用于两个数据库对象，即View1的模型1010和View2的模型1012。View2的模型1012引用View1，因为该模型包含定义由View1的模型1010定义的数据的特定子集的SQL选择语句。因此，模型1010包括对模型1012的依赖性。具体地，模型1010依赖于View1存在，并且在View1中存在字段“KeyField”。

在时间t₁处，接收View2的第二版本的模型1016。与模型1012相比，模型1016在View2的定义中包括View1的另一个字段，即Field1。在一些情况下，模型1016可以作为完整的模型提供，而在其它情况下，仅发送与先前模型版本相比的变化。

在时间t₂处，第二系统上传删除View2的指示1022。需要注意的是，在这种情况下，因为View2依赖于View1，但是View1不依赖于View2，所以删除View2不会影响任何描述的工件定义。相反，如果已经在时间t₂处删除了View1，则可以确定删除View1会产生View2的问题。

图10图示了如以第一格式定义的工件定义，诸如定义视图的SQL语句。图11A和图11B图示了如何可以将图10所示的工件定义转换成不同的格式，数据库表格的集合中的这些记录用于存储工件定义的表示。具体地，图11A示出了表格1104，该表格1104包括与表格的记录相关联的对象类型的字段1106、保存对象名称的字段1108、保存与对象相关联的版本标识符的字段1110、提供与接收到相应工件定义的原始格式相关联的类型的字段1112(例如，纯文本、JSON、XML、CSN等)、保存(在与字段1112相关联的类型中的)原始源内容的列表的字段1114、以及包括接收对象时的时间戳(例如，参照图10，与时间t₀、t₁或t₂相关联的时间戳)的字段1116。表格1104可以可选地包括一个或多个附加字段1120。

可以看出，表格1104包括在t₀处接收到的View1的记录1122、在t₀处接收到的View2的工件定义的记录1124、以及在t₁处接收到的View2的工件定义的记录1126。需要注意的是，表格1104可以包括对象源版本的信息，因此类型、名称和版本信息(即字段1106、1108、1110)对于作为对象源(例如，数据定义语言源或DDLS)的对象可以是特定的。

表格1128可以包括用于数据定义语言对象版本的字段，这些字段可以包括用于DDLS名称的字段1130和用于DDLS版本标识符的字段1132，这些字段可以对应表格1104的字段1108、1110。表格1128还可以包括描述与相应工件定义相关联的实体(例如，工件定义)类型的字段1134。实体类型的示例可以是表格、视图、访问控制、注解扩展、元数据扩展等。

字段1136可以包括实体名称或标识符，该实体名称或标识符可以是在工件定义的声明中分配给工件定义的名称或标识符，诸如在图10所示的SQL语句中。例如，图10示出了定义VIEW1的工件定义1010，其然后提供字段1134中指示的类型和在为记录1138指示的字段1136中输入的名称。需要注意的是，字段1136可以是工件定义的名称的规范形式，并且在字段1140中可以包括在工件定义中提供的原始名称。同样地，字段1136的规范名称可以与其它格式(诸如字段1142中提供的格式)相关联，如图所示，该格式可以是工件定义的SQL查询中使用的名称，该名称可以对应在数据库层中(诸如在信息模式中)使用的工件定义的名称。表格1128可以包括一个或多个附加字段1144。

如图11A所示，在图10中的t₀和t₁处提供的工件定义的所有信息都可以根据单个字段或具有原始源内容的字段1114从表格1104、1128中检索。图11B图示了表格1150、1152、1154、1156，这些表格可以存储关于工件定义的附加信息，包括关于从其接收工件定义或从其接收更新(包括删除)的系统的附加信息。具体地，表格1150可以用于使工件定义与软件组件版本标识符相关联，而软件组件版本标识符可以用于描述从其接收工件定义的系统上的操作环境。表格1150包括用于与字段1164中列出(并且对应表格1104的字段1108)的工件定义对象名称相关联的软件组件版本ID的字段1160和字段1166的版本标识符(对应表格1104的字段1110)。可以在字段1162中指定对象的类型。

当工件定义发生改变时，与字段1166中的标识符相关联的版本可以链接到工件定义的先前版本，其可以存储在字段1168中。在工件定义删除的情况下，删除时间可以在字段1170中列出(其中没有值或NULL值可以指示已经删除了该对象)。在一些情况下，可以针对数据模型的所有版本填写删除字段1170。在其它情况下，仅针对在删除之前的工件定义的最后版本填入删除字段1170。

表格1152可以将字段1172中列出(并且对应于字段1160)的特定软件组件与字段1174中列出的特定系统软件版本相关联。反过来，表格1154可以使字段1176中的特定软件系统版本与字段1178中的系统标识符所指示的特定系统以及字段1180中指示何时安装、释放或激活系统的时间戳相关联。表格1156可以包括特定软件组件版本的字段1182(其对应于字段1160)、具有字段1184中提供的软件组件的标识符、字段1186中的释放标识符和字段1188中的支持数据包标识符。表格1150、1152、1154、1156中的每一个都可以可选地包括一个或多个附加字段1190。

示例13——示例元数据关系模型，包括查询语言操作

图12图示了参照两个视图工件定义1206、1208来定义工件定义1204(尤其是视图)而视图工件定义又可以依赖一个或多个附加数据模型的场景。工件定义1206依赖于表格的工件定义1210，而工件定义1208依赖于表格的工件定义1212并且与另一个视图的工件定义1214有关联关系，该另一个视图又引用表格的工件定义1216。这些依赖性可以如针对范围界定功能和遍历组件所描述的那样进行评估以用于标识一个或多个特定工件(包括响应于特定搜索/查询请求的工件)的数据库工件和相关联元数据。

视图工件定义1204、1206、1208、1214包括可以以可替换格式(诸如表格形式)存储的SQL选择语句，如图13所示。图12的视图工件定义1204、1206、1208、1214的选择语句可以包括可以以可替换表示存储的附加特征/操作，诸如工件定义1204中的join条件1220、工件定义1208与工件定义1214之间的关联关系1224以及工件定义1214中的where条件1228。

图13图示了可以以表格形式存储具有选择语句的工件定义的信息的表格1304。表格1304包括用于对象类型的字段1308，对于工件定义1204、1206、1208、1214，该字段是数据定义语言源对象。字段1310包括每个记录的名称或标识符，该名称或标识符可以是系统分配的名称或用于系统目的的名称，以便对于给定对象，诸如以唯一地标识每个对象。

需要注意的是，图12中的SQL语句不会分配字段1310中使用的名称。字段1312可以存储与每个记录相关联的对象的对象版本标识符值。在一些情况下，字段1312中存储的值对于给定对象可以是唯一的，并且可以在对象发生改变时递增。例如，记录1316示出为具有DDLS1对象的对象版本标识符56。如果DDLS1对象再次发生改变，则对象版本标识符可以递增到57。

表格1304可以包括存储实体名称的字段1320，该实体名称可以是图12所示的SQL语句中使用的实体名称。例如，工件定义1204定义视图View4，该视图是在字段1220中为记录1322提供的名称，对应于View4。在至少一些情况下，表格1304中的每个对象都与主数据源相关联。例如，SQL语句可以具有“SELECT FROM primaryDataSource”的形式，其中“primaryDataSource”的标识符存储在字段1324中。对于工件定义1204，View4主要是相对于View1定义的，因此将View1列在记录1322的字段1324中。字段1324的主数据源可以具有诸如表格或字段的类型，该类型在字段1326中提供。

如上所述，工件定义中使用的选择语句可以具有附加操作，这些附加操作可以记录在表格1304中。如果对象工件定义包括where条件，则该条件的标识符可以包括在字段1328中。工件定义1214包括where条件1228，因此该条件的标识符可以输入到记录1322的字段1328中。字段1328中的标识符可以标识特定的条件集合，其中附加信息可以包括在条件集合表格1332中，如将进一步描述的。同样地，如果对象工件定义包括join条件，则该条件的标识符可以包括在字段1336中。字段1334中的标识符可以标识表格1332中的条件集合。

表格1332允许进一步详述与表格1304中的选择语句相关联的条件细节。表格1332包括对象类型字段1338和对象名称字段1340，其可以对应表格1304的字段1308、1310。需要注意的是，工件定义1204的join条件由记录1344-1348表示，工件定义1214的“where”条件由记录1350表示，而工件定义1208的关联关系的“on”条件由记录1352表示。

表格1332包括用于在字段1340中列出的对象的版本标识符的字段1356，并且可以对应于字段1312。字段1358包括条件集合标识符，并且可以对应字段1328、1336。组ID字段1360和分组序号字段1362可以用于保留最初表达(例如，在SQL中)的条件的语义。例如，组ID字段1360可以用于指示与字段1364中指示的数据源相关联的条件的一部分。因此，因为记录1344与字段1364中的VIEW1的值相关联，所以该记录1344与字段1360中的组标识符1相关联；而因为记录1346、1348与字段1364的VIEW2的值相关联，所以这两个记录1346、1348均与组标识符2相关联。分组序号字段1362的值可以进一步标识记录1346、1348的特定语义，诸如指示记录1346处于原始选择语句中的记录1348之前。分组运算符字段1366可以提供使记录与字段1360的特定组标识符值相关联的运算符。

对于字段1368中列出的给定运算符或关系，字段1370、1364、1372、1374可以分别列出左组标识符、左数据源名称、左字段名称和左值。同样地，字段1376、1378、1380、1382可以分别提供右组标识符、右组源名称、右字段名称和右值。“左”和“右”指的是值相对于字段1368的运算符的位置。

因此，可以看出表格1332的记录可以用于以图12所示的格式重建工件定义的操作或条件。虽然表格1332可能没有明确列出操作或条件的类型，但是该信息可以从表格1304的字段1328、1336中收集(或者从表格1384中收集，如将进一步描述的)。

关联关系定义表格1384可以定义工件定义(诸如以图12所示的格式提供的模型)中包括的关联关系，并且可以包括对象类型字段1386、对象名称字段1387、对象版本标识符字段1388和实体名称字段1389，这些字段可以如针对表格1304的字段1308、1310、1312、1320所描述的。字段1390可以存储字段1392中列出的对象标识符(例如，对象工件定义的标识符)的标准化版本，其可以是如原始工件定义中的关联关系定义中包括的对象名称，诸如关联关系1224。字段1394可以提供相关联的实体的名称，并且可以在字段1395中提供与该实体(例如，表格、视图)相关联的类型。关联关系可以分别与最小基数和最大基数(即字段1396和1397)相关联。字段1398可以包括条件集合标识符，该条件集合标识符可以对应表格1332的字段1358。

以图12的示例关联关系1224为例，记录1352阐述了针对关联关系(即“on”条件)定义的条件。例如，由所定义的视图1208引用的表格的FIELD3中的值等于在工件定义1214中定义的相关联的视图的FIELD3，而该FIELD3又与工件定义1216中定义的表格相关联。

表格1304、1332、1384可以可选地包括一个或多个附加字段1399。

示例14——示例关系工件定义，包括字段定义和关系

在一些情况下，元数据对象(诸如视图)可以包括计算得到的或至少部分地基于一个或多个其它工件定义的元素(例如，字段)的字段。这些计算可以在工件定义中明确指定，或者可以在模型定义中引用，诸如通过调用内置函数或引用另一个工件定义、库、API调用等中的函数。

图14图示了参照工件定义1408定义视图的工件定义1404，该工件定义1408又引用由工件定义1412定义的表格。工件定义1404包括从工件定义1408中的字段导出的四个字段1420、1422、1424、1426。工件定义1408包括从由工件定义1412定义的表格中选择出的三个字段1430、1432、1434。由工件定义1412定义的表格包括在该工件定义中声明/定义的三个字段1440、1442、1444。

图15图示了可用于概括工件定义1404、1408、1412中使用的字段的表格1500。表格1500包括字段1502，该字段指示与该字段相关联的对象的类型，诸如与表格或数据定义语言源对象(例如，视图)相关联。字段1504中提供了对象的名称，该名称可以是由与工件定义一起使用的系统(例如由元数据存储库)使用或提供的对象名称。

可在字段1506中提供对象的版本标识符，如针对其它工件定义表示所论述的，该版本标识符可以是每个对象的唯一编号并且可以随着对象的改变而递增。实体名称字段1508可以包括与工件定义相关联的名称，诸如在工件定义的声明中定义的名称。

每个元数据对象可以与一个或多个字段相关联，并且字段1510可以存储字段1512中提供的字段名称的标准化表示。例如，字段1510可以存储从字段1512中列出的字段名称中移除格式化或大写(例如，小写字母)的名称。如上所述，工件定义可以合并来自其它工件定义的字段。字段的直接源可以具有在字段1514中提供的名称并且可以具有诸如表格或视图的类型，并且该类型可以在字段1516中提供。直接源中的字段的名称可以不同于它所并入的工件定义中的字段的名称，因此字段1518可以包括源工件定义中的字段的名称。

计算字段可以与表达相关联，并且表达的标识符可以在字段1520中提供，该字段1520可以用于访问表达，诸如作为表示存储在一个或多个其它表格中的表达。字段1522可以指示该字段是否是关键字字段(例如，在主关键字中使用的字段)。字段可以与数据类型相关联，数据类型可以在字段1526中列出，并且数据类型可以与诸如在数据元素中的附加语义或技术信息相关联，其标识符可以在字段1524中提供。通常，与字段1526(进而与字段1524)相关联的数据类型可以具有一定长度，诸如允许的数字或字符的数量，并且该信息可以包括在字段1528中。

允许使用小数的数字字段可以通过字段1530与值(例如，允许的小数位数)相关联。字段1532、1534、1536、1538可以用于定义表达的定义出现在源工件定义中的何处，诸如分别为开始行、开始列、结束行和结束列。表格1500可以可选地包括一个或多个附加字段1540。

作为如何可以使用表格1504来表示来自图14的工件定义的字段的一个示例，考虑与工件定义1408相关联的记录1550。工件定义1408用于视图VIEW1，并且引用(由工件定义1412定义的)Table1的Field1，该Field1是关键字段。记录1552对应于工件定义1412中的Table1的Field1的定义，其中Field1被定义为具有数据元素类型DE1的关键字段，并且可以不是空值。记录1550包括字段1508中的对象名称VIEW1、字段1510中的对象中的字段名称FIELD1、字段1512中的对象中的字段原始名称Field1、字段1514中的从其引用该字段的实体名称TABLE1、字段1516中被引用实体(针对表格)的类型TABL、以及字段1518中被引用的实体中的字段名称FIELD1。记录1550的字段1522设置为TRUE，指示与记录1550相关联的字段是关键字段，而字段1524指定该字段具有数据元素类型DE1，字段1526和1528指示长度为30的字符数据类型。

示例15——示例关系工件定义，包括注解

如在示例10中所描述的，元数据对象(诸如视图定义)可以包括注解。图16图示了可彼此依赖的元数据对象如何可以具有可以另一种格式(诸如图17的表格1700中所示的格式)存储的注解。

图16包括视图View2的工件定义1604，该视图View2是相对于工件定义1608中定义的另一个视图View1来定义的。元数据扩展DDLX2的工件定义1612为工件定义1604提供附加元数据元素。工件定义1608包括两个注解1620、1622，这两个注解可以合并到工件定义1604中。然而，为View1提供标签的注解1620由在View2的工件定义1604中定义的注解1626取代。在一些情况下，如果注解在引用工件定义中具有与在被引用工件定义中相同的名称或类型(例如，如图所示的“@EndUserText.label”)，则该注解可以被取代。

工件定义1630图示了工件定义1604的“有效”表示，包括通过依赖关系合并到工件定义1604中的注解。可以看出，有效工件定义1630包括注解1626，但不包括注解1620。由于工件定义1608的注解1622没有被取代，所以该注解包括在有效工件定义1630中，来自工件定义1612的注解1634也是如此。

表格1700可以概括图16的工件定义的注解。表格1700包括与由表示注解的记录来注解的工件定义相关联的对象类型的字段1704。如图所示，字段1704包括视图的“DDLS”或元数据扩展对象的“DDLX”的值。字段1708可以提供对象的名称，诸如系统名称，而字段1712可以提供由对象的声明定义的对象名称。字段1710可以提供对象的版本标识符。字段1714可以提供与注解相关联的子实体的名称，该子实体可以是例如注解所应用的特定视图字段。

字段1716可以提供注解内部标识符，该注解内部标识符可以用于区分工件定义的多个注解，并且可以用于在工件定义中存在多个注解时提供注解的排序。字段1716的值还可以用于使基础或父类注解或注解类型与子注解相关联，如将进一步描述的。注解名称可以包括在字段1718中，该字段1718可以是注解的类型(或类别)或子类型(或类别方法或类别数据成员)。字段1720可以提供父类注解的标识符。例如，记录1740将注解内部标识符“1”分配给注解“ENDUSERTEXT”。“ENDUSERTEXT”可以是基础注解类型，而记录1742可以包括注解的子类型“ENDUSERTEXT.LABEL”，其中字段1720中的值“1”指示记录1720引用了记录1740的注解。

在工件定义的声明中定义的注解的值可以在字段1722中提供。字段1722中的值表示分配给注解的明确定义的值。分配给注解的有效值可以在字段1724中指示。例如，注解@Search.defaultSearchElement的有效值为“TRUE”，即使该值没有在工件定义的声明中明确获得，而是从注解默认逻辑中自动导出。此外，在所示的示例中，语言相关文本的有效值可以是相对于表格1750中的标识符来指定的，其中字段1724中的值对应于文本标识符字段1754中的值。表格1750也示为包括提供与文本相关联的语言的代码的字段1756，并且待显示的实际文本可以在字段1758中提供。

表格1700可以存储合并到特定工件定义中的所有注解的信息。然而，如上所述，一些注解可能不是“活动的”，例如，因为本地声明的注解可能会覆盖导入或引用的注解。同样地，在一些情况下，来自多个被引用的来源(例如，工件定义)的注解可能重叠或冲突。在这种情况下，只有这些注解中的一个注解(通常是子集)可以指定为活动的。单独维持可以如图18的表格1800中所示存储的活动注解的存储库可能是有益的。

表格1800可以包括对象类型的字段1804、对象名称的字段1808、对象版本标识符的字段1810、实体名称的字段1812、子实体名称的字段1814、注解内部标识符的字段1816、注解名称的字段1818、父类注解标识符的字段1820、注解值的字段1822、以及有效注解值的字段1824，这些字段可以是至少一般地针对表格1700的相似命名和编号的字段来描述的。

表格1800可以包括附加字段，诸如活动注解版本标识符字段1830。需要注意的是，字段1830中的活动注解版本标识符可以具有不同于字段1810中的对象版本标识符的值。例如，新元数据扩展能够改变被注解的现有基础(例如，视图)模型版本的活动注解，因此单独跟踪版本可能是有用的。

因为注解可以从其它来源导入，所以相对于源对象(例如，工件定义)跟踪关于这些注解的信息可能是有用的。因此，字段1832可以存储与注解相关联的对象类型(本地对象类型或者从其导入注解的对象的对象类型)，而字段1834可以存储起源对象的名称。字段1836可以存储起源对象的版本标识符。

示例16——元数据访问的示例API

用户或应用可以访问存储的工件定义，诸如以示例12-15中描述的一种或多种表格格式维持的元数据。在一些情况下，可以经由API访问信息，诸如使用REST服务的基于web的API。在一个特定示例中，API可以使用OData协议。

图19图示了持久性模型的摘录1904(例如，示例12-15的表格中的全部或一部分)和OData服务的摘录1950，这些摘录可以用于访问持久性中维持的数据或者从持久性中的数据确定或计算出的数据。持久性摘录1904可以包括用于DDLS版本信息1920、对象版本源信息1922、文本信息1924(例如，原始元数据定义信息的文本)、与对象版本相关联的选择语句信息1926、与对象版本相关联的关联关系信息1928、与对象版本相关联的字段信息1930、与对象版本相关联的条件信息1932(例如，“where”或“on”条件，诸如相对于表格1332描述的)、与对象版本相关联的本地注解信息1934以及与对象版本相关联的活动注解信息1936的表格或其部分(例如，一个或多个字段)。

用于访问元数据服务的服务的API或其它功能可以提供查询和维持工件定义的表示等功能，诸如创建、更新或删除工件定义表示(或其特定版本)。API可以允许其它选项，诸如聚合来自持久工件定义表示的数据或搜索元数据存储库，包括使用模糊搜索技术。例如，用户(或应用)可能请求关于在存储库中注册了多少对象、多少版本与特定对象相关联或一个对象可以具有的字段的数量(诸如最大字段数)的信息。

图20图示了具有对象版本源信息的示例表格2004和具有DDLS版本信息的示例表格2008。表格2004可以具有多个字段，包括与记录相关联的对象类型的字段2012、与记录相关联的对象名称的字段2014和与记录相关联的对象版本标识符的字段2016。表格2008可以具有用于DDLS名称的字段2020、DDLS版本字段2022、实体名称(诸如CDS实体名称)字段2024和原始实体名称(诸如原始CDS实体名称)字段2026。

以表格2004和2008的元数据表示为例并使用摘录1950，可以通过OData读取请求将摘录的导航属性从对象版本源表格2004的记录遍历到DDLS版本表格2008，如：

这检索了具有DDLS对象名称(例如，字段2014)为I_CUSTOMER的所有五个记录。需要注意的是，用户可以检索和访问元数据信息，而无需知道工件定义或其任何组成元素的确切名称。

API或其它元数据服务访问功能可以支持其它服务，包括基于比仅检索和更新工件定义的粒度更大的动作的服务。这些服务可以包括上传对象源信息、比较工件定义(及其部分)，包括比较不同组件或系统版本之间的工件定义。可以提供对在何处使用各种工件定义或元素的分析，包括标识工件定义/工件定义组件之间的依赖性。与每次通过应用多个低级函数来实现功能相比，提供这样的服务可能是更有效的并且更不容易出错。

作为一个示例，对于上传工件定义的请求，用户或应用可以请求上传对象动作，而不是从对象版本表格开始将每个单独表格的对象源信息转换成存储更详细信息的表格，该动作可以提供定义对象的原始字符串(例如，原始SQL语句)以及可选的附加信息，诸如原始源字符串的类型(例如，SQL、XML、纯文本)、对象的名称、对象类型(例如，视图、表格)、其它信息及其组合。输入可以包括：

ObjectType

ObjectName

SerializedObjectSourceType

SerializedObjectSourceContent

ObjectMaintenanceLanguage

ObjectLastChangedDateTime

SoftwareComponentId

SoftwareComponentReleaseId

SoftwareComponentReleaseId

可以查询元数据存储库以确定是否需要创建工件定义的新版本；如果是，则可以将上传的模型转换成元数据服务所使用的持久性格式。在至少一些情况下，可以确定任何工件定义是否依赖于更新的模型；如果是，则可以更新这些依赖性模型以提供新的模型版本。

对于比较两个工件定义(包括工件定义的两个版本)的函数，可以提供关于对象之间的差异、如何在软件组件的不同版本之间区分工件定义或如何在系统的不同版本之间区分工件定义的信息。用于比较工件定义的两个版本的示例输入可以包括：

ObjectType

ObjectName

ObjectVersion1Id

ObjectVersion2Id

ChangeTypes[例如，将类型更改为查询，诸如全选、插入、更新、删除、未更改]

ComparisionScope[例如，工件定义的所有元素或仅指定的元素或元素集]

比较可以返回包括以下的信息：

ObjectVersion

ChangeType

SubObjectType[例如，字段、关联关系、参数]

SubObjectName

PropertyType[例如，活动注解、关键字、数据类型、名称]

PropertyName

PropertyValue

以下可以表示针对工件定义中的更改的请求中的信息：

Input:

ChangeTypes＝INSERT

ComparisonScope＝ALL

该响应可以包括：

Output:

ObjectVersion＝2

ChangeType＝INSERT

SubObjectType＝FIELD

SubObjectName＝NewField

因此，比较请求表明了在工件定义的对象版本2中引入了一个新字段NewField。

用于访问元数据存储库的元数据展示服务或其它功能可以返回使用特定元数据元素的对象列表。例如，字段可以是最初为特定表格定义的，但是随后可以被多个视图引用。该功能的输入可以包括：

Input:

ObjectType:Identification

ObjectName:Identification

ObjectVersionId:Identification

UseageTypes[例如，ALL、关联关系、目标、数据源、注解]

MaximumNumberOfIndirections

该请求的输出可以包括：

UsingObjectType

UsingObjectName

UsingObjectVersionId

UsageType

DirectlyUsedObjectType

DirectlyUsedObjectName

DirectlyUsedObjectName

DirectlyUsedObjectVersionId

NumberOfIndirections

图21提供了“where used”请求的示例。相关工件定义组2104包括View3的工件定义2108，工件定义2108引用View2的工件定义2110，工件定义2110引用View1的工件定义2112，工件定义2112又引用Table1的工件定义2114。假设视图2108、2110、2112中的每一个都引用Table1的字段，并且这些视图都通过它们所引用的视图来引用该字段，如图所示，则请求可以是：

Input:

ObjectName:TABLE1

UseageTypes:ALL

MaximumNumberOfIndirections:5

响应于该请求，可以以所示的表格形式或以另一种形式提供表格2130所示的信息。

对于依赖性检查，输入(例如，函数的自变量)可以包括：

ObjectType

ObjectName

ObjectSourceType

ObjectSourceContent

SoftwareComponentVersions

NewSoftwareComponentVersions

对该请求的响应(例如，由函数返回的值，诸如在结构(例如，C++struct)类别实例或另一种复杂或抽象的数据类型中)可以包括：

MessageType[例如，INFO,WARNING,ERROR]

MessageText

EntityReference[例如，指向工件定义的附加细节的链接，以便可以标识关于依赖性对象的附加信息]

作为一个特定示例，考虑向由用户模型展示的字段ViewField添加新的注解NewAnnotation。依赖性检查的输出可以包括：

MessageType:INFO

MessageText:A new annotation NewAnnotation was added to the fieldViewField

EntityReference＝…/sap/opu/odata/sap/CdsMetadataService/…NewAnnotation…

处理对元数据的访问的服务可以促使或帮助向终端用户显示元数据信息，诸如在用户界面屏幕上显示。该服务可以利用可定义用户界面布局的附加信息来扩充模型元数据，并且可以包括或定义允许用户与数据交互的附加服务。例如，可以提供经由值帮助来帮助用户提供过滤标准的注解，如图22的示例代码所示。

示例17——计算系统

图23描绘了可实施所描述的创新的合适的计算系统2300的一般化示例。计算系统2300不旨在对本公开的使用范围或功能提供任何限制，因为这些创新可以在各种各样的通用或专用计算系统中实施。

参照图23，计算系统2300包括一个或多个处理单元2310、2315和存储器2320、2325。在图23中，该基本配置2330包括在虚线内。处理单元2310、2315执行诸如用于实施图1的环境100的组件、图2的环境200的组件、或图3和图4的方法300、400的计算机可执行指令，包括如示例1-16中所述的。处理单元可以是通用中央处理单元(CPU)、专用集成电路(ASIC)中的处理器、或任何其它类型的处理器。在多处理系统中，多个处理单元执行计算机可执行指令以提高处理能力。例如，图23示出了中央处理单元2310以及图形处理单元或协同处理单元2315。有形存储器2320、2325可以是可由处理单元2310、2315访问的易失性存储器(例如，寄存器、高速缓存、RAM)、非易失性存储器(例如，ROM、EEPROM、闪存等)或两者的某种组合。存储器2320、2325以适合由处理单元2310、2315执行的计算机可执行指令的形式存储实施本文描述的一个或多个创新的软件2380。

计算系统2300可以具有附加特征。例如，计算系统2300包括存储装置2340、一个或多个输入设备2350、一个或多个输出设备2360和一个或多个通信连接2370。诸如总线、控制器或网络的互连机制(未示出)将计算系统2300的组件互相连接。通常，操作系统软件(未示出)为在计算系统2300中执行的其它软件提供操作环境，并且协调计算系统2300的组件的活动。

有形存储装置2340可以是可移除或不可移除的，并且包括磁盘、磁带或盒式磁带、CD-ROM、DVD、或可以用于以非暂时性方式存储信息并且可以在计算系统2300内访问的任何其它介质。存储装置2340存储用于实施本文描述的一个或多个创新的软件2380的指令。

输入设备2350可以是诸如键盘、鼠标、笔或轨迹球的触摸输入设备、语音输入设备、扫描设备、或向计算系统2300提供输入的另一种设备。输出设备2360可以是显示器、打印机、扬声器、CD刻录机、或从计算系统2300提供输出的另一种设备。

通信连接2370通过通信介质实现与另一个计算实体的通信。通信介质传送信息，诸如计算机可执行指令、音频或视频输入或输出、或调制数据信号中的其它数据。调制数据信号是其一个或多个特性以编码信号中的信息的方式进行设置或更改后的信号。作为示例而非限制，通信介质可以使用电学、光学、RF或其它载体。

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

术语“系统”和“设备”在本文中可以互换使用。除非上下文另有明确说明，否则这两个术语都不意味着对计算系统或计算设备的类型有任何限制。一般而言，计算系统或计算设备可以是本地的或分布式的，并且可以包括专用硬件和/或通用硬件与实现本文描述的功能的软件的任何组合。

在本文描述的各示例中，可以将模块(例如，组件或引擎)“编码”为执行某些操作或提供某些功能，表明可以执行用于该模块的计算机执行指令以执行这些操作或使这些操作被执行或以其他方式提供这些功能。虽然相对于软件组件、模块或引擎描述的功能可以作为分立软件单元(例如，程序、函数、类别方法)来实现，但是不需要作为分立单元来实现。也就是说，该功能可以合并到更大或更通用的程序中，诸如更大或更通用程序中的一行或多行代码。

为了表述的目的，详细描述使用了如“确定”和“使用”的术语来描述计算系统中的计算机操作。这些术语是对计算机执行的操作的高级抽象，并且不应该与人类执行的动作混淆。与这些术语相对应的实际计算机操作根据实施方式而变化。

示例18——云计算环境

图24描绘了可以实施所描述的技术的示例云计算环境2400。云计算环境2400包括云计算服务2410。云计算服务2410可以包括各种类型的云计算资源，诸如计算机服务器、数据存储库、组网资源等。云计算服务2410可以是位于中心的(例如，由业务或组织的数据中心提供)或分布式的(例如，由位于不同位置(诸如不同的数据中心)和/或位于不同的城市或国家的各种计算资源提供)。

云计算服务2410由各种类型的计算设备(例如，客户端计算设备，诸如计算设备2420、2422和2424)利用。例如，计算设备(例如，2420、2422和2424)可以是计算机(例如，桌上型或膝上型计算机)、移动设备(例如，平板计算机或智能电话)、或其它类型的计算设备。例如，计算设备(例如，2420、2422和2424)可以利用云计算服务2410来执行计算运算符(例如，数据处理、计算存储等)。

示例19——实施

虽然为了方便呈现，以特定的顺序描述了所公开的一些方法的操作，但是应该理解的是，这种描述方式包括重新排列，除非下面阐述的特定语言要求了特定排序。例如，顺序描述的操作在一些情况下可以被重新排列或同时执行。此外，为了简单起见，附图可能没有示出所公开的方法可以与其它方法结合使用的各种方式。

任何所公开的方法可以被实施为存储在一个或多个计算机可读存储介质(诸如有形的非暂时性计算机可读存储介质)上并在计算设备(例如，任何可用的计算设备，包括智能电话或包括计算硬件的其它移动设备)上执行的计算机可执行指令或计算机程序产品。有形的计算机可读存储介质是可以在计算环境内访问的任何可用的有形介质，例如，一个或多个光学介质盘(诸如DVD或CD)、易失性存储器组件(诸如DRAM或SRAM)或非易失性存储器组件(诸如闪存或硬盘驱动)。举例来说，参照图23，计算机可读存储介质包括存储器2320和2325、以及存储装置2340。术语计算机可读存储介质不包括信号和载波。此外，术语计算机可读存储介质不包括通信连接(例如，2370)。

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

为了清楚起见，仅描述了基于软件的实施方式的某些选定方面。省略了本领域公知的其它细节。例如，应该理解的是，所公开的技术不限于任何特定的计算机语言或程序。例如，所公开的技术可以由用C、C++、C#、Java、Perl、JavaScript、Python、Ruby、ABAP、SQL、XCode、GO、Adobe Flash或任何其它合适的编程语言、或者在一些示例中用标记语言(诸如html或XML)或合适的编程语言和标记语言的组合编写的软件来实现。同样，所公开的技术不限于任何特定的计算机或硬件类型。合适的计算机和硬件的某些细节是公知的，不需要在本公开中详细阐述。

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

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

来自任何示例的技术也可以与任何一个或多个其它示例中描述的技术相结合。鉴于所公开的技术的原理可以应用于许多可能的实施例，应当认识到，所示实施例是所公开的技术的示例，而不应该被视为限制所公开的技术的范围。相反，所公开的技术的范围包括由以下权利要求的范围和精神所覆盖的内容。

Claims (20)

1.一种计算系统，包括：

至少一个硬件处理器；

至少一个存储器，所述至少一个存储器与所述至少一个硬件处理器耦接；以及

一个或多个计算机可读存储介质，所述一个或多个计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令在被执行时使所述计算系统执行操作，所述操作包括：

接收第一数据工件，所述第一数据工件包括多个基础元素和包括至少一个第一扩展元素的扩展；

确定与所述第一数据工件相关的至少一个第二数据工件；

分析所述至少一个第一扩展元素以供传播到所述至少一个第二数据工件；

确定应该将所述至少一个第一扩展元素传播到所述至少一个第二数据工件；以及

将所述至少一个第一扩展元素传播到所述至少一个第二数据工件。

2.根据权利要求1所述的计算系统，其中所述分析所述至少一个第一扩展元素包括确定所述至少一个第一扩展元素的类型，并且所述确定应该将所述至少一个第一扩展元素传播到所述至少一个第二数据工件包括确定所述类型是用于指示传播的类型。

3.根据权利要求1所述的计算系统，其中所述分析所述至少一个第一扩展元素包括分析所述至少一个第二数据工件如何与所述第一数据工件相关。

4.根据权利要求3所述的计算系统，其中分析所述至少一个第二数据工件如何与所述第一数据工件相关包括确定由所述至少一个第二数据工件使用的所述第一数据工件的元素的数量，其中，如果元素的数量满足阈值，则将所述至少一个第一扩展元素传播到所述至少一个第二数据工件。

5.根据权利要求4所述的计算系统，其中所述阈值包括两个元素。

6.根据权利要求3所述的计算系统，其中分析所述至少一个第二数据工件如何与所述第一数据工件相关包括确定所述至少一个第二数据工件是否使用所述第一数据工件的、非关键字段的元素。

7.根据权利要求1所述的计算系统，所述操作还包括：

分析所述第一数据工件的至少一个第二扩展元素以供传播到所述至少一个第二数据工件；

确定不应该将所述至少一个第二扩展元素传播到所述至少一个第二数据工件；以及

不将所述至少一个第二扩展元素传播到所述至少一个第二数据工件。

8.根据权利要求7所述的计算系统，其中确定不应该将所述至少一个第二扩展元素传播到所述至少一个第二数据工件包括确定所述至少一个第二扩展元素是指定用于非传播的类型。

9.根据权利要求7所述的计算系统，其中确定不应该将所述至少一个第二扩展元素传播到所述至少一个第二数据工件包括确定所述至少一个第二扩展元素与定义数据选择的操作一起使用。

10.根据权利要求7所述的计算系统，其中确定不应该将所述至少一个第二扩展元素传播到所述至少一个第二数据工件包括确定所述至少一个第二扩展元素与定义数据分组的操作一起使用。

11.根据权利要求7所述的计算系统，其中确定不应该将所述至少一个第二扩展元素传播到所述至少一个第二数据工件包括确定所述至少一个第二扩展元素与定义呈现或提供数据的顺序的操作一起使用。

12.根据权利要求7所述的计算系统，其中确定不应该将所述至少一个第二扩展元素传播到所述至少一个第二数据工件包括确定所述至少一个第二扩展元素用在公式中。

13.根据权利要求1所述的计算系统，所述操作还包括：

确定所述至少一个第一扩展元素具有与已经在所述至少一个第二数据工件中使用的标识符相同的标识符；

其中将所述至少一个第一扩展元素传播到所述至少一个第二数据工件包括在所述至少一个第二数据工件中使用时对所述至少一个第一扩展元素进行重命名。

14.根据权利要求1所述的计算系统，所述操作还包括：

分析所述第一数据工件是用户定义的工件还是提供商定义的工件；以及

确定所述第一数据工件是提供商定义的工件，其中所述传播是至少部分地基于确定所述第一数据工件是提供商定义的工件来执行的。

15.根据权利要求1所述的计算系统，所述操作还包括：

确定与所述第一数据工件相关的至少一个第三数据工件；

对所述至少一个第三数据工件执行所述接收、分析和确定。

16.根据权利要求1所述的计算系统，所述操作还包括：

确定与所述第一数据工件相关的至少一个第三数据工件；

确定用户有权访问所述至少一个第三数据工件；以及

至少部分地基于确定用户有权访问所述至少一个第三数据工件，不对所述至少一个第三数据工件执行所述接收、分析和确定。

17.根据权利要求1所述的计算系统，所述操作还包括：

确定与所述第一数据工件相关的至少一个第三数据工件；

确定用户无权访问所述至少一个第三数据工件；以及

至少部分地基于确定用户无权访问所述至少一个第三数据工件，对所述至少一个第三数据工件执行所述接收、分析和确定。

18.根据权利要求1所述的计算系统，所述操作还包括：

在指示上显示推荐将所述至少一个第一扩展元素传播到所述至少一个第二数据工件；

接收指示选择所述至少一个第一扩展元素以用于传播的用户输入，其中所述传播是响应于接收到用户输入来执行的。

19.一种方法，所述方法在计算系统中实施，所述计算系统包括至少一个存储器和与所述至少一个存储器耦接的至少一个硬件处理器，所述方法包括：

接收第一数据工件，所述第一数据工件包括多个基础元素和包括至少一个第一扩展元素的扩展；

确定与所述第一数据工件相关的至少一个第二数据工件；

分析所述至少一个第一扩展元素以供传播到所述至少一个第二数据工件；

确定应该将所述至少一个第一扩展元素传播到所述至少一个第二数据工件；以及

将所述至少一个第一扩展元素传播到所述至少一个第二数据工件。

20.一种或多种计算机可读存储介质，包括：

在由计算系统执行时使所述计算系统接收第一数据工件的计算机可执行指令，所述计算系统包括至少一个存储器和与所述至少一个存储器耦接的至少一个硬件处理器，所述第一数据工件包括多个基础元素和包括至少一个第一扩展元素的扩展；

在由所述计算系统执行时使所述计算系统确定与所述第一数据工件相关的至少一个第二数据工件的计算机可执行指令；

在由所述计算系统执行时使所述计算系统分析所述至少一个第一扩展元素以供传播到所述至少一个第二数据工件的计算机可执行指令；

在由所述计算系统执行时使所述计算系统确定应该将所述至少一个第一扩展元素传播到所述至少一个第二数据工件的计算机可执行指令；以及

在由所述计算系统执行时使所述计算系统将所述至少一个第一扩展元素传播到所述至少一个第二数据工件的计算机可执行指令。