Patent Description:
This application refers to generating software artifacts from a conceptual data model.

Organizations may employ data models that represent information used within the organization's technical systems. The data model serves as an abstraction that allows organizations to better manage, control, and organize data, improve and enhance communications between systems, and create better documentation. Organizations may construct and express these data models using entity-relationship diagrams, XML schemas, or other suitable constructs that define the architecture while decoupling the representation from any particular physical storage implementation or solution. These data models may serve as a valuable reference for engineers within the organization and moreover, may be deployed, harnessed, and leveraged in a variety of programmatic contexts serving varied use cases.

<CIT> provides an integrated provisioning framework that automates the process of provisioning storage resources, end-to-end, for an enterprise storage cloud environment. Such embodiments configure and orchestrate the deployment of a user's workload and, at the same time, provide optimization across a multitude of storage cloud resources. The end-to end provisioning of storage clouds is based on set of models and workload requirements. <CIT> relates to generating implementation artefacts for contextually-aware business applications. <CIT> discloses querying a virtual unified database model across multiple platforms. <NPL> describes a model-driven management of multi-cloud applications.

Specific embodiments are defined in the dependent claims.

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the arts to make and use the embodiments.

Provided herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for generating software artifacts operable across diverse platforms from a single conceptual data model.

A conceptual data model may represent data used in an organization's technical landscape. Such a technical landscape may include various software applications, systems, and tools that harness, incorporate, and depend upon various types of data. The software applications may run on different platforms and be hosted in different environments, and the data used by the software applications housed in differing data stores (e.g., databases, data lakes, text files, etc.). A conceptual data model may catalogue and map data across these data sources in a centralized location. An organization may create such a conceptual data model using a suitable data modeling technique, interface, or tool, and one skilled in the relevant art(s) will appreciate that a wide-array of techniques exist generally to create data models.

An organization may house, store, and access data in, on, and/or across one or more cloud-service platforms. These platforms may offer varied functionalities and disparate storage mechanisms for housing an organization's data. Such platforms may have strengths and weaknesses compared to other platforms, and thus, different platforms may be better suited for a particular data-driven application used by an organization. Thus, an organization may employ multiple cloud-service platforms across its technical landscape. An organization may also house data and run applications on internally managed servers, e.g., in data centers, hosting facilities, in offices, etc., which may also be referred to as a platform in the below disclosure.

Platforms may accommodate varied storage mechanisms. For instance, some platforms may offer/include relational databases, graph databases, columnar databases, in-memory databases, NoSQL databases, key-value stores, data lakes, or other suitable storage mechanisms to store data. Moreover, multiple solutions, products, approaches, etc. may be offered to satisfy or provide these storage mechanisms. For example, an organization may be able to choose between particular relational databases on a particular platform.

An organization may create a conceptual data model describing applications and data across these platforms and data storage mechanisms. The abstraction provided by a conceptual data model offers several practical benefits. For example, a conceptual data model may serve as a reference for engineers within an organization. Organizations may also employ a conceptual data model, once developed, in a variety of programmatic contexts and use cases. For example, an organization may create, deploy, and maintain physical entities (e.g., actual tables, files, etc.), logical data models, and physical data models using the conceptual data model. An organization may create software artifacts, e.g., data definition language (DDL) scripts and data manipulation language (DML) scripts, to instantiate, create, and maintain these entities across the data landscape.

However, when an organization leverages multiple platforms, each platform may have unique requirements and protocols that the software artifacts must adhere to. The organization may need to develop a massive amount of software artifacts to cover every integrated platform and every storage mechanism used in those platforms. Moreover, when the conceptual data model changes in any fashion, which may happen frequently (e.g., during a software update that adds a new field), the organization may have to manually modify and update existing software artifacts and redeploy all of the software artifacts across every platform. For organizations using many platforms and storage mechanisms, the creation and maintenance of software artifacts may be extremely burdensome. No legacy data modeling technique or system provides a solution to ease this burden.

