提供对应用程序内容多个实例的访问的合并空间

技术领域

本公开总体上涉及管理包括多个景观元素的景观，例如软件应用程序或可与之一起使用的内容。具体实施例涉及对景观元素进行分组或合并。

背景技术

软件使用场景越来越复杂。例如，使用该软件的企业可以运行软件应用程序的多个实例，而不是运行软件应用程序的单个实例。以在美国和欧盟同时经营的企业为例。出于各种原因(例如不同的法律约束)，企业可以使用一个软件实例来处理美国的数据或运营，使用另一个软件实例来处理欧盟的数据或运营，而不是运行单个软件实例来处理这两个区域的数据。

软件使用场景变得越来越复杂的另一种原因在于用户越来越普遍地希望合并来自多个软件应用程序的数据。例如，公司可以使用一个软件应用程序来管理员工信息，使用另一个软件应用程序来管理财务运营。出于各种原因，用户可能希望同时利用这两个应用程序中的数据。

当用户可以使用多个软件应用程序时，还可能存在应用程序功能或数据可能因用户可用的其他软件应用程序而异的情况。也就是说，如果只能假定应用程序A可用，则应用程序A的软件功能可能会受到限制。但是，如果应用程序B也可用，则可以为应用程序A提供附加功能。由于各种原因，将该等“跨应用程序内容”或简称为“交叉内容”包括在应用程序A中可能是不期望的，原因包括对于无法使用应用程序B的用户，这可能会增加应用程序A的大小和复杂性。

实施涉及多个软件应用程序或单个软件应用程序的多个实例的软件使用方案可能很复杂。因此，存在改进的空间。

发明内容

提供本发明内容部分用于以简化的形式介绍一系列概念，这些概念将在下文的具体实施方式中进一步描述。本发明内容部分无意确定要求保护的主题的关键特征或基本特征，也不意图用于限制要求保护的主题的范围。

提供了用于对应用程序进行分组的技术和解决方案，包括应用程序内容或计算机实施的过程可以使用的其他内容。特别是，为此目的提供了一个合并空间作为轻量级机制。接收多个景观元素的标识符，其中景观元素可以是应用程序、应用程序内容或其他内容。给定的景观元素具有类型，并且具有一个或多个工件。为具有第一类型的至少第一景观元素和第二景观元素生成合并空间。在合并空间中生成合并工件，其中所述合并工件引用第一景观元素和第二景观元素中第一工件的相应第一实例和第二实例。

在一个方面中，本公开提供用于创建合并空间的技术，其中所述合并空间用于提供对与软件应用程序或软件内容的多个实例相关联的数据的合并访问。接收多个景观元素的标识符，例如软件应用程序的实例或软件内容。多个景观元素中的给定景观元素包括一个或多个工件，例如表格或视图，并且具有类型(例如，该类型可以标识特定应用程序或特定软件内容集)。为具有第一类型的多个景观元素中的至少第一景观元素以及具有第一类型的多个景观元素中的至少第二景观元素生成合并空间。在合并空间中生成第一合并工件。第一合并工件引用至少第一个景观元素中第一工件的第一实例以及至少第二景观元素中的第一工件的第二实例。

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

附图说明

图1和图2是方框图，其中示出如何对应用程序或内容进行分组，包括出于提供交叉内容的目的。

图3A和图3B是方框图，其中示出分组为何变得更加复杂，并且可能更加模糊，因为景观包括更多的景观元素，例如额外的应用程序或额外的内容，或其额外的实例。

图4是方框图，其中示出如何在具有多个景观元素的景观中使用分组。

图5是方框图，其中示出如何使用分组来辅助计算过程，例如安装交叉内容。

图6是类似于图5的方框图，但包括可用于合并应用程序或内容的多个实例的合并元素。

图7是示出如何在景观中，包括具有图5和图6所示的景观的示例性元素的景观中，使用合并元素的方框图。

图8到图12是方框图，其中示出如何使用分组来限定景观，例如包括合并元素或交叉内容，并且进一步示出可使用分组来从组中排除景观元素。

图13示出如何在工件定义或表格或其他数据结构或数据类型中维护分组信息。

图14示出具有多个景观元素的景观，这些景观元素使用合并空间进行组合，其中所述合并空间可供外部客户端或消耗应用程序访问。

图15到图17示出具有一个或多个合并空间的景观，其中包括用于识别特定数据来自哪个景观元素的特征，以及示出引用合并空间中的合并工件的工件。

图18提供合并工件的示例性定义。

图19示出将集成配置信息添加到工件的注释的示例性代码。

图20和图21提供包括数据集成配置信息的数据工件的示例性代码。

图22是示出定义合并空间的技术的流程图。

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

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

具体实施方式

示例1概述

软件使用场景越来越复杂。例如，使用该软件的企业可以运行软件应用程序的多个实例，而不是运行软件应用程序的单个实例。以在美国和欧盟同时经营的企业为例。出于各种原因(例如不同的法律约束)，企业可以使用一个软件实例来处理美国的数据或运营，使用另一个软件实例来处理欧盟的数据或运营，而不是运行单个软件实例来处理这两个区域的数据。

软件使用场景变得越来越复杂的另一种原因在于用户越来越普遍地希望合并来自多个软件应用程序的数据。例如，公司可以使用一个软件应用程序来管理员工信息，使用另一个软件应用程序来管理财务运营。出于各种原因，用户可能希望同时利用这两个应用程序中的数据。

当用户可以使用多个软件应用程序时，还可能存在应用程序功能或数据可能因用户可用的其他软件应用程序而异的情况。也就是说，如果只能假定应用程序A可用，则应用程序A的软件功能可能会受到限制。但是，如果应用程序B也可用，则可以为应用程序A提供附加功能。

可以针对应用程序A和应用程序B均可用的场景来开发交叉内容。交叉内容可以是为其定义交叉内容的一个或多个软件应用程序的功能，例如进程、用户界面元素或软件元素(例如，数据类型，包括抽象或复合数据类型、数据结构或数据模型的实例，其中在某些情况下，数据模型可以是软件对象的集合，例如抽象数据类型实例)。也就是说，如果为应用程序A和应用程序B的组合定义了交叉内容，则所述交叉内容可以是应用程序A的内容、应用程序B的内容或应用程序A和B的内容。

出于各种原因，将该等“跨应用程序内容”或简称为“交叉内容”包括在应用程序A中可能是不可取的。例如，对于无法使用应用程序B的用户，将应用程序B的交叉内容包括在应用程序A中可能会增加应用程序A的大小和复杂性。在单组件应用程序中合并交叉内容可能是不可取的其他原因包括：交叉内容的生命周期可能与基本应用程序不同，并且该等跨内容可能是由不同的组织/组来负责的。也就是说，应用程序A的开发人员可能不熟悉应用程序B，因此适于将应用程序B的交叉内容合并到应用程序A中。如果必须打包各种类型的内容，以便在特定安装环境不满足安装整个包的要求时可以安装包的独立部分，则数据包的复杂性也会增加。

将交叉内容置于与为其定义交叉内容的应用程序分开的安装包中有助于解决此问题。此外，将交叉内容置于单独的安装包中有助于限制对交叉内容的访问。交叉内容可以表示重要的开发工作，并且可以提供有价值的特征。将交叉内容置于单独的安装包中提供了一种限制对交叉内容的访问的方法，例如，限制认为交叉内容具有足够价值公司来单独获取交叉内容。请注意，本申请中使用“跨应用程序内容”来进行简要说明。但是，除非另有说明，否则对跨应用程序内容的讨论与其他类型的“交叉内容”具有同等效力。

实施涉及多个软件应用程序或单个软件应用程序的多个实例的软件使用方案可能很复杂。因此，存在改进的空间。

作为涉及多个软件应用程序或软件应用程序实例的软件场景如何复杂的示例，假定安装场景通常是在计算系统的特定状态下进行的。即使对于单个软件应用程序的安装，也假定安装通常需要存在适当的系统资源(处理器、内存)、适当的操作系统以及例如软件库或支持程序或框架的可选的其他软件。

在特定用户可以拥有同一软件应用程序的多个实例的情况下，或者应用程序或内容在一组应用程序可用时是可用的情况下，可能难以预测正在使用什么样的景观，或者应如何处理景观中的应用程序和内容。本文所用的“景观”是指可用于特定计算环境中的一组应用程序或内容。景观可以包括应用程序或内容的多个实例，或者可以包括不同的应用程序或内容。

作为难以解释变化的景观的示例，考虑应用程序A和应用程序B在目标系统上均可用时可安装的所开发的软件或内容。如果应用程序B在特定景观中不存在，或者如果景观中存在应用程序A的两个实例，则可能无法安装软件或内容。作为另一个示例，考虑应用程序A的两个实例和应用程序B的两个实例均可用的两个景观。可以对应用程序实例的数据进行分组，但分组可能是以不同的方式进行的。一种分组可以是对应用程序A的两个实例进行分组，并且对应用程序B的两个实例进行分组。另一个分组可能是形成两个组，每个组中具有应用程序A和应用程序B的实例。除了难以涵盖可能的所有不同景观方面之外，可能还不清楚应该选择多种处理景观方式中的哪一种来处理特定情况。

本公开提供有助于解决这些问题的各种创新。一项创新提供了一种分组技术，该分组技术允许在景观，包括具有应用程序或内容的多个实例的景观中对应用程序和内容进行分组。分组可以实现对景观的整理，以使得能够执行软件安装和其他操作，而无需开发人员关注不同的环境配置，因为给定景观的管理程序可以定义适当的分组。分组提供一种重要特征，通过将组定义为包括某些应用程序或内容，其他应用程序或内容根据定义被排除在不包括该等应用程序或内容的组之外。至少在某些情况下，应用程序或内容不需要被包括在任何组中，或者可以被包括在组中，但它们是组中的唯一成员。还在某些情况下，应用程序或内容可以被包括在多个组中，包括在嵌套组中。

