CN112930529A - 从概念数据模型生成软件工件 - Google Patents

Abstract

本文公开了用于从单个概念数据模型生成可跨不同平台操作的软件工件的系统、方法和计算机程序产品实施方式。可以使用元数据增强概念数据模型，元数据允许创建平台特定的逻辑数据模型，其中包括用于创建可部署软件工件的附加元数据。组织可以随后修改概念数据模型，并且可以跨所有集成平台更新和重新部署所有相关软件工件。这种概念数据模型还促进描述组织技术基础设施中数据实体的文档的创建，数据交换系统使用的映射文件的创建，以及从多个数据存储中跨数据环境收集数据的整合查询的处理。

Description

从概念数据模型生成软件工件

相关申请的交叉引用

本申请要求于2019年8月27日提交的标题为GENERATING SOFTWARE ARTIFACTSFROM A CONCEPTUAL DATA MODEL的美国专利申请第16/552,755的优先权，其出于所有目的通过引用并入本文。

背景技术

组织可采用代表组织技术系统中使用的信息的数据模型。数据模型用作抽象概念，该抽象概念允许组织更好地管理、控制和组织数据，改善和增强系统之间的通信并创建更好文档。当将表达与任何特定的物理存储实施或解决方案解耦时，组织可使用实体关系图、XML架构或限定体系结构的其他合适结构来构建和表达这些数据模型。这些数据模型可以用作为组织内工程师提供有价值的参考，并且此外，可以在服务于各种用例的各种编程环境中部署、利用和使用。

附图说明

并入本文并构成说明书的一部分的附图，示出了本公开的实施方式。并且与说明书一起用来进一步解释本公开的原理，使本领域技术人员能够进行和使用实施方式。

图1是根据一些实施方式的包括概念数据模型的环境的框图。

图2是根据一些实施方式的包括数据建模工具的体系结构的框图。

图3示出了根据一些实施方式的基于概念数据模型创建软件工件的方法的流程图。

图4示出了根据一些实施方式的基于概念数据模型生成开发人员文档的方法的流程图。

图5是可用于实施各种实施方式的示例计算机系统。

在附图中，相似的附图标记通常表示相同或相似的元件。另外，通常附图标记的最左边的数字表示该附图标记首次出现。

具体实施方式

本文提供了用于从单个概念数据模型生成可跨不同平台操作的软件工件的系统、装置、设备、方法和/或计算机程序产品实施方式、和/或其组合和子组合。

概念数据模型可表示在组织技术环境中使用的数据。这样的技术环境可以包括利用、结合以及取决于各种类型数据的各种软件应用程序、系统和工具。软件应用程序可以在不同的平台上运行并且可以在不同的环境中托管，并且软件应用程序所使用的数据存储在不同的数据存储中(如数据库、数据湖、文本文件等)。概念数据模型可以在集中的位置跨这些数据源对数据进行分类和映射。组织可以使用合适的数据建模技术、接口或工具来创建这样的概念数据模型，并且本领域的技术人员将理解，通常存在广泛的技术来创建数据模型。

组织可以在一个或多个云服务平台中、上、和/或跨一个或多个云服务平台来容纳、存储和访问数据。这些平台可提供各种功能和不同的存储机制来容纳组织的数据。与其他平台相比，这种平台可能具有优点和缺点，并且因此，不同的平台可能更适合组织所使用的特定数据驱动的应用程序。因此，组织可以跨其技术环境使用多个云服务平台。组织还可以在例如数据中心、托管设施、办公室等内部管理的服务器上，容纳数据并运行应用程序，在下文的公开中，该服务器也可以称为平台。

平台可以容纳各种存储机制。例如，一些平台可以提供/包括关系数据库、图形数据库、柱列数据库、内存数据库、NoSQL数据库、键值存储、数据湖或其他合适的存储机制来存储数据。此外，可以提供多种解决方案、产品、方法等来满足或提供这些存储机制。例如，组织可能能够在特定平台上的特定关系数据库之间进行选择。

组织可以创建描述跨这些平台和数据存储机制的应用程序和数据的概念数据模型。概念数据模型提供的抽象概念提供了多个实际的好处。例如，概念数据模型可以用作组织内工程师的参考。一旦被开发，组织还可以在各种编程环境和用例中使用概念数据模型。例如，组织可以使用概念数据模型来创建、部署和维护物理实体(例如，实际表、文件等)、逻辑数据模型和物理数据模型。组织可以创建软件工件(software artifacts)，例如数据定义语言(DDL)脚本和数据操作语言(DML)脚本，用于跨数据环境实例化、创建和维护这些实体。

然而，当组织利用多个平台时，每个平台可能具有软件工件必须遵守的特有要求和协议。组织可能需要开发大量的软件工件，以覆盖这些平台中使用的每个集成平台和存储机制。此外，当概念数据模型可能频繁地以任何方式更改时(例如在添加新字段的软件更新期间)，组织可能必须手动修改和更新现有的软件工件，并跨每个平台重新部署所有软件工件。对于使用许多平台和存储机制的组织，创建和维护软件工件可能会非常繁重。没有任何旧数据建模技术或系统可以提供减轻这种负担的解决方案。