Accordingly, a need exists to harness a single conceptual data model that spurs the generation of multiple logical data models across diverse platforms to facilitate the creation of software artifacts operable across all integrated platforms and data stores. By generating the full gamut of software artifacts needed to instantiate and maintain a data landscape across all integrated platforms from a single conceptual data model, organizations may better manage their data landscape from a centralized location, automate the release software updates to integrated software applications, and ultimately save time, money, and resources.

<FIG> is a block diagram of environment <NUM> including a conceptual data model, according to some embodiments. Any operation herein may be performed by any type of structure in the diagram, such as a module or dedicated device, in hardware, software, or any combination thereof. Environment <NUM> may include conceptual data model <NUM>, data model dictionary <NUM>, data model diagram <NUM>, first metadata <NUM>, platforms <NUM>, logical data models <NUM>, second metadata <NUM>, physical data models <NUM>, deployment tools <NUM>, installation scripts <NUM>, population scripts <NUM>, and documentation <NUM>.

Conceptual data model <NUM> may be a data model depicting a data landscape. Conceptual data model <NUM> may represent data used by software applications or otherwise stored across platforms employed by an organization. Conceptual data model <NUM> may represent the organization's data without reference to physical devices, architectural specifics, implementation details, storage particularities, etc. and is thus a logical representation of the data entities. An organization may create conceptual data model <NUM> using any suitable data modeling technique or tool, e.g., an XML document, modeling language, or suitable design tool. Conceptual data model <NUM> may facilitate the creation of software artifacts, e.g., installation scripts <NUM>, population scripts <NUM>, and documentation <NUM>, across platforms <NUM> and different storage mechanisms offered therein. By maintaining only conceptual data model <NUM>, an organization may avoid maintaining a logical data model unique to each platform, physical data models unique to each storage mechanism integrated within the organization's technical landscape, and, as described in further detail below, software artifacts to manage the data landscape. Conceptual data model <NUM> includes data model dictionary <NUM>, data model diagram <NUM>, and first metadata <NUM>.

Data model dictionary <NUM> may be a textual or other suitable syntactic description of data entities existing within an organization's technical systems. Such entities include database tables, documents, files, data lakes, etc. Data model dictionary <NUM> may include entity names, data types, field width or size, ordering, relationships between the entities, and other suitable information describing the physical attributes of a data entity or element. In some embodiments, data model dictionary <NUM> may be an ASCII text file, an XML file, or other suitable textual definition file. Data model dictionary <NUM> may be created and maintained using a suitable data modeling tool, composer, toolkit, etc. In an embodiment, data model dictionary <NUM> may be derived from information in an entity-relationship diagram (ERD) or other visual representation or through other suitable advanced data modeling techniques.

Data model diagram <NUM> may be an ERD or other graphical representation of data used in an organization's technical systems. Data model diagram <NUM> may compliment or supplement data model dictionary <NUM> or provide redundant information in a graphical form. Thus, data model diagram <NUM> may provide an alternative mechanism by which to specify entities and relationships between the entities across the data landscape. Data model diagram <NUM> may specify relationships between entities using arrows, lines, or other suitable indicator. For example, in a relational database system, the relationship between entities may be a reference constraint between a field in one database table and a field in a second database table, and data model diagram <NUM> may display these tables as boxes, the fields within the table as boxes within the boxes, and connect these boxes with a line or arrow to indicate the relationship. In an embodiment, data model diagram <NUM> may be derived from the information in data model dictionary <NUM>. However, in other embodiments, the reverse may be true, and data model dictionary <NUM> may be derived from data model diagram <NUM>.