另一项创新提供一种可用于实现应用程序或内容的分组的合并空间。所述合并空间可以与本公开的分组技术一起使用，也可以在应用程序/内容分组的其他情况下使用。所述合并空间可以是组合与软件应用程序或内容关联的数据的轻量级机制。所述合并空间接收查询，并且将查询指向该应用程序所合并的一个或多个目标。在特定示例中，在合并空间中创建工件的定义，这些定义是使用合并空间合并的目标中的工件的联合视图。因此，查询可以通过合并空间(或更一般地说，合并元素)中的合并工件来获取合并数据。或者，如下所述，可以提供一个或多个特定目标(例如合并元素)的标识符作为筛选条件，并且用于限制所检索的数据。

在某些情况下，使用应用程序或内容的用户可能只希望与合并数据进行交互，而不论合并数据是通过本公开的分组技术获得的还是使用所公开的合并空间进行合并的。但是，至少在某些情况下，维护指示合并数据来源的标识符可能是有用的。也就是说，例如，如果合并数据源自应用程序A、B和C，则既提供与应用程序A、B和C中的数据作为合并数据进行交互的能力，又提供识别源自特定应用程序的数据的能力，这可能是有用的。类似地，如果合并数据与应用程序A的两个实例相关联，则允许用户选择性地获取与应用程序A的特定实例关联的数据可能是有用的。在某些情况下，可以在用户界面中提供有助于合并数据的单个目标的标识符，例如与合并数据一起使用的筛选条件。

合并数据可以包括合并公共数据工件的多个实例，例如虚拟或物理数据模型中的工件。合并数据还可以包括合并实际存储的与此类工件关联的数据。在一个方面中，本公开提供用于指示工件的多个实例(选择性地可以是工件的不同版本(例如，其中一个版本包括不在工件的另一个版本中的字段或属性))如何相互关联的技术，例如工件的一个实例的键如何与另一个实例的键相关，或者当工件的多个实例具有合格数据时，应从哪个实例中检索工件数据。

示例2示例性计算环境

图1到图12示出如何对应用程序和内容进行分组的示例，例如合并数据或控制景观定义。景观定义可以用于协助或指导如何部署应用程序或内容，或者是否部署该等应用程序或内容。图1示出场景110、140、160，这些场景涉及第一应用程序即应用程序A的一个或多个实例、第二应用程序即应用程序B的一个或多个实例，以及如果应用程序A和应用程序B这两者可用时可以安装的跨应用程序内容。

场景110涉及应用程序A的单个实例112以及应用程序B的单个实例114。跨应用程序内容116被定义为当应用程序A和应用程序B的单个实例可用时进行安装。因此，场景110可以表示安装景观与跨应用程序内容116的预期部署景观相匹配的直观场景。

场景140和160不符合针对跨应用程序内容116的预期部署场景。场景140具有应用程序B的单个实例146，但是具有应用程序A的多个实例142、144。实例142、144可以表示例如针对欧洲区域运营的软件应用程序的实例以及针对北美区域运营的软件应用程序的实例。由于跨应用程序内容116是针对应用程序A的单个实例定义的，因此(对于安装程序或负责安装跨应用程序内容的管理员)可能不清楚是否应为应用程序A的实例142和应用程序B的单个实例146的组合、应用程序A的实例144和应用程序B的单个实例146的组合安装跨应用程序内容，或者应用程序A的实例142、144是否应组合，以及该组合是否与应用程序B的单个实例146组合。

可以是将应用程序A的两个实例142、144组合在一起，然后为该组合和应用程序B的单个实例146安装跨应用程序内容116是最“合乎逻辑的”。但是，即使在这种场景下，也可能会出现问题。首先，即便应用程序A的两个实例142、144可以组合，场景140的景观的用户可能不希望为应用程序A的这两个实例142、144安装跨应用程序内容116。该景观的用户可能出于一些原因而不希望合并应用程序A的数据，例如出于性能原因或维护数据分离的原因。或者，跨应用程序内容116可能与许可费相关联，并且用户可能认为跨应用程序内容不具备足够价值以获取应用程序A的实例142、144的许可。

请注意，跨应用程序内容可以与跨应用程序空间相关联。除非另有说明，否则应假定跨应用程序内容可以与跨应用程序空间相关联。可以考虑将跨应用程序空间用于分组、合并或本公开中描述的其他技术。也就是说，在某些情况下，可以使用示例4中描述的合并空间进行合并。在其他情况下，可以使用不同的机制进行合并。

场景160示出以下场景：跨应用程序内容116预期具有应用程序A和应用程序B的景观，但该场景仅包括应用程序B的实例162，而不包括应用程序A的实例。

图2示出使用分组来整理应用实例142、144、146和跨应用程序内容116的两种方式。在场景210中，应用程序A的两个实例212、214(在本例中表示美国的数据和欧盟的数据)被组合以提供合并的应用程序A内容216。然后安装跨应用程序内容116，引用合并应用程序A内容216和应用程序B的单个实例146。场景210会生成针对应用程序A的两个实例142、144的池化数据。

在场景240中，应用程序B的单个实例246存在，但被定义为两个组的一部分。一个组将应用程序B的实例246与应用程序A的第一实例242组合在一起。另一组将应用程序B的实例246与应用程序A的第二实例244组合在一起。在这种情况下，安装了交叉内容的两个实例250、252，一个用于具有应用程序A的第一实例242的组，另一个用于具有应用程序A的第二实例244的组。场景240在以下情况下是有益：例如，希望将与美国相关的数据的交叉内容(实例242)从与欧盟相关的交叉内容(实例244)分开。场景240示出，至少在某些场景下，可以将特定应用程序或内容定义为在多个组中。

图3A和3B示出更复杂的景观300，其具有应用程序A的两个实例308、310，应用程序B的两个实例314、316，以及当应用程序A和B存在时可以安装的交叉内容320。从不同的分组可能性可以看出，随着应用程序/内容类型数量的增加，或者随着给定应用程序/内容类型的实例数量的增加，景观的复杂性将迅速增加。

在场景330中，已经为应用程序A的第一实例308和应用程序B的第一实例314安装了交叉内容320。应用程序A和B的第二实例310、316尚未安装跨内容。场景334与场景330相反，其中已经针对应用程序A和B的第二实例310、316安装跨应用程序内容320，但未针对应用程序A和B的第一实例308、314安装该跨应用程序内容320。

在场景340中，已经从应用程序A的两个实例308、310生成合并内容342，并且已经从应用程序B的两个实例314、316生成合并内容344。已经为应用程序A的合并内容342和应用程序B的合并内容344安装了交叉内容320。

在场景350中，针对应用程序A和应用程序B的实例安装交叉内容，然后将该交叉内容进行合并。也就是说，针对应用程序A的第一实例308以及应用程序B的第一实例314安装交叉内容的第一实例320a，同时针对应用程序A的第二实例310以及应用程序B的第二实例316安装交叉内容的第二实例320b。从两个交叉内容实例320a、320b生成合并的交叉内容352。

场景340、350均表示形成交叉内容并且形成合并数据的“合乎逻辑的”方法。也就是说，场景340按应用程序分组，而场景350按区域分组。如果没有用户干预的情况下，或者如果不使用所公开的分组技术，特别对于自动进程，可能难以确定场景340或场景350是否应该被实现，因为根据所期望的结果，这两者均是合理的。但是，甚至不清楚用户是希望实施场景340还是350，因为用户可能会希望实施方案330或334。或者，用户可能希望不安装任何交叉内容320，或者可能希望实施方案350，但不提供合并的交叉内容352。

此外，尽管场景340、350，甚至场景330、334均是“有意义的”，但管理员或自动进程可能难以将这些场景与“无意义”场景区分开来。图B的场景360是从语义角度看来没有意义的布置的示例。也就是说，可以按照场景360所示将数据进行组合，但不清楚为什么该等布置是所预期的。

场景360示出针对应用程序A的第一实例308(表示来自美国的数据)和应用程序B的第二实例316(表示来自欧盟的数据)生成的跨应用程序内容320a，而跨应用程序320b是针对应用程序A的第二实例310(欧盟数据)和应用程序B的第一实例314(美国数据)生成的。合并的跨应用程序内容364可以从交叉内容实例320a、320b生成。目前尚不清楚为什么用户希望组合来自不同区域和不同应用程序的数据，而不是按区域组合数据或按应用程序组合数据。但是，如果不理解数据的“含义”，安装规则通常将无法区分场景340、350、360。

图4示出如何使用分组来定义景观中的组，其中可以使用这些组等来确定如何安装其他软件/内容或如何组合数据。不分组(由景观本身提供的除外)的基本景观410包括应用程序A的三个实例412、414、416和应用程序B的两个实例420、422。因此，应理解，相对于图3A和图3B，图4中示出用于组合数据和安装跨应用程序内容的更多选择方案。

景观430定义了两个组432、434，这两个组是基于应用程序类型定义的，但更一般地示出基于类型的分组，其中类型也可以是例如内容类型。因此，组432包括应用程序A的所有三个实例412、414、416，而组434包括应用程序B的两个实例420、422。

景观440还示出按应用程序类型的分组，但示出如何使用分组来将景观元素从组中排除。也就是说，尽管组444包括应用程序B的实例420、422这两者，并且因此类似于组434，应用程序A的组442包括应用程序A的实例412、414，但是已被定义成使得应用程序A的实例416被排除在组442之外。尽管从组中排除景观元素的原因多种多样，但其中一个原因可能是要为应用程序A和应用程序B安装跨应用程序内容，但仅针对US和EU地区数据，而不针对亚太地区数据。原因可能在于，如景观440所示，不存在针对亚太地区数据的应用程序B的实例。

