CN116450637A - 一种数据管理方法、装置、电子设备以及存储介质 - Google Patents

Abstract

本申请实施例公开了一种数据管理方法、装置、电子设备以及存储介质，该方法包括：获取待处理数据流，待处理数据流包括若干个数据库表；确定若干个数据库表的次序信息和关键字段信息；根据若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，数据流模型用于表征若干个数据库表之间的关联关系。这样，基于待处理数据流中若干个数据库表对应的次序信息和关键字段信息生成的数据流模型，能够实现对若干个数据库表的高效管理，降低了人工维护成本，而且查询方便，提升了数据管理效率。

Description

一种数据管理方法、装置、电子设备以及存储介质

技术领域

本申请涉及数据管理技术领域，尤其涉及一种数据管理方法、装置、电子设备以及存储介质。

背景技术

元数据(Metadata)是描述其它数据的数据(data about other data)，或者是用于提供某种资源的有关信息的结构数据(structured data)。在这里，元数据是描述信息资源或数据等对象的数据，其使用目的在于：识别资源；评价资源；追踪资源在使用过程中的变化；实现简单高效地管理大量网络化数据；实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。

随着业务系统的业务逻辑日益复杂，如何在海量数据下有效管理元数据信息成为亟需要解决的一个问题。目前，针对元数据的管理，主要是通过人工梳理手段把元数据信息一条条的录入到文档里面，而且还需要建立标准的数据字典模型，导致人工维护成本高，查询工作量较大，进而导致效率低。

发明内容

本申请提供了一种数据管理方法、装置、电子设备以及存储介质，能够通过数据流模型实现对若干个数据库表的高效管理，降低了人工维护成本，而且查询方便，提升了数据管理效率。

本申请的技术方案是这样实现的：

第一方面，本申请实施例提供了一种数据管理方法，该方法包括：

获取待处理数据流，所述待处理数据流包括若干个数据库表；

确定所述若干个数据库表的次序信息和关键字段信息；

根据所述若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，所述数据流模型用于表征所述若干个数据库表之间的关联关系。

第二方面，本申请实施例提供了一种数据管理装置，包括获取单元，确定单元和生成单元，其中，

所述获取单元，配置为获取待处理数据流，所述待处理数据流包括若干个数据库表；

所述确定单元，配置为确定所述若干个数据库表的次序信息和关键字段信息；

所述生成单元，配置为根据所述若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，所述数据流模型用于表征所述若干个数据库表之间的关联关系。

第三方面，本申请实施例提供了一种电子设备，该电子设备包括存储器和处理器，其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如第一方面所述的数据管理方法。

第四方面，本申请实施例提供了一种计算机存储介质，该计算机存储介质存储有计算机程序，该计算机程序被至少一个处理器执行时实现如第一方面所述的数据管理方法。

本申请实施例所提供的一种数据管理方法、装置、电子设备以及存储介质，该方法包括：获取待处理数据流，待处理数据流包括若干个数据库表；确定若干个数据库表的次序信息和关键字段信息；根据若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，数据流模型用于表征若干个数据库表之间的关联关系。这样，基于待处理数据流中的若干个数据库表的次序信息和关键字段信息生成的数据流模型，不仅能够实现对这若干个数据库表的高效管理，降低了人工维护成本，而且还能够适用复杂的应用场景；另外，由于该数据流模型能够完整记录数据库表与数据库表之间的关联关系，避免了创建物理外键导致的性能问题，同时还能够在数据流模型中对数据流信息进行方便查询，提升了数据管理效率。

附图说明

图1为本申请实施例提供的一种数据管理方法的流程示意图；

图2为本申请实施例提供的另一种数据管理方法的流程示意图；

图3为本申请实施例提供的又一种数据管理方法的流程示意图；

图4为本申请实施例提供的一种数据管理装置的组成结构示意图；

图5为本申请实施例提供的一种电子设备的组成结构示意图；

图6为本申请实施例提供的另一种电子设备的组成结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释相关申请，而非对该申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关申请相关的部分。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

元数据(Metadata)是描述其它数据的数据(data about other data)，或者是用于提供某种资源的有关信息的结构数据(structured data)。元数据是描述信息资源或数据等对象的数据，其使用目的在于：识别资源；评价资源；追踪资源在使用过程中的变化；实现简单高效地管理大量网络化数据；实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。

由于元数据也是数据，因此可以用类似数据的方法在数据库中进行存储和获取。如果提供数据元的组织同时提供描述数据元的元数据，将会使数据元的使用变得准确而高效。用户在使用数据时可以首先查看其元数据以便能够获取自己所需的信息。

随着业务系统的业务逻辑日益复杂，尤其是自敏捷开发的流行，一个项目可以分为多个相互联系且能够独立运行的小项目，并分别完成，这给系统的数据质量与一致性带来了巨大的挑战，在这样的背景下，需要一套元数据管理方法来保证业务系统数据的质量以及后续的可维护性。

目前，一种解决方案是可以通过数据字典或者文档管理的方式管理业务系统元数据。其中，数据字典是描述数据的信息集合，是对系统中使用的所有数据元素的定义的集合。在传统的关系型数据库(如Oracle、MySQL)中，都包含一些数据字典表，用以存储表信息、字段信息、索引、约束信息等等，在系统开发过程中，一旦有加表、改字段等操作，数据字典表的信息将相应更新。数据库数据字典不仅是每个数据库的中心，而且对每个用户也是非常重要的信息。另一种解决方案是可以使用文档(如Excel、Word)来管理元数据。其中，文档管理元数据需要建立标准的数据字典模型，用以管理数据库中表、字段的定义与描述信息，需要安排专门人员来维护、更新文档信息，以保证数据字典文档与数据库表结构的一致性。

