CN107220266B - 一种创建业务数据库、业务数据存储和确定业务数据的方法及装置 - Google Patents

Abstract

本申请公开了一种创建业务数据库、业务数据存储和确定业务数据的方法及装置。该业务数据存储方法包括：接收业务数据，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值；将业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中；确定各业务公用属性的属性值是否存在于第二数据库的一条记录中，当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一记录的关联关系。使得不需要将各所述业务公用属性的属性值在第二数据库中重新进行存储，从而解决了现有技术的存储方式造成业务数据大量冗余的问题。

Description

一种创建业务数据库、业务数据存储和确定业务数据的方法 及装置

技术领域

本申请涉及数据库技术领域，尤其涉及一种创建业务数据库、业务数据存储和确定业务数据的方法及装置。

背景技术

随着互联网技术的快速发展，出现了众多基于互联网的业务，这些不同的业务在业务处理过程中均会产生业务数据。因此对于提供这些业务的企业来说，如何将这些不同业务所产生的业务数据进行存储是一个重大的技术问题。

现有技术主要通过一个业务数据库对不同的业务所产生的业务数据进行存储，该业务数据库通常会包括业务主体字段、业务客体字段以及属性维度字段。其中，业务主体字段用于记录使用对应业务的用户，业务客体字段用于记录该业务的业务标识，属性维度字段通过与该业务相关的多个业务属性来记录该业务在业务处理过程中的数据。通过这种方式，可以将不同业务在业务处理过程中所产生的业务数据存储在该数据库中。

然而，在实际大数据的背景下，当企业的业务数据的量达到一定规模时，现有技术的这种业务数据存储方式，通常会造成极大的数据冗余，从而使得需要较多的存储资源对这些业务数据进行存储。例如，在大数据的背景下会出现使用某一业务的用户数量较多的现象，因此通常会有几个用户在该业务的使用过程中的业务行为相同的情况，这样就会使得所产生的业务数据具有较大的共性。而现有技术会将这些有较大共性的数据，全部重复在数据库中进行存储，这样就使得数据库中的业务数据出现大量冗余，从而需要较多的存储资源对业务数据进行存储。

发明内容

本申请实施例提供一种创建业务数据库、业务数据存储和确定业务数据的方法及装置，用于解决现有技术的业务数据存储方式，在大数据下通常会造成极大的数据冗余，从而使得需要较多的存储资源对这些业务数据进行存储的问题。

本申请实施例提供了一种业务数据的存储方法，其特征在于，该方法包括：

接收业务数据，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值，所述业务公用属性的属性枚举值的数量小于预设数量；

将所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中；

确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中，当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一数据库的所述第一记录之间的关联关系。

优选的，所述第二数据库通过如下方法构建：

创建空白数据表；

在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识。

优选的，所述第一数据库包括关联字段；则，所述建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一记录的关联关系具体包括：

建立所述第二记录中的记录标识字段的属性字段值和所述第一记录中的关联字段的属性字段值的关联关系。

优选的，所述方法还包括：

在第二数据库中构建用于记录业务标识的业务标识字段；

通过所述第二数据库中的所述业务标识字段关联第三数据库，用以通过所述第三数据库确定各所述业务公用属性在对应业务中所对应的业务属性。

优选的，所述业务数据还包括自定义属性的属性值，所述业务自定义属性的属性枚举值的数量大于或等于预设数量；则，

所述第一数据库还包括业务自定义属性字段，所述业务自定义属性字段用于在接收所述业务数据后，存储所述业务数据中所述业务自定义属性的属性值。

优选的，所述方法还包括：

通过所述第一数据库中的所述业务标识字段关联第四数据库，用以通过所述第四数据库确定各所述业务自定义属性在对应业务中所对应的业务属性。

优选的，所述方法还包括：

当不存在时，将各所述业务公用属性对应的属性值作为第三记录存储在第二数据库，并将所述第三记录和所述第一记录建立关联关系。

本申请实施例还提供一种创建业务数据库的方法，该方法包括：

创建空白数据表；

在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识，所述业务公用属性的属性枚举值的数量小于预设数量；

将所述数据表作为业务数据库，用以存储业务数据中各业务公用属性对应的属性值，所述业务数据至少包括一个所述业务公用属性对应的属性值。

优选的，所述方法还包括：分别将各所述业务公用属性作为当前业务公用属性，固定所述当前业务公用属性之外的其它各业务公用属性的属性值，依次将所述当前业务公用属性的各个属性值作为当前属性值，并将所述当前属性值和当前业务公用属性之外的其它各业务公用属性的属性值记录在所述数据库中。

本申请实施例还提供一种确定业务数据的方法，该方法包括：

接收确定业务数据的请求，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性对应的属性值，所述业务公用属性的属性枚举值的数量小于预设数量；

根据所述请求获取第一数据库中的第一记录，用以确定所述业务用户标识和所述业务标识，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储各业务数据的业务用户标识，所述业务标识字段用于存储各业务数据的业务标识；

通过所述第一记录关联到第二数据库中的第二记录，用以确定各所述业务公用属性的属性值，所述第二记录为记录有各所述业务公用属性对应的属性值的记录。

本申请实施例还提供一种业务数据的存储装置，该装置包括：接收单元、第一记录存储单元、判断单元以及第二记录存储单元，其中：