First metadata <NUM> may be information incorporated, included, or added in conceptual data model <NUM>. First metadata <NUM> may describe techniques for deploying entities across platforms <NUM>. First metadata <NUM> may contain information about storage mechanisms and data stores available on platforms <NUM>. First metadata <NUM> includes information about various platforms' particular access requirements and protocols. For example, authentication protocols may differ between a first platform and a second platform, and first metadata <NUM> may reflect these differences and include information about how to adhere to each of the protocols. Additional details about particular storage mechanisms available in each platform may be included in first metadata <NUM>. For example, different relational database systems may have different indexing requirements and capabilities, e.g., a particular relational database system may offer different indexing capabilities than a second relational database system, and the syntactic requirements for instantiating, changing, deleting or refreshing an index may differ between products. Thus, to perform certain behaviors, syntactical requirements across storage mechanisms may differ and an indication of the appropriate protocols is included in first metadata <NUM>. For example, first metadata <NUM> may describe partitioning requirements unique to a platform in platforms <NUM> or a data storage mechanism employed therein. First metadata <NUM> thus enables the auto-creation of logical data models representing conceptual model <NUM> across each platform in platforms <NUM> (as described below). These logical data models in turn facilitate the creation of software artifacts operable across every integrated platform.

Platforms <NUM>, such as platform 120A and platform 120B, may be one or more cloud-service platforms or other suitable hosting architecture, infrastructure, or system. Platform 120A may differ from platform 120B in a variety of respects and may offer different services, functionalities, data stores, etc. For example, some platforms <NUM> may offer storage mechanisms, e.g., relational databases, graph databases, columnar databases, in-memory databases, NoSQL databases, key-value stores, data lakes, or other suitable storage mechanisms. Multiple approaches (i.e., particular products or services) may be offered among these individual storage mechanisms, for example, a platform may offer more than one data-lake solution. In an embodiment, platforms <NUM> may also be internally managed web servers, databases, and other web components or other internally managed resources outside of the context of a vendor-managed cloud-service platform.

Logical data models <NUM>, such as logical data model 130A and logical data model 130B, may be data models depicting a platform-specific data landscape. Logical data models <NUM> may represent entities, relationships between the entities, entity types, identifiers, and other suitable entity characteristics. While specific to a particular platform in an organization's technical landscape, logical data models <NUM> may be decoupled from particular physical storage mechanisms, products, approaches, or architectures and associated operational and deployment details. Thus, logical data models may represent the organization's data architecture using storage- and implementation-independent means. Logical data models <NUM> may be derived from conceptual data model <NUM> for each of platforms <NUM>. Logical data models <NUM> may provide the capability to derive platform-specific and storage-specific software artifacts via second metadata <NUM>, described in further detail below.

Second metadata <NUM> may be information incorporated, included, or added in logical data models <NUM> describing techniques for deploying entities on a platform and onto a particular data storage mechanism within platforms <NUM>. Second metadata <NUM> may describe data stores employed by an organization with a platform among platforms <NUM>. Second metadata <NUM> may list the scope of data stores employed on that platform used to determine a number of software artifacts to be generated, as described in further detail below. Second metadata <NUM> further indicate particularized requirements or protocols mandated by a data storage mechanism within a platform among platforms <NUM>. For example, a first platform housing a relational database may require particularized syntax for the creation of a table in the relational database, and this may differ from the particularized syntax for the creation of a table in a second type of relational database on the platform. Second metadata <NUM> stores the information needed to create software artifacts readily deployable in a particular platform and storage mechanism, as described in further detail below.

Physical data models <NUM> may be a storage-mechanism-specific model that represents objects in a particular data storage system on a particular platform. For instance, physical data models <NUM> may represent tables, columns, primary keys, and foreign keys in a relational database. However, physical data models <NUM> may reflect other data storage systems such as graph databases, columnar databases, in-memory databases, NoSQL databases, key-value stores, data lakes, etc. Moreover, multiple solutions may be offered among these varied storage mechanisms. Additionally, physical data models <NUM> may be tailored to a particular product among these varied storage mechanisms. For example, physical data models <NUM> representing relational data objects in a first type of relational database may appear different than physical data models <NUM> representing relational data objects in a second type of relational database. Physical data models <NUM> may be harnessed to generate various software artifacts such as installation scripts 152A and population scripts 154A.