然而，在利用数据字典进行元数据管理时，需要建立物理外键来记录表与表的关联关系，物理外键的好处是对于不满足外键约束的数据，无法录入系统，这样很大程度上避免了垃圾数据的产生。但是，物理外键也存在很大问题，一是加大了系统开发难度，二是加大数据处理难度，三是对系统性能有较大影响。因此，多数企业通常不选择建立物理外键，而是在系统开发中加入对外键约束的校验。另外，数据字典无法描述一些复杂的业务场景，数据字典中的外键关系，只能描述一个子表对应一个父表的关系，在实际业务中，可能存在一个子表对应多个父表的关系。在利用文档管理进行元数据管理时，人工维护的成本太高，而且容易出现文档更新不及时与系统版本不一致的情况。另外，查询工作量往往较大，需要查阅文档的多处确认表与表的关联关系，导致查询复杂且效率低下。此外，对于上述已有的两种解决方案还存在一次只能查询到两个表之间的关联关系，而不能一次性查询多张表的上下游关系的问题。

基于此，本申请实施例提供了一种数据管理方法，该方法的基本思想是：获取待处理数据流，待处理数据流包括若干个数据库表；确定若干个数据库表的次序信息和关键字段信息；根据若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，数据流模型用于表征若干个数据库表之间的关联关系。这样，基于待处理数据流中的若干个数据库表的次序信息和关键字段信息生成的数据流模型，不仅能够实现对这若干个数据库表的高效管理，降低了人工维护成本，而且还能够适用复杂的应用场景；另外，由于该数据流模型能够完整记录数据库表与数据库表之间的关联关系，避免了创建物理外键导致的性能问题，同时还能够在数据流模型中对数据流信息进行方便查询，提升了数据管理效率。

下面将结合附图对本申请各实施例进行详细说明。

本申请的一实施例中，参见图1，其示出了本申请实施例提供的一种数据管理方法的流程示意图。如图1所示，该方法可以包括：

S101、获取待处理数据流，待处理数据流包括若干个数据库表。

S102、确定若干个数据库表的次序信息和关键字段信息。

S103、根据若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，数据流模型用于表征若干个数据库表之间的关联关系。

需要说明的是，本申请实施例提供了一种数据管理方法，具体可以是指元数据管理方法。该方法可以应用于数据管理装置，或者集成有该数据管理装置的电子设备。在这里，电子设备可以是诸如计算机、智能手机、平板电脑、笔记本电脑、掌上电脑、个人数字助理(Personal Digital Assistant，PDA)、导航装置、服务器等等，本申请实施例对此不作具体限定。

还需要说明的是，对于业务系统中的某一个业务过程，该业务过程中产生的数据可以存储到数据库的一个个表中，将这些表称作数据库表。这些数据库表组成待处理数据流，每一个数据库表都代表了业务过程中的某一阶段。这里，数据库表即为元数据，通过本申请实施例提供的数据管理方法可以对这些元数据进行高效管理，并清晰地表征各数据库表之间的关联关系。

以一个简单的商品订货业务为例，在该业务的业务过程中，其对应的待处理数据流所包括的数据库表参见表1和表2。

表1

表2

如表1和表2所示，每个数据库表均可以包括表名称，若干个字段的字段名、字段描述、字段类型以及字段是否为主键。其中，表1为产品表，表2为订单表。

以表1为例，表名称为product，表1包括三个字段，三个字段的字段名分别为：product_no，product_name和price。其中，product_no表示产品号，字段类型为整数型(int)，是表1的主键；product_name表示产品名称，字段类型为可变长字符串(varchar(100))；price表示单价，字段类型为十进制(decimal(10,2))。

表2的表名称为order，在表2中，order_no和item_no均为表2的主键，这时候，order_no和item_no可以组成表2的联合主键。

在一些实施例中，确定若干个数据库表的次序信息和关键字段信息，可以包括：

确定若干个数据库表在待处理数据流中的先后顺序，并根据先后顺序生成若干个数据库表的次序信息；

确定若干个数据库表中每一个数据库表对应的流入字段和流出字段，并根据每一个数据库表对应的流入字段和流出字段确定若干个数据库表的关键字段信息。

需要说明的是，在本申请实施例中，数据库表的次序信息表示数据库表在待处理数据流中产生的先后顺序。因此，首先确定若干个数据库表在待处理数据流中的先后顺序，然后根据先后顺序生成每个数据库表的次序信息，这里，可以用从1开始顺序增长的自然数表示次序信息。

另外，对于一个待处理数据流，可能存在两个或者两个以上的数据库表的顺序相同，例如在进行采购时，采购的对象可以是产品A，也可以是产品B；其中，产品A对饮数据库表A，产品B对应数据库表B。这时候，数据库表A和数据库表B就具有相同的次序信息。

对于表1和表2组成的待处理数据流，其先后顺序可以是根据产品表形成针对该产品的订单表，即表1先产生，表2后产生。那么表1对应的次序信息为1，表2对应的次序信息为2。

还需要说明的是，在本申请实施例中，在确定关键字段信息时，可以分别确定若干个数据库表各自对应的流入字段和流出字段，并根据流入字段和流出字段确定数据库表的关键字段信息。也就是说，数据库表的关键字段信息可以包括数据库表的流入字段和流出字段。

其中，流出字段为该数据库表的主键字段，流入字段为该数据库表的流入表的主键字段，流入表通常为次序信息与数据库表相邻的前一个数据库表。这里，主键字段可以是数据库表中的一个或多个字段，它的值可以用于唯一标识数据库表。

进一步的，对于每一个数据库表，关键字段信息还可以包括：流入表和接收字段。

需要说明的是，数据库表对应的关键字段信息还可以包括流入表名称和接收字段；其中，流入表为数据库表的流入表的名称字段，接收字段为流入表的关联字段(通常为数据库表的外键字段)，数据库表对应的接收字段与流入表的流入字段相关联。

在一些实施例中，根据若干个数据库表的次序信息和关键字段信息，生成数据流模型，可以包括：

根据若干个数据库表，生成若干个数据流节点；

根据若干个数据库表的次序信息和关键字段信息，将若干个数据流节点进行串接，得到数据流模型。

需要说明的是，根据若干个数据库表，可以生成若干个数据流节点，其中，一个数据库表可以对应生成一个或者多个数据流节点，在数据库表对应一个父表的情况下，一个数据库表对应生成一个数据流节点；在一个数据库表对应多个父表的情况下，一个数据库表对应生成多个数据流节点。

一个数据流节点的内容包括但不限于数据库表的次序信息和关键字段信息。然后，按照各数据库表的次序信息和关键字段信息，依次将得到的数据流节点串接在一起，就得到了数据流模型。