接收单元，用于接收业务数据，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值，所述业务公用属性的属性枚举值的数量小于预设数量；

第一记录存储单元，用于将所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中；

判断单元，用于确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中；

第二记录存储单元，用于当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一数据库的所述第一记录之间的关联关系。

本申请实施例还提供一种创建业务数据库的装置，改装置包括：数据表创建单元、字段构建段元和数据库形成单元，其中：

数据表创建单元，用于创建空白数据表；

字段构建段元，用于在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识，所述业务公用属性的属性枚举值的数量小于预设数量；

数据库形成单元，用于将所述数据表作为业务数据库，用以存储业务数据中各业务公用属性对应的属性值，所述业务数据至少包括一个所述业务公用属性对应的属性值。

本申请实施例还提供一种确定业务数据的装置，该装置包括：接收单元、获取单元和关联单元，其中：

接收单元，用于接收确定业务数据的请求，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性对应的属性值，所述业务公用属性的属性枚举值的数量小于预设数量；

获取单元，用于根据所述请求获取第一数据库中的第一记录，用以确定所述业务用户标识和所述业务标识，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储各业务数据的业务用户标识，所述业务标识字段用于存储各业务数据的业务标识；

关联单元，用于通过所述第一记录关联到第二数据库中的第二记录，用以确定各所述业务公用属性的属性值，所述第二记录为记录有各所述业务公用属性对应的属性值的记录。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

在接收业务数据后，将业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中，然后在确定各业务公用属性的属性值存在于第二数据库的第二记录中时，建立所述第二记录与所述第一记录的关联关系。使得不需要将各所述业务公用属性的属性值在第二数据库中重新进行存储，从而解决了现有技术的存储方式对相似数据的重复存储，造成业务数据大量冗余的问题，占用较多存储资源的问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例1提供的一种业务数据的存储方法的具体实现流程示意图；

图2为本申请实施例2提供的一种创建业务数据库的方法的具体实现流程示意图；

图3为本申请实施例3提供的一种确定业务数据的方法的具体实现流程示意图；

图4为本申请实施例4提供的一种业务数据的存储装置的具体结构示意图；

图5为本申请实施例5提供的一种创建业务数据库的装置的具体结构示意图；

图6为本申请实施例6提供的一种确定业务数据的装置的具体结构示意图。

具体实施方式

接上所述，在实际应用中，越来越多的业务通过互联网来完成，并且通常会出现同一个企业提供的多个不同业务都是基于互联网。例如提供网购服务的企业通常还会提供网上支付的业务。因此，对于这些不同业务产生的业务数据进行有效地存储是企业遇到的一个重大问题。

现有技术存储业务数据的数据库中，通常会包括业务主体字段、业务客体字段以及属性维度字段。其中，业务主体字段用于记录使用对应业务的用户，业务客体字段用于记录该业务的业务标识，属性维度字段通过与该业务相关的多个业务属性来记录该业务在业务处理过程中的数据。

如表1所示，该表中的数据显示，张三和王五使用了Mkt_01业务，该业务有a属性(a_property，其它类比)、b属性以及c属性，其中a属性的属性值为value_1(a_property:value_1，其它类比)；李四使用了Mkt_02业务，该业务有d属性和e属性，其中d属性的属性值为value_4。

表1、现有技术的数据库

在大数据的背景下，当企业的业务数据的量达到一定规模时，现有技术的这种业务数据存储方式，通常会造成极大的数据冗余，从而使得需要较多的存储资源对这些业务数据进行存储。

在表1中，张三和王五均使用了Mkt_01业务，并且各个属性的属性值均相同，在这两组数据中只有业务主体不同，这样就使得业务数据出现冗余。特别是在实际应用中，企业为了更加全面的掌握用户对业务的使用情况，通常会在属性维度字段上设置较多的属性项。例如，在网上购物的业务中，属性纬度字段通常可以设置15个(甚至更多)属性项以上。这样就会使得业务数据冗余的情况进一步严重，企业通常需要较多的资源来存储这些业务资源。

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

以下结合附图，详细说明本申请各实施例提供的技术方案。

实施例1

实施例1提供了一种业务数据的存储方法，用于解决现有技术的业务数据存储方式，造成数据冗余，导致消耗更多存储资源的问题。该方法的具体流程示意图如图1所示，包括下述步骤：

步骤S11：接收业务数据。

在这里，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值，所述业务公用属性的属性枚举值的数量小于预设数量。

同一个企业通常会提供多个业务，为了便于管理，通常会为每个不同的业务分配业务标识，通过业务标识来区分不同的业务。需要说明的是，这里的业务通常可以是实际应用中服务类的业务或者商品交易类的业务，当然也可以是其它的业务。对应的业务标识可以是服务业务标识或者商品交易业务标识，通常为了提高便捷性，甚至也可以是服务或者商品本身的标识，也就是说业务标识可以是服务的标识或者是商品的标识。

业务用户标识用于标识使用该业务的用户。在使用某个业务的用户较多时，通常需要为各个不同的用户分配业务用户标识，用来区分使用该业务的不同用户。在实际应用中，该业务用户标识可以是注册使用该业务的用户ID、也可以是唯一标识该用户的其它用户个人信息。

