identification and import of extended metadata for database artifacts

Abstract

Techniques and solutions for storing and processing metadata are described. A target system sends a request to a source system to identify extensions to one or more specified database artifacts. The source system identifies one or more software objects that include metadata extensions to the one or more specified database artifacts, and in response to the request, sends at least a portion of such metadata elements to the target system. The source system can expose an API, such as an API in a standard format, to the target system to facilitate requesting and retrieving metadata from the source system.

Description

TECHNICAL FIELD

[0001] The present disclosure generally relates to describing metadata for data artefacts (e.g., database artefacts such as tables or views). Particular implementations provide a metadata exposure service that receives requests from a target system to identify or retrieve relevant metadata in a source system. BACKGROUND

[0002] Increasing amounts of data are becoming available from an increasing variety of sources. Data associated with a particular purpose, such as a particular simulated-world entity, is often associated with metadata that describes the data. For example, a ten-digit integer can be data, but without metadata, it can be difficult to know what this ten-digit integer represents - a phone number, a driver's license number, a password, and so on. Thus, using and making data "meaningful" can depend in large part on having the right metadata to provide context for the data.

[0003] Databases or other data sources associated with complex work such as the operation of an enterprise entity 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 can be useful in another system. For example, it can be desirable to copy or transfer data from one system to another, such as when migrating from a pre-packaged database solution to a cloud-based solution. Or, it can be desirable to make data available to another platform, such as through data federation. However, if the metadata is not accessible, it can be difficult or impossible to use or interpret the copied or federated data. Given the potentially vast amount of metadata that can exist in a source system, it can be very time-consuming to recreate the metadata manually in the new system. Thus, there is room for improvement. SUMMARY

[0004] This Summary is provided to introduce selected concepts in a simplified form, which are further described below in the DETAILED DESCRIPTION. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0005] Techniques and solutions for storing and processing metadata are described. A target system sends a request to a source system to identify extensions to one or more specified database artefacts. The source system identifies one or more software objects that include metadata extensions to the one or more specified database artefacts, and in response to the request, sends at least a portion of such metadata elements to the target system. The source system can expose an API, such as an API in a standard format, to the target system to facilitate requesting and retrieving metadata from the source system.

[0006] In one aspect, a method for sending metadata of data artifact extensions to a target system is provided. A first request for at least a portion of metadata in a metadata repository is received from a target system. One or more software objects comprising metadata extensions of one or more database artifacts are identified. At least a portion of metadata elements of the metadata extensions are returned to the target system in response to the first request.

[0007] In another aspect, a method for obtaining metadata describing data of a database artifact from a client system is provided. A plurality of database artifacts are created in a database system. The database artifacts are configured to store data or references to data, where the data is described by metadata. At least a first portion of metadata associated with the data is deployed. A request for a second portion of metadata associated with the data is sent to a client system. The second portion of metadata is deployed.

[0008] The present disclosure also includes computing systems configured to perform the above methods (or operations) or tangible, non-transitory computer-readable storage media comprising instructions for performing the above methods (or operations). Various other features and advantages can be incorporated into the technology as described herein as needed. BRIEF DESCRIPTION OF DRAWINGS

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

[0010] Figure 2A is a timing diagram of a method of handling requests for metadata by a client, with specific details of the operations of components of a source system.

[0011] Figure 2B is a timing diagram of a method of handling requests for metadata by a client, with specific details of the operations of components of a target system.

[0012] Figure 2C is a flowchart of a method of automatically creating database artifacts at a target system and linking those artifacts to data and metadata maintained at a source system.

[0013] Figure 3 illustrates how a standardized API can provide access to metadata in a standardized format, and how it can reference non-standardized format APIs.

[0014] Figure 4 illustrates information that can be maintained by and accessible using a metadata exposure service.

[0015] Figure 5is a diagram illustrating a computing environment that can be used to supplement standard metadata of a database artifact with metadata associated with extensions of such database artifacts.

[0016] Figure 6 is a diagram of a database schema showing technical relationships between at least some of the database tables in the schema.

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

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

[0019] Figure 9 is code for an example metadata model for a database view.

[0020] Figure 10 is code for an example metadata model for a database view, and code for a metadata model that modifies or references such example metadata model.

[0021] Figure 11 is a diagram illustrating how metadata models can be related, and how they can be updated or deleted, including by multiple computing systems.

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

[0023] Figure 13 is a diagram illustrating how metadata models can be related, and how they can include query operations such as select statements, join conditions, and where conditions, and how database objects can be related through associations.

[0024] Figure 14 provides an example database table illustrating how metadata model information presented in Figure 13 can be stored in a relational format.

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

[0026] Figure 16 provides an example database table illustrating how metadata model information presented in Figure 15 can be stored in a relational format.

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

[0028] Figure 18 and Figure 19 An example database table is provided that illustrates how the metadata model information presented in Figure 17

[0029] Figure 20 Code is presented that illustrates a data access service that can access a persistence model of a metadata model.

[0030] Figure 21 and Figure 22 An example table is presented that can be used to perform operations requested through a data access service.

[0031] Figure 23 Example code is presented that can be used to annotate a user interface service that displays metadata model information.

[0032] Figure 24A An example metadata description of a data warehouse is provided, while Figure 24B a vocabulary that can be generated from it is illustrated.

[0033] Figure 25A An example metadata description is provided that includes elements in the form of arrays, while Figure 25B a vocabulary that can be generated from it is illustrated.

[0034] Figure 26A An example metadata description is provided that includes elements in the form of enumerated lists, while Figure 26B a vocabulary that can be generated from it is illustrated.

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

[0036] Figures 28A-28C An example list of metadata in a standardized format is provided.

[0037] Figure 29A and Figure 29B is a flow diagram that illustrates an embodiment of the disclosed innovation.

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

[0039] Figure 31 is an example cloud computing environment that can be used in connection with the technology described herein. DETAILED DESCRIPTION

[0040] ​Example 1 Overview

[0041] Increasing amounts of data are becoming available from an increasing variety of sources. Data associated with a particular purpose, such as a particular simulated world entity, is often associated with metadata that describes the data. For example, a ten-digit integer can be data, but without metadata, it can be difficult to know what the ten-digit integer represents - a phone number, a driver's license number, a password, and so on. Thus, using and making data "meaningful" can depend greatly on having the correct metadata to provide context for the data.

[0042] Databases or other data sources associated with complex work, such as the operation of an enterprise entity, 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 can be useful in another system. For example, it can be desirable to copy or transfer data from one system to another, such as when migrating from a pre-packaged database solution to a cloud-based solution. Or, it can be desirable to make data available to another platform, such as through data federation. However, without access to the metadata, it can be difficult or impossible to use or interpret the copied or federated data. Given the potentially vast amount of metadata that can exist in a source system, it can be very time consuming to recreate the metadata manually in the new system. Thus, there is room for improvement.

[0043] The present disclosure provides techniques that can be used to retrieve metadata. In particular examples, metadata at a source system can be accessed or linked for access when data described by the metadata is available at a target system. For example, data at the target system can be made available through data federation (retrieving data from the source system upon a particular request) or through data replication (retrieving data from the source system and storing on the target system, such as prior to a particular request for such data). By automatically linking data available at the target system to metadata at the source system, the data is made more available at the target system. Thus, the disclosed techniques can eliminate the need for a user to manually recreate metadata or manually retrieve metadata from a source system for a data artifact available at the source system, such as a database table, a database view, or a database procedure.

[0044] In some aspects, a metadata service at the source system facilitates metadata retrieval by the target system or an intermediary system on behalf of the target system. The metadata service at the source system can include a metadata converter that converts metadata of the source system into a common format for facilitating sharing of metadata content between systems. In a specific example, the common format can be CSN (Core Schema Notation, such as used in software available from SAP, SE of Walldorf, Germany). CSN can be considered a SQL statement that is rich in annotations or semantic information.

[0045] The source system can include an API that makes 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 creation of an API. For example, a specific entity can be flagged for exposure, and metadata related to that entity can be exposed via one or more APIs, and can optionally trigger conversion of base metadata to a standard format.

[0046] In some cases, different source systems can make data and metadata available through different interfaces. For example, one system can have a SQL API, while another system can have an OData API. The present disclosure provides techniques in which a source system can include an API catalog that contains descriptions of APIs provided by the source system in a standard format.

[0047] To facilitate storage, retrieval, and comparison of models, models can be converted between representations. For example, models can be converted between string or string-like representations (e.g., strings that hold SQL query text) and structured representations, such as programming language (including markup language) representations (e.g., instances of complex, composite, or abstract data types, such as instances of classes) or platform-independent but structured formats. For example, a string representation can be a SQL DDL statement for defining database objects such as tables and views. The string can be parsed to generate a structured representation.

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

[0049] In some cases, metadata from the source system can be retrieved when a database artifact is first instantiated on or associated with the target system. In other cases, metadata can be retrieved that supplements existing metadata of a database artifact. For example, in some cases, standard content is provided to a client associated with standard metadata. The client can wish to extend that content, and can have done so on the target system. Rather than having the client re-create such content on the target system, the disclosed technology can retrieve the extension of the standard metadata from the source system.

[0050] Example 2 Example computing environment facilitating metadata identification and import

[0051] Figure 1 An example computing environment 100 that facilitates metadata retrieval is illustrated. The computing environment 100 includes a source system 104 and a target system 108. The target system 108 is illustrated as being in communication with a database 112. While the database 112 is illustrated as a component separate from the target system 108, in some implementations the database can be part of the target system 108. In further embodiments, the computing environment 100 need not include the database 112. For example, the disclosed technology can facilitate metadata retrieval, but that retrieval need not be associated with creating a database artifact in the database 112.

[0052] The source system 104 includes a metadata repository 116. The metadata repository 116 includes metadata, such as metadata describing data maintained by or accessible to the source system 104, such as data maintained in relational database tables (not shown). An example of metadata is metadata describing data types or semantic information of data, such as information indicating when a particular value set of a database table, such as a particular column / field, represents a currency, a phone number, a social security number, etc. Metadata can indicate a language of a particular string value (e.g., German or English), or can provide details about a particular calculation of a particular number (e.g., how to calculate a particular KPI).