因此，存在利用单一概念数据模型的需求，该概念数据模型促进了跨不同平台生成多个逻辑数据模型，以促进创建跨所有集成平台和数据存储可操作的软件工件。通过从单个概念数据模型，生成跨所有集成平台实例化和维护数据环境所需的全部软件工件，组织可以更好地从集中位置管理其数据环境，使对集成软件应用程序的发布软件更新自动化，并且最终节省时间、金钱和资源。

图1是根据一些实施方式的包括概念数据模型的环境100的框图。本文中的任何操作可以由图表中的任意类型的结构(诸如模块或专用设备)，以硬件、软件或其任意组合来执行。环境100可包括概念数据模型110、数据模型字典112、数据模型图114、第一元数据116、平台120、逻辑数据模型130、第二元数据132、物理数据模型140、部署工具150、安装脚本152、填充脚本154和文档156。

概念数据模型110可以是描述数据环境的数据模型。概念数据模型110可表示由软件应用程序使用的数据，或者跨组织利用的平台存储的数据。概念数据模型110可表示在没有参考物理设备、体系结构细节、实施细节、存储特性等的情况下组织的数据，并且因此是数据实体的逻辑表示。组织可使用任意合适的数据建模技术或工具(例如XML文档，建模语言或合适的设计工具)创建概念数据模型110。概念数据模型110可促进创建跨平台120和其中提供的不同存储机制的软件工件，例如，安装脚本152、填充脚本154和文档156。通过仅维护概念数据模型110，组织可以避免维护每个平台特有的逻辑数据模型、组织技术环境内集成的每个存储机制特有的物理数据模型、以及下文要详细描述的用于管理数据环境的软件工件。概念数据模型110可包括数据模型字典112、数据模型图114和第一元数据116。

数据模型字典112可以是组织技术系统内存在的数据实体的文本或其他合适的语法描述。这样的实体可包括数据库表、文档、文件、数据湖等。数据模型字典112可包括实体名称、数据类型、字段宽度或尺寸、排序、实体之间的关系以及描述数据实体或元素的物理属性的其他合适的信息。在一些实施方式中，数据模型字典112可以是ASCII文本文件、XML文件或其他合适的文本定义文件。可以使用合适的数据建模工具、编辑器、工具包等，来创建和维护数据模型字典112。在一个实施方式中，可以从实体关系图(ERD)或其他视觉表示中的信息或者通过其他合适的高级数据建模技术，来获得数据模型字典112。

数据模型图114可以是组织的技术系统中使用的数据的ERD或其他图形表示。数据模型图114可补充或完善数据模型字典112，或者以图形形式提供冗余的信息。因此，数据模型图114可提供替代机制，通过该替代机制来指定实体和整个数据环境中实体之间的关系。数据模型图114可使用箭头、线条或其他合适的指示符，来指定实体之间的关系。例如，在关系数据库系统中，实体之间的关系可以是一个数据库表中的字段与第二个数据库表中的字段之间的参考约束，并且数据模型图114可以将这些表显示为框，表中的字段显示为框内的框，并将这些框用线条或箭头连接起来以表示关系。在一个实施方式中，可从数据模型字典112中的信息导出数据模型图114。然而，在其他实施方式中，相反的情况可能是合适的，即可以从数据模型图114导出数据模型字典112。

第一元数据116可以是结合、包括或添加到概念数据模型110中的信息。第一元数据116可描述用于跨平台120部署实体的技术。第一元数据116可包括关于平台120上可用的存储机制和数据存储的信息。例如，第一元数据116可包括关于各个平台的特定访问要求和协议的信息。例如，在第一个平台和第二个平台之间认证协议可能不同，以及第一元数据116可以反映这些不同并且包括关于如何遵守每个协议的信息。关于在每个平台中可用的特定存储机制的附加细节可以包括在第一元数据116中。例如，不同的关系数据库系统可能具有不同的索引要求和能力，例如，特定的关系数据库系统可能提供与第二个关系数据库系统不同的索引能力，并且不同产品之间实例化、更改、删除或刷新索引的语法要求可能不同。因此，为了执行某些行为，跨存储机制的语法要求可能会有所不同，并且适当协议的指示可以包括在第一元数据116中。例如，第一元数据116可描述对于平台120中的一个平台或其中采用的数据存储机制特有的分区要求。因此，第一元数据116使得能够跨平台120中的每个平台自动创建表示概念模型110的逻辑数据模型(如下所述)。这些逻辑数据模型进而有助于创建跨每个集成平台可操作的软件工件。

平台120，例如平台120A和平台120B，可以是一个或多个云服务平台，或其他合适的托管体系结构、基础设施或系统。平台120A可在各个方面与平台120B不同，并且可以提供不同的服务、功能、数据存储等。例如，一些平台120可以提供存储机制，例如关系数据库、图形数据库、柱列数据库、内存数据库、NoSQL数据库、键值存储、数据湖或其他合适的存储机制。在这些单独的存储机制中可以提供多种方法(即特定产品或服务)，例如，一个平台可以提供多个数据湖解决方案。在一个实施方式中，平台120还可以是内部管理的web服务器、数据库以及其他web组件或在供应商管理的云服务平台的上下文之外的其他内部管理的资源。