这里所说的至少一个业务公用属性的属性值是指有一个或者多个业务公用属性的属性值，并且当有多个业务公用属性的属性值时，这些不同的业务公用属性的属性值属于不同的业务共用属性。例如，业务数据中有两个业务公用属性的属性值分别为上海和工商银行，其中上海属于业务共用属性城市的属性值，工商银行属于业务共用属性支付渠道的属性值，也就是说上海和工商银行为不同的业务共用属性的属性值。

所述业务公用属性的属性枚举值的数量小于预设数量。需要说明的是，业务所涉及到的业务属性通常有许多个，业务公用属性具体为属性值的枚举值的数量小于预设数量的业务属性。例如，赵六在北京通过工商银行卡号为M的信用卡，花费N元购买甲品牌手机的业务中，赵六为业务用户标识，手机为业务标识，业务属性包括城市(北京)、支付渠道(工商银行信用卡)、消费金额(N元)、品牌(甲)、卡号(M)。通常根据实际需要先设置一个预设数量(100、200或者其它值)，在这些业务属性中业务属性的枚举值的数量小于该预设数量时，将该业务属性作为业务公用属性，例如支付渠道等。需要进一步说明的是，在实际应用中通常也会有属性值的枚举值的数量大于或等于预设数量的业务属性，例如卡号等，在这里可以将这些业务属性称之为业务自定义属性。也就是说，所述业务自定义属性的属性枚举值的数量大于或等于预设数量。

步骤S12：将所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中。

在这里，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储业务用户标识，所述业务标识字段用于存储业务标识。因此，在将业务数据存储在第一数据库时，将业务数据中的业务用户标识和业务标识作为一条记录(这里称之为第一记录)，存储在第一数据库中，其中业务用户标识存储在对应的业务用户标识字段下，业务标识存储在对应的业务标识字段下。

需要说明的是，在实际应用中，由于业务数据通常还包括业务自定义属性的属性值，所以所述第一数据库还可以包括业务自定义属性字段，所述业务自定义属性字段用于在接收所述业务数据后，存储所述业务数据中所述业务自定义属性的属性值。对应步骤S11中的例子，卡号为业务自定义属性，可以在第一数据库中增加相应的业务自定义属性字段，用来存储该用户的卡号M。

需要进一步说明的是，在实际应用中，由于业务场景的多样性，通常在进行业务前并不清楚需要增加的什么样的业务自定义属性字段，也就是说并不清楚所要增加的业务自定义属性字段所对应的业务属性是什么。例如，孙七通过卡号为P的银行卡花费Q元购买某商品A，田八在商店H预定某服务B，在该例子中银行卡(P)、消费金额(Q)以及商店ID(H)均可以为业务自定义属性。但是在将这些数据存储在第一数据库时，通常不会增加三个业务自定义属性字段，而是增加两个业务自定义属性字段，这两个自定义属性字段，然后可以通过所述业务标识字段关联第四数据库，用以通过所述第四数据库确定所述业务自定义属性在对应业务中所对应的业务属性，如表2和表3，其中表2为实际应用中有两个业务自定义属性字段的第一数据库，表3为与实际应用中第一数据库关联的第四数据库。

表2、有两个业务自定义属性字段的第一数据库

业务用户标识	业务标识	业务自定义属性1	业务自定义属性2
				孙七	A	P	Q
田八	B	H

表3、与第一数据库关联的第四数据库

业务标识	业务自定义属性	业务属性
			A	业务自定义属性1	银行卡
A	业务自定义属性2	消费金额
			B	业务自定义属性1	商店ID

另外，在实际应用中，还可以通过所述业务标识字段关联第四数据库，用以通过所述第四数据库关联第五数据库来确定所述业务自定义属性在对应业务中所对应的业务属性。这种情况下，第五数据库中通常会包含对业务属性进行具体描述的字段，例如表3中的商品ID通过关联到第五数据库后，可以在第五数据库中确定该商店ID为提供服务(或商品)的商店的标识。这种通过第四数据库关联到第五数据库的方式，可以进一步细化对业务属性的描述，在需要准确描述各个业务属性的场景下可以进行使用。

当然，在实际应用中，第一数据库还可以包括一些其它的字段，用以通过这些字段来完成新的功能。例如，可以在第一数据库中增加时间字段，通过该时间字段来记录业务进行的时间；还可以在第一数据库中增加关联到其它数据库的字段，用来关联到其它的数据库。

步骤S13：确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中，当存在时执行步骤S14，当不存在时执行步骤S15。

步骤S14：建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一数据库的所述第一记录的关联关系。

步骤S15：将各所述业务公用属性对应的属性值作为第三记录存储在第二数据库，并将所述第三记录和所述第一记录建立关联关系。

综合分析步骤S13和步骤S14，当确定各所述业务公用属性的属性值存在于第二数据库的一条记录中时，只需要将该条记录(也就是第二记录，所述第二记录中的各属性字段的值与各所述业务公用属性的属性值对应相等)与第一记录建立关联关系即可，这种关联关系通常来说是指通过所述第一记录能够获取所述第二记录，当然也可以是通过所述第二记录来获取所述第一记录。这样就不需要将各所述公用数据的属性值在第二数据库中再次存储，从而能够减少业务数据的冗余，在存储时减少存储资源的占用。特别是在大数据的背景下，业务属性数量较多并且业务的使用频率较高，这种减少存储资源占用的效果更加明显。