[0053] In some cases, metadata in the metadata repository 116 can be maintained in a format that is not readily consumable outside of the source system 104, or even by a different application of the source system. Accordingly, the source system 104 can include a converter 120. The converter 120 can convert metadata between formats, including between application-specific formats and standardized / conveyed / exchanged formats such as CSN, JSON, or XML.

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

[0055] One or more of the metadata repository 116, the converter 120, or the metadata traversal component 124 can be part of the metadata provider framework 126.

[0056] In some cases, the resolution framework 128 can have access to a set of scoping functions 132. The scoping functions 132 can be used to help determine the operation of the metadata traversal component 124. The scoping functions 132 can include graph traversal algorithms, such as algorithms that determine a transitive hull. In some cases, the scoping functions can specify that the scope includes all hierarchy views related to a selected entity or to a dimension view, related dimension views, text views associated with the dimension view, and optionally additional dimension views within a specified level of indirection. Or the scoping functions can include parameters that determine the scope of the traversal, such as retrieving all relevant or specified metadata for a specific star schema, retrieving all metadata for a specific view and all tables or views referenced by the view, or retrieving all or selected metadata for one or more specified / relevant database artifacts and artifacts within a specified level of indirection.

[0057] While the scoping functions 132 are shown in the source system 104, the scoping functions can be implemented in the target system 108 instead of or in addition to the scoping functions 132 implemented in the source system.

[0058] The metadata exposure service 136 can have access to the resolution framework 128, which in turn can communicate with the import manager 144 of the target system 108. The metadata exposure service 136 can accept metadata requests from the import manager 144 and pass them to the resolution framework 128, optionally with any scoping parameters that can be specified by the target system 108.

[0059] Source system 104 can include a search service 140 that communicates with metadata repository 116. Search service 140 can communicate all or a portion of the metadata available in metadata repository 116. Search service 140 can allow target system 108 to specify search terms (e.g., strings, portions of strings) that return relevant results from metadata repository 116 to specify specific database objects, portions of database objects (e.g., columns), or collections of database objects (e.g., specify a specific schema) to return, or a combination of search terms and database object specifications.

[0060] Search service 140 communicates with target system 108, such as through a user interface 148. User interface 148 allows a user or application to input search parameters and present search results in response. In some cases, user interface 148 allows a user to navigate through metadata repository 116. User interface 148 also communicates with import manager 144, allowing a user or application to specify a request to retrieve metadata and optionally parameters for the search request, such as scoping functionality to be used by metadata traversal component 124. In other cases, the scoping functionality is located at target system 108, and import manager 144 issues requests to metadata exposure service 136 according to the scoping functionality of target system 108.

[0061] User interface 148 can also communicate with a connection manager 152, which can also communicate with import manager 144. Connection manager 152 can store parameters for accessing source system 104, such as storing network locations of source systems, login information, user credentials, and the like. In at least some cases, the communication parameters can be provided through user interface 148. In other cases, the communication parameters can be retrieved from another source, such as from configuration information of target system 108, for example from configuration information associated with a particular application of the target system. Import manager 144 can retrieve connection information from connection manager 152 for use in connecting to metadata exposure service 136 of source system 104.

[0062] Target system 108 includes metadata repository 156. Metadata repository 156 stores metadata, including metadata received from one or more source systems 104. Metadata can be stored in the format received from source system 104 (e.g., CSN, XML), or can be converted to one or more formats used by target system 108, such as storing data in relational database tables, or storing metadata in instances of abstract or composite data types (e.g., in logical data objects, such as BusinessObjects), or in data dictionaries (such as ABAP data dictionaries), or as elements of a virtual data model (e.g., CDS views), such as implemented in software available from SAP SE of Walldorf, Germany.

[0063] Metadata repository 156 can also manage changes to metadata, such as with CRUD (create read update delete) component 158. Metadata repository 156 can manage conflicts between metadata received from source system 104 and metadata stored in target system 108. Conflicts can arise, for example, if metadata is updated on source system 104 after the metadata is initially transferred to target system 108, or if metadata is updated on the target system after import from the source system. Conflict resolution solutions can include applying rules, such as specifying that the most recent changes will be applied, or specifying that the source system 104 or target system 108 version will take precedence over the other version.