此外，通常，可以手动或使用规则，包括用户定义的规则、作为用户选择选项提供的规则，或者由计算机实施过程所确定的规则来定义分组。规则可以是默认规则，其中只要用户未设置其他规则、未设置优先级高于默认规则的规则(例如，如果存在[定义的景观情况存在，则]使用规则B，否则使用默认规则)，或禁用默认规则，就会应用默认规则。默认规则可以是“按类型分组”，例如景观430、440所示。对于景观440，可以将默认规则编程为仅对存在应用程序B的相应实例的应用程序A的实例进行分组。

请注意，“规则”可以完全自动化，或者可以向用户或进程显示可以应用“规则”的信息，并且用户或进程可以选择实施该规则或忽略该规则。例如，如果检测到应用程序或内容的两个实例，则可以通知用户存在多实例(“多租户”)情况，并且在不使用本公开的多实例特征的现有场景之外，可以选择不实施该多实例逻辑、实施多实例逻辑或创建多实例逻辑(例如合并元素，如下文进一步所讨论)。

可以基于其他条件，包括与景观元素关联的数据或元数据而手动或自动进行分组。景观450示出用作分组标准的“位置”，其中应用程序A的实例412已与应用程序B的实例420被分组在组452中，因为这两个实例均涉及与US相关的数据，而组454包括应用程序A的实例414和应用程序B的实例422，具有用于EU的数据。在这种情况下，组452、454被定义成使得具有亚太地区数据的应用程序A的实例416被排除在所述组之外。

当分组是手动定义的时，可以基于任何所需条件进行分组，无论是否反映在与景观元素关联的数据或元数据中。也就是说，例如，用户可能知道应用程序A的一个实例与US数据相关联，并且应用程序A的另一个实例与EU数据相关联，并且基于该信息，而不使用具有指示区域的正式“标记”的景观元素进行分组。当然，在其他情况下，景观元素可以具有可用于分组的标记，无论这些标记是否也用于其他目的还是专门定义为用于手动或自动分组操作。

图5示出如何使用分组来协助计算过程，例如安装或部署软件或由软件使用的内容。在图5所示的场景中，分析景观500以确定是否可以部署已开发在景观中存在应用程序A和应用程序B时使用的交叉内容。图5中所示的场景与图4中所示的场景450相对应。组452、454可以手动定义或使用自动进程定义。

安装进程对景观500进行评估。安装进程将组452标识为包括应用程序A的实例412和应用程序B的实例420。由于应用程序A和应用程序B在组中可用，因此安装了交叉内容的实例520。

请注意，分组如何帮助解决之前确定的问题。也就是说，组452可以作为除了景观500的其他组或元素之外的一个单元进行评估(尽管在某些情况下，给定组可以相对于其他组或非分组的景观元素进行评估)。当组452被评估为一个单元时，不需要对安装过程进行编程以适应应用程序或内容的多个实例存在的情况，因为分组会导致具有每个应用程序的单个实例的组452。此外，分组还解决了景观元素分组方式可能含糊不清的问题。也就是说，通过将应用程序A和应用程序B的US数据分组到组452中，可以避免安装进程(无论是自动还是手动)错误地将应用程序A的US数据和应用程序B的EU数据分组，然后安装此组的交叉内容。

之后，安装进程可以评估组454，确定其包括应用程序A的实例414和应用程序B的实例422，并且针对组454安装该内容的实例522。

接着，安装进程评估应用程序A的第三实例416。由于应用A的第三实例416不在任何其他组中，因此景观500可以被用作分组标准。也就是说，组452、454可以优先于景观500，形成包括在外部组内的内部组。由于景观500不包括不包含内部组452、454内的应用程序B的实例，因此不会针对应用程序A的实例416安装交叉内容。

由于图5包括AB跨应用程序内容的两个实例550、552，可任选地包括用于这些实例的合并元素。图6示出场景600，其中合并元素610已被添加到景观500中，该景观550合并了AB跨应用程序内容的两个实例550、AB。

如上所述，可以提供不同的规则来处理嵌套组。在刚描述的示例中，内部分组优于外部分组，但其他分组以类似的方式处理。在其他情况下，可以将动作定义为仅对内部组执行，即如果特定景观元素可能存在的唯一分组是景观本身提供的分组，则不执行。以景观500为例，但现在包括应用程序B的附加实例，其中包括南美洲地区的运营数据。如果定义的规则为按景观分组(而不是景观中的指定分组)的应用程序实例提供交叉内容的安装，则将安装应用程序A的第三实例416和应用程序B的附加实例的交叉内容实例，即使在此示例中，该等安装可能被视为错误的结果。如果定义的规则未为仅按景观分组的景观元素提供交叉内容的安装，则将不会安装交叉实例。

无论分组标准如何，均可以应用关于组的使用的规则，至少在某些实施方案中是如此。也就是说，可以分析的是存在哪些组(以及可选地与组关联的类型)，而不是用于定义组的标准(这些标准甚至不需要与组关联)。也就是说，可以基于地理位置定义一个组(所选地理区域内的多个不同类型的应用程序或内容可能被包括在一个组中)，而另一个组可以基于应用程序或内容类型进行分组，而不考虑地理位置。这些组可以单独处理，而不用关注使用什么标准来组成一个组。请注意，可以对可用于分组的元素进行约束，例如在呈现给特定用户或分组进程的整体景观中。

图7示出景观700，其中包括与景观500和600相同的基本元素。景观700可以基于这些基本元素和组合规则而创建，而不必要求分组(尽管可以定义分组)。也就是说，可以使用组合同一应用程序或内容的多个实例的规则以及在应用程序A的实例和应用程序B的实例可用时安装跨应用程序内容的规则来创建景观700。

可以分析景观700以应用第一规则。应用程序A的三个实例412、414、416被标识，并且由应用程序A的合并元素710组合。应用程序B的两个实例420、422被标识，并且通过应用程序B的合并元素720组合。第二规则的应用标识用于应用程序A的合并数据的(单个)实例710存在，并且用于应用程序B的合并数据的(单个)实例720存在，因此跨应用程序内容的实例730可被用于合并元素710、720。

对应用程序A的实例412、414、416和应用程序B的实例420、422进行分组可以帮助定义景观700。例如，对应用程序A的实例412、414、416进行分组可以肯定地表明应将这些实例一起考虑，包括出于安装跨应用程序内容或合并实例的内容的目的。由于上文所讨论的原因，合并应用程序实例的一揽子规则可能并不总是适用的/符合用户的意愿。同样，用户可能希望从交叉内容中排除一个或多个应用程序实例。

图8示出景观800，其中示出如何使用分组来定义或指导涉及应用程序或内容的合并的更复杂场景。即便景观700可以使用默认规则生成，该景观也可能并非适用于所有情况。因此，分组不仅可以帮助指导行为以生成景观700，而且还可用于推翻分组规则以生成具有不同配置的景观。

具体来说，在景观800中，已经定义了组810，其中包括表示US和EU的数据的应用程序实例412、414、420、422，但已被定义为排除具有亚太地区数据的应用程序A的实例416。结合图7描述的对景观800的规则应用可提供组合应用程序A的实例412、414的内容的合并元素820以及组合应用程序B的实例420、422的内容的合并元素830。交叉内容实例840是为合并元素820、830创建的。与景观700一样，可以选择性地包括其他分组，以帮助指导合并元素的形成以及跨应用程序内容的安装。例如，在某些情况下，可能需要不合并某数据，或者不安装某跨应用程序内容。

图9示出一个比前面描述的场景更复杂的场景，其中三个应用程序位于一个景观中，并且一个或多个应用程序具有多个实例。具体来说，图9示出具有应用程序A的三个实例910、912、914，应用程序B的两个实例918、920以及应用程序C的单个实例924的景观900。在此场景中，有两种类型的跨应用程序内容可用。跨应用程序内容是针对应用程序A、B和C均可用的场景定义的。还针对应用程序A和B可用的场景定义了跨应用程序内容。

针对景观900定义了三个组。组930包括应用程序A的第一实例910以及应用程序B的第一实例918，其可以表示在同一地理区域内使用的不同应用程序。组934包括应用程序A的第二实例912以及应用程序B的第二实例920。组932、934可用于安装针对应用程序A和B的组合定义的跨应用程序内容的实例940、942。

景观900，无论是使用未示出的分组还是所定义的规则，均包括合并元素948、950，其中合并元素948合并应用程序A的实例910、912的数据，并且合并元素950合并针对应用程序A和B定义的跨应用程序内容的实例940、942。

组936包括用于应用程序A的合并元素948、应用程序B的第二实例920和应用程序C的单个实例924。由于组936包括应用程序A、B和C中的每一者的实例，因此可以为组936安装针对应用程序A、B和C定义的跨应用程序内容的实例960。

通过定义如图9所示的组936，可控制合并元素和跨应用程序内容这两者。也就是说，通过定义组936以使其排除应用程序B的第一实例918，不会为应用程序B创建合并元素。类似地，由于应用程序B的第一实例918不在组936中，因此不安装包括应用程序B的第一实例的应用程序A、B、C的交叉内容。

图10示出可从图9所示的应用程序实例生成的替代景观1000。景观1000总体上与景观900相似，但不包括组936。当对景观1000进行分析以确定是否可以安装用于应用程序A、B和C的组合的跨应用程序内容时，可以确定存在应用程序AB交叉内容的单个实例950存在，其可被视为应用程序A数据的单个实例和应用程序B数据的单个实例(因为AB交叉内容链接到应用程序A和应用程序B的实例)。因此，当确定存在应用程序C的单个实例924时，可以使用合并元素950和应用程序C的实例924来安装ABC跨应用程序内容的实例1010。