一般来说，确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中的方式有多种。常用的方式是，通过各所述业务公用属性以及各所述业务公用属性对应的属性值查询第二数据库的各个记录，通过查询的结果来确定是否存在。

在步骤S13和步骤S15中，当确定各所述业务公用属性的属性值不存在于第二数据库的一条记录中时，将各所述业务公用属性对应的属性值作为第三记录存储在第二数据库，并将所述第三记录和所述第一记录建立关联关系。也就是说，只有在第二数据库中不存在第二记录时，才将各所述公用属性的属性值在第二数据库中作为一条记录(第三记录)进行存储。

需要说明的是第一记录、第二记录和第三记录只是为了将这三条记录进行区分，而不是指记录的生成时间或者重要性等方面存在差别。

采用实施例1提供的该方法，在接收业务数据后，将业务数据中的业务标识和业务用户表示存储在第一数据库中的第一记录中，然后确定第二数据库中是否存在各属性字段的值与各所述业务公用属性的属性值对应相等的记录，当存在时只需要将该记录与第一记录建立关联关系即可，这样就可以不用在第二数据库中再次存储各所述业务公用属性的属性值，从而减少了数据的冗余，节省了存储资源。特别是在数据量级大，业务属性的数量较多的情况下该方法能够更加显著的达到减少了数据的冗余，节省存储资源的效果。

进一步的，在实际应用中，在实施例1中所提到的所述第二数据库可以通过如下的步骤S21至步骤23来构建。

步骤S21：创建空白数据表。

创建空白数据表的方式可以有多种，所创建的数据表的格式也可以有多种，这里并不对数据表的格式以及创建数据表的方法做出限定。

步骤S22：在所述数据表中构建记录标识字段以及至少一个业务公用属性字段。

各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识。

在实际应用中，在建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一记录的关联关系时，通常可以将第一记录的记录标识和第二记录的记录标识建立关联关系。当然通常在数据库中，由于记录的条数通常会增减，因此各条记录的记录标识可能会发生变化，为了便于管理，通常可以在数据库中增加专门的字段，用于关联到其它的数据库。因此，所述第一数据库还可以包括关联字段，所述关联字段用于通过所述关联字段的属性字段的值与所述第二数据库中对应的记录进行关联；则，所述建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一记录的关联关系具体包括：建立所述第二记录中的记录标识字段的属性字段值和所述第一记录中的关联字段的属性字段值的关联关系。

为了便于理解，可以结合表4和表5进一步说明，其中表4为实际应用中增加了关联字段的第一数据库，表5为实际应用中的一种第二数据库。

表4、增加了关联字段的第一数据库

业务用户标识	业务标识	关联字段
			甲	A	P1
乙	B	H1

表5、实际应用中的一种第二数据库

记录标识字段	业务公用属性
		P2	W
H2	J

在表4中，通过关联字段的属性字段值，与表5中的记录标识字段的属性字段值进行关联，通过这种关联关系来确定两个数据库中记录的对应关系。例如，在表4中记录了甲使用了A业务，通过关联字段P1关联到表5中的P2，可以确定业务公用属性为W。需要说明的是P1和P2关联(H1和H2类比)，这种关联可以是指通过P1能够确定P2(例如P1和P2相等或相同)，也可以是一个连接等。

步骤S23：将所述数据表作为第二数据库，用于联合第一数据库存储业务数据。

通过步骤S21至步骤S23，可以构建第二数据库，该第二数据库包括记录标识字段以及至少一个业务公用属性字段。其实，在实际应用中，还可以在第二数据库中增加新的字段，用以实现另外的功能。例如，可以在第二数据库中也增加业务标识字段，通过该第二数据库中的业务标识字段的各个属性字段值关联到第三数据库，通过第三数据库来确定各公用属性在不同的业务中对应的业务属性。如表6和表7所示，其中表6为实际应用中增加了业务标识字段的第二数据库，表7为实际应用中的一种第三数据库。

表6增加了关联字段的第二数据库

记录标识字段	业务标识	业务公用属性
			aa	A	上海
bb	B	上海

表7、与第二数据库关联的第三数据库

业务标识	业务公用属性	业务属性
			A	上海	出售地
B	上海	生产地

在表6中可以发现，记录aa和记录bb的业务公用属性字段的属性字段值均为上海，这时候可以通过增加业务标识字段关联到第三数据库(表7)。从表7中可以确定，记录aa的上海为出售地，而记录bb的上海为生产地，通过这种方式在实际应用中，可以进一步减少表6中不同业务公用属性字段的数量。

需要说明的是，第一数据库、第二数据库、第三数据库、第四数据库和第五数据库只是为了区分不同的数据库，并不是指构建这些数据库的时间上有先后顺序，也不代表数据库重要性的区别，也不代表气的一些含义。特别的，这里的第三数据库在实际应用中其实可以和步骤S12中的第四数据库进行整合，也就是说第三数据库和第四数据库可以为同一个数据库。例如，该数据库的形式可以为表8的形式。

表8、实际应用中的一种第三(第四)数据库