在数据流模型中，数据流节点是按照各数据流节点所对应的数据库表的次序信息顺序串接的，而且对于次序信息相邻的两个数据流节点，前一数据流节点的流出字段为后一数据流节点的流入字段，形成了两个数据流节点之间的关联，并清晰表示了数据库表的关联关系。

在一些实施例中，确定若干个数据库表中每一个数据库表对应的流入字段和流出字段，可以包括：

确定第一数据库表的主键字段，将主键字段作为第一数据库表对应的流出字段；

确定第一数据库表对应上一数据流节点的第二数据库表，将第二数据库表确定为第一数据库表对应的流入表，并将流入表的主键字段作为第一数据库表对应的流入字段；

其中，第一数据库表为若干个数据库表中的任意一个数据库表。

需要说明的是，对于若干个数据库表中的任意一个数据库表(称作第一数据库表)，在确定其流入字段和流出字段时，可以先确定第一数据库表的主键字段，并将主键字段确定为第一数据库表的流出字段；同时，确定第一数据库表对应的上一数据流节点的第二数据库表，即第二数据库表为次序信息与第一数据库表相邻且位于第一数据库表之前的数据库表，也就是第一数据库表的流入表，将流入表的主键字段作为第一数据库表对应的流入字段。

在一些实施例中，该方法还可以包括：

在第一数据库表处于待处理数据流的起始数据流节点的情况下，确定第一数据库表对应的流入表和流入字段均为空；

在第一数据库表处于待处理数据流的结束数据流节点的情况下，确定第一数据库表对应的流出字段为空。

需要说明的是，对于第一数据库表，如果其为待处理数据流的起始，那么其并不存在流入表，则确定其对应的流入表和流入字段均为空(null)，同时，其接收字段也为空；如果第一数据库表为待处理数据流的结束，那么其并不存在流出字段，则其对应的流出字段为空。

对于表1而言，其流出字段为其主键字段product_no，由于其为待处理数据流的起始，没有数据库表流入，因此，表1的流入字段、流入表和接收字段均为空。对于表2而言，其流入表为表1，其流入字段为表1的主键字段product_no，由于表2为待处理数据流的结束，因此，其流出字段为空。

参见表3，其为基于表1和表2生成的数据流模型(也称为数据流模型表)。

表3

flow_name

seq_no

tab_name

out_col

get_col

in_tab_name

in_col

产品订货流

1

product

product_no

null

null

null

产品订货流

2

order

null

product_no

product

product_no

如表3所示的数据流模型，其中的每一行为数据流模型的一个数据流节点，表3包括两个数据流节点，一个是表1对应的数据流节点(即表3的第二行)，另一个是表2对应的数据流节点(即表3的第三行)。

在表3中，flow_name表示数据流模型的名称，通常为其代表的待处理数据流的名称，由于表3代表的是产品订货流，因此其flow_name为产品订货流；seq_no表示数据流节点对应的数据库表的次序信息；tab_name表示数据流节点对应的数据库表的表名称；out_col表示数据流节点的流出字段，也就是数据流节点对应的数据库表的流出字段；get_col表示数据流节点的接收字段，也就是数据流节点对应的数据库表的流出字段；in_tab_name，表示数据流节点的流入表，也就是数据流节点对应的数据库表的流入表的名称；in_col表示数据流节点的流入字段，也就是数据流节点对应的数据库表的流入字段。

如表3所示，在数据流模型中除包括次序信息和关键字段信息之外，还可以包括数据流名称(flow_name)，用于表示该数据流模型所对应的待处理数据流。

可见，通过表3，能够将表1和表2之间的关联关系进行表征。例如，表1和表2之间的流入流出关系为，表1流入表2，以及各表的流入字段、流出字段以及接收字段等等。

还需要说明的是，该管理方法生成的数据流模型可以实现对某一业务过程中的数据库表的管理。这里，该业务过程不一定已经实际进行；也就是说，本申请实施例能够在业务开展之前或者之后的任意时间，生成数据流模型。

还需要说明的是，本申请实施例的基本思想是将数据库表看作数据库中的一个个节点，按照数据产生的先后顺序以及数据库表之间的关联关系，把一个个节点串联起来，就构成该业务过程的数据流，然后将数据流中的信息按照一定的数据结构存储到数据库中，得到数据流模型，数据流模型中包括若干个数据流节点。示例性地，如表4所示，其示出了本申请实施例提供的一种数据流模型的表结构及示例数据。其主要描述了在数据流模型中，一个数据流节点所包括的内容，以及数据流节点的各字段的字段描述、字段类型以及字段属性等。

表4

如表4所示，data_flow表示数据流，对于一个待处理数据流，其生成的数据流模型所包括的数据流节点中可以包括以下内容：flow_name、seq_no、tab_name、out_col、get_col、in_tab_name和in_col。

flow_name、seq_no、tab_name、in_tab_name均为数据流模型的主键，三者可以作为数据流模型的联合主键；seq_no表示tab_name(该数据流节点对应的数据库表)在待处理数据流中的次序信息，也称作序号；in_tab_name为流入表名称(也称作上游节点表名称)，in_col为in_tab_name的主键字段；out_col为该数据流节点的流出字段(通常为该数据流节点的主键字段)，get_col为本节点接收上游节点(即流入表对应的数据流节点)的关联字段(通常为数据流节点的外键字段)，一个完整的数据流模型为同一待处理数据流的多条data_flow表(即数据流节点)记录构成。

表2、表3和表4示出了一种简单的业务场景下，由待处理数据流生成数据流模型的过程，在实际中，往往还会存在更复杂的场景。例如，一个子表对应多个父表的业务场景。

因此，在一些实施例中，根据若干个数据库表，生成若干个数据流节点，可以包括：

若第一数据库表对应一个父表，则根据第一数据库表生成一个数据流节点；

若第一数据库表对应至少两个父表，则根据第一数据库表生成至少两个数据流节点，且至少两个数据流节点的次序信息相同；

其中，第一数据库表为若干个数据库表中的任意一个数据库表。

需要说明的是，将若干个数据库表中的任意一个数据库表记为第一数据库表，父表表示第一数据库的流入表。