图11所示的景观1100示出如何能为AB跨应用程序内容的单个实例安装ABC跨应用程序内容，而不是为AB跨应用程序内容的所有实例安装跨应用程序内容。

景观1100总体上类似于景观900，包括应用程序A的实例910、912、914，应用程序B的实例920、922，组930、934，AB跨应用程序内容实例940、942，以及AB跨应用程序内容的合并元素950。但是，景观1100包括组1110的定义，该组包括AB跨应用程序内容的实例940以及应用程序C的实例924，但排除AB跨应用程序内容实例942以及用于AB跨应用程序内容的合并元素950。由于只有AB跨应用程序的实例940与应用程序C的实例924被分组在一起，所以为景观1100安装ABC跨应用程序内容1120，但仅相对于组1110中的元素进行该安装。

作为如何使用分组来控制合并元素的生成和跨应用程序内容的安装的最后一个示例，请考虑图12所示的景观1200。景观1200总体上类似于景观900，包括应用程序A的实例910、912、914，应用程序B的实例920、922，组930、934，AB跨应用程序内容实例940、942，以及AB跨应用程序内容的合并元素950。在这种情况下，景观1200包括应用程序C的实例924和应用程序C的第二实例1210。

组1220包括组930及其组成元素、AB跨应用程序内容的实例940以及应用程序C的实例924。由于组1220包括应用程序A、B和C这三者的实例，因此可以为组1220安装ABC跨应用程序内容的实例1230。以类似的方式，组1224包括组934及其组成元素、用于应用程序A和B的跨应用程序内容的实例942、以及应用程序C的实例1210。由于组1224包括应用程序A、B和C这三者的实例，因此可以为组1224安装ABC跨应用程序内容的实例1234。由于存在两个实例1230、1234，因此可任选地创建用于ABC跨应用程序内容的合并空间1240(或如果适用，使用应用自动规则自动创建)。

示例3-示例性组标识

图13示出用于维护分组信息的技术，尽管分组信息可以用其他方式维护而不脱离本公开的范围。分组信息可以通过多种方式进行维护，例如定义组并且列出组内包括的组景观元素或与之相关的工件，或者为单个景观元素或与之关联的工件提供相应元素所属的任何组或组的标识符。分组标识符可以被包括在景观元素的定义、说明或声明中，也可以将此信息保留在另一个结构中。

表格1350可用于维护成员资格信息。该表格包括用于标识特定包，例如可以对应于应用程序或内容的安装包的列1352。如上所述，存在可以在列1354中指定的应用程序或内容的多个实例或“租户”。这些实例可以是一种类型的“景观元素”，如该术语在本公开中所使用。

表格1350可以包括用于跟踪组成员资格的一个或多个列1358。在某些情况下，景观元素或其工件可以属于多个组。组可以是嵌套的，也可以是非嵌套的。如果允许嵌套组，则不同的列1358可以表示嵌套级别的增加或减少。非嵌套组中的成员资格可以通过表格中具有给定元素的多个条目来指示，每个条目均具有各自非嵌套组的组标识符(以及可选地，列1536的附加值以指示与给定独立组的嵌套)。

表格1350的主键(primary key)可以取决于是否允许嵌套。如果既不允许嵌套也不允许多个组成员资格，则表格1350的主键可以由列1352、1354、1356组成。如果允许嵌套或多个组成员身份，则列1352、1354、1356以及列1356的第一实例可以作为主键。

在其他示例中，可以针对特定景观或景观元素维护分组信息，如该术语在本公开中所用。在整体景观的情况下，可以在具有表格1350信息的表格中维护分组信息，或者在数据结构或数据类型的实例中维护等效信息，例如将该信息包括在JSON文档中，或与景观(或景观元素)相关联的元数据中。或者，可以在用于景观元素或者与景观元素相关联的元数据中维护分组信息(可以查询景观元素的集合以收集/识别特定组中的景观元素，其中可以选择性地为整体景观存储此信息)。

示例4示例性合并元素实施方案

如上所述，景观元素可以针对景观来合并。本公开的各个方面不限于任何特定的合并机制。但是本公开提供一种可以达到这一目的的创新合并空间。

合并空间用作独立于正在合并的“空间”的“空间”。例如，应用程序可以与特定的命名空间或建模空间相关联。建模空间的示例包括物理或虚拟数据模型或方案，例如关系数据库的物理或虚拟方案。

使用单独的空间进行合并可以提供若干优势。一个优势在于，除了出于合并目的创建特定的空间外，还可使用现有技术来实施合并空间。例如，合并空间可以包括引用要合并的空间中的数据工件(例如，表格或视图)的视图。

图14示出示例性计算环境1400，其中包括可被外部应用程序1414引用的合并空间1410，该外部应用程序1414也可以称为消耗应用程序或客户端。

可以定义合并空间，例如数据库方案的实例化。作为定义的一部分，合并空间1410可以包括元数据1418，其标识作为合并空间的空间，或者合并空间也可以被标识为合并空间。在某些数据库系统中，可以使用类似的方法来标识用于开发、测试/质量保证或生产的特定空间。因此，可以为空间提供标签，其方式类似于指示空间用于“开发”，而不是指示该空间用于合并来自其他空间(例如应用程序或内容的实例)的数据的目的。但是，与指示空间是否用于“开发”等的标签的一个区别在于，合并空间是从其他空间(例如，景观元素，如该术语在本申请中所使用)生成的，因此具有依赖于底层合并空间的生命周期。

合并空间1410被图示为包括引用景观元素1446中的相应工件1430、1432、1434和景观元素1448中的相应工件1438、1440、1442的三个合并工件1422、1424、1426。

合并空间的一个考虑因素是合并空间中的内容应在多大程度上被包括在合并空间中。如果需要，合并空间中的所有内容例如所有工件均可以由合并空间寻址(例如，通过具有引用合并空间中的工件的相应工件)。但是，至少在某些情况下，可能没有必要针对合并景观元素的工件或元素而具有被称为合并工件或合并元素的工件或元素(如视图)。具体来说，在许多情况下，要合并的景观元素具有未对外暴露的工件(或其他元素/内容，其中将出于简化表示的目的而使用术语工件)。例如，合并空间可能具有视图栈，其中栈的较高级别处的一个或多个视图对外部用户暴露(可供外部用户使用)，但较低级别的视图或工件(例如表格)不对外部用户暴露。在其他情况下，单个工件例如表格可以对外部用户暴露，因此可以为此类工件创建合并元素。

因此，当定义了合并空间时，在某些情况下，可以通过检查相关合并空间中的工件，自动地将合并工件填充到合并空间中。可以对合并空间中的工件进行注释或以其他方式进行配置，以指示其是否对客户端/外部暴露。图14所示的工件1430具有指示其对外部暴露的注释1452，而工件1454具有指示其不对外部暴露的注释1456。暴露信息可能不是工件定义的一部分，而是可以位于与工件关联的其他元数据(包括与工件关联的标志)中，或者可以集中收集此类信息。例如，表格可以存储工件标识符以及指示其是否对外部消耗暴露的指示符。或者，该表格可以简单地存储暴露工件的标识符。

具体来说，这些“暴露”注释可以作为德国瓦尔多夫的SAP SE提供的技术实施，也可以以类似于其方式实施，包括可在虚拟数据模型(如核心数据服务视图)中使用的核心方案标记(CSN)中的定义。因此，在定义合并空间时，进程可以检查方案以确定暴露的方案元素(例如工件或特定工件的特定属性)，然后在合并空间中创建相应的合并工件，并且实施从底层工件获取数据的进程。具体来说，可以创建联合(UNION)视图，该视图组合来自两个或多个合并工件的数据，如由合并空间1410的工件1422、1424、1426的联合操作1460所示。

关于合并空间，通常，在某些情况下，可以为景观中的所有元素创建合并空间，即使元素的多个实例尚不存在并且因此而需要合并空间。类似地，合并空间可以选择性地包括来自未合并底层空间的暴露工件，例如因为仅存在单个空间，或者因为合并空间引用多个底层空间，但一个空间具有在另一个合并空间中没有对应项的一个或多个工件。与确实存在于多个合并空间中的工件一样，合并空间中当前未合并多个工件的任何工件均可以是具有特定性质的工件，例如被指示成对外部暴露。

默认情况下创建合并空间可能是有利的，因为在开发外部应用程序/配置进程以从景观中获取数据时，外部用户/开发人员能够假定存在合并空间。如果如上所述将合并空间实施成方案，则可以减少创建合并空间的空间/开销。

合并空间可能出现的一个问题是如何引用合并空间。也就是说，任意应用程序可能“不知道”合并空间和底层合并元素这两者均存在。因此，问题可能是如何将来自客户端的请求指向合并空间，而不是一个底层合并元素。在某些情况下，外部用户所引用的工件具有跨景观元素一致的逻辑名称。可以确定所引用的景观元素或工件是否与合并空间相关联。如果是，则可以将对逻辑名称的引用定向到合并空间中相应的合并景观元素/工件。如果不是，可以将逻辑名称定向到“基本”(未合并)景观元素或“基本”工件。

如果由合并空间合并的景观元素与不同版本相关联，例如具有两个版本的合并的软件应用程序或内容，则可能会出现问题。软件应用程序的一个版本可能具有另一个版本的软件应用程序中不存在的工件。或者，软件应用程序的两个版本可能具有相同的工件，但工件的定义可能因版本而异，例如一个版本中的表格或视图具有另一个版本中不存在的字段/属性。图14提供这种情况的示例，其中工件的第一版本即工件1440作为工件的第二版本即工件1432中不存在的属性(“P”)。