实际应用中第三(第四)数据库的形式还可以为其它。当然，实际应用中还可以，通过所述第二数据库中的所述业务标识字段关联第三数据库，然后通过所述第三数据库关联第六数据库来确定各所述业务公用属性在对应业务中所对应的业务属性。这样，在需要对业务属性进行进一步描述的时候，可以采用这种实施方式。当然在实际应用中，这里的第六数据库和上面步骤S12中提到的第四数据库也可以为同一个数据库。

另外这里还需要对第二数据库做进一步的说明，在实际应用中，为了增加第二数据库的安全性能，还可以将第二数据库中的每条记录进行加密，然后在第二数据库中增加加密属性字段，用于存储每条记录加密后对应的结果，通常进行加密的方式可以为md5等方式。这样第二数据库的就可以包括记录标识字段、至少一个业务公用属性字段以及加密属性字段等。

优选的，在实际应用中，还可以将记录标识字段和加密属性字段组成第六数据库，通过将第六数据库和第一数据库关联，以及第六数据库和第二数据库关联，这样第一数据库和第二数据库可以通过第六数据库进行关联，而不是直接关联。在将第一数据库和第二数据库通过第六数据库进行关联后，由于第六数据库的数据进行了加密，这样可以进一步加强数据的安全性。并且，第六数据库相比较于第二数据库字段较少，占用存储空间少，实际应用中可以将第六数据库存储在分布式缓存中，这样可以在需要通过第一数据库获取第二数据库的数据时，加快获取的速度。

需要说明的是，实施例1所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法的各步骤也可以由不同设备作为执行主体。比如，步骤11和步骤12的执行主体可以为设备1；又比如，步骤11的执行主体可以为设备1，步骤12和的执行主体可以为设备2；等等。

以上是对本申请实施例提供的业务数据的存储方法的说明。为了便于理解该方法，这里还可以列举一种实际应用场景，对该应用场景下实施该方法进行说明。该应用场景为用户使用互联网进行购物的业务时，对该业务的业务数据进行存储。通过结合表9、表10表11和表12，在该业务场景中业务标识为商品代码(表9中的product_code字段)，业务用户标识为用户ID(表9中的principal_id字段)，业务自定义属性字段为表9中的Var1字段和Var2字段，关联字段为表9中的proddata_ID字段，记录标识字段为表10中的ID_1，第二业务标识字段为表10中的Sproduct_code字段，加密属性字段为表10中的Md5_property字段，通过Sproduct_code字段的属性字段值promo_A_01关联到表11中的Tproduct_code字段(第三业务标识字段)，在表11中Property_dict_ID字段与表12的ID_3关联，从而在表12中可以确定业务属性(Property)，以及对各个业务属性的描述信息(description)。另外，在表11中还有类型字段(Type)字段和索引字段(IndexFlag)，可以用于根据实际需要实现新的功能。

业务公用属性为商品生产地、商品销售地和支付渠道，业务自定义属性为银行卡号、商店ID

表9、实际网购应用场景下的第一数据库

principal_id	product_code	proddata_ID	Var1	Var2
					principal1	promo_A_01	1001	XX	YY

表10、实际网购应用场景下的第二数据库

表11、实际网购应用场景下的第三数据库

ID_2	Property_key	Property_ID	Type	IndexFlag	Tproduct_code
						1	Key1	1	1	1	promo_A_01
2	Key2	2	1	1	promo_A_01
						3	Key3	n	1	0	promo_A_01
4	Var1	3	2	2	promo_A_01
						5	Var2	4	2	1	promo_A_01
……	……	……	……	……	……

表12、实际网购应用场景下的第四数据库

下面将具体描述在该应用场景下，实施该业务数据的存储方法的步骤：

步骤S31：接收业务数据。

所述业务数据包括principal1(商品代码)、promo_A_01(用户ID)以及北京(商品生产地)、上海(商品销售地)、工商银行存储卡(支付渠道)，XX(银行卡号)、YY(商店ID)。

步骤S32：将principal1、promo_A_01、XX、YY作为第一记录存储在表9的对应字段中。

步骤S33：确定商品生产地为北京、商品销售地为上海、支付渠道为工商银行存储卡是否存表10的一条记录中，当存在时执行步骤S34，当不存在时，执行步骤S35。

步骤S34：建立ID_1的属性字段值(1001)和proddata_ID的属性字段值(1001)的关联关系。

在需要获取这些业务数据是，可以通过表10中的Sproduct_code关联到表11的Tproduct_code，在表11中查询发现Key1在表12中的Property_ID的属性字段值为1，通过表12查询Key1的业务属性为商品生产地，也就是说表10中Key1的属性字段值为北京，指的是商品生产地为北京。其它的Key2、Key3、Var1和Var2可以通过相同的方法查询。

步骤S35：将商品生产地为北京、商品销售地为上海、支付渠道为工商银行存储卡作为第三记录存储在第二数据库，并将所述第三记录和所述第一记录建立关联关系。

当商品生产地为北京、商品销售地为上海、支付渠道为工商银行存储卡在表10的通一条记录中存在时，只需要将该记录与第一记录进行关联即可，而不需要在此在表10中进行存储。这样能够减少数据的冗余，从而降低存储资源的消耗。

实施例2

实施例2提供了一种创建业务数据库的方法，用于解决现有技术的业务数据存储方式，造成数据冗余，导致消耗更多存储资源的问题。该方法的具体流程示意图如图2所示，包括下述步骤：

步骤S41：创建空白数据表。