对于第一数据库表(记为子表)，其对应的流入表记为父表。如果一个子表只对应一个父表，即第一数据库表只存在一个流入表，则如前述的表2～4，第一数据库表对应生成一个数据流节点。

如果一个子表对应至少两个父表，即第一数据库表存在多个流入表，则分别生成第一数据库表对应的至少两个数据流节点，这至少两个数据流节点的次序信息相同，但是流入信息不同(流入信息可以包括前述的：流入表名称、流入字段和接收字段)，而且子表对应的至少两个数据流节点的数量和至少两个父表的数量相同。

示例性地，以待处理数据流为一个物资采购流为例，其包括的数据库表为下述表5～8。

表5

表6

表7

表8

表5～8为某制造行业系统的物资采购业务的数据库表，其中，表5为工程部件表，表6为标准件表，表7为技术需求单表，表8为采购单表。工程部件为某个工程的专用物资，标准件为所有工程的通用物资，由于两种物资特征属性差异较大，故分为两张表存储。

在这种业务中，技术需求可能是针对工程部件的需求，也有可能是针对标准件的需求，从而表5和表6均为表7的父表，这时候，在生成数据流模型时，就需要针对表7生成两个数据流节点。最终生成的数据流模型如表9所示。

表9 某制造行业物资采购流示例数据

如表9所示，由于表5和表6均为物资采购流的起始，因此，表5和表6对应的数据流节点共用一个自增长序列(次序信息)，保证两张表的主键不冲突。该行业的物资采购流程是先由技术部门创建技术需求单，指定要采购的物资及数量，再交由采购部门创建采购单，发起采购。

该数据流模型存在两个起始数据流节点，proj_mat和std_mat，故数据流模型存在两条seq_no为1的记录，tech_mat_req的接收字段mat_no或者来源于proj_mat的流出字段proj_mat_no，或者来源于std_mat的流出字段std_mat_no，故数据流模型存在两条seq_no为2的记录。

另外，由于tech_mat_req的主键为tmr_no、tmr_item_no组成的联合主键，故表tech_mat_req的输出字段及表purchase_order的输入字段和接收字段均使用联合主键的元组格式表示。表5～9说明了如何使用数据流模型来表示一个子表对应多个父表的复杂业务场景。

进一步的，在实际中还存在一个待处理数据流对应多个业务过程的场景。对于这种复杂的待处理数据流，还可以按照先分流再合流的方式进行处理。参见图2，其示出了本申请实施例提供的另一种数据管理方法的流程示意图。如图2所示，该方法可以包括：

S201、对待处理数据流包括的若干个数据库表进行分流处理，得到至少两组数据库表。

S202、确定至少两组数据库表中每一组数据库表的次序信息和关键字段信息。

S203、根据每一组数据库表的次序信息和关键字段信息，生成至少两个数据流子模型；每一个数据流子模型分别用于表征每一组数据库表之间的关联关系。

需要说明的时候，在一些复杂的业务场景下，对于待处理数据流，虽然其对应的是同一个目标业务的业务过程，但是即使是同一个目标业务，与可能在业务进行时，存在不同的业务过程，即待处理数据流对应至少两个业务过程。

在这种情况下，本申请实施例还可以对待处理数据流所包括的数据库表进行分流处理，即将该待处理数据流中的数据库表分流为至少两组数据库表。这里，对于同时参与了多个业务过程的数据库表，在分流时，在每一个数据库表中均包括该数据库表。

对分流得到的每一组数据库表，分别确定每一组数据库表的次序信息和关键字段信息，并据此生成各自对应的数据流子模型。每一个数据流子模型分别用于表征每一组数据库表之间的关联关系。

对于每一组数据库表，确定数据流子模型的方式如前述。

示例性地，物资的采购流程可能分两种情况，一是通过技术需求单直接生成采购单，二是通过技术需求单先生成询价单再生成采购单。这种场景是由技术需求单开始，通过询价与不询价的两条分支，最终又合并于采购单，关于这种场景应该将业务过程归于两条业务流，即将待处理数据流分流为询价采购流和不询价采购流。

以这种询价和不询价的物资采购场景为例，待处理数据流中包括的数据库表为表7，以及下述表10～14。

表10

表11

表12

表13

表14

其中，表7为技术需求单，表10为询价单表；表11为技术需求与询价关联表(tmr与enq关联表)；表12为询价与采购关联表(enq和po关联表)；表13为技术需求与采购关联表(tmr与po关联表)，表14为采购单表。

需要说明的是，对于存在询价和不询价两种业务过程的物资采购流，关于技术需求单、询价单以及采购单之间可能存在多对多的关系，需要通过几个关联表进行关联，以区分询价和不询价的过程。且采购单表不再需要tmr_no、tmr_item_no字段。

将表7以及表10～14组成的待处理数据流进行分流，分流的结果为询价采购流和不询价采购流两组数据流，其中，询价采购流包括表7、表11、表10、表12和表14，对应询价场景下的物资采购流程；不询价采购流包括表7、表13和表14，对应不询价场景下的物资采购流程。

根据询价采购流得到的数据流子模型如图表15。

表15

根据不询价采购流得到的数据流子模型如表16。

表16

如表15和16所示，将询价与不询价的业务流程对应的数据库表划分为两个数据流，可以更加清晰地描述业务过程，待处理数据流被分为两组数据库表，并得到了两个数据流子模型，且两个数据流子模型的起始数据流节点对应的数据库表均为表7，结束数据流节点对应的数据库表均为表14，即两者具有相同的起点，在分流之后，最后又合流为相同的终点。

进一步的，在一些实施例中，该方法还可以包括：

对至少两个数据流子模型进行合流处理，得到数据流模型。

需要说明的是，在得到两个数据流子模型之后，还可以将两个数据流子模型进行合流处理，例如进行拼接或者保存在同一目录下，至少两个数据流子模型合流后的得到这种复杂场景下的数据流模型。

本示例说明了如何使用数据流模型来表示数据分流之后再合流的场景，对于一个非常复杂的待处理数据流，如果中间阶段存在分流再合流的情况，可以把待处理数据流分为多个阶段来处理，在命名数据流时可以用“XX流-XX阶段”来区分，分流的数据库表处于分别的数据流中。例如，将表15对应的数据流命名为：物资采购流—询价阶段，将表16对应的数据流命名为：物资采购流-不询价阶段。