Deployment tools <NUM> may be software artifacts that instantiate, deploy, and maintain entities (e.g., tables, files, documents, structures, etc.) across data stores on platforms <NUM>. Deployment tools <NUM> may be DDL scripts, DML scripts, developer documentation, mapping files, and other suitable programmatic constructs that can create and update the physical entities across platforms <NUM>. Deployment tools <NUM> may include installation scripts 152A, population scripts 154A, documentation <NUM>, and other suitable constructs. Deployment tools <NUM> may be harnessed by deployment agent <NUM>, described in further detail below, to initialize the entities across platforms <NUM> and to modify software artifacts and update the entities upon a change to conceptual data model <NUM>.

Installation scripts <NUM> are database initialization scripts provided in DDL or other suitable syntax capable of defining data structures. Initialization scripts <NUM> are used to deploy, initialize, rollout, or otherwise implement physical elements related to conceptual data model <NUM>. Installation scripts <NUM> may vary based on the target storage mechanism, i.e., a graph database script may differ substantially from a key-value store script. For example, initialization scripts <NUM> may be built automatically to implement Sales Order, Account, and Locale tables on a customer-relationship-management (CRM) platform through the creation of DDL syntax, e.g., "CREATE TABLE," "ALTER TABLE", etc. Platforms <NUM> may require unique protocols and syntax as captured in first metadata <NUM> and second metadata <NUM>, and the created installation scripts <NUM> may adhere to these requirements. Installation scripts <NUM> may further include scripts in DML or other suitable syntax capable of accessing, modifying, and retrieving data from existing data structures. For example, installation scripts <NUM> may be built automatically to make changes to the previously deployed Sales Order, Account, and Locale tables through the creation and execution of DML syntax, e.g., "UPDATE," "INSERT INTO TABLE", etc..

Population scripts <NUM> may be text files, documents, scripts, and other suitable tools that are created to add data that is nominal, dummy, contrived, test, etc. to entities created using installation scripts <NUM>. In one example, population scripts <NUM> may include rows of information to be processed by a script in installation scripts <NUM> to auto-populate relational database tables with information. For example, an entity may exist in conceptual data model <NUM> describing a "Customer" table containing numerous columns/fields describing the customer, e.g., "Name," "Address," "Phone Number," etc. In such an example, population scripts <NUM> may contain a row of "XXXXX" "<NUM> Maple Ave. ", "<NUM>-<NUM>-<NUM>", etc. which may be used to add a row to the table via an "INSERT" table. Such a need may be enhanced where the storage mechanism is not a relational database table, e.g., where the storage mechanism is a graph database and the actual entity is not created in any sense until the data is populated. Population scripts <NUM> may be created by employing a heuristic method with knowledge about the entities, e.g., the entity name, described in conceptual data model <NUM>. In the above "Customer" table example, first metadata <NUM> may contain additional descriptors of the characteristics of the entity known to data modeling tool <NUM>.

Documentation <NUM> may provide descriptions about entities defined in conceptual data model <NUM>. Documentation <NUM> may take any suitable readable format, e.g., HTML, text, word documents, or other suitable human-readable. In an embodiment, documentation <NUM> may include images, tables, graphs, ERDs, and other non-textual information to enhance the readability of the information. Documentation <NUM> may be automatically generated for each platform in platforms <NUM> based on conceptual data model <NUM>, i.e., the documentation may differ between platforms <NUM>. Documentation <NUM> may be provided to documentation interface <NUM>, which may serve the information to developers and other users inside or outside of an organization, e.g., using HTTP or other web infrastructure.

<FIG> is a block diagram of architecture <NUM> including a data modeling tool, according to some embodiments. Any operation herein may be performed by any type of structure in the diagram, such as a module or dedicated device, in hardware, software, or any combination thereof. Architecture <NUM> may include data modeling tool <NUM>, query agent <NUM>, documentation interface <NUM>, data exchange system <NUM>, and deployment agent.

Data modeling tool <NUM> may be used by a representative of an organization to create conceptual data model <NUM> and/or to include first metadata <NUM> in conceptual data model <NUM> and/or second metadata <NUM> in logical data models <NUM>. Data modeling tool <NUM> may allow an administrator to identify platforms <NUM> used throughout the organization's data landscape and data storage mechanisms employed by those platforms. After pre-selecting platforms <NUM> and the data storage mechanisms, data modeling tool <NUM> may allow a user to tailor conceptual data model <NUM> towards these platforms and storage mechanisms. Data modeling tool <NUM> may interact with platforms <NUM> via an appropriate application programming interface (API) to attain appropriate information about the storage mechanisms employed by platforms <NUM> when compiling first metadata <NUM> and/or second metadata <NUM>. Data modeling tool <NUM> may further interact with query agent <NUM>, documentation interface <NUM>, data exchange system <NUM>, and deployment agent <NUM> to derive additional functionalities using conceptual data model <NUM>, as described in further detail below.

Query agent <NUM> may interact with data modeling tool <NUM> to process federated queries run against multiple data sources in an organization's data architecture. A federated query may be a query, e.g., using SQL or other querying language, that gathers data from across multiple platforms <NUM> in a data landscape. Query agent <NUM> may use conceptual data model <NUM> to process a federated query received from an administrator, developer, or other user at an organization. In an embodiment, query agent <NUM> may provide an interface to users to enter a query and/or browse the data landscape indicated in conceptual data model <NUM>. In an embodiment, data modeling tool <NUM> may expose conceptual data model <NUM> to query agent <NUM> in a suitable manner, and query agent <NUM> may process federated queries based on the information contained therein. In another embodiment, data modeling tool <NUM> may provide a querying interface and receive the query from the user of data modeling tool <NUM>. In this embodiment, data modeling tool <NUM> may then engage query agent <NUM> to process the received query, access the various storage mechanisms through appropriate protocols, and return appropriate data records. In this embodiment, data modeling tool <NUM> may display the results of the federated query for a user.

Documentation interface <NUM> may provide developer documentation, such as documentation <NUM>, in the form of HTML pages, help manuals, text, documents, etc. to members of the organization and other users. Documentation interface <NUM> may receive documentation <NUM> automatically created by data modeling tool <NUM> based on created logical data models <NUM> and second metadata <NUM> contained therein. Documentation interface <NUM> may provide documentation <NUM> to interested parties using web servers, HTTP, or other appropriate web technologies. In an embodiment, documentation interface <NUM> may impose access restrictions in the form of security requirements, e.g., by requiring a login and password to limit the access to documentation <NUM> to authorized individuals and groups. In an embodiment, documentation interface <NUM> may receive conceptual data model <NUM> from data modeling tool <NUM>, store documentation <NUM>, and provide documentation <NUM> via a suitable web interface. In another embodiment, data modeling tool <NUM> may engage documentation interface <NUM> to provide documentation <NUM> to users within data modeling tool <NUM>.

Data exchange system <NUM> may process mapping files created by data modeling tool <NUM>. Such mapping files may facilitate data transformation and loading between and among data stores across platforms <NUM>. Data exchange system <NUM> may cause the transfer of data from a platform in platforms <NUM>, i.e., the source schema, into a second platform in platforms <NUM>, i.e., the target schema. Data exchange system <NUM> thus allows an organization to streamline extract, transform, and load (ETL) functions based on the information in conceptual data model <NUM>. In an embodiment, a user may perform ETL transactions within data modeling tool <NUM>, i.e., data modeling tool <NUM> may engage data exchange system <NUM> to perform the ETL transactions from within the interface provided by data modeling tool <NUM>.

Deployment agent <NUM> may deploy entities into a physical environment using software artifacts such as deployment tools <NUM> created by data modeling tool <NUM>. In an embodiment, deployment agent <NUM> may operate within or at the bequest of data modeling tool <NUM>. In such an embodiment, a user may design conceptual data model <NUM> within data modeling tool <NUM>, imbue conceptual data model <NUM> with first metadata <NUM> and second metadata <NUM>. Deployment agent <NUM> may receive updated software artifacts based on a change made to conceptual data model <NUM> in data modeling tool <NUM>, and deployment agent <NUM> may update the entities in the physical environments using the updated software artifacts.

<FIG> is a flowchart illustrating method <NUM> of creating software artifacts based on a conceptual data model. Method <NUM> may be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in <FIG>, as will be understood by a person of ordinary skill in the art(s).