在实际应用中，创建空白数据表的方法有很多，创建的空白数据表的格式也可以有很多，这里并不对此做出限定。

步骤S42：在所述数据表中构建记录标识字段以及至少一个业务公用属性字段。

各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识，所述业务公用属性的属性枚举值的数量小于预设数量。

该数据表中包含记录标识字段和至少一个业务公用属相字段。通常来说，业务数据作为一条记录存储在数据库时，为了便于管理，可以给每条不同的记录分配一个记录标识，记录标识字段用于存储该记录标识，该记录标识用于唯一表示每条记录。通常来说向每条记录分配记录标识的方式有很多种，例如可以按数字(或字母)顺序进行编号，也可以随机生成数字字母组合，这里不对记录标识的形式做限定。

在用户使用某个业务的过程中，该业务通常会包括多个业务属性，业务公用属性是指属性值的枚举值的数量小于预设数量的业务属性。通常来说可以根据实际需要来设置枚举数量。

步骤S43：将所述数据表作为业务数据库，用以存储业务数据中各业务公用属性对应的属性值。

所述业务数据至少包括一个所述业务公用属性对应的属性值。

这里所说的至少一个业务公用属性的属性值是指有一个或者多个业务公用属性的属性值，并且当有多个业务公用属性的属性值时，这些不同的业务公用属性的属性值属于不同的业务共用属性。例如，业务数据中有两个业务公用属性的属性值分别为上海和工商银行，其中上海属于业务共用属性城市的属性值，工商银行属于业务共用属性支付渠道的属性值，也就是说上海和工商银行为不同的业务共用属性的属性值。

需要说明的是，在实际应用中，同一个企业能够提供的业务通常有限，并且具有相似性。因此企业为了便于管理业务数据，通常先确定出这些业务中的业务公用属性，然后将这些业务公用属性的属性值做笛卡尔积确定出一个业务数据库。这时候当用户使用该企业的某一个业务时，该业务的各个公用属性的所有属性值均存在与该数据库中，因此就可以不用在该数据库中添加新的记录。

因此一种优选的方案是，分别将各所述业务公用属性作为当前业务公用属性，固定所述当前业务公用属性之外的其它各业务公用属性的属性值，依次将所述当前业务公用属性的各个属性值作为当前属性值，并将所述当前属性值和当前业务公用属性之外的其它各业务公用属性的属性值记录在所述数据库中。

例如，某个手机生产商生产的多个型号的手机，这些手机屏幕尺寸和内存大小之分，其中屏幕尺寸分为3、4和5，内存分为8和16。这时候，该企业可以将屏幕尺寸和内存作为业务公用属性构建一个业务数据库，该业务数据库的形式如表13所示。

表13、实际应用中的一种业务数据库

记录标识字段	屏幕尺寸	内存
			1	3	8
2	3	16
			3	4	8
4	4	16
			5	5	8
6	5	16

在创建表13所述的数据库后，当产生业务数据时，只需要将记录标识字段，与业务数据中屏幕尺寸和内存之外的其它数据生成的字段进行关联即可，而不需要再将业务数据中的屏幕尺寸和内存进行重新存储。这样在业务数据达到一定的量级时，可以极大地减少业务数据由于存储造成的冗余，减少企业对存储资源的消耗。

采用实施例2提供的该方法创建数据库，该数据库在存储业务数据时，将该业务数据的各个业务公用属性的属性值作为一条记录进行存储，当其它业务数据进行存储时，可以根据其它业务数据各公用属性的属性值与数据库中的记录进行对比，当比对结果相同时，只需要将这条相同的记录与该业务数据中的其它数据建立索引。因此，解决了现有技术中的存储方式造成数据冗余的问题。

实施例3

实施例3提供了一种确定业务数据的方法。该方法的具体流程示意图如图3所示，包括下述步骤：

步骤S51：接收确定业务数据的请求。

所述业务数据包括业务用户标识、业务标识以及至少一个业务公用属性对应的属性值，所述业务公用属性的属性枚举值的数量小于预设数量。

这里所说的至少一个业务公用属性的属性值是指有一个或者多个业务公用属性的属性值，并且当有多个业务公用属性的属性值时，这些不同的业务公用属性的属性值属于不同的业务共用属性。例如，业务数据中有两个业务公用属性的属性值分别为上海和工商银行，其中上海属于业务共用属性城市的属性值，工商银行属于业务共用属性支付渠道的属性值，也就是说上海和工商银行为不同的业务共用属性的属性值。在实际应用中，所述业务公用属性具体为属性值的枚举值小于预设阈值的业务属性。

这里的业务用户标识、业务标识与实施例1的步骤S11中所提到的业务用户标识、业务标识相同。

步骤S52：根据所述请求获取第一数据库中的第一记录，用以确定所述业务用户标识和所述业务标识。

所述第一记录为所述第一数据库中记录有所述业务用户标识和所述业务标识的记录；所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储各业务数据的业务用户标识，所述业务标识字段用于存储各业务数据的业务标识。

在实际应用中，根据所述请求获取第一数据库中的第一记录的方式有多种，一种常用的方式是，通过设定条件查询第一数据库来确定所述第一记录。

步骤S53：通过所述第一记录关联到第二数据库中的第二记录，用以确定各所述业务公用属性的属性值。

所述第二记录为记录有各所述业务公用属性对应的属性值的记录。