进一步地，在得到数据流模型之后，还可以将数据流模型与数据字典进行比较，以确保信息准确无误。因此，在一些实施例中，在生成数据流模型之后，该方法还可以包括：

将数据流模型中的数据信息与数据字典进行比较；其中，数据字典存储有待处理数据流对应的数据信息；

若数据流模型中的数据信息与数据字典中的数据信息不一致，则基于数据字典中的数据信息对数据流模型中的数据信息进行修正，使得数据流模型中的数据信息与数据字典中的数据信息一致。

需要说明的是，数据字典中存储有待处理数据流对应的目标业务的业务数据，在得到待处理数据流对应的数据流模型之后，将数据流模型和数据字典进行比较核对，如果两者信息一致，则说明生成的数据流模型无误；如果两者信息不一致，就基于数据字典中的数据信息对数据流模型中的数据流信息进行修正，使得数据流模型与数据字典中的数据信息是一致的，从而得到准确的数据流模型。

进一步地，基于生成的数据流模型，还可以对各数据流节点对应的数据库表进行查询，并查询任意数据流节点的上下游关系。因此，在一些实施例中，在生成数据流模型之后，该方法还可以包括：

确定待查询信息；

基于待查询信息在数据流模型中进行查询，确定待查询信息对应的数据库表，和/或，确定待查询信息对应的数据流节点与数据流节点之间的关联关系。

需要说明的是，首先确定待查询信息，这里可以将次序信息和/或关键字段信息作为待查询信息在数据流模型中进行查询，从而能够得到待查询信息对应的至少一个数据流节点，并进一步得到该数据流节点对应的数据库表，同时，还可以获知数据流节点与其它数据流节点之间的关联关系。关联关系可以包括数据流节点之间的上下游关系、关键字段信息之间的关联等等，其中，将流入该数据流节点的数据流节点称为上游数据流节点，将该数据流节点所流入的数据流节点称为下游数据流节点；例如在前述表3中，第二行的产品订货流1就是第三行的产品订货流2的上游数据流节点，产品订货流2就是产品订货流1的下游数据流节点。在进行查询时，可以使用结构化查询语言(Structured Query Language，SQL语句)方便地实现查询多张数据库表的上下游关系及复杂的逻辑关联。

本实施例提供了一种数据管理方法，通过获取待处理数据流，待处理数据流包括若干个数据库表；确定若干个数据库表的次序信息和关键字段信息；根据若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，数据流模型用于表征若干个数据库表之间的关联关系。这样，基于待处理数据流中的若干个数据库表的次序信息和关键字段信息生成的数据流模型，不仅能够实现对这若干个数据库表的高效管理，降低了人工维护成本，而且还能够适用复杂的应用场景；另外，由于该数据流模型能够完整记录数据库表与数据库表之间的关联关系，避免了创建物理外键导致的性能问题，同时还能够在数据流模型中对数据流信息进行方便查询，提升了数据管理效率；另外，针对一个字表对应多个父表，以及待处理数据流过于复杂的场景，本申请实施例还可以针对一个数据流表生成多个数据流节点，或者通过对待处理数据流进行分流，分别得到数据流子模型后再合流等方式，实现将这些复杂场景下的待处理数据流转化为简洁清晰的数据流模型，进行数据流的高效管理。

本申请的另一实施例中，参见图3，其示出了本申请实施例提供的又一种数据管理方法的流程示意图。如图3所示，该方法可以包括：

S301、确定待处理数据流。

需要说明的是，数据流是对业务过程的一种描述，在本申请实施例中，每个待处理数据流通常只对应一个业务过程。确定待处理数据流，即是确定业务过程，可以根据业务过程为待处理数据流进行命名，例如：产品订货流、物资采购流等等，该命名可以作为待处理数据流的唯一标识。

S302、确定待处理数据流所包含的所有数据库表。

需要说明的是，在确定待处理数据流后，需要确定该待处理数据流对应的业务过程所涉及的所有数据库表。

还需要说明的是，同一数据库表可能存在于多个不同的待处理数据流中，即不同的待处理数据流中可能会包括有相同的数据库表。例如，前述的表7就分别存在于两个待处理数据流中。

示例性地，对于前述实施例中的产品订货流，其包括的数据库表为表1(产品表)和表2(订单表)；对于前述实施例中的物资采购流，其包括的数据库表为表5(工程部件表)、表6(标准件表)、表7(技术需求单表)和表8(采购单表)；对于前述实施例中需要进行分流-合流的复杂的物资采购流，其包括的数据库表为表7(技术需求单表)、表10(询价单表)、表11(技术需求与询价关联表)、表12(询价与采购关联表)、表13(技术需求与采购关联表)和表14(采购单表)。

S303、确定待处理数据流中所有数据库表的先后次序，为每个数据库表编号，并确定每个数据库表的流入流出字段信息，确定数据流信息。

S304、将确定的数据流信息写入到数据流模型中。

需要说明的是，根据业务过程中各数据库表产生的先后顺序，确定待处理数据流中所有数据库表的先后次序，为每个数据库表进行编号，并确定每个数据库表的流入流出字段信息。

确定出的数据流信息可以包括包括次序信息、流入字段、流出字段，还可以包括接收字段以及流入表等等。

具体来说，根据数据库表在待处理数据流中的先后顺序，生成每个数据库表在待处理数据流中的序号，即前述实施例中的次序信息。这里可以按照数字顺序生成从1到n的数字序列，并将其写入到数据流模型中。

在数据流模型中，每一行数据为该数据流模型中的一个数据流节点，对于每一个数据流节点，其流出字段为数据库表自身的主键，接收字段为外键字段，流入表为上一个节点的数据库表，流入字段为流入表的主键(数据库表的接收字段与流入表的流入字段相关联)。

顺序最先的数据库表对应数据流节点为起始数据流节点，起始数据流节点的接收字段、流入表、流入字段为null，顺序最后的数据库表对应的数据流节点为结束数据流节点，结束数据流节点的流出字段为null。