[0064] Metadata repository 156 can also include pre-deployment component 160, which in other implementations can be part of another component of target system 108, or can be implemented as a separate component of the target system. Pre-deployment component 160 can communicate with deployment component 164. Prior to sending a request to deployment component 164, pre-deployment component 160 can 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 imported metadata. Pre-deployment component 160 can perform other functions, such as editing metadata to be imported. For example, an initial specification of metadata to be imported can include dangling references, such as references to metadata or database artifacts that are below a threshold granularity specified for the import that are not exposed for export, or references to data described by the metadata but not the metadata itself. Pre-deployment component 160 can analyze the initial import specification (such as received from import manager 144, in turn received from 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 particular implementation, the deployment component 164 causes a table or view to be created in the database 112 and the metadata associated with the table to be imported. The created table or view can be implemented as a standalone table in the database 112 or can be implemented as a table identified as referencing an external table (e.g., a table stored in or accessible by the source system 104). A table identified as referencing the 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 the data is dynamically retrieved at runtime when requested. A particular implementation of a database table that references the source system 104 can be a constructed virtual table implemented in software available from SAP SE of Walldorf, Germany. The constructed virtual table can be set up as a local table that receives and stores data copied from the source system 104 or as a federated table where the requested data is dynamically fetched at runtime when requested.

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

[0067] Example 3 - Example operations in metadata identification and retrieval

[0068] Figure 2A is a timing diagram of a method 200 of a client 204 requesting metadata from a target system. The method 200 can be implemented in the computing environment 100 of Figure 1 may correspond to the respective components 108, 136, 128, 132, 126 of Figure 1 The client 204 (e.g., a component of the target system), the metadata exposure service 206, the parsing component 208, the one or more scoping functions 210, and the metadata provider 212 of the corresponding components 108, 136, 128, 132, 126 of

[0069] At 214, the client 204 provides a metadata request to the metadata exposure service 206, such as by specifying a particular database artifact or element thereof, such as specifying a particular schema, table, or view. At 216, the metadata exposure service 206 passes the request to the resolution component 208. At 218, the resolution component 208 invokes the scope bounding function 210 to determine the entity types related to the database artifact specified by the client 204. In some cases, an identifier of the scope bounding function 210 to be used is included in the request from the client 204, or the request includes a scope algorithm to be applied. In other cases, the resolution component 208 determines the scope bounding function 210 to be applied, including in cases where the request from the client 204 does not specify a scope bounding function (as well as cases where the scope bounding function 210 used by the resolution component 208 can be a default function). At 220, the scope bounding function 210 returns the related entities to the resolution component 208.

[0070] At 222, the resolution component 208 sends the metadata provider 212 identifiers of the entities whose metadata should be retrieved, optionally identifying a subset of such metadata (e.g., only particular metadata fields). At 224, the metadata provider 212 returns those identifiers as well as identifiers of additional related entities. The method 200 can loop at 218-224 until no more related entities are identified, at which point the method can proceed to 226.

[0071] At 226, the resolution component 208 sends the metadata exposure service 206 identifiers of the database artifacts with related metadata. At 228, the metadata exposure service 206 sends the resolution component 208 a request to transform the metadata of all or selected database artifacts identified at 218-224. In some cases, the resolution component 208 includes the transformer 120, in other cases, the request is sent to the transformer instead of the resolution component sending a request to transform the metadata. In yet another example, the transform request is first sent to the resolution component 208, which then sends the request to the transformer 120. Figure 1

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

[0073] Figure 2B An import process 240 is illustrated, which can include the process 200. The process is performed using a client 242 (such as a target system, which can be a cloud-based system), an import wizard 244 (which can be part of the import user interface 148 of the Figure 1 , an import manager 246 (which can be the import manager 144), a metadata repository 248 (such as the metadata repository), a deployment service 250 (which can be the deployment component 164), and a local or source system 252 (such as the source system 104 of the Figure 1 .

[0074] At 254, the client submits an import request through the import wizard 244, such as providing one or more identifiers of database artifacts to import, or providing search criteria to identify such artifacts. At 256, the import wizard 244 passes the request to the source system 252. The request can be processed by a metadata transport framework of the source system 252, such as the metadata exposure service 136 (which in turn can communicate with the resolution framework 128, the scoping function 132, or the metadata framework 126).

[0075] At 258, the source system 252 returns identifiers of related database artifacts, such as identifiers of artifacts determined using the scoping function 132. At 260, the import wizard 244 invokes the import manager 246 to retrieve at least some metadata associated with at least some of the database artifacts returned at 258.

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

[0077] At 270, the import manager 246 requests that the deployment service 250 deploy the metadata, which can 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 having the metadata. At 272, the deployment service 250 returns control to the import manager 246, optionally with an indication of whether the metadata was successfully deployed. At 274, the import manager 246 returns control to the import wizard, optionally with an indication of whether the earlier operations were successfully performed, including identifying any errors that can have occurred, and in turn, at 276, the import wizard 244 returns control / information to the client 242.

[0078] The processes 200 and 240, or processes similar thereto (e.g., containing one or more steps from one or both of these processes), can be used in processes that automatically generate database artifacts based on retrieved metadata, as well as linking the generated database artifacts to metadata used to describe the database artifacts and data stored in the source system for the database artifacts. Figure 2C An example of such a process is provided, as shown by the process 280. At 282, a user or process selects metadata for import. The metadata can be all of the 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 database artifacts of the source system, such as the columns in a table or view, the names or identifiers of these columns, and the data types associated with these columns.

[0079] At 284, the import manager 144 or user interface 148 of the system 100 receives the metadata. At 286, database artifacts are created at the target system according to the imported metadata, where the database artifacts can be created as local artifacts, or as virtual artifacts linked to the database artifacts on the source system (e.g., through data replication or federation). Figure 1

[0080] At 288, the database artifacts created on the target system are linked to the corresponding database artifacts on the source system. For example, the API on the source system used to obtain data for the database artifacts can use the metadata to identify the data to be obtained, and / or the metadata can be used to identify the database artifacts on the target system to which the data is to be linked. Figure 1 ​metadata exposure service 136 to locate and link to the database artifact on the target system. At 290, the target system can use the API to obtain data and optional additional metadata for the database artifact 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 the 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 for the database artifact. The data type can include a data member that stores an API location or a data member that stores an API type. When metadata or data is needed for a database artifact, a method of an instance of the data type for the particular database artifact can be invoked. The method can invoke an API on the source system to retrieve the requested information.

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

[0083] In some cases, there can be one method to retrieve data and a separate method to retrieve metadata for a database artifact of the source system, while in other cases, a single method can be used to obtain both data and metadata. An instance of a data type can act as a link between a particular database artifact and information maintained in the source system about the artifact. In a particular implementation, an instance of a data type is automatically created for linking a database artifact to data / metadata in the source system when the database artifact is created in the target system, or at least when the database artifact is created using the disclosed technology.

[0084] In some cases, the disclosed technology can be used to create a single database artifact. However, in other cases, the disclosed technology can be used to create multiple database artifacts. That is, for example, an identifier of a database artifact at a source system, or search criteria, can be used to identify multiple related database artifacts in the source system (such as using a scoping function). The database artifacts can be created at a target system using metadata from the source system, linked to the appropriate APIs, and data and / or additional metadata retrieved from the source system and populated to the target system.

[0085] The disclosed technology can be implemented in different ways if desired. For example, in some cases, rather than storing information for imported database artifacts in instances of abstract or composite data types, such information can be stored in a relational database table. For example, the table can have a field with a database artifact identifier, a field with an API location identifier, and a field with an API type identifier. The import process / component can access the database table to determine how to retrieve the data / metadata for the artifact, and the table can thus act as a link between the database artifact and the data / metadata in the source system.

[0086] The present disclosure can provide technology, such as process 280, for creating data artifacts at a target system based on data artifacts that are source systems. In particular, the disclosed technology can allow for automatic creation of database artifacts at a target system, and automatic import of associated data and metadata from source systems. Thus, a user can have a database artifact made quickly available to the user without the user having to perform any action manually (except to provide initial import criteria).

[0087] Use of the metadata exposure service 136 can help facilitate automation of the database artifact creation process, as it can help locate APIs for obtaining data / metadata, and provide information about how the data / metadata can be accessed (e.g., protocol / API type). The parsing framework can help ensure that relevant metadata is obtained, and can be used to create database artifacts that can be relevant to a user’s request. That is, a user can specify a single database artifact, or search criteria, and the disclosed technology can result in creation of one or more database artifacts at a target system for related database artifacts in a source system (e.g., as determined by a scoping function), and population of the target system with corresponding data / metadata from the source system.

[0088] Example 4 Example software objects that facilitate metadata discovery and exchange

[0089] Figure 3Figures illustrate how information about specific database artifacts on a source system that have 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 take 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 A portion of the API 310 expressed in SQL format is illustrated. Note that the SQL format API 310 specifies a specific database artifact 314, in this case a view "product." The database artifact 314 is specified by a schema name and an entity name.

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

[0092] In the illustrated example, 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 A standardized representation 330 of the database artifact 314 is also shown, along with metadata 332 for the artifact. The data and metadata in the standardized representation 330 can be exposed using the SQL API 310, and the information about which is made available using the standardized API representation 320. The standardized representation 330 includes an identifier 314 for the database artifact, and that identifier is included in the standardized API representation 320. In this way, the standardized API representation 320 links a specific database artifact to the SQL API 310 that can be used to obtain data for the database artifact, and links metadata associated with the data through a link to the representation 330 (which in turn can be generated from a native representation of the metadata on the source system).

[0094] Note that, in general, the standardized representation of metadata and the standardized representation of the specific entity from which data can be retrieved (and associated with the metadata) can be in a standardized format. That is, the 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 identification and type information, but the overall structure of the standardized representation can be the same (e.g., have the same fields or keys). In the same manner, the data of the specific entity can be expressed in a common format in both the standardized representation of the entity 330 and the standardized API representation 320, which can facilitate the target system finding information about the APIs available to obtain data or metadata associated with a specific database entity on the source system and the database artifacts.

[0095] Example 5 Example Metadata Exposure Service

[0096] Figure 4 Figures illustrate information exposed by a metadata exposure service 404 that can use a metadata exposure service 136 that can be Figure 1 of the metadata exposure service 136.

[0097] The metadata exposure service 404 can provide information about an entity 408, which can be a database artifact such as a table or view. The information for an entity 408 can include the name or identifier of the entity (such as a reference to the entity expressed in a serializable format such as CSN or XML), a language dependent description of the entity, an optional publication contract (which can be used to help maintain a set of entities that can be used with a specific contract identifier, which can be used to help ensure that the correct set of entities is selected, such as to maintain the set of entities stable with respect to incompatible changes such as changes that an application has not yet been updated to use), a 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 can be included, such as when the entity was first created, or an identifier of the user, process, or application that created or last updated the entity 408.

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

[0099] Entities 408 can also be associated with sources 416, where a source can be a standardized (e.g., CSN, XML) representation of an entity (e.g., a definition or content of an entity). In some cases, sources 416 of entities 408 can include language-specific content. Such content can be saved as localized data 420, where the localized data can be retrieved by navigating on a particular entity 408.

[0100] Metadata exposure 404 can be associated with contexts 424. Contexts 424 can be used to identify metadata, such as metadata belonging to a particular repository or application. That is, contexts 424 can provide namespace information, or for similar purposes as namespace information. Contexts 424 can include additional information, such as labels or descriptions of entities 408.

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

[0102] As has been described, it is often desirable to obtain metadata not only for a single entity 408, but also for a collection of related entities. Thus, a given entity 408 of metadata exposure 404 can be linked to entities in scope 432, which provides a list of related entities. The related entities can include a complete list of related entities 408, or a smaller subset of these entities. Scope defining functionality can be used to define entities in scope 432, and available scope defining functionality can be 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] Venue 444 can store information about particular venues associated with metadata exposure service 404, such as venues represented in localized data 420. Venue 444 can be used, for example, to filter data associated with metadata exposure 404 by location.

[0105] Example 6 has an example computing environment with database artifact extensions and examples thereof

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

[0107] Figure 5 A computing environment 500 in which the disclosed technology can be implemented is illustrated. The computing environment 500 includes a central database system 504, which in some implementations can be a cloud-based database system. The central database system 504 can include standard content 508, such as database artifacts 512, 514, where a database artifact can be a table or a view. The standard content 508 can be, for example, content associated with a particular application or set of applications, and generally all or most of the content is relevant to many clients. The standard content 508 can be installed from a package 518, and can be updated or upgraded using an update 522 (which can also be implemented as a package).

[0108] In some cases, a client can modify all or a portion of the standard content 508. In other cases, the standard content 508 is protected from modification by a client, especially if the standard content is shared by multiple clients or if modification of the standard content can result in loss of application functionality. If the standard content 508 is not modifiable by a client, it can be extended by a client in some implementations. That is, a database artifact of the standard content 508 can be "locked," but a client can be able to create other database artifacts that add to or alter the standard database artifact.

[0109] Figure 5 The computing environment 500 is shown to include tenants 526a, 526b. In some cases, the tenants 526a, 526b access the standard content 508 via a shared container 530, as shown for tenant 526a (where the tenant container is not shown to include artifacts 512, 514). In other cases, the tenant container can include artifacts of the standard content 508, such as shown for tenant 526b, which 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 COVID-19 pandemic that began in 2020 and the vaccines introduced in 2020-2021, employers may want to track whether employees have been vaccinated, the date of their 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 or by the client. For example, artifact 542 can be created by combining or merging artifact 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 aboutFigure 1 Similar components 144-168 are retrieved from the client system 550 in a similar manner as discussed. That is, the central system 504 or a target system 558 in communication with the central system can include components similar to the components 144-168 of the Figure 1 In some implementations, a portion of the components 148-168 can be omitted from the use case of the computing environment 500. For example, the import UI 148 can be omitted when installing, updating, or upgrading a standard package, when the system automatically attempts to retrieve client-specific information.

[0115] The logic for obtaining information from the client system 550 can be generally similar to the method 200 of FIG. 2. However, such a method can optionally remove steps from the method 200, or can add steps. As discussed, the step of receiving input from a user interface of metadata / data artifacts to import can be omitted. A step of checking the client system 550 for extensions to database artifacts of the standard content 508 can be added. If no extension exists for a particular database artifact, no further action need be taken. If an extension exists, the relevant metadata can be retrieved and used to define the data artifact 542, and the metadata can optionally be stored in a container of the tenant 526a, 526b.

[0116] In some cases, metadata can be obtained from the client system 550 multiple times. 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 can include selecting a single version of metadata or layering multiple versions of metadata. The update service 560 can apply various rules 562, which can include priority rules. For example, a priority rule can specify that the most recent version of a metadata artifact is used. Or, a priority rule can specify how multiple versions of metadata should be combined, such as with changes made by later versions overwriting metadata elements from earlier versions, where changes from the most recent version would typically be applied in case of conflict with an earlier version. Metadata elements from a base version that are not modified would be included in the final metadata in their original form. In other cases, a priority rule can specify that at least some metadata is additive. For example, if metadata is specified as an array or enumerated list of values, a rule can specify whether values are added or overwritten. Whether elements are added or overwritten can depend on the nature of the metadata element, so the rule can be specified at the granularity of a particular metadata element if appropriate.

[0118] Client system 550 can include a logging component 564. Logging component 564 can include a change list 566, which can 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 can also specify specifically what metadata to import, such as the result of applying rules 562. A change log 568 can be used to track the progress of the transfer of metadata from client system 550 to central database system 504 or target system 558, such as tracking failed transactions and error messages, so that it can be determined whether the transfer completed as expected / indicated. In some cases, instead of or in addition to including change log 568 in client system 550, it can be included in central database system 504 or target system 558.

[0119] Figure 5 An example of a standard content 508 and an extension of such standard content is also illustrated in the form of content 570 of artifact 512 and content 580 of extension 534a. Content 570 includes a selection of data 572, which includes data elements 574a, 574b. Selection of data 572 can be a query, such as a SQL query. Content 570 can include metadata elements 576a, 576b, such as elements that provide semantic information about data elements 574a, 574b. Content 570 can further include annotations 578a, 578b, 578c, where annotations can indicate characteristics of artifact 512 or control the use of the artifact, 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 annotations of content 570. As shown, content 580 includes annotation 582a, which modifies annotation 578a, annotation 582b, which sets the value of annotation 578c to NULL, and annotation 582c, which has been added to content 570. Since annotation 578b is not removed or modified, it will exist in artifact 570 when the artifact is merged with artifact extension 580.

[0121] At least in some cases, data elements and metadata can be handled in a similar manner as 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 can include additional data elements or additional selection of data elements 588, or can remove data elements, such as statement 590 that sets the value of data element 576a to NULL.

[0122] Example 7 includes an example table element of semantic identifiers

[0123] Database systems often include an information repository that stores information about the database schema. For example, PostgreSQL includes an INFORMATION SCHEMA that includes 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 noted above, these types of repositories often only store technical information about the database components, and not semantic information.

[0124] Other database systems or applications or frameworks that use database layer operations can include a repository that stores semantic information about the data. For example, SAP SE of Walldorf, Germany, provides an ABAP programming language that can be used in conjunction with database systems. ABAP provides the ability to develop database applications that are agnostic to the nature of the underlying relational database management system, including the vendor. To some extent, this ability is realized with a data dictionary. The data dictionary can include at least some information similar to that maintained in the information schema. However, the data dictionary can include semantic information about the data, and optionally additional technical information.

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

[0126] As used herein, "technical information" (or technical metadata) relates to information that describes data as data, which is information such as the type of value that can be used to interpret the data, which can affect 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 character array, among various possibilities. In some cases, the value can be processed differently depending on whether it is a number (such as an integer or floating point number), or is treated as a collection of characters. Similarly, technical information can specify acceptable values for data, such as an allowed length or number of decimal places. Technical information can specify properties of data without regard to what the data represents or "means." However, a designer of a database system can certainly choose a particular technical property for a particular data given that the designer knows the semantic properties of the data - for example, "if I want to use a value to represent a person's name, I should use a string or character array, not a floating point number." On the other hand, at least in some cases, the data type can be a type that a database administrator or user does not expect. For example, a separate numeric or alphanumeric identifier can be used instead of using a person's name to identify data associated with that person, which can be counterintuitive based on the "meaning" of the data (e.g., "I don't think of myself as a number").

[0127] As used herein, "semantic information" (or semantic metadata) relates to information that describes the meaning or purpose of data, which can be for a human or for a computer process. As an example, technical data information can specify that data having a value in the format of "XXX-XX-XXXX" where X is an integer between 0 and 9 is obtained. This technical information can be used to determine how the value should be processed by the data, or whether a particular value is valid (e.g., "111-11-1111" is valid, but "1111-11-1111" is not), but does not indicate what the value represents. Semantic information associated with the data can indicate whether the value is a social security number, a phone number, a routing address, etc.

[0128] Semantic information can also describe how data is to be handled or displayed. For example, "knowing" that data is a phone number can cause the value to be displayed in one part of a GUI rather than another part of the GUI, or can cause or not cause a particular handling rule to be invoked, depending on whether the rule is valid for "phone number." In at least some cases, "semantic information" can include other types of information that can be used to describe data or how data should be used or handled. In particular cases, data can be associated with one or more of the following: a label, such as a human-understandable description of the data (e.g., "phone number"), a document, such as a description of what information should be included in a field with a label (e.g., "enter an 11-digit phone number including area code"), or information that can be used in a help screen (e.g., "enter your home phone number here").

[0129] In general, technical information must be provided for data. For example, in the case of fields of a database table, it is generally necessary to provide a name or identifier for the field and the data type. The name or identifier of the field can or can not be used to provide semantic information. That is, a database designer can choose the name "Employee_Name," "EMPN," or "3152." However, since the name or identifier is used to locate / differentiate this field from another field, it is considered technical information, not semantic information, in the context of the present disclosure, even though it can readily convey meaning to a human. In at least some implementations, the use of semantic information is optional. For example, even with the use of a data dictionary, some fields used in a database object (such as a table, but possibly other objects, where these other objects are typically associated with one or more tables in an underlying relational database system) can be specified without the use of semantic information, while other fields are associated with semantic information.

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

[0131] ​Each of the tables 604, 608, 612, 616 has a plurality of attributes 620 (although, in some cases, a table can have only one attribute). For a particular table 604, 608, 612, 616, one or more attributes 620 can act as a primary key - uniquely identifying a particular record in a tuple, and being assigned as the primary method of accessing tuples in the table. For example, in table 604, the Car_Serial_No attribute 620a acts as a primary key. In table 616, the combination of attributes 620b and 620c together act as a primary key.

[0132] Tables can reference records associated with a primary key of another table by using foreign keys. For example, the license number table 616 has an attribute 620d of Car_Serial_No in table 616 that is a foreign key and is associated with the corresponding attribute 620a of table 604. The use of foreign keys can be used for various purposes. Foreign keys can link particular tuples in different tables. For example, the foreign key value 8888 of attribute 620d will be associated with a particular tuple in table 604 that has that value for attribute 620a. Foreign keys can also act as constraints, where a record cannot be created (or changed to have) a foreign key value that does not exist as a primary key value in the referenced table. Foreign keys can also be used to maintain database consistency, where changes to a primary key value can be propagated to tables where attributes are foreign keys.

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

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

[0135] Example 8 - Example Table Elements Including Semantic Identifiers

[0136] Figure 7is a diagram illustrating elements of a database schema 700 and how they can be interrelated. In at least some cases, the database schema 700 can be maintained outside of the database layer of a database system. That is, for example, the database schema 700 can be independent of the underlying database, including the schema for the underlying database. Generally, the database schema 700 is mapped to the schema of the database layer (e.g., the schema 600 of the database 600), such that records or portions thereof (e.g., specific values of specific fields) can be retrieved through the database schema 700. Figure 6

[0137] The database schema 700 can include one or more packages 710. The packages 710 can represent organizational components used to categorize or classify other elements of the schema 700. For example, the packages 710 can be replicated or deployed to various database systems. The packages 710 can also be used to enforce security restrictions, such as by limiting access to specific schema elements by specific users or specific applications.

[0138] The packages 710 can be associated with one or more domains 714 (i.e., semantic identifiers or semantic information of a specific type). In turn, the domains 714 can be associated with one or more packages 710. For example, domain 1, 714a is associated with only package 710a, while domain 2, 714b is associated with both package 710a and package 710b. In at least some cases, a domain 714 can specify which packages 710 can use the domain. For example, a domain 714 that can be associated with materials used in a manufacturing process can 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 have access to a domain 714 (and database objects incorporating the domain), the domain (and optionally other database objects, such as tables 718, data elements 722, and fields 726, described in greater detail below) is primarily assigned to one package. Assigning a domain 714 and other database objects to a unique package can help create logical (or semantic) relationships between database objects. In Figure 7 In the example, the assignment of domains 714 to packages 710 is shown as solid lines, while access permissions are shown as dashed lines. Thus, domain 714a is assigned to package 710a, while domain 714b is assigned to package 710b. Package 710a can access domain 714b, but package 710b cannot access domain 714a.

[0140] ​Note that at least some database objects, such as tables 718, can include database objects that are associated with multiple packages. For example, table 718 (table 1) can be assigned to package A and have fields assigned to package A, package B, and package C. The use of fields in table 1 assigned to package A, package B, and package C creates a semantic relationship between package A and package B and package C, which can be further interpreted if the fields are associated with a particular domain 714 (i.e., a domain can provide further semantic context for a database object that is associated with an object of another package (rather than being assigned to a general package)).

[0141] As will be explained in greater detail, domains 714 can represent the finest granularity unit from which database tables 718 or other schema elements or objects can be constructed. For example, domains 714 can be associated with data types at a minimum. Each domain 714 is associated with a unique name or identifier, and is typically associated with a description, such as a human-readable textual description that provides the semantic meaning of the domain (or an identifier that can be related to a human-readable textual description). For example, one domain 714 can be an integer value that represents a phone number, while another domain can be an integer value that represents a part number, while yet another integer domain can represent a social security number. Thus, domains 714 can be maintained across schema 700 to provide a common and consistent use (e.g., semantic meaning). That is, for example, whenever a domain that represents a social security number is used, the corresponding field can be recognized as having that meaning, even if the field or data element has a different identifier or other characteristics for a different table.

[0142] Schema 700 can include one or more data elements 722. Each data element 722 is typically associated with a single domain 714. However, multiple data elements 722 can be associated with a particular domain 714. Although not shown, multiple elements of a table 718 can be associated with the same data element 722, or can be associated with different data elements that have the same domain 714. Data elements 722 can be used to allow for customization of domains 714 for a particular table 718, among other things. Thus, data elements 722 can provide additional semantic information for elements of a table 718.

[0143] Tables 718 include one or more fields 726, at least some of which are mapped to data elements 722. Fields 726 can be mapped to a schema of a database layer, or a table 718 can be mapped to a database layer in another manner. In any case, in some embodiments, fields 726 are mapped to a database layer in some manner. Alternatively, a database schema can include semantic information equivalent to elements of schema 700, including domains 714.

[0144] In some embodiments, one or more of the fields 726 are not mapped to a domain 714. For example, the fields 726 can be associated with raw data components (e.g., associated with raw data types such as integers, strings, Boolean values, character arrays, etc.) that do not include semantic information. Alternatively, the database system can include one or more tables 718 that do not include any fields 726 associated with the domains 714. However, the disclosed technology can include a schema 700 (which can be separate from the database schema, or incorporated into the database schema) that includes a plurality of tables 718 having at least one field 726 associated with a domain 714, directly or through a data element 722.

[0145] Example 9 Data Dictionary Component

[0146] Schema information, such as information associated with the schema 700 of Figure 7 The schema information, such as information associated with the schema 700 of

[0147] Figure 8A database environment 800 is illustrated with a data dictionary 804 that can be accessed such as by a mapping access database layer 808. The database layer 808 can include a schema 812 (e.g., INFORMATION_SCHEMA in PostgreSQL) and data 816, such as data associated with a table 818. The schema 812 includes various technical data items / components 822, which can be associated with a field 820, such as a field name 822a (which can or can not correspond to an easily human-understandable description of the purpose of the field, or otherwise explicitly describe the semantic meaning of the values of the field), a field data type 822b (e.g., integer, variable length string, string, Boolean), a length 822c (e.g., the size of the number of digits allowed for the value in the field, the length of the string, etc.), a number of decimal places 822d (optionally, for suitable data types, such as for a floating point number with a length of 6, specifying whether the value represents XX.XXXX or XXX.XXX), a position 822e (e.g., the position in the table at which the field should be displayed, such as being the first displayed field, the second displayed field, etc.), optionally a default value 822f (e.g., "NULL", "0", or some other value), a NULL flag 822g indicating whether the field allows NULL values, a primary key flag 822h indicating whether the field is or is used in the primary key of the table, and a foreign key element 822i that can indicate whether the field 820 is associated with the primary key of another table, and optionally an identifier of the table / field referenced by the foreign key element. A particular schema 812 can include more, fewer, or different technical data items 822 than shown. Figure 8

[0148] The table 818 is associated with one or more values 826. The values 826 are typically associated with fields 820 defined using one or more of the technical data elements 822. That is, each row 828 typically represents a unique tuple or record, and each column 830 is typically associated with a definition of a particular field 820. The table 818 is typically defined as a collection of fields 820 and is given a unique identifier.

[0149] The data dictionary 804 includes one or more packages 834, one or more domains 838, one or more data elements 842, and one or more tables 846, which can at least generally correspond to the similarly named components 710, 714, 722, 718 of Figure 7 Figure 7 ​​As explained in the discussion of FIG. 8, the package 834 includes one or more (typically multiple) domains 838. Each domain 838 is defined by a plurality of domain elements 840. The domain elements 840 can include one or more names 840a. The names 840a are used to uniquely identify the particular domain 838 in some cases. The domain 838 includes at least one unique name 840a, and can include one or more names that can or can not be unique. The names that can or can not be unique can include various length or detail versions of the name or description of the domain 838. For example, the names 840a can include text that can be used as a label for the domain 838, and can include short, medium, and long versions, as well as text that can be designated as a header. Alternatively, the names 840a can include a primary name or identifier and a short description or field label that provides human understandable semantics for the domain 838.

[0150] In at least some cases, the data dictionary 804 can store at least a portion of the names 840a in multiple languages, such as to make domain labels available in 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 the names 840a, can be searched. For example, if "customer" is specified, the German and French portions of the names 840a can be searched in addition to the English version.

[0151] The domain elements 840 can also include information at least similar to that which can be included in the schema 812. For example, the domain elements 840 can include a data type 840b associated with the relevant data type, a length 840c, and a number of decimal places 840d, which can correspond to the technical data elements 822b, 822c, 822d, respectively. The domain elements 840 can include conversion information 840e. The conversion information 840e can be used to convert (or convert to and from) values entered for the domain 838 (optionally including as modified by the data elements 842). For example, the conversion information 840e can specify that numbers having the form XXXXXXXX should be converted to XXX-XX-XXXX, or that numbers should have decimal places or commas separating groups of digits (e.g., format 1234567 to 1,234,567.00). In some cases, the field conversion information for multiple domains 838 can be stored in a repository, such as a field directory.

[0152] Domain element 840 can include one or more value restrictions 840f. Value restrictions 840f can specify, for example, that negative values are allowed or disallowed, or a specific range or threshold of values that are acceptable for domain 838. In some cases, an error message or similar indication can be provided when an attempt is made to use a value with domain 838 that does not comply with value restrictions 840f. Domain element 840g can specify one or more packages 834 that are allowed to use domain 838.

[0153] Domain element 840h can specify metadata that records 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, and the time at which the modification occurred. In some cases, domain element 840h stores a greater history of creation and modification of domain 838, including a complete history.

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

[0155] Data element 842 can include data element fields 844, at least some of which can be at least generally similar to domain elements 840. For example, data element field 844a can correspond to at least a portion of name domain element 840a, such as being (or including) a unique identifier for the particular data element 842. Field tag information described with respect to name domain element 840a is shown divided into short description tag 844b, medium description tag 844c, long description tag 844d, and header description 844e. As described for name domain element 840a, tags and header 844b-844e can be maintained in one language or multiple languages.

[0156] Data element field 844f can specify a domain 838 for use with data element 842, incorporating features of domain elements 840 into the data element. Data element field 844g can represent a default value for data element 842, and can be at least similar to default value 822f of schema 812. Created / modified data element field 844h can be at least generally similar to domain element 840h.

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

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

[0159] Create / modify table element 848e can be at least generally similar to domain element 840h.

[0160] Example 10 Example Metadata Model

[0161] Figure 9 A definition of a metadata model 900 is illustrated. In particular, metadata model 900 represents a view, such as a Core Data Services view of SAP SE of Walldorf, Germany, and is expressed in a format such as CSN. Metadata model 900 can include a variety of different components, at least some of which can be considered a metadata model. That is, metadata model 900 can be a model that is based at least in part on a plurality of sub-models. The sub-models can specify specific aspects of the overall metadata model 900.

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

[0163] In the illustrated example, the annotation 904 can be indicated as an annotation using a particular syntax element, such as by prefixing the annotation with an "@" symbol. In at least some cases, the annotation 904 can also be indicated by placing the annotation 904 in an appropriate portion of the metadata model, such as in a header portion or another portion assigned for annotations. In some cases, the annotation 904 can reference other metadata models, such as a metadata model of a data source, or can reference a data source associated with the metadata model. In either case, such an association 904 can create a dependency between the metadata model 900 and the other metadata model / data source.

[0164] The metadata model 900 can include an instruction 908, in this case a SQL statement 910, that defines a core metadata model / object with an identifier 912 (which can be used, for example, to later access or activate, such as instantiate, the metadata model). In particular, the illustrated instruction 908 defines a view. The annotation 904 further specifies characteristics of the view, as do other portions of the metadata model 900, as will be further described.

[0165] The instruction 908 can specify one or more data sources 916. The data sources 916 can define data to which at least a portion of the metadata of the metadata model 900 is to be applied, and can also supply additional metadata for the metadata model 900. Note that the metadata model 900 can depend, at least in some sense, on the referenced data sources 916. For example, if the metadata model 900 depends on particular data or metadata of the data sources 916 that is expected, the metadata model can not be usable, have performance issues, or provide incorrect results if the referenced data sources do not include the expected data or metadata, or otherwise are inconsistent with how the data sources are to be used in the metadata model. As illustrated, the data sources 916 include two tables, "vbak" and "vbkd." These tables will typically include metadata characteristics, such as one or more fields, with each field associated with a data type, an assignment of a primary key, and optionally an association with other database components, such as an association with other database tables or foreign key relationships.

[0166] The metadata model 900 can optionally include a specification of one or more associations 920. The associations 920 can define a relationship with another entity. The associations 920 can be processed during use of the metadata model 900, such as converted into a SQL expression such as a JOIN. Unlike other conditions or elements included in the metadata model 900, the associations can define a relationship that is optional at least in some cases, such as selectively activated depending on how the metadata model is accessed. For example, the associations 920 can be converted into a JOIN condition that uses a table provided in a SELECT statement that references the metadata model 900.

[0167] The metadata model 900 can 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. The processing can include computing values, such as using formulas specified in or referenced by the metadata model 900. In particular, the processing components 922 can specify that a particular field value should be treated as an element 924, where the element can be as described in examples 8 and 9. Thus, the metadata model 900 can include dependencies on how to define elements, and the metadata model 900 can not be accurate or usable if the element definitions do not match how it is used and intended to be used in the metadata model 900.

[0168] The metadata model 900 can optionally include additional components such as one or more conditions 928, or other operations such as aggregations, unions, and the like, including those typically supported by database query languages.

[0169] Example 11 illustrates a metadata model, including relationships to other metadata models

[0170] Figure 10 illustrates how a metadata model can depend on other metadata models. In particular, Figure 10 illustrates a view metadata model 1004, which can be Figure 9 the metadata model 900. Figure 10 Also illustrated are a metadata model 1008 for access control objects such as DCLS or data control language sources, a metadata model 1012 for metadata extension objects such as DDLX or metadata extensions, and a metadata model 1016 for extension element objects such as DDLS or data definition language sources. The metadata model 1016 represents an extension, whose data can be imported by a target system from a source system, as described in example 6.

[0171] Access control object metadata model 1008 can be used to restrict access to data that can be retrieved using view metadata model 1004. For example, when view metadata model 1004 is activated, view metadata model 1004 and access control object metadata model 1008 can be processed together, such as generating SQL commands that retrieve data for the view metadata model, but the commands are filtered or restricted based on the access control object metadata model. Because access control object metadata model 1008 references view metadata model 1004, the access control object metadata model is dependent on the existing view, and on the view containing the elements specified in the access control object metadata model. For example, the access control object metadata model references the "SalesOrderType" element of view "I_SampleSalesOrder" and the authorization object "V_VBAK_AAT" with its authorization field "AUART". Thus, the first element would be undefined or unavailable if the corresponding element did not exist in view metadata model 1004.

[0172] Metadata extension object metadata model 1012, which adds annotations to view metadata model 1004, has similar dependencies on the view metadata model, as does extension element object metadata model 1016, which adds additional elements to the view metadata model.

[0173] Example 12 Example relationship model for metadata models

[0174] Figure 11 Figure illustrates how metadata models can depend on each other, and can change over time, which can affect the use or validity of the dependent metadata models. At time tO, a data definition language version of the metadata models is provided. Metadata model 1110 is used for Viewl, and model 1112 is used for View2. Model 1112 for View2 references Viewl, because it contains a SQL select statement that defines a specific subset of the data defined by model 1110 for Viewl. Thus, model 1110 includes a dependency on model 1112. Specifically, model 1110 depends on the existence of Viewl, and on the existence of field "KeyField" in Viewl.

[0175] At time tl, a second version of the model 1116 for View2 is received. Model 1116 includes another field Fieldl of Viewl in the definition of View2, compared to model 1112. In some cases, model 1116 can be provided as a complete model, while in other cases only the changes compared to the previous model version are sent.

[0176] At time t2, an indication 1122 is received on the second system that View2 is deleted. Note that in this case, the deletion of View2 does not affect any of the described metadata models because View2 depends on Viewl, but Viewl does not depend on View2. In contrast, if Viewl had been deleted at time t2, it could be determined that deleting Viewl would cause problems for View2.

[0177] Figure 11 Figures illustrate a metadata model defined in a first format, such as SQL statements defining views. Figure 12A and Figure 12B Figures illustrate how the metadata model shown in Figure 11 Figures can be converted to a different format, such as records in a set of database tables storing a representation of the metadata model. Specifically, Figure 12A Figures show a table 1204 that includes a field 1206 for the object type associated with the table's record, a field 1208 that holds the object name, a field 1210 that holds a version identifier associated with the object, a field 1212 that provides a type associated with the original format (e.g., plain text, JSON, XML, CSON, etc.) in which the corresponding metadata model was received, a field 1214 that holds a list of original source content (in the type associated with field 1212), and a field 1216 that includes a timestamp of when the object was received (e.g., with reference to Figure 11 , timestamps associated with times t0, tl, or t2). Table 1204 can optionally include one or more additional fields 1220.

[0178] As can be seen, table 1204 includes a record 1222 for Viewl received at t0, a record 1224 for the metadata model of View2 received at t0, and a record 1226 for the metadata model of View2 received at tl. Note that table 1204 can include information for object source versions, so the type, name, and version information (i.e., fields 1206, 1208, 1210) can be specific to objects that are object sources (e.g., data definition language sources or DDLS).

[0179] Table 1228 can include fields for data definition language object versions, which can include a field 1230 for DDLS name and a field 1232 for DDLS version identifier, which can correspond to fields 1208, 1210 of table 1204. Table 1228 can also include a field 1234 that describes the entity (e.g., metadata model) type associated with the corresponding metadata model. Examples of entity types can be table, view, access control, annotation extension, metadata extension, 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 the specific software components listed in field 1272 (and corresponding to field 1260) with the particular system software version listed in field 1274. In turn, table 1254 can associate the particular software system version in field 1276 with the particular system indicated by the system identifier in field 1278 and the timestamp indicating when the system was installed, released, or activated in field 1280. Table 1256 can include field 1282 (corresponding to field 1260) for a specific software component version, with an identifier for the software component provided in field 1284, a release identifier in field 1286, and a support pack identifier in field 1288. Each table 1250, 1252, 1254, 1256 can optionally include one or more additional fields 1290.

[0184] Example 13 illustrates a metadata relationship model, including query language operations

[0185] Figure 13 The scenario of defining a metadata model 1304 (specifically, a view) with reference to two view metadata models 1306, 1308, which can in turn rely on one or more additional data models, is illustrated. Metadata model 1306 relies on a table's metadata model 1310, while metadata model 1308 relies on a table's metadata model 1312, and has an association with a metadata model 1314 for another view, which in turn references a table's metadata model 1316. These dependencies can be evaluated as described for the scope defining functions and traversal components for identifying associated metadata for a database artifact and one or more specified artifacts, including artifacts in response to a specific search / query request.

[0186] The view metadata models 1304, 1306, 1308, 1314 include SQL select statements, which can be stored in alternative formats, such as in tabular form, as shown in Figure 14 Figure 13 The select statements of the view metadata models 1304, 1306, 1308, 1314 can include additional features / operations that can be stored in alternative representations, such as join conditions 1320 in metadata model 1304, an association 1324 between metadata model 1308 and metadata model 1314, and where conditions 1328 in metadata model 1314.

[0187] Figure 14 ​Table 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 noted above, select statements used in the metadata model can have additional operations, which can be recorded in table 1404. If the object metadata model definition includes a where condition, an identifier for the condition can be included in field 1428. Metadata model 1314 includes a where condition 1328, so an identifier for the condition can be entered in field 1428 of record 1422. The identifier in field 1428 can identify a particular set of conditions, where additional information can be included in a condition set table 1432, as will be further described. Similarly, if the object metadata model definition includes a join condition, an identifier for the condition can be included in field 1436. The identifier in field 1434 can identify a condition set in table 1432.

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

[0192] Table 1432 includes a field 1456 for version identifiers for the objects listed in field 1440, and can correspond to field 1412. Field 1458 includes a condition set identifier, and can correspond to fields 1428, 1436. A group ID field 1460 and a group sequence number field 1462 can be used to preserve the semantics of the originally expressed conditions (e.g., in SQL). For example, 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, 1448 are associated with group identifier 2, because both records are associated with the value VIEW2 in field 1464. The value of group sequence number field 1462 can further identify the specific semantics of records 1446, 1448, such as indicating that record 1446 precedes record 1448 in the originally select statement. A group operator field 1466 can provide an operator to be associated with the records associated with a particular group identifier value of 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 metadata model of 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 standardized 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 minimum cardinality fields 1496 and maximum cardinality fields 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 illustrates a relational metadata model, including field definitions and relationships.

[0199] In some cases, a metadata object, such as a view, can include fields that are computed based at least in part on elements (e.g., fields) of one or more other metadata models, or otherwise based at least in part on elements (e.g., fields) of one or more other metadata models. The computation can be specified explicitly in the metadata model definition, or can be referenced in the model definition, such as 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 A metadata model 1504 that defines a view that references a metadata model 1508, which in turn references a table defined by metadata model 1512 is illustrated. Metadata model 1504 includes four fields 1520, 1522, 1524, 1526 that are derived from fields in metadata model 1508. Metadata model 1508 includes three fields 1530, 1532, 1534 that are selected from a table defined by metadata model 1512. The table defined by metadata model 1512 includes three fields 1540, 1542, 1544 that are declared / defined in that metadata model.

[0201] Figure 16 A table 1600 that can be used to summarize fields used in metadata models 1504, 1508, 1512 is illustrated. Table 1600 includes a field 1602 that indicates the type of object associated with the field, such as being 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 a system with which the metadata model is used, or for example, an object name used or provided by a metadata repository.

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

[0203] Each metadata object can be associated with one or more fields, and fields 1610 can store a standardized representation of the field name provided in fields 1612. For example, fields 1610 can store a name that removes formatting / capitalization from the field name listed in fields 1612 (e.g., lower case letters). As described above, a metadata model can incorporate fields from other metadata models. The direct source of a field can have a name provided in fields 1614, and can have a type, such as a table or view, and the type can be provided in fields 1616. The name of a field in the direct source can be different from the name of the field in the metadata model into which it is incorporated, so fields 1618 can include the name of the field in the source metadata model.

[0204] Computed fields can be associated with an expression, and an identifier of the expression can be provided in fields 1620, which can be used to access the expression, such as an expression stored as a representation in one or more other tables. Fields 1622 can indicate whether the field is a key field (e.g., a field used in a primary key). A field can be associated with a data type that can be listed in fields 1626, and the data type can be associated with additional semantic or technical information (such as in a data element), an identifier of which can be provided in fields 1624. In general, a data type associated with fields 1626 (and in turn, fields 1624) can have a length, such as a number of digits or characters allowed, and this information can be included in fields 1628.

[0205] A numeric field that allows use of decimals can be associated with a value (e.g., a number of decimal places allowed) through fields 1630. Fields 1632, 1634, 1636, 1638 can be used to define where the definition of an expression occurs in a source metadata model, such as a start row, start column, end row, and end column, respectively. Table 1600 can optionally include one or more additional fields 1640.

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

[0207] Example 15 illustrates a relational metadata model, including annotations

[0208] As described in example 10, metadata objects such as view definitions can include annotations. Figure 17 Figure illustrates how metadata objects that can depend on each other can have annotations that 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 View2, which is defined relative to another view Viewl defined in metadata model 1708. Metadata model 1712 for metadata extension DDLX2 provides additional metadata elements for this metadata model 1704. Metadata model 1708 includes two annotations 1720, 1722 that can be incorporated into metadata model 1704. However, annotation 1720 that provides a label for Viewl is replaced by annotation 1726 defined in metadata model 1704 for View2. In some cases, an annotation in a referenced metadata model can be replaced if it has the same name or type as an annotation in the referencing metadata model (e.g., "@EndUserText.label" as shown).

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

[0211] The table 1800 can summarize annotations of a metadata model Figure 17 The table 1800 includes a field 1804 of object types associated with a metadata model that is annotated by a record representing an annotation. As shown, the field 1804 includes a value of "DDLS" for a view, or a value of "DDLX" for a metadata extension object. The field 1808 can provide a name of the object, such as a system name, while the field 1812 can provide an object name defined by a declaration of the object. The field 1810 can provide a version identifier of the object. The field 1814 can provide a name of a sub-entity associated with the annotation, which can be, for example, a specific view field to which the annotation applies.

[0212] The field 1816 can provide an annotation internal identifier, which can be used to distinguish multiple annotations of a metadata model, and can be used to provide an ordering of the annotations when there are multiple annotations of a metadata model. As will be further described, the value of the field 1816 can also be used to relate a base or parent annotation or annotation type to a child annotation. An annotation name can be included in the field 1818, which can be a type (or class) or a sub-type (or class method or class data member) of the annotation. The field 1820 can provide an identifier of a parent annotation. For example, the record 1840 assigns an annotation internal identifier of "1" to the "ENDUSERTEXT" annotation. The "ENDUSERTEXT" can be a base annotation type, and the record 1842 can include a sub-type of the annotation of "ENDUSERTEXT.LABEL," with the value of "1" in the field 1820 indicating that the record 1842 references the annotation of the record 1840.

[0213] The values of annotations defined in the declarations of the metadata model can be provided in field 1822. The values in field 1822 represent explicitly defined values assigned to the annotations. The effective values assigned to the annotations can be indicated in field 1824. For example, the annotation @Search.defaultSearchElement has an effective value of "TRUE" even though this is not explicitly captured in the declaration of the metadata model, but is automatically derived from the annotation default logic. Further, in the illustrated example, the effective values of language-dependent text can be specified relative to identifiers in table 1850, where the values in field 1824 correspond to values in text identifier field 1854. Table 1850 is further shown to include field 1856, which provides a 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 for all annotations incorporated into a particular metadata model. However, as noted above, some annotations can not be "active," e.g., because locally declared annotations can override imported or referenced annotations. Similarly, in some cases, annotations from multiple referenced sources (e.g., metadata models) can overlap or conflict, in which case only one annotation (or typically a subset) can be assigned as active. It can be beneficial to maintain a separate repository of active annotations, which can be stored as shown in table 1900 of FIG. 19. Figure 19

[0215] Table 1900 can include field 1904 for object type, field 1908 for object name, field 1910 for object version identifier, field 1912 for entity name, field 1914 for sub-entity name, field 1916 for annotation internal identifier, field 1918 for annotation name, field 1920 for parent annotation identifier, field 1922 for annotation value, and field 1924 for effective annotation value, which can be implemented at least generally as described for the similarly titled and numbered fields of table 1800.

[0216] Table 1900 can include additional fields, such as active annotation version identifier field 1930. Note that the active annotation version identifier in field 1930 can have a different value than the object version identifier in field 1910. For example, a new metadata extension can change the active annotations for an existing base (e.g., view) model version that is being annotated, so it can 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., the metadata model). Accordingly, field 1932 can store the object type associated with the annotation (either the local object type or the object type of the 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 Example API for metadata access

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

[0220] Figure 20 An excerpt 2004 of the persistence model (e.g., all or part of the tables of examples 12-15) and an excerpt 2050 of an OData service that can be used to access data maintained in the persistence or determined or computed from data in the persistence is illustrated. The persistence excerpt 2004 can 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 original metadata object definition information), select statement information 2026 associated with an object version, association information 2028 associated with an object version, field information 2030 associated with an object version, condition information 2032 associated with an object version (e.g., "where" or "on" conditions such as described with respect to 1432), local annotation information 2034 associated with an object version, and active annotation information 2036 associated with an object version.

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

[0222] Figure 21An example table 2104 with object version source information and an example table 2108 with DDLS version information are illustrated. Table 2104 can have a plurality of fields, including a field 2112 for object type associated with a record, a field 2114 for object name associated with a record, and a field 2116 for object version identifier associated with a record. Table 2108 can have a field 2120 for DDLS name, a DDLS version field 2122, an entity name (such as CDS entity name) field 2124, and an original entity name field (such as original CDS entity name) field 2126.

[0223] With the metadata representation of tables 2104 and 2108, and using the excerpt 2050, the navigation properties of the excerpt can be traversed from the record of object version source table 2104 to the DDLS version table 2108 by an OData read request as follows:

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

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

[0226]

[0227] The API can allow searching for all related information for a given object version. For example, a search request for "cust" can have the following form:

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

[0229] which retrieves all five records of DDLS object name (e.g., field 2114) as I_CUSTOMER. Note that the user can retrieve and access the metadata information without knowing the exact name of the metadata model or any of its constituent elements.

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

[0231] As an example, for a request to upload a metadata model, rather than converting object source information for each individual table starting from the object version table into a table storing more detailed information, a user or application can request an upload object action, which can provide a defining object's initial string (e.g., initial SQL statement), optionally along with additional information such as the type of initial source string (e.g., SQL, XML, plain text), the object's name, the object type (e.g., view, table), other information, and combinations thereof. The input can 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 the persistence format used by the metadata service. At least in some cases, it can be determined if any metadata models depend on the updated model, and if so, such dependent models can be updated to provide the new model version.

[0241] For comparing the functionality of 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. An example input for comparing two versions of a metadata model can include:

[0242] ObjectType

[0243] ObjectName

[0244] ObjectVersion1Id

[0245] ObjectVersion2Id

[0246] ChangeTypes [e.g., change types to query, such as all, insert, update, delete, invariant]

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

[0248] The comparison can return information, including:

[0249] ObjectVersion

[0250] ChangeType

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

[0252] SubObjectName

[0253] PropertyType [e.g., active annotation, key, data type, name]

[0254] PropertyName

[0255] PropertyValue

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

[0257] Input:

[0258] ChangeTypes = INSERT

[0259] ComparisonScope = ALL

[0260] The response can include:

[0261] Output:

[0262] ObjectVersion = 2

[0263] ChangeType = INSERT

[0264] SubObjectType = FIELD

[0265] SubObjectName = NewField

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

[0267] A metadata exposure service or other functionality for accessing a metadata repository can be to return a list of objects that use a particular metadata element. For example, a field can initially be defined for a particular table, but subsequently can be referenced by multiple views. The input to this functionality can include:

[0268] Input:

[0269] ObjectType: Identification

[0270] ObjectName: Identification

[0271] ObjectVersionId: Identification

[0272] UseageTypes [e.g., ALL, associated, target, data source, annotation)

[0273] MaximumNumberOfIndirections

[0274] The output of the request can include:

[0275] UsingObjectType

[0276] UsingObjectName

[0277] UsingObjectVersionId

[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 model includes metadata model 2208 for View3, which references metadata model 2210 for View2, which references metadata model 2212 for Viewl, which in turn references metadata model 2214 for Tablel. Assume that each view 2208, 2210, 2212 references a field of Tablel, and that the views reference this field through the views they reference as shown, then the request can be:

[0285] Input:

[0286] ObjectName: TABLE1

[0287] UseageTypes: ALL

[0288] MaximumNumberOfIndirections: 5

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

[0290] For dependency checking, the input (e.g., the parameters of a function) can include:

[0291] ObjectType

[0292] ObjectName

[0293] ObjectSourceType

[0294] ObjectSourceContent

[0295] SoftwareComponentVersions

[0296] NewSoftwareComponentVersions

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

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

[0299] MessageText

[0300] EntityReference [e.g., a link to additional details of the metadata model so that additional information about the dependent object can be identified]

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

[0302] MessageType: INFO

[0303] MessageText: New annotation NewAnnotation added to field ViewField

[0304] EntityReference

[0305] =... / sap / opu / odata / sap / CdsMetadataService / ...NewAnnotation...

[0306] A service handling access to the metadata can facilitate or assist in displaying the metadata information to an end user, such as on a user interface screen. The service can augment the model metadata with additional information that can define the layout of the user interface, and can include or define additional services that allow the user to interact with the data. For example, as shown in the example code of Figure 23 , an annotation can be provided that aids the user in providing filter criteria via value help.

[0307] Example 17 Example glossary

[0308] As discussed with respect to Figure 4 , a metadata exposure service can provide access to a glossary that describes the annotations that act as metadata for a database artifact. Some examples of how a glossary can be derived from the corresponding annotations are provided.

[0309] Figure 24A An annotation 2404 for a data warehouse is illustrated, which lists the elements of the annotation 2414. Figure 24B An example glossary 2426 created from the annotation 2404 is provided. The annotation 2404 represents an annotation expressed in CDS notation (as in products available from SAP SE of Walldorf, Germany), while the glossary 2426 is expressed in CSN. This pattern of using CDS notation for annotations, and CSN notation for glossaries, continues in the remaining examples in this example 17.

[0310] 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.

[0311] Example 18: Standardized API and Metadata Representation

[0312] Figures 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.

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

[0314] Example 19 Example Implementation

[0315] Figure 29A This is a flowchart of an example method 2900 for sending metadata of data artifact extensions to a target system. Method 2900 can be... Figure 1 Computing environment 100 or Figure 5 It is implemented in the computing environment 500.

[0316] At 2905, a first request for at least a portion of the metadata in the metadata repository is received from the target system. At 2910, one or more software objects comprising metadata extensions of one or more database artifacts are identified. At 2915, in response to the first request, at least a portion of the metadata elements of the metadata extensions are returned to the target system.

[0317] Figure 29B This is a flowchart of an example method 2950 for obtaining metadata describing database artifacts from a client system. Method 2950 can be... Figure 1 Computing environment 100 or Figure 5 It is implemented in the computing environment 500.

[0318] In 2955, multiple database artifacts are created in the database system. These artifacts are configured to store data or references to data, where the data is described by metadata. In 2960, at least the first part of the metadata associated with the data is deployed. In 2965, a request for the second part of the metadata associated with the data is sent to the client system. In 2970, the second part of the metadata is deployed.

[0319] Example 20 Computing System

[0320] 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.

[0321] 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 units can be general-purpose central processing units (CPUs), processors in application-specific integrated circuits (ASICs), 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 memories 3020, 3025 may be volatile memories (e.g., registers, caches, RAM), non-volatile memories (e.g., ROM, EEPROM, flash memory, etc.), or some combination thereof, accessible by the processing units(s) 3010, 3015. Memories 3020, 3025 store 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.

[0322] 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.

[0323] The tangible storage 3040 can be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory way and that can be accessed within the computing system 3000. The storage 3040 stores instructions for the software 3080 implementing one or more innovations described herein.

[0324] The input device(s) 3050 can be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing system 3000. The output device(s) 3060 can be a display, printer, speaker, CD-writer, or another device that provides output from the computing system 3000.

[0325] The communication connection(s) 3070 enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, audio or video input or output, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media can use electrical, optical, RF, or other carriers.

[0326] Innovations can be described in the general context of computer- executable instructions, such as those included in program modules, being executed on a target real or virtual processor in a computing system. Generally, program modules or components include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules can be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules can be executed within the local or distributed computing system.

[0327] The terms "system" and "device" are used interchangeably herein. Unless the context clearly indicates otherwise, neither term implies any limitation on the types of computing systems or computing devices. In general, a computing system or computing device can be local or distributed, and can include special-purpose hardware and / or general-purpose hardware in combination with software implementing the functionality described herein.

[0328] In various examples described herein, a module (e.g., component or engine) can be“coded” to perform certain operations or provide certain functionality, indicating that computer-executable instructions of the executable module can perform, cause to be performed, or otherwise provide such operations or functionality. Although the functionality described with respect to software components, modules, or engines can be implemented as discrete software units (e.g., programs, functions, class methods), it need not be implemented as discrete units. That is, the functionality can be incorporated into a larger or more general program, such as one or more lines of code in a larger or general program.

[0329] To facilitate explanation, detailed descriptions use terms like“determine” and“use” to describe computer operations in a computing system. These terms are high-level abstractions of the actual computer operations performed, and should not be construed to have special functionality as humans do. The actual computer operations corresponding to these terms vary depending on implementation.

[0330] Example 21 Cloud Computing Environment

[0331] Figure 31 An example cloud computing environment 3100 in which described technologies can be implemented is depicted. Cloud computing environment 3100 includes cloud computing services 3110. Cloud computing services 3110 can include various types of cloud computing resources, such as computer servers, data storage repositories, network resources, and the like. Cloud computing services 3110 can 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 at different locations, such as different data centers, and / or located at different cities or countries).

[0332] Cloud computing services 3110 are 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., tablet computers or smartphones), or other types of computing devices. For example, computing devices (e.g., 3120, 3122, and 3124) can utilize cloud computing services 3110 to perform computing operations (e.g., data processing, data storage, and the like).