通常来说第二数据库可以包括记录标识字段以及至少一个业务公用属性字段。该记录标识字段用于通过该记录标识字段的属性字段值与第一记录进行关联。

采用实施例3提供的该方法，在接收确定业务数据的请求后，通过在第一数据库中确定出第一记录，该第一记录的属性字段值包括业务用户标识和业务标识，并通过第一记录关联到第二数据库中的第二记录，从而确定各所述业务属性的属性值。由于第二记录并不需要通过重新存储，而只是和第一记录进行了关联，从而在业务数据存储时，相比于现有技术能够减少数据冗余。

实施例4

基于与实施例1相同的发明构思，实施例4提供了一种业务数据的存储装置。如图4所示，该装置60包括：接收单元601、第一记录存储单元602、判断单元603以及第二记录存储单元604，其中：

接收单元601，用于接收业务数据，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值，所述业务公用属性的属性枚举值的数量小于预设数量；

第一记录存储单元602，用于将所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中；

判断单元603，用于确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中；

第二记录存储单元604，用于当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一记录的关联关系。

采用本申请实施例4提供的该装置60，由于该装置与实施例1的方法具有相同的发明构思，因此能够取得实施例1相同的技术效果。另外，在实际应用中，实施例4的该装置60通过结合具体的硬件能够获得其它的技术效果。例如，将第二数据库放置在分布式缓存中，在判断单元603进行判断时，能够进一步更快地获取判断结果。

实施例5

基于与实施例2相同的发明构思，实施例5提供了一种创建业务数据库的装置。如图5所示，该装置70包括：数据表创建单元701、字段构建段元702和数据库形成单元703，其中：

数据表创建单元701，用于创建空白数据表；

字段构建段元702，用于在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识，所述业务公用属性的属性枚举值的数量小于预设数量；

数据库形成单元703，用于将所述数据表作为业务数据库，用以存储业务数据中各业务公用属性对应的属性值，所述业务数据至少包括一个所述业务公用属性对应的属性值。

通过本申请的实施例5提供的该装置70，由于与实施例2采用相同的发明构思，因此可以取得与实施例2相同的技术效果。另外，该装置70通过结合实际应用中的硬件设备，还可以取得其它的技术效果。例如，可以通过将该装置70结合计算机来自动化创建业务数据库。

实施例6

基于与实施例3相同的发明构思，实施例6提供了一种确定业务数据的装置。如图6所示，该装置80包括：接收单元801、获取单元802和关联单元803，其中：

接收单元801，用于接收确定业务数据的请求，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性对应的属性值，所述业务公用属性的属性枚举值的数量小于预设数量；

获取单元802，用于根据所述请求获取第一数据库中的第一记录，用以确定所述业务用户标识和所述业务标识，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储各业务数据的业务用户标识，所述业务标识字段用于存储各业务数据的业务标识；

关联单元803，用于通过所述第一记录关联到第二数据库中的第二记录，用以确定各所述业务公用属性的属性值，所述第二记录为记录有各所述业务公用属性对应的属性值的记录。

采用本申请实施例所提供的该装置80，由于该装置80的发明构思以实施例3相同，因此可以取得与实施例3相同的发明效果。在实际应用中，该装置80还可以通过结合具体的硬件设备，取得额外的技术效果。例如，将第一数据库和/或第二数据库存储在分布式缓存中时，可以更快的来确定业务数据。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其它数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其它类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其它内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其它光学存储、磁盒式磁带，磁带磁磁盘存储或其它磁性存储设备或任何其它非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (12)

1.一种业务数据的存储方法，其特征在于，包括：

接收业务数据，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值；其中，所述业务标识用于区别不同的业务，所述业务用户标识用于标识使用所述业务的用户；对所述业务的任一业务属性，若该业务属性的属性枚举值的数量小于预设数量，则将该业务属性作为业务公用属性；

将所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中；其中，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储业务用户标识，所述业务标识字段用于存储业务标识；

确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中，当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一数据库的所述第一记录之间的关联关系；

其中，所述第二数据库通过如下方法构建：

创建空白数据表；

在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识。

2.如权利要求1所述方法，其特征在于，所述第一数据库包括关联字段；则，所述建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一记录的关联关系具体包括：

建立所述第二记录中的记录标识字段的属性字段值和所述第一记录中的关联字段的属性字段值的关联关系。

3.如权利要求1所述方法，其特征在于，所述方法还包括：

在第二数据库中构建用于记录业务标识的业务标识字段；

通过所述第二数据库中的所述业务标识字段关联第三数据库，用以通过所述第三数据库确定各所述业务公用属性在对应业务中所对应的业务属性。

4.如权利要求1所述方法，其特征在于，所述业务数据还包括自定义属性的属性值，所述业务自定义属性的属性枚举值的数量大于或等于预设数量；则，

所述第一数据库还包括业务自定义属性字段，所述业务自定义属性字段用于在接收所述业务数据后，存储所述业务数据中所述业务自定义属性的属性值。

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

通过所述第一数据库中的所述业务标识字段关联第四数据库，用以通过所述第四数据库确定各所述业务自定义属性在对应业务中所对应的业务属性。

6.如权利要求1所述方法，其特征在于，所述方法还包括：