逻辑数据模型130，例如逻辑数据模型130A和逻辑数据模型130B，可以是描述平台特定的数据环境的数据模型。逻辑数据模型130可表示实体、实体之间的关系、实体类型、标识符和其他合适的实体特征。虽然针对组织技术环境中的特定平台，但逻辑数据模型130可以与特定物理存储机制、产品、方法或体系结构以及相关联的操作和部署细节解耦。因此，逻辑数据模型可使用独立于存储和实施的方法，来表示组织的数据体系结构。对于平台120中的每一个，逻辑数据模型130可从概念数据模型110导出。逻辑数据模型130可以提供经由第二元数据132导出平台特定和存储特定的软件工件的能力，下文将进一步详细描述。

第二元数据132可以是在逻辑数据模型130中结合、包括或添加的信息，逻辑数据模型130描述了用于将实体部署在平台上以及平台120内的特定数据存储机制上的技术。第二元数据132可描述组织在平台120中的一个平台上所使用的数据存储。如下文将进一步详细描述的，第二元数据132可以列出在该平台上采用的用于确定要生成的软件工件数量的数据存储的范围。第二元数据132可进一步表示由平台120中的一个平台内的数据存储机制所授权的特定要求或协议。例如，容纳关系数据库的第一平台可能需要用于在关系数据库中创建表的特定语法，并且这可能不同于用于在平台上的第二类型关系数据库中创建表的特定语法。第二元数据132存储创建可在特定平台和存储机制中易于部署的软件工件所需的信息，如下文进一步详细描述的。

物理数据模型140可以是表示特定平台上的特定数据存储系统中的对象的特定存储机制的模型。例如，物理数据模型140可表示关系数据库中的表、列、主键和外键。然而，物理数据模型140可表明其他数据存储系统，例如图形数据库、柱列数据库、内存数据库、NoSQL数据库、键值存储、数据湖等。此外，在这些不同的存储机制中可以提供多种解决方案。另外，物理数据模型140可以针对这些不同存储机制中的特定产品进行定制。例如，表示第一类型关系数据库中的关系数据对象的物理数据模型140，可能看起来与表示第二类型关系数据库中的关系数据对象的物理数据模型140不同。可以利用物理数据模型140来生成各种软件工件，诸如安装脚本152A和填充脚本154A。

部署工具150可以是跨平台120上的数据存储实例化、部署和维护实体(例如，表、文件、文档、结构等)的软件工件。部署工具150可以是DDL脚本、DML脚本、开发人员文档、映射文件和可在平台120上创建和更新物理实体的其他合适的编程结构。部署工具150可以包括安装脚本152A、填充脚本154A、文档156及其他合适的结构。如下文将进一步详细描述，部署工具150可由部署代理210利用，用于跨平台120初始化实体，并在概念数据模型110更改时修改软件工件和更新实体。

安装脚本152可以是以DDL或能够定义数据结构的其他合适语法提供的数据库初始化脚本。初始化脚本152可用于部署、初始化、展示或以其他方式实施与概念数据模型110相关的物理元素。安装脚本152可以基于目标存储机制而变化，即图形数据库脚本可以与键值存储脚本实质不同。例如，可以通过DDL语法(例如，“创建表(CREATE TABLE)”、“更改表(ALTER TABLE)”等)的创建，自动构建初始化脚本232以在客户关系管理(CRM)平台上实施销售订单、帐户和区域表。平台120可能需要在第一元数据116和第二元数据132中捕获的唯一协议和语法，并且所创建的安装脚本152可能遵循这些要求。安装脚本152还可以包括DML或能够从现有数据结构访问、修改和检索数据的其他合适语法中的脚本。例如，可以通过创建和执行DML语法(例如“更新(UPDATE)”，“插入表(INSERT INTO TABLE)”等)来自动构建安装脚本152，以对先前部署的销售订单、帐户和区域表进行更改。

填充脚本154可以是文本文件、文档、脚本和被创建以向使用安装脚本152创建的实体添加数据的其他合适的工具，该数据是名义的、虚拟的、人为的、测试的数据等。在一个示例中，填充脚本154可包括要由安装脚本152中的脚本处理的信息行，以便用信息自动填充关系数据库表。例如，实体可以存在于描述“客户”表的概念数据模型110中，该“客户”表包含描述客户的许多列/字段，例如，“姓名”、“地址”、“电话号码”等。在这样的示例中，填充脚本154可包含“XXXXX”“55枫树大街”、“555-555-5555”行等，该行可以用来通过“插入(INSERT)”表向表中添加行。在存储机制不是关系数据库表的情况下，例如在存储机制是图形数据库的情况下可以增强这种需求，并且在数据被填充之前无论怎样都不会创建实际实体。填充脚本154可通过使用具有概念数据模型110中描述的关于实体的知识(例如实体名称)的启发式方法来创建。在上述“客户”表的示例中，第一元数据116可包含数据建模工具202已知的实体特征的附加描述符。

文档156可提供关于概念数据模型110中定义的实体的描述。文档156可采用任何合适的可读格式，例如HTML、文本、word文档或其他合适的人类可读格式。在一个实施方式中，文档156可包括图像、表格、图形、ERD和其他非文本信息，以增强信息的可读性。可以基于概念数据模型110，为平台120中的每个平台自动生成文档156，即文档在平台120之间可能不同。可将文档156提供给文档接口206，文档接口206可以使用例如HTTP或其他web基础设施向组织内外的开发人员和其他用户提供信息。

