数据处理方法、装置、电子设备及存储介质

技术领域

本申请涉及知识图谱领域，尤其涉及智能办公领域。

背景技术

大数据处理的便利性体现在方方面面，以智能办公的应用场景为例，办公环境日趋复杂，存在海量的数据待分析，比如，多个项目组的协同工作、每个项目组中的各职能部门及人员的分布、每个项目组所对接的兄弟智能部门及该项目组在办公环境的数据拓扑结构中所处的节点位置、该项目组的职能及人员更新等等这些数据海量存在，导致如何从海量的数据中获取到有价值的数据是重中之重，这对办公是否高效提供了数据基础，也就是说，如何通过大数据处理抽取到有价值的各类实体数据(如抽取得到人实体数据、事实体数据等)，以提高办公效率(示例性的，如何提高办公环境中“以事找人”或“以人找事”的搜索处理效率)是要解决的技术问题。

发明内容

本申请提供了一种数据处理方法、装置、电子设备及存储介质。

根据本申请的一方面，提供了一种数据处理方法，包括：

从多源数据中抽取第一类实体及小实体；

对所述小实体进行数据格式统一及合并处理，得到第二类实体；

建立所述第一类实体与所述第二类实体的关联结果；

响应数据搜索操作，根据所述关联结果得到与搜索操作关键词对应的目标实体数据。

根据本申请的另一方面，提供了一种数据处理装置，包括：

抽取模块，用于从多源数据中抽取第一类实体及小实体；

格式统一及合并模块，用于对所述小实体进行数据格式统一及合并处理，得到第二类实体；

关联建立模块，用于建立所述第一类实体与所述第二类实体的关联结果；

搜索模块，用于响应数据搜索操作，根据所述关联结果得到与搜索操作关键词对应的目标实体数据。

根据本申请的另一方面，提供了一种电子设备，包括：

至少一个处理器；以及

与该至少一个处理器通信连接的存储器；其中，

该存储器存储有可被该至少一个处理器执行的指令，该指令被该至少一个处理器执行，以使该至少一个处理器能够执行本申请任意一实施例所提供的方法。

根据本申请的另一方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，该计算机指令用于使该计算机执行本申请任意一项实施例所提供的方法。

采用本申请，可以从多源数据中抽取第一类实体及小实体，对小实体进行数据格式统一及合并处理，以得到第二类实体。可以建立第一类实体与第二类实体的关联结果，响应数据搜索操作，根据该关联结果得到与搜索操作关键词对应的目标实体数据。由于是从多源数据中抽取数据，数据的完整性得到保障，多源数据的准确性及有效性需要通过所建立的关联结果来保障，以便可以从海量的数据中抽取到有价值的各类实体数据，从而提高智能化办公场景下的办公效率。

应当理解，本部分所描述的内容并非旨在标识本申请的实施例的关键或重要特征，也不用于限制本申请的范围。本申请的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1是根据本申请实施例的数据处理方法的流程示意图；

图2是根据本申请实施例的知识图谱中第一类实体与第二类实体的示意图，

图3是根据本申请实施例的基于多源数据的人-事件构建的结构示意图；

图4是根据本申请实施例的小实体生成过程的流程示意图；

图5是根据本申请实施例的相关人标志获取过程的流程示意图；

图6是根据本申请实施例的小实体合并为事实体过程的流程示意图；

图7是根据本申请实施例的数据处理装置的组成结构示意图；

图8是用来实现本申请实施例的数据处理方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。本文中术语“第一”、“第二”表示指代多个类似的技术用语并对其进行区分，并不是限定顺序的意思，或者限定只有两个的意思，例如，第一特征和第二特征，是指代有两类/两个特征，第一特征可以为一个或多个，第二特征也可以为一个或多个。

另外，为了更好的说明本申请，在下文的具体实施方式中给出了众多的具体细节。本领域技术人员应当理解，没有某些具体细节，本申请同样可以实施。在一些实例中，对于本领域技术人员熟知的方法、手段、元件和电路未作详细描述，以便于凸显本申请的主旨。

