Systems and methods for facilitating metadata identification and import

Abstract

This describes technologies and solutions for storing and processing metadata, including instantiating database artifacts on a target system based on metadata maintained at the source system. The target system can query the source system for metadata associated with its database artifacts. The target system can then instantiate database artifacts based on this metadata. The target system's database artifacts are linked to corresponding database artifacts in the source system, such as by associating them with APIs that allow data or metadata from the source system's corresponding database artifacts to be obtained. The target system uses the corresponding API to obtain additional data or metadata from its database artifacts.

Description

Technical Field

[0001] This disclosure generally relates to metadata describing database artifacts (including database artifacts such as tables or views). Specific implementations provide a metadata exposure service that receives requests from a target system to identify or retrieve relevant metadata in the source system. Background Technology

[0002] An increasing amount of data is becoming available from an ever-growing variety of sources. Data associated with a specific purpose, such as a particular simulated world entity, is often associated with metadata describing that data. For example, a ten-digit integer may be data, but without metadata, it may be difficult to know what that ten-digit integer represents—a phone number, a driver's license number, a password, and so on. Therefore, using and making data “meaningful” can largely depend on having the right metadata to provide context for that data.

[0003] Databases or other data sources associated with complex tasks such as the operation of business entities can involve thousands of table types and billions of records. Tables or other database objects can reference each other, adding to the complexity. In some cases, metadata from one system may be useful in another. For example, it may be desirable to copy or transfer data from one system to another, such as when migrating from an on-premises database solution to a cloud-based solution. Or, it may be desirable to make data available to another platform, such as through data federation. However, using or interpreting copied or federated data can be difficult or impossible if the metadata is inaccessible. Given the potentially massive amounts of metadata in the source system, manually recreating metadata in the new system would be extremely time-consuming. Therefore, there is room for improvement. Summary of the Invention

[0004] This overview is provided to introduce, in a simplified form, the concept of the options that will be further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter.

[0005] This document describes techniques and solutions for storing and processing metadata, including instantiating database artifacts at a target system based on metadata maintained at a source system. The target system can query the source system for metadata associated with the database artifacts of the source system. The target system can instantiate the database artifacts based on such metadata. The database artifacts of the target system are linked to corresponding database artifacts of the source system, such as by associating the database artifacts of the target system with an API (Application Programming Interface) that can be used to obtain data or metadata of the corresponding database artifacts of the source system. The target system uses the corresponding API to obtain additional data or metadata for the database artifacts of the target system.

[0006] In one embodiment, a method is provided for creating database artifacts at a target system based on metadata retrieved from a source system, and linking these created database artifacts to corresponding database artifacts in the source system. The method involves receiving input, such as input from a user- or computer-implemented process, specifying one or more database artifacts in the source system or criteria (e.g., search terms / criteria) sufficient to identify one or more database artifacts in the source system. A first request is sent to the source system requesting metadata associated with the one or more database artifacts. In response to the first request, metadata is received from the source system.

[0007] At the target system, one or more database artifacts are instantiated using metadata received from the source system. The one or more instantiated database artifacts are linked to the one or more database artifacts in the source system. A second request is sent to the source system requesting additional data or metadata for the one or more instantiated database artifacts. In response to the second request, data or metadata is received from the source system. Such data or metadata is stored in association with the one or more instantiated database artifacts.

[0008] This disclosure also includes a computing system configured to perform the methods (or operations) described above, or including instructions for performing the methods (or operations) described above, and a tangible, non-transitory computer-readable storage medium. As described herein, various other features and advantages may be incorporated into the art as needed. Attached Figure Description

[0009] Figure 1 This is a diagram illustrating an example computing environment in which the disclosed technology can be implemented, where the source system provides metadata exposure services that can be accessed by the target system.

[0010] Figure 2A It is a sequence diagram of the methods for handling client requests for metadata, which contains specific details of the operations of the components of the source system.

[0011] Figure 2B It is a sequence diagram of the methods for handling client requests for metadata, which contains specific details of the operations of the components of the target system.

[0012] Figure 2C This is a flowchart of a method for automatically creating database artifacts on the target system and linking these artifacts to the data and metadata maintained on the source system.

[0013] Figure 3 The diagram illustrates how a standardized API can provide access to metadata in a standardized format, and how a non-standardized API can be referenced.

[0014] Figure 4 The diagram illustrates information that can be maintained by and accessed using the metadata exposure service.

[0015] Figure 5 This is a diagram illustrating a computing environment that can be used to supplement the standard metadata of a database artifact with metadata associated with an extension of this database artifact.

[0016] Figure 6 It is a diagram of a database schema that shows the technical relationships between at least a portion of the database tables in the schema.

[0017] Figure 7 It is a diagram illustrating the relationships between table elements that can be included in the data dictionary or otherwise used to define database tables.

[0018] Figure 8 This is a schematic diagram of the components of the data dictionary and the database layer.

[0019] Figure 9 This is the code for a sample metadata model used in a database view.

[0020] Figure 10 This is the code for a sample metadata model used in a database view, and the code for a metadata model used to modify or reference this sample metadata model.

[0021] Figure 11 It is a diagram illustrating how the metadata model can be correlated and how it can be updated or deleted, including correlation, updating or deletion by multiple computing systems.

[0022] Figure 12A and Figure 12B This is an example table illustrating how a metadata model can be stored in a relational format.

[0023] Figure 13It illustrates how the metadata model can be related, how it can include query operations such as select statements, join conditions and where conditions, and how database objects can be related through association.

[0024] Figure 14 Sample database tables are provided, illustrating how to store data in a relational format. Figure 13 The metadata model information presented in the document.

[0025] Figure 15 This is a diagram illustrating how a metadata model can have fields defined relative to other metadata models.

[0026] Figure 16 A sample database table is provided, illustrating how it can be stored in a relational format. Figure 15 The metadata model information presented in the document.

[0027] Figure 17 It is a diagram illustrating how metadata models can be related, including metadata models with annotations and metadata models that annotate other metadata models.

[0028] Figure 18 and Figure 19 A sample database table is provided, illustrating how it can be stored in a relational format. Figure 17 The metadata model information presented in the document.

[0029] Figure 20 The diagram illustrates the code for a persistent model data access service that can access the metadata model.

[0030] Figure 21 and Figure 22 A sample table is presented that can be used to perform operations that require a data access service request.

[0031] Figure 23 Sample code is presented for a user interface service that can be used to annotate and display metadata model information.

[0032] Figure 24A It provides a sample metadata description of the data warehouse, while Figure 24B The diagram illustrates the vocabulary that can be generated from it.

[0033] Figure 25A It provides example metadata descriptions, including elements in array form, while Figure 25B The diagram illustrates the vocabulary that can be generated from it.

[0034] Figure 26A It provides example metadata descriptions of elements in the form of an enumerated list, while Figure 26B The diagram illustrates the vocabulary that can be generated from it.

[0035] Figures 27A-27J A list of examples of APIs that can be used to retrieve metadata in a standardized format is provided.

[0036] Figures 28A-28C At least a portion of a standardized list of sample metadata is provided.

[0037] Figure 29 This is a flowchart illustrating an embodiment of the disclosed innovation.

[0038] Figure 30 This is a diagram of an example computing system in which some of the described embodiments can be implemented.

[0039] Figure 31 This is an example cloud computing environment that can be used in conjunction with the technologies described in this article. Detailed Implementation

[0040] Example 1 – Overview

[0041] An increasing amount of data is becoming available from an ever-growing variety of sources. Data associated with a specific purpose, such as a particular simulated world entity, is often associated with metadata describing that data. For example, a ten-digit integer may be data, but without metadata, it may be difficult to know what that ten-digit integer represents—a phone number, a driver's license number, a password, and so on. Therefore, using and making data “meaningful” can largely depend on having the right metadata to provide context for that data.

[0042] Databases or other data sources associated with complex tasks such as the operation of business entities can involve thousands of table types and billions of records. Tables or other database objects can reference each other, adding to the complexity. In some cases, metadata from one system may be useful in another. For example, it may be desirable to copy or transfer data from one system to another, such as when migrating from an on-premises database solution to a cloud-based solution. Or, it may be desirable to make data available to another platform, such as through data federation. However, using or interpreting copied or federated data can be difficult or impossible without access to the metadata. Given the potentially massive amounts of metadata in the source system, manually recreating metadata in the new system would be extremely time-consuming. Therefore, there is room for improvement.

[0043] This disclosure provides techniques for retrieving metadata. In specific examples, metadata can be accessed or linked for access when the data described by metadata at the source system is available at the target system. For example, data at the target system can be made available through data federation (retrieving data from the source system when specifically requested) or through data replication (retrieving data from the source system and storing it on the target system, such as before a specific request for such data). Data is made more available at the target system by automatically linking the data available to the target system to the metadata at the source system. Therefore, the disclosed techniques eliminate the need for users to manually recreate metadata or manually retrieve metadata from the source system for database artifacts (such as database tables, database views, or database processes) that are available at the source system.

[0044] In some respects, metadata services at the source system facilitate metadata retrieval by the target system or an intermediate system representing the target system. Metadata services at the source system may include metadata converters that transform the source system's metadata into a common format for facilitating the sharing of metadata content between systems. In a specific example, the common format may be CSN (Core Schema Notation, such as that used in software available from SAP SE in Walldorf, Germany). CSN can be considered as SQL statements rich in annotations or semantic information.

[0045] The source system may include APIs that make metadata available to external systems. In a specific example, metadata in the source system (which can be native metadata or metadata stored in a common format) can be flagged for exposure, which can trigger the creation of APIs. For example, a specific entity can be flagged for exposure, and metadata associated with that entity can be exposed via one or more APIs, optionally triggering a conversion of the underlying metadata to a standard format.

[0046] In some cases, different source systems may make data and metadata available through different interfaces. For example, one system may have an SQL API, while another system may have an OData API. This disclosure provides a technique for source systems to include an API catalog, wherein the API catalog contains descriptions of the APIs provided by the source system in a standard format.

[0047] To facilitate the storage, retrieval, and comparison of models, models can be converted between representations. For example, a model can be converted between a string or string-like representation (e.g., a string storing the text of an SQL query) and a structured representation, such as a programming language (including markup languages) representation (e.g., instances of complex, composite, or abstract data types, such as instances of classes), or a platform-independent but structured format. For instance, a string representation could be an SQL DDL statement used to define database objects such as tables and views. This string can be parsed to generate a structured representation.

[0048] Structured representations can be representations of these statements in a relational format, such as representations in one or more tables. For example, one entity (table) might store the definitions of table fields, and another entity (table) might store features such as WHERE and JOIN conditions. Structured formats can also include formats such as XML, JSON, or CSON (SAP Core Schema Object Notation for SE, also known as CSN or Core Schema Notation from Waldorf, Germany). However, in some cases, format conversion can include conversions between different structured formats, such as conversions from structured formats like XML, CSON, or JSON to relational formats, and vice versa.

[0049] Example 2 – An example computing environment that facilitates metadata identification and import

[0050] Figure 1 An example computing environment 100 facilitating metadata retrieval is illustrated. Computing environment 100 includes a source system 104 and a target system 108. Target system 108 is shown communicating with a database 112. Although database 112 is shown as a separate component from target system 108, in some implementations, the database may be part of target system 108. In further embodiments, computing environment 100 does not need to include database 112. For example, the disclosed techniques can facilitate metadata retrieval, but this retrieval does not need to be associated with creating database artifacts in database 112.

[0051] Source system 104 includes a metadata store 116. Metadata store 116 includes metadata, such as metadata describing data maintained by or accessible by source system 104 (such as data maintained in relational database tables (not shown)). Examples of metadata are metadata describing the data type or semantic information, such as information indicating when a specific set of values ​​in a database table (such as a specific column / field) represents currency, phone number, social security number, etc. Metadata may indicate the language of a specific string value (e.g., German or English) or provide details about specific calculations of a specific number (e.g., how a specific KPI is calculated).

[0052] In some cases, the metadata in metadata store 116 may be maintained in a format that is not easily consumed outside of source system 104, or even maintained by different applications of the source system. Accordingly, source system 104 may include converter 120. Converter 120 can convert metadata between formats, including converting metadata between application-specific formats and standardized / transmission / exchange formats such as CSN, JSON, or XML.

[0053] In some cases, converter 120 only transforms metadata in metadata store 116 when specifically requested, such as in response to a request from target system 108. Metadata traversal component 124 can be invoked by parsing frame 128. Metadata traversal component 124 can retrieve specific metadata or determine what metadata is relevant to a request. For example, a metadata request may specify a specific database object (or artifact, such as a table, view, column, or row), and parsing frame 128 can determine what metadata is relevant to that database object. In some cases, metadata relevant to a specific request may be associated with multiple database objects. For example, tables may be related to each other through formal relationships such as foreign keys or associations implemented from products available from SAP SE in Walldorf, Germany. Parsing frame 128 can determine the relevant database objects and related metadata, such as by following foreign key relationships or associations.

[0054] One or more of the metadata store 116, converter 120, or metadata traversal component 124 may be part of the metadata provider framework 126.

[0055] In some cases, the parsing framework 128 can access a set of scope definition functions 132. Scope definition functions 132 can be used to help determine the operation of the metadata traversal component 124. Scope definition functions 132 may include graph traversal algorithms, such as algorithms for determining the transitive hull. In some cases, scope definition functions may specify that the scope includes all hierarchical views related to the selected entity or dimension view, related dimension views, text views associated with the dimension view, and optional additional dimension views within a specified indirection level. Alternatively, scope definition functions may include parameters for determining the traversal scope, such as retrieving all related or specified metadata for a specific star schema, retrieving all metadata for a specific view and all tables or views referenced by that view, or retrieving all or selected metadata for one or more specified / related database artifacts and artifacts within a specified indirection level.