图2是根据一些实施方式的包括数据建模工具的体系结构200的框图。本文中的任何操作可以由图中的任意类型的结构(例如模块或专用设备)以硬件、软件或其任意组合执行。体系结构200可以包括数据建模工具202、查询代理204、文档接口206、数据交换系统208和部署代理210。

数据建模工具202可由组织的代表用于创建概念数据模型110,和/或包括概念数据模型110中的第一元数据116,和/或包括逻辑数据模型130中的第二元数据132。数据建模工具202可允许管理员识别在整个组织的数据环境中使用的平台120以及这些平台所采用的数据存储机制。在预选择平台120和数据存储机制之后，数据建模工具202可允许用户针对这些平台和存储机制定制概念数据模型110。数据建模工具202可经由适当的应用程序接口(API)与平台120交互，以获得关于平台120在编译第一元数据116和/或第二元数据132时所采用的存储机制的合适信息。如下文进一步详细描述的,数据建模工具202可进一步与查询代理204、文档接口206、数据交换系统208和部署代理210交互，以使用概念数据模型110导出附加功能。

查询代理204可以与数据建模工具202交互以处理针对组织的数据体系结构中的多个数据源运行的整合查询。整合查询可以是例如使用SQL或其他查询语言的查询，其在数据环境中跨多个平台120收集数据。查询代理204可以使用概念数据模型110来处理从组织的管理员、开发人员或其他用户接收的整合查询。在一个实施方式中，查询代理204可以向用户提供接口，以输入查询和/或浏览概念数据模型110中指示的数据环境。在一个实施方式中，数据建模工具202可以以适当的方式向查询代理204公开概念数据模型110，并且查询代理204可以基于其中包含的信息来处理整合查询。在另一实施方式中，数据建模工具202可以提供查询接口并从数据建模工具202的用户接收查询。在本实施方式中，之后数据建模工具202可以使查询代理204处理所接收的查询，通过合适的协议访问各种存储机制，并返回合适的数据记录。在本实施方式中，数据建模工具202可以为用户显示整合查询的结果。

文档接口206可以以HTML页面、帮助手册、文本、文档等形式向组织的成员和其他用户提供开发人员文档，例如文档156。文档接口206可以接收由数据建模工具202基于创建的逻辑数据模型130和其中包含的第二元数据132自动创建的文档156。文档接口206可以使用web服务器、HTTP或其他合适的web技术向感兴趣的各方提供文档156。在一个实施方式中，文档接口206可以以安全要求的形式施加访问限制，例如通过要求登录名和密码以将对文档156的访问限制到授权的个人和团组。在一个实施方式中，文档接口206可以从数据建模工具202接收概念数据模型110、存储文档156，并经由适当的web接口提供文档156。在另一实施方式中，数据建模工具202可以促使文档接口206向数据建模工具202的用户提供文档156。

数据交换系统208可处理由数据建模工具202创建的映射文件。这种映射文件可以促进跨平台120的数据存储之间的数据转换和加载。数据交换系统208可导致将数据从平台120中的一个平台(即源模式)传输到平台120中的第二个平台(即目标模式)。因此，数据交换系统208允许组织基于概念数据模型110中的信息简化提取、转换和加载(ETL)功能。在一个实施方式中，用户可以在数据建模工具202内执行ETL事务，即数据建模工具202可以使数据交换系统208从数据建模工具202提供的接口内执行ETL事务。

部署代理210可以使用诸如由数据建模工具202创建的部署工具150的软件工件，将实体部署到物理环境中。在一个实施方式中，部署代理210可在数据建模工具202内或在其附属处操作。在这样的实施方式中，用户可以在数据建模工具202内设计概念数据模型110，向概念数据模型110嵌入第一元数据116和第二元数据132。部署代理210可以基于对数据建模工具202中的概念数据模型110所做的更改，来接收更新的软件工件，并且部署代理210可以使用更新的软件工件来更新物理环境中的实体。

图3示出了基于概念数据模型创建软件工件的方法300的流程图。方法300可以通过处理逻辑来执行，处理逻辑可包括硬件(例如电路、专用逻辑、可编程逻辑、微码等)、软件(例如在处理设备上执行的指令)或其组合。应当理解的是，可能无需执行本公开提供的所有步骤。此外，如本领域普通技术人员理解的，可以同时执行一些步骤，或者以与图3所示不同的顺序执行。

在302中，数据建模工具202可创建概念数据模型110，或以其他方式促进由管理员、数据架构师或其他用户对概念数据模型110的创建。在一个实施方式中，数据建模工具202可允许用户导入外部创建的数据模型，并从接收的数据模型(例如接收数据模型字典112、数据模型图114，和/或在外部工具中创建并上传到数据建模工具202的概念数据模型110的其他合适描述符)导出概念数据模型110。当存储概念数据模型110时，数据建模工具202可以基于关于平台120所存储的逻辑和其中的存储机制，在概念数据模型110内包括或并入第一元数据116。在一个实施方式中，数据建模工具202可允许用户从平台120中选择一个或多个平台，并基于所选平台更新概念数据模型110。数据建模工具202可以添加第一元数据116，第一元数据116包括特定于平台120中的每个平台的部署信息。第一元数据116可包括特定于平台120的认证协议信息，和/或指定数据建模工具202和平台120之间发生的交互的性质的其他信息，例如，在平台上或平台内执行软件工件所需要的参数。第一元数据116还可包括基于内部检索逻辑的存储解决方案的特定信息。例如，跨平台使用的关系数据库可能会有所不同(例如，SQL SERVER、ORACLE、MYSQL)，并且第一元数据116可包括特定于平台120中的具体平台上的具体存储解决方案的信息。

在304中，数据建模工具202可以基于概念数据模型110和其中包含的第一元数据116，来创建逻辑数据模型130。数据建模工具202可为组织的数据环境中使用的平台120中的每个平台创建逻辑数据模型130。数据建模工具202还可向所创建的逻辑数据模型130添加第二元数据132。第二元数据132可包括特定于逻辑数据模型所对应的平台的实施细节。随后第二元数据132可允许数据建模工具202通过结合关于平台120之间的每个平台所遵循的协议的已知信息、以及关于平台所提供的物理存储模型和机制的协议、规则等，来创建部署工具150。例如，一个示例性数据环境可包括在两个不同平台上运行的数据库实例。在本实施方式中，数据建模工具202可创建两个逻辑数据模型130，每个平台一个。所创建的逻辑数据模型130可保持独立于存储解决方案，即逻辑数据模型130可以不指示确切的存储机制(例如，SQL SERVER、ORACLE等)，但是可以以逻辑方式定义实体及其关系。然而，所创建的逻辑数据模型130可在第二元数据132中包括平台120中的特定平台所需的特定信息，并且特定于这些平台120中提供的存储机制。

在306中，数据建模工具202可以基于逻辑数据模型130、第一元数据116和第二元数据132，创建可跨平台120操作的软件工件。如本领域的技术人员将理解的，软件工件可包括安装脚本152、填充脚本154、文档156和其他合适的部署工具150。数据建模工具202可将创建的软件工件存储在合适的结构、文件系统、磁盘、存储器等中。在一个实施方式中，数据建模工具202可允许用户在经由软件工件部署实体之前查看所创建的软件工件，并且以附加方式编辑或操纵所创建的软件工件。为了继续上面跨多个平台并由关系数据库技术组成的应用部署的示例，数据建模工具202可以检验为概念数据模型110中指定的每个平台创建的逻辑数据模型130。对于逻辑数据模型130中的每个逻辑数据模型，数据建模工具202可生成适当的DDL脚本来创建概念数据模型110中指定的表、行、列、索引、磁盘分区以及其他组件。由于相较于第二个平台，该示例中的第一个平台对于执行DDL脚本具有不同的要求或创建实际DDL脚本具有不同的语法要求，因此DDL脚本可能不同。数据建模工具202可使用第一元数据116来适应这些不同。另外，概念数据模型110可指定多个平台内的不同存储机制。因此，第一个DDL脚本和第二个DDL脚本可能基于底层存储机制进一步不同。数据建模工具202可使用第二元数据132提供的信息来适应这些不同。除了用于实例化关系数据库表的DDL脚本之外，数据建模工具202可创建DML脚本，该DML脚本指定适当的“更新(UPDATE)”或“插入(INSERT)”语句来填充所创建的表。为了适当地利用这些DML脚本，数据建模工具202还可以创建填充脚本154提供给DML脚本以将标称数据并入到表中。特别是在图形数据库的上下文中，通过填充脚本154包括虚拟数据，对于创建实体是必要的。然而，上述示例仅仅是示例性的，并且本领域技术人员将理解，可以在数据环境中以及在除关系数据库之外广泛的存储机制阵列中并入多个平台。

在308中，数据建模工具202可使用部署代理210，以使用在306中生成的软件工件跨平台120和跨其中的各种存储系统来实例化物理实体。在一个实施方式中，数据建模工具202可以从数据建模工具202的用户接收命令，以跨平台120或在平台120之间的特定平台上初始化实体。在一个实施方式中，部署代理210可以通过与平台120提供的适当API或其他接口交互来实例化实体。例如，在上述示例中由特定平台提供的服务，可以允许组织针对后端数据库运行查询或其他SQL命令。如由第一元数据116和第二元数据132获取的，该服务的要求和性质在平台之间可能不同。部署代理120可使用存储的参数接入服务，并针对后端数据库运行软件工件(在本示例中为DDL和DML脚本)，以及响应于创建实体的命令返回适当的结果或确认。在另一实施方式中，数据建模工具202可以以可导出的方式向管理员或用户提供软件工件的可下载版本。在本实施方式中，随后用户可以使用平台120和其中的存储设施上可用的工具和本机的工具，来执行软件工件。例如，用户可以接收DDL脚本并将该脚本复制/粘贴到由平台120中的一个平台提供的查询工具中。

图4示出了根据一些实施方式的基于概念数据模型生成开发人员文档的方法400的流程图。方法400可以通过处理逻辑来执行，处理逻辑可以包括硬件(例如电路、专用逻辑、可编程逻辑、微码等)、软件(例如在处理设备上执行的指令)或其组合。应当理解，可能不需要执行本文提供的所有步骤。此外，如本领域普通技术人员所理解的，可以同时执行一些步骤，或者以与图4所示不同的顺序执行。

在402中，数据建模工具202可更新概念数据模型110，或促进由管理员、数据架构师或其他用户对概念数据模型110的更新。在一个实施方式中，数据建模工具202可允许用户导入外部创建的数据模型，并从导入的数据模型确定对概念数据模型110的先前创建版本的更改。数据建模工具202可基于更改，来完成对概念数据模型110内的第一元数据116的任何所需更新。例如，用户可将在平台120中一个新平台上运行的附加应用程序包括在概念数据模型110的更新版本中。在该示例中，数据建模工具202可以更新第一元数据116以适应新的软件应用、其中使用的实体以及先前未包括在数据环境中的新平台。

在404中，如在402中更新的，数据建模工具202可以基于更改的概念数据模型110和其中包含的第一元数据116，重新创建逻辑数据模型130。数据建模工具202可跨平台120中的每个平台完成对逻辑数据模型130的所需更新。数据建模工具202还可基于对概念数据模型110所做的任何更改，来更新第二元数据132。为了继续上述示例，可更新第二元数据132以包括存储位置特定信息，以适应新应用和由应用存储和使用的数据。

在406中，数据建模工具202可以重新创建受概念数据模型110的更改所影响的任何软件工件。如本领域的技术人员理解的，数据建模工具202可更新安装脚本152、填充脚本154、文档156和其他合适的部署工具150。为了继续上述示例，新应用程序、平台和数据实体可以要求创建新的DDL和DML脚本，以使服务于新应用程序的实体实例化。在另一示例中，在402中可能已经接收到将列添加到关系数据库系统中的表的更改。在该示例中，可以修改先前创建的软件工件以包括变更，或者可以创建一组新的脚本，以使原始概念数据模型和更新的概念数据模型之间的增量实例化。

在408中，数据建模工具202可使用部署代理210来使用在406中更新的软件工件，跨平台120以及跨其中的各种存储系统，更新物理实体。例如，部署代理120可使用由特定平台提供的服务，来针对平台中的数据存储机制运行软件工件。部署代理120可响应于更新而接收合适的结果或确认。在另一实施方式中，数据建模工具202可提供更新的软件工件的下载和导出版本。在本实施方式中，随后用户可以使用平台120和其中的存储设施上可用的工具和本机的工具，来执行这些操作。

以这种方式，对概念数据模型110的更改可以向下传播到从概念数据模型110导出的所有软件工件。因此，组织可以在单个集中位置(即概念数据模型110)中对其技术环境的更改进行文档化或注释化。在此示例中，组织不需要跨所有平台、存储机制和应用程序更新或维护所有软件工件以适应所有位置的更改。

例如，可以使用一个或多个众所周知的计算机系统(例如图5所示的计算机系统500)来实施各种实施方式。例如可以使用一个或多个计算机系统500以及其组合和子组合，来实施本文所讨论的任何实施方式。

计算机系统500可包括一个或多个处理器(也称为中央处理单元或CPU)，例如处理器504。处理器504可以连接到通信设施506或总线。

计算机系统500还可以包括用户输入/输出设备508，例如监视器、键盘、指针设备等，其可以通过用户输入/输出接口502与通信设施506通信。

一个或多个处理器504可以是图形处理单元(GPU)。在一个实施方式中，GPU可以是设计用于处理数学密集型应用的专用电子电路的处理器。GPU可以具有并行结构，该并行结构对于大数据块(例如计算机图形应用程序、图像、视频等所共有的数学密集型数据)的并行处理是高效的。

计算机系统500还可以包括中心存储器或主存储器508，例如随机存取存储器(RAM)。主存储器508可包括一级或多级高速缓存。主存储器508可在其中存储控制逻辑(即计算机软件)和/或数据。

计算机系统500还可包括一个或多个辅存储设备或存储器510。辅存储器510可以包括例如硬盘驱动器512和/或可移动存储设备或驱动器514。可移动存储驱动器514可以是软盘驱动器、磁带驱动器、光盘驱动器、光存储设备、磁带备份设备和/或任何其他存储设备/驱动器。

可移动存储驱动器514可与可移动存储单元518交互。可移动存储单元518可包括计算机可用或可读的存储设备，其上存储有计算机软件(控制逻辑)和/或数据。可移动存储单元518可以是软盘、磁带、光盘、DVD、光存储盘和/或任何其他计算机数据存储设备。可移动存储驱动器514可以从可移动存储单元518读取和/或向可移动存储单元518写入。

辅存储器510可以包括用于允许计算机系统500访问计算机程序和/或其他指令和/或数据的其他装置、设备、组件、工具或其他方法。此类装置、设备、组件、工具或其他方法可包括例如可移动存储单元522和接口520。可移动存储单元522和接口520的示例可包括程序盒和盒式接口(例如在视频游戏设备中找到的程序盒和盒式接口)、可移动存储器芯片(例如EPROM或PROM)和相关联的插槽、存储卡和USB端口、存储卡和相关联的存储卡插槽，和/或任何其他可移动存储器单元和相关接口。

计算机系统500还可进一步包括通信或网络接口524。通信接口524可使计算机系统500能够与外部设备、外部网络、外部实体等的任意组合进行通信和交互(由附图标记528标记为单独和共同)。例如，通信接口524可以允许计算机系统500通过通信路径526与外部或远程设备528通信，通信路径526可以是有线和/或无线的(或其组合)，并且可包括LAN、WAN、互联网网等的任意组合。可以经由通信路径526向计算机系统500发送控制逻辑和/或数据，以及可以从计算机系统500发送控制逻辑和/或数据。

以几个非限制性示例为例，计算机系统500还可以是个人数字助理(PDA)、台式工作站、便携式计算机或笔记本计算机、上网本、平板电脑、智能电话、智能手表或其他可穿戴设备、电器、物联网的一部分和/或嵌入式系统中的任意一项或其任意组合。

计算机系统500可以是客户端或服务器，通过任意交付范式访问或托管任意应用程序和/或数据，包括但不限于远程或分布式云计算解决方案；本地或私有软件(基于云的“本地”解决方案)；“即服务”模型(例如，内容即服务(CaaS)，数字内容即服务(DCaaS)、软件即服务(SaaS)、管理软件即服务(MSaaS)、平台即服务(PaaS)、桌面即服务(DaaS)、框架即服务(FaaS)、后端即服务(BaaS)、移动后端即服务(MBaaS)、基础设施即服务(IaaS)等)；和/或包括上述示例或其他服务或交付范式的任意组合的混合模型。

计算机系统500中的任何适用的数据结构、文件格式和模式可以从标准中导出，该标准包括但不限于JavaScript对象表示法(JSON)、可扩展标记语言(XML)、另一种标记语言(YAML)、可扩展超文本标记语言(XHTML)、无线标记语言(WML)、信息包(MessagePack)、XML用户界面语言(XUL)，或单独或组合的任何其他功能相似的表示形式。可替代地，专有的数据结构、格式或模式可以单独使用，也可以与已知的或开放的标准结合使用。

在一些实施方式中，有形、非暂时性设备或制品包括存储有控制逻辑(软件)的有形、非暂时性计算机可用或可读介质，有形、非暂时性设备或制品在本文中也可称为计算机程序产品或程序存储设备。这包括但不限于计算机系统500、主存储器508、辅存储器510、可移动存储单元518和522，以及体现上述任意组合的有形物品。当由一个或多个数据处理设备(例如计算机系统500)执行时，这样的控制逻辑可以使这样的数据处理设备如本文所描述的操作。

基于本公开所包含的教程，本领域的技术人员将清楚地知道如何使用除图5所示之外的数据处理设备、计算机系统和/或计算机体系结构来进行和使用本公开的实施方式。具体而言，实施方式可与本文描述的以外的软件、硬件和/或操作系统实施一起操作。

应当理解，具体实施方式部分而不是任何其他部分，旨在用于解释权利要求。其他部分可提出发明人所设想的一个或多个但不是全部的示例性实施方式，并且因此，并不旨在以任何方式限制本公开或所附权利要求。

虽然本公开描述了用于示例性领域和应用的示例性实施方式，但是应当理解本公开并不限于此。在本公开的范围和精神内，其他实施方式及其修改是可行的。例如，在不限制本段的一般性的情况下，实施方式不限于图中所示和/或本文所描述的软件、硬件、固件和/或实体。此外，实施方式(无论是否在本文中明确描述)对于本文所描述的示例之外的领域和应用具有重要的实用性。

本文借助于示出特定功能及其关系的实施的功能构件描述了实施方式。为了便于描述，本文任意定义了这些功能构件的边界。只要合适地执行指定的功能和关系(或其等同物)，就可以定义替代边界。另外，替代实施方式可以使用不同于本文所描述的顺序，来执行功能块、步骤、操作、方法等。

本文中对“一个实施方式”、“实施方式”、“示例实施方式”或类似短语的引用，表示所描述的实施方式可包括特定特征、结构或特性，但是每个实施方式不一定包括特定特征、结构或特性。此外，这些短语不一定指同一实施方式。此外，当结合实施方式描述特定特征、结构或特性时，将该特征、结构或特性合并到其他实施方式中(无论本文是否明确提及或描述)，将在本领域的技术人员的知识范围内。另外，可以使用表达“耦合”和“连接”及其派生词来描述一些实施方式。这些术语不一定是彼此的同义词。例如，可以使用术语“连接”和/或“耦合”来描述一些实施方式，以表示两个以上元件彼此直接物理或电接触。然而，术语“耦合”也可以表示两个以上元件彼此不直接接触，但仍然彼此协作或相互作用。

本公开的广度和范围不应受到上述任何示例性实施方式的限制，而应仅根据所附权利要求及其等同物来限定。

Claims (20)

1.一种计算机实施的方法，包括：

由一个或多个处理器定义概念数据模型，所述概念数据模型包括实体、多个平台和描述所述多个平台中每个平台的部署要求的第一元数据；

由所述一个或多个处理器，基于所述概念数据模型和用于所述多个平台中每个平台的所述第一元数据，创建逻辑数据模型，所述逻辑数据模型包括描述存储机制和存储特定实体定义的部署要求的第二元数据；

由所述一个或多个处理器，基于所述第二元数据和所述存储特定实体定义，来生成用于所述多个平台中每个平台的安装脚本和数据填充脚本；以及

由所述一个或多个处理器，使用所述安装脚本和所述数据填充脚本，将所述实体部署到所述多个平台中的每个平台中。

2.根据权利要求1所述的方法，还包括：

由所述一个或多个处理器，接收对所述概念数据模型的更改；