随着公司规模的不断扩大和经营时间的不断累积，公司的员工信息、项目信息、行政信息等知识性文档的积累也越来越多。公司员工在进行工作协同的过程中，需要经常与其他业务线条的同事进行交流沟通，需要通过项目、业务等信息，寻找到对应的负责人。当前，公司内部的人员与事件的关系，往往分布在大量不同的数据文档中。每种类型的数据文档所能提供的事件信息也是比较片面的，往往需要通过多源数据(即来自于多个知识平台的数据文档)进行搜索结果的组合，才能对事件有一个全面的了解。

一方面，针对同一事件(项目、业务等)搜索场景为例，同一事件的相关信息可能分散在不同的知识平台中。当用户进行相关查询时，往往只能找到比较片面的信息。想要获取更全面的人—事件关系信息，就需要用户用事实体(如项目名)或者人实体(人名)去不同的知识平台去查询事件的相关人员进行搜索，导致搜索成本高，效率低。

另一方面，各知识平台对人—事件关系的组织形式各不相同，提供的搜索能力也不尽相同。有些结构化程度很低的知识文档中所蕴含的人—事件关系信息，很难被有效搜索到，导致搜索成本高，效率低。

本申请，通过从多源数据中抽取人实体、小实体及事实体，以建立人实体与事实体的关联结果(如人<—>事的关系)，以该关联结果为基础(即提供了人找事和以事找人能力的数据基础)去执行搜索操作，可以大大提高搜索速度，且降低了搜索成本。

根据本申请的实施例，提供了一种数据处理方法，图1是根据本申请实施例的数据处理方法的流程示意图，该方法可以应用于数据处理装置，例如，该装置可以部署于终端或服务器或其它处理设备执行的情况下，可以执行第一类实体及小实体的数据抽取、根据小实体得到第二类实体、基于第一类实体与第二类实体的关联结果执行搜索操作等等。其中，终端可以为用户设备(UE，User Equipment)、移动设备、蜂窝电话、无绳电话、个人数字处理(PDA，Personal Digital Assistant)、手持设备、计算设备、车载设备、可穿戴设备等。在一些可能的实现方式中，该方法还可以通过处理器调用存储器中存储的计算机可读指令的方式来实现。如图1所示，包括：

S101、从多源数据中抽取第一类实体及小实体。

一示例中，多源数据，不仅可以来自于多个知识平台，而且数据格式包括结构化数据类型及非结构化数据类型等多种数据结构。比如，所述多源数据包括：员工数据、平台数据、项目数据、接口人数据、wiki数据中的至少一种。

一示例中，第一类实体可以为人实体，小实体可以为用于生成第二类实体的中间数据。

S102、对所述小实体进行数据格式统一及合并处理，得到第二类实体。

一示例中，所述小实体来自于不同数据源，可能导致数据格式不统一，需要对该小实体的数据格式进行统一。小实体中来自于不同数据源，在不同数据源对同名小实体可能使用的名称不一样，因此，需要对这种同名小实体进行合并处理，得到第二类实体。

S103、建立所述第一类实体与所述第二类实体的关联结果。

一示例中，第一类实体可以为人实体，第二类实体可以为事实体，可以建立人实体与事实体的关联结果，从而得到以人<—>事的关系为基础的关系图谱(如知识图谱)。

S104、响应数据搜索操作，根据所述关联结果得到与搜索操作关键词对应的目标实体数据。

一示例中，在一个搜索场景中，可以建立第二类实体(如事实体)与第一类实体(如人实体)的关联结果，响应第一搜索操作，解析出所述第一搜索操作中的第一关键词包含所述第一类实体，根据所述关联结果，得到与所述第一类实体对应的第二类实体，从而实现了在搜索场景中的高效搜索处理，如一个网页页面或客户端界面等的搜索入口输入上述事实体(事实体用于表征事信息或事属性等)，得到与该事实体相关的人实体的搜索结果。

在另一个搜索场景中，还可以建立第二类实体(如事实体)与第一类实体(如人实体)的关联结果，响应第二搜索操作，解析出所述第二搜索操作中的第二关键词包含所述第二类实体，根据所述关联结果，得到与所述第二类实体对应的第一类实体，从而实现了在搜索场景中的高效搜索处理，如一个网页页面或客户端界面等的搜索入口输入上述人实体(人实体用于表征人员信息或人员属性等)，得到与该人实体相关的事实体的搜索结果。

上述第一搜索操作中的第一关键词(第一关键词包含第一类实体)，或者第二搜索操作中的第二关键词(第二关键词包含第二类实体)，可以是基于电子设备(如笔记本电脑或平板电脑等便携终端、如手机等移动终端)的操作界面输入的搜索词，具体的输入方式本实施例不做限定。

采用本申请，可以从多源数据中抽取第一类实体及小实体，对小实体进行数据格式统一及合并处理，以得到第二类实体。可以建立第一类实体与第二类实体的关联结果，响应数据搜索操作，根据该关联结果得到与搜索操作关键词对应的目标实体数据。由于是从多源数据中抽取数据，数据的完整性得到保障，多源数据的准确性及有效性需要通过所建立的关联结果来保障，以便可以从海量的数据中抽取到有价值的各类实体数据，从而提高智能化办公场景下的办公效率。

一示例中，就上述知识图谱而言，知识图谱中可以包括上述第一类实体(如人实体)以及第二类实体(如事实体)。其中，该人实体又可以分别包括人员姓名、岗位、职级等；事实体可以包括项目名称、项目属性等。可以根据关联结果在线更新该知识图谱，即更新知识图谱中人实体及事实体的关系，以完善该以“人<—>事”为核心的该知识图谱。

一示例中，就上述关联结果而言，上述关联结果为第一类实体以及第二类实体之间具备的关系(第一类实体与第二类实体之间的关系可以是负责、协同、参与等，这里不做限定)，也就是人实体和事实体之间的关系，从而基于该关联结果可以建立以“人<—>事”为核心的上述知识图谱，以基于该知识图谱及知识图谱更新后的数据在搜索场景中达到高效的“以事找人”或“以人找事”的目的，在复杂及多职能且不断更新的办公环境中大大提高了搜索处理效率，达到精准定位到要搜索的人或要搜索的事的技术效果，并最终构建了智能化的办公环境，大大提高了包括该搜索处理效率在内的办公效率。

图2是根据本申请实施例的知识图谱中第一类实体与第二类实体的示意图，如图2所示，第二类实体可以为项目A，第一类实体有2个分别为人员1和人员2；第一类实体与第二类实体之间的关系可以分别为负责和协同，比如，图2中项目A与人员1之间的关系为负责，项目A与人员2之间的关系为协同。另外，第一类实体还可以具备自身的属性信息，比如，图2中人员1具备的属性信息可以包括：姓名1、职级1、岗位1。当然，虽然图中未示出，但是第二类实体也可以具备自身的属性信息，比如可以是项目A的名称、部门名等等。基于图2所示的办公环境中人<—>事为核心的上述知识图谱中的一个示例性说明如下：

为了基于该知识图谱在搜索场景中达到高效的“以人找事”的目的，举例来说，假设第二关键词包含的第二类实体为“项目A”，也就是想要确定公司内部“项目A”项目的负责人时，可以通过知识图谱，以“项目A”的相关信息进行搜索，比如可以是“项目A”的实体名，和/或是项目A的发布时间信息等等。其中，第二关键词中可以包含一个或多个与第二类实体相关的字段。比如，可以是一个项目的项目名称，也可以是某个产品团队的团队名称，还可以是某项产品的平台型号，这里不做穷举。

一实施方式中，所述响应数据搜索操作，根据所述关联结果得到与搜索操作关键词对应的目标实体数据，包括：响应数据搜索操作，得到所述搜索操作关键词；所述搜索操作关键词包含所述第一类实体的情况下，根据所述关联结果得到对应所述第一类实体的目标第二类实体，将所述目标第二类实体作为所述目标实体数据；所述搜索操作关键词包含所述第二类实体的情况下，根据所述关联结果得到对应所述第二类实体的目标第一类实体，将所述目标第一类实体作为所述目标实体数据。

一实施方式中，所述从多源数据中抽取第一类实体及小实体，包括：从所述多源数据中抽取员工数据(如公司的全体员工信息列表，该列表是生成该第一类实体如人实体的数据来源)，根据所述员工数据及所述第一类实体对应的属性生成所述第一类实体。从所述多源数据中抽取所述第二类实体对应的名称及相匹配的别名，根据所述第二类实体对应的名称及相匹配的别名、及第二类实体对应的角色属性生成所述小实体。

一示例中，根据所述员工数据及所述第一类实体对应的属性生成所述第一类实体，可以包括：所述第一类实体为人实体的情况下，将所述员工数据映射到人实体对应的属性中。采用本实施方式，第一类实体，如人实体中除了相关事件属性外，其余属性都包含在了员工信息数据中(人实体的表格中，员工数据是属于人实体的，都包含在该员工信息数据中)。在人实体生成的过程中，直接将员工信息一一映射到人实体对应的属性中即可。

一示例中，还包括：将与所述人实体相关的事件属性增补到所述第一类实体中。由于相关事件属性不属于人实体的，是属于事实体的，为了后续在人实体与事实体间建立上述关联结果，因此，会在事件实体的挖掘过程中，使用事件与人的关系，以反边补充的形式将相关事件属性增补到第一类实体中。其中，所述与所述人实体相关的事件属性的获取方式，包括从已有关系图谱中查询第一类实体与第二类实体的关联结果，或者，从所述多源数据中实时挖掘所述第一类实体与第二类实体的关联结果。

一实施方式中，根据所述第二类实体对应的名称及相匹配的别名、及第二类实体对应的角色属性生成所述小实体，包括：从所述多源数据中抽取结构化数据类型(结构化数据类型的来源可以是项目数据、平台数据、接口人数据等)；根据所述结构化数据类型，得到第二类实体对应的名称及相匹配的别名，将所述第二类实体对应的名称及相匹配的别名，根据角色归一化标识映射到所述第二类实体对应的角色属性中。采用本实施方式，由于通过结构化数据类型，可以直接得到基本信息，如第二类实体对应的名称及相匹配的别名，因此，可以通过角色归一化标识(角色归一化标识是定义出每类角色的各种通用性标识方式，以基于该角色归一化标识映射到标准的角色属性中，达到统一该名称及别名到底具体对应啥角色的目的)直接映射到所述第二类实体对应的角色属性中。而且在角色归一化，比如技术负责人和研发负责人实际上同一个角色，可以采用角色归一化标识“techLeader”映射到同一个角色，并可以保留别名。

一实施方式中，还包括：从所述多源数据中抽取非结构化数据类型(非结构化数据类型的来源可以是wiki数据)；根据所述非结构化数据类型，得到用于表征所述第二类实体对应的名称及相匹配的别名的描述信息；根据所述描述信息，确定所述第二类实体对应的名称及相匹配的别名。采用本实施方式，由于无法直接得到上述第二类实体对应的名称及相匹配的别名，该描述信息只是对该上述第二类实体对应的名称及相匹配的别名的解释说明，因此，需要根据所述描述信息确定所述第二类实体对应的名称及相匹配的别名。

应用示例：

应用本申请实施例一处理流程包括如下内容：

本申请基于公司内部积累的各种知识数据，构建人<—>事为核心的关系，使得用户可以基于该人<—>事为核心的关系，实现高效、快速地进行以事找人、以人找事。基于多源数据的人与事件关系抽取包含以下三类数据：人实体，小实体及事件实体。图3是根据本申请实施例的基于多源数据的人-事件构建的结构示意图，如图3所示，员工数据可以作为生成人实体的数据来源，根据该员工数据可以得到人实体。产品数据、接口人数据、项目数据及除此之外的其他数据可以作为生成小实体的数据来源，根据产品数据、接口人数据、项目数据及除此之外的其他数据可以得到小实体。小实体作为生成事实体之前的中间处理数据，得到小实体后可以根据小实体生成事实体。

一示例中，公司内部所积累的知识数据，基本都是基于内部的各种知识平台进行组织和积累的。其中，有些会有比较好的运维，有着比较清晰的数据结构；但有些就会是一种无结构的文本数据积累。采用本应用示例，可以将结构化较好的知识源，进行数据格式的统一及合并处理，并最终形成更加完整的事件实体体系，并从无结构的文本数据中，进行一定的补充挖掘，进一步丰富事件体的内容。

一、生成人实体

可以采用人实体生成模块来实现，以完成对员工数据的实体化。人实体信息的来源，是公司的全体员工信息列表。在员工信息列表中，会包含员工姓名、邮箱、部门、工作账号等员工的基础信息。在生成人实体时，需要定义出人实体的schema结构如表1所示：

表1

其中，relatedEvent是人的相关事件，是一个列表。列表中的每一个列表项，都表示了人与某个事件的关系。relatedEvent的schema结构如表2所示：

表2

其中，actorId和actor是相互对应的枚举类型。其具体格式为：actorId\tactor。例如hrInterfaceUser->人力资源接口人，teachInterfaceUser->技术接口人等。在本申请中，人的角色包含35种不同的角色id和角色名，以便于表示不同人员在不同事件中的角色。

人实体中，除了相关事件属性外，其余属性都包含在了员工信息数据中。在人实体生成的过程中，需要将员工信息一一映射到人实体对应的属性中。相关事件属性，会在事件实体的挖掘过程中，使用事件与人的关系，进行反边补充。

二、生成小实体

可以采用小实体生成模块来实现，其主要功能是统一数据源的格式，保存实体的有效信息。由于各数据源所能够提供的信息各有不同，故小实体的schema，除了一些比较基础的公共属性外，根据数据源的不同，会有比较灵活的变化。小实体的生成，不仅会从结构化程度比较好的项目数据、平台数据等数据源抽取，还会从wiki等无结构化文本中，进行抽取和信息补充。

a)小实体schema

所有数据源所生成的小实体，都会包含名称、别名等信息。而不同的数据源，所包含的相关人的角色各有不同。故小实体的schema，包含公共的基础部分，还包含根据数据源进行定制的部分。小实体基础schema如表3所示：

表3

考虑到整理出来的人员角色有35中之多，并且需要保证后续可扩充引入其他数据源的扩展性，不可能完全使用人工的方式去定义每一类数据源所能抽取的相关人员角色。故采取人工整理角色映射表的方式，定义出每类角色的各种泛化性的标识方法，并映射到标准的角色表示中。这样，就可以通过修改映射表的方式，来影响实体生成策略过程中的相关人员角色的生成。角色归一映射表的格式为：actorId\t[泛化的角色名词]。例如，techLeader\t[技术负责人，研发负责人，技术总监，rd负责人，…]。

小实体额外属性的schema如表4所示：

表4

actorId是一个可变的值，根据数据源中所能提供的人员角色和映射表确定。其值是一个列表，列表中的每一项都是一个字典，包含了人的@id、name、email等可以标志其身份的值。

b)根据结构化的数据生成小实体

结构化数据，指的是某些比较细分的管理平台的数据，如项目数据、平台数据、接口人数据等。这类数据结构化程度高，结构清晰，属性含义准确，是小实体数据最主要的来源。从这些数据中抽取小实体，需要先进行基础属性的抽取，然后根据数据源所能提供的角色信息，配置好角色归一映射表。最后，抽取策略通过映射表，抽取对应的人员角色，并合并到对应的小实体中。例如，在处理接口人数据时，我们先观察接口人数据，其中可以提供rd接口人、pm接口人等角色信息。那么，就在归一映射表中配置如下信息：

teachInterfaceUser\t[rd接口人]

productInterfaceUser\t[pm接口人]

在生成了基础的实体属性后。策略会根据映射表中配置的信息，生成对应的角色属性和相关人的信息。

c)根据非结构化的数据生成小实体

非结构化数据主要指wiki数据。这里的知识主要是以文档的方式进行存储。除了文档名称、创建人信息、编辑人信息，其他的信息，都在正文中。但是正文大都是一些无结构的文本，想要抽取出有用的信息比较困难。因此。本方案从无结构化数据中，主要去抽小实体的解释，并根据编辑者，抽取出相关人员的信息。图4是根据本申请实施例的小实体生成过程的流程示意图，如图4所示，包括如下内容：

1)使用结构化抽取中的小实体名称，作为抽取的实体结合。

2)使用实体识别工具，从文档中，匹配出小实体。

3)根据模板词(是、定义)，抽取小实体的释义。

4)对于在文章title中匹配到的小实体名，将文章的编辑人，作为该小实体的相关人抽取出来，统一定义为参与人(participant)。

三、生成事实体

可以采用事实体生成模块来实现，其主要功能是合并小实体结果，抽出人<—>事为核心的关系的基础属性，以用于各个不同有相应数据需求的应用场景的应用层。

由于事实体需要提供给应用层使用，故其schema就应当尽可能简化，既需要保留完整的事件、相关人的信息，又不能使角色属性多而导致数据的属性数量不可控制。故在事件实体中，使用relatedPerson属性，来保存事件中所有的相关人员信息。事件实体的schema如表5所示：

表5

事件实体的relatedPerson是一个List结构，其中的每一个item即为一条相关人员记录。相关人员记录是一个字典，包含了相关人的基础信息，其结构如表6所示：

表6

在小实体生成过程中，为了保存尽可能多的关系信息，当只能获取相关人员的name信息时，也对关系进行了保留。在事件实体生成过程中，对于这些关系记录，需要明确指出，并确定这些相关人员的标志信息。这里，可以采用简单的部门投票方式进行人员标识进行确认。图5是根据本申请实施例的相关人标志获取过程的流程示意图，如图5所示，如果这个名字在人员实体中是唯一的，那么可以直接确定这个人的标志。如果不是，那么对于同个小实体的其他相关人员，获取他们的部门信息，然后从全量的人员实体中，通过部门限定，查找同名的人员。若最终只获取到了一个唯一的人实体，则将其标识补充进来；若不唯一，则直接舍弃。

对于不同数据源生成的同名小实体，在生成事件实体的时候，就需要进行合并处理。图6是根据本申请实施例的小实体合并为事实体过程的流程示意图，如图6所示，在执行该合并处理时，会根据事件的相关人员信息，来校验同名的小实体是否应当合并。当两个同名的小实体，拥有相同的相关人员数量，或者其相关人员所属部门有超过两个是相同的，则将这两个同名小实体分为一组。最后，保留数量最多的组，用这些小实体的内容，合并成新的事件实体。在合并的过程中，使用角色id-角色映射表，将相关人融合到relatedPerson属性中。这样一来，所生成的事件实体，就可以与人实体建立起关系。最后，通过事件实体上的相关人信息，来补充人员实体中的relatedEvent属性。

采用本应用示例，通过从多源数据中抽取出人实体、小实体及事实体并基于人实体与事实体的关联结果得到人<—>事为核心关系的基础属性，以通过该人<—>事为核心关系的基础属性作为“以人找事”和“以事找人”的数据基础，并应用于各个不同有相应数据需求的应用场景的搜索场景中。在搜索场景可以根据用户的检索query(query即搜索关键词、搜索条件等)，进行相关人、相关事件的信息展现。本申请的优势在于如下两方面：

第一、对分布在不同知识管理平台中的事件实体进行了整合，使各来源的知识数据相互补充，合并成一个包含的信息相对完成的事件实体。这样，用户在进行相关检索时，可以一次性获取最全面的人——事件关系信息，有效降低的检索成本。

第二、统一了对人<—>事关系的组织形式。实体结构的人实体、事件实体及人——事件关系，可以灵活标识不同数据源所提供的人——事件关系，信息覆盖全面，并且提供“以人找事”和“以事找人”的检索方式，有效提高检索效率。

根据本申请的实施例，提供了一种数据处理装置，图7是根据本申请实施例的数据处理装置的组成结构示意图，如图7所示，包括：抽取模块41，用于从多源数据中抽取第一类实体及小实体；格式统一及合并模块42，用于对所述小实体进行数据格式统一及合并处理，得到第二类实体；关联建立模块43，用于建立所述第一类实体与所述第二类实体的关联结果；搜索模块44，用于响应数据搜索操作，根据所述关联结果得到与搜索操作关键词对应的目标实体数据。其中，所述多源数据包括：员工数据、平台数据、项目数据、接口人数据、wiki数据中的至少一种。