在本申请实施例的一种实现方式中，对于仅包括两个数据库表(表1和表2)的产品订货流，在数据流模型3中，表1对应的数据流节点的序号为1，表2对应的节点序号为2。表3为该业务过程对应的数据流模型。

如表3所示，其中包括两个数据流节点：产品订货流1和产品订货流2，产品订货流1为表1(产品表，product表)对应的数据流节点，和产品订货流2为表2(订单表，order表)对应的数据流节点。

由于product表对应的产品订货流1为该数据流模型的起始数据流节点，故产品订货流1的get_col、in_tab_name以及in_col均为null；order表对应的产品订货流2为该数据流模型的结束数据流节点，故产品订货流2的out_col为null。其中，product.product_no与order.product_no互为关联。

表1～3为产品订货流的一个简单业务场景，在实际中，往往存在更加复杂的业务场景。

在本申请实施例的另一种实现方式中，对于一个子表对应多个父表的复杂情况，如物资采购流，表5～8为某制造行业系统的物资采购业务的数据库表，其中工程部件可以为某个工程的专用物资，标准件可以为所有工程的通用物资。由于两种物资特征属性差异较大，故分为两张表(表5和表6)进行存储；该行业的物资采购流程是先由技术部门创建技术需求单，指定要采购的物资及其数量，再交由采购部门创建采购单，发起采购。该行业物资采购的数据流信息如表9所示。

在这种情况下，表7可以与表5关联，表7也可以与表6关联，即表7作为一个子表，存在表5和表6两个父表。在数据库模型中，表5和表6对应的数据流节点的主键共用一个自增长序列(即次序信息)，以保证两张表的主键不冲突。如表9所示，由于表5和表6对应的数据流节点均可以作为该数据流模型的起始数据流节点，故标5和表6对应的两个数据流节点的节点序号均为1。tech_mat_req.mat_no或者来源于proj_mat.proj_mat_no，或者来源于std_mat.std_mat_no，故表tech_mat_req存在两条seq_no为2的记录。

另外，由于tech_mat_req的主键为tmr_no、tmr_item_no的联合主键，故表tech_mat_req的输出字段及表purchase_order的输入字段和接收字段均使用元组格式表示。本示例说明了如何使用数据流模型来表示一个子表对应多个父表的复杂业务场景。

在本申请实施例的再一种实现方式中，在物资的采购流程中，还能存在不同的业务过程，例如物资的采购流程可能分两种情况，一是直接通过技术需求单直接生成采购单，二是通过技术需求单先生成询价单再生成采购单，关于tmr、enq、po可能存在多对多的关系，故需要几个关联表，且采购单表不再需要tmr_no、tmr_item_no字段。这种场景是由技术需求单开始，通过询价与不询价的两条分支，最终又合并与采购单，关于这种场景可以将业务归于两个数据流子模型，分别如表15和表16所示。

如表15和16所示，将询价与不询价划分为两个数据流，可以更加清晰地描述业务过程。本示例说明了如何使用数据流模型来表示数据分流之后再合流的场景，对于一个非常复杂的数据流，如果中间阶段存在分流再合流的情况，可以把数据流分为多个阶段来处理，在命名数据流用“XX流-XX阶段”来区分，分流的信息仍然处于分别的数据流中。

进一步的，在将数据流信息插入数据流模型时，可以通过以下语句实现：

该语句可重复执行，直至数据流模型中的数据流节点数量达到该数据流模型所包含的数据流节点的总数量。

当存在数据流业务的更新需求，例如根据前述确定的数据流信息(包括次序信息、流入字段、流出字段、接收字段以及流入表等等)更新数据时，可以通过以下语句实现：

该语句的参数可以根据前述确定的数据流信息来设置，其中需更新的字段均为可选项，根据实际情况更新数据。

S305、核对数据流信息，与数据字典相关信息保持一致。

在完成数据流信息的处理，得到数据流模型后，将数据流中的表名称以及关键字段信息等与数据字典的表名称、关键字段信息等进行核对是否一致，两者保持一致以便后续数据流模型与数据字典的结合使用。

综上所述，本申请实施例提供了一种数据流模型和生成数据流模型的方法，该数据流模型可以用来描述业务系统数据库中的表与表之间的关系，使业务系统的逻辑更加容易理解，同时使得系统更容易维护及二次开发，也为后期将系统数据集成到数据仓库带来了便利。本申请实施例可以通过一个简洁的数据流模型来记录数据库中表与表的关联关系，并且可存储于数据库中与数据字典并存。在数据流模型中，可以使用SQL语句方便地查询多张数据库表的上下游关系及复杂的逻辑关联，同时，系统也避免了因为创建物理外键而导致的各种性能问题。

以一个简单的示例来说明数据流模型的使用，以商品订货为例，如表1～3所示，表3中的两条数据为产品订货流的product表与order表的数据流节点信息，由于product表为起始数据流节点，故get_col、in_tab_name、in_col为null，order表为结束数据流节点，故out_col为null，product.product_no与order.product_no互为关联。

以上是数据流模型的简单示例，数据流模型的核心在于对数据流信息的收集，本申请实施例的完备的数据收集流程如下：(1)确定数据流。(2)确定数据流所包含的所有数据库表。(3)确定数据流中所有数据库表的先后次序，为每个数据库表编号，并确定数据流中每个数据库表的流入流出字段。(4)将确定的数据流信息写入到数据流模型中。(5)核对数据流信息，与数据字典相关信息保持一致。

在相关技术方案中，通过数据字典物理外键或文档来记录业务系统数据库表与表之间关系，会导致系统的性能问题且效率低下，易出错。而本申请实施例提出了一种数据流模型，不仅能够完整记录数据库表与表之间关系，避免了创建物理外键导致的性能问题，还能够在数据库中对数据流信息进行查询，远比文档记录更加方便和高效。另外，本申请实施例在提出数据流模型的同时，还提出了在一个子表对应多个父表、数据分流之后再合流的业务场景的数据标准，从而能够记录更加复杂的业务场景，与数据字典的单表元数据相结合使用，数据流模型将会有更广泛的应用场景。

