CN115905164A - 对数据库工件的扩展的元数据的标识和导入 - Google Patents
对数据库工件的扩展的元数据的标识和导入 Download PDFInfo
- Publication number
- CN115905164A CN115905164A CN202211101500.5A CN202211101500A CN115905164A CN 115905164 A CN115905164 A CN 115905164A CN 202211101500 A CN202211101500 A CN 202211101500A CN 115905164 A CN115905164 A CN 115905164A
- Authority
- CN
- China
- Prior art keywords
- metadata
- data
- database
- field
- computing system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/14—Details of searching files based on file metadata
- G06F16/148—File search processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/25—Integrating or interfacing systems involving database management systems
- G06F16/258—Data format conversion from or to a database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
- G06F16/164—File meta data generation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2457—Query processing with adaptation to user needs
- G06F16/24573—Query processing with adaptation to user needs using data annotations, e.g. user-defined metadata
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Library & Information Science (AREA)
- Human Computer Interaction (AREA)
- Computational Linguistics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
描述了用于存储和处理元数据的技术和解决方案。目标系统向源系统发送请求以标识对一个或多个指定的数据库工件的扩展。源系统标识包括对一个或多个指定的数据库工件的元数据扩展的一个或多个软件对象,并且响应于该请求,将这种元数据元素的至少一部分发送到目标系统。源系统可以向目标系统暴露API,诸如标准格式的API,以辅助从源系统请求和检索元数据。
Description
技术领域
本公开一般地涉及描述数据工件(artefact)(例如,诸如表格或视图之类的数据库工件)的元数据。具体的实现方式提供了接收来自目标系统的请求以在源系统中标识或检索相关元数据的元数据暴露服务。
背景技术
越来越多的数据量从越来越多的各种源变得可用。与诸如特定模拟世界实体之类的特定目的相关联的数据通常与描述该数据的元数据相关联。例如,十位数的整数可能是数据,但是没有元数据,可能难以知道这个十位数的整数表示什么——电话号码、驾照号码、密码等等。因此,使用和使得数据“有意义”可能在很大程度上取决于有正确的元数据来为该数据提供上下文。
与诸如企业实体的运营之类的复杂工作相关联的数据库或其他数据源可能涉及数千种表格类型和数十亿条记录。表格或其他数据库对象可以相互引用,增加了复杂性。在某些情况下,来自一个系统的元数据可能在另一个系统中有用。例如,可能希望将数据从一个系统复制或传输到另一个系统,诸如当从预置数据库解决方案迁移到基于云的解决方案时。或者,可能希望诸如通过数据联合而使数据对另一个平台可用。然而,如果在不能访问元数据的情况下,使用或解释复制的或联合的数据可能是困难的或不可能的。考虑到源系统中可能存在巨量的元数据,在新系统中手动重新创建元数据会非常耗时。因此,存在改进的空间。
发明内容
提供本概述来以简化的形式介绍将在以下详细描述中进一步描述的选择的概念。本概述不旨在标识所要求保护的主题的关键特征或必要特征,也不旨在用于限制所要求保护的主题的范围。
描述了用于存储和处理元数据的技术和解决方案。目标系统向源系统发送请求以标识对一个或多个指定的数据库工件的扩展。源系统标识包括对一个或多个指定的数据库工件的元数据扩展的一个或多个软件对象,并且响应于该请求,将这种元数据元素的至少一部分发送到目标系统。源系统可以向目标系统暴露API,诸如标准格式的API,以辅助从源系统请求和检索元数据。
在一个方面,提供了一种用于向目标系统发送数据工件扩展的元数据的方法。从目标系统接收对元数据储存库中的至少一部分元数据的第一请求。标识包括一个或多个数据库工件的元数据扩展的一个或多个软件对象。响应于第一请求,将元数据扩展的至少一部分元数据元素返回给目标系统。
在另一方面,提供了一种用于从客户端系统获得描述数据库工件的数据的元数据的方法。在数据库系统中创建多个数据库工件。数据库工件被配置成存储数据或对数据的引用,其中数据由元数据描述。部署与数据相关联的元数据的至少第一部分。向客户端系统发送对与数据相关联的元数据的第二部分的请求。部署元数据的第二部分。
本公开还包括被配置为执行上述方法(或操作)或包括用于执行上述方法(或操作)的指令的计算系统和有形的非暂时性计算机可读存储介质。如本文所述,可以根据需要将各种其他特征和优点并入技术中。
附图说明
图1是图示其中可实现所公开的技术的示例计算环境的图,其中源系统提供可由目标系统访问的元数据暴露服务。
图2A是处理客户端对元数据的请求的方法的时序图,其中具有源系统的组件的操作的具体细节。
图2B是处理客户端对元数据的请求的方法的时序图,其中具有目标系统的组件的操作的具体细节。
图2C是在目标系统处自动创建数据库工件并将这些工件链接到在源系统处维护的数据和元数据的方法的流程图。
图3图示了标准化API如何能够提供对标准化格式的元数据的访问,以及如何能够引用非标准化格式的API。
图4图示了可由元数据暴露服务维护并可使用元数据暴露服务来访问的信息。
图5是图示计算环境的图,该计算环境可用于以与这种数据库工件的扩展相关联的元数据来补充数据库工件的标准元数据。
图6是示出模式中至少一部分数据库表格之间的技术关系的数据库模式的图。
图7是图示表格元素之间的关系的示意图,这些表格元素可以被包括在数据字典中,或者以其他方式用于定义数据库表格。
图8是图示数据字典的组件和数据库层的组件的示意图。
图9是用于数据库视图的示例元数据模型的代码。
图10是用于数据库视图的示例元数据模型的代码,以及用于修改或引用这种示例元数据模型的元数据模型的代码。
图11是图示元数据模型如何能够相关,以及如何能够被更新或删除的示意图,包括由多个计算系统进行相关、更新或删除。
图12A和图12B是图示如何能够以关系格式存储元数据模型的示例表格。
图13是图示元数据模型如何能够相关,并且如何能够包括查询操作,诸如select语句、join条件和where条件,以及数据库对象如何能够通过关联进行相关的示意图。
图14提供了示例数据库表格,图示了如何能够以关系格式存储图13中呈现的元数据模型信息。
图15是图示元数据模型如何能够具有相对于其他元数据模型定义的字段的示意图。
图16提供了示例数据库表格,其图示了如何能够以关系格式存储图15中呈现的元数据模型信息。
图17是图示元数据模型如何能够相关的示意图,包括具有注释的元数据模型和注释其他元数据模型的元数据模型。
图18和图19提供了示例数据库表格,其图示了如何能够以关系格式存储图17中呈现的元数据模型信息。
图20图示了能够访问元数据模型的持续性模型的数据访问服务的代码。
图21和图22呈现了可用于执行通过数据访问服务请求的操作的示例表格。
图23呈现了可用于注释显示元数据模型信息的用户界面服务的示例代码。
图24A提供了数据仓库的示例元数据描述,而图24B图示了能够从中生成的词汇表。
图25A提供了包括数组形式的元素的示例元数据描述,而图25B图示了可以从中生成的词汇表。
图26A提供了包括枚举列表形式的元素的示例元数据描述,而图26B图示了可以从中生成的词汇表。
图27A-图27J提供了可用于检索元数据的标准化格式的API的示例列表。
图28A-图28C提供了标准化格式的示例元数据列表的至少一部分。
图29A和图29B是图示了所公开的创新的实施例的流程图。
图30是其中可以实现一些所描述的实施例的示例计算系统的图。
图31是可以结合本文描述的技术使用的示例云计算环境。
具体实施方式
示例1概述
越来越多的数据量从越来越多的各种来源变得可用。与诸如特定模拟世界实体之类的特定目的相关联的数据通常与描述该数据的元数据相关联。例如,一个十位数的整数可能是数据,但是没有元数据,可能难以知道这个十位数的整数表示什么——电话号码、驾照号码、密码等等。因此,使用和使得数据“有意义”可能在很大程度上取决于具有正确的元数据来为该数据提供上下文。
与诸如企业实体的运营之类的复杂工作相关联的数据库或其他数据源可能涉及数千种表格类型和数十亿条记录。表格或其他数据库对象可以相互引用,增加了复杂性。在某些情况下,来自一个系统的元数据可能在另一个系统中有用。例如,可能希望将数据从一个系统复制或传输到另一个系统,诸如当从预置数据库解决方案迁移到基于云的解决方案时。或者,可能希望诸如通过数据联合而使数据对另一个平台可用。然而,在不能访问元数据的情况下,使用或解释复制的或联合的数据可能是困难的或不可能的。考虑到源系统中可能存在巨量的元数据,在新系统中手动重新创建元数据会非常耗时。因此,存在改进的空间。
本公开提供了可用于检索元数据的技术。在具体示例中,当源系统处的元数据描述的数据在目标系统处可用时,元数据可以被访问或被链接以供访问。例如,可以通过数据联合(当特别请求时从源系统检索数据)或通过数据复制(从源系统检索数据并存储在目标系统上,诸如在对这种数据的特定请求之前)而使目标系统处的数据可用。通过将对目标系统可用的数据自动链接到源系统处的元数据,而使数据在目标系统处更加可用。因此,所公开的技术可以消除用户手动重新创建元数据或手动从源系统中检索用于在源系统处可用的数据工件(诸如数据库表格、数据库视图或数据库进程)的元数据的需要。
在一些方面,源系统处的元数据服务促进目标系统或代表目标系统的中间系统进行元数据检索。源系统处的元数据服务可以包括将源系统的元数据转换成用于促进系统之间共享元数据内容的通用格式的元数据转换器。在具体示例中,通用格式可以是CSN(核心模式记法(Core Schema Notation),诸如在从德国沃尔多夫的SAP,SE可获得的软件中使用的)。CSN可以被认为是富含注释或语义信息的SQL语句。
源系统可以包括使元数据对外部系统可用的API。在具体示例中,源系统中的元数据(其可以是原生元数据或以通用格式存储的元数据),可以针对暴露而被加标志,这可以触发API的创建。例如,可以针对暴露对具体实体加标志,并且与该实体相关的元数据可以经由一个或多个API来暴露,并且可以可选地触发基本元数据到标准格式的转换。
在某些情况下,不同的源系统可能通过不同的接口使得数据和元数据可用。例如,一个系统可能具有SQL API,而另一个系统可能具有OData API。本公开提供了源系统可以包括API目录的技术,其中API目录包含由源系统提供的API的标准格式的描述。
为了促进模型的存储、检索和比较,可以在表示之间转换模型。例如,模型可以在字符串或类字符串表示(例如,保存SQL查询文本的字符串)和结构化表示,诸如编程语言(包括标记语言)表示(例如,复杂、复合或抽象数据类型的实例,例如类的实例)或独立于平台但结构化的格式之间转换。例如,字符串表示可以是用于定义诸如表格和视图之类的数据库对象的SQL DDL语句。可以解析该字符串以生成结构化表示。
结构化表示可以是这些语句在关系格式中的表示,诸如在一个或多个表格中的表示。例如,一实体(表格)可以存储表格字段的定义,且另一实体(表格)可以存储WHERE和JOIN条件之类的特征。结构化格式还可以包括诸如XML、JSON或CSON(德国沃尔多夫的SAP,SE的核心模式对象记法,也称为CSN或核心模式记法)的格式。然而,在某些情况下,格式转换可以包括不同结构化格式之间的转换,诸如从诸如XML、CSON或JSON之类的结构化格式到关系格式的转换,反之亦然。
在某些情况下,当数据库工件首次在目标系统上实例化或与目标系统相关联时,可以检索来自源系统的元数据。在其他情况下,可以检索补充数据库工件的现有元数据的元数据。例如,在一些情况下,标准内容被提供给与标准元数据相关联的客户端。客户端可能希望扩展该内容,并且可能已经在目标系统上这样做了。所公开的技术可以从源系统检索标准元数据的扩展,而不是让客户端在目标系统上重新创建这样的内容。
示例2促进元数据标识和导入的示例计算环境
图1图示了促进元数据检索的示例计算环境100。计算环境100包括源系统104和目标系统108。目标系统108被示为与数据库112通信。虽然数据库112被示为与目标系统108分离的组件,但是在一些实现方式中,数据库可以是目标系统108的一部分。在进一步的实施例中,计算环境100不需要包括数据库112。例如,所公开的技术可以促进元数据检索,但是该检索不需要与在数据库112中创建数据库工件相关联。
源系统104包括元数据储存库116。元数据储存库116包括元数据,诸如描述由源系统104维护或可由源系统104访问的数据(诸如在关系数据库表格(未示出)中维护的数据)的元数据。元数据的示例是描述数据的数据类型或语义信息的元数据,诸如指示数据库表格的具体值集(诸如具体列/字段)何时表示货币、电话号码、社会保险号等的信息。元数据可以指示具体字符串值的语言(例如,德语或英语),或者可以提供关于具体数字的具体计算的细节(例如,如何计算具体的KPI)。
在一些情况下,元数据储存库116中的元数据可以以在源系统104外部不容易消耗的格式来维护,或者甚至由源系统的不同应用来维护。相应地,源系统104可以包括转换器120。转换器120可以在格式之间转换元数据,包括在应用特定格式和诸如CSN、JSON或XML之类的标准化/输送/交换格式之间转换元数据。
在一些情况下,转换器120仅在被特别请求时,诸如响应于来自目标系统108的请求,才转换元数据储存库116中的元数据。元数据遍历组件124可以被解析框架128调用。元数据遍历组件124可以检索特定的元数据,或者可以确定什么元数据与请求相关。例如,元数据请求可以指定具体的数据库对象(或工件,例如表格、视图、列或行),并且解析框架128可以确定什么元数据与该数据库对象相关。在某些情况下,与具体请求相关的元数据可以与多个数据库对象相关联。例如,表格可以通过诸如外键之类的正式关系或如从德国沃尔多夫的SAP SE可获得的产品中实现的关联而彼此相关。解析框架128可以诸如通过遵循外键关系或关联来确定相关的数据库对象和相关的元数据。
元数据储存库116、转换器120或元数据遍历组件124中的一个或多个可以是元数据提供者框架126的一部分。
在一些情况下,解析框架128可以访问一组范围界定功能132。范围界定功能132可用于帮助确定元数据遍历组件124的操作。范围界定功能132可以包括图遍历算法,诸如确定传递壳(transitive hull)的算法。在某些情况下,范围界定功能可以指定范围包括与所选实体或与维度视图相关的所有层级视图、相关维度视图、与维度视图相关联的文本视图以及可选地所指定的间接级别内的附加维度视图。或者范围界定功能可以包括确定遍历范围的参数,诸如检索具体星型模式的所有相关或指定的元数据,检索具体视图和该视图引用的所有表格或视图的所有元数据,或者检索一个或多个指定的/相关数据库工件和指定的间接级别内的工件的所有或选择的元数据。
虽然在源系统104中示出了范围界定功能132,但是代替在源系统中实现的范围界定功能132或者除了在源系统中实现的范围界定功能132之外,范围界定功能可以在目标系统108中实现。
元数据暴露服务136可以访问解析框架128,元数据暴露服务136进而可以与目标系统108的导入管理器144通信。元数据暴露服务136可以接受来自导入管理器144的元数据请求,并将它们传递给解析框架128,可选地具有可能由目标系统108指定任何范围界定参数。
源系统104可以包括与元数据储存库116通信的搜索服务140。搜索服务140可以传送元数据储存库116中可用的全部或部分元数据。搜索服务140可以允许目标系统108指定返回来自元数据储存库116的相关结果的搜索项(例如,字符串、字符串的部分),以指定要返回的具体数据库对象、数据库对象的部分(例如,列)或数据库对象的集合(例如,指定具体模式),或者搜索项和数据库对象规范的组合。
搜索服务140诸如通过用户接口148与目标系统108通信。用户接口148允许用户或应用输入搜索参数,并呈现作为响应的搜索结果。在一些情况下,用户接口148允许用户浏览元数据储存库116/通过元数据储存库116导航。用户接口148还与导入管理器144通信,从而允许用户或应用指定检索元数据的请求以及可选地搜索请求的参数,诸如元数据遍历组件124要使用的范围界定功能。在其他情况下,范围界定功能位于目标系统108处,并且导入管理器144根据目标系统108的范围界定功能向元数据暴露服务136发出请求。
用户接口148还可以与连接管理器152通信,其中连接管理器还可以与导入管理器144通信。连接管理器152可以存储用于访问源系统104的参数,诸如存储源系统的网络位置、登录信息、用户凭证等。至少在某些情况下,可以通过用户接口148提供通信参数。在其他情况下,通信参数可以从另一个源中检索,诸如从目标系统108的配置信息中检索,例如从与目标系统的具体应用相关联的配置信息中检索。导入管理器144可以从连接管理器152检索连接信息,以在连接到源系统104的元数据暴露服务136时使用。
目标系统108包括元数据储存库156。元数据储存库156存储元数据,包括从一个或多个源系统104接收的元数据。元数据可以以从源系统104接收的格式(例如,CSN、XML)存储,或者可以被转换成目标系统108使用的一种或多种格式,诸如将数据存储在关系数据库表格中,或者将元数据存储在抽象或复合数据类型的实例中(例如,在逻辑数据对象中,诸如BusinessObjects),或者存储在数据字典(诸如,ABAP数据字典)中,或者作为虚拟数据模型的元素(例如,CDS视图),诸如在从德国沃尔多夫的SAP,SE可获得的软件中实现的。
元数据储存库156还可以诸如利用CRUD(创建读取更新删除)组件158来管理元数据的改变。元数据储存库156可以管理从源系统104接收的元数据和在目标系统108中存储的元数据之间的冲突。例如,如果在元数据初始被传输到目标系统108之后在源系统104上更新了元数据,或者如果在从源系统导入之后在目标系统上更新了元数据,则可能会出现冲突。冲突解决方案可以包括应用规则,诸如指定将应用最近的改变,或者指定源系统104或目标系统108版本将优先于另一个版本。
元数据储存库156还可以包括预部署组件160,在其他实现方式中,预部署组件160可以是目标系统108的另一组件的一部分,或者可以被实现为目标系统的单独组件。预部署组件160可以与部署组件164通信。在向部署组件164发送请求之前,预部署组件160可以创建合适的工件(例如,表格、复合或抽象数据类型的实例、虚拟数据模型中的工件、或者对现有表格、数据类型或工件的更新/修改)来存储导入的元数据。预部署组件160可以执行其他功能,诸如编辑要导入的元数据。例如,要导入的元数据的初始规范可能包括悬空引用(dangling reference),诸如对低于为导入指定的阈值粒度的、未被暴露用于导出的元数据或数据库工件的引用,或者对由元数据描述的数据而不是元数据本身的引用。预部署组件160可以分析初始导入规范(诸如来自导入管理器144,进而从元数据暴露服务136接收的),并检测和移除这样的悬空引用。
预部署组件160可以通过调用部署组件164来发起元数据以及可选地相关联的数据的传输。在具体实现方式中,部署组件164使得在数据库112中创建表格或视图,并且导入与该表格相关联的元数据。所创建的表格或视图可被实现为数据库112中的独立表格,或者可被实现为被标识为引用外部表格(例如,存储在源系统104中或可由源系统104访问的表格)的表格。被标识为引用源系统104的表格可以被实现为从与源系统相关联的表格中检索数据的表格,或者可以被链接到这样的表格,其中当被请求时在运行时动态检索数据。引用源系统104的数据库表格的具体实现方式可以是在从德国沃尔多夫的SAP SE可获得的软件中实现的构造虚拟表格。构造虚拟表格可以被设置为接收和存储从源系统104复制的数据的本地表格,或者被设置为所请求的数据在请求时在运行时被动态获取的联合表格。
数据库112可以包括数据库对象180a、180b、180c,诸如表格或视图。数据库对象180a可以表示纯粹的本地数据库对象(例如,相对于目标系统108是本地的)。数据库对象180b可以表示与源系统104的数据库对象184相关联的数据库对象,其中数据被复制到并存储在目标系统108的数据库对象180b中。数据库对象180c可以表示与数据库对象184相关联的数据库对象,但是其中数据是在请求时经由联合从数据库对象184获得的,而不是预期地将数据存储在数据库对象180c中。
示例3-元数据标识和检索中的示例操作
图2A是客户端204请求来自目标系统的元数据的方法200的时序图。方法200可以在图1的计算环境100中实现,其中客户端204可以表示目标系统108的一个或多个组件,诸如用户接口148或导入管理器144。使用可以分别对应于图1的对应组件108、136、128、132、126的客户端204(例如,目标系统的组件)、元数据暴露服务206、解析组件208、一个或多个范围界定功能210和元数据提供者212来执行方法200。
在214,客户端204向元数据暴露服务206提供元数据请求,诸如通过指定具体的数据库工件或其元素,诸如指定具体的模式、表格或视图。在216,元数据暴露服务206将该请求传递给解析组件208。在218,解析组件208调用范围界定功能210来确定与由客户端204指定的数据库工件相关的实体类型。在一些情况下,要使用的范围界定功能210的标识符被包括在来自客户端204的请求中,或者该请求包括要应用的范围算法。在其他情况下,解析组件208确定要应用的范围界定功能210,包括在来自客户端204的请求未指定范围界定功能的情况(以及解析组件208使用的范围界定功能210可以是默认功能的情况)。在220,范围界定功能210将相关实体返回给解析组件208。
在222,解析组件208向元数据提供者212发送应检索其元数据的实体的标识符,可选地标识这种元数据的子集(例如,仅具体的元数据字段)。在224,元数据提供者212返回那些标识符以及附加相关实体的标识符。方法200可以在218-224循环,直到不再标识出相关实体,此时该方法可以前进到226。
在226,解析组件208向元数据暴露服务206发送具有相关元数据的数据库工件的标识符。在228,元数据暴露服务206向解析组件208发送转换在218-224标识出的所有或所选择的数据库工件的元数据的请求。在一些情况下,解析组件208包括图1的转换器120,在其他情况下,将请求发送到转换器,而不是将转换元数据的请求发送到解析组件。在又一示例中,转换请求首先被发送给解析组件208,然后解析组件将该请求发送给转换器120。
在230,解析组件208(或转换器120)向元数据提供者212发送对相关元数据的请求。在232,元数据提供者212将元数据返回给解析组件208(或转换器120)。在234,解析组件208(或转换器)将从元数据提供者212接收的元数据转换成诸如标准或可串行化格式,诸如CSN或XML。在236,将转换后的元数据从解析组件208发送到暴露服务206。在238,暴露服务206将转换后的元数据返回给客户端204。在另一个实现方式中,在236,将与转换后的元数据相关联的数据库工件的列表发送到客户端204,但不发送实际的元数据本身。在这种情况下,客户端204可以稍后请求与这些数据库工件相关联的全部或部分实际元数据。
图2B图示了导入过程240,其可以包括过程200。使用客户端242(诸如目标系统,其可以是基于云的系统)、导入向导244(其可以是图1的导入用户接口148的一部分)、导入管理器246(其可以是导入管理器144)、元数据储存库248(诸如元数据储存库)、部署服务250(其可以是部署组件164)以及本地或源系统252(诸如图1的源系统104)来执行该过程。
在254,客户端通过导入向导244提交导入请求,诸如提供要导入的数据库工件的一个或多个标识符,或者提供搜索标准来标识这样的工件。在256,导入向导244将该请求传递给源系统252。该请求可以由源系统252的元数据传输框架来处理,诸如元数据暴露服务136(其进而可以与解析框架128、范围界定功能132或元数据框架126通信)。
在258,源系统252返回相关数据库工件的标识符,诸如使用范围界定功能132确定的工件的标识符。在260,导入向导244调用导入管理器246来检索与在258返回的至少一部分数据库工件相关联的至少一部分元数据。
在262,导入管理器246向源系统252发送对指定的元数据的请求,在264,该指定的元数据被返回给导入管理器246。在266,导入管理器246将元数据保存到储存库248。在268,储存库248将控制返回给导入管理器246,可选地包括保存是否被成功执行的指示。
在270,导入管理器246请求部署服务250部署元数据,这可以包括将元数据链接到目标系统的数据库工件、或者创建和/或填充软件对象,诸如具有元数据的抽象或复合数据类型的实例。在272,部署服务250将控制返回给导入管理器246,可选地具有元数据是否被成功部署的指示。在274,导入管理器246将控制返回给导入向导,可选地,具有早期操作是否被成功执行的指示,包括标识可能已经发生的任何错误,并且进而在276,导入向导244将控制/该信息返回给客户端242。
过程200和240或与其类似的过程(例如,包含来自这些过程中的一者或两者的一个或多个步骤)可以用于基于检索的元数据自动生成数据库工件的过程中,以及将生成的数据库工件链接到用于描述数据库工件的元数据和针对数据库工件存储在源系统中的数据。图2C提供了这种过程的示例,如过程280所示。在282,用户或过程选择用于导入的元数据。元数据可以是与一个或多个数据库工件相关联的所有元数据,或者这种数据的一部分。通常,元数据至少包括足够的元数据来描述源系统的数据库工件的模式,诸如表格或视图中的列、这些列的名称或标识符、以及与这些列相关联的数据类型。
在284,诸如由图1的导入管理器144或用户接口148接收元数据。在286,根据导入的元数据在目标系统处创建数据库工件,其中数据库工件可以被创建为本地工件,或者被创建为链接到源系统上的数据库工件的虚拟工件(例如,通过数据复制或联合)。
在288,在目标系统上创建的数据库工件被链接到源系统上的对应数据库工件。例如,用于获得数据库工件的数据的源系统上的API可以使用图1的元数据暴露服务136来定位,并且链接到目标系统上的数据库工件。在290,目标系统可以使用API来从源系统获得目标系统上的数据库工件的数据和可选的附加元数据。
一种或多种数据类型,诸如抽象或复合数据类型,可以用来帮助实现过程280。例如,抽象数据类型可以被定义以表示数据库工件,并且可以包含可用于获得数据库工件的数据或元数据的信息。数据类型可以包括存储API位置的数据成员或存储API类型的数据成员。当数据库工件需要元数据或数据时,可以调用针对具体数据库工件的数据类型的实例的方法。该方法可以调用源系统上的API来检索所请求的信息。
可以通过具有诸如以标准格式描述源系统中可用于从所标识的数据库工件中检索数据/元数据的API的信息,来促进从源系统中检索数据/元数据。因此,所公开的技术可以帮助避免由于API未知而无法在源系统上为数据库工件检索数据/元数据的情况。类似地,具有API的储存库/库可能有助于避免因具有不同类型的API而可能产生的问题。该库可以用于定位适当的API,并且为该API存储的类型信息可以帮助确定用于从该API获得数据的适当方法(例如,表示导入的数据库工件的抽象数据类型的实例可以调用不同的API/导入方法,这取决于对于源系统的给定数据库工件,在源系统上可以获得什么样的API来获得数据)。
在某些情况下,对于源系统的数据库工件,可以有一种检索数据的方法和一种单独的检索元数据的方法,而在其他情况下,可以使用单个方法来获得数据和元数据二者。数据类型的实例可以充当具体数据库工件和源系统中维护的关于工件的信息之间的链接。在具体的实现方式中,当在目标系统中创建数据库工件,或者至少是使用公开的技术创建的数据库工件时,自动创建用于将数据库工件链接到源系统中的数据/元数据的数据类型的实例。
在一些情况下,所公开的技术可以用于创建单个数据库工件。然而,在其他情况下,公开的技术可以用于创建多个数据库工件。也就是说,例如,源系统处的数据库工件的标识符、或搜索标准,可以用于标识源系统中的多个相关的数据库工件(诸如使用范围界定功能)。可以使用来自源系统、链接到适当的API的元数据以及从源系统检索并填充到目标系统的数据和/或附加元数据,在目标系统处创建数据库工件。
如果需要,所公开的技术可以以不同的方式实现。例如,在某些情况下,不是在抽象或复合数据类型的实例中存储导入的数据库工件的信息,而是可以将这样的信息存储在关系数据库表格中。例如,表格可以具有带有数据库工件标识符的字段、带有API位置标识符的字段和带有API类型标识符的字段。导入过程/组件可以访问数据库表格以确定如何检索工件的数据/元数据,并且该表格因此可以充当数据库工件和源系统中的数据/元数据之间的链接。
本公开可以提供用于基于作为源系统的数据工件在目标系统创建数据工件的技术,诸如过程280。具体而言,所公开的技术可以允许在目标系统自动创建数据库工件,并且自动从源系统导入相关联的数据和元数据。因此,用户无需手动执行任何动作(除了提供初始导入标准),就可以使得数据库工件对于该用户快速可用。
元数据暴露服务136的使用可以帮助促进数据库工件创建过程的自动化,因为它可以帮助定位用于获得数据/元数据的API,并提供关于如何能够访问数据/元数据的信息(例如,协议/API类型)。解析框架能够帮助确保获得相关元数据,并可用于创建可能与用户的请求相关的数据库工件。也就是说,用户可以指定单个数据库工件,或搜索标准,并且所公开的技术可以导致在目标系统处针对源系统中的相关数据库工件创建一个或多个数据库工件(例如,如范围界定功能所确定的),以及用来自源系统的对应数据/元数据填充目标系统。
示例4促进元数据发现和交换的示例软件对象
图3图示了关于源系统上具有元数据或与元数据相关联的具体数据库工件的信息如何能够被暴露给目标系统。源系统可以提供用于获得关于数据库工件的信息的API。API可以采用不同的格式,在不同的源系统之间,或在单个源系统内。例如,API可以以OData格式、SQL格式或一些其他格式实现。
图3图示了以SQL格式表达的API 310的一部分。注意,SQL格式API310指定了具体的数据库工件314,在这种情况下是视图“产品(product)”。数据库工件314由模式名称和实体名称指定。
图3还图示了API 310的标准化表示320。标准化表示320包括标识符322,并包括对API的引用324(例如,以URI的形式)。标准表示320可以具有类型326,其可以指示被引用/源API 310所使用的协议,诸如API是SQL API还是OData API。标准表示320可以具有元素330,其可以标识API 310的一个或多个用例,诸如该API是否旨在用于ETL过程、用于不同类型的过程、或者可以用于一般的元数据发现和检索。类似地,标准表示320可以指定覆盖范围的具体类型或级别332,其可以指示元数据的哪个部分已经可用于数据库实体。
在所示的示例中,已经指定了单个数据库工件314。在其他情况下,单个表示320可以指定多个数据库工件,其中对于不同的数据库工件,覆盖范围可以是相同的或不同的。
图3还示出了数据库工件314的标准化表示330,以及工件的元数据332。标准化表示330中的数据和元数据可以使用SQL API 310来暴露,使用标准化API表示320可以使得关于其的信息可获得。标准化表示330包括数据库工件的标识符314,并且该标识符被包括在标准API表示320中。以这种方式,标准API表示320将具体的数据库工件与可用于获得数据库工件的数据的SQL API 310联结起来,并通过到表示330(其进而可以从源系统上的元数据的原生表示中生成)的链接而将与数据相关联的元数据联结起来。
注意,一般来说,元数据的标准化表示和可以从中检索数据(并且与元数据相关联)的具体实体的标准化表示可以是标准化格式。也就是说,元数据和数据库实体信息可以以通用格式表示,而不管元数据或数据的实际存储格式或者用于访问这种数据或元数据的协议(例如,API类型)如何。相应地,如果对应于API 310的API是不同的格式(例如,OData),则标准化API表示320可以具有不同的标识和类型信息,但是标准表示的整体结构可以是相同的(例如,具有相同的字段或键)。以相同的方式,具体实体的数据可以在实体的标准化表示330和标准化API表示320两者中用通用格式来表达,这可以促进目标系统找到关于可用于获得与源系统上的具体数据库实体相关联的数据或元数据的API的信息和数据库工件。
示例5示例元数据暴露服务
图4图示了可以使用可以是图1的元数据暴露服务136的元数据暴露服务404暴露的信息。
元数据暴露服务404可以提供关于实体408的信息,其可以是诸如表格或视图之类的数据库工件。用于实体408的信息可包括实体的名称或标识符(诸如参照以诸如CSN或XML的可串行化格式表达的实体)、实体的语言相关描述、可选地发布合同(其可用于帮助维护可与具体合同标识符一起使用的一组实体,其可用于帮助确保选择正确的一组实体,诸如保持该组实体相对于诸如应用尚未被更新以使用的改变之类的不兼容的改变是稳定的)、发布状态(诸如该实体是否已发布、过时、停用、尚未发布等),以及指示实体何时最后被修改的信息。可选地,可以包括其他信息,诸如实体何时被首次创建,或者创建或最后更新实体408的用户、过程或应用的标识符。
实体408可以与建模模式412相关联。建模模式412可用于指示具体实体408被用于做什么。在一些情况下,诸如视图之类的实体408可以具有主要目的,其可以由建模模式412来指示。可选地,建模模式412可以列出给定实体408的多种用途,其中在一些情况下,给定用途可以被标注为主要用途。
实体408还可以与源416相关联,其中源可以是实体的标准化(例如,CSN、XML)表示(例如,实体的定义或内容)。在一些情况下,实体408的源416可以包括语言特定的内容。这样的内容可以被保存为本地化数据420,其中本地化数据可以通过在具体实体40上进行导航来检索。
元数据暴露404可以与上下文424相关联。上下文424可用于标识元数据,诸如属于特定储存库或应用的元数据。也就是说,上下文424可以提供名称空间信息,或者用于与名称空间信息类似的目的。上下文424可以包括附加信息,诸如实体408的标签或描述。
元数据暴露404可以与类型428相关联。类型428可用于标识实体408的具体类型(例如,视图、表格、列、存储的进程等),并且还可以包含该类型的定义信息(例如,模式信息,诸如与给定类型相关联的具体元数据元素,本质上提供了具体类型的结构或定义)。可以使用类型428或将其与具体的源416相关联,并且进而可使其被本地化数据420引用(例如,与该类型相关的具体语言的信息,诸如该类型的语言相关描述)。
如已经描述的,通常希望不仅获得单个实体408的元数据,而且获得相关实体的集合的元数据。因此,元数据暴露404的给定实体408可以链接到范围中的实体432,这提供了相关实体的列表。相关实体可以包括相关实体408的完整列表,或者这些实体的较小子集。范围界定功能可用于定义范围中的实体432,可用的范围界定功能可由范围436提供。
元数据可以用不同的方式指定,包括通过注释(例如,CSN中的注释)。词汇表440可以提供各种注释的定义。
场所444可以存储关于与元数据暴露服务404相关联的具体场所的信息,诸如在本地化数据420中表示的场所。场所444可用于例如按位置过滤与元数据暴露404相关联的数据。
示例6具有数据库工件扩展的示例计算环境及其示例
在某些情况下,所公开的技术,如元数据暴露服务,可用于在数据传输至目标系统时,从源系统检索元数据,作为独立的本地表格、具有从源系统复制的数据的本地表格、或虚拟表格,其中当在目标系统处请求时,从源系统检索虚拟表格的数据(例如,响应来自目标系统的对与目标系统相关联的数据库的查询)。然而,所公开的技术可以用在其他场景中。具体而言,所公开的技术可以用于用客户特定的内容来扩充标准内容。例如,在安装或升级了标准数据库模式之后,可以从客户端的数据库系统中检索对这些内容的扩展。
图5图示了可实施所公开技术的计算环境500。计算环境500包括中央数据库系统504,在一些实现方式中,中央数据库系统504可以是基于云的数据库系统。中央数据库系统504可以包括标准内容508,诸如数据库工件512、514,其中数据库工件可以是表格或视图。标准内容508可以是例如与特定应用或一组应用相关联的内容,并且通常所有或大部分内容与许多客户端相关。标准内容508可以从包518安装,并且可以使用更新522(也可以被实现为包)来更新或升级。
在某些情况下,客户端可以修改标准内容508的全部或一部分。在其他情况下,标准内容508被保护免受客户端修改,尤其是如果标准内容被多个客户端共享,或者如果标准内容的修改可能导致应用功能的损失。如果标准内容508不可由客户端修改,则在一些实现方式中,它可以由客户端扩展。也就是说,标准内容508的数据库工件可以被“锁定”,但是客户端可能能够创建添加到标准数据库工件或更改标准数据库工件的其他数据库工件。
图5示出了包括租户(tenant)526a、526b的计算环境500。在一些情况下,租户526a、526b经由共享容器530访问标准内容508,如针对租户526a所示(其中租户容器未被示为包括工件512、514)。在其他情况下,租户容器可以包括标准内容508的工件,诸如针对租户526b所示,该容器包括工件512。
租户容器被示为包括对工件512的扩展534a、534b。扩展534a、534b可以对工件512进行各种修改,诸如添加、移除或改变工件的数据或元数据。作为对数据的改变的示例,扩展534a可以向由工件512表示的视图或表格添加列。例如,工件512可以表示雇员的数据,具有姓名、社会保险号、作业标识符、工资率等字段。鉴于2020年开始的COVID-19大流行,以及2020-2021年引入的疫苗,雇主可能希望跟踪雇员是否已经接种疫苗、雇员接种疫苗的日期等。由于各种原因,在经由标准内容508将指示雇员是否接种疫苗的标志被引入工件512之前可能需要时间。客户端(由租户526a、526b表示)可以包括扩展534a、534b,其将接种疫苗的标志添加到工件512。在一些情况下,基于标准内容508和为客户端定义的/由客户端定义的任何扩展来创建用于具体客户端或租户的工件。例如,可以通过将工件512与扩展534a或534b组合或合并来创建工件542(例如,使用DDL语句)。
在一些实现方式中,针对扩展的数据从客户端系统550导入,并存储在租户526a、526b的容器中,或以其他方式存储在中央数据库系统504中。在其他情况下,将数据存储在计算环境500的另一组件中,或者作为工件创建过程的一部分从客户端系统550获得数据,但是不将其存储在客户端系统550之外。
可使用元数据基础设施552从相关客户端系统550获得扩展534a的元数据。元数据基础设施552可以包括图1的源系统104的组件116-140。客户端系统550可以包括数据库工件556,其可以对应于源系统104的数据库对象184。在图1中,一个或多个数据库对象可以是数据库工件,其通过将数据库工件的标准定义与为与该数据库工件一起使用而创建的扩展进行组合或合并而产生。也就是说,数据库对象184可以对应于数据库工件542。
元数据基础设施552包括工件512的元数据554和对工件552的扩展的元数据556。元数据554、556可以用于描述,并且在至少一些实现方式中创建工件558。
可通过与关于图1所讨论的类似的方式从客户端系统550中检索扩展数据。也就是说,中央系统504或与中央系统通信的目标系统558可以包括类似于图1的组件144-168的组件。在一些实现方式中,组件148-168的一部分可以从计算环境500的用例中省略。例如,当安装、更新或升级标准包时,当系统自动尝试检索客户端特定信息时,可以省略导入UI148。
用于从客户端系统550获得信息的逻辑可大致类似于图2的方法200。然而,这种方法可以可选地从方法200中移除步骤,或者可以添加步骤。如所讨论的,可以省略从用户接口接收要导入的元数据/数据工件的输入的步骤。可以添加检查对标准内容508的数据库工件进行扩展的客户端系统550的步骤。如果对于具体的数据库工件不存在扩展,则不需要采取进一步的动作。如果存在扩展,则相关元数据可以被检索并用于定义数据工件542,并且元数据可以可选地存储在租户526a、526b的容器中。
在某些情况下,可多次从客户端系统550获得元数据。例如,当客户端“在机”时,并且响应于客户端做出的后续更新/改变,可以获得元数据。
更新服务560可用于确定应发送什么元数据,这可包括选择单一版本的元数据或分层多个版本的元数据。更新服务560可以应用各种规则562,这些规则可以包括优先规则。例如,优先规则可以指定使用元数据工件的最新版本。或者,优先规则可以指定应如何组合多个元数据版本,诸如用较晚的版本所做的改变来覆写来自较早版本的元数据元素,其中通常在与较早版本冲突的情况下将应用最晚版本的改变。来自基本版本的未被修改的元数据元素将以其最初形式包含在最终元数据中。在其他情况下,优先规则可以指定至少某些元数据是附加的。例如,如果元数据被指定为值的数组或枚举列表,则规则可以指定值是否被添加或覆写。元素是否被添加或覆写可以取决于元数据元素的性质,因此如果适当的话,可以以具体元数据元素的粒度指定规则。
客户端系统550可包括日志记录组件564。日志记录组件564可以包括改变列表566,其可以标识应该被导入的元数据,因为它还不存在于中央数据库系统504或目标系统558中,或者自从上次导入以来已经被改变。改变列表566还可以具体指定要导入什么元数据,诸如应用规则562的结果。改变日志568可用于跟踪元数据从客户端系统550到中央数据库系统504或目标系统558的传输进度,如跟踪失败的事务和错误消息,使得可以确定传输是否如预期/指示的那样完成。在一些情况下,代替将改变日志568包括在客户端系统550中,可以将其包括在中央数据库系统504或目标系统558中,或除了将其包括在客户端系统550中之外,还可以将其包括在中央数据库系统504或目标系统558中。
图5还以工件512的内容570和扩展534a的内容580的形式图示了标准内容508和对这种标准内容的扩展的示例。内容570包括数据的选择572,其包括数据元素574a、574b。数据的选择572可以是查询,诸如SQL查询。内容570可以包括元数据元素576a、576b,诸如提供关于数据元素574a、574b的语义信息的元素。内容570可以进一步包括注释578a、578b、578c,其中注释可以指示工件512的特性或者控制工件的使用,诸如定义工件是否暴露给最终用户。
扩展534的内容580可以添加、移除或更改内容570的数据元素,并可以添加或修改内容570的注释。如所示的,内容580包括修改注释578a的注释582a、设置注释578c的值为NULL的注释582b,以及已经被添加到内容570的注释582c。由于注释578b没有被移除或修改,当工件与工件扩展580合并时,该注释将存在于工件570中。
至少在某些情况下,数据元素和元数据可以与注释类似的方式处理。工件扩展580示出了元数据元素584a已经被添加到内容570,并且已经通过使用元数据元素584b将元数据元素576b的值设置为NULL而移除了元数据元素576a。内容580可以包括附加的数据元素或数据元素的附加选择588,或者可以移除数据元素,诸如内容580中的将数据元素576a的值设置为NULL的语句590。
示例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”的名称。然而,由于名称或标识符用于定位/区分该字段和另一个字段,在本公开的上下文中,它被认为是技术信息,而不是语义信息,即使它可以容易地向人传达含义。在至少一些实现方式中,语义信息的使用是可选的。例如,即使使用数据字典,在数据库对象(诸如表格,但也可能是其他对象,其中这些其他对象通常与底层关系数据库系统中的一个或多个表格相关联)中使用的一些字段可以在不使用语义信息的情况下被指定,而其他字段与语义信息相关联。
图6是图示与驾驶员事故历史相关的数据模式600或元数据模型的示例实体-关系(ER)类型图。模式600(其可以是更大模式的一部分,其他组件未在图6中示出)可以包括与执照持有者(例如,具有驾照的个人)相关联的表格608,与执照相关联的表格612,表示事故历史的表格616,以及表示汽车(或其他车辆)的表格604。
表格604、608、612、616中的每一个均具有多个属性620(尽管,在某些情况下,表格可能仅具有一个属性)。对于具体的表格604、608、612、616,一个或多个属性620可以充当主键——唯一地标识元组中的具体记录,并且被指派为访问表格中元组的主要方法。例如,在表格604中,Car_Serial_No属性620a充当主键。在表格616中,属性620b和620c的组合一起充当主键。
表格可以通过使用外键来引用与另一个表格的主键相关联的记录。例如,执照号码表格616具有表格616中的作为外键并且与表格604的对应属性620a相关联的Car_Serial_No的属性620d。外键的使用可以用于各种用途。外键可以链接不同表格中的具体元组。例如,属性620d的外键值8888将与表格604中针对属性620a具有该值的具体元组相关联。外键也可以作为约束,其中不能创建具有(或被更改为具有)在作为被引用表格中的主键值不存在的外键值的记录。外键也可以用于维护数据库一致性,其中对主键值的改变可以传播到属性是外键的表格中。
表格可具有其他属性或属性组合,其可用于唯一地标识元组,但它们不是主键。例如,表格616具有由属性620c和属性620d形成的替换键。因此,可以使用主键(例如,作为另一个表格中的外键)或者通过与该替换键的关联来访问表格616中的唯一元组。
模式信息通常在数据库层中维护,诸如与维护表格值的位置相关联的软件层(例如,在RDBMS中),并且通常包括表格604、608、612、616的标识符,及其他们相关联属性620的名称626和数据类型628。模式信息还可以包括至少一些使用标志630可传达的信息,诸如字段是否与主键相关联,或指示外键关系。然而,包括更多非正式关联的其他关系可能不包括在与数据库层相关联的模式(例如,PostgreSQL的INFORMATION_SCHEMA)中。
示例8-包括语义标识符的示例表格元素
图7是图示数据库模式700的元素以及它们可以如何相互关联的图。至少在某些情况下,可以在数据库系统的数据库层之外维护数据库模式700。即,例如,数据库模式700可以独立于底层数据库,包括用于底层数据库的模式。通常,数据库模式700被映射到数据库层的模式(例如,图6的模式600),使得记录或其部分(例如,具体字段的具体值)可以通过数据库模式700来检索。
数据库模式700可包括一个或多个包710。包710可以表示用于对模式700的其他元素进行分类或归类的组织组件。例如,包710可以被复制或部署到各种数据库系统。包710还可用于实施安全限制,诸如通过限制具体用户或具体应用对具体模式元素的访问。
包710可与一个或多个域714相关联(即,具体类型的语义标识符或语义信息)。反过来,域714可以与一个或多个包710相关联。例如,域1,714a仅与包710a相关联,而域2,714b与包710a和包710b相关联。在至少一些情况下,域714可以指定哪些包710可以使用该域。例如,可能是与制造过程中使用的材料相关联的域714可以被过程控制应用使用,但是不能被人力资源应用使用。
在至少一些实现方式中,尽管多个包710可访问域714(和合并该域的数据库对象),但域(和可选地其他数据库对象,诸如表格718、数据元素722和字段726,在下文中更详细地描述)主要分配给一个包。将域714和其他数据库对象分配给唯一的包可以帮助创建数据库对象之间的逻辑(或语义)关系。在图7中,将域714分配给包710示出为实线,而访问许可示出为虚线。因此,域714a被分配给包710a,而域714b被分配给包710b。包710a可以访问域714b,但是包710b不能访问域714a。
注意,至少某些数据库对象,诸如表格718,可包括与多个包相关联的数据库对象。例如,表格718(表格1)可被分配给包A,并具有被分配给包A、包B和包C的字段。表格1中分配给包A、包B和包C的字段的使用创建了包A和包B以及包C之间的语义关系,如果字段与具体域714相关联,则该语义关系可被进一步解释(即,域可以为与另一包的对象相关联(而不是被分配给通用包)的数据库对象提供进一步的语义上下文)。
如将更详细地解释的,域714可表示最细粒度的单元,可从该单元构建数据库表格718或其他模式元素或对象。例如,域714至少可以与数据类型相关联。每个域714与唯一的名称或标识符相关联,并且通常与描述相关联,诸如提供该域的语义含义的人类可读文本描述(或者可以与人类可读文本描述相关的标识符)。例如,一个域714可以是表示电话号码的整数值,而另一个域可以是表示零件号码的整数值,而又一个整数域可以表示社会保险号。因此,域714可以跨模式700保持提供通用且一致的使用(例如,语义含义)。也就是说,例如,每当使用表示社会保险号的域时,即使字段或数据元素对于不同的表格具有不同的标识符或其他特性,对应的字段也可以被辨别为具有该含义。
模式700可包括一个或多个数据元素722。每个数据元素722通常与单个域714相关联。然而,多个数据元素722可以与具体的域714相关联。尽管未示出,表格718的多个元素可以与相同的数据元素722相关联,或者可以与具有相同域714的不同数据元素相关联。除了其他之外,数据元素722可以用于允许为具体表格718定制域714。因此,数据元素722可以为表格718的元素提供附加的语义信息。
表格718包括一个或多个字段726,字段中的至少一部分被映射到数据元素722。字段726可以被映射到数据库层的模式,或者表格718可以以另一种方式被映射到数据库层。在任何情况下,在一些实施例中,字段726以某种方式映射到数据库层。或者,数据库模式可以包括等同于模式700的元素的语义信息,包括域714。
在一些实施例中,字段726中的一个或多个未被映射到域714。例如,字段726可以与原始数据成分(例如,与诸如整数、字符串、布尔值、字符数组等之类的原始数据类型相关联),其中原始数据成分不包括语义信息。或者,数据库系统可以包括其中不包括与域714相关联的任何字段726的一个或多个表格718。然而,所公开的技术可以包括模式700(其可以与数据库模式分离,或者并入到数据库模式中),该模式700包括多个表格718,这些表格718具有直接或通过数据元素722与域714相关联的至少一个字段726。
示例9示例数据字典组件
模式信息,诸如与图7的模式700相关联的信息,可存储在诸如数据字典的储存库中。至少在某些情况下,数据字典独立于底层关系数据库,但是被映射到底层关系数据库。这种独立性可以允许相同的数据库模式700被映射到不同的底层数据库(例如,使用来自不同供应商的软件或者来自同一供应商的不同软件版本或产品的数据库)。数据字典可以是持续性的,诸如被维护在存储的表格中,并且可以被整体或部分地维护在存储器中。数据字典的内存(in-memory)版本可以称为字典缓冲区。
图8图示了具有数据字典804的数据库环境800,该数据字典804可诸如通过映射访问数据库层808。数据库层808可以包括模式812(例如PostgreSQL中的INFORMATION_SCHEMA)和数据816,诸如与表格818相关联的数据。模式812包括各种技术数据项/组件822,其可以与字段820相关联,诸如字段名称822a(其可以对应于也可以不对应于该字段的目的的易于人类理解的描述,或者以其他方式明确描述该字段的值的语义含义)、字段数据类型822b(例如,整数、可变长字符串、字符串、布尔值)、长度822c(例如,字段中的值所允许的数字的大小、字符串的长度等)、小数位的数量822d(可选地,对于合适的数据类型,诸如对于长度为6的浮点数,指定值是否表示XX.XXXX或XXX.XXX)、位置822e(例如,表格中应该显示该字段的位置,诸如是第一个显示的字段、第二个显示的字段等),可选地,默认值822f(例如,“NULL”、“0”或某个其他值),指示该字段是否允许NULL值的NULL标志822g,指示该字段是否是表格的主键或在表格的主键中使用的主键标志822h,以及可以指示字段820是否与另一个表格的主键相关联的外键元素822i,以及可选地,由该外键元素引用的表格/字段的标识符。具体模式812可以包括比图8所示更多、更少或不同的技术数据项822。
表格818与一个或多个值826相关联。值826通常与使用技术数据元素822中的一个或多个定义的字段820相关联。也就是说,每行828通常表示唯一的元组或记录,并且每列830通常与具体字段820的定义相关联。表格818通常被定义为字段820的集合,并被赋予唯一的标识符。
数据字典804包括一个或多个包834、一个或多个域838、一个或多个数据元素842,和一个或多个表格846,其可以至少大体上分别对应于图7的类似命名的组件710、714、722、718。如在图7的讨论中所解释的,包834包括一个或多个(通常是多个)域838。每个域838由多个域元素840定义。域元素840可以包括一个或多个名称840a。名称840a用于在某些情况下唯一地标识具体的域838。域838包括至少一个唯一的名称840a,并且可以包括一个或多个可以是也可以不是唯一的名称。可以是也可以不是唯一的名称可以包括各种长度或详细程度的域838的名称或描述的版本。例如,名称840a可以包括可以用作域838的标签的文本,并且可以包括短、中和长版本,以及可以被指定为标头的文本。或者,名称840a可以包括主名称或标识符以及为域838提供人类可理解的语义的简短描述或字段标签。
在至少一些情况下,数据字典804可以多种语言存储名称840a的至少一部分,诸如使域标签对于多种语言可用。在所公开的技术的实施例中,当域信息用于标识表格或其他数据库元素或对象之间的关系时,包括搜索具体值,可以搜索多种语言的信息,诸如名称840a。例如,如果指定了“客户(customer)”,则可以搜索名称840a的德语和法语部分以及英语版本。
域元素840还可以包括至少与可包括在模式812中的信息相似的信息。例如,域元素840可以包括与相关数据类型相关联的数据类型840b、长度840c和小数位的数量840d,它们可以分别对应于技术数据元素822b、822c、822d。域元素840可以包括转换信息840e。转换信息840e可用于转换(或相互转换)为域838输入的值(可选地,包括由数据元素842所修改的)。例如,转换信息840e可以指定具有XXXXXXXXX形式的数字应该被转换成XXX-XX-XXXX,或者数字应该具有分隔各组数字的小数位或逗号(例如,将1234567格式化为1,234,567.00)。在一些情况下,多个域838的字段转换信息可以存储在储存库中,诸如字段目录中。
域元素840可包括一个或多个值限制840f。值限制840f可以指定例如允许或不允许负值,或者域838可接受的值的具体范围或阈值。在一些情况下,当试图将不符合值限制840f的值与域838一起使用时,可以提供错误消息或类似指示。域元素840g可以指定被允许使用域838的一个或多个包834。
域元素840h可指定记录与域元素838相关联的创建或修改事件的元数据。例如,域元素840h可以记录最后修改域元素840h的用户或应用的身份,以及修改发生的时间。在一些情况下,域元素840h存储域838的创建和修改的更大的历史,包括完整历史。
域元素840i可指定与域838(包括名称840a)相关联的最初语言。例如,当要确定名称840a是否应该转换成另一种语言,或者应该如何完成这种转换时,域元素840i可能是有用的。
数据元素842可包括数据元素字段844,数据元素字段中的至少一些可至少大体上类似于域元素840。例如,数据元素字段844a可以对应于名称域元素840a的至少一部分,诸如是(或包括)具体数据元素842的唯一标识符。相对于名称域元素840a描述的字段标签信息被示为分成短描述标签844b、中描述标签844c、长描述标签844d和标头描述844e。如针对名称域元素840a所描述的,标签和标头844b-844e可以用一种语言或多种语言来维护。
数据元素字段844f可指定与数据元素842一起使用的域838,从而将域元素840的特征并入数据元素中。数据元素字段844g可以表示数据元素842的默认值,并且可以至少类似于模式812的默认值822f。创建/修改的数据元素字段844h可以至少大体上类似于域元素840h。
表格846可包括一个或多个表格元素848。表格元素848的至少一部分可以至少类似于域元素840,诸如表格元素848a至少大体上类似于域元素840a或数据元素字段844a。描述表格元素848b可以类似于结合域元素840a,或者标签和标头数据元素字段844b-844e所描述的描述和标头标签。表格846可以使用表格元素848c与类型相关联。示例表格类型包括诸如在从德国沃尔多夫的SAP SE可获得的数据库产品中使用的透明表格、簇表格和池化表格。
表格846可包括一个或多个字段表格元素848d。字段表格元素848d可以定义具体数据库表格的具体字段。每个字段表格元素848d可以包括针对该字段使用的具体的数据元素842的标识符850a。标识符850b-850d可以指定该字段是表格的主键还是其一部分(标识符850b),或者与另一数据库表格的一个或多个字段具有关系,诸如是外键(标识符850c)或关联(标识符850d)。
创建/修改的表格元素848e可至少大体上类似于域元素840h。
示例10示例元数据模型
图9图示了元数据模型900的定义。具体而言,元数据模型900表示视图,诸如德国沃尔多夫的SAP SE的核心数据服务(Core Data Services)视图,并且用诸如CSN的格式来表达。元数据模型900可以包括各种不同的组件,其中至少一些可以被认为是元数据模型。也就是说,元数据模型900可以是至少部分地基于多个子模型的模型。子模型可以指定整个元数据模型900的具体方面。
元数据模型900可以可选地包括一个或多个注释904。注释可以是可以被添加到元数据模型的元数据组件。例如,提供者可能供应基本模型,而个人用户或客户可能希望添加特定于他们的操作环境和用例的元数据。因此,添加注释的能力可以通过允许定制元数据元素来增强可用性,而不会影响基本元数据模型的其他用户。可以为不同的软件层或框架指定注释。
在所示示例中,可使用具体语法元素将注释904指示为注释,诸如通过在注释前面加上“@”符号。在至少一些情况下,还可以通过将注释904放置在元数据模型的适当部分中,诸如在为注释指派的标头部分或另一部分中,来指示注释904。在一些情况下,注释904可以引用其他元数据模型,诸如数据源的元数据模型,或者可以引用与元数据模型相关联的数据源。在任一情况下,这样的关联904可以在元数据模型900和其他元数据模型/数据源之间创建依赖性。
元数据模型900可包括指令908,在这种情况下为SQL语句910,其定义了具有标识符912的核心元数据模型/对象(其可用于例如稍后访问或激活,诸如实例化元数据模型)。具体地,所示的指令908定义了视图。注释904进一步指定视图的特性,元数据模型900的其他部分也是如此,这将被进一步描述。
指令908可指定一个或多个数据源916。数据源916可以定义元数据模型900的元数据的至少一部分将被应用到的数据,并且还可以为元数据模型900供应附加的元数据。注意,元数据模型900至少在某种意义上可以依赖于引用的数据源916。例如,如果元数据模型900依赖于数据源916的预期的具体数据或元数据,如果引用的数据源不包括预期的数据或元数据,或者以其他方式与如何在元数据模型中的使用数据源不一致,则元数据模型可能不可用,具有性能问题,或者提供不正确的结果。如所示的,数据源916包括两个表格,“vbak”和“vbkd”。这些表格通常将包括元数据特征,诸如一个或多个字段,其中每个字段与数据类型、主键的指派、以及可选地与其他数据库组件的关联(诸如与其他数据库表格的关联或外键关系)相关联。
元数据模型900可以可选地包括一个或多个关联920的规范。关联920可以定义与另一个实体的关系。关联920可以在元数据模型900的使用期间被处理,诸如被转换成诸如JOIN之类的SQL表达式。与包括在元数据模型900中的其他条件或元素不同,关联可以定义至少在某些情况下是可选的关系,诸如根据如何访问元数据模型而被选择性地激活。例如,关联920可以被转换成使用引用元数据模型900的SELECT语句中提供的表格的JOIN条件。
元数据模型900可包括一个或多个组件922,其指定应如何处理使用元数据模型检索的数据,包括生成与元数据模型的其他元数据元素相关联的值。处理可以包括计算值,诸如使用元数据模型900中指定的或由元数据模型900引用的公式。具体而言,处理组件922可以指定具体字段值应当被视为元素924,其中元素可以如示例8和9中所描述的。因此,元数据模型900可以包括对如何定义元素的依赖,并且如果元素定义与在元数据模型900中如何使用以及打算如何使用它不匹配,则元数据模型900可能不准确或不可用。
元数据模型900可以可选地包括诸如一个或多个条件928之类的附加组件,或诸如聚合、联合等之类的其他操作,包括通常由数据库查询语言支持的这些操作。
示例11示例元数据模型,包括与其他元数据模型的关系
图10图示了元数据模型可以如何依赖于其他元数据模型。具体而言,图10示出了视图元数据模型1004,其可以是图9的元数据模型900。图10还图示了用于访问控制对象(诸如DCLS或数据控制语言源)的元数据模型1008、用于元数据扩展对象(诸如DDLX或元数据扩展)的元数据模型1012,以及用于扩展元素对象(诸如DDLS或数据定义语言源)的元数据模型1016。元数据模型1016表示扩展,其数据可以由目标系统从源系统导入,如示例6中所述。
访问控制对象元数据模型1008可用于限制对可使用视图元数据模型1004检索的数据的访问。例如,当视图元数据模型1004被激活时,视图元数据模型1004和访问控制对象元数据模型1008可以被一起处理,诸如生成检索视图元数据模型的数据的SQL命令,但是基于访问控制对象元数据模型对这些命令进行过滤或限制。因为访问控制对象元数据模型1008引用视图元数据模型1004,所以访问控制对象元数据模型依赖于现有的视图,并且依赖于包含在访问控制对象元数据模型中指定的元素的视图。例如,访问控制对象元数据模型引用视图“I_SampleSalesOrder”的“SalesOrderType”元素和具有其授权字段“AUART”的授权对象“V_VBAK_AAT”。因此,如果视图元数据模型1004中不存在对应的元素,则第一元素将是未定义的或不可用的。
元数据扩展对象元数据模型1012(其向视图元数据模型1004添加注释)对视图元数据模型具有相似的依赖性,扩展元素对象元数据模型1016(其向视图元数据模型添加附加元素)也是如此。
示例12元数据模型的示例关系模型
图11图示了元数据模型可以如何相互依赖,并可随时间改变,这可影响依赖元数据模型的使用或有效性。在时间t0,提供了元数据模型的数据定义语言版本。元数据模型用于两个数据库对象,模型1110用于View1,并且模型1112用于View2。用于View2的模型1112引用View1,因为它包含定义由用于View1的模型1110定义的数据的具体子集的SQL select语句。因此,模型1110包括对模型1112的依赖性。具体地,模型1110依赖于View1的存在,并且View1中存在字段“KeyField”。
在时间t1,接收用于View2的第二版本的模型1116。与模型1112相比,模型1116在View2的定义中包括View1的另一字段Field1。在一些情况下,模型1116可以作为完整的模型提供,而在其他情况下,仅发送与先前模型版本相比的改变。
在时间t2,第二系统上传View2被删除的指示1122。注意,在这种情况下,View2的删除不会影响任何描述的元数据模型,因为View2依赖于View1,但是View1不依赖于View2。相反,如果View1已经在时间t2被删除,则可以确定删除View1会给View2带来问题。
图11图示了以第一格式定义的元数据模型,诸如定义视图的SQL语句。图12A和图12B图示了可以如何将图11中所示的元数据模型转换成不同的格式,诸如用于存储元数据模型的表示的数据库表格集合中的记录。具体地,图12A示出了表格1204,其包括与表格的记录相关联的对象类型的字段1206、保存对象名称的字段1208、保存与对象相关联的版本标识符的字段1210、提供与接收对应元数据模型的最初格式(例如,纯文本、JSON、XML、CSON等)相关联的类型的字段1212、保存最初源内容列表的字段1214(以与字段1212相关联的类型)、以及包括对象何时被接收的时间戳(例如,参考图11,与时间t0、t1或t2相关联的时间戳)的字段1216。表格1204可以可选地包括一个或多个附加字段1220。
可以看出,表格1204包括在t0接收的View1的记录1222、在t0接收的View2的元数据模型的记录1224,和在t1接收的View2的元数据模型的记录1226。注意,表格1204可以包括对象源版本的信息,因此类型、名称和版本信息(即,字段1206、1208、1210)可以特定于作为对象源(例如,数据定义语言源或DDLS)的对象。
表格1228可包括数据定义语言对象版本的字段,其可包括DDLS名称的字段1230和DDLS版本标识符的字段1232,这些字段可对应于表格1204的字段1208、1210。表格1228还可以包括字段1234,该字段描述与对应的元数据模型相关联的实体(例如,元数据模型)类型。实体类型的示例可以是表格、视图、访问控制、注释扩展、元数据扩展等。
字段1236可包括实体名称或标识符,其可以是诸如图11所示的SQL语句之类的元数据模型的声明中分配给元数据模型的名称或标识符。例如,图11将元数据模型1110示为定义VIEW1,其然后提供在字段1234中指示的类型,以及在字段1236中输入的为记录1238指示的名称。注意,字段1236可以是元数据模型的名称的典型形式,并且在元数据模型定义中提供的最初名称可以包括在字段1240中。类似地,字段1236的典型名称可以与其他格式相关联,诸如在字段1242中提供的格式,如所示的,其可以是在对元数据模型的SQL查询中使用的名称,该名称可以对应于在诸如在信息模式之类的数据库层中使用的元数据模型的名称。表格1228可以包括一个或多个附加字段1244。
如图12A所示,可从表格1204、1228中,或者从单独的字段或者从具有最初源内容的字段1214中,检索图11中t0和t1处提供的元数据模型的所有信息。图12B图示了表格1250、1252、1254、1256,其可以存储关于元数据模型的附加信息,包括关于从其接收元数据模型或更新(包括删除)的系统的附加信息。具体而言,表格1250可用于将元数据模型与软件组件版本标识符相关联,其可用于描述从其接收元数据模型的系统上的操作环境。表格1250包括与在字段1264中列出的元数据模型对象名称(并且其对应于表格1204的字段1208)和字段1266的版本标识符(其对应于表格1204的字段1210)相关联的软件组件版本ID的字段1260。可以在字段1262中指定对象的类型。
当元数据模型被改变时,与字段1266中的标识符相关联的版本可链接至元数据模型的先前版本,这可存储在字段1268中。在元数据模型删除的情况下,删除时间可以在字段1270中列出(其中没有值或NULL值可以指示对象没有被删除)。在一些情况下,可以为数据模型的所有版本填写删除字段1270。在其他情况下,删除字段1270仅针对删除之前的元数据模型的最后版本被填充。
表格1252可将字段1272(并对应于字段1260)中列出的具体软件组件与字段1274中列出的特定系统软件版本相关联。进而,表格1254可以将字段1276中的特定软件系统版本与字段1278中的系统标识符所指示的特定系统以及字段1280中指示系统何时被安装、发布或激活的时间戳相关联。表格1256可以包括用于具体软件组件版本的字段1282(对应于字段1260),具有在字段1284中提供的软件组件的标识符,在字段1286中的发布标识符,在字段1288中的支持包标识符。每个表格1250、1252、1254、1256可以可选地包括一个或多个附加字段1290。
示例13示例元数据关系模型,包括查询语言操作
图13图示了参照两个视图元数据模型1306、1308来定义元数据模型1304(具体是视图)的场景,这两个视图元数据模型1306、1308可以进而依赖于一个或多个附加数据模型。元数据模型1306依赖于表格的元数据模型1310,而元数据模型1308依赖于表格的元数据模型1312,并且与用于另一视图的元数据模型1314具有关联,元数据模型1314进而引用表格的元数据模型1316。这些依赖性可以如针对用于标识数据库工件和一个或多个指定工件(包括响应于具体搜索/查询请求的工件)的相关联元数据的范围界定功能和遍历组件所描述的那样被评估。
视图元数据模型1304、1306、1308、1314包括SQL select语句,其可以以替代格式存储,诸如以表格形式存储,如图14所示。图13的视图元数据模型1304、1306、1308、1314的select语句可以包括能够以替代表示存储的附加特征/操作,诸如元数据模型1304中的join条件1320、元数据模型1308和元数据模型1314之间的关联1324,以及元数据模型1314中的where条件1328。
图14图示了表格1404,其可以以表格格式存储具有select语句的元数据模型的信息。表格1404包括用于对象类型的字段1408,其对于元数据模型1304、1306、1308、1314是数据定义语言源对象。字段1410包括给定对象的每个记录的名称或标识符,其可以是系统分配的名称,或者用于系统目的的名称,以便唯一地标识每个对象。
注意,图13中的SQL语句不分配字段1410中使用的名称。字段1412可以存储与每个记录相关联的对象的对象版本标识符值。在一些情况下,存储在字段1412中的值对于给定对象可以是唯一的,并且可以对对象进行改变时被增量。例如,记录1416被示为针对DDLS1对象具有对象版本标识符56。如果DDLS1对象再次改变,则对象版本标识符可以被增量到57。
表格1404可包括存储实体名称的字段1420,所述实体名称可以是图13所示SQL语句中使用的实体名称。例如,元数据模型1304定义了视图View4,它是在字段1420中为记录1422提供的名称,对应于View4。在至少一些情况下,表格1404中的每个对象可以与主数据源相关联。例如,SQL语句可以具有“SELECT FROM primaryDataSource(从primaryDataSource中选择)”的形式,其中“primaryDataSource”的标识符存储在字段1424中。对于元数据模型1304,View4主要是相对于View1定义的,因此View1被列在记录1422的字段1424中。字段1424的主数据源可以具有诸如表格或字段之类的类型,该类型在字段1426中提供。
如上所述,元数据模型中使用的select语句可具有附加操作,其可记录在表格1404中。如果对象元数据模型定义包括where条件,则该条件的标识符可以包括在字段1428中。元数据模型1314包括where条件1328,因此可以在记录1422的字段1428中输入该条件的标识符。字段1428中的标识符可以标识具体的条件集合,其中附加信息可以包括在条件集合表格1432中,如将进一步描述的。类似地,如果对象元数据模型定义包括join条件,则该条件的标识符可以包括在字段1436中。字段1434中的标识符可以标识表格1432中的条件集合。
表格1432允许进一步详述与表格1404中的select语句相关的条件细节。表格1432包括对象类型字段1438和对象名称字段1440,它们可以对应于表格1404的字段1408、1410。注意,元数据模型1304的join条件由记录1444-1448表示,元数据模型1314的“where”条件由记录1450表示,元数据模型1308的关联的“on”条件由记录1452表示。
表格1432包括用于字段1440中所列对象的版本标识符的字段1456,并可对应于字段1412。字段1458包括条件集合标识符,并且可以对应于字段1428、1436。组ID字段1460和分组序号字段1462可用于保留最初表达的条件的语义(例如,在SQL中)。例如,组ID字段1460可用于指示与字段1464中指示的数据源相关联的条件的部分。因此,记录1444与字段1460中的组标识符1相关联,因为它与字段1464中的值VIEW1相关联,而记录1446、1448与组标识符2相关联,因为两个记录都与字段1464的值VIEW2相关联。分组序号字段1462的值可以进一步标识记录1446、1448的具体语义,诸如指示在最初select语句中记录1446在记录1448之前。分组操作符字段1466可以提供将与字段1460的具体组标识符值相关联的记录相关联的操作符。
对于字段1468中列出的给定操作符或关系,字段1470、1464、1472、1474可分别列出左侧组标识符、左侧数据源名称、左侧字段名称和左侧值。类似地,字段1476、1478、1480、1482可以分别提供右侧组标识符、右侧组源名称、右侧字段名称和右侧值。“左侧”和“右侧”指的是值相对于字段1468的操作符的位置。
由此可见,表格1432的记录可用于重建图13所示的格式的元数据模型的操作或条件。尽管表格1432可能没有明确列出操作或条件的类型,但是该信息可以从表格1404的字段1428、1436中收集(或者从表格1484中收集,如将进一步描述的)。
关联定义表格1484可定义包括在元数据模型(诸如以图13所示格式提供的模型)中的关联,并可包括对象类型字段1486、对象名称字段1487、对象版本标识符字段1488,和实体名称字段1489,其可如针对表格1404的字段1408、1410、1412、1420所述。字段1490可以存储在字段1492中列出的对象标识符(例如,对象元数据模型的标识符)的标准化版本,其可以是包括在最初元数据模型中的关联定义中的对象名称,诸如关联1324。字段1494可以提供相关联的实体的名称,并且可以在字段1495中提供与该实体相关联的类型(例如,表格、视图)。关联可以分别与最小基数字段和最大基数字段1496和1497相关联。字段1498可以包括条件集合标识符,其可以对应于表格1432的字段1458。
以图13的示例关联1324为例,记录1452提出了为关联定义的条件(即“on”条件)。例如,被定义的视图1308所引用的表格的FIELD3中的值等于在元数据模型1314中定义的相关联视图的FIELD3,其进而与在元数据模型1316中定义的表格相关联。
表格1404、1432、1484可以可选地包括一个或多个附加字段1499。
示例14示例关系元数据模型,包括字段定义和关系
在某些情况下,元数据对象,诸如视图,可包括至少部分地基于一个或多个其他元数据模型的元素(例如,字段)计算或以其他方式至少部分地基于一个或多个其他元数据模型的元素(例如,字段)的字段。可以在元数据模型定义中明确指定该计算,或者可以在模型定义中引用该计算,例如通过调用内置函数或引用另一元数据模型中的函数、库中的函数、API调用等。
图15图示了引用元数据模型1508定义视图的元数据模型1504,元数据模型1508进而引用由元数据模型1512定义的表格。元数据模型1504包括从元数据模型1508中的字段导出的四个字段1520、1522、1524、1526。元数据模型1508包括从由元数据模型1512定义的表格中选择的三个字段1530、1532、1534。由元数据模型1512定义的表格包括在该元数据模型中声明/定义的三个字段1540、1542、1544。
图16图示了可用于总结元数据模型1504、1508、1512中使用的字段的表格1600。表格1600包括字段1602,该字段指示与该字段相关联的对象的类型,诸如与表格或数据定义语言源对象(例如,视图)相关联。在字段1604中提供对象的名称,该名称可以是由与元数据模型一起使用的系统使用或提供的对象名称,或者例如由元数据储存库使用或提供的对象名称。
可以在字段1606中提供对象的版本标识符,如针对其他元数据模型表示所讨论的,该版本标识符可以是每个对象的唯一编号,并且可以随着对象的改变而被增量。实体名称字段1608可以包括与元数据模型相关联的名称,诸如在元数据模型的声明中定义的名称。
每个元数据对象可与一个或多个字段相关联,并且字段1610可存储字段1612中提供的字段名称的标准化表示。例如,字段1610可以存储从字段1612中列出的字段名称中移除格式化/大写的名称(例如,小写字母)。如上所述,元数据模型可以并入来自其他元数据模型的字段。字段的直接源可以具有在字段1614中提供的名称,并且可以具有类型,诸如表格或视图,并且该类型可以在字段1616中提供。直接源中的字段的名称可以不同于它所并入的元数据模型中的字段的名称,因此字段1618可以包括源元数据模型中的字段的名称。
计算的字段可与表达式相关联,可在字段1620中提供表达式的标识符,其可用于访问表达式,诸如在一个或多个其他表格中存储为表示的表达式。字段1622可以指示该字段是否是关键字段(例如,在主键中使用的字段)。字段可以与可以在字段1626中列出的数据类型相关联,并且数据类型可以与附加的语义或技术信息相关联(诸如在数据元素中),数据元素的标识符可以在字段1624中提供。通常,与字段1626(进而与字段1624)相关联的数据类型可以具有长度,诸如允许的数字或字符的数量,并且该信息可以被包括在字段1628中。
允许使用小数的数值字段可通过字段1630与值(例如,允许的小数位的数量)相关联。字段1632、1634、1636、1638可用于定义表达式的定义出现在源元数据模型中的何处,诸如分别为开始行、开始列、结束行和结束列。表格1600可以可选地包括一个或多个附加字段1640。
作为表格1604可以如何用于表示来自图15的元数据模型中的字段的示例,考虑与元数据模型1508相关联的记录1650。元数据模型1508用于视图VIEW1,并引用作为关键字段的Table1的Field1(由元数据模型1512定义)。记录1652对应于元数据模型1512中的Table1的Field1的定义,其中Field1被定义为关键字段,其具有数据元素类型DE1,并且不能是NULL值。记录1650包括字段1608中的对象的名称VIEW1、字段1610中的对象中的字段的名称FIELD1、字段1614中的对象中的字段的最初名称Field 1、字段1616中的从其中引用该字段的实体的名称TABLE1、字段1616中的被引用实体的类型TABL(对于表格)、以及字段1618中的被引用实体中的字段的名称FIELD1。记录1650的字段1622被设置为真,指示与记录1650相关联的字段是关键字段,而字段1624指定该字段具有数据元素类型DE1,字段1626和1628指示是长度为30的字符数据类型。
示例15示例关系元数据模型,包括注释
如示例10中所述,诸如视图定义的元数据对象可以包括注释。图17图示了可以相互依赖的元数据对象可以如何具有注释,这些注释可以以另一种格式存储,诸如图18的表格1800中所示的格式。
图17包括用于视图View2的元数据模型1704,视图view2是相对于元数据模型1708中定义的另一视图View1定义的。用于元数据扩展DDLX2的元数据模型1712为该元数据模型1704提供了附加的元数据元素。元数据模型1708包括可以并入到元数据模型1704中的两个注释1720、1722。然而,为View1提供标签的注释1720被在元数据模型1704中为View2定义的注释1726取代。在某些情况下,如果引用元数据模型中的注释与被引用元数据模型中的注释具有相同的名称或类型(例如,如所示的“@EndUserText.label”),则该注释可以被取代。
元数据模型1730图示了元数据模型1704的“生效”表示,包括通过依赖性并入元数据模型1704的注释。可以看出,生效元数据模型1730包括注释1726,但不包括注释1720。由于元数据模型1708的注释1722没有被取代,所以它被包括在生效元数据模型1730中,来自元数据模型1712的注释1734也是如此。
表格1800可总结图17的元数据模型的注释。表格1800包括与元数据模型相关联的对象类型的字段1804,该元数据模型由表示注释的记录来注释。如图所示,字段1804包括用于视图的值“DDLS”,或用于元数据扩展对象的值“DDLX”。字段1808可以提供对象的名称,诸如系统名称,而字段1812可以提供由对象的声明定义的对象名称。字段1810可以提供对象的版本标识符。字段1814可以提供与注释相关联的子实体的名称,其可以是例如注释所应用的具体视图字段。
字段1816可提供注释内部标识符,其可用于区分元数据模型的多个注释,并可用于在元数据模型中存在多个注释时提供注释的排序。如将进一步描述的,字段1816的值还可以用于将基本或父注释或注释类型与子注释相关。注释名称可以包括在字段1818中,其可以是注释的类型(或类)或子类型(或类方法或类数据成员)。字段1820可以提供父注释的标识符。例如,记录1840将注释内部标识符“1”分配给“ENDUSERTEXT”注释。“ENDUSERTEXT”可以是基本注释类型,并且记录1842可以包括注释的子类型“ENDUSERTEXT.LABEL”,其中字段1820中的值“1”指示记录1842引用记录1840的注释。
可在字段1822中提供元数据模型的声明中定义的注释的值。字段1822中的值表示分配给注释的明确定义的值。分配给注释的生效值可以在字段1824中指示。例如,注释@Search.defaultSearchElement具有生效值“TRUE”,即使这没有在元数据模型的声明中明确地捕获,而是从注释默认逻辑中自动导出。此外,在所示的示例中,语言相关文本的生效值可以相对于表格1850中的标识符来指定,其中字段1824中的值对应于文本标识符字段1854中的值。表格1850还被示为包括字段1856,其提供了与文本相关联的语言的代码,并且要显示的实际文本可以在字段1858中提供。
表格1800可存储被并入具体元数据模型的所有注释的信息。然而,如上所述,一些注释可能不是“活动的”,例如,因为本地声明的注释可能会覆写导入或引用的注释。类似地,在一些情况下,来自多个被引用的源(例如,元数据模型)的注释可能重叠或冲突,在这种情况下,只有一个注释(或者通常是一个子集)可以被指派为活动的。单独维护活动注释的储存库可能是有益的,该储存库可以如图19的表格1900所示进行存储。
表格1900可包括用于对象类型的字段1904、用于对象名称的字段1908、用于对象版本标识符的字段1910、用于实体名称的字段1912、用于子实体名称的字段1914、用于注释内部标识符的字段1916、用于注释名称的字段1918、用于父注释标识符的字段1920、用于注释值的字段1922,和用于生效注释值的字段1924,可以至少一般地针对表格1800的类似标题和编号的字段所描述的来实现这些字段。
表格1900可包括附加字段,诸如活动注释版本标识符字段1930。注意,字段1930中的活动注释版本标识符可以具有不同于字段1910中的对象版本标识符的值。例如,新的元数据扩展可以改变被注释的现有基本(例如,视图)模型版本的活动注释,因此单独跟踪这些版本可能是有用的。
由于注释可从其他来源导入,因此相对于它们的源对象(例如,元数据模型)跟踪关于这些注释的信息可能是有用的。相应地,字段1932可以存储与注释相关联的对象类型(本地对象类型或者从其导入注释的对象的对象类型),而字段1934可以存储起源对象的名称。字段1936可以存储起源对象的版本标识符。
示例16用于元数据访问的示例API
用户或应用可访问存储的元数据模型,诸如以示例12-15中描述的一种或多种表格格式维护的元数据。在某些情况下,可以经由API访问信息,诸如使用REST服务的基于web的API。在具体示例中,API可以使用OData协议。
图20图示了持续性模型的摘录2004(例如,示例12-15的全部或部分表格)和可用于访问持续性中维护的数据或根据持续性中的数据确定或计算的数据的OData服务的摘录2050。持续性摘录2004可以包括表格或其部分(例如,一个或多个字段),用于DDLS版本信息2020、对象版本源信息2022、文本信息2024(例如,最初元数据对象定义信息的文本)、与对象版本相关联的select语句信息2026、与对象版本相关联的关联信息2028、与对象版本相关联的字段信息2030、与对象版本相关联的条件信息2032(例如,诸如关于1432所描述的“where”或“on”条件)、与对象版本相关联的本地注释信息2034,以及与对象版本相关联的活动注释信息2036。
API或用于访问元数据服务的其他功能,可提供除了其他之外的查询和维护元数据模型的表示的功能,诸如创建、更新或删除元数据模型表示(或其特定版本)。API可以允许其他选项,诸如聚合来自持续性的元数据模型表示的数据,或者搜索元数据储存库,包括使用模糊搜索技术。例如,用户(或应用)可能请求关于在储存库中注册了多少对象、多少版本与具体对象相关联,或对象可能具有的字段的数量(诸如字段的最大数量之类)的信息。
图21图示了具有对象版本源信息的示例表格2104和具有DDLS版本信息的示例表格2108。表格2104可以具有多个字段,包括用于与记录相关联的对象类型的字段2112、用于与记录相关联的对象名称的字段2114以及用于与记录相关联的对象版本标识符的字段2116。表格2108可以具有用于DDLS名称的字段2120、DDLS版本字段2122、实体名称(诸如CDS实体名称)字段2124和最初实体名称字段(诸如最初CDS实体名称)字段2126。
采用表格2104和2108的元数据表示,并使用摘录2050,摘录的导航特性可通过OData读取请求从对象版本源表格2104的记录遍历到DDLS版本表格2108,OData读取请求如下:
…sap/opu/odata/sap/CdsMetadataService/ObjectVersionSource(ObjectType='DDLS',ObjectName='I_SALESORDER',ObjectVersionId=1)/to_DdlsVersion
该操作导致相关的数据记录:
API可允许搜索给定对象版本的所有相关信息。例如,对“cust”的搜索请求可以具有以下形式:
…/sap/opu/odata/sap/CdsMetadataService/Ddls/?search=cust
其检索DDLS对象名称(例如字段2114)为I_CUSTOMER的所有五条记录。注意,用户可以检索和访问元数据信息,而无需知道元数据模型的确切名称或其任何组成元素。
API或其他元数据服务访问功能可支持其他服务,包括基于更粗粒度的动作的服务,而不仅仅是简单检索和更新元数据模型。这些服务可以包括上传对象源信息、比较元数据模型(及其部分),包括比较不同组件或系统版本之间的元数据模型。可以提供对在何处使用各种元数据模型或元素的分析,包括标识元数据模型/元数据模型组件之间的依赖性。与每次通过应用多个较低级别的功能来实现功能相比,提供这样的服务可能更有效率,并且更不容易出错。
作为示例,对于上传元数据模型的请求,不是将从对象版本表格开始的每个单独表格的对象源信息转换为存储更详细信息的表格,用户或应用可请求上传对象动作,其可提供定义对象的最初字符串(例如,最初SQL语句),可选地连同附加信息,诸如最初源字符串的类型(例如,SQL、XML、纯文本)、对象的名称、对象类型(例如,视图、表格)、其它信息及其组合。输入可以包括:
ObjectType
ObjectName
SerializedObjectSourceType
SerializedObjectSourceContent
ObjectMaintenanceLanguage
ObjectLastChangedDateTime
SoftwareComponentId
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
图22提供了“where used(在哪使用)”请求的示例。相关元数据模型的组2204包括用于View3的元数据模型2208,其引用用于View2的元数据模型2210,用于View2的元数据模型2210引用用于View1的元数据模型2212,用于View1的元数据模型2212进而引用用于Table1的元数据模型2214。假设每个视图2208、2210、2212引用了Table1的字段,并且视图通过如所示的它们所引用的视图来引用这个字段,则请求可以是:
Input:
ObjectName:TABLE1
UseageTypes:ALL
MaximumNumberOfIndirections:5
响应于该请求,表格2230中所示的信息可以以所示的表格形式或另一种格式提供。
对于依赖性检查,输入(例如,函数的参数)可包括:
ObjectType
ObjectName
ObjectSourceType
ObjectSourceContent
SoftwareComponentVersions
NewSoftwareComponentVersions
对请求的响应(例如,由函数返回的值,诸如在结构(例如,C++struct)或类实例中,或者另一复杂或抽象数据类型中),可以包括:
MessageType[例如,INFO,WARNING,ERROR]
MessageText
EntityReference[例如,到元数据模型的附加细节的链接,以便可以标识关于依赖对象的附加信息]
作为具体示例,考虑向通过用户模型暴露的字段ViewField添加新注释NewAnnotation。依赖性检查的输出可以包括:
MessageType:INFO
MessageText:新注释NewAnnotation被添加到字段ViewField
EntityReference
=…/sap/opu/odata/sap/CdsMetadataService/…NewAnnotation…
处理对元数据的访问的服务可促使或帮助向最终用户诸如在用户界面屏幕上显示元数据信息。该服务可以用可以定义用户界面的布局的附加信息来加强模型元数据,并且可以包括或定义允许用户与数据交互的附加服务。例如,如图23的示例代码所示,可以提供注释,该注释经由值帮助来辅助用户提供过滤标准。
示例17示例词汇表
如关于图4所讨论的,元数据暴露服务可提供对描述充当数据库工件的元数据的注释的词汇表的访问。提供了一些如何从对应的注释中导出词汇表的示例。
图24A图示了数据仓库的注释2404,其列出了注释的元素2414。图24B提供了从注释2404创建的示例词汇表2426。注释2404表示以CDS记法表达的注释(如在可从德国沃尔多夫的SAP SE获得的产品中),而词汇表2426以CSN表达。使CDS记法用于注释、CSN记法用于词汇表的这种模式在本示例17中其余的示例中继续。
图25A图示了包括值(在这种情况下为整数)数组的注释2504。图25B示出了对应的词汇表2508。图26A示出了示例注释2604,其提供了类型的枚举列表,包括默认值2606,而图26B示出了对应的词汇表2608。
示例18示例标准化API和元数据表示
图27A-27J图示了标准化格式的API的至少一部分的示例列表,其可以是图3的标准化格式320的API的示例。
图28A-28C图示了标准化格式的数据工件的至少一部分元数据的示例列表,其可以是图3的标准化格式330的元数据的示例。
示例19示例实现方式
图29A是用于向目标系统发送数据工件扩展的元数据的示例方法2900的流程图。方法2900可以在图1的计算环境100或图5的计算环境500中实现。
在2905,从目标系统接收对元数据储存库中的至少一部分元数据的第一请求。在2910,标识包括一个或多个数据库工件的元数据扩展的一个或多个软件对象。在2915,响应于第一请求,将元数据扩展的至少一部分元数据元素返回给目标系统。
图29B是用于从客户端系统获得描述数据库工件的数据的元数据的示例方法2950的流程图。方法2950可以在图1的计算环境100或图5的计算环境500中实现。
在2955,在数据库系统中创建多个数据库工件。数据库工件被配置成存储数据或对数据的引用,其中数据由元数据描述。在2960,部署与数据相关联的元数据的至少第一部分。在2965,向客户端系统发送对与数据相关联的元数据的第二部分的请求。在2970,部署元数据的第二部分。
示例20计算系统
图30描绘了可实现所述创新的合适计算系统3000的一般化示例。计算系统3000不旨在对本公开的使用范围或功能提出任何限制,因为该创新可以在各种通用或专用计算系统中实现。
参考图30,计算系统3000包括一个或多个处理单元3010、3015和存储器3020、3025。在图30中,该基本配置3030包括在虚线内。处理单元3010、3015执行计算机可执行指令,诸如用于实现图1的环境100的组件,包括如示例1-19中所描述的。处理单元可以是通用中央处理单元(CPU)、专用集成电路(ASIC)中的处理器或任何其他类型的处理器。在多处理系统中,多个处理单元执行计算机可执行指令来提高处理能力。例如,图30示出了中央处理单元3010以及图形处理单元或协处理单元3015。有形存储器3020、3025可以是可由(多个)处理单元3010、3015访问的易失性存储器(例如,寄存器、高速缓存、RAM)、非易失性存储器(例如,ROM、EEPROM、闪存等),或两者的某种组合。存储器3020、3025以适于由(多个)处理单元3010、3015执行的计算机可执行指令的形式存储实现这里描述的一个或多个创新的软件3080。
计算系统3000可具有附加特征。例如,计算系统3000包括存储装置3040、一个或多个输入设备3050、一个或多个输出设备3060以及一个或多个通信连接3070。诸如总线、控制器或网络之类的互连机制(未示出)将计算系统3000的组件互连。通常,操作系统软件(未示出)为在计算系统3000中执行的其他软件提供操作环境,并协调计算系统3000的组件的活动。
有形存储装置3040可以是可移除的或不可移除的,并且包括磁盘、磁带或盒式磁带、CD-ROM、DVD或可用于以非暂时性方式存储信息且可在计算系统3000内被访问的任何其他介质。存储装置3040存储实现这里描述的一个或多个创新的软件3080的指令。
(多个)输入设备3050可以是触摸输入设备,诸如键盘、鼠标、笔或轨迹球、语音输入设备、扫描设备或向计算系统3000提供输入的另一设备。(多个)输出设备3060可以是显示器、打印机、扬声器、CD刻录机或从计算系统3000提供输出的另一设备。
(多个)通信连接3070使得能够通过到另一计算实体的通信介质进行通信。通信介质传达信息,诸如计算机可执行指令、音频或视频输入或输出、或调制数据信号中的其他数据。调制数据信号是以在信号中编码信息的方式设置或改变其一个或多个特性的信号。通过示例的方式而非限制,通信介质可以使用电、光、RF或其他载体。
可在计算机可执行指令的一般背景下描述创新,诸如在目标真实或虚拟处理器上的计算系统中执行的程序模块中包含的那些。通常,程序模块或组件包括例程、程序、库、对象、类、组件、数据结构等,它们执行具体的任务或实现具体的抽象数据类型。在各种实施例中,程序模块的功能可以根据需要在程序模块之间组合或分割。程序模块的计算机可执行指令可以在本地或分布式计算系统内执行。
术语“系统”和“设备”在本文中可互换地使用。除非上下文另有明确指示,否则这两个术语都不暗示着对计算系统或计算设备的类型的任何限制。一般而言,计算系统或计算设备可以是本地的或分布式的,并且可以包括专用硬件和/或通用硬件与实现这里描述的功能的软件的任何组合。
在本文所述的各种示例中,可对模块(例如,组件或引擎)进行“编码”,以执行某些操作或提供某些功能,指示可执行模块的计算机可执行指令,以执行此类操作、促使此类操作被执行或以其他方式提供此类功能。尽管关于软件组件、模块或引擎描述的功能可以作为分立的软件单元(例如,程序、函数、类方法)来实现,但是它不必作为分立的单元来实现。也就是说,该功能可以被并入到更大或更通用的程序中,诸如更大或通用程序中的一行或多行代码中。
为便于表述,详细说明使用“确定”和“使用”之类术语来描述计算系统中的计算机操作。这些术语是对计算机执行的操作的高级抽象,并且不应与人类执行的动作相混淆。对应于这些术语的实际计算机操作根据实现而变化。
示例21云计算环境
图31描绘了可实现所描述的技术的示例云计算环境3100。云计算环境3100包括云计算服务3110。云计算服务3110可以包括各种类型的云计算资源,诸如计算机服务器、数据存储储存库、网络资源等。云计算服务3110可以是集中定位式(例如,由企业或组织的数据中心提供)或分布式的(例如,由位于不同位置(诸如不同的数据中心)和/或位于不同的城市或国家的各种计算资源提供)。
云计算服务3110由各种类型的计算设备(例如,客户端计算设备)(诸如计算设备3120、3122和3124)利用。例如,计算设备(例如,3120、3122和3124)可以是计算机(例如,台式或膝上型计算机)、移动设备(例如,平板计算机或智能电话)或其他类型的计算设备。例如,计算设备(例如,3120、3122和3124)可以利用云计算服务3110来执行计算操作(例如,数据处理、数据存储等)。
示例22实现方式
尽管为方便呈现,以具体的顺序次序对一些公开方法的操作进行了描述,但应理解,这种描述方式涵盖了重新排列,除非下文阐述的特定语言要求具体的排序。例如,顺序描述的操作在某些情况下可以被重新排列或同时执行。此外,为了简单起见,附图可能没有示出所公开的方法可以结合其他方法使用的各种方式。
任何公开的方法可实现为存储在一种或多种计算机可读存储介质(诸如有形的非暂时性计算机可读存储介质)上的计算机可执行指令或计算机程序产品,并在计算设备(例如,任何可用的计算设备,包括智能手机或其他包括计算硬件的移动设备)上执行。有形计算机可读存储介质是可以在计算环境内访问的任何可用的有形介质(例如,一个或多个光学介质盘,诸如DVD或CD,易失性存储器组件(诸如DRAM或SRAM),或非易失性存储器组件(诸如闪存或硬盘驱动器))。通过示例的方式,并且参考图30,计算机可读存储介质包括存储器3020和3025以及存储装置3040。术语计算机可读存储介质不包括信号和载波。此外,术语计算机可读存储介质不包括通信连接(例如,3070)。
用于实现所公开的技术的任何计算机可执行指令以及在实现所公开的实施例期间创建和使用的任何数据可存储在一个或多个计算机可读存储介质上。计算机可执行指令可以是例如专用软件应用或经由网络浏览器访问或下载的软件应用或其他软件应用(诸如远程计算应用)的一部分。这种软件可以例如在单个本地计算机(例如,任何合适的市场上可买到的计算机)上或在使用一个或多个网络计算机的网络环境(例如,经由互联网、广域网、局域网、客户端-服务器网络(诸如云计算网络)或其他这种网络)中执行。
为清楚起见,仅描述了基于软件的实现方式的某些选定方面。省略了本领域公知的其他细节。例如,应该理解,所公开的技术不限于任何特定的计算机语言或程序。例如,可以由以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.根据权利要求1所述的计算系统,其中,所述请求是更新请求,并且所述操作还包括:
确定与先前被发送到目标系统的元数据元素的版本相比,是否已经添加、删除或修改了元数据元素。
5.根据权利要求4所述的计算系统,其中,返回已经修改或添加的元数据元素。
6.根据权利要求1所述的计算系统,所述操作还包括:
整合给定数据库工件的元数据的多个版本。
7.根据权利要求6所述的计算系统,其中,所述整合包括应用一个或多个优先规则。
8.根据权利要求7所述的计算系统,其中,优先规则指定使用元数据元素的较晚版本来代替元数据元素的较早版本。
9.根据权利要求6所述的计算系统,其中,优先规则指定将元数据元素的一个或多个值的较晚集合添加到元数据元素的一个或多个值的较早集合。
10.根据权利要求1所述的计算系统,所述操作还包括:
确定用于访问所述一个或多个数据库工件的多个API;
将所述多个API转换成标准化交换格式并在目录中保存标准化交换格式的多个API。
11.根据权利要求10所述的计算系统,其中,所述标准化交换格式的多个API用于提供关于与所述多个API相关联的数据库工件的信息,但数据库工件的数据或元数据是使用与标准化交换格式的对应API相关联的所述多个API中的API来检索的。
12.根据权利要求10所述的计算系统,还包括向另一计算系统暴露标准化交换格式的多个API。
13.根据权利要求10所述的计算系统,其中,标准化交换格式的API包括对用于创建标准化交换格式的API的对应API的引用,以及对与对应数据库工件相关联的元数据的引用。
14.根据权利要求1所述的计算系统,其中,确定一个或多个数据库工件的集合包括分析外键关系或关联。
15.根据权利要求1所述的计算系统,所述操作还包括:
将所述至少一部分元数据元素从第一格式转换成标准化格式,其中,向目标系统返回元数据扩展的至少一部分元数据元素包括返回标准化格式的至少一部分元数据元素。
16.一个或多个计算机可读存储介质,包括:
计算机可执行指令,当由包括至少一个硬件处理器和耦合到所述至少一个硬件处理器的至少一个存储器的计算系统执行时,所述计算机可执行指令使得所述计算系统从目标系统接收对元数据储存库中的至少一部分元数据的请求,所述请求包括足以标识一个或多个数据库工件的信息;
计算机可执行指令,当由计算系统执行时,所述计算机可执行指令使得计算系统标识包括所述一个或多个数据库工件的元数据扩展的一个或多个软件对象,所述元数据扩展包括一个或多个元数据元素;
计算机可执行指令,当由计算系统执行时,所述计算机可执行指令使得计算系统响应于所述请求向目标系统返回元数据扩展的至少一部分元数据元素。
17.一种在包括源计算系统和目标计算系统的计算环境中实现的方法,所述源计算系统和所述目标计算系统各自包括至少一个硬件处理器和耦接到所述至少一个硬件处理器的至少一个存储器,所述方法包括,在源计算系统处:
在数据库系统中创建多个数据库工件,所述多个数据库工件被配置成存储数据或对数据的引用,所述数据由元数据描述;
部署与所述数据相关联的元数据的第一部分;
向客户端系统发送对与所述数据相关联的元数据的第二部分的请求;以及
部署元数据的第二部分。
18.根据权利要求17所述的方法,其中,所述请求是第一请求,所述方法还包括:
向客户端系统发送对元数据的至少第三部分的第二请求,所述至少第三部分选自所述元数据的第二部分;以及
从客户端系统接收与元数据的至少第三部分相关联的元数据元素。
19.根据权利要求17所述的方法,其中,响应于第二请求而返回的元数据元素包括在客户端系统处更新的元数据元素。
20.根据权利要求18所述的方法,其中,所述请求是第一请求,所述方法还包括:
向客户端系统发送对元数据的至少第三部分的第二请求;以及
从客户端系统接收与元数据的至少第三部分相关联的元数据元素,其中,元数据的至少第三部分包括在部署元数据的第二部分之后添加到客户端系统的至少一个元数据元素。
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/448,514 US11940951B2 (en) | 2021-09-22 | 2021-09-22 | Identification and import of metadata for extensions to database artefacts |
US17/448,514 | 2021-09-22 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115905164A true CN115905164A (zh) | 2023-04-04 |
Family
ID=83400542
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202211101500.5A Pending CN115905164A (zh) | 2021-09-22 | 2022-09-09 | 对数据库工件的扩展的元数据的标识和导入 |
Country Status (3)
Country | Link |
---|---|
US (1) | US11940951B2 (zh) |
EP (1) | EP4155968A1 (zh) |
CN (1) | CN115905164A (zh) |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4912026B2 (ja) * | 2006-04-27 | 2012-04-04 | キヤノン株式会社 | 情報処理装置、情報処理方法 |
US20080005062A1 (en) * | 2006-06-30 | 2008-01-03 | Microsoft Corporation | Component for extracting content-index data and properties from a rich structured type |
US20100161648A1 (en) | 2008-12-19 | 2010-06-24 | Peter Eberlein | Flexible multi-tenant support of metadata extension |
US20140279839A1 (en) * | 2013-03-14 | 2014-09-18 | Sap Ag | Integration of transactional and analytical capabilities of a database management system |
US9619552B2 (en) * | 2013-09-06 | 2017-04-11 | Sap Se | Core data services extensibility for entity-relationship models |
US11294927B2 (en) | 2019-04-18 | 2022-04-05 | Sap Se | Metadata hub for metadata models of database objects |
US11829606B2 (en) * | 2020-06-12 | 2023-11-28 | Rubrik, Inc. | Cloud object storage and versioning system |
-
2021
- 2021-09-22 US US17/448,514 patent/US11940951B2/en active Active
-
2022
- 2022-09-09 CN CN202211101500.5A patent/CN115905164A/zh active Pending
- 2022-09-21 EP EP22196904.1A patent/EP4155968A1/en active Pending
Also Published As
Publication number | Publication date |
---|---|
US20230105205A1 (en) | 2023-04-06 |
EP4155968A1 (en) | 2023-03-29 |
US11940951B2 (en) | 2024-03-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11907247B2 (en) | Metadata hub for metadata models of database objects | |
EP3446242B1 (en) | Query plan generation and execution in a relational database management system with a temporal-relational database | |
CA2318299C (en) | Metadata exchange | |
US7895226B2 (en) | System and method for translating and executing update requests | |
KR20060045622A (ko) | 컴퓨터화된 재무 시스템의 추출, 변환 및 로딩 설계자 모듈 | |
US11341142B2 (en) | Framework and metadata artefacts for updating data artefacts | |
EP4155964A1 (en) | Centralized metadata repository with relevancy identifiers | |
US11893026B2 (en) | Advanced multiprovider optimization | |
US11138206B2 (en) | Unified metadata model translation framework | |
US20230418808A1 (en) | Maintaining data separation for data consolidated from multiple data artifact instances | |
EP4155965A1 (en) | System and method for facilitating metadata identification and import | |
US8271463B2 (en) | System and method for providing access to data with user defined table functions | |
EP4155968A1 (en) | Identification and import of metadata for extensions to database artefacts | |
EP4170516A1 (en) | Metadata elements with persistent identifiers | |
US12038944B2 (en) | Propagation of extensions of data artifacts | |
EP4258126A1 (en) | Propagation of extensions of data artifacts | |
US20240134883A1 (en) | Data object management using data object clusters | |
US20240232227A9 (en) | Data object management using data object clusters | |
US11797552B2 (en) | System and method for selective retrieval of metadata artefact versions | |
EP4361868A1 (en) | Access controls for modelled content using namespaces | |
US20240232186A9 (en) | Virtual access to parameterized data objects | |
US20240134849A1 (en) | Virtual access to parameterized data objects | |
EP4266205A1 (en) | Logical pointers supporting reuse of text translations | |
US20240241865A1 (en) | Automatic enforcement of standardized data model mapping | |
US20240119071A1 (en) | Relationship-based display of computer-implemented documents |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |