物流资源协同关系信息处理方法及装置

摘要

本申请实施例公开了物流资源协同关系信息处理方法及装置，其中，一种物流资源协同关系信息处理方法，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；所述方法包括：提供已定义的协同关系类型信息；接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。通过本申请实施例，能够提高系统的可扩展性。

说明书

技术领域

本申请涉及物流信息处理技术领域，特别是涉及物流资源协同关系信息处理方法及装置。

背景技术

随着电子商务交易平台的不断完善，以及传统通信、移动通信等技术的快速发展，越来越多的人们通过网上购物的方式来获取自己所需的商品，商品的种类可以涉及到人们日常生活的方方面面，其中包括家用电器、家具等类目的商品。对于这类商品而言，由于具有体积大、重量大、易损坏等特点，如何进行商品的仓储以及配送是一个关键性的问题。

为了提高消费者对大家电等商品的购物体验，有些电商平台的电器城商家可以将大家电商品入驻到平台提供的仓库(例如第二类型仓库资源，也就是大家电仓库，每个仓库都有自己的配送覆盖范围)，平台提供的仓库一般包括分布在不同物理位置的多个仓库，例如，北京仓、杭州仓、上海仓，等等。另外，商家还可能有自己的物流资源，例如，自建的仓库等等，一个商家可能会同时使用平台提供的仓库以及自己的仓库(为便于描述，将平台提供的仓库称为“第二类型仓库资源”，将商家自己的仓库称为“第一类型仓库资源”)，等等。

为了帮助商家合理的在体系内管理库存(包括商品的入库、补货、铺货等问题)，有些交易平台会引入平台供应链，涉及从销售预测开始到采购计划、到入库计划、到调拨计划、到完成最后的计划执行，等等。其中的多方协同会比较复杂，例如，某个供货商某个商品在各个第二类型仓库资源之间的分配比例关系、某个供货商某个商品在第二类型仓库资源某个仓库内的使用面积、某个供货商跟另外一个供货商在某个第二类型仓库资源中的竞争关系，等等。但是，计划又是通过一系列复杂的协同关系确定出来的，这些错综复杂的协同，给系统设计带来了复杂性。

例如，商家在针对某商品选择了深圳仓以及东莞仓之后，一般会根据预先制定的在各地的销售计划，向在各个仓进行备货。但深圳仓与东莞仓之间还具有一定的协同关系：东莞距离深圳较近，东莞仓在一天之内就可以完成向深圳仓的补货，因此，如果能够将这种关系的仓库资源更合理的利用，将会提高资源的利用率，也避免出现某仓库由于过量补货而导致的库存积压等问题。

为此，平台供应链需要为商家提供计划协同方案，计划协同的本质根据基础数据和多方协同规则去形成一份最终执行的计划的过程。但是，每个业务场景都会有自己的基础数据和多方协同的规则。例如：

业务场景1：针对C2B(消费者对企业，一般式先有消费者需求产生而后有企业生产)期货预售订单下沉供应链方案。

(1)基础数据包括：C2B的期货定金订单、商品的第二类型仓库资源的库存分布等。

(2)协同关系包括：第二类型仓库资源之间下沉关系(如从A仓下沉到B仓)、该供货商在第二类型仓库资源可使用的库容面积、该供货商的该商品在第二类型仓库资源的库存比例等。

业务场景2：制定的多级仓供应链方案。

(1)基础数据包括：销售预测数据、当前库存在各种的分布数据等；

(2)协同关系包括：某个商品在某两个仓之间的分配比例关系、该供货商在第二类型仓库资源可使用的库容面积、该供货商的该商品在第二类型仓库资源的库存比例等等。

现有技术中，通过为每种业务独立开发一套计划协同方案来支持业务的发展，每一套计划协同逻辑中涵盖了对应业务的基础数据和协同方案。但是，现实的供应链协同中充斥着各种协同关系，例如cdc仓与dc仓存在着调拨关系，商家入仓时与日日顺的收货能力存在协同关系，某个区域如果我们限制某个类目的商品在某个销售时间区间不允许过度铺货，那么商家在某个区域的某个类目的铺货又存在竞争关系，等等。有些协同关系现在已经清楚，但是有更多的协同关系暂时无法预知。因此，现有技术的做法是：每发现一种协同关系，建立一个数据表进行存储。在平台供应链的早期，业务种类少，现有的方案是合理的。但随着供应链业务场景的不断发展，各种供应链场景不断增多，供应链中的协同关系也越来越复杂，现有的方案的不足也逐渐暴露出来。

例如，为每种业务独立开发计划协同方案的方式研发周期长，维护成本高，资源浪费严重，难以支撑业务的快速发展。当若干业务并行发展时，这种缺陷就更加显而易见。

再者，业务演进过程中，可能不断变更的业务需求，对系统变更的挑战，现有方案中一旦某种计划协同方案部署完毕则难以扩展，需要修改源码后重新部署，因此，这种模式难以满足业务的进化需求。

另外，对于还未发生的可以预见协同关系无法快速表达，在业务需求发生时需要重新建立数据库表进行代码开发，因此效率低下。

总之，如何降低平台供应链计划系统开发和维护成本，支持业务的快速发展，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了物流资源协同关系信息处理方法及装置，能够提高系统的可扩展性。

本申请提供了如下方案：

一种物流资源协同关系信息处理方法，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；

所述方法包括：

提供已定义的协同关系类型信息；

接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。

一种物流资源协同关系信息处理装置，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；

所述装置包括：

类型信息提供单元，用于提供已定义的协同关系类型信息；

接收单元，用于接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，可以构建一个基于元数据的可配置的模型，在产生新的需求时，只需要按照模型添加新的定义，可以快速承载平台供应链中计划协同所需要的各种因素，基础代码部分则不需要修改，也不需要发表新的程序，因此提高了系统的可扩展性。并且，也能够支持复杂协同关系的表达。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的索引模型示意图；

图3是本申请实施例提供的另一索引模型示意图；

图4是本申请实施例提供的再一索引模型示意图；

图5是本申请实施例提供的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在传统的供应链协同计划系统中，是针对各种协同场景，每产生一个需求，就进行一次编程实现，然后发表程序，而在本申请实施例中，旨在构建一个基于元数据的可配置的模型，在产生新的需求时，只需要按照模型添加新的定义，基础代码部分则不需要修改，也不需要发表新的程序。

基于上述考虑，在具体实现时，本申请实施例中的平台供应链计划系统的核心领域模型可以构建为：

供应链协同计划＝协同流程+协同基础数据+协同关系+协同规则

因此，只要能够抓住构建供应链协同计划的各个子要素的本质，进行抽象建模，建立一套稳定的可扩展的模型，那么就可以基于这套模型“以不变应万变”，灵活表达各种供应链协同场景。

在上述模型中，关于协同流程表达，业界已经有了各种成熟的流程产品，例如，可以采用TbBpm来实现流程建模，等等。关于协同基础数据表达，现有技术也有了成熟的资源中心来支撑，协同规则部分有成熟的规则引擎，因此本申请实施例的重点在于如何为协同关系进行建模。

也就是说，在本申请实施例中，是针对供应链协同这个场景，抽象出来一套模型，这个模型可以通过数据初始化进行扩展，以一种一致的方式来表达各种协同关系。这样当有新的需求时，只需要在现有的软件中，进行元数据的扩展，而不需要进行新的代码编写，便可以支撑一种新的协同关系。

从产品层面而言，本申请实施例可以构建一个具有可扩展性的平台供应链计划系统，其中，协同关系表达是这个系统的一个核心模块。对于商家来说，看到的是一个在线的系统，这个系统内置了很多种协同关系的表达，商家可以根据自己的需求、商品的特点等，对其中的协同关系进行实例化。进而，这些实例化数据，就可以用作各种计划执行引擎的执行依据，被计划执行引擎检索使用，并为计划执行引擎的决策提供数据支持。

其中，关于协同关系建模，在本申请实施例中，首先可以抽象出如下几种关键要素：

(1)协同关系类型：可以理解为协同上下文，多个供应链的参与者为什么要协同，要解决一个什么样的业务问题。例如：多个供货商都需要使用某个仓库，但是仓库可用面积一定，因此多个供货商就某个仓库的使用存在竞争关系，这便是一种协同关系。在定义协同关系类型时，可以为每种类型的协同关系取一个名字，通过这个名字来标识该种协同关系，如前述例子中的协同关系，可以取名为：“仓面积竞争协同”，这便是一种协同关系类型。

(2)协同主体类型：既然谈到协同，那么很显然协同关系的参与者必然要多于一种，这里谈到的协同参与者不一定是人，可能是其它的可协调的元素。当然，协同参与者未必都是协同主体，例如：现实中的一个仓，可以根据sku(Stock Keeping Unit，库存量单位)不同，选择不同的配送公司，存在一种仓配协同关系，在这个场景里，仓和sku作为协同主体，而配送公司就不是协同主体，因为现实需求为：给出仓和sku找出采用哪个配送公司来配送，显然仓和sku一定的情况下，配送公司是可能随着商务合作关系进行改变的。因此，判断一个协同关系的参与者中谁是协同主体的方法可以为：用来定位协同关系的协同参与者为协同主体，否则就不是协同主体。

(3)协同关系变量类型：关系变量表达了在协同场景下，协同主体与协同参与者(非主体)就什么进行协同，也就是协同的内容。仍然以上面的面积竞争协同为例，仓的面积表达了协同者之间就什么进行协同，因此仓面积就是协同关系变量。之所以称为变量，是因为它并非定值，不同的仓库能够供商家使用的面积是不同的，同一个仓，在不同时间段，能够提供的使用面积也是不同的，因此仓库可用面积为协同关系变量。

这样，各种协同关系都可以通过上述几种关键要素的组合进行表达，这就是协同关系的本质，因此，上述关键要素就可以作为各种协同关系的元数据。在抽象出上述元数据之后，就可以用于表达各种协同关系。其中，系统支持多少种协同关系可以是由程序员也就是系统的设计者来进行配置的，这个数据的初始化可以定义为设计期或者定义期，然后每个商家可以基于已经定义好的协同关系在进行数据的实例化。以配比协同关系为例：系统的开发者基于模型定义了第一类型仓库资源与第二类型仓库资源就某个商品的库存分配存在配比关系，但是具体是哪个商家、哪个第二类型仓库资源、哪个商品，在这个阶段是不知道的，接下来就可以进行实例化，每个商家都可以根据自己的商品设置在不同的第一类型仓库资源与第二类型仓库资源之间的配比关系。

也就是说，可以将协同关系的表达分为两个阶段：定义阶段与实例化阶段。在定义阶段，可以从类型的级别描述协同关系，以仓配协同为例，此时只指出了仓与配存在协同关系，但是具体是哪个仓与哪个配有协同关系，在定义阶段并没有体现，这个需要在实例化阶段完成。

其中，关于协同关系的定义阶段，可以有多种实现方式，例如，在一种实现方式下，可以通过四个数据库表进行建模(因为协同主体类型可能在多个协同关系定义中多次出现，因此将协同主体类型单独建模)，分别称为第一数据库表、第二数据库表、第三数据库表以及第四数据库表，其中，第一数据库表用于定义协同关系类型信息，第二数据库表用于定义协同主体类型信息，第三数据库表用于定义各协同关系类型关联的关系变量类型信息，第四数据库表用于定义各协同关系类型关联的协同主体类型信息。例如，第一数据库表的结构可以如以下表1所示：

表1

该第一数据库表中，条目的数量是由定义的协同关系的数量决定的，一般情况下，定义了多少种协同关系，该第一数据库表中就会保存多少个条目，当需要新增一种协同关系时，该第一数据库表中就会新增一个条目，用于描述该新增的系统关系的类型信息。在上述表1中，协同关系类型信息可以由关系类型ID以及关系类型名称等来表达。当然，在实际应用中，协同关系类型信息也可以通过其他方式表达。

第二数据库表的结构可以如以下表2所示：

表2

由于在一个系统中，协同主体的数量一般是有限并且固定的，同一协同主体可能会出现在不同类型的协同关系中，因此，该第二数据库表是一个全局的表，可以对各种可能的执行主体罗列在该第二数据库表中，在定义具体的协同关系时，可以通过引用该第二数据库表中的记录来表达具体的协同主体。在上述表2中，协同主体类型信息可以由主体类型ID以及主体类型名称等来表达。当然，在实际应用中，协同主体类型信息也可以通过其他方式表达。

第三数据库表的结构可以如以下表3所示：

表3

每定义一种类型的协同关系，如果该协同关系需要用到某变量，就可以在该第二数据库表中添加新的条目，其中，一种协同关系可能会使用一个或多个变量，因此，一种协同关系在该第二数据库表中可能会对应一个或多个条目。例如，在上述表3中，关系类型ID为1的协同关系，对应着名称为1、2的两个关系变量。关于第三数据库表中的关系变量类型信息，如表3所示，可以包括变量类型ID以及变量类型名称等，类似的，在实际应用中，关系变量类型信息也可以通过其他方式表达。

第三数据库表的结构可以如以下表4所示：

表4

在第二数据库表中建立的协同主体为全局的协同关系主体，因此还可以要将协同主体与具体的协同关系建立关联。与第三数据库表类似，每定义一种类型的协同关系，都可以在第四数据库表中添加新的条目，用于描述该协同关系的协同主体，其中，一种协同关系一般会涉及到多种协同主体，因此，在第四数据库表中，同一种协同关系可能会对应多个数据条目，分别用于描述该协同关系中的各种协同主体。例如，在上表4中表达的含义为：在协同关系类型id＝1的协同关系上下文中，有协同主体id＝1，2，3的三个协同主体参与。

另外，如表4所示，第四数据库表中的协同主体类型信息可以通过引用第二数据库表中的主体类型ID的形式表示，协同关系类型信息可以通过引用第一数据库表彰的关系类型ID的形式来表示。另外，该第四数据库表中还可以定义出同一种协同关系下，各种协同主体的检索顺序，以用于后续索引模型的建立，关于这部分内容，在后文中会有详细介绍。

为了更清晰的理解上述协同关系定义过程，下面以协同配比关系为例进行介绍。

协同配比关系的业务背景：为了实现对货品的强管控，大家电体系采用统仓统配模式，即前端可销库存与后端第二类型仓库资源实物库存绑定，在商家货品没有入第二类型仓库资源之前，前端显示不可销售。但有部分大的商家，在线下有着强大的仓资源，且商家部分仓离第二类型仓库资源比较近，补货周期大约在1-2天，因此一种可行的货品管控方式是针对这类大商家的部分区域，部分货物放到自己的第一类型仓库资源销售，这样对部分非畅销商品商家就可以对第二类型仓库资源补充少于销售预测的库存，既可保证不缺货，又能避免因为对第二类型仓库资源补过量的货，造成库存积压。以上业务需求产生了一种商品铺货的配比关系，在实际进行供应链协同计算时，就可以首先在系统中定义出这种协同关系。

具体的定义过程如下：

第一步，在第一数据库表中注册这种协同关系，如以下表5所示：

表5

第二步，在第三数据库表中定义协同关系变量，在该协同关系中，关系变量类型包括第一类型仓库资源对第二类型仓库资源的销量占比，如以下表6所示：

表6

第三步：在第四数据库表中将协同主体与协同关系建立关联，在该协同关系中，关联的协同主体类型包括：供应商、第一类型仓库资源、第二类型仓库资源、货品，如以下表7所示：

表7

以上是根据业务需求，抽象定义了一种配比关系，该定义过程即描述为定义阶段，因此上述的定义只从类型的角度定义协同关系，之后就可以进入协同关系的实例化阶段，以及后续的建立索引的阶段。

参见图1，本申请实施例提供了一种物流资源协同关系信息处理方法，该方法可以包括以下步骤：

S101：提供已定义的协同关系类型信息；

在定义了各种协同关系之后，可以将定义好的各种协同关系信息通过在线系统进行公布，例如，可以将各种协同关系的名称等信息，通过列表等形式展示在用户界面中，并且还可以提供关于各种协同关系的作用等信息的描述。这样，商家可以通过查看各种协同关系类型信息，并结合自己的需求，选择其中某种或者某些协同关系进行实例化。

S102：接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值；

这里的用户主要是指商家用户或者卖家用户，为便于描述，本文中均描述为“商家”。商家在选中了某类型的协同关系后，系统可以将与该类型的协同关系关联的协同主体类型、关系变量类型提供给商家，例如，在如前述各数据库表进行协同关系的定义的情况下，系统可以根据该协同关系的类型，查询前述表3，确定出与该类型的协同关系关联的关系变量类型，查询前述表4以及表2，确定出与该类型的协同关系关联的协同主体类型，进而，商家就可以填入具体的实例化数据并提交，其中，实例化数据就包括关系变量值以及协同主体值。具体实现时，在接收到商家提交的实例化数据时，仍然可以通过数据库表的形式进行保存。

其中，在通过数据库表的形式保存实例化数据时，仍然可以将协同关系类型、协同主体值、关系变量值分别在不同的数据库表中保存。例如，可以提供第五数据库表，用于保存用户选中的目标协同关系的类型，提供第六数据库表，用于保存目标协同关系的主体类型标识及协同主体值，提供第七数据库表，保存目标协同关系的变量类型标识以及关系变量值。

为便于理解，下面结合具体的例子进行介绍。假设某商家选择了前述例子中的配比关系这一协同关系，则首先可以通过表8保存这一协同关系类型。

表8

随着商家对实例化数据的提交，上述表8中会保存多个条目，商家每选择一个类型的协同关系进行实例化时，该表8中就会新增一个条目。其中引用的协同关系类型id，是根据表1中的记录确定的，也就是说，第五数据库表中目标协同关系的类型通过引用所述第一数据库表中的关系类型ID的形式表示。

在商家为该选择的目标协同关系提交了协同主体值时，可以对该目标协同关系的协同主体进行实例化，具体可以在以下表9中进行保存：

表9

也就是说，供应商标识为GYS_01的货品HP_01，需要在第一类型仓库资源SJC_01与第二类型仓库资源RRSC_01之间，使用类型id为1的协同关系。其中，第六数据库表中的主体类型标识可以通过引用第二数据库表中的主体类型ID的形式表示，关系id引用的是第五关系表中的记录。

另外，还可以实例化协同关系变量，具体的，可以通过以下表10的形式进行保存：

表10

序列id协同关系id引用关系变量id引用关系变量值

(relation_id)(relation_var_id)(relation_var_value)1110.5

上述表10中给出关系变量的值为0.5表示，针对货品HP_01，在第一类型仓库资源与第二类型仓库资源的销售分配比例为各占50％。其中，第七数据库表中的变量类型标识可以通过引用所述第三数据库表中的变量类型ID的形式表示。

以上分别从定义期与实例化的角度，对现实的协同业务场景进行了建模，并通过数据库表的形式保存相应的值，完成了模型的实例化。在保存之后，系统中的各种执行引擎就可以通过检索这些实例化数据，来为具体的决策提供依据。其中，计划引擎可能会有多个，例如，包括基于C2B期货定金订单来决定商家的补货和调拨计划引擎、基于菜鸟仓体系给商家通用的物流解决方案的入库和调拨计划引擎、基于菜鸟仓体系和第一类型仓库资源体系的物流解决方案的计划引擎、基于第一类型仓库资源体系就近补货给菜鸟仓体系的计划引擎，等等。

S103：基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，并加载到缓存中，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，以便执行引擎在执行计划协同时，通过所述索引检索出实例化数据中的关系变量值。

为了便于各种执行引擎对协同关系定义以及实例化数据的使用，可以系统启动时和新建立一个协同关系保存后，将协同关系的定义以及实例化数据写入缓存中，这样，执行引擎就可以从缓存中读取具体的协同关系数据，而不必每次都进行数据库的读写操作，可以提高处理效率。

其中，将数据库表中的数据加载到缓存中的执行时间可能会有多种，例如，可以是在系统启动时加载，或者，还可以是在系统中新建一种协同关系时重新加载，等等。

为了能够方便执行引擎检索协同关系，本申请实施例在将协同关系数据加载到缓存的过程中，还可以将存储在数据库表里的协同关系表达，转换成基于key-value模式的存储表达，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，例如，检索模型可以如图2所示。这样，执行引擎在执行计划协同时，就可以通过这种索引检索出实例化数据中的关系变量值，进而为具体的执行提供依据。

其中，如果数据库表的结构如前文表1至表10所示，则具体在基于Key-Value模型建立目标协同关系对应的实例化数据的索引检索时，可以包括以下步骤：

步骤一：检索第五数据库表，确定目标协同关系的类型；

步骤二：根据目标协同关系的类型检索所述第六数据库表，确定目标协同关系对应的协同主体值；

步骤三：将目标协同关系的类型以及所述协同主体值组合为Key；

其中，如果第四数据库表中还定义了同一协同关系类型中，各协同主体类型的检索顺序信息，则该步骤三具体可以包括：

根据目标协同关系的类型，检索第四数据库表，确定该目标协同关系类型关联的各主体类型的检索顺序信息；

按照该检索顺序，将各个协同主体值进行排序；

将目标协同关系的类型以及排序后的协同主体值组合为Key

例如，在前述表7中，各主体类型id为1、2、3、4的协同主体，检索顺序分别为1、2、3、4，则在组合检索模型中的key时，就可以按照主体类型id为1、2、3、4的顺序进行排序。

步骤四：检索第七数据库表，确定目标协同关系对应的变量类型ID以及关系变量值；

步骤五：根据变量类型ID检索所述第三数据库表，确定该关系类型ID对应的变量类型名称；

步骤六：将变量类型名称与关系变量值组合为Value。

以上给出了基于数据库表存储的协同关系建立的KV检索模型，以及如何根据定义期与实例化期的数据，建立实际的检索映像，下面给出执行引擎的检索接口模型定义。

在按照如上方式建立了检索模型后，执行引擎在需要检索时，输入的信息可以包括：协同关系类型、协同主体名值对，这样，执行引擎得到的返回值为：List(列表)类型，列表里的每个元素为以协同关系变量key-value的map，列表中可能存在一个或者多个值，多个值的情况为一对多协同关系。

这样，在系统接收到一个检索请求之后，检索的过程就可以包括以下步骤：

步骤一：根据协同关系类型(relation_type)从第一数据库表查出协同关系类型id(relation_type_id)；

步骤二：根据relation_type_id从第四数据库表中检索出协同主体的值在检索中的排列顺序；

步骤三：根据输入的协同主体名值对和协同主体值在检索中的排列顺序，组合检索的key；

步骤四：基于组合出的key进行检索，并返回检索出相应的数据，数据为一个以协同关系变量为key，协同关系变量的值为value的map对。如果检索不出数据，说明输入的查询条件可能存在问题。

以上对协同关系的定义期、实例化期以及KV检索模型进行了介绍，下面将给出另外两组例子，来说明本申请实施例中的协同关系模型能够支撑更为复杂的模型场景。

例一：一对多协同关系

例如，可以是仓配协同关系，其中，一个仓库资源可以对应多个配送资源，每个配送资源有一个优先级(现实业务中可能还需要结合其它的业务规则来进行协同)，这里只给出如何基于模型定义出一对多的协同关系。

定义阶段：

步骤一：在第一数据库表中注册这种协同关系，如表11所示：

表11

步骤二：在第三数据库表中定义协同关系变量。由于在仓配协同关系中，一个仓库的货物可以由多个配送资源来配送，因此仓配协同关系为一对多，为了便于表达该一对多的关系，可以引入一个系统内置的协同变量：父协同关系(parent_relation_id)，具体进行实例化时，一个协同关系可以通过该变量指向另一个协同关系，这样便可以形成一个关系变量的列表。因此，关系变量类型包括配送资源编码、配送优先级、父协同关系标识，如表12所示：

表12

步骤三：在第四数据库表中将协同主体与协同关系类型建立关联。关联的协同主体类型包括仓库资源，如表13所示：

表13

需要说明的是，在上述协同类型定义中，关于仓配协同，作为协同关系参与者的配送资源并没有出现在协同主体中，因为实际的关系检索中的需要为：根据仓库资源找出这个仓库资源对应的配送资源，因此配送资源为协同配角，出现在协同关系变量的定义中。

实例化阶段：

步骤一：在第五数据表中定义一个协同关系类型的实例，如表14所示：

表14

步骤二：在第六数据库表中定义协同主体的具体实例化值，例子中给出的协同主体标识值在实际业务中，为各个基础数据的主键值，可能是无意义的自增长整型或者其它的数值定义。如表15所示：

表15

步骤三：在第七数据库表中定义关系变量的具体实例化值。具体的，可以设置一个第二类型仓库资源对应的配送资源，和实际选用这些配送资源的时候选择的优先级，如表16所示：

表16

通过上述表16中的第6行以及第9行可见，协同关系3通过父关系变量指向了协同关系2，协同关系4也通过父关系变量也指向了协同关系2，这也就意味着，协同关系2、3、4之间为父子关系，其中协同关系2为父协同关系，协同关系3、4为子协同关系。另外，通过第4行以及第7行可见，协同关系2的配送优先级为1，协同关系3的配送优先级为2，协同关系4的配送优先级为3。

后续在建立KV检索模型时，如果一个协同关系有parent_relation_id关系变量值，那么在构建自己的检索关系后，还要把构建形成的关系变量值加入到其父协同关系的对于的列表里。如图3所示，同时可以看出，一对多的协同关系中，多个协同关系的协同关系类型与协同主体是相同的，因此形成的协同KV映像里，key值的多少等同于协同主体的个数。

例二：序列协同关系

例如，不同仓库资源之间的调拨顺序关系。在仓库资源的网络调拨过程中，假定存在这种场景，某个货品的调拨线路为A仓—B仓—C仓，下面的例子将演示如何在协同关系模型中对这种关系进行表达。

定义阶段：

步骤一：在第一数据库表中注册这种协同关系，如表17所示：

表17

步骤二：在第三数据库表中定义协同关系变量，包括前置协同关系标识、后置协同关系标识、调拨源仓、调拨目的仓。如表18所示：

表18

步骤三：在第四数据库表中将协同主体与协同关系类型建立关联，协同主体包括供应商以及货品。如表19所示：

表19

本例中，以供应商和货品为协同主角，实际的需求为查询某个供应商的某个货品的调拨顺序。

实例化阶段：

步骤一：在第五数据表中定义一个协同关系类型的实例，如表20所示：

表20

步骤二：在第六数据库表中定义协同主体的具体实例化值，例子中给出的协同主体标识值在实际业务中，为各个基础数据的主键值，可能是无意义的自增长整型或者其它的数值定义。如表21所示：

表21

步骤三：在第七数据库表中定义关系变量的具体实例化值。如表22所示：

表22

以上实例化的数据表达了供应商GYS_01的货品HP_01的调拨路线为RRSC_01→RRSC_02→RRSC_03，构建的KV存储映像如图4所示。

与本申请实施例提供的物流资源协同关系信息处理方法相对应，本申请实施例还提供了一种物流资源协同关系信息处理装置，在该装置中，预先定义协同关系，所述协同关系由以下元数据表示：协同关系类型、关联的关系变量类型、关联的协同主体类型；所述关系变量用于表达协同的内容，所述协同主体为协同关系的参与者；

参见图5，所述装置可以包括：

类型信息提供单元501，用于提供已定义的协同关系类型信息；

接收单元502，用于接收用户选择的目标协同关系的类型，以及为目标协同关系提交的实例化数据，并以数据库表的形式进行保存；所述实例化数据包括关系变量值以及协同主体值。

具体实现时，该装置还可以包括：

索引建立单元，用于基于Key-Value模型建立所述目标协同关系对应的实例化数据的索引，并加载到缓存中，其中，通过组合目标协同关系的类型与关联的协同主体值建立Key，以关联的关系变量值为Value，以便执行引擎在执行计划协同时，通过所述索引检索出实例化数据中的关系变量值。

其中：

所述协同关系类型包括不同类型仓库资源之间的配比关系；

所述关系变量类型包括第一类型仓库资源对第二类型仓库资源的销量占比；

所述协同主体类型包括：供应商、第一类型仓库资源、第二类型仓库资源、货品。

所述协同关系类型包括仓库资源与配送资源之间的仓配协同关系；

所述关系变量类型包括配送资源编码、配送优先级、父协同关系标识；

所述协同主体类型包括仓库资源。

具体的，所述索引建立单元具体用于：

如果某目标协同关系的实例化数据中包含父协同关系标识，则将该目标协同关系关联的关系变量值，加入到其父协同关系关联的关系变量值列表中，以组合后的关系变量值列表为Key-Value模型中的Value。

其中：

所述协同关系类型包括不同仓库资源之间的调拨顺序关系；

所述关系变量类型包括前置协同关系标识、后置协同关系标识、调拨源仓、调拨目的仓；

所述协同主体类型包括供应商以及货品。

在协同关系定义阶段，所述装置还包括：

第一数据表提供单元，用于提供第一数据库表，所述第一数据库表用于定义协同关系类型信息；

第二数据表提供单元，用于提供第二数据库表，所述第二数据库表用于定义协同主体类型信息；

第三数据表提供单元，用于提供第三数据库表，所述第三数据库表用于定义各协同关系类型关联的关系变量类型信息；

第四数据表提供单元，用于提供第四数据库表，所述第四数据库表用于定义各协同关系类型关联的协同主体类型信息。

在协同关系实例化阶段，所述装置还包括：

第五数据表提供单元，用于提供第五数据库表，所述第五数据库表用于保存用户选中的目标协同关系的类型；

第六数据表提供单元，用于提供第六数据库表，所述第六数据库表用于保存目标协同关系的主体类型标识及协同主体值；

第七数据表提供单元，用于提供第七数据库表，所述第七数据库表用于保存目标协同关系的变量类型标识以及关系变量值。

其中，所述第一数据库表中的协同关系类型信息包括关系类型ID以及关系类型名称，所述第二数据库表中的协同主体类型信息包括主体类型ID以及主体类型名称，所述第三数据库表中的关系变量类型信息包括变量类型ID以及变量类型名称，所述第四数据库表中的协同主体类型信息通过引用所述第二数据库表中的主体类型ID的形式表示；

所述第五数据库表中目标协同关系的类型通过引用所述第一数据库表中的关系类型ID的形式表示；

所述第六数据库表中的主体类型标识通过引用所述第二数据库表中的主体类型ID的形式表示；

所述第七数据库表中的变量类型标识通过引用所述第三数据库表中的变量类型ID的形式表示。

所述索引建立单元包括：

类型确定子单元，用于检索所述第五数据库表，确定目标协同关系的类型；

协同主体值确定子单元，用于根据目标协同关系的类型检索所述第六数据库表，确定所述目标协同关系对应的协同主体值；

Key组合子单元，用于将所述目标协同关系的类型以及所述协同主体值组合为Key；

关系变量信息确定子单元，用于检索所述第七数据库表，确定目标协同关系对应的变量类型ID以及关系变量值；

变量类型名称确定子单元，用于根据所述变量类型ID检索所述第三数据库表，确定该关系类型ID对应的变量类型名称；

Value组合子单元，用于将所述变量类型名称与关系变量值组合为Value。

所述第四数据库表中还定义了同一协同关系类型中，各协同主体类型的检索顺序信息；所述Key组合子单元包括：

检索顺序确定子单元，用于根据所述目标协同关系的类型，检索所述第四数据库表，确定该目标协同关系类型关联的各主体类型的检索顺序信息；

排序子单元，用于按照所述检索顺序，将各个协同主体值进行排序；

组合子单元，用于将所述目标协同关系的类型以及排序后的协同主体值组合为Key。

另外，该装置还可以包括：

提取单元，用于接收到执行引擎的检索请求时，从所述检索请求中提取出协同关系类型以及协同主体名值对；

类型id确定单元，用于根据协同关系类型从所述第一数据库表检索出协同关系类型id；

顺序确定单元，用于根据协同关系类型id从所述第四数据库表中检索出协同主体的值在检索中的排列顺序；

检索Key确定单元，用于根据输入的协同主体名值对以及协同主体值在检索中的排列顺序，组合检索的key；

检索单元，用于基于组合出的key进行检索，并返回检索出相应的数据。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的物流资源协同关系信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。