当不存在时，将各所述业务公用属性对应的属性值作为第三记录存储在第二数据库，并将所述第三记录和所述第一记录建立关联关系。

7.一种创建业务数据库的方法，其特征在于，包括：

创建空白数据表；

在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识，所述业务公用属性的属性枚举值的数量小于预设数量；

将所述数据表作为业务数据库，用以存储业务数据中各业务公用属性对应的属性值，所述业务数据至少包括一个所述业务公用属性对应的属性值；

当接收到业务数据时，确定业务数据的各所述业务公用属性的属性值是否存在于第二数据库的一条记录中，当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与第一数据库的第一记录之间的关联关系；

其中，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值，所述业务标识用于区别不同的业务，所述业务用户标识用于标识使用所述业务的用户；所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储业务数据的业务用户标识，所述业务标识字段用于存储业务数据的业务标识，所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中。

8.如权利要求7所述方法，其特征在于，所述方法还包括：分别将各所述业务公用属性作为当前业务公用属性，固定所述当前业务公用属性之外的其它各业务公用属性的属性值，依次将所述当前业务公用属性的各个属性值作为当前属性值，并将所述当前属性值和当前业务公用属性之外的其它各业务公用属性的属性值记录在所述数据库中。

9.一种确定业务数据的方法，其特征在于，包括：

接收确定业务数据的请求，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性对应的属性值；其中，所述业务标识用于区别不同的业务，所述业务用户标识用于标识使用所述业务的用户；对所述业务的任一业务属性，若该业务属性的属性枚举值的数量小于预设数量，则将该业务属性作为业务公用属性；

根据所述请求获取第一数据库中的第一记录，用以确定所述业务用户标识和所述业务标识，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储各业务数据的业务用户标识，所述业务标识字段用于存储各业务数据的业务标识；

通过所述第一记录关联到第二数据库中的第二记录，用以确定各所述业务公用属性的属性值，所述第二记录为记录有各所述业务公用属性对应的属性值的记录；

其中，所述第二数据库通过如下方法构建：

创建空白数据表；

在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识。

10.一种业务数据的存储装置，其特征在于，包括：接收单元、第一记录存储单元、判断单元以及第二记录存储单元，其中：

接收单元，用于接收业务数据，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值；其中，所述业务标识用于区别不同的业务，所述业务用户标识用于标识使用所述业务的用户；对所述业务的任一业务属性，若该业务属性的属性枚举值的数量小于预设数量，则将该业务属性作为业务公用属性；

第一记录存储单元，用于将所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中；其中，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储业务用户标识，所述业务标识字段用于存储业务标识；

判断单元，用于确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中；

第二记录存储单元，用于当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一数据库的所述第一记录之间的关联关系；

所述装置还包括：

数据表创建单元、字段构建段元和数据库形成单元，其中：

数据表创建单元，用于创建空白数据表；

字段构建段元，用于在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识。

11.一种创建业务数据库的装置，其特征在于，包括：数据表创建单元、字段构建段元和数据库形成单元，其中：

数据表创建单元，用于创建空白数据表；

字段构建段元，用于在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识，所述业务公用属性的属性枚举值的数量小于预设数量；

数据库形成单元，用于将所述数据表作为业务数据库，用以存储业务数据中各业务公用属性对应的属性值，所述业务数据至少包括一个所述业务公用属性对应的属性值；

所述装置还包括：

接收单元，用于接收业务数据，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性的属性值；其中，所述业务标识用于区别不同的业务，所述业务用户标识用于标识使用所述业务的用户；

第一记录存储单元，用于将所述业务数据的业务用户标识和业务标识作为第一记录存储于第一数据库中；其中，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储业务用户标识，所述业务标识字段用于存储业务标识；

判断单元，用于确定各所述业务公用属性的属性值是否存在于第二数据库的一条记录中；

第二记录存储单元，用于当存在时，建立所述第二数据库中存储有各所述业务公用属性的属性值的第二记录与所述第一数据库的所述第一记录之间的关联关系。

12.一种确定业务数据的装置，其特征在于，包括：接收单元、获取单元和关联单元，其中：

接收单元，用于接收确定业务数据的请求，所述业务数据包括业务标识、业务用户标识以及至少一个业务公用属性对应的属性值；其中，所述业务标识用于区别不同的业务，所述业务用户标识用于标识使用所述业务的用户；对所述业务的任一业务属性，若该业务属性的属性枚举值的数量小于预设数量，则将该业务属性作为业务公用属性；

获取单元，用于根据所述请求获取第一数据库中的第一记录，用以确定所述业务用户标识和所述业务标识，所述第一数据库包括业务用户标识字段和业务标识字段，所述业务用户标识字段用于存储各业务数据的业务用户标识，所述业务标识字段用于存储各业务数据的业务标识；

关联单元，用于通过所述第一记录关联到第二数据库中的第二记录，用以确定各所述业务公用属性的属性值，所述第二记录为记录有各所述业务公用属性对应的属性值的记录；

所述装置还包括：

数据表创建单元、字段构建段元和数据库形成单元，其中：

数据表创建单元，用于创建空白数据表；

字段构建段元，用于在所述数据表中构建记录标识字段以及至少一个业务公用属性字段，各所述业务公用属性字段用于记录对应的业务公用属性的属性值，所述记录标识字段用于记录所述数据表中各条记录的标识。

Images