In <NUM>, data modeling tool <NUM> creates or otherwise facilitates the creation of conceptual data model <NUM> by an administrator, data architect, or other user. In an embodiment, data modeling tool <NUM> may allow the user to import an externally created data model and derive conceptual data model <NUM> from the received data model, e.g., receive data model dictionary <NUM>, data model diagram <NUM>, and/or other suitable descriptors of conceptual data model <NUM> created in external tools and uploaded to data modeling tool <NUM>. When storing conceptual data model <NUM>, data modeling tool <NUM> includes or incorporates first metadata <NUM> within conceptual data model <NUM> based on stored logic about platforms <NUM> and storage mechanisms therein. In an embodiment, data modeling tool <NUM> may allow a user to select a platform or platforms from platforms <NUM> and update conceptual data model <NUM> based on the selected platforms. Data modeling tool <NUM> may add first metadata <NUM> that includes deployment information specific to each platform in platforms <NUM>. First metadata <NUM> include authentication protocol information specific to platforms <NUM> and/or other information specifying the nature of interactions to occur between data modeling tool <NUM> and platforms <NUM>, e.g., parameters needed to execute software artifacts on or within the platform. First metadata <NUM> may further include storage-solution specific information based on internally retrieved logic. For example, relational databases used across platforms may differ (e. SQL SERVER, ORACLE, MYSQL), and first metadata <NUM> may include information specific to a particular storage solution on a particular platform among platforms <NUM>.

In <NUM>, data modeling tool <NUM> creates logical data models <NUM> based on conceptual data model <NUM> and first metadata <NUM> contained therein. Data modeling tool <NUM> may create logical data models <NUM> for each platform in platforms <NUM> employed within an organization's data landscape. Data modeling tool <NUM> may also add second metadata <NUM> to the created logical data models <NUM>. Second metadata <NUM> may include implementation details specific to the platform to which the logical data model corresponds. Second metadata <NUM> may subsequently allow data modeling tool <NUM> to create deployment tools <NUM> by incorporating known information about the protocols adhered to by each platform among platforms <NUM> as well as the protocols, rules, etc. for physical storage models and mechanisms provided by the platform. For example, one exemplary data landscape may include database instances running on two different platforms. In this embodiment, data modeling tool <NUM> may create two logical data models <NUM>, one for each of the platforms. The created logical data models <NUM> may remain storage solution independent, i.e., the logical data models <NUM> may not indicate the exact storage mechanism (e. g, SQL SERVER, ORACLE, etc.), but may define the entities and their relationships in a logical fashion. However, the created logical data models <NUM> may include specific information in second metadata <NUM> required by that specific platform among platforms <NUM> and specific to the storage mechanisms provided within those platforms <NUM>.

In <NUM>, data modeling tool <NUM> creates software artifacts operable across platforms <NUM> based on logical data models <NUM>, first metadata <NUM>, and second metadata <NUM>. The software artifacts include installation scripts <NUM>, population scripts <NUM>, documentation <NUM>, and other suitable deployment tools <NUM>, as will be understood by one skilled in the relevant art(s). Data modeling tool <NUM> may store created software artifacts in a suitable structure, file system, disk, memory, etc. In an embodiment, data modeling tool <NUM> may allow a user to view the created software artifacts and edit or manipulate the created software artifacts in additional fashions prior to deploying entities via the software artifacts. To continue the above example of an application deployment spanning multiple platforms and consisting of relational database technologies, data modeling tool <NUM> may examine logical data models <NUM> created for each platform specified in conceptual data model <NUM>. For each logical data model in logical data models <NUM>, data modeling tool <NUM> may generate appropriate DDL scripts to create the tables, rows, columns, indexes, disk partitions, and other components as specified in conceptual data model <NUM>. Because a first platform in the example may have different requirements for executing a DDL script or different syntactic requirements for creating the actual DDL script than a second platform, the DDL scripts may differ. Data modeling tool <NUM> may adapt to these differences using on first metadata <NUM>. Additionally, conceptual data model <NUM> may specify differing storage mechanisms within the multiple platforms. Thus, the first DDL script and the second DDL script may further differ based on the underlying storage mechanism. Data modeling tool <NUM> may accommodate these differences using the information provided by second metadata <NUM>. In addition to DDL scripts to instantiate the relational database tables, data modeling tool <NUM> may create DML scripts that specify appropriate "UPDATE" or "INSERT" statements to populate the created tables. To appropriately harness these DML scripts, data modeling tool <NUM> may also create population scripts <NUM> to feed the DML scripts to incorporate nominal data in the tables. Especially in the context of graph database, the inclusion of dummy data via population scripts <NUM> is necessary to create the entities. The above example is merely exemplary, however, and one skilled in the arts will appreciate that many more than two platforms may be incorporated within a data landscape as well as a wide-array of storage mechanisms beyond relational databases.