可以为整个合并进程、特定景观元素或特定景观元素的特定工件开发规则。一个可能的规则是，如果存在多个版本，将使用较新版本的景观元素或工件。另一规则是将使用旧版本的景观元素或工件。使用较旧版本有助于维护版本之间的数据一致性，因为通常较新版本的景观元素将添加数据工件/属性，同时保留以前的数据工件/属性。但是，此方法可能会导致新的数据工件或属性在延长的时段内不可用于外部使用，或者至少以合并方式提供。此外，可能难以确定景观元素或工件的所有实例何时均已更新到通用版本，否则可能会触发对合并空间的更新(例如，添加合并工件或修改合并工件以反映对合并工件的更改)。此外，某些跨应用程序内容可能需要在创建跨应用程序空间/安装跨应用程序内容之前安装特定的应用程序版本。

可以定义联合视图，以便不具有特定属性的数据工件可以具有为此类属性生成的NULL值，包括在与合并工件关联而存储的数据中。因此，如果在使用最新版本的景观元素/工件的情况下定义了规则，则可以安装跨应用程序内容(或者可以继续进行需要最新版本的景观元素/工件的其他进程)，因为景观元素/工件这两者均具有可用的属性，即使并非所有工件/景观元素均具有NULL值以外的值。

具有使用最新版本的景观元素/项目的规则可以避免上述问题。但是，由于基于未更新的景观元素/工件可能会遇到NULL值，因此消耗进程可能需要考虑NULL值的可能性，包括在使用与合并工件关联的数据执行的计算中。

“缺失值”/属性可以用其他方式处理。在一个实施方案中，可以对合并空间中的工件进行添加注释，以指示在合并元素中的相应工件没有特定属性的值，例如工件1424的默认值1464时使用的默认值。或者，可以例如使用注释指定如果第一合并景观元素中的第一合并工件没有特定属性的值，则应使用来自第二合并景观元素中相应第二个景观工件的值。在另一个实施方案中，可以对景观元素中的工件添加注释以指定属性的默认值，其中该值用于不包括该属性的其他景观元素的工件，例如工件1440的注释1468。尽管针对扩展添加的属性进行了描述，但类似的技术可用于处理由于合并景观元素中的版本差异而导致的工件之间的差异。

景观元素中的工件可以具有扩展，包括在CSN中表示的工件中实现的扩展，包括德国瓦尔多夫SAP SE所提供的产品中实现的CDS视图，以及如2022年4月5日提交的标题为“数据工件扩展的传播”(Propagation of Extensions of Data Artifacts)的第17/140,007号美国申请中所述，该申请在与本公开不矛盾的范围内、以引用方式并入本文中。扩展在计算环境1400中被示出，其中工件的第一版本1434包括扩展1472，该扩展1472不同于工件的第二版本1442的扩展1474。

扩展可以按照上述版本类似的方式处理。也就是说，可以将规则设置成使用工件的非扩展版本或工件的扩展版本(如果这两者均存在)，或者合并(例如通过联合(UNION)操作)均具有扩展，但扩展的性质不同的工件的两个实例。在某些情况下，扩展是否相同由扩展的名称或标识符决定，其中具有相同标识符的扩展被视为相同，并且具有不同标识符的扩展被视为不同。

扩展可能会引起额外的复杂性，例如，当两个扩展具有相同的名称和相同的属性，但该属性在一个工件中的类型(例如数据类型)与另一个项目不同。在某些情况下，可以设置规则，以便通过强制转换操作(cast operation)来解决此类差异，其中可以将特定的景观元素、数据工件或数据类型指示为优选，并且可以使用强制转换操作来将其他数据类型的数据转换为扩展属性的优选源的数据类型。在其他情况下，可以通过至少相对于具有冲突类型的扩展元素，将具有不同扩展元素数据类型的扩展视为不同的扩展来解决类型冲突。当冲突的扩展元素均被包括在合并工件中时，可以使其名称是唯一的来将其区分开来。

可以对合并在合并空间中的景观元素进行更新，或者对合并空间中所包括的工件进行更新。可以设置各种触发器或监控进程，以便在更新其引用的一个景观元素或更新该等景观元素的特定工件时可以更新合并空间。例如，如果安装了新版本的景观元素，则可以例如通过在合并空间中添加、移除或修改工件来更新包括该景观元素的合并空间。

对于此示例4的合并空间的内容，在某些实施方案中，合并空间中的工件仅限于合并空间所引用的景观元素中存在的工件。在其他情况下，可以允许合并空间中的其他建模，其中至少一部分工件存在于合并空间中，但不存在于底层景观元素中，可以向外部客户端/用户暴露。不允许在合并空间中进行其他建模可能是有益的，因为这样可以产生轻量级的合并空间，并且可以轻松添加、删除或修改。例如，如果删除不允许进行额外建模的合并空间，则不会丢失任何信息，因为合并空间中的所有工件将继续存在于原始景观元素中。此外，如果需要，可以基于原始景观元素轻松重建该合并空间。如果允许在合并空间中进行其他建模，则至少在可能影响现有合并空间的范围内，更改景观的组织方式(例如景观元素的分组)可能不切实际。

如果不允许建模，则可以在更高级别的使用栈，例如在访问合并空间的外部客户端上基于合并空间中的工件进行建模，如外部客户端1414的建模工件1476所示。或者，可以将其他工件包括在合并空间的构成景观元素中。关于视图栈的其他详细信息请参见于2022年4月5日提交的标题为“数据工件扩展的传播”(Propagation of Extensions of DataArtifacts)的第17/140,007号美国专利申请中，该专利申请在与本公开不矛盾的范围内、以引用方式并入本文中。

使用合并空间时可能出现的另一个问题涉及访问与合并空间中的工件关联的数据的用户授权。在某些情况下，可以维护用于合并空间的授权信息(包括为一个或多个工件指定授权的注释或扩展工件)，并且可以在合并空间中例如使用授权信息1480来检查授权。但是，如果需要轻量级合并空间，包括出于上述原因，则无需将授权维持在合并空间级别。相反，可以将用户信息传送到合并的景观元素，以使用景观元素的授权信息进行评估，作为执行合并工件的联合(UNION)逻辑的一部分。例如，图14示出用于景观元素1446、1448的授权信息1482。任选地，即使合并空间不对访问与合并空间相关联的数据施加限制，用于合并空间1480的授权信息1480或用于外部客户端1414的授权信息1484可以限制用户创建、删除或修改合并空间的能力。

请注意，此示例4的合并空间可以使用示例1-3的分组技术。也就是说，可以分析特定组中的景观元素以进行合并，包括在组嵌套的不同级别上进行合并。但是，合并空间可用于景观元素未分组的情况，或者现有分组是默认分组的情况，例如特定组织可用的一组应用程序或内容。或者，可以考虑更精细的分组，但使用示例1-3中描述的技术以外的技术。

示例5具有合并空间的示例性组织操作

合并空间以及(在某些情况下更一般地)合并元素可以执行各种操作，包括添加合并空间、移除合并空间、向合并空间添加景观元素或从合并空间中移除景观元素。具体来说，合并空间的优势在于，其构造对最终用户或进程是不可见的。但是，一旦合并空间被创建并投入使用，消耗空间(包括交叉空间)的操作应重定向到合并空间，这可能需要暂停操作，直到更新配置。

此外，可能需要重新部署消耗空间中的工件，这可能涉及更新/更改视图以更改其关联条件以引用合并空间中的工件。

另一个组织操作涉及上文所讨论的分组操作。也就是说，在某些情况下，可以从组中移除景观元素，这可能需要新的交叉空间，因为未分组的空间不再是消耗交叉空间所引用的合并空间的一部分。现有交叉空间中的工件可以更新为不再引用合并空间，至少在其涉及从分组中移除的景观元素的范围内。如果从分组中移除所有景观元素，则可能不再需要合并空间，因为合并空间可能不再合并任何景观元素。作为移除合并空间的一部分，可能需要更新消耗应用程序中的引用，这可能与创建合并空间时使用的进程相反。

除了从合并空间中移除景观元素对交叉空间的影响外，从合并空间中移除景观元素可能涉及重新定义或重新部署合并空间中的工件，例如从合并空间的合并工件中的联合(UNION)操作中移除与已移除景观元素关联的工件。在某些情况下，已移除的工件可能具有其他合并工件中不存在的属性，这可能导致将NULL值(或默认值或其他值)添加到该等其他合并工件中。如果需要，可以从仍由合并空间合并的景观元素的工件中移除这些NULL值/额外属性。

如下文进一步描述，合并的景观元素可以具有重叠数据，即具有相同键的同一工件的数据。如果从合并空间中移除的景观元素的工件被指定为合并工件的优选数据源(如示例7中所述)，则可能需要更新该指定以考虑景观元素的移除。

一般来说，在某些情况下，一旦从合并空间中移除最后一个合并景观元素，就可以移除合并空间。在其他情况下，即使合并空间中不包括任何景观元素，也可以保留合并空间的实例化，其中如果分组或景观元素发生更改，则可以使用该实例，并且可以再次使用合并空间来合并景观元素。当合并空间中仅保留单个景观元素时，可以采取类似的操作，因为从技术上讲，使用仅引用单个景观元素的合并空间不会合并任何内容。

如果将景观元素添加到合并空间中，则可以相应地更新起作用的景观元素中的工件，例如更新合并空间的合并工件中的联合(UNION)操作以引用所添加的景观元素的工件。工件本身可能也需要更新，以在所添加的景观元素中包括来自工件的任何新属性。如果合并工件的源工件的属性存在差异，则可能需要更新源工件以包括新属性，并将NULL(或默认值或某个其他指定值)添加到合并景观元素的工件中。如示例6中进一步解释，合并空间可以例如使用表格来跟踪合并空间中所包括的景观元素。将景观元素添加到合并空间时，也可以更新此构造。任选地，合并空间的消耗空间中的工件可能也需要更新，例如，以便其可以确定是否应使用合并数据，或者是否应将数据筛选为所添加的合并景观元素的数据。在某些情况下，如示例7中所述，消耗工件可以与提供要检索的数据的配置信息相关联，将具有由在处理期间检索的初始数据项设置的特定景观元素的标识符，其中该标识符确定将如何执行其他数据处理(例如关联(JOIN)操作)。在这种情况下，移除景观元素可能不需要重新部署引用合并空间的工件，尽管可以对合并空间中的工件进行更新。