一实施方式中，所述搜索模块，用于响应数据搜索操作，得到所述搜索操作关键词；所述搜索操作关键词包含所述第一类实体的情况下，根据所述关联结果得到对应所述第一类实体的目标第二类实体，将所述目标第二类实体作为所述目标实体数据；所述搜索操作关键词包含所述第二类实体的情况下，根据所述关联结果得到对应所述第二类实体的目标第一类实体，将所述目标第一类实体作为所述目标实体数据。

一实施方式中，所述抽取模块，包括第一抽取子模块，用于从所述多源数据中抽取员工数据，根据所述员工数据及所述第一类实体对应的属性生成所述第一类实体；第二抽取子模块，用于从所述多源数据中抽取所述第二类实体对应的名称及相匹配的别名，根据所述第二类实体对应的名称及相匹配的别名、及第二类实体对应的角色属性生成所述小实体。

一实施方式中，所述第一抽取子模块，用于所述第一类实体为人实体的情况下，将所述员工数据映射到人实体对应的属性中。

一实施方式中，还包括增补模块，用于将与所述人实体相关的事件属性增补到所述第一类实体中；其中，所述与所述人实体相关的事件属性的获取方式，包括从已有关系图谱中查询第一类实体与第二类实体的关联结果，或者，从所述多源数据中实时挖掘所述第一类实体与第二类实体的关联结果。

一实施方式中，所述第二抽取子模块，用于从所述多源数据中抽取结构化数据类型；根据所述结构化数据类型，得到第二类实体对应的名称及相匹配的别名，将所述第二类实体对应的名称及相匹配的别名，根据角色归一化标识映射到所述第二类实体对应的角色属性中。

一实施方式中，还包括第三抽取子模块，用于从所述多源数据中抽取非结构化数据类型；根据所述非结构化数据类型，得到用于表征所述第二类实体对应的名称及相匹配的别名的描述信息；根据所述描述信息，确定所述第二类实体对应的名称及相匹配的别名。

一实施方式中，所述格式统一及合并模块，用于所述小实体来自于不同数据源的数据格式情况下，对所述小实体的数据格式进行统一；将所述小实体中的同名小实体进行合并处理，得到所述第二类实体。

本申请实施例各装置中的各模块的功能可以参见上述方法中的对应描述，在此不再赘述。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图8所示，是用来实现本申请实施例的数据处理方法的电子设备的框图。该电子设备可以为前述部署设备或代理设备。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图8所示，该电子设备包括：一个或多个处理器801、存储器802，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图8中以一个处理器801为例。

存储器802即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的数据处理方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的数据处理方法。

存储器802作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的数据处理方法对应的程序指令/模块(例如，附图7所示的抽取模块、格式统一及合并模块、关联建立模块、搜索模块等模块)。处理器801通过运行存储在存储器802中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的数据处理方法。

存储器802可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据电子设备的使用所创建的数据等。此外，存储器802可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器802可选包括相对于处理器801远程设置的存储器，这些远程存储器可以通过网络连接至电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

数据处理方法的电子设备，还可以包括：输入装置803和输出装置804。处理器801、存储器802、输入装置803和输出装置804可以通过总线或者其他方式连接，图8中以通过总线连接为例。

输入装置803可接收输入的数字或字符信息，以及产生与电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置804可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决传统物理主机与虚拟专用服务器(VPS)服务中，存在的管理难度大，业务扩展性弱的缺陷。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。

采用本申请，可以从多源数据中抽取第一类实体及小实体，对小实体进行数据格式统一及合并处理，以得到第二类实体。可以建立第一类实体与第二类实体的关联结果，响应数据搜索操作，根据该关联结果得到与搜索操作关键词对应的目标实体数据。由于是从多源数据中抽取数据，数据的完整性得到保障，多源数据的准确性及有效性需要通过所建立的关联结果来保障，以便可以从海量的数据中抽取到有价值的各类实体数据，从而提高智能化办公场景下的办公效率。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本申请中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本申请公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本申请保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本申请的精神和原则之内所作的修改、等同替换和改进等，均应包含在本申请保护范围之内。