In <NUM>, data modeling tool <NUM> may employ deployment agent <NUM> to instantiate physical entities across platforms <NUM> and across the various storage systems therein using the software artifacts generated in <NUM>. In an embodiment, data modeling tool <NUM> may receive a command to initialize the entities across platforms <NUM> or on a particular platform among platforms <NUM> from a user of data modeling tool <NUM>. In one embodiment, deployment agent <NUM> may instantiate the entities by interacting with appropriate APIs or other interfaces provided by platforms <NUM>. For example, a service provided by a particular platform in the above example may allow an organization to run a query or other SQL command against a back-end database. The requirements and nature of this service may differ between platforms, as captured by first metadata <NUM> and second metadata <NUM>. Deployment agent <NUM> may engage the service using stored parameters and run the software artifacts, in this example, DDL and DML scripts, against the backend-databases and return appropriate results or confirmations in response to the command to create the entities. In another embodiment, data modeling tool <NUM> may provide downloadable versions of the software artifacts to an administrator or user in an exportable fashion. In this embodiment, a user may then execute the software artifacts using tools available on and native to platforms <NUM> and storage facilities therein. For example, the user could receive a DDL script and copy/paste the script into a querying tool provided by a platform among platforms <NUM>.

<FIG> is a flowchart illustrating method <NUM> of generating developer documentation based on a conceptual data model, according to some embodiments. Method <NUM> may be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps may be needed to perform the disclosure provided herein. Further, some of the steps may be performed simultaneously, or in a different order than shown in <FIG>, as will be understood by a person of ordinary skill in the art(s).

In <NUM>, data modeling tool <NUM> may update or facilitate the updating of conceptual data model <NUM> by an administrator, data architect, or other user. In an embodiment, data modeling tool <NUM> may allow such a user to import an externally created data model and determine changes to a previously created version of conceptual data model <NUM> from the imported data model. Data modeling tool <NUM> may complete any needed updates to first metadata <NUM> within conceptual data model <NUM> based on the changes. For example, a user may include an additional application running on a new platform among platforms <NUM> in an updated version of conceptual data model <NUM>. In this example, data modeling tool <NUM> may update first metadata <NUM> to accommodate the new software application, the entities used therein, and the new platform not previously included in the data landscape.

In <NUM>, data modeling tool <NUM> may recreate logical data models <NUM> based on the changed conceptual data model <NUM> and first metadata <NUM> contained therein, as updated in <NUM>. Data modeling tool <NUM> may complete needed updates to logical data models <NUM> across each platform in platforms <NUM>. Data modeling tool <NUM> may also update second metadata <NUM> based on any changes made to conceptual data model <NUM>. To continue the above example, second metadata <NUM> may be updated to include storage-location specific information to accommodate the new application and data stored and used by the application.

Data data modeling tool <NUM> may recreate any software artifacts impacted by the changes to conceptual data model <NUM>. Data modeling tool <NUM> may update installation scripts <NUM>, population scripts <NUM>, documentation <NUM>, and other suitable deployment tools <NUM>, as will be understood by one skilled in the relevant art(s). To continue the above example, the new application, platform, and data entities may mandate the creation of new DDL and DML scripts to instantiate the entities serving the new application. In another example, a change may have been received in <NUM> to add a column to a table in a relational database system. In this example, the previously created software artifacts may be modified to include the change or a new set of scripts may be created to instantiate the delta between the original conceptual data model and the updated conceptual data model.