示例6具有合并景观元素的数据分离的示例性合并元素实施方案

对数据进行分组和合并，或者至少使用合并元素例如示例4中所描述的合并空间提供对数据的访问，可能是有益的，因为与访问单个数据实例(如与应用程序的特定实例关联的数据)相比，其可以允许用户或进程访问更大的数据集。即使用户或进程有权限访问特定类型数据的多个实例，从多个源获取数据也可能较为繁琐。用户或进程需要知道数据的多个实例是否存在，执行操作以获取数据，然后考虑是否或如何从多个实例合并数据。

即使获取并且合并了数据，有关特定数据源的信息也可能丢失，并且用户或进程可能不再能够从特定数据实例检索或操作数据。

上文的示例中描述了美国的应用程序实例和欧盟的应用程序实例的存在方式。分组技术可用于指示至少出于某些目的，应将来自这两个实例的数据一起考虑，并且合并元素可以允许访问组合数据。但是，需要考虑使用仅合并来自多个数据源的数据的联合(UNION)操作来提供合并的情况。除非通过联合(UNION)操作组合的数据具有允许有选择地获取来自一个源的数据的某些属性，否则针对联合(UNION)操作的查询将从组合数据源中检索数据，这可能导致计算资源浪费或结果不准确。尽管数据可以直接从合并数据的数据源获得，但至少在某些情况下，这仍然会产生额外的知识和实施负担。

本公开可以通过引入一个属性来解决上述问题，该属性指示与数据相关的景观元素(即，从中获得特定数据的景观元素)。景观元素识别属性可以作为属性添加到包括联合(UNION)操作的工件中。具体而言，可以将该属性添加到包括联合(UNION)操作的视图定义中，例如作为视图的字段(新列)。

图15示出包括景观元素识别属性的计算环境1500。至少在这种上下文下，“景观元素”可以包括相对于其他景观元素定义的景观特征。也就是说，某些环境元素可能是“基本”元素，例如作为景观中的主数据源的应用程序/内容实例。至少在某些情况下，“基本”元素是景观的主数据源，但不是数据的最终主数据源。例如，景观元素可以具有至少一些工件，包括表格或视图，其中数据是通过复制或数据联合而获取的。景观之外的远程数据源可以用作复制/联合数据的主要来源。

非“基本”元素的景观元素的示例包括引用一个或多个基本景观元素定义的元素。例如，合并元素合并两个或多个基本元素，但反过来，其他景观元素例如附加合并元素或交叉空间可以引用合并元素进行定义。类似地，可以针对两个或更多个“基本”景观元素定义交叉空间，但可以参考另一个交叉空间创建额外的交叉空间，或者可以通过合并元素来组合交叉空间。

图15示出相对于第一景观元素1508和第二景观元素1510定义的合并元素1520。第一景观元素1508和第二景观元素1510包括多个工件1530，例如表格或视图。景观元素1508、1510的至少一部分工件表示公共工件的不同实例，例如视图的第一实例和视图的第二实例。景观元素1508、1510可以具有不重叠的工件。此外，如上所述，景观元素可以具有未包括在合并元素中的工件，而不论是否存在其中一个工件的另一个实例，包括因为该等工件未对景观元素外部暴露。

景观元素1508、1510被图示为各自具有两个工件的实例，这两个工件是工件1530的一部分。也就是说，景观元素1508、1510具有第一工件的相应实例1534a、1534b，以及第二工件的相应实例1538a、1538b。请注意，工件的实例可以相同，也可以在某些方面有所不同。如图所示，工件实例1534a、1534b是相同的，而工件实例1538b的属性1542不被包括在实例1538a中。为说明如何使用所公开的技术，假设景观元素1508包括应用程序的欧盟数据，而景观元素1510包括应用程序的美国数据。

合并元素1520包括分别对应于由工件1534a、1534b和1538a、1538b形成的合并工件1550和1552。以工件1550为例，可以看出其所包括的属性1558对应于工件实例1534a、1534b的属性1560。工件1550可以是工件实例1534a、1534b上的视图，例如定义为工件实例1534a、1534b的联合(UNION)的视图。由于工件1550组合了来自工件实例1534a、1534b的数据，因此其包括这些工件的属性1560(以属性1558的形式)。

工件1550还包括属性1562，该属性用于标识哪个工件实例1534a、1534b被用作特定数据例如行的来源。因此，以工件实例1534a的第一数据集例如行为例。当使用合并工件1550检索数据时，数据将包括工件实例1534a中的属性1560的值。来自实例1534a的数据也将与属性1562的值相关联，其中该值标识景观元素1508。现在，假设工件1550的数据包括源自工件实例1534b的第二行。合并工件1550可用于获取第二行的属性1560的值，并且该数据将进一步与标识景观元素1510的属性1562的值相关联。

消耗者空间1570引用合并元素1520。消耗者空间1570可以是最终用户使用的应用程序，也可以是景观的另一个元素。例如，跨应用程序内容的空间可能引用合并空间。或者，较高级别的合并空间可以引用合并元素1520所表示的较低级别合并空间。

在引用合并空间1520时，消耗者空间1570可以包括直接或间接引用合并空间的一个或多个工件的一个或多个工件。例如，消耗者空间1570被图示为具有引用合并元素1520的工件1550的工件1572。尽管工件1572具有与工件1550相同的属性1560、1562，但工件1572可以选择包括不在工件1550中的属性或排除一个或多个属性1560。

消耗者空间1570的工件1576引用了工件1572。尽管工件1576被图示为仅引用工件1572，但任选地，工件1576可以引用其他工件，包括对应于合并元素1520的工件的工件或在消耗者空间1570中定义的工件。此外，工件1576可以任选地包括不在工件1572或工件1550中的属性，或者可以省略工件1572、1550中的属性。

工件1572、1576被图示为包括景观元素识别属性1562(其也可以称为贡献者标识符属性)。通过这种方式，使用工件1572、1576的查询可以通过包括属性1562的一个或多个适当值来按景观元素筛选数据。

维护关于合并元素中包括哪些景观元素的信息是有用的。除此之外，此信息可用于消耗空间/应用程序，以帮助识别(例如最终用户)合并元素的范围，包括标识哪些筛选可用于检索或操作与合并元素关联的数据。

相应地，合并元素1520被图示为包括贡献者表格1580，其也可以称为景观元素表格或空间表格。贡献者表格1580包括列1582，其标识在合并元素1520中使用的特定景观元素。列1582用作表格1580的主键，并且属性1562的值用作表格1580的外键。任选地，表格1580可以包括附加属性，例如列1584，其提供贡献空间的语义描述。该语义描述可用于向用户提供更多有意义的信息，例如帮助用户确定应选择哪些景观元素标识符作为特定用例的筛选标准。

下文将参照图16进一步说明使用合并元素和标识符来标识与合并元素相关联的数据的源景观元素。图16示出计算环境1600，该计算环境表示比计算环境1500更复杂的场景，其中计算环境1600包括两个合并元素1604、1606，这两个合并元素又被景观元素1610引用，该景观元素1610是用于跨应用程序内容的景观元素。也就是说，合并元素1604包括合并工件1612，其合并用于第一景观元素1618和第二景观元素1620(其可以表示第一应用程序的实例)的工件的第一实例1614和第二实例1616的数据(或对数据的访问)，而合并元素1606包括合并工件1622，其合并用于合并第三景观元素1628和第四景观元素1632(其可以表示第二应用程序的实例)的工件的第一实例1624和第二实例1626的数据。

合并工件1612、1622被构造为如针对合并元素1520所述的。合并工件1612、1622包括来自相应工件1614、1616、1624、1626的属性。合并工件1612、1622还包括可以被实施为属性1562的相应景观标识符属性1636、1638。此外，每个合并元素1604、1606分别包括贡献者表格1642、1644，其可以被实施为如针对贡献者表格1580所述的。

景观元素1610用作合并元素1606、1608的消耗者。景观元素1610包括引用合并工件1612的工件1650以及引用合并工件1622的工件1652。请注意，尽管工件1650包括合并工件1612的所有属性，包括景观标识符属性1636，但工件1652不包括合并工件1622的所有属性。例如，这可以表示工件1652被定义为工件1622的投影。

景观元素1610包括通过引用工件1650定义的工件1660，以及相对于工件1650和1652这两者定义的工件1662。由于工件1662是相对于与不同合并元素相关联的工件来定义的，因此工件1662包括对于组成合并元素1604、1606中的每一者的贡献者识别属性1636、1638。如果需要，当使用工件1662处理数据请求时，可以提供针对属性1636、1638中的一者或者这两者的筛选标准。因此，尽管合并数据可以从合并元素1604、1406获得，但景观元素1610还可以检索与使用合并元素合并的特定景观元素相关联的数据。

在消耗者空间中，例如在消耗者空间1570或景观元素1610中，多个工件可以引用整合空间中的工件。例如，工件1662不引用景观元素1610中的工件1650、1652，而是可以直接引用合并工件1612、1622。但是，如果可能，使得消耗空间中的工件引用消耗空间中引用合并元素中的工件的另一个工件，而不是直接引用合并空间中的工件，这可能是有益的。原因在于，引用合并元素中的工件(可称为代理工件)的第一对象(可以是工件栈中的最低级别工件)可以设置可由引用代理工件的工件所控制的筛选和投影操作，包括限制从合并元素传送到消耗者空间的数据。引用代理工件可以简化工件依赖项的处理。