本实施例提供了一种数据管理方法，本实施例是对前述实施例的具体实现进行详细阐述，从中可以看出，与相关技术相比，本申请实施例提供的技术方案至少具有以下优势：(1)相关技术使用数据字段管理元数据，需要在表上建立物理外键来记录表与表之间的关联关系，建立物理外键会导致系统开发难度加大、数据处理难度变大、影响系统性能等问题，使用数据流模型避免了系统开发时建立物理外键，也避免了相关种种问题。(2)相关技术使用文档管理元数据，人工维护的工作量较大、查阅困难、容易造成与系统信息不一致。使用数据流模型，即是在系统数据库中建立数据流表，在数据库中维护数据流信息，可以方便地与数据字典进行对比，避免与系统信息不一致，也可以方便地在数据库中进行查询数据流信息。(3)本申请实施例使用数据流模型，不仅仅能表示相邻两张表的关联关系，还能完整地表示整个数据链路的先后关联关系；建立数据流模型，即是对业务逻辑的梳理过程，可与业务系统开发同时进行，便于发现业务逻辑存在的问题；数据流模型还能够表示关于一个子表对应多个父表、数据分流之后再合流的复杂业务场景，相对于相关技术有更广的应用场景。

本申请的再一实施例中，参见图4，其示出了本申请实施例提供的一种数据管理装置40的组成结构示意图。如图4所示，该数据管理装置40可以包括确定单元401，生成单元402操作单元403，其中，

获取单元401，配置为获取待处理数据流，待处理数据流包括若干个数据库表；

确定单元402，配置为确定若干个数据库表的次序信息和关键字段信息；

生成单元403，配置为根据若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，数据流模型用于表征若干个数据库表之间的关联关系。

在一些实施例中，确定单元402，具体配置为确定若干个数据库表在所述待处理数据流中的先后顺序，并根据先后顺序生成若干个数据库表的次序信息；以及确定若干个数据库表中每一个数据库表对应的流入字段和流出字段，并根据每一个数据库表对应的流入字段和流出字段确定若干个数据库表的关键字段信息。

在一些实施例中，生成单元403，具体配置为根据若干个数据库表，生成若干个数据流节点；以及根据若干个数据库表的次序信息和关键字段信息，将若干个数据流节点进行串接，得到数据流模型。

在一些实施例中，确定单元402，还具体配置为确定第一数据库表的主键字段，将主键字段作为第一数据库表对应的流出字段；以及确定第一数据库表对应上一数据流节点的第二数据库表，将第二数据库表确定为第一数据库表对应的流入表，并将流入表的主键字段作为第一数据库表对应的流入字段；其中，第一数据库表为若干个数据库表中的任意一个数据库表。

在一些实施例中，确定单元402，还配置为在第一数据库表处于待处理数据流的起始数据流节点的情况下，确定第一数据库表对应的流入表和流入字段均为空；以及在第一数据库表处于待处理数据流的结束数据流节点的情况下，确定第一数据库表对应的流出字段为空。

在一些实施例中，生成单元403，还具体配置为若第一数据库表对应一个父表，则根据第一数据库表生成一个数据流节点；以及若第一数据库表对应至少两个父表，则根据第一数据库表生成至少两个数据流节点，且至少两个数据流节点的次序信息相同；其中，第一数据库表为若干个数据库表中的任意一个数据库表。

在一些实施例中，如图4所示，该数据管理装置还可以包括分流单元404，配置为对待处理数据流包括的若干个数据库表进行分流处理，得到至少两组数据库表；

确定单元402，还配置为确定至少两组数据库表中每一组数据库表的次序信息和关键字段信息；

生成单元403，还配置为根据每一组数据库表的次序信息和关键字段信息，生成至少两个数据流子模型；其中，每一个数据流子模型分别用于表征每一组数据库表之间的关联关系。

在一些实施例中，如图4所示，该数据管理装置还可以包括合流单元405，配置为对至少两个数据流子模型进行合流处理，得到数据流模型。

在一些实施例中，如图4所示，该数据管理装置还可以包括比较单元406，配置为将数据流模型中的数据信息与数据字典进行比较；以及若数据流模型中的数据信息与数据字典中的数据信息不一致，则基于数据字典中的数据信息对数据流模型中的数据信息进行修正，使得数据流模型中的数据信息与数据字典中的数据信息一致。

在一些实施例中，如图4所示，该数据管理装置还可以包括查询单元407，配置为确定待查询信息；以及基于待查询信息在数据流模型中进行查询，确定待查询信息对应的数据库表，和/或，确定待查询信息对应的数据流节点与数据流节点之间的关联关系。

可以理解地，在本实施例中，“单元”可以是部分电路、部分处理器、部分程序或软件等等，当然也可以是模块，还可以是非模块化的。而且在本实施例中的各组成部分可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

因此，本实施例提供了一种计算机存储介质，该计算机存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现前述实施例中任一项所述数据处理方法的步骤。

基于上述的一种数据管理装置40的组成以及计算机存储介质，参见图5，其示出了本申请实施例提供的一种电子设备50的组成结构示意图。如图5所示，可以包括：通信接口501、存储器502和处理器503；各个组件通过总线系统504耦合在一起。可理解，总线系统504用于实现这些组件之间的连接通信。总线系统504除包括数据总线之外，还包括电源总线、控制总线和状态信号总线。但是为了清楚说明起见，在图5中将各种总线都标为总线系统504。其中，通信接口501，用于在与其他外部网元之间进行收发信息过程中，信号的接收和发送；

存储器502，用于存储能够在处理器503上运行的计算机程序；

处理器503，用于在运行所述计算机程序时，执行：

获取待处理数据流，待处理数据流包括若干个数据库表；

确定若干个数据库表的次序信息和关键字段信息；

根据若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，数据流模型用于表征若干个数据库表之间的关联关系。