[0333] Example 22 Implementation

[0334] Although the operations of some of the disclosed methods are described in particular orders, unless otherwise specifically stated, the described ordering is not required and thus, the described ordering should not be construed as a limitation unless specifically stated otherwise. For example, some of the operations described can be rearranged or performed concurrently, or in different orders, unless otherwise specifically stated. Furthermore, some of the disclosed methods can be implemented by a computer program product that is stored in a computer-readable storage medium (e.g., any available non-transitory computer-readable storage medium) that is executed by a computing device (e.g., any available computing device, including a smartphone or other mobile device that includes computing hardware).

[0335] Any of the disclosed methods can be implemented as computer-executable instructions or a computer program product stored on one or more computer-readable storage media (such as a tangible, non-transitory computer-readable storage medium) and executed on a computing device (e.g., any available computing device, including a smartphone or other mobile device that includes computing hardware). Tangible computer-readable storage media are computer-readable storage media having a physical form that is readable by a computing device. Examples of tangible computer-readable storage media include one or more optical media discs, such as DVD or CD, a volatile memory component (such as DRAM or SRAM), or a non-volatile memory component (such as flash memory or hard drives). By way of example, and not limitation, computer-readable storage media include memory 3020 and 3025 and storage 3040. The computer-readable storage media does not include carrier waves and signals. Figure 30

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