[0056] Although the scope definition function 132 is shown in the source system 104, the scope definition function may be implemented in the target system 108 in place of or in addition to the scope definition function 132 implemented in the source system.

[0057] Metadata exposure service 136 can access parsing frame 128, and can in turn communicate with import manager 144 of target system 108. Metadata exposure service 136 can accept metadata requests from import manager 144 and pass them to parsing frame 128, optionally with any scope-delimiting parameters that may be specified by target system 108.

[0058] Source system 104 may include a search service 140 that communicates with metadata store 116. Search service 140 may transmit all or part of the metadata available in metadata store 116. Search service 140 may allow target system 108 to specify search terms (e.g., strings, parts of strings) to return relevant results from metadata store 116, to specify a specific database object to return, a part of a database object (e.g., a column), or a collection of database objects (e.g., specifying a specific schema), or a combination of search terms and database object specifications.

[0059] Search service 140 communicates with target system 108 via user interface 148. User interface 148 allows users or applications to input search parameters and presents search results in response. In some cases, user interface 148 allows users to browse / navigate through metadata repository 116. User interface 148 also communicates with import manager 144, allowing users or applications to specify requests to retrieve metadata and, optionally, parameters for the search requests, such as scope delimiting features to be used by metadata traversal component 124. In other cases, scope delimiting features reside at target system 108, and import manager 144 makes requests to metadata exposure service 136 based on the scope delimiting features of target system 108.

[0060] User interface 148 can also communicate with connection manager 152, which in turn can communicate with import manager 144. Connection manager 152 can store parameters used to access source system 104, such as the source system's network location, login information, user credentials, etc. Communication parameters can be provided through user interface 148 at least in certain cases. In other cases, communication parameters can be retrieved from another source, such as from the configuration information of target system 108, for example, from configuration information associated with a specific application on the target system. Import manager 144 can retrieve connection information from connection manager 152 for use when connecting to metadata exposure service 136 of source system 104.

[0061] Target system 108 includes a metadata store 156. The metadata store 156 stores metadata, including metadata received from one or more source systems 104. The metadata may be stored in a format received from source systems 104 (e.g., CSN, XML), or may be converted to one or more formats used by target system 108, such as storing data in relational database tables, storing metadata in instances of abstract or composite data types (e.g., in logical data objects such as BusinessObjects), storing it in a data dictionary (e.g., an ABAP data dictionary), or as elements of a virtual data model (e.g., a CDS view), such as in software implemented from SAP SE in Walldorf, Germany.

[0062] Metadata store 156 can also manage changes to metadata using CRUD (Create, Read, Update, Delete) components 158. Metadata store 156 can manage conflicts between metadata received from source system 104 and metadata stored in target system 108. For example, a conflict may occur if metadata is updated on source system 104 after it has been initially transferred to target system 108, or if metadata is updated on target system after it has been imported from source system. Conflict resolution can include application rules, such as specifying that the most recent changes will be applied, or specifying that one version of source system 104 or target system 108 takes precedence over the other.

[0063] Metadata store 156 may also include a pre-deployment component 160, which, in other implementations, may be part of another component of target system 108 or may be implemented as a separate component of the target system. Pre-deployment component 160 may communicate with deployment component 164. Before sending a request to deployment component 164, pre-deployment component 160 may create appropriate artifacts (e.g., tables, instances of composite or abstract data types, artifacts in a virtual data model, or updates / modifications to existing tables, data types, or artifacts) to store the imported metadata.

[0064] The pre-deployment component 160 can perform other functions, such as editing the metadata to be imported. For example, the initial specification of the metadata to be imported may include dangling references, such as references to metadata or database artifacts that are not exposed for export and whose granularity is below the threshold specified for import, or references to data described by the metadata rather than the metadata itself. The pre-deployment component 160 can analyze the initial import specification (such as those received from the import manager 144 and subsequently from the metadata exposure service 136) and detect and remove such dangling references.

[0065] The pre-deployment component 160 can initiate the transfer of metadata and optionally associated data by invoking the deployment component 164. In a specific implementation, the deployment component 164 causes the creation of a table or view in database 112 and the import of metadata associated with that table. The created table or view can be implemented as a standalone table in database 112, or as a table identified as referencing an external table (e.g., a table stored in or accessible by source system 104). The table identified as referencing source system 104 can be implemented as a table that retrieves data from a table associated with the source system, or can be linked to such a table where data is dynamically retrieved at runtime upon request. The specific implementation of the database table referencing source system 104 can be a constructed virtual table implemented in software available from SAP SE in Walldorf, Germany. The constructed virtual table can be configured as a local table that receives and stores data copied from source system 104, or as a federated table where requested data is dynamically retrieved at runtime upon request.

[0066] Database 112 may include database objects 180a, 180b, and 180c, such as tables or views. Database object 180a may represent a purely local database object (e.g., local to the target system 108). Database object 180b may represent a database object associated with database object 184 of the source system 104, wherein data is copied and stored in database object 180b of the target system 108. Database object 180c may represent a database object associated with database object 184, but wherein data is obtained from database object 184 via federation at request, rather than being intended to be stored in database object 180c.

[0067] Example 3 - Example Operations in Metadata Identification and Retrieval

[0068] Figure 2A This is a sequence diagram of method 200, which represents a client's 204 request for metadata from the target system. Method 200 can be... Figure 1 Implemented in computing environment 100, where client 204 can represent one or more components of target system 108, such as user interface 148 or import manager 144. Use can correspond to respectively Figure 1 The client 204 (e.g., a component of the target system), metadata exposure service 206, parsing component 208, one or more scope delimitation functions 210 and metadata provider 212 of the corresponding components 108, 136, 128, 132, and 126 execute method 200.

[0069] At 214, client 204 provides a metadata request to metadata exposure service 206, such as by specifying a specific database artifact or its elements, such as a specific schema, table, or view. At 216, metadata exposure service 206 passes the request to parsing component 208. At 218, parsing component 208 invokes scope delimitation function 210 to determine the entity type associated with the database artifact specified by client 204. In some cases, the identifier of the scope delimitation function 210 to be used is included in the request from client 204, or the request includes the scope algorithm to be applied. In other cases, parsing component 208 determines the scope delimitation function 210 to be applied, including when the request from client 204 does not specify a scope delimitation function (and when the scope delimitation function 210 used by parsing component 208 can be a default function). At 220, scope delimitation function 210 returns the relevant entities to parsing component 208.

[0070] At 222, parsing component 208 sends the identifiers of the entities whose metadata should be retrieved to metadata provider 212, optionally identifying a subset of such metadata (e.g., only specific metadata fields). At 224, metadata provider 212 returns those identifiers along with the identifiers of the associated entities. Method 200 can loop through 218-224 until no more associated entities are identified, at which point the method can proceed to 226.

[0071] At 226, the parsing component 208 sends the identifier of the database artifact containing the relevant metadata to the metadata exposure service 206. At 228, the metadata exposure service 206 sends a request to the parsing component 208 to transform the metadata of all or selected database artifacts identified in 218-224. In some cases, the parsing component 208 includes... Figure 1 In other cases, converter 120 sends the request to the converter instead of sending the request to the parsing component to transform the metadata. In yet another example, the transformation request is first sent to parsing component 208, which then sends the request to converter 120.

[0072] At 230, parsing component 208 (or converter 120) sends a request for relevant metadata to metadata provider 212. At 232, metadata provider 212 returns the metadata to parsing component 208 (or converter 120). At 234, parsing component 208 (or converter) converts the metadata received from metadata provider 212 into a standard or serializable format, such as CSN or XML. At 236, the converted metadata is sent from parsing component 208 to exposure service 206. At 238, exposure service 206 returns the converted metadata to client 204. In another implementation, at 236, a list of database artifacts associated with the converted metadata is sent to client 204, but the actual metadata itself is not sent. In this case, client 204 can later request all or part of the actual metadata associated with these database artifacts.