可以理解，本申请实施例中的存储器502可以是易失性存储器或非易失性存储器，或可包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，其用作外部高速缓存。通过示例性但不是限制性说明，许多形式的RAM可用，例如静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data RateSDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步链动态随机存取存储器(Synchronous link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本文描述的系统和方法的存储器502旨在包括但不限于这些和任意其它适合类型的存储器。

而处理器503可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器503中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器503可以是通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现场可编程门阵列(Field Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器502，处理器503读取存储器502中的信息，结合其硬件完成上述方法的步骤。

可以理解的是，本文描述的这些实施例可以用硬件、软件、固件、中间件、微码或其组合来实现。对于硬件实现，处理单元可以实现在一个或多个专用集成电路(ApplicationSpecific Integrated Circuits，ASIC)、数字信号处理器(Digital Signal Processing，DSP)、数字信号处理设备(DSP Device，DSPD)、可编程逻辑设备(Programmable LogicDevice，PLD)、现场可编程门阵列(Field-Programmable Gate Array，FPGA)、通用处理器、控制器、微控制器、微处理器、用于执行本申请所述功能的其它电子单元或其组合中。

对于软件实现，可通过执行本文所述功能的模块(例如过程、函数等)来实现本文所述的技术。软件代码可存储在存储器中并通过处理器执行。存储器可以在处理器中或在处理器外部实现。

可选地，作为另一个实施例，处理器503还配置为在运行所述计算机程序时，执行前述实施例中任一项所述的方法。

基于上述数据处理装置40的组成，参见图6，其示出了本申请实施例提供的另一种电子设备50的组成结构示意图。如图6所示，该电子设备50至少包括前述实施例中任一项所述的数据管理装置40。

对于电子设备50而言，由于基于待处理数据流中的若干个数据库表的次序信息和关键字段信息生成的数据流模型，不仅能够实现对这若干个数据库表的高效管理，降低了人工维护成本，而且还能够适用复杂的应用场景；另外，由于该数据流模型能够完整记录数据库表与数据库表之间的关联关系，避免了创建物理外键导致的性能问题，同时还能够在数据流模型中对数据流信息进行方便查询，提升了数据管理效率。

以上所述，仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。

需要说明的是，在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (13)

1.一种数据管理方法，其特征在于，所述方法包括：

获取待处理数据流，所述待处理数据流包括若干个数据库表；

确定所述若干个数据库表的次序信息和关键字段信息；

根据所述若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，所述数据流模型用于表征所述若干个数据库表之间的关联关系。

2.根据权利要求1所述的方法，其特征在于，所述确定所述若干个数据库表的次序信息和关键字段信息，包括：

确定所述若干个数据库表在所述待处理数据流中的先后顺序，并根据所述先后顺序生成所述若干个数据库表的次序信息；

确定所述若干个数据库表中每一个数据库表对应的流入字段和流出字段，并根据所述每一个数据库表对应的流入字段和流出字段确定所述若干个数据库表的关键字段信息。

3.根据权利要求2所述的方法，其特征在于，所述根据所述若干个数据库表的次序信息和关键字段信息，生成数据流模型，包括：

根据所述若干个数据库表，生成若干个数据流节点；

根据所述若干个数据库表的次序信息和所述关键字段信息，将所述若干个数据流节点进行串接，得到所述数据流模型。

4.根据权利要求3所述的方法，其特征在于，所述确定所述若干个数据库表中每一个数据库表对应的流入字段和流出字段，包括：

确定第一数据库表的主键字段，将所述主键字段作为所述第一数据库表对应的流出字段；

确定所述第一数据库表对应上一数据流节点的第二数据库表，将所述第二数据库表确定为所述第一数据库表对应的流入表，并将所述流入表的主键字段作为所述第一数据库表对应的流入字段；

其中，所述第一数据库表为所述若干个数据库表中的任意一个数据库表。

5.根据权利要求4所述的方法，其特征在于，所述方法还包括：

在所述第一数据库表处于所述待处理数据流的起始数据流节点的情况下，确定所述第一数据库表对应的所述流入表和所述流入字段均为空；

在所述第一数据库表处于所述待处理数据流的结束数据流节点的情况下，确定所述第一数据库表对应的所述流出字段为空。

6.根据权利要求3所述的方法，其特征在于，所述根据所述若干个数据库表，生成若干个数据流节点，包括：

若第一数据库表对应一个父表，则根据所述第一数据库表生成一个数据流节点；

若第一数据库表对应至少两个父表，则根据所述第一数据库表生成至少两个数据流节点，且所述至少两个数据流节点的次序信息相同；

其中，所述第一数据库表为所述若干个数据库表中的任意一个数据库表。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

对所述待处理数据流包括的若干个数据库表进行分流处理，得到至少两组数据库表；

确定所述至少两组数据库表中每一组数据库表的次序信息和关键字段信息；

根据所述每一组数据库表的次序信息和关键字段信息，生成至少两个数据流子模型；其中，每一个数据流子模型分别用于表征每一组数据库表之间的关联关系。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：

对所述至少两个数据流子模型进行合流处理，得到所述数据流模型。

9.根据权利要求1至8任一项所述的方法，其特征在于，在所述生成数据流模型之后，所述方法还包括：

将所述数据流模型中的数据信息与数据字典进行比较；

若所述数据流模型中的数据信息与所述数据字典中的数据信息不一致，则基于所述数据字典中的数据信息对所述数据流模型中的数据信息进行修正，使得所述数据流模型中的数据信息与所述数据字典中的数据信息一致。

10.根据权利要求1至8任一项所述的方法，其特征在于，在所述生成数据流模型之后，所述方法还包括：

确定待查询信息；

基于所述待查询信息在所述数据流模型中进行查询，确定所述待查询信息对应的数据库表，和/或，确定所述待查询信息对应的数据流节点与数据流节点之间的关联关系。

11.一种数据管理装置，其特征在于，包括获取单元，确定单元和生成单元，其中，

所述获取单元，配置为获取待处理数据流，所述待处理数据流包括若干个数据库表；

所述确定单元，配置为确定所述若干个数据库表的次序信息和关键字段信息；

所述生成单元，配置为根据所述若干个数据库表的次序信息和关键字段信息，生成数据流模型；其中，所述数据流模型用于表征所述若干个数据库表之间的关联关系。

12.一种电子设备，其特征在于，所述电子设备包括存储器和处理器，其中，

所述存储器，用于存储能够在所述处理器上运行的计算机程序；

所述处理器，用于在运行所述计算机程序时，执行如权利要求1至10任一项所述的数据管理方法。

13.一种计算机存储介质，其特征在于，所述计算机存储介质存储有计算机程序，所述计算机程序被至少一个处理器执行时实现如权利要求1至10任一项所述的数据管理方法。