[0337] ​For clarity, only certain selected aspects of the software-based implementations are described. Other details that are well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any specific computer language or program. For instance, the disclosed technology 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 combinations of suitable programming languages and markup languages. Likewise, the disclosed technology is not

[0338] Moreover, any software-based embodiments (including, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.

[0339] The disclosed methods, apparatus, and systems should not be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and subcombinations with each other. The disclosed methods, apparatus, and systems are not limited to any specific aspect or feature or combination of aspects and features, nor do the disclosed embodiments require the presence of any particular described aspects or features, or combinations thereof.

[0340] The technology from any example can be combined with the technology described in any one or more of the other examples. In view of the principles underlying the disclosed technology, it will be recognized that the illustrated embodiments are examples of the disclosed technology and should not be considered to be limiting of the scope of the disclosed technology. Rather, the scope of the disclosed technology includes what can be covered by the scope and spirit of the following claims.

Claims

1. A computing system comprising: at least one hardware processor; at least one memory coupled to the at least one hardware processor; and one or more computer-readable storage media storing computer-executable instructions that, when executed, cause the computing system to perform operations comprising: receiving, from a target system, a request for at least a portion of metadata in a metadata repository, the request including information sufficient to identify one or more database artifacts, wherein a respective database artifact of the one or more database artifacts includes a respective standard definition, and wherein the respective standard definition of the respective database artifact includes a first set of one or more first metadata elements of the respective database artifact; identifying one or more software objects that include a metadata extension for the one or more database artifacts, the metadata extension including a second set of one or more second metadata elements that add and / or change and / or remove data or metadata of a corresponding database artifact of the one or more database artifacts without modifying the one or more first metadata elements in the first set of the one or more first metadata elements of the corresponding database artifact; and in response to the request, returning, to the target system, at least a portion of the metadata elements of the metadata extension, wherein when a given database artifact of the one or more database artifacts is instantiated on the target system, the instantiation uses a database artifact definition obtained by merging the one or more first metadata elements in the respective standard definition of the given database artifact with the one or more second metadata elements in the metadata extension for the given database artifact. Identifying the one or more software objects is constrained by a range definition function.

2. The computing system of claim 1, wherein, The operations further comprise:

3. The computing system of claim 1, wherein, integrating the metadata elements of the metadata extension with base metadata associated with the respective standard definitions of the one or more database artifacts; and in response to the request, returning, to the target system, at least a portion of the base metadata. The request is an update request, and the operations further comprise:

4. The computing system of claim 1, wherein, determining whether metadata elements of a database artifact of the one or more database artifacts have been added, deleted, or modified compared to metadata elements of the database artifact that were previously sent to the target system. Returning the metadata elements that have been modified or added.

5. The computing system of claim 4, wherein, 6. The computing system of claim 1, the operations further comprising: integrating multiple versions of metadata for a given database artifact. The integrating includes applying one or more precedence rules.

7. The computing system of claim 6, wherein, A precedence rule specifies using a later version of a metadata element in place of an earlier version of the metadata element.

8. The computing system of claim 7, wherein, A precedence rule specifies adding a later set of one or more values of a metadata element to an earlier set of one or more values of the metadata element.

9. The computing system of claim 7, wherein, 10. The computing system of claim 1, the operations further comprising: determining a plurality of APIs for accessing metadata of the one or more database artifacts; converting the plurality of APIs to a standardized exchange format and saving the plurality of APIs in the standardized exchange format in a catalog. ​ 11. The computing system of claim 10, wherein, The plurality of APIs of the standardized exchange format are used to provide information about database artifacts associated with the plurality of APIs, but data or metadata of database artifacts is retrieved using an API of the plurality of APIs associated with a corresponding API of the standardized exchange format.

12. The computing system of claim 10, further comprising exposing a plurality of APIs of the standardized exchange format to another computing system.

13. The computing system of claim 10, wherein, An API of the standardized exchange format includes a reference to a corresponding API used to create the API of the standardized exchange format, and a reference to metadata associated with a corresponding database artifact.

14. The computing system of claim 1, wherein, Determining the set of one or more database artifacts includes analyzing foreign key relationships or associations.

15. The computing system of claim 1, the operations further comprising: converting at least a portion of the first metadata elements in the first set or at least a portion of the second metadata elements in the second set from a first format to a standardized format, wherein returning at least a portion of the metadata extension of metadata elements to the target system includes returning at least a portion of the metadata elements in the standardized format.

16. One or more computer-readable storage media comprising: computer-executable instructions that, when executed by a computing system comprising at least one hardware processor and at least one memory coupled to the at least one hardware processor, cause the computing system to receive, from a target system, a request for at least a portion of metadata in a metadata repository, the request comprising information sufficient to identify one or more database artifacts, wherein respective database artifacts of the one or more database artifacts comprise respective standard definitions, and wherein the respective standard definition of a respective database artifact comprises a first set of one or more first metadata elements of the respective database artifact; computer-executable instructions that, when executed by the computing system, cause the computing system to identify one or more software objects comprising a metadata extension of the one or more database artifacts, the metadata extension comprising a second set of one or more second metadata elements that add and / or change and / or remove data or metadata of a corresponding database artifact of the one or more database artifacts without modifying the first set of one or more first metadata elements of the corresponding database artifact; and computer-executable instructions that, when executed by the computing system, cause the computing system to return, to the target system in response to the request, at least a portion of the metadata extension of metadata elements, wherein when a given database artifact of the one or more database artifacts is instantiated on the target system, the instantiation uses a database artifact definition obtained by merging the one or more first metadata elements in the respective standard definition of the given database artifact with the one or more second metadata elements in the metadata extension of the given database artifact.

17. A method implemented by a first computing system comprising at least one hardware processor and at least one memory coupled to the at least one hardware processor, the method comprising: storing a standard definition of a database artifact, wherein the standard definition of the database artifact comprises a first set of one or more first metadata elements of the database artifact; sending, to a second computing system, a request for a second set of one or more second metadata elements of one or more metadata extensions of the database artifact, wherein the one or more second metadata elements in the second set add and / or change and / or remove data or metadata of the database artifact without modifying the one or more first metadata elements in the first set; receiving, from the second computing system, the second set of one or more second metadata elements; and instantiating the database artifact according to the first set of one or more first metadata elements and the second set of one or more second metadata elements or updating an existing instance of the database artifact according to the second set of one or more second metadata elements.

18. The method of claim 17, further comprising: sending, to the second computing system, a request for a standard definition of the database artifact.

19. The method of claim 17, wherein, receiving, from the second computing system, the second set of one or more second metadata elements comprises receiving a definition of the database artifact created by merging the standard definition with a metadata extension of one or more metadata extensions.

20. The method of claim 18, wherein, instantiating the database artifact or updating the existing instance of the database artifact comprises merging first metadata elements in the first set and second metadata elements in the second set.

Images