[0073] Figure 2B The diagram illustrates import process 240, which may include process 200. It utilizes client 242 (such as the target system, which may be a cloud-based system) and import wizard 244 (which may be... Figure 1 The import user interface 148 is part of the import manager 246 (which may be the import manager 144), the metadata store 248 (such as a metadata store), the deployment service 250 (which may be the deployment component 164), and the local or source system 252 (such as... Figure 1 The source system 104) is used to execute the process.

[0074] At 254, the client submits an import request via import wizard 244, providing, for example, one or more identifiers of the database artifacts to be imported, or providing search criteria to identify such artifacts. At 256, import wizard 244 passes the request to source system 252. This request can be processed by the metadata data transfer framework of source system 252, such as metadata exposure service 136 (which in turn can communicate with parsing framework 128, scope delimitation function 132, or metadata framework 126).

[0075] At 258, the source system 252 returns the identifier of the relevant database artifact, such as the artifact identifier determined using the scope delimitation function 132. At 260, the import wizard 244 invokes the import manager 246 to retrieve at least a portion of the metadata associated with at least a portion of the database artifacts returned at 258.

[0076] At 262, import manager 246 sends a request for specified metadata to source system 252. At 264, the specified metadata is returned to import manager 246. At 266, import manager 246 saves the metadata to storage 248. At 268, storage 248 returns control to import manager 246, optionally including an indication of whether the saving was successfully performed.

[0077] At 270, the import manager 246 requests the deployment service 250 to deploy metadata. This may include linking the metadata to database artifacts of the target system, or creating and / or populating software objects, such as instances of abstract or composite data types with metadata. At 272, the deployment service 250 returns control to the import manager 246, optionally with an indication of whether the metadata has been successfully deployed. At 274, the import manager 246 returns control to the import wizard, optionally with an indication of whether earlier operations were successfully performed, including identifying any errors that may have occurred, and then at 276, the import wizard 244 returns control / this information to the client 242.

[0078] Processes 200 and 240, or similar processes (e.g., those comprising one or more steps from one or both of these processes), can be used in the process of automatically generating database artifacts based on retrieved metadata, and in linking the generated database artifacts to metadata describing the database artifacts and data stored for the database artifacts in the source system. Figure 2C An example of this process is provided, as shown in process 280. In 282, the user or process selects the metadata to be imported. The metadata can be all metadata associated with one or more database artifacts, or a portion of such data. Typically, the metadata includes at least enough metadata to describe the schema of the source system's database artifacts, such as columns in tables or views, the names or identifiers of these columns, and the data types associated with these columns.

[0079] In 284, such as by Figure 1 The import manager 144 or user interface 148 receives metadata. At 286, a database artifact is created at the target system based on the imported metadata, wherein the database artifact can be created as a local artifact or as a virtual artifact linked to the database artifact on the source system (e.g., through data replication or federation).

[0080] In section 288, the database artifacts created on the target system are linked to their corresponding database artifacts on the source system. For example, the API on the source system used to retrieve data from the database artifacts can be used... Figure 1The metadata exposure service 136 is used to locate and link to database artifacts on the target system. 290, the target system can use the API to obtain data and optional additional metadata of the database artifacts on the target system from the source system.

[0081] One or more data types, such as abstract or composite data types, can be used to help implement process 280. For example, an abstract data type can be defined to represent a database artifact and can contain information that can be used to obtain data or metadata from the database artifact. Data types can include data members that store API locations or data members that store API types. When a database artifact needs metadata or data, a method can be invoked for an instance of the data type specific to the database artifact. This method can invoke an API on the source system to retrieve the requested information.

[0082] Retrieving data / metadata from a source system can be facilitated by having information such as APIs in the source system that can be used to retrieve data / metadata from an identified database artifact, described in a standard format. Therefore, the disclosed techniques can help avoid situations where data / metadata cannot be retrieved for a database artifact on the source system due to an unknown API. Similarly, a repository / library with APIs can help avoid problems that might arise from having different types of APIs. The library can be used to locate the appropriate API, and the type information stored for that API can help determine the appropriate method for obtaining data from that API (e.g., instances representing the abstract data type of the imported database artifact can invoke different APIs / import methods depending on what APIs are available on the source system to obtain data for a given database artifact).

[0083] In some cases, for a database artifact in the source system, there may be one method for retrieving data and a separate method for retrieving metadata; in other cases, a single method can be used to obtain both data and metadata. Instances of data types can act as a link between a specific database artifact and information about the artifact maintained in the source system. In a specific implementation, when a database artifact is created in the target system, or at least created using publicly available technologies, instances of the data type used to link the database artifact to the data / metadata in the source system are automatically created.

[0084] In some cases, the disclosed techniques can be used to create a single database artifact. However, in other cases, the disclosed techniques can be used to create multiple database artifacts. That is, for example, identifiers or search criteria for database artifacts at the source system can be used to identify multiple related database artifacts at the source system (such as using scope delimitation features). Database artifacts can be created at the target system using metadata from the source system, linked to appropriate APIs, and data and / or additional metadata retrieved from the source system and populated into the target system.

[0085] The disclosed techniques can be implemented in different ways if needed. For example, in some cases, instead of storing information about imported database artifacts in instances of abstract or composite data types, such information can be stored in a relational database table. For instance, the table could have fields with database artifact identifiers, fields with API location identifiers, and fields with API type identifiers. The import process / component can access the database table to determine how to retrieve the artifact's data / metadata, and the table can thus act as a link between the database artifact and the data / metadata in the source system.

[0086] This disclosure provides techniques, such as process 280, for creating database artifacts on a target system based on a database artifact from a source system. Specifically, the disclosed techniques allow for the automatic creation of database artifacts on the target system and the automatic import of associated data and metadata from the source system. Therefore, the database artifacts can be quickly made available to the user without requiring any manual action (except for providing initial import criteria).

[0087] The use of metadata exposure service 136 can help automate the database artifact creation process because it can help locate the API used to obtain data / metadata and provide information on how the data / metadata can be accessed (e.g., protocol / API type). The parsing framework helps ensure that relevant metadata is obtained and can be used to create database artifacts that may be relevant to a user's request. That is, a user can specify a single database artifact, or search criteria, and the exposed techniques can lead to the creation of one or more database artifacts at the target system against relevant database artifacts in the source system (e.g., as determined by the scope delimitation function), and the population of the target system with corresponding data / metadata from the source system.

[0088] Example 4 – Example Software Objects Facilitating Metadata Discovery and Exchange

[0089] Figure 3This diagram illustrates how information about specific database artifacts, which have metadata or are associated with metadata, can be exposed to a target system. The source system can provide an API for obtaining information about the database artifacts. The API can be in different formats, between different source systems, or within a single source system. For example, the API can be implemented in OData format, SQL format, or some other format.

[0090] Figure 3 The diagram illustrates a portion of API 310 expressed in SQL format. Note that the SQL format API 310 specifies a concrete database artifact 314, in this case, the view "product". Database artifact 314 is specified by a schema name and an entity name.

[0091] Figure 3 The diagram also illustrates a standardized representation 320 of API 310. The standardized representation 320 includes an identifier 322 and a reference to the API 324 (e.g., in the form of a URI). The standardized representation 320 may have a type 326, which may indicate the protocol used by the referenced / source API 310, such as whether the API is an SQL API or an OData API. The standardized representation 320 may have an element 330, which may identify one or more use cases for API 310, such as whether the API is intended for use in ETL processes, for different types of processes, or can be used for general metadata discovery and retrieval. Similarly, the standardized representation 320 may specify a specific type or level of coverage 332, which may indicate which portion of the metadata is already available to the database entity.

[0092] In the example shown, a single database artifact 314 has been specified. In other cases, a single representation 320 can specify multiple database artifacts, where the coverage can be the same or different for different database artifacts.

[0093] Figure 3 The diagram also shows a normalized representation 330 of database artifact 314, and metadata 332 of the artifact. The data and metadata in the normalized representation 330 can be exposed using SQL API 310, and information about it can be made available using the normalized API representation 320. The normalized representation 330 includes an identifier 314 of the database artifact, and this identifier is included in the normalized API representation 320. In this way, the normalized API representation 320 links the specific database artifact to the SQL API 310 that can be used to obtain data from the database artifact, and links the metadata associated with the data through a link to representation 330, which can in turn be generated from the native representation of metadata on the source system.

[0094] Note that, generally, the standardized representation of metadata and the standardized representation of the concrete entity from which data can be retrieved (and associated with the metadata) can be in a standardized format. That is, metadata and database entity information can be represented in a common format, regardless of the actual storage format of the metadata or data, or the protocol (e.g., API type) used to access such data or metadata. Accordingly, if the API corresponding to API 310 is in a different format (e.g., OData), the standardized API representation 320 can have different identifier and type information, but the overall structure of the standardized representation can be the same (e.g., having the same fields or keys). In the same way, the data of a concrete entity can be expressed in a common format in both the entity's standardized representation 330 and the standardized API representation 320, which can facilitate the target system in finding information and database artifacts about the API that can be used to obtain data or metadata associated with a concrete database entity on the source system.

[0095] Example 5 – Example Metadata Exposure Service

[0096] Figure 4 The diagram shows that it can be used. Figure 1 The metadata exposure service 136 exposes information that has been exposed by the metadata exposure service 404.

[0097] Metadata exposure service 404 can provide information about entity 408, which can be a database artifact such as a table or view. Information for entity 408 may include the entity's name or identifier (such as a reference to an entity expressed in a serializable format such as CSN or XML), a language-related description of the entity, optionally a publication contract (which can be used to help maintain a set of entities that can be used with a specific contract identifier, and can help ensure that the correct set of entities is selected, such as keeping the set of entities stable relative to incompatible changes such as changes to which the application has not yet been updated to use), publication status (such as whether the entity is published, obsolete, deprecated, not yet published, etc.), and information indicating when the entity was last modified. Optionally, other information may be included, such as when the entity was first created, or the identifier of the user, process, or application that created or last updated entity 408.

[0098] Entity 408 can be associated with modeling pattern 412. Modeling pattern 412 can be used to indicate what a specific entity 408 is used for. In some cases, entity 408, such as a view, may have a primary purpose, which can be indicated by modeling pattern 412. Optionally, modeling pattern 412 can list multiple uses for a given entity 408, where in some cases, a given use can be labeled as the primary use.

[0099] Entity 408 can also be associated with source 416, where the source can be a standardized (e.g., CSN, XML) representation of the entity (e.g., the entity's definition or content). In some cases, the source 416 of entity 408 may include language-specific content. Such content can be stored as localized data 420, which can be retrieved by navigating over the specific entity 40.

[0100] Metadata exposure 404 can be associated with context 424. Context 424 can be used to identify metadata, such as metadata belonging to a specific repository or application. That is, context 424 can provide namespace information, or be used for purposes similar to namespace information. Context 424 may include additional information, such as a label or description for entity 408.

[0101] Metadata exposure 404 can be associated with type 428. Type 428 can be used to identify the specific type of entity 408 (e.g., view, table, column, stored process, etc.) and can also contain definition information for that type (e.g., schema information, such as specific metadata elements associated with a given type, which essentially provide the structure or definition of the specific type). Type 428 can be used or associated with a specific source 416, and can in turn be referenced by localized data 420 (e.g., information about the specific language associated with that type, such as a language-related description of that type).

[0102] As already described, it is generally desirable to obtain not only the metadata of a single entity 408, but also the metadata of a set of related entities. Therefore, a given entity 408 of metadata exposure 404 can be linked to entities 432 in the scope, which provides a list of related entities. Related entities can include a complete list of related entities 408, or a smaller subset of these entities. Scope delimitation features can be used to define entities 432 in the scope, and the available scope delimitation features are provided by scope 436.

[0103] Metadata can be specified in different ways, including through annotations (e.g., annotations in CSN). Glossary 440 can provide definitions for various annotations.

[0104] Location 444 can store information about a specific location associated with metadata exposure service 404, such as the location represented in localized data 420. Location 444 can be used, for example, to filter data associated with metadata exposure 404 by location.

[0105] Example 6 – Example computing environment with database artifact extensions and its examples

[0106] In some cases, the disclosed techniques, such as metadata exposure services, can be used to retrieve metadata from the source system as a separate local table, a local table with data copied from the source system, or a virtual table when data is transferred to the target system (e.g., in response to a query from the target system to a database associated with the target system). However, the disclosed techniques can be used in other scenarios. Specifically, the disclosed techniques can be used to augment standard content with client-specific content. For example, after installing or upgrading a standard database schema, extensions to this content can be retrieved from the client's database system.

[0107] Figure 5 The illustration depicts a computing environment 500 in which the disclosed technology can be implemented. The computing environment 500 includes a central database system 504, which, in some implementations, may be a cloud-based database system. The central database system 504 may include standard content 508, such as database artifacts 512, 514, where database artifacts may be tables or views. The standard content 508 may be content associated with, for example, a specific application or a set of applications, and typically all or most of the content is associated with many clients. The standard content 508 can be installed from package 518 and can be updated or upgraded using update 522 (which may also be implemented as a package).

[0108] In some cases, a client can modify all or part of the standard content 508. In other cases, the standard content 508 is protected from client modification, especially if the standard content is shared by multiple clients, or if modification of the standard content would result in a loss of application functionality. If the standard content 508 cannot be modified by the client, then in some implementations, it can be extended by the client. That is, the database artifact of the standard content 508 can be "locked," but the client may be able to create other database artifacts that are added to or modified from the standard database artifact.

[0109] Figure 5 A computing environment 500 including tenants 526a and 526b is shown. In some cases, tenants 526a and 526b access standard content 508 via a shared container 530, as shown for tenant 526a (where the tenant container is not shown to include artifacts 512 and 514). In other cases, the tenant container may include artifacts of standard content 508, as shown for tenant 526b, where the container includes artifact 512.

[0110] The tenant container is shown as including extensions 534a and 534b to artifact 512. Extensions 534a and 534b can make various modifications to artifact 512, such as adding, removing, or changing the artifact's data or metadata. As an example of changing data, extension 534a can add columns to a view or table represented by artifact 512. For example, artifact 512 can represent employee data with fields such as name, social security number, job identifier, and wage rate. Given the vaccines introduced in 2020-2021, employers may want to track whether employees have been vaccinated, the date of vaccination, etc. For various reasons, it may take time before a flag indicating whether an employee has been vaccinated is introduced into artifact 512 via standard content 508. Clients (represented by tenants 526a and 526b) can include extensions 534a and 534b that add a vaccination flag to artifact 512. In some cases, artifacts for a specific client or tenant are created based on standard content 508 and any extensions defined for / by the client. For example, workpiece 542 can be created by combining or merging workpiece 512 with extensions 534a or 534b (e.g., using DDL statements).

[0111] In some implementations, the extended data is imported from client system 550 and stored in containers of tenants 526a and 526b, or otherwise stored in central database system 504. In other cases, the data is stored in another component of computing environment 500, or obtained from client system 550 as part of the artifact creation process, but not stored outside of client system 550.

[0112] Metadata infrastructure 552 can be used to obtain metadata for extension 534a from the relevant client system 550. Metadata infrastructure 552 may include... Figure 1 The source system 104 comprises components 116-140. The client system 550 may include database artifacts 556, which may correspond to database object 184 of the source system 104. Figure 1 In this context, one or more database objects can be database artifacts, which are generated by combining or merging the standard definition of a database artifact with extensions created for use with that database artifact. That is, database object 184 can correspond to database artifact 542.

[0113] Metadata infrastructure 552 includes metadata 554 of artifact 512 and metadata 556 that extends artifact 552. Metadata 554 and 556 can be used to describe and create artifact 558 in at least some implementations.

[0114] Through communication with about Figure 1The discussed method retrieves extended data from client system 550. That is, central system 504 or target system 558 communicating with central system 558 may include similar... Figure 1 Components 144-168 are components of the Components 144-168. In some implementations, a portion of Components 148-168 can be omitted from the use cases of the Computing Environment 500. For example, when installing, updating, or upgrading standard packages, or when the system automatically attempts to retrieve client-specific information, importing UI148 can be omitted.

[0115] The logic for obtaining information from client system 550 can be broadly similar to method 200 of Figure 2. However, this method may optionally remove steps from method 200, or steps may be added. As discussed, the step of receiving input from the user interface for the metadata / database artifact to be imported can be omitted. A step can be added to check the client system 550 for extensions to the database artifact of standard content 508. If no extension exists for a specific database artifact, no further action is required. If an extension exists, the relevant metadata can be retrieved and used to define database artifact 542, and the metadata may optionally be stored in containers of tenants 526a, 526b.

[0116] In some cases, metadata can be obtained multiple times from the client system 550. For example, metadata can be obtained when the client is "on-premises" and in response to subsequent updates / changes made by the client.

[0117] The update service 560 can be used to determine what metadata should be sent, which may include selecting a single version of metadata or hierarchical versions of metadata. The update service 560 can apply various rules 562, which may include priority rules. For example, a priority rule may specify that the latest version of the metadata artifact should be used. Alternatively, a priority rule may specify how multiple metadata versions should be combined, such as overwriting metadata elements from earlier versions with changes made in later versions, where changes from the latest version are typically applied in cases of conflict with earlier versions. Unmodified metadata elements from the base version will be included in the final metadata in their original form. In other cases, a priority rule may specify that at least some metadata is appended. For example, if the metadata is specified as an array or enumerated list of values, the rule may specify whether values ​​are added or overwritten. Whether an element is added or overwritten can depend on the nature of the metadata element, so rules can be specified at the granularity of the specific metadata element, if appropriate.

[0118] Client system 550 may include logging component 564. Logging component 564 may include change list 566, which may identify metadata that should be imported because it does not yet exist in central database system 504 or target system 558, or has been changed since the last import. Change list 566 may also specify what metadata to import, such as the result of applying rule 562. Change log 568 can be used to track the progress of metadata transfer from client system 550 to central database system 504 or target system 558, such as tracking failed transactions and error messages, making it possible to determine whether the transfer was completed as expected / indicated. In some cases, instead of including change log 568 in client system 550, it may be included in central database system 504 or target system 558, or in addition to including it in client system 550, it may also be included in central database system 504 or target system 558.

[0119] Figure 5 Examples of standard content 508 and extensions to such standard content are also illustrated in the form of content 570 of artifact 512 and content 580 of extension 534a. Content 570 includes data selection 572, which includes data elements 574a and 574b. Data selection 572 can be a query, such as an SQL query. Content 570 can include metadata elements 576a and 576b, such as elements that provide semantic information about data elements 574a and 574b. Content 570 may further include annotations 578a, 578b, and 578c, where annotations can indicate characteristics of artifact 512 or control the use of artifacts, such as defining whether the artifact is exposed to end users.

[0120] Content 580 of extension 534 can add, remove, or change data elements of content 570, and can add or modify comments of content 570. As shown, content 580 includes comment 582a that modifies comment 578a, comment 582b that sets the value of comment 578c to NULL, and comment 582c that has already been added to content 570. Since comment 578b has not been removed or modified, it will remain in workpiece 570 when the workpiece is merged with workpiece extension 580.

[0121] At least in some cases, data elements and metadata can be handled in a manner similar to annotations. Artifact extension 580 shows that metadata element 584a has been added to content 570, and that metadata element 576a has been removed by setting the value of metadata element 576b to NULL using metadata element 584b. Content 580 may include additional data elements or additional selections 588 of data elements, or it may remove data elements, such as the statement 590 in content 580 that sets the value of data element 576a to NULL.

[0122] Example 7 – Example table elements including semantic identifiers

[0123] Database systems typically include information repositories that store information about the database schema. For example, PostgreSQL includes an INFORMATION_SCHEMA, which contains information about tables and certain table components in the database system, such as attributes (or fields) and their associated data types (e.g., varchar, int, float). Other database systems or query languages ​​contain similar concepts. However, as mentioned above, these types of repositories typically store only technical information about database components, rather than semantic information.

[0124] Other database systems, applications, or frameworks that operate using the database layer may include repositories storing semantic information about the data. For example, SAP SE in Walldorf, Germany, provides the ABAP programming language that can be used in conjunction with database systems. ABAP provides the ability to develop database applications whose nature (including the vendor) is agnostic to the underlying relational database management system. To some extent, this capability is achieved using a data dictionary. A data dictionary may include at least some information similar to that maintained in an information schema. However, a data dictionary may include semantic information about the data, as well as optionally additional technical information.

[0125] Furthermore, a data dictionary can include textual information about fields in a table, such as human-readable descriptions of the purpose or use of the fields (sometimes in different languages, such as English, French, or German). At least in some cases, textual information can serve as semantic information for the computer. However, other types of semantic information are not necessarily (at least not readily) human-understandable, but may be easier for a computer to process than parsing textual information primarily intended for human use. A data dictionary can also contain or express relationships between data dictionary objects through various characteristics (which may be reflected in metadata), such as allowing the data dictionary to reflect that dictionary objects are assigned to packages, thus having relationships with each other through package assignment. The information in the data dictionary may correspond to metadata that can be retrieved by the target system from the source system according to the techniques previously described in this disclosure.

[0126] As used in this article, "technical information" (or technical metadata) refers to information that describes data; it includes information such as the type of value that can be used to interpret the data, which can influence how the data is processed. For example, the value "6453" can be interpreted (or represented) as an integer, a floating-point number, a string, or an array of characters, among other possibilities. In some cases, a value can be processed differently depending on whether it is a number (such as an integer or a floating-point number) or treated as a collection of characters. Similarly, technical information can specify acceptable values ​​for data, such as the allowed length or the number of decimal places. Technical information can specify the characteristics of data without considering what the data represents or "means." However, database system designers, knowing the semantic characteristics of the data, can certainly choose specific technical characteristics for specific data—for example, "If I want to use a value to represent a person's name, I should use a string or an array of characters instead of a floating-point number." On the other hand, at least in some cases, the data type may be a type that database administrators or users do not expect. For example, instead of using a person's name, a single numeric or alphanumeric identifier might be used to identify data associated with that person, which may be contrary to intuition based on the "meaning" of the data (e.g., "I don't consider myself a number").

[0127] As used herein, “semantic information” (or semantic metadata) refers to information that describes the meaning or purpose of data, which can be directed at humans or at computer processes. As an example, technical data information might specify that data should be obtained with a value in the format “XXX-XX-XXXX”, where X is an integer between 0 and 9. This technical information can be used to determine how the data value should be processed, or whether a specific value is valid (e.g., “111-11-1111” is valid, but “1111-11-1111” is invalid), but it does not indicate what the value represents. Semantic information associated with data might indicate whether the value is a social security number, phone number, routing address, etc.

[0128] Semantic information can also describe how data will be processed or displayed. For example, knowing that the data is a phone number might allow the value to be displayed in one part of the GUI rather than another, or it might allow specific processing rules to be invoked or not, depending on whether those rules apply to "phone number". At least in some cases, "semantic information" can include other types of information that can be used to describe the data or how or how the data should be used or processed. In specific cases, the data may be associated with one or more of the following: labels, such as human-understandable descriptions of the data (e.g., "phone number"), documents, such as descriptions of what information should be included in fields with labels (e.g., "Enter an 11-digit phone number including the area code"), or information that can be used in help screens (e.g., "Enter your home phone number here").

[0129] Typically, technical information must be provided for data. For example, in the case of fields in a database table, it is usually necessary to provide names or identifiers for the fields and their data types. The name or identifier of a field may or may not be used to provide semantic information. That is, a database designer might choose names like “Employee_Name,” “EMPN,” or “3152.” However, because the name or identifier is used to locate / distinguish the field from another field, in the context of this disclosure, it is considered technical information, not semantic information, even if it can easily convey meaning to a human. In at least some implementations, the use of semantic information is optional. For example, even when using a data dictionary, some fields used in database objects (such as tables, but also other objects that are typically associated with one or more tables in the underlying relational database system) can be specified without using semantic information, while other fields are associated with semantic information.

[0130] Figure 6 This is an example entity-relationship (ER) type diagram illustrating a data schema 600 or metadata model related to a driver's accident history. Schema 600 (which can be part of a larger schema, with other components not shown) Figure 6 (As shown in the figure) may include Form 608 associated with a license holder (e.g., an individual with a driver's license), Form 612 associated with the license, Form 616 indicating an accident history, and Form 604 indicating a car (or other vehicle).

[0131] Each of tables 604, 608, 612, and 616 has multiple attributes 620 (although, in some cases, a table may have only one attribute). For a specific table 604, 608, 612, or 616, one or more attributes 620 can serve as a primary key—uniquely identifying a specific record within a tuple and being assigned as the primary method for accessing tuples in the table. For example, in table 604, the Car_Serial_No attribute 620a serves as the primary key. In table 616, the combination of attributes 620b and 620c serves as the primary key.

[0132] Tables can reference records that are associated with the primary key of another table using foreign keys. For example, the license number table 616 has an attribute 620d in table 616 that is a foreign key and is associated with the corresponding attribute 620a in table 604, Car_Serial_No. Foreign keys can be used for various purposes. Foreign keys can link specific tuples in different tables. For example, the foreign key value 8888 of attribute 620d will be associated with the specific tuple in table 604 that has that value for attribute 620a. Foreign keys can also serve as constraints, preventing the creation of records with (or being changed to have) foreign key values ​​that do not exist in the primary key value of the referenced table. Foreign keys can also be used to maintain database consistency, where changes to primary key values ​​can propagate to tables where the attribute is a foreign key.

[0133] Tables may have other attributes or combinations of attributes that can be used to uniquely identify tuples, but these are not primary keys. For example, table 616 has a substitution key formed by attributes 620c and 620d. Therefore, unique tuples in table 616 can be accessed using a primary key (e.g., as a foreign key in another table) or through association with that substitution key.

[0134] Schema information is typically maintained at the database layer, such as the software layer associated with the location that maintains table values ​​(e.g., in an RDBMS), and typically includes identifiers for tables 604, 608, 612, and 616, and the names 626 and data types 628 of their associated attributes 620. Schema information may also include at least some information that can be conveyed using flags 630, such as whether a field is associated with a primary key or indicates a foreign key relationship. However, other relationships that include more informal associations may not be included in the schema associated with the database layer (e.g., PostgreSQL's INFORMATION_SCHEMA).

[0135] Example 8 - Example table elements including semantic identifiers

[0136] Figure 7This is a diagram illustrating the elements of database schema 700 and how they can be related to each other. At least in some cases, database schema 700 can be maintained outside the database layer of a database system. That is, for example, database schema 700 can be independent of the underlying database, including the schema used by the underlying database. Typically, database schema 700 is mapped to the schema of the database layer (e.g., ...). Figure 6 The schema 600 allows records or portions thereof (e.g., specific values ​​of specific fields) to be retrieved via the database schema 700.

[0137] Database schema 700 may include one or more packages 710. Package 710 may represent organizational components used to classify or categorize other elements of schema 700. For example, package 710 may be replicated or deployed to various database systems. Package 710 may also be used to implement security restrictions, such as restricting access to specific schema elements by specific users or applications.

[0138] Package 710 may be associated with one or more fields 714 (i.e., semantic identifiers or semantic information of a specific type). Conversely, field 714 may be associated with one or more packages 710. For example, field 1, 714a is associated only with package 710a, while field 2, 714b is associated with both packages 710a and 710b. In at least some cases, field 714 may specify which packages 710 can use that field. For example, a field 714 associated with materials used in a manufacturing process might be used by a process control application but not by a human resources application.

[0139] In at least some implementations, although multiple packages 710 can access domain 714 (and the database objects that merge that domain), the domain (and optionally other database objects such as table 718, data element 722, and field 726, described in more detail below) is primarily assigned to one package. Assigning domain 714 and other database objects to a single package helps in creating logical (or semantic) relationships between the database objects. Figure 7 In the diagram, the assignment of domain 714 to packet 710 is shown as a solid line, while access permissions are shown as dashed lines. Therefore, domain 714a is assigned to packet 710a, and domain 714b is assigned to packet 710b. Packet 710a can access domain 714b, but packet 710b cannot access domain 714a.

[0140] Note that at least some database objects, such as Table 718, may include database objects associated with multiple packages. For example, Table 718 (Table 1) may be assigned to package A and has fields assigned to packages A, B, and C. The use of the fields in Table 1 assigned to packages A, B, and C creates semantic relationships between packages A and B, as well as package C. These semantic relationships can be further interpreted if the fields are associated with a specific domain 714 (i.e., the domain can provide further semantic context for database objects associated with objects in another package (rather than being assigned to a generic package).

[0141] As will be explained in more detail, field 714 can represent the finest-grained unit from which database table 718 or other schema elements or objects can be constructed. For example, field 714 can at least be associated with a data type. Each field 714 is associated with a unique name or identifier and is typically associated with a description, such as a human-readable text description that provides the semantic meaning of the field (or an identifier that may be associated with the human-readable text description). For example, one field 714 could be an integer value representing a telephone number, another could be an integer value representing a part number, and yet another integer field could represent a social security number. Thus, field 714 can maintain a common and consistent use (e.g., semantic meaning) across schema 700. That is, for example, whenever a field representing a social security number is used, even if the field or data element has different identifiers or other characteristics for different tables, the corresponding field can be identified as having that meaning.

[0142] Schema 700 may include one or more data elements 722. Each data element 722 is typically associated with a single field 714. However, multiple data elements 722 may be associated with a specific field 714. Although not shown, multiple elements of table 718 may be associated with the same data element 722, or they may be associated with different data elements having the same field 714. Among other things, data elements 722 may be used to allow customization of the field 714 for a specific table 718. Thus, data elements 722 may provide additional semantic information for the elements of table 718.

[0143] Table 718 includes one or more fields 726, at least a portion of which are mapped to data elements 722. Fields 726 may be mapped to a database layer schema, or table 718 may be mapped to a database layer in another manner. In any case, in some embodiments, field 726 is mapped to a database layer in a certain way. Alternatively, the database schema may include semantic information of elements equivalent to schema 700, including fields 714.

[0144] In some embodiments, one or more of the fields 726 are not mapped to the domain 714. For example, field 726 may be associated with primitive data components (e.g., primitive data types such as integers, strings, booleans, character arrays, etc.) where the primitive data components do not include semantic information. Alternatively, the database system may include one or more tables 718 in which no field 726 associated with the domain 714 is included. However, the disclosed techniques may include a schema 700 (which may be separate from or incorporated into the database schema) comprising a plurality of tables 718 having at least one field 726 associated with the domain 714 directly or through data element 722.

[0145] Example 9 – Example Data Dictionary Component

[0146] Pattern information, such as with Figure 7 Information associated with schema 700 can be stored in a repository such as a data dictionary. At least in some cases, the data dictionary is independent of the underlying relational database, but is mapped to it. This independence allows the same database schema 700 to be mapped to different underlying databases (e.g., databases using software from different vendors or different software versions or products from the same vendor). The data dictionary can be persistent, such as being maintained in stored tables, and can be maintained wholly or partially in memory. An in-memory version of the data dictionary can be called a dictionary buffer.

[0147] Figure 8The diagram illustrates a database environment 800 with a data dictionary 804, which can access a database layer 808, for example, through mapping. The database layer 808 may include schemas 812 (e.g., INFORMATION_SCHEMA in PostgreSQL) and data 816, such as data associated with tables 818. Schemas 812 include various technical data items / components 822, which may be associated with fields 820, such as field names 822a (which may or may not correspond to a human-readable description of the field's purpose, or otherwise explicitly describe the semantic meaning of the field's values), field data types 822b (e.g., integer, variable-length string, string, boolean), length 822c (e.g., the size of numbers allowed in the field's values, the length of strings, etc.), and the number of decimal places 822d (optionally, for appropriate data types, such as for a floating-point number of length 6, specifying whether the value represents XX). XXXX or XXX.XXX), position 822e (e.g., the position in the table where the field should be displayed, such as the first field to be displayed, the second field to be displayed, etc.), optionally, default value 822f (e.g., "NULL", "0", or some other value), NULL flag 822g indicating whether the field allows NULL values, primary key flag 822h indicating whether the field is the primary key of the table or used in the primary key of the table, and foreign key element 822i that can indicate whether field 820 is associated with the primary key of another table, and optionally, the identifier of the table / field referenced by the foreign key element. Specific pattern 812 may include... Figure 8 822 shows more, fewer, or different technical data items.

[0148] Table 818 is associated with one or more values ​​826. Values ​​826 are typically associated with one or more fields 820 defined using technical data elements 822. That is, each row 828 typically represents a unique tuple or record, and each column 830 is typically associated with the definition of a specific field 820. Table 818 is typically defined as a set of fields 820 and assigned a unique identifier.

[0149] The data dictionary 804 includes one or more packages 834, one or more fields 838, one or more data elements 842, and one or more tables 846, which may at least substantially correspond to... Figure 7 Similar components with similar names are 710, 714, 722, and 718. For example, in... Figure 7As explained in the discussion, package 834 includes one or more (typically multiple) domains 838. Each domain 838 is defined by multiple domain elements 840. Domain elements 840 may include one or more names 840a. Names 840a are used to uniquely identify a specific domain 838 in certain circumstances. Domain 838 includes at least one unique name 840a and may include one or more names that may or may not be unique. Names that may or may not be unique may include versions of the name or description of the domain 838 of various lengths or levels of detail. For example, name 840a may include text that can be used as a label for domain 838 and may include short, medium, and long versions, as well as text that can be designated as headers. Alternatively, name 840a may include a main name or identifier and a brief description or field label that provides human-understandable semantics for domain 838.

[0150] In at least some cases, data dictionary 804 can store at least a portion of name 840a in multiple languages, such as making domain labels available for multiple languages. In embodiments of the disclosed technology, when domain information is used to identify relationships between tables or other database elements or objects, including searching for specific values, information in multiple languages, such as name 840a, can be searched. For example, if "customer" is specified, the German and French portions of name 840a, as well as the English version, can be searched.

[0151] Field element 840 may also include information at least similar to that included in pattern 812. For example, field element 840 may include a data type 840b, a length 840c, and a number of decimal places 840d associated with a related data type, which may correspond to technical data elements 822b, 822c, and 822d, respectively. Field element 840 may include conversion information 840e. Conversion information 840e can be used to convert (or mutually convert) values ​​input to field 838 (optionally, including those modified by data element 842). For example, conversion information 840e may specify that numbers of the form XXXXXXXXX should be converted to XXX-XX-XXXX, or that numbers should have decimal places or commas separating groups of numbers (e.g., formatting 1234567 as 1,234,567.00). In some cases, field conversion information for multiple fields 838 may be stored in a repository, such as a field catalog.

[0152] Domain element 840 may include one or more value limits 840f. Value limits 840f may specify, for example, whether negative values ​​are allowed or not, or a specific range or threshold of values ​​acceptable to domain 838. In some cases, an error message or similar indication may be provided when attempting to use a value that does not conform to value limit 840f with domain 838. Domain element 840g may specify one or more packages 834 that are allowed to be used with domain 838.

[0153] Domain element 840h can specify metadata to record creation or modification events associated with domain element 838. For example, domain element 840h can record the identity of the user or application that last modified domain element 840h, as well as the time the modification occurred. In some cases, domain element 840h stores a larger history of the creation and modification of domain 838, including the complete history.

[0154] Domain element 840i can specify the original language associated with domain 838 (including name 840a). For example, domain element 840i may be useful when determining whether name 840a should be translated into another language, or how such a translation should be done.

[0155] Data element 842 may include data element fields 844, at least some of which may be at least substantially similar to domain element 840. For example, data element field 844a may correspond to at least a portion of name domain element 840a, such as being (or including) a unique identifier for the specific data element 842. The field label information described relative to name domain element 840a is shown as being divided into short description label 844b, medium description label 844c, long description label 844d, and header description 844e. As described for name domain element 840a, the labels and headers 844b-844e may be maintained in one or more languages.

[0156] Data element field 844f can specify the field 838 used with data element 842, thereby incorporating the characteristics of field element 840 into the data element. Data element field 844g can represent the default value of data element 842 and can be at least similar to the default value 822f of pattern 812. Data element field 844h, which is created / modified, can be at least substantially similar to field element 840h.

[0157] Table 846 may include one or more table elements 848. At least a portion of table element 848 may be at least similar to domain element 840, such as table element 848a being at least substantially similar to domain element 840a or data element field 844a. The description table element 848b may be similar to the description and header labels described in conjunction with domain element 840a, or the labels and header data element fields 844b-844e. Table 846 may be associated with a type using table element 848c. Example table types include transparent tables, clustered tables, and pooled tables, such as those used in database products available from SAP SE in Walldorf, Germany.

[0158] Table 846 may include one or more field table elements 848d. Field table elements 848d may define specific fields of a specific database table. Each field table element 848d may include an identifier 850a for the specific data element 842 used for that field. Identifiers 850b-850d may specify whether the field is a primary key or part of the table (identifier 850b), or whether it has a relationship with one or more fields of another database table, such as being a foreign key (identifier 850c) or a relation (identifier 850d).

[0159] The table element 848e that is created / modified can be at least substantially similar to the field element 840h.

[0160] Example 10 – Example Metadata Model

[0161] Figure 9 The diagram illustrates the definition of metadata model 900. Specifically, metadata model 900 represents a view, such as a Core Data Services view from SAP SE in Walldorf, Germany, and is expressed in a format such as CSN. Metadata model 900 can include various different components, at least some of which can be considered metadata models. That is, metadata model 900 can be a model that is at least partially based on multiple sub-models. Sub-models can specify specific aspects of the overall metadata model 900.

[0162] Metadata model 900 may optionally include one or more annotations 904. Annotations can be metadata components that can be added to the metadata model. For example, a provider may supply a base model, while individual users or customers may wish to add metadata specific to their operating environment and use cases. Therefore, the ability to add annotations can enhance usability by allowing customized metadata elements without affecting other users of the base metadata model. Annotations can be specified for different software layers or frameworks.

[0163] In the example shown, comment 904 can be indicated as a comment using specific syntax elements, such as by prefixing it with the "@" symbol. In at least some cases, comment 904 can also be indicated by placing it in an appropriate part of the metadata model, such as in the header section assigned to the comment or another section. In some cases, comment 904 can reference other metadata models, such as the metadata model of a data source, or it can reference a data source associated with a metadata model. In either case, such an association 904 can create a dependency between metadata model 900 and other metadata models / data sources.

[0164] Metadata model 900 may include instructions 908, in this case SQL statement 910, which defines a core metadata model / object with identifier 912 (which can be used, for example, for later access or activation, such as instantiating the metadata model). Specifically, instruction 908, as shown, defines a view. Note 904 further specifies the characteristics of the view, as do other parts of metadata model 900, which will be described further.

[0165] Instruction 908 may specify one or more data sources 916. Data source 916 may define the data to which at least a portion of the metadata of metadata model 900 will be applied, and may also supply additional metadata to metadata model 900. Note that metadata model 900 may depend on the referenced data source 916, at least in some sense. For example, if metadata model 900 depends on the expected specific data or metadata of data source 916, and if the referenced data source does not include the expected data or metadata, or is otherwise inconsistent with how the data source is used in the metadata model, the metadata model may be unusable, have performance issues, or provide incorrect results. As shown, data source 916 includes two tables, “vbak” and “vbkd”. These tables will typically include metadata characteristics, such as one or more fields, where each field is associated with a data type, primary key assignment, and optionally, associations with other database components (such as associations or foreign key relationships with other database tables).

[0166] Metadata model 900 may optionally include specifications for one or more associations 920. An association 920 may define a relationship with another entity. Associations 920 may be processed during the use of metadata model 900, such as being transformed into SQL expressions like JOIN. Unlike other conditions or elements included in metadata model 900, associations may define relationships that are optional, at least in some cases, such as being selectively activated based on how the metadata model is accessed. For example, association 920 may be transformed into a JOIN condition using a table provided in a SELECT statement that references metadata model 900.

[0167] Metadata model 900 may include one or more components 922 that specify how data retrieved using the metadata model should be processed, including generating values ​​associated with other metadata elements of the metadata model. Processing may include computed values, such as using formulas specified in or referenced by metadata model 900. Specifically, processing component 922 may specify that a particular field value should be treated as element 924, where elements may be as described in Examples 8 and 9. Therefore, metadata model 900 may include dependencies on how elements are defined, and if an element definition does not match how it is used and intended to be used in metadata model 900, metadata model 900 may be inaccurate or unusable.

[0168] Metadata model 900 may optionally include additional components such as one or more conditions 928, or other operations such as aggregation, union, etc., including those operations that are typically supported by database query languages.

[0169] Example 11 – Example metadata model, including its relationship with other metadata models.

[0170] Figure 10 The diagram illustrates how a metadata model can depend on other metadata models. Specifically, Figure 10 View metadata model 1004 is shown, which can be Figure 9 Metadata model 900. Figure 10 Metadata model 1008 is also illustrated for access control objects (such as DCLS or Data Control Language sources), metadata model 1012 for metadata extension objects (such as DDLX or metadata extensions), and metadata model 1016 for extension element objects (such as DDLS or Data Definition Language sources). Metadata model 1016 represents an extension whose data can be imported from the source system by the target system, as described in Example 6.

[0171] The access control object metadata model 1008 can be used to restrict access to data that can be retrieved using the view metadata model 1004. For example, when the view metadata model 1004 is activated, the view metadata model 1004 and the access control object metadata model 1008 can be processed together, such as generating SQL commands to retrieve data from the view metadata model, but filtering or restricting these commands based on the access control object metadata model. Because the access control object metadata model 1008 references the view metadata model 1004, the access control object metadata model depends on existing views and on views containing elements specified in the access control object metadata model. For example, the access control object metadata model references the "SalesOrderType" element of the view "I_SampleSalesOrder" and the authorization object "V_VBAK_AAT" with its authorization field "AUART". Therefore, if a corresponding element does not exist in the view metadata model 1004, the first element will be undefined or unavailable.

[0172] The metadata extension object metadata model 1012 (which adds annotations to the view metadata model 1004) has a similar dependency on the view metadata model, as does the extension element object metadata model 1016 (which adds additional elements to the view metadata model).

[0173] Example 12 – Example Relational Model of Metadata Model

[0174] Figure 11 The diagram illustrates how metadata models can depend on each other and how they can change over time, affecting the use or effectiveness of dependent metadata models. At time t0, a Data Definition Language version of the metadata model is provided. The metadata models are used for two database objects: model 1110 for View1 and model 1112 for View2. Model 1112 for View2 references View1 because it contains SQL select statements that define specific subsets of the data defined by model 1110 for View1. Therefore, model 1110 includes a dependency on model 1112. Specifically, model 1110 depends on the existence of View1, and View1 has a field "KeyField".

[0175] At time t1, a second version of model 1116 for View2 is received. Compared to model 1112, model 1116 includes another field, Field1, from View1 in the definition of View2. In some cases, model 1116 may be provided as a complete model, while in others, only the changes compared to the previous model version are sent.

[0176] At time t2, the second system uploads indication 1122 that View2 has been deleted. Note that in this case, the deletion of View2 will not affect any described metadata model because View2 depends on View1, but View1 does not depend on View2. Conversely, if View1 had already been deleted at time t2, it can be determined that deleting View1 would cause problems for View2.

[0177] Figure 11 The illustration shows a metadata model defined in a first format, such as an SQL statement defining a view. Figure 12A and Figure 12B The diagram illustrates how to... Figure 11 The metadata model shown is converted into records in different formats, such as a collection of database tables used to store the representation of the metadata model. Specifically, Figure 12A Table 1204 is shown, which includes a field 1206 for the object type associated with a record in the table, a field 1208 for storing the object name, a field 1210 for storing a version identifier associated with the object, a field 1212 for providing the type associated with the initial format of the received corresponding metadata model (e.g., plain text, JSON, XML, CSON, etc.), a field 1214 for storing a list of the initial source content (in the type associated with field 1212), and a timestamp including when the object was received (e.g., reference). Figure 11 The table 1204 may optionally include one or more additional fields 1220. (This includes a timestamp associated with time t0, t1, or t2.)

[0178] As can be seen, Table 1204 includes record 1222 of View1 received at t0, record 1224 of the metadata model of View2 received at t0, and record 1226 of the metadata model of View2 received at t1. Note that Table 1204 may include information about the object source version, so the type, name, and version information (i.e., fields 1206, 1208, 1210) can be specific to the object as the object source (e.g., a Data Definition Language source or DDLS).

[0179] Table 1228 may include a field for the Data Definition Language Object (DDLS) version, which may include field 1230 for the DDLS name and field 1232 for the DDLS version identifier, corresponding to fields 1208 and 1210 of Table 1204. Table 1228 may also include field 1234, which describes the entity (e.g., metadata model) type associated with the corresponding metadata model. Examples of entity types may be tables, views, access controls, annotation extensions, metadata extensions, etc.

[0180] Field 1236 may include an entity name or identifier, which may be such as Figure 11 The name or identifier assigned to the metadata model in the declaration of a metadata model, such as the SQL statement shown. For example, Figure 11 Metadata model 1110 is shown as definition VIEW1, which then provides the type indicated in field 1234 and the name indicated for record 1238 entered in field 1236. Note that field 1236 can be a typical form of the metadata model name, and the initial name provided in the metadata model definition can be included in field 1240. Similarly, the typical name of field 1236 can be associated with other formats, such as the format provided in field 1242, as shown, which can be the name used in an SQL query on the metadata model, corresponding to the name of the metadata model used in a database layer such as an information schema. Table 1228 may include one or more additional fields 1244.

[0181] like Figure 12A As shown, data can be retrieved from tables 1204 and 1228, or from individual fields, or from field 1214 which contains the original source content. Figure 11 All information about the metadata model provided at t0 and t1. Figure 12B Tables 1250, 1252, 1254, and 1256 are illustrated and can store additional information about the metadata model, including information about the system from which the metadata model is received or updated (including deleted). Specifically, Table 1250 can be used to associate the metadata model with a software component version identifier, which can be used to describe the operating environment on the system from which the metadata model is received. Table 1250 includes a field 1260 for a software component version ID associated with the metadata model object name listed in field 1264 (which corresponds to field 1208 in Table 1204) and the version identifier in field 1266 (which corresponds to field 1210 in Table 1204). The type of the object can be specified in field 1262.

[0182] When the metadata model is modified, the version associated with the identifier in field 1266 can be linked to a previous version of the metadata model, which can be stored in field 1268. In the case of metadata model deletion, the deletion time can be listed in field 1270 (where no value or a NULL value indicates that the object was not deleted). In some cases, deletion field 1270 can be filled for all versions of the data model. In other cases, deletion field 1270 is only filled for the last version of the metadata model prior to deletion.

[0183] Table 1252 can associate a specific software component listed in field 1272 (and corresponding to field 1260) with a specific system software version listed in field 1274. Furthermore, Table 1254 can associate a specific software system version in field 1276 with a specific system indicated by a system identifier in field 1278 and a timestamp in field 1280 indicating when the system was installed, released, or activated. Table 1256 may include field 1282 (corresponding to field 1260) for a specific software component version, an identifier for the software component provided in field 1284, a release identifier in field 1286, and a support package identifier in field 1288. Each of tables 1250, 1252, 1254, and 1256 may optionally include one or more additional fields 1290.

[0184] Example 13 – Example metadata relational model, including query language operations

[0185] Figure 13 The illustration depicts a scenario where metadata model 1304 (specifically a view) is defined with reference to two view metadata models 1306 and 1308, which in turn may depend on one or more additional data models. Metadata model 1306 depends on table metadata model 1310, while metadata model 1308 depends on table metadata model 1312 and is associated with metadata model 1314 for another view, which in turn references table metadata model 1316. These dependencies can be evaluated as described by the scope definition and traversal components for the associated metadata used to identify database artifacts and one or more specified artifacts (including artifacts responding to specific search / query requests).

[0186] View metadata models 1304, 1306, 1308, and 1314 include SQL select statements, which can be stored in alternative formats, such as tables. Figure 14 As shown. Figure 13 The select statement of the view metadata models 1304, 1306, 1308, and 1314 may include additional features / operations that can be stored in lieu of representation, such as join condition 1320 in metadata model 1304, association 1324 between metadata model 1308 and metadata model 1314, and where condition 1328 in metadata model 1314.

[0187] Figure 14Table 1404 is illustrated, which can store information of a metadata model with select statements in tabular format. Table 1404 includes field 1408 for object types, which are Data Definition Language source objects for metadata models 1304, 1306, 1308, and 1314. Field 1410 includes the name or identifier of each record for a given object, which can be a system-assigned name or a name used for system purposes to uniquely identify each object.

[0188] Notice, Figure 13 The SQL statement in the record does not assign the name used in field 1410. Field 1412 can store the object version identifier value of the object associated with each record. In some cases, the value stored in field 1412 can be unique for a given object and can be incremented as the object changes. For example, record 1416 is shown as having object version identifier 56 for the DDLS1 object. If the DDLS1 object changes again, the object version identifier can be incremented to 57.

[0189] Table 1404 may include a field 1420 for storing entity names, which may be... Figure 13 The entity names used in the SQL statements shown. For example, metadata model 1304 defines view View4, which is the name provided for record 1422 in field 1420, corresponding to View4. In at least some cases, each object in table 1404 can be associated with a primary data source. For example, the SQL statement could have the form "SELECT FROM primaryDataSource", where the identifier of "primaryDataSource" is stored in field 1424. For metadata model 1304, View4 is primarily defined relative to View1, so View1 is listed in field 1424 of record 1422. The primary data source for field 1424 can have a type such as a table or field, which is provided in field 1426.

[0190] As described above, the select statement used in the metadata model may have additional operations, which can be recorded in table 1404. If the object metadata model definition includes a WHERE condition, the identifier of that condition can be included in field 1428. Metadata model 1314 includes a WHERE condition 1328, so the identifier of that condition can be entered in field 1428 of record 1422. The identifier in field 1428 can identify a specific set of conditions, where additional information can be included in the condition set table 1432, as will be described further. Similarly, if the object metadata model definition includes a JOIN condition, the identifier of that condition can be included in field 1436. The identifier in field 1434 can identify the set of conditions in table 1432.

[0191] Table 1432 provides further details regarding the conditions related to the select statement in Table 1404. Table 1432 includes an object type field 1438 and an object name field 1440, which can correspond to fields 1408 and 1410 in Table 1404. Note that the join condition in metadata model 1304 is represented by records 1444-1448, the "where" condition in metadata model 1314 is represented by record 1450, and the associated "on" condition in metadata model 1308 is represented by record 1452.

[0192] Table 1432 includes field 1456, which is a version identifier for the objects listed in field 1440 and may correspond to field 1412. Field 1458 includes a condition set identifier and may correspond to fields 1428 and 1436. The group ID field 1460 and the group sequence number field 1462 can be used to preserve the semantics of the originally expressed conditions (e.g., in SQL). For example, the group ID field 1460 can be used to indicate the portion of the condition associated with the data source indicated in field 1464. Thus, record 1444 is associated with group identifier 1 in field 1460 because it is associated with the value VIEW1 in field 1464, while records 1446 and 1448 are associated with group identifier 2 because both records are associated with the value VIEW2 in field 1464. The value of the group sequence number field 1462 can further identify the specific semantics of records 1446 and 1448, such as indicating that record 1446 precedes record 1448 in the initial select statement. The grouping operator field 1466 can provide operators that associate records with specific group identifier values ​​associated with field 1460.

[0193] For a given operator or relation listed in field 1468, fields 1470, 1464, 1472, and 1474 can list the left-hand group identifier, left-hand data source name, left-hand field name, and left-hand value, respectively. Similarly, fields 1476, 1478, 1480, and 1482 can provide the right-hand group identifier, right-hand group source name, right-hand field name, and right-hand value, respectively. "Left-hand" and "right-hand" refer to the position of the value relative to the operator in field 1468.

[0194] Therefore, the records in Table 1432 can be used for reconstruction. Figure 13 The operations or conditions of the metadata model in the format shown. Although the type of operation or condition may not be explicitly listed in Table 1432, this information can be collected from fields 1428 and 1436 of Table 1404 (or from Table 1484, as will be described further).

[0195] Association definition table 1484 can define inclusion in metadata models (such as...) Figure 13 The associations in the model (provided in the format shown) may include an object type field 1486, an object name field 1487, an object version identifier field 1488, and an entity name field 1489, which may be as described for fields 1408, 1410, 1412, and 1420 of table 1404. Field 1490 may store a normalized version of the object identifier (e.g., the identifier of the object metadata model) listed in field 1492, which may be the object name included in the association definition in the initial metadata model, such as association 1324. Field 1494 may provide the name of the associated entity, and may provide the type (e.g., table, view) associated with that entity in field 1495. Associations may be associated with the minimum cardinality field and the maximum cardinality field 1496 and 1497, respectively. Field 1498 may include a condition set identifier, which may correspond to field 1458 of table 1432.

[0196] by Figure 13 Taking the example association 1324 as an example, record 1452 proposes the conditions (i.e., "on" conditions) defined for the association. For example, the value in FIELD3 of the table referenced by the defined view 1308 is equal to the FIELD3 of the associated view defined in metadata model 1314, which in turn is associated with the table defined in metadata model 1316.

[0197] Tables 1404, 1432, and 1484 may optionally include one or more additional fields 1499.

[0198] Example 14 – Example relational metadata model, including field definitions and relations

[0199] In some cases, metadata objects, such as views, may include fields that are at least partially based on elements (e.g., fields) of one or more other metadata models, or otherwise at least partially based on elements (e.g., fields) of one or more other metadata models. This computation can be explicitly specified in the metadata model definition, or it can be referenced in the model definition, for example, by calling a built-in function or referencing a function in another metadata model, a function in a library, an API call, etc.

[0200] Figure 15 The illustration shows metadata model 1504, which references a view defined by metadata model 1508. Metadata model 1508, in turn, references a table defined by metadata model 1512. Metadata model 1504 includes four fields 1520, 1522, 1524, and 1526 derived from fields in metadata model 1508. Metadata model 1508 includes three fields 1530, 1532, and 1534 selected from the table defined by metadata model 1512. The table defined by metadata model 1512 includes three fields 1540, 1542, and 1544 declared / defined in that metadata model.

[0201] Figure 16 Table 1600 is illustrated and can be used to summarize the fields used in metadata models 1504, 1508, and 1512. Table 1600 includes field 1602, which indicates the type of object associated with that field, such as an object associated with a table or data definition language source object (e.g., a view). The name of the object is provided in field 1604, which can be an object name used or provided by the system used with the metadata model, or, for example, an object name used or provided by a metadata repository.

[0202] A version identifier for an object can be provided in field 1606, as discussed for other metadata model representations. This version identifier can be a unique number for each object and can be incremented as the object changes. The entity name field 1608 can include a name associated with the metadata model, such as a name defined in the metadata model's declaration.

[0203] Each metadata object may be associated with one or more fields, and field 1610 may store a normalized representation of the field names provided in field 1612. For example, field 1610 may store names from the field names listed in field 1612 after removing formatting / capitalization (e.g., lowercase letters). As mentioned above, a metadata model may incorporate fields from other metadata models. The direct source of a field may have a name provided in field 1614 and may have a type, such as a table or view, and this type may be provided in field 1616. The name of a field in the direct source may differ from the name of a field in the metadata model it is incorporated into; therefore, field 1618 may include the name of a field in the source metadata model.

[0204] The calculated field may be associated with an expression, and an identifier for the expression may be provided in field 1620, which can be used to access the expression, such as an expression stored as a representation in one or more other tables. Field 1622 may indicate whether the field is a key field (e.g., a field used in a primary key). Fields may be associated with data types that can be listed in field 1626, and the data type may be associated with additional semantic or technical information (such as in data elements), the identifier of which may be provided in field 1624. Typically, the data type associated with field 1626 (and consequently with field 1624) may have a length, such as the number of allowed numbers or characters, and this information may be included in field 1628.

[0205] Numeric fields that allow decimals can be associated with values ​​(e.g., the number of allowed decimal places) via field 1630. Fields 1632, 1634, 1636, and 1638 can be used to define where the expression definition appears in the source metadata model, such as the start row, start column, end row, and end column, respectively. Table 1600 may optionally include one or more additional fields 1640.

[0206] How can Table 1604 be used to represent information from... Figure 15Consider an example of a field in a metadata model, specifically record 1650 associated with metadata model 1508. Metadata model 1508 is used for view VIEW1 and references Field1 of Table1 (defined by metadata model 1512) as a key field. Record 1652 corresponds to the definition of Field1 of Table1 in metadata model 1512, where Field1 is defined as a key field with data element type DE1 and cannot be NULL. Record 1650 includes the name of the object VIEW1 in field 1608, the name of the field FIELD1 in the object in field 1610, the original name of the field Field1 in the object in field 1614, the name of the entity from which the field is referenced in field TABLE1 in field 1616, the type TABL (for tables) of the referenced entity in field 1616, and the name of the field FIELD1 in the referenced entity in field 1618. Field 1622 of record 1650 is set to true, indicating that the field associated with record 1650 is a critical field, while field 1624 specifies that the field has a data element type DE1, and fields 1626 and 1628 indicate that it is a character data type with a length of 30.

[0207] Example 15 – Example relational metadata model, including annotations

[0208] As described in Example 10, metadata objects such as view definitions can include annotations. Figure 17 This diagram illustrates how interdependent metadata objects can have annotations, which can be stored in another format, such as... Figure 18 The format shown in Table 1800.

[0209] Figure 17 Metadata model 1704 includes a metadata model for view 2, which is defined relative to another view, View1, defined in metadata model 1708. Metadata model 1712, used for metadata extension DDLX2, provides additional metadata elements to metadata model 1704. Metadata model 1708 includes two annotations, 1720 and 1722, that can be incorporated into metadata model 1704. However, annotation 1720, which provides a label for View1, is replaced by annotation 1726, defined in metadata model 1704 for View2. In some cases, an annotation can be replaced if it has the same name or type as an annotation in the referenced metadata model (e.g., "@EndUserText.label" as shown).

[0210] Metadata model 1730 illustrates the "effective" representation of metadata model 1704, including annotations incorporated into metadata model 1704 through dependencies. It can be seen that effective metadata model 1730 includes annotation 1726 but not annotation 1720. Since annotation 1722 of metadata model 1708 was not superseded, it is included in effective metadata model 1730, as is annotation 1734 from metadata model 1712.

[0211] Table 1800 can be summarized Figure 17 The metadata model is annotated. Table 1800 includes a field 1804 for the object type associated with the metadata model, which is annotated by records representing annotations. As shown, field 1804 includes the value "DDLS" for views, or the value "DDLX" for metadata extended objects. Field 1808 can provide the name of the object, such as the system name, while field 1812 can provide the object name defined by the object's declaration. Field 1810 can provide the version identifier of the object. Field 1814 can provide the name of the sub-entity associated with the annotation, which can be, for example, the specific view field to which the annotation is applied.

[0212] Field 1816 provides an internal annotation identifier that can be used to distinguish multiple annotations in the metadata model and to provide the ordering of annotations when multiple annotations exist in the metadata model. As will be further described, the value of field 1816 can also be used to associate a base or parent annotation or annotation type with a child annotation. Annotation names can be included in field 1818, which can be the annotation's type (or class) or subtype (or class method or class data member). Field 1820 can provide an identifier for the parent annotation. For example, record 1840 assigns the internal annotation identifier "1" to the "ENDUSERTEXT" annotation. "ENDUSERTEXT" can be the base annotation type, and record 1842 can include the annotation's subtype "ENDUSERTEXT.LABEL," where the value "1" in field 1820 indicates that record 1842 references the annotation in record 1840.

[0213] The value of an annotation defined in the metadata model declaration can be provided in field 1822. The value in field 1822 represents an explicitly defined value assigned to the annotation. The effective value assigned to the annotation can be indicated in field 1824. For example, the annotation @Search.defaultSearchElement has an effective value "TRUE," even though this is not explicitly captured in the metadata model declaration but is automatically derived from the annotation's default logic. Furthermore, in the example shown, the effective value for language-related text can be specified relative to the identifier in table 1850, where the value in field 1824 corresponds to the value in the text identifier field 1854. Table 1850 is also shown to include field 1856, which provides the code for the language associated with the text, and the actual text to be displayed can be provided in field 1858.

[0214] Table 1800 can store information about all annotations incorporated into a specific metadata model. However, as mentioned above, some annotations may not be "active," for example, because locally declared annotations may override imported or referenced annotations. Similarly, in some cases, annotations from multiple referenced sources (e.g., metadata models) may overlap or conflict, in which case only one annotation (or usually a subset) can be assigned as active. Maintaining a separate repository for active annotations may be beneficial, such as... Figure 19 The data is stored as shown in Table 1900.

[0215] Table 1900 may include a field 1904 for object type, a field 1908 for object name, a field 1910 for object version identifier, a field 1912 for entity name, a field 1914 for child entity name, a field 1916 for comment internal identifier, a field 1918 for comment name, a field 1920 for parent comment identifier, a field 1922 for comment value, and a field 1924 for effective comment value, which may be implemented at least generally with respect to the fields described in similar headings and numbering of Table 1800.

[0216] Table 1900 may include additional fields, such as the Activity Annotation Version Identifier field 1930. Note that the Activity Annotation Version Identifier in field 1930 may have a different value than the Object Version Identifier in field 1910. For example, new metadata extensions may change the activity annotations of existing base (e.g., view) model versions that are being annotated, so it may be useful to track these versions separately.

[0217] Since annotations can be imported from other sources, it can be useful to track information about these annotations relative to their source objects (e.g., metadata models). Accordingly, field 1932 can store the object type associated with the annotation (a local object type or the object type of an object from which the annotation was imported), while field 1934 can store the name of the originating object. Field 1936 can store the version identifier of the originating object.

[0218] Example 16 – Sample API for Metadata Access

[0219] Users or applications can access the stored metadata model, such as metadata maintained in one or more tabular formats as described in Examples 12-15. In some cases, information can be accessed via an API, such as a web-based API using a REST service. In a specific example, the API may use the OData protocol.

[0220] Figure 20 The illustration depicts an extract 2004 of the persistence model (e.g., all or part of the tables in Examples 12-15) and an extract 2050 of the OData service that can be used to access data maintained in persistence or data determined or calculated based on data in persistence. The persistence extract 2004 may include tables or portions thereof (e.g., one or more fields) for DDLS version information 2020, object version source information 2022, text information 2024 (e.g., text of the initial metadata object definition information), select statement information associated with the object version 2026, association information associated with the object version 2028, field information associated with the object version 2030, condition information associated with the object version 2032 (e.g., “where” or “on” conditions such as those described with respect to 1432), local annotation information associated with the object version 2034, and activity annotation information associated with the object version 2036.

[0221] An API, or other functionality for accessing metadata services, can provide, among other things, the ability to query and maintain representations of the metadata model, such as creating, updating, or deleting metadata model representations (or specific versions thereof). An API may allow additional options, such as aggregating data from persistent metadata model representations or searching the metadata repository, including using fuzzy search techniques. For example, a user (or application) might request information about how many objects are registered in the repository, how many versions are associated with a specific object, or the number of fields an object might have (such as the maximum number of fields).

[0222] Figure 21The illustrations show example table 2104 with object version source information and example table 2108 with DDLS version information. Table 2104 may have multiple fields, including a field 2112 for the object type associated with the record, a field 2114 for the object name associated with the record, and a field 2116 for the object version identifier associated with the record. Table 2108 may have a field 2120 for the DDLS name, a DDLS version field 2122, an entity name (such as CDS entity name) field 2124, and an initial entity name field (such as initial CDS entity name) field 2126.

[0223] Metadata representations using tables 2104 and 2108 are employed, and extract 2050 is used. The navigation features of the extract can traverse records from the object version source table 2104 to the DDLS version table 2108 via OData read requests. The OData read request is as follows:

[0224] …sap / opu / odata / sap / CdsMetadataService / ObjectVersionSource(ObjectType='DDLS',ObjectName='I_SALESORDER',ObjectVersionId=1) / to_DdlsVersion

[0225] This operation results in the following data records:

[0226]

[0227] The API allows searching for all relevant information about a version of a given object. For example, a search request for "cust" could take the following form:

[0228] … / sap / opu / odata / sap / CdsMetadataService / Ddls / ?search=cust

[0229] It retrieves all five records whose DDLS object name (e.g., field 2114) is I_CUSTOMER. Note that users can retrieve and access metadata information without knowing the exact name of the metadata model or any of its components.

[0230] API or other metadata service access capabilities can support additional services, including those based on coarser-grained actions, rather than simply retrieving and updating metadata models. These services could include uploading object source information, comparing metadata models (and parts thereof), including comparing metadata models across different components or system versions. Analysis of where various metadata models or elements are used can be provided, including identifying dependencies between metadata models / metadata model components. Providing such services is likely more efficient and less error-prone than implementing functionality by applying multiple lower-level functions each time.

[0231] As an example, instead of converting object source information from each individual table starting with the object version table into a table storing more detailed information, a user or application can request an object upload action that provides the initial string defining the object (e.g., the initial SQL statement), optionally along with additional information such as the type of the initial source string (e.g., SQL, XML, plain text), the object's name, object type (e.g., view, table), other information, and combinations thereof. Input may include:

[0232] ObjectType

[0233] ObjectName

[0234] SerializedObjectSourceType

[0235] SerializedObjectSourceContent

[0236] ObjectMaintenanceLanguage

[0237] ObjectLastChangedDateTime

[0238] SoftwareComponentId

[0239] SoftwareComponentReleaseId

[0240] The metadata repository can be queried to determine if a new version of the metadata model needs to be created, and if so, the uploaded model can be converted to a persistent format used by the metadata service. At least in some cases, it can be determined whether any metadata model depends on the updated model, and if so, this dependent model can be updated to provide the new model version.

[0241] For functionality to compare two metadata models (including two versions of a metadata model), information can be provided about the differences between objects, how the metadata model differs between different versions of a software component, or how the metadata model differs between two versions of a system. Example inputs for comparing two versions of a metadata model may include:

[0242] ObjectType

[0243] ObjectName

[0244] ObjectVersion1Id

[0245] ObjectVersion2Id

[0246] ChangeTypes [For example, the type of change to query, such as All, Insert, Update, Delete, Unchanged]

[0247] ComparisionScope [e.g., all elements of the metadata model, or just a specified element or a collection of elements]

[0248] This comparison can return information, including:

[0249] ObjectVersion

[0250] ChangeType

[0251] SubObjectType [e.g., field, association, parameter]

[0252] SubObjectName

[0253] PropertyType [e.g., activity's comment, key, data type, name]

[0254] PropertyName

[0255] PropertyValue

[0256] The following can represent information in a request for changes to the metadata model:

[0257] Input:

[0258] ChangeTypes = INSERT

[0259] ComparisonScope = ALL

[0260] The response may include:

[0261] Output:

[0262] ObjectVersion = 2

[0263] ChangeType = INSERT

[0264] SubObjectType = FIELD

[0265] SubObjectName = NewField

[0266] Therefore, the comparison request revealed that a new field, NewField, was introduced in object version 2 of the metadata model.

[0267] Metadata exposure services, or other functionalities for accessing a metadata repository, could return a list of objects that use specific metadata elements. For example, a field might initially be defined for a specific table but could subsequently be referenced by multiple views. Inputs to this functionality could include:

[0268] Input:

[0269] ObjectType: Identification

[0270] ObjectName: Identification

[0271] ObjectVersionId: Identification

[0272] UseageTypes [e.g., ALL, Related, Target, Data Source, Comment]

[0273] MaximumNumberOfIndirections

[0274] The requested output may include:

[0275] Using ObjectType

[0276] UsingObjectName

[0277] Using ObjectVersionId

[0278] UsageType

[0279] DirectlyUsedObjectType

[0280] DirectlyUsedObjectName

[0281] DirectlyUsedObjectName

[0282] DirectlyUsedObjectVersionId

[0283] NumberOfIndirections

[0284] Figure 22 An example of a "where used" request is provided. Group 2204 of the relevant metadata models includes metadata model 2208 for View3, which references metadata model 2210 for View2; metadata model 2210 for View2 references metadata model 2212 for View1; and metadata model 2212 for View1, in turn, references metadata model 2214 for Table1. Assuming each view 2208, 2210, 2212 references a field in Table1, and the views reference this field through the views they reference, as shown, the request could be:

[0285] Input:

[0286] ObjectName: TABLE1

[0287] UseageTypes: ALL

[0288] MaximumNumberOfIndirections: 5

[0289] In response to the request, the information shown in Form 2230 may be provided in the form shown or in another format.

[0290] For dependency checking, inputs (e.g., function arguments) may include:

[0291] ObjectType

[0292] ObjectName

[0293] ObjectSourceType

[0294] ObjectSourceContent

[0295] SoftwareComponentVersions

[0296] NewSoftwareComponentVersions

[0297] The response to a request (e.g., a value returned by a function, such as in a struct (e.g., a C++ struct) or class instance, or another complex or abstract data type) may include:

[0298] MessageType [e.g., INFO, WARNING, ERROR]

[0299] MessageText

[0300] EntityReference [for example, a link to additional details of the metadata model so that additional information about dependent objects can be identified]

[0301] As a concrete example, consider adding a new annotation, `NewAnnotation`, to a `ViewField` field exposed through the user model. The output of the dependency check may include:

[0302] MessageType: INFO

[0303] MessageText: A new annotation, NewAnnotation, has been added to the ViewField.

[0304] EntityReference = … / sap / opu / odata / sap / CdsMetadataService / …NewAnnotation…

[0305] Services that handle access to metadata can facilitate or help display metadata information to end users, such as on user interface screens. This service can enhance the model metadata with additional information that can define the layout of the user interface, and can include or define additional services that allow users to interact with the data. For example, such as... Figure 23 As shown in the example code, comments can be provided, which help users provide filtering criteria via values.

[0306] Example 17 – Example Vocabulary

[0307] Such as about Figure 4 The metadata exposure service discussed here provides access to a vocabulary of annotations that describe metadata that acts as database artifacts. Some examples of how to derive the vocabulary from the corresponding annotations are provided.

[0308] Figure 24A The diagram illustrates annotation 2404 of the data warehouse, which lists element 2414 of the annotation. Figure 24BExample glossary 2426, created from note 2404, is provided. Note 2404 represents notes expressed in CDS notation (as in products available from SAP SE in Walldorf, Germany), while glossary 2426 is expressed in CSN notation. This pattern of using CDS notation for notes and CSN notation for glossaries continues in the rest of the examples in Example 17.

[0309] Figure 25A The illustration shows note 2504, which includes an array of values ​​(in this case, integers). Figure 25B The corresponding vocabulary list 2508 is shown. Figure 26A Example comment 2604 is shown, which provides an enumeration list of types, including the default value 2606, while Figure 26B The corresponding vocabulary list 2608 is shown.

[0310] Example 18 – Example of Standardized API and Metadata Representation

[0311] Figure 27A-27J The illustration shows an example list of at least a portion of a standardized format API, which may be... Figure 3 An example of the standardized format 320 API.

[0312] Figures 28A-28C The illustration shows an example list of at least a portion of the metadata of a database artifact in a standardized format, which may be... Figure 3 Examples of metadata in the standardized format 330.

[0313] Example 19 – Example Implementation

[0314] Figure 29 This is a flowchart of example method 2900, which is used to create database artifacts on a target system based on metadata retrieved from a source system, and to link these created database artifacts to corresponding database artifacts in the source system. Method 2900 can be... Figure 1 It is implemented in computing environment 100.

[0315] At 2905, input is received, such as input from a user or computer-implemented process, specifying one or more database artifacts of the source system or criteria (e.g., search terms / criteria) sufficient to identify one or more database artifacts of the source system. At 2910, a first request is sent to the source system requesting metadata associated with one or more database artifacts. At 2915, metadata is received from the source system in response to the first request. At 2920, one or more database artifacts are instantiated at the target system using the metadata received from the source system. At 2925, one or more instantiated database artifacts are linked to one or more database artifacts of the source system. At 2930, a second request is sent to the source system requesting additional data or metadata for one or more instantiated database artifacts. At 2935, data or metadata is received from the source system in response to the second request. At 2940, such data or metadata is stored in association with one or more instantiated database artifacts.

[0316] Example 20 – Computing Systems

[0317] Figure 30 A generalized example of a suitable computing system 3000 capable of realizing the aforementioned innovation is depicted. The computing system 3000 is not intended to impose any limitation on the scope or functionality of this disclosure, as the innovation can be implemented in various general-purpose or special-purpose computing systems.

[0318] refer to Figure 30 The computing system 3000 includes one or more processing units 3010, 3015 and memories 3020, 3025. Figure 30 In the diagram, the basic configuration 3030 is included within the dashed lines. Processing units 3010 and 3015 execute computer-executable instructions, such as those for implementing... Figure 1 The components of environment 100 include those described in Examples 1-19. The processing unit can be a general-purpose central processing unit (CPU), a processor in an application-specific integrated circuit (ASIC), or any other type of processor. In a multiprocessor system, multiple processing units execute computer-executable instructions to increase processing power. For example, Figure 30 A central processing unit 3010 and a graphics processing unit or coprocessor 3015 are shown. Physical memory 3020, 3025 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination thereof, accessible by the processing units(s) 3010, 3015. Memory 3020, 3025 stores one or more innovative software 3080 implementing the invention described herein in the form of computer-executable instructions suitable for execution by the processing units(s) 3010, 3015.

[0319] The computing system 3000 may have additional features. For example, the computing system 3000 includes a storage device 3040, one or more input devices 3050, one or more output devices 3060, and one or more communication connections 3070. Interconnection mechanisms (not shown), such as buses, controllers, or networks, interconnect the components of the computing system 3000. Typically, operating system software (not shown) provides an operating environment for other software executing in the computing system 3000 and coordinates the activities of the components of the computing system 3000.

[0320] The physical storage device 3040 may be removable or non-removable and includes a magnetic disk, magnetic tape or cassette tape, CD-ROM, DVD, or any other medium that can be used to store information in a non-transitory manner and can be accessed within the computing system 3000. The storage device 3040 stores instructions for implementing one or more innovative software 3080 described herein.

[0321] The input devices 3050 may be touch input devices, such as a keyboard, mouse, pen or trackball, voice input device, scanning device, or another device that provides input to the computing system 3000. The output devices 3060 may be a monitor, printer, speaker, CD burner, or another device that provides output from the computing system 3000.

[0322] Multiple communication connections 3070 enable communication via a communication medium to another computing entity. The communication medium conveys information, such as computer-executable instructions, audio or video inputs or outputs, or other data in modulated data signals. A modulated data signal is a signal whose one or more characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, the communication medium may be electrical, optical, RF, or other carriers.

[0323] Innovations can be described within the general context of computer-executable instructions, such as those contained in program modules that execute on a computing system targeting a real or virtual processor. Typically, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of program modules can be combined or divided among program modules as needed. The computer-executable instructions of a program module can execute within a local or distributed computing system.

[0324] The terms “system” and “device” are used interchangeably herein. Neither term implies any limitation on the type of computing system or computing device unless the context clearly indicates otherwise. In general, a computing system or computing device can be local or distributed and can include any combination of dedicated hardware and / or general-purpose hardware with software that implements the functions described herein.

[0325] In the various examples described herein, modules (e.g., components or engines) may be "coded" to perform certain operations or provide certain functions, instructing computer-executable instructions of the executable module to perform such operations, cause such operations to be performed, or otherwise provide such functions. While the functionality described with respect to a software component, module, or engine may be implemented as a discrete software unit (e.g., a program, function, class method), it does not necessarily have to be implemented as a discrete unit. That is, the functionality may be incorporated into a larger or more general program, such as one or more lines of code within a larger or more general program.

[0326] For ease of explanation, we will explain in detail the use of terms such as "determine" and "use" to describe computer operations in a computing system. These terms are high-level abstractions of the operations performed by the computer and should not be confused with actions performed by humans. The actual computer operations corresponding to these terms vary depending on the implementation.

[0327] Example 21 – Cloud Computing Environment

[0328] Figure 31 An example cloud computing environment 3100 is depicted, which enables the described technology. The cloud computing environment 3100 includes cloud computing services 3110. Cloud computing services 3110 may include various types of cloud computing resources, such as computer servers, data storage repositories, network resources, etc. Cloud computing services 3110 may be centrally located (e.g., provided by a data center of an enterprise or organization) or distributed (e.g., provided by various computing resources located in different locations (such as different data centers) and / or in different cities or countries).

[0329] Cloud computing service 3110 is utilized by various types of computing devices (e.g., client computing devices) such as computing devices 3120, 3122, and 3124. For example, computing devices (e.g., 3120, 3122, and 3124) can be computers (e.g., desktop or laptop computers), mobile devices (e.g., tablets or smartphones), or other types of computing devices. For example, computing devices (e.g., 3120, 3122, and 3124) can utilize cloud computing service 3110 to perform computing operations (e.g., data processing, data storage, etc.).

[0330] Example 22 – Implementation

[0331] Although some of the operations of the disclosed methods have been described in a specific order for ease of presentation, it should be understood that this descriptive approach encompasses rearrangement unless the specific language used below requires a particular order. For example, the operations described sequentially may be rearranged or performed concurrently in certain situations. Furthermore, for simplicity, the accompanying figures may not show the various ways in which the disclosed methods can be combined with other methods.

[0332] Any disclosed method may be implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media, such as tangible, non-transitory computer-readable storage media, and executed on a computing device, such as any available computing device, including smartphones or other mobile devices that include computing hardware. A tangible computer-readable storage medium is any available tangible medium that can be accessed within a computing environment (e.g., one or more optical media discs, such as DVDs or CDs, volatile memory components such as DRAM or SRAM, or non-volatile memory components such as flash memory or hard disk drives)). By way of example and reference Figure 30 Computer-readable storage media include memories 3020 and 3025 and storage device 3040. The term "computer-readable storage medium" excludes signals and carrier waves. Furthermore, the term "computer-readable storage medium" excludes communication connections (e.g., 3070).

[0333] Any computer-executable instructions used to implement the disclosed technology, and any data created and used during the implementation of the disclosed embodiments, may be stored on one or more computer-readable storage media. The computer-executable instructions may be, for example, a dedicated software application or a software application accessed or downloaded via a web browser, or part of another software application (such as a remote computing application). Such software may execute, for example, on a single local computer (e.g., any commercially available computer) or in a network environment using one or more networked computers (e.g., via the Internet, a wide area network, a local area network, a client-server network (such as a cloud computing network), or other such networks).

[0334] For clarity, only certain selected aspects of the software-based implementation have been described. Other details well-known in the art have been omitted. For example, it should be understood that the disclosed techniques are not limited to any particular computer language or program. For instance, the disclosed techniques can be implemented by software written in C, C++, C#, Java, Perl, JavaScript, Python, Ruby, ABAP, SQL, Xcode, Go, Adobe Flash, or any other suitable programming language, or in some examples, markup languages ​​such as HTML or XML, or a combination of suitable programming languages ​​and markup languages. Similarly, the disclosed techniques are not limited to any specific computer or type of hardware. Certain details of suitable computers and hardware are well-known and do not need to be elaborated in this disclosure.

[0335] Furthermore, any software-based implementation (including, for example, computer-executable instructions for causing a computer to perform any disclosed method) can be uploaded, downloaded, or remotely accessed via suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave, and infrared communication), electronic communication, or other such communication means.

[0336] The disclosed methods, apparatuses, and systems should not be construed as limiting in any way. Rather, this disclosure is directed toward all novel and non-obvious features and aspects of the various disclosed embodiments, individually and in various combinations and sub-combinations of each other. The disclosed methods, apparatuses, and systems are not limited to any particular aspect or feature or combination thereof, nor are the disclosed embodiments required to have any one or more particular advantages or solve any one or more particular problems.

[0337] The techniques from any example can be combined with the techniques described in any one or more other examples. Given that the principles of the disclosed techniques can be applied to many possible embodiments, it should be understood that the illustrated embodiments are examples of the disclosed techniques and should not be considered as limiting the scope of the disclosed techniques. Rather, the scope of the disclosed techniques includes what is covered by the scope and spirit of the appended claims.

Claims

1. A computing system, comprising: At least one hardware processor; At least one memory coupled to the at least one hardware processor; as well as One or more computer-readable storage media storing computer-executable instructions, which, when executed, cause the computing system to perform operations including: Receive input, which specifies one or more database artifacts of the source system or criteria sufficient to identify one or more database artifacts of the source system; Send a first request to the source system for metadata associated with the one or more database artifacts; In response to the first request, metadata is received from the source system; Using the metadata received from the source system, one or more database artifacts are instantiated at the target system to provide one or more instantiated database artifacts; Link the one or more instantiated database artifacts to the one or more database artifacts of the source system; Send a second request to the source system for additional data or metadata for the one or more instantiated database artifacts; In response to the second request, data or metadata is received from the source system; The data or metadata received in response to the second request shall be stored in association with the one or more instantiated database artifacts; and At the source system: In response to a third request from the target system, which could be either the first request or the second request, metadata of one or more database artifacts maintained by the source system is converted from a first format to a second format in response to the third request to provide the converted metadata; and Send at least a portion of the transformed metadata to the target system.

2. The computing system according to claim 1, wherein, Linking the one or more instantiated database artifacts to the one or more database artifacts of the source system includes associating a corresponding instantiated database artifact among the one or more instantiated database artifacts with a corresponding API for the corresponding database artifact of the source system.

3. The computing system according to claim 2, wherein, The given API in the corresponding API is associated with a type, and at least a portion of the second request is sent using the appropriate protocol for that type.

4. The computing system according to claim 1, wherein, The metadata received from the source system in response to the first request includes metadata of at least one database artifact of the source system that is identified by the source system as being related to a database artifact specified in the first request, or related to a database artifact identified by the source system using the standard.

5. The computing system according to claim 4, wherein the operation further comprises: At the source system, a set of one or more database artifacts is determined by invoking a scope delimitation function that is related to the database artifact specified in the first request or to the database artifact identified by the source system using the standard.

6. The computing system according to claim 5, wherein, The scope definition function determines a set of one or more database artifacts by analyzing foreign key relationships or associations.

7. The computing system according to claim 1, wherein, Instantiating one or more database artifacts includes instantiating one or more database tables or database views.

8. The computing system according to claim 1, wherein, Instantiating one or more database artifacts includes instantiating one or more virtual database tables, wherein at least one virtual database table obtains data from the source system using data replication.

9. The computing system according to claim 1, wherein, Instantiating one or more database artifacts includes instantiating one or more virtual database tables, wherein at least one virtual database table obtains data from the source system using data federation.

10. The computing system according to claim 1, wherein, Receiving data or metadata from the source system in response to the second request includes: receiving additional metadata of an instantiated database artifact from the one or more instantiated database artifacts, where at least a portion of the additional metadata is not required to instantiate the instantiated database artifact.

11. The computing system according to claim 1, wherein the operation further comprises: At the source system, multiple APIs for accessing the one or more database artifacts of the source system are identified; as well as The multiple APIs are converted into a standardized exchange format, and the multiple APIs in the standardized exchange format are saved in a directory.

12. The computing system according to claim 11, wherein, The standardized exchange format has multiple APIs used to provide information about database artifacts associated with the multiple APIs, but the data or metadata of the database artifacts are retrieved using APIs among the multiple APIs associated with the corresponding APIs of the standardized exchange format.

13. The computing system according to claim 11, further comprising: Expose multiple APIs of the standardized exchange format to the target system.

14. The computing system according to claim 11, wherein, The API for the standardized exchange format includes references to corresponding APIs used to create the API for the standardized exchange format, as well as references to metadata associated with the corresponding database artifacts.

15. The computing system according to claim 1, wherein, Linking the one or more instantiated database artifacts to the one or more database artifacts in the source system includes: instantiating an instance of an abstract or composite data type, storing the identifier of the database artifact in the one or more database artifacts in the source system in the instance, and storing the identifier of the API of the source system for the database artifact in the instance.

16. The computing system of claim 15, wherein the operation further comprises: An identifier for the type of the API used for the database artifact is stored in the source system, wherein the type can be used to identify the protocol for accessing the API at the source system.

17. The computing system according to claim 1, wherein, Linking the one or more instantiated database artifacts to the one or more database artifacts in the source system includes storing records in a table of the instantiated database artifacts in the one or more instantiated database artifacts, the records including an identifier of the database artifact in the one or more database artifacts in the source system and an identifier of the API of the source system for the database artifact.

18. One or more computer-readable storage media, comprising: Computer-executable instructions, when executed by a computing system comprising at least one hardware processor and at least one memory coupled to said at least one hardware processor, cause said computing system to receive input specifying one or more database artifacts of a source system or criteria sufficient to identify one or more database artifacts of the source system; Computer-executable instructions, when executed by the computing system, cause the computing system to send a first request to the source system for metadata associated with the one or more database artifacts; Computer-executable instructions, when executed by the computing system, cause the computing system to receive metadata from the source system in response to the first request; Computer-executable instructions, when executed by the computing system, cause the computing system to instantiate the one or more database artifacts using the metadata received from the source system to provide one or more instantiated database artifacts; Computer-executable instructions, when executed by the computing system, cause the computing system to link the one or more instantiated database artifacts to the one or more database artifacts of the source system; Computer-executable instructions, when executed by the computing system, cause the computing system to send a second request to the source system for additional data or metadata of the one or more instantiated database artifacts; Computer-executable instructions, when executed by the computing system, cause the computing system to receive data or metadata from the source system in response to the second request; Computer-executable instructions, when executed by the computing system, cause the computing system to store the data or metadata received in response to the second request in association with the one or more instantiated database artifacts; as well as Computer-executable instructions, when executed by the computing system, cause the computing system to: At the source system: In response to a third request from the target system, which may be either the first request or the second request, the metadata of one or more database artifacts maintained by the source system is converted from a first format to a second format in response to the third request to provide the converted metadata. as well as Send at least a portion of the transformed metadata to the target system.

19. A method implemented in a computing environment including a source system and a target system, each of the source system and the target system including at least one hardware processor and at least one memory coupled to the at least one hardware processor, the method comprising: Receive input, which specifies one or more database artifacts of the source system or criteria sufficient to identify one or more database artifacts of the source system; Send a first request to the source system for metadata associated with the one or more database artifacts; In response to the first request, metadata is received from the source system; The metadata received from the source system is used to instantiate the one or more database artifacts to provide one or more instantiated database artifacts; Link the one or more instantiated database artifacts to the one or more database artifacts of the source system; Send a second request to the source system for additional data or metadata for the one or more instantiated database artifacts; In response to the second request, data or metadata is received from the source system; The data or metadata received in response to the second request shall be stored in association with the one or more instantiated database artifacts; as well as At the source system: In response to a third request from the target system, which may be either the first request or the second request, the metadata of one or more database artifacts maintained by the source system is converted from a first format to a second format in response to the third request to provide the converted metadata. as well as Send at least a portion of the transformed metadata to the target system.

Images