代理工件还可以简化配置问题。如将在后续示例中所讨论，可能是有用的是对工件进行配置以指定如何集成来自多个来源的数据，包括是否合并数据、将数据维护为单独的数据，或者当数据可从多个数据源获得时是否应使用单个数据源(例如，具有相同键的数据存在于不同合并景观元素中的工件中)。使用代理工件，这些配置选项可以设置一次，并且由多个更高级别工件使用，这些工件例如如果不需要代理工件的所有数据，则可以执行额外的筛选和投影操作。

在某些情况下，在消耗空间中创建工件之前，可以在合并景观元素中创建合并工件，其中消耗空间引用合并工件或引用由合并元素合并的景观元素中的“基本”工件。在这种情况下，可以将消耗空间中的工件创建为包括一个或多个景观标识符属性列。但是，在其他情况下，在创建合并元素之前，消耗空间中的工件可能已经存在。或者，可能期望更新包括景观标识符属性的工件，而不考虑如何/合适创建工件。

在一些实施方案中，创建或更新合并元素中的合并工件时，也会更新消耗空间，例如创建引用合并工件的工件或更新引用合并工件的工件。消耗工件可以具有更新的定义，以包括适当的景观标识符属性(例如，对于特定合并元素)、移除景观标识符属性(例如，如果从景观中移除合并元素)或修改景观标识符属性(可以被实施为删除先前属性和添加新属性)。在其他情况下，景观标识符属性作为工件定义的扩展被包含。将景观标识符属性作为扩展被包含可能是有益的，因为有助于避免通过对底层(扩展)工件的更改的干扰，包括当扩展工件是交叉内容景观元素中的工件时。例如，在交叉内容景观元素中，工件的内容可以与工件的景观组织方面分开管理。

景观标识符属性可以在消耗景观元素中的工件之间传播。例如，可以创建引用具有景观标识符属性的第一工件的第二工件，并且可以将景观标识符属性添加(传播到)第二工件。该场景如图16所示，其中消耗工件1650的景观标识符属性1636被传播到工件1660、1662，并且消耗工件1652的景观标识符属性1638被传播到工件1662。可以包括在所公开技术中的传播技术包括于2022年4月5日提交的第17/714,007号美国专利申请中所描述的技术，该专利申请在与本公开不矛盾的范围内、以引用方式并入本文中。

当合并元素按层次结构排列，即一个合并元素本身合并另一个合并元素，如图17所示时，可能会出现复杂情况。图17示出在某些方面类似于图16所示的计算环境1600的计算环境1700，即这两者均包括两个合并元素。但是，尽管计算环境1600具有用于不同软件应用程序的合并元素，但计算环境1700包括用于同一应用程序的单独合并元素，并且这些合并元素本身使用更高级别的合并元素进行合并，如下文进一步描述。

图17包括基本景观元素1704、1706、1708、1710，在本示例中，这些元素可以表示四个独立地理区域的应用程序实例：美国、欧盟、中国和印度。每个基本景观元素1704、1706、1708、1710包括第一数据工件的实例1714，例如表格或视图。分别为包括基本景观元素1704、1706(用于美国和欧盟)的“西部”分组和包括基本景观元素1708、1710(用于中国和印度)的“东部”分组定义了单独的合并元素1720、1722。

合并元素1720、1722包括合并第一数据工件的相应实例1714的相应合并工件1726、1728。如结合图16所解释，合并工件1726、1728包括贡献者标识符属性1732、1734，以指示作为给定数据集(例如表格或视图中的一行)的来源的基本景观元素1704、1706、1708、1710。合并元素1720、1722还包括相应贡献者表格1738、1740，其提供关于由相应合并元素1720、1722合并的相应基本景观元素1704、1706和1708、1710的附加信息。

合并元素1750对合并元素1720、1722进行合并。对于合并工件1754(被图示为版本1754a、1754b)，存在用以提供贡献者信息以允许在多个级别的景观元素进行筛选的各种选项。将单个值贡献者标识符包括在单个贡献者属性中可能会有问题，因为可能会将筛选选项限制为合并层次结构的单个级别。例如，如果只能提供一个贡献者标识符值，则贡献者信息可能仅限于标识合并元素1720、1722中的一者或基本景观元素1704、1706、1708、1710中的一者。因此，按景观元素筛选数据的能力可能会受到限制。

如果需要保留多个选项以在多个级别的景观元素进行筛选，则可以采用不同的方法，这两者均在合并元素1750中图示。在实践中，通常只实施一种方法。在合并工件1754a中，提供了两个景观标识符属性1760、1762。属性1760、1762中的一者可以用于标识合并元素1720或合并元素1722，另一个属性可用于标识基本景观元素1704、1706、1708或1710。这种方法的一个问题在于，多个层次的景观元素是如何相关的可能不清楚或不至少一样清楚。也就是说，从属性1760、1762本身来看，合并元素1720是否合并了基本景观元素1704、1706或基本景观元素1704、1706、1708、1710的其他组合可能不清楚或不可确定。另一个问题在于，由于给定的合并工件中可能存在两个或更多个贡献者标识符属性，因此可能不清楚应如何确定贡献者标识符属性，例如合并工件中存在多少贡献者标识符属性或该等属性的名称可能是什么。

在某些情况下，可以使用贡献者表格来改善其中一个或这两个问题，例如，如针对贡献者表格1770所示。标识符列1772描述了使用合并元素1750直接合并的空间。贡献者表格的说明列1774可以为贡献者标识符属性1760(指示层次结构的最高级别)、1762(指示层次结构的下一个最低级别)的可能值提供父子信息。例如，如果筛选值为“CS_S4_W”，则说明列1772可以具有指示景观元素1704、1706是“CS_SW”的子元素的信息。类似地，如果筛选值是景观元素1704或景观元素1708的标识符，则合并元素1720可以被标识为该景观元素的父元素。

合并工件1754b示出一种替代方法，该方法具有单个贡献者标识符属性1782。在某些方面中，标识符属性1782的值可以通过串接不同贡献景观元素的值来生成，例如“S4/L1+S4L1”，其中L1和L2分别指示合并元素1720、1722的级别以及基本景观元素1704、1706、1708、1710的级别。

这种方法的优势在于可以使用静态属性名称，并且合并工件的结构不需要根据特定景观的体系结构而更改。此方法的缺点是处理筛选值可能占用更多资源，因为可能使用字符串操作将串接后的值分隔为其构成筛选值。

在某些情况下，如表格1790所示，对景观/计算环境中的所有景观元素进行总结可能是有益的。在某些情况下，表格1790可以类似于贡献者表格1780(或图16中所示的贡献者表格1642、1644)，包括提供景观元素的标识符1792和景观元素的说明1794。在这种情况下，贡献者表格1738、1740可以任选地省略，或者可以仅包括合并景观元素的标识符，其中其他信息，例如说明，可以从表格1790中获取，例如通过连接(JOIN)操作。

图18示出代码1800，用于可以被包括在合并元素中的示例性合并数据工件。代码部分1810定义要合并的景观元素中的至少一个工件中存在的列，并且行1812添加具有对于特定合并元素唯一的名称1814的贡献者标识符属性。

行1820指定联合(UNION)操作(在本例中，具体来说，UNIONALL操作)，其中包括选择操作1830和1840。选择操作1830、1840包括相应语句1832、1842，这些语句填充在1812声明的贡献者标识符列，其值指示从中检索通过联合(UNION)操作检索的数据的特定景观元素。

示例7示例性数据集成技术

示例6描述用于维护合并景观元素的数据分离的技术。此示例7描述了如何能够合并来自各个景观元素的数据。示例7的这些创新可以与本公开的其他技术一起使用，包括与分组、合并空间和数据分离相关的技术。但是，示例7的创新可用于要集成来自多个源的数据的其他场景。

如上所述，不同的景观元素可以表示公共源的实例，例如软件应用程序的实例，其中软件应用程序可以具有特定的工件，例如表格或视图。因此，合并不同景观元素的数据可以涉及合并来自与特定类型的景观元素，例如特定软件应用程序关联的特定数据工件的不同实例的数据。

本讨论继续使用工件例如数据库视图的数据合并示例，但应理解，所描述的技术可以与其他类型的工件、软件对象等一起使用。视图的不同实例可能具有结构差异以及与视图关联的数据差异。例如，如示例6中所述，视图的某些实例可能具有其他版本的视图中不存在的属性。至于数据，可以存在各种情况。与数据工件的两个(或更多个)实例关联的数据可以是完全分离的，例如具有不同主键的数据；可以具有协调数据(具有相同主键的数据，其中具有相同键的两个不同视图实例中的数据引用相同“事物”，例如实体)、不协调的数据(其中至少一些主键在两个视图实例之间重叠，但其中至少一些键引用不同的“事物”或其组合)。

在合并视图的多个版本的数据时，存在多种可能性。在分离数据的情况下，通常可以假设数据可以简单地“组合”到合并工件中，因为来自一个实例的数据不会覆盖来自另一个实例的数据/与来自另一个实例的数据冲突。但是，对于协调数据，从两个源工件导入数据通常会导致来自一个工件的数据替换来自具有相同的键的另一个工件的数据。在分离数据的情况下也存在类似的情况，但在这种情况下，由于重复的键而覆盖数据或未能包括某些数据可能会导致一个项目(例如实体)的数据“丢失”/未合并，因为另一个项目具有相同的键，即使第一项目与键的另一个实例中引用的项“不同”。

数据之间的不同可能关系可能会产生问题，包括因为可能难以确定应如何(或是否)组合特定数据。例如，可能无法确定如何将数据组合类型应用于任意视图的两个实例。撇开这一点不谈，逐个工件地实现特定类型的数据组合可能既耗时又容易出错。