Data data modeling tool <NUM> may employ deployment agent <NUM> to update the physical entities across platforms <NUM> and across the various storage systems therein using the updated software artifacts. For example, deployment agent <NUM> may engage a service provided by a particular platform to run the software artifacts against the data storage mechanisms in the platform. Deployment agent <NUM> may receive appropriate results or confirmations in response to the updates. In another embodiment, data modeling tool <NUM> may provide downloaded and exportable versions of the updated software artifacts. In this embodiment, the user may then execute the using tools available on and native to platforms <NUM> and storage facilities therein.

In this fashion, a change to conceptual data model <NUM> may be propagated down to all software artifacts derived from conceptual data model <NUM>. Thus, an organization may make document or note a change to its technical landscape in a single, centralized location, i.e., conceptual data model <NUM>. In this example, the organization need not update or maintain all software artifacts across all platforms, storage mechanisms, and applications to accommodate the change in all locations.

Various embodiments may be implemented, for example, using one or more well-known computer systems, such as computer system <NUM> shown in <FIG>. One or more computer systems <NUM> may be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof.

Computer system <NUM> may include one or more processors (also called central processing units, or CPUs), such as a processor <NUM>. Processor <NUM> may be connected to a communication infrastructure or bus <NUM>.

Computer system <NUM> may also include user input/output device(s) <NUM>, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure <NUM> through user input/output interface(s) <NUM>.

One or more of processors <NUM> may be a graphics processing unit (GPU). In an embodiment, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc..

Computer system <NUM> may also include a main or primary memory <NUM>, such as random access memory (RAM). Main memory <NUM> may include one or more levels of cache. Main memory <NUM> may have stored therein control logic (i.e., computer software) and/or data.

Removable storage unit <NUM> may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage drive <NUM> may read from and/or write to removable storage unit <NUM>.

Secondary memory <NUM> may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system <NUM>. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit <NUM> and an interface <NUM>. Examples of the removable storage unit <NUM> and the interface <NUM> may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.

Communication interface <NUM> may enable computer system <NUM> to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number <NUM>). For example, communication interface <NUM> may allow computer system <NUM> to communicate with external or remote devices <NUM> over communications path <NUM>, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system <NUM> via communication path <NUM>.

Computer system <NUM> may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.

Computer system <NUM> may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software ("on-premise" cloud-based solutions); "as a service" models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.

Any applicable data structures, file formats, and schemas in computer system <NUM> may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.

In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system <NUM>, main memory <NUM>, secondary memory <NUM>, and removable storage units <NUM> and <NUM>, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system <NUM>), may cause such data processing devices to operate as described herein.

It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way.

While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible, within the scope of the claims.

Claim 1:
A computer implemented method (<NUM>), comprising:
defining (<NUM>), by one or more processors, a conceptual data model comprising a table , a plurality of platforms, and first metadata comprising platform-specific access requirements for authenticating with each platform in the plurality of platforms and syntactical requirements to create an index on each storage mechanism available in each platform, wherein the platform-specific access requirements indicate authentication protocol information comprising a parameter needed to execute software artifacts in each platform in the plurality of platforms;
creating (<NUM>), by the one or more processors, for each platform in the plurality of platforms, a logical data model comprising second metadata that specifies a particularized syntax to create the table on each storage mechanism available in each platform;
generating (<NUM>), by the one or more processors, for each platform in the plurality of platforms, platform-specific installation scripts and platform-specific data population scripts for each storage mechanism available in each platform based on the second metadata, wherein the platform-specific installation scripts create the table in a database and an index on the table using the second metadata and the first metadata, and wherein the platform-specific data population scripts populate the table with data; and
deploying (<NUM>), by the one or more processors, the table into each platform in the plurality of platforms by engaging a service offered by each platform using the platform-specific access requirements and the parameter to execute the platform-specific installation scripts and the platform-specific data population scripts.