由所述一个或多个处理器，基于所述更改和所述概念数据模型，为所述多个平台中的每个平台创建更新的安装脚本和更新的数据填充脚本；以及

由所述一个或多个处理器，使用所述更新的安装脚本和所述更新的数据填充脚本，将所述实体重新部署到所述多个平台中的每个平台中。

3.根据权利要求1所述的方法，生成所述数据填充脚本还包括：

由所述一个或多个处理器，确定与所述实体相对应的实体类型；

由所述一个或多个处理器，基于所述第一元数据和所述实体类型获得随机化数据；以及

由所述一个或多个处理器，创建数据填充脚本，以使用所述随机化数据为所述多个平台中每个平台填充所述实体。

4.根据权利要求1所述的方法，还包括：

由所述一个或多个处理器，确定与所述实体相对应的实体类型；以及

由所述一个或多个处理器，基于所述第一元数据和所述实体类型创建文档，其中所述文档描述所述实体和所述实体类型。

5.根据权利要求1所述的方法，还包括：

由所述一个或多个处理器，基于所述概念数据模型创建映射文件。

6.根据权利要求1所述的方法，还包括：

由所述一个或多个处理器，向查询代理公开所述概念数据模型以处理整合查询。

7.根据权利要求1所述的方法，其中所述概念数据模型还包括第二实体以及所述实体与所述第二实体之间的关系。

8.一种系统，包括：

存储器；以及

至少一个处理器，耦接到所述存储器并且被配置为：

定义概念数据模型，所述概念数据模型包括实体、多个平台和描述所述多个平台中每个平台的部署要求的第一元数据；

基于所述概念数据模型和用于所述多个平台中每个平台的所述第一元数据，创建逻辑数据模型，所述逻辑数据模型包括描述存储机制和存储特定实体定义的部署要求的第二元数据；

基于所述第二元数据和所述存储特定实体定义，来生成用于所述多个平台中每个平台的安装脚本和数据填充脚本；以及

使用所述安装脚本和所述数据填充脚本，将所述实体部署到所述多个平台中的每个平台中。

9.根据权利要求8所述的系统，所述至少一个处理器还被配置为：

接收对所述概念数据模型的更改；

基于所述更改和所述概念数据模型，为所述多个平台中的每个平台创建更新的安装脚本和更新的数据填充脚本；以及

使用所述更新的安装脚本和所述更新的数据填充脚本，将所述实体重新部署到所述多个平台中的每个平台中。

10.根据权利要求8所述的系统，其中，为生成所述数据填充脚本，所述至少一个处理器被配置为：

确定与所述实体相对应的实体类型；

基于所述第一元数据和所述实体类型获得随机化数据；以及

创建数据填充脚本，以使用所述随机化数据为所述多个平台中每个平台填充所述实体。

11.根据权利要求8所述的系统，所述至少一个处理器还被配置为：

确定与所述实体相对应的实体类型；以及

基于所述第一元数据和所述实体类型创建文档，其中所述文档描述所述实体和所述实体类型。

12.根据权利要求8所述的系统，所述至少一个处理器还被配置为：

基于所述概念数据模型创建映射文件。

13.根据权利要求8所述的系统，所述至少一个处理器还被配置为：

向查询代理公开所述概念数据模型以处理整合查询。

14.根据权利要求8所述的系统，其中所述概念数据模型还包括第二实体以及所述实体与所述第二实体之间的关系。

15.一种非暂时性计算机可读设备，存储有指令，当所述指令由至少一个计算设备执行时，使所述至少一个计算设备执行以下操作，包括：

定义概念数据模型，所述概念数据模型包括实体、多个平台和描述所述多个平台中每个平台的部署要求的第一元数据；

基于所述概念数据模型和用于所述多个平台中每个平台的所述第一元数据，创建逻辑数据模型，所述逻辑数据模型包括描述存储机制和存储特定实体定义的部署要求的第二元数据；

基于所述第二元数据和所述存储特定实体定义，来生成用于所述多个平台中每个平台的安装脚本和数据填充脚本；以及

使用所述安装脚本和所述数据填充脚本，将所述实体部署到所述多个平台中的每个平台中。

16.根据权利要求15所述的非暂时性计算机可读设备，所述操作还包括：

接收对所述概念数据模型的更改；

基于所述更改和所述概念数据模型，为所述多个平台中的每个平台创建更新的安装脚本和更新的数据填充脚本；以及

使用所述更新的安装脚本和所述更新的数据填充脚本，将所述实体重新部署到所述多个平台中的每个平台中。

17.根据权利要求15所述的非暂时性计算机可读设备，生成所述数据填充脚本还包括：

确定与所述实体相对应的实体类型；

基于所述第一元数据和所述实体类型获得随机化数据；以及

创建数据填充脚本，以使用所述随机化数据为所述多个平台中每个平台填充所述实体。

18.根据权利要求15所述的非暂时性计算机可读设备，所述操作还包括：

确定与所述实体相对应的实体类型；以及

基于所述第一元数据和所述实体类型创建文档，其中所述文档描述所述实体和所述实体类型。

19.根据权利要求15所述的非暂时性计算机可读设备，所述操作还包括：

基于所述概念数据模型创建映射文件。

20.根据权利要求15所述的非暂时性计算机可读设备，所述操作还包括：

向查询代理公开所述概念数据模型以处理整合查询。

Images