在某些情况下，可以定义规则，例如，以指示一个特定的景观元素应作为所有重叠数据/工件的“主要”数据源。也就是说，在重复键的情况下，将选择来自“主要”源的数据。但是这种指定可能过于粗糙，因为在实践中，一个景观元素应作为一特定视图的主要来源，而另一个景观要素应作为另一特定视图的主要来源。在其他情况下，可以基于与数据关联的内容类型定义规则，其中类型可能与视图相关联，例如在注释中，它可以自动确定应如何组合数据。但是，该等规则可能并非适用于所有情况，并且可能无法提供适当的内容类型指示符。

本公开将引用合并工件的构造与指示应如何组合来自不同底层源工件实例的工件的数据或应使用多个源工件实例中的哪一个的配置信息相关联，从而帮助解决上述问题。在特定示例中，所述配置信息可以以对消耗工件的注释的形式提供。与将配置信息包括在特定景观元素的源工件实例中相比，将配置信息包括在合并工件的消耗者中可能是有益的，因为特定的景观元素(或其创建者/管理员)可能不知道可能存在哪些其他景观元素，当景观元素中的至少某些内容由与合并信息的消耗者不同的来源提供时尤其如此。也就是说，尽管景观元素中的工件可能由特定的软件公司创建，但该公司可能不知道该景观元素可能出现的所有可能的景观，如本公开的前述示例中所描述。即使该公司对不同的使用场景有一些了解，也可能无法配置工件以考虑所有使用可能性，其中包括该公司可能没有设想到的可能性。

在某些情况下，可以在合并元素中维护适当的配置信息，这在合并元素是针对特定景观元素定义的时候是有用的。为提供更高精细度，可以在特定的合并工件中维护用于数据集成的配置信息。

但是，在某些情况下，例如，如果希望合并元素是轻量级的或例如在以上示例中讨论的合并空间中可以自动创建的合并元素，在合并元素中维护配置信息可能是不可取的。此外，当删除合并元素(或其特定的合并工件)时，配置信息也会丢失。

因此，在特定的实施方案中，数据集成配置信息被包括在使用合并元素的合并工件(例如合并空间中的工件)的组件中。例如，消耗工件通常由用户创建，其更了解消耗工件所使用的数据源，因而了解应如何集成数据。一旦提供了配置信息，计算机实施的框架即可以根据配置信息来处理数据集成。

上述方法的一个缺点在于，可能需要为同一消耗者或不同消耗者重复定义配置信息。也就是说，消耗空间中单独引用合并空间的每个工件可能需要包括数据集成配置信息，因为配置不是在合并元素级别进行的。如果同一消耗者的配置信息冗余，则可以通过具有引用合并元素并且包括集成配置信息的“代理”(poxy)工件来改善此问题。其他工件可以引用代理工件/通过代理工件被定义，因此不需要包括冗余配置信息。

配置信息可以以应用于合并元素消耗者组件的标记或类别的形式提供，例如在消耗空间的工件中包括标记。这些类别可以包括“未定义”、“分离”、“协调键”、“代表性提供者”和“协调数据”的枚举值，每个标签的含义将在下文中进一步解释。“未定义”标记可以指不对数据集成做出任何假设的情况，并且可以是默认标记，直到/除非更新，包括通过应用特定的自动化规则。如果使用“未定义”标签，则无需提供特定景观元素的标识符，除非需要特定的筛选。在这种情况下，不考虑按景观元素进行的任何筛选，具有“未定义”标记的工件将检索与合并工件中定义的所有工件实例关联的数据。但是，组合来自多个工件的数据的关联(例如在引用多个其他视图/实体的视图中)，包括正式的连接(JOIN)操作，对贡献者标识符属性具有额外的关联条件。换言之，关联条件的每次执行都将检索与特定景观元素关联的数据，其与锚定点记录(或其他锚定点数据)相关联。

当已知不同的源工件使用不同的键时(例如，美国的应用程序实例的员工与欧盟的应用程序实例的员工不同，并且这些员工与不同的主键值相关联)，则可以使用“分离”标记。如果使用“分离”标签，则无需提供特定景观元素的标识符，除非需要特定的筛选。在这种情况下，不考虑按景观元素进行的任何筛选，具有“分离”标记的工件将检索与合并工件中定义的所有工件实例关联的数据。但是，与“未定义”工件相同，组合来自多个工件的数据(例如在引用多个其他视图/实体的视图中)的“分离”工件实例的关联，包括正式的连接(JOIN)操作，对贡献者标识符属性具有额外的关联条件。换言之，关联条件的每次执行都将检索与特定景观元素关联的数据，其与锚定点记录(或其他锚定点数据)相关联。

当已知至少某些键在不同的源工件中重复时，可以使用“协调键”标记，但是如果一个键存在于多个源工件中，则其引用同一个“事物”。但是，某些源工件可以具有其他源工件中没有的键，或者不同的源工件可以具有具有相同键但某些属性不同的元素。在这种情况下，可以使用连接(JOIN)操作来检索来自多个源工件的数据，其中将贡献空间的标识符添加到连接(JOIN)条件中。因此，与“未定义”和“分离”标记一样，对于具有“协调键”的工件实例，给定锚记录的连接(JOIN)结果将限制为同一景观元素中的结果，进而可以避免数据在不同景观元素中的相应工件实例中不存在的情况，或者特定工件实例中的键被协调的情况，但非键属性中的数据是分离的。

“代表提供者”是存在“协调键”的情况的特例。在这种情况下，选择特定的源数据工件作为要与消耗工件一起使用的数据源，例如，因为特定工件具有更大的数据量/较高的数据质量。可以在消耗工件的定义中手动提供代表性提供者的标识。此标识符将用作筛选条件(例如，“WHERE CONTRIBUTOR_IDENTIFIER＝REPRESENTATIVE_PROVIDER_ID”)。

“协调数据”是“协调键”的另一种特例。“协调数据”是指可以从任何来源选择数据，大概不会损失信息或质量。“协调数据”可以使用特定源工件的静态标识符来实施，也可以动态确定特定标识符，例如基于每个查询。可以随机选择或使用特定标准选择要使用的源工件标识符，例如基于哪个源工件实例具有最大的数据量或最高的数据质量，或者哪个源工件将提供最佳性能(例如，提供最快的查询响应或最少的计算资源)。否则，“协调数据”的实施方式与“代表性提供者”场景中所述的方式类似，其中筛选条件被应用于视图定义。

将配置信息置于消耗者空间中时可能出现的问题是，随着景观的变化，配置是否仍然有效。例如，如果从合并空间中移除了景观元素，则可能会影响使用合并元素的消耗工件中的配置信息的有效性。在某些情况下，当对合并元素进行更改(例如向合并元素添加景观元素或从中移除景观元素)时，合并元素可以触发对用户的警报，以便用户可以确定是否应更新任何配置信息。

图19示出数据工件，例如在德国瓦尔多夫SAP SE提供的产品中实施的CSN视图的示例性广义注释定义的代码1900。代码1900包括标识贡献者标识属性的元素1910。元素1920标识要与带注释工件一起使用的特定数据集成类型，其中元素1920的值可以是上文所指示的标记中的一者。在“代表性提供者”的情况下，可以为元素1920提供贡献者标识属性的特定值。

图20示出用于示例性工件定义的示例性代码2000，该工件定义包括注释2010，该注释是代码1900的特定实施方案。在这种情况下，注释2010指示由代码1900定义的工件所引用的源数据工件实例是分离的，因此，例如，由代码1900定义的工件的数据关联将被修改为包括与贡献者标识属性的关联。

图21示出用于另一示例性工件定义的示例性代码2100，该工件定义包括注释2110，该注释是代码1900的特定实施方案。在这种情况下，注释2110指示应使用“代表性提供者”制度，其中行2120提供代表性提供者的标识符，即特定的景观元素。

示例8示例性实施方案

本公开提供用于创建合并空间的技术，其中所述合并空间用于提供对与软件应用程序或软件内容的多个实例相关联的数据的合并访问。一种该等技术总结在图22所示的流程图2200中。

在2210中，接收多个景观元素的标识符，例如软件应用程序或软件内容的实例。多个景观元素中的给定景观元素包括一个或多个工件，例如表格或视图，并且具有类型(例如，该类型可以标识特定应用程序或特定软件内容集)。在2220中，为具有第一类型的多个景观元素中的至少第一景观元素以及具有第一类型的多个景观元素中的至少第二景观元素生成合并空间。在2230中，在合并空间中生成第一合并工件。第一合并工件引用至少第一景观元素中第一工件的第一实例以及至少第二景观元素中的第一工件的第二实例。

示例9计算系统

图23示出适当计算系统2300的广义示例，其中可以实施所描述的创新。计算系统2300不旨在暗示对本公开的使用范围或功能的任何限制，因为创新可以实施于不同的通用或专用计算系统中。

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

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

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

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

通信连接2370使得能够通过通信介质与另一个计算实体进行通信。通信介质在调制数据信号中传送信息，例如计算机可执行指令、音频或视频输入或输出、或其他数据。调制数据信号是以对信号中的信息进行编码的方式设置或更改其一个或多个特性的信号。例如但不限于，通信介质可以使用电气、光学、RF或其他载体。

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

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

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

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

示例10云计算环境

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

云计算服务2410被各种类型的计算设备(例如，客户端计算设备)，例如计算设备2420、2422和2424所使用。例如，计算设备(例如，2420、2422和2424)可以是计算机(例如，台式机或膝上型计算机)、移动设备(例如，平板计算机或智能手机)或其他类型的计算设备。例如，计算设备(例如，2420、2422和2424)可以使用云计算服务2410来执行计算运算符(例如，数据处理、数据存储等)。

示例11实施方案

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

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

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

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

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

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

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