基于Spark平台的分布式大数据函数依赖发现方法
阅读：777发布：2024-01-13
专利汇可以提供基于Spark平台的分布式大数据函数依赖发现方法专利检索，专利查询，专利分析的服务。并且本 发明 提供一种基于Spark平台的分布式 大数据 函数依赖发现方法，包括数据分区，包括根据Spark集群各 节点 分配的CPU 内核 数对数据进行分区；生成属性集合的所有非空子集，包括通过 数据库 中的所有属性集合，生成含有所有非空子集的集合，为求解所有属性集合的等价类个数作准备；累加各节点属性集合的等价类数量，通过等价类计算得到全局数据库的(属性集合，等价类数)集合； 迭代 各属性集合生成函数依赖集合，包括由各属性集合的子集构建候选函数依赖关系，判断函数依赖关系是否成立。该方法解决了分布式环境下函数依赖发现 算法 的负载 不平衡 和低效问题，大幅度提高了函数依赖发现的执行效率。，下面是基于Spark平台的分布式大数据函数依赖发现方法专利的具体信息内容。
1.一种基于Spark平台的分布式大数据函数依赖发现方法，其特征在于，包括以下步骤：
步骤1，数据分区，包括根据Spark集群各节点分配的CPU内核数对数据进行分区；
步骤2，生成属性集合的所有非空子集，包括通过数据库中的所有属性集合，生成含有所有非空子集的集合，为求解所有属性集合的等价类个数作准备；
步骤3，累加各节点属性集合的等价类数量，通过等价类计算得到全局数据库的(属性集合，等价类数)集合；
步骤4，迭代包含各集合属性的函数依赖关系，构建下一层候选函数依赖关系，判断各层函数依赖关系是否成立。
2.根据权利要求1所述的基于Spark平台的分布式大数据函数依赖发现方法，其特征在于：步骤1包括以下子步骤，
步骤1.1，设置Spark集群节点，设置HDFS默认的Block大小调整分区数；
步骤1.2，按照Spark集群的节点将整个数据集进行分区，并装载到Spark运行环境当中。
3.根据权利要求1所述的基于Spark平台的分布式大数据函数依赖发现方法，其特征在于：步骤2的实现过程如下，
按照所有属性的自由排列组合方式，计算出所有的非空子集属性，对于有n个属性的数据集来说，所有的非空子集数量为2n-1。
4.根据权利要求1所述的基于Spark平台的分布式大数据函数依赖发现方法，其特征在于：步骤3的实现包括以下子步骤，
步骤3.1，对于步骤2计算出的非空子集，逐条扫描每条数据，当发现新的数据时在哈希表中新建key值，value值标为1；
步骤3.2，在逐行扫描数据时，如果遇到哈希表中已有的值，则将value值加1，直至扫描完毕，得到该非空子集的等价类；
步骤3.3，依次迭代所有非空子集，得到该节点所有非空自己的等价类；
步骤3.4，调用Spark的reducebykey算子，将各节点的所有属性集合进行累加，得到全局数据库的(属性集合，等价类数)。
5.根据权利要求1所述的基于Spark平台的分布式大数据函数依赖发现方法，其特征在于：步骤4的实现包括以下子步骤，
步骤4.1，由输入函数依赖关系t生成下一层候选函数依赖关系得到集合γ，从步骤3得到的(属性集合、等价类个数)数组中查找每个候选函数依赖关系的左部和整体属性集合的等价类个数；
步骤4.2，遍历集合γ中候选函数依赖关系，当遍历到一个候选函数依赖关系时，若该函数依赖关系左部属性集合的等价类个数大于或等于整体属性集合的等价类个数，表明该候选函数依赖关系在数据集中成立，此时将函数依赖关系左部作为输入返回步骤4.1，进行下一层迭代；反之，则该函数依赖关系不存在，进入步骤4.3；
步骤4.3，此时函数依赖关系不存在，则对候选函数依赖集合进行剪枝，在集合γ中删除该关系及所有子关系，然后判断是否对集合γ中候选函数依赖关系遍历完成，是则进入步骤4.4，否则返回步骤4.2，继续遍历集合γ中候选函数依赖关系，从集合γ剩余候选函数依赖关系取一个进行同样处理；
步骤4.4，此时当前的集合γ遍历完毕，若集合中每个关系都不成立，则此时输入函数依赖关系为最小函数依赖关系，将结果进行保存，然后进入步骤4.5；否则直接进入步骤
4.5；
步骤4.5，判断输入函数依赖关系是否包含所有属性集合，是则表明当前所有迭代已经完成，结束程序；否则表明当前函数依赖关系为步骤4.2迭代进入的下一层候选函数依赖关系，此时返回上一层迭代关系，继续遍历上层集合γ的候选函数依赖关系，执行步骤4.2。
基于Spark平台的分布式大数据函数依赖发现方法
技术领域
[0001] 本发明属于函数依赖发现技术领域，特别是设计一种基于Spark平台的分布式大数据函数依赖发现方法。
背景技术
[0002] 本发明涉及的相关技术介绍如下：
[0004] 函数依赖表示一个属性或属性集合的值对另一个属性或属性集合的值的依赖性。在传统关系数据库中，函数依赖发现在知识发现、数据库语义分析、数据质量评估以及数据库设计等领域有着广泛的应用。当前大数据背景下，数据呈现出4V特性，即数据量大(volumn)、数据种类多(variety)、数据更新速度快 (velocity)、数据价值密度低(value)等特点。在此背景下，传统的函数依赖发现算法很难适合大数据环境。
[0005] [文献1]阐述了一种经典的函数依赖发现算法TANE。TANE根据元组的属性值将元组划分成不同的集合，然后在不同的划分上对候选函数依赖进行检测。通过逐层发现的方法，在每一层对候选函数依赖进行验证，生成符合条件的函数依赖，然后根据发现的结果生成下一层的候选函数依赖。[文献2]同样利用逐层发现的思想生成满足要求的函数依赖，然后利用迭代的思想产生下一层候选函数依赖，以此得到所有候选函数依赖集并从中找出函数依赖关系。[文献3]考虑函数依赖Armstrong公理系统得到候选函数依赖剪枝策略，在逐层发现过程中对候选函数依赖进行剪枝。[文献4]和[文献5]从初始数据库中得到数据集划分，根据这些划分计算出一致集合和差异集合，并最终根据得到的一致集合和差异集合可以发现最小的函数依赖覆盖。两篇文献的主要区别在于，[文献4]使用了深度优先的搜索策略，而[文献5]使用了逐层搜索的策略。
[0006] 以上函数依赖发现方法主要针对传统集中环境下函数依赖的发现。在当前的大数据时代背景下，数据分布在不同的节点，上述函数依赖发现算法直接使用容易引起判断误差。[文献6]研究了分布式数据库函数依赖挖掘方法，给出了一个分布式数据库函数依赖挖掘框架。该计算框架首先在各个节点进行函数依赖发现，然后根据发现的结果对候选函数依赖集合进行剪枝，最后将各个节点的数据集中到一个中心节点，在中心节点执行集中式环境下的函数依赖挖掘算法。该方法主要的挖掘执行过程还是在集中式环境进行，实际的执行效率较低，不适合大规模海量数据。[文献7]考虑在大数据背景下，利用函数依赖的左部特征，对函数依赖候选集进行分组，针对每一组候选函数依赖并行执行分布式环境发现算法，最终得到所有函数依赖。这种方法基于Hama平台，需要在不同节点间依据函数依赖候选集的哈希值将数据进行重分布，极端情况下需要消耗节点间计算和带宽资源，影响最终的计算效率。
[0007] (2)Hadoop计算平台
[0008] 随着大数据时代的到来，Hadoop平台各项技术发展迅猛。Hadoop由Apache 软件基金会于2005年秋天作为Lucene的子项目Nutch的一部分正式引入。 Hadoop的核心架构由多个模块组成，[文献8]介绍了Hadoop分布式文件系统 (HDFS)，用来存储Hadoop集群所有存储节点上的文件。[文献9]介绍了Hadoop 默认的MapReduce计算框架，采用了概念“Map(映射)”和“Reduce(归约)”，用于大规模数据集的并行运算。用户只需编写两个称作Map和Reduce的函数即可，系统能够管理Map或Reduce并行任务的执行以及任务之间的协调，并且能够处理上述某个任务失败的情况，并且同时能够保障对硬件故障的容错性。此外， [文献10]介绍了Hadoop平台的资源调度系统YARN。
[0009] (3)Spark云计算平台
[0010] Spark是由UC Berkeley AMP实验室开发的开源通用并行云计算平台，Spark 基于MapReduce思想实现分布式计算，拥有Hadoop MapReduce所具有的优点；但是不同地方是运算中间输出结果能存储在内存中，从而不在需要读写分布式文件系统(HDFS)，因此Spark能更好的运行数据挖掘与机器学习等需要迭代的 MapReduce算法。Spark启用了内存分布数据集，它可以提供交互式查询，除此之外还可以将数据集缓存在内存中，提高数据集读写速率实现计算过程中的数据集的重用，优化迭代工作负载。Spark底层可使用多种分布式文件系统如HDFS 文件系统存放数据，不过更多的是与资源调度平台Mesos和YARN一起合作出现。
[0011] [文献11]介绍了Spark的核心抽象概念：弹性分布式数据库RDD(Resilient Distributed Datasets)，该抽象是分布在计算集群上的可恢复数据集。RDD是Spark 的核心，RDD是分布于各个计算节点存储于内存中的数据对象集合，RDD允许用户在执行多个查询时显式地将工作集缓存在内存中，后续的查询能够重用工作集，这极大地提升了查询速度。RDD分布在多个节点上，并可以对其进行并行处理。RDD是可扩展、弹性的，在运算过程中，内存小于RDD时，可以转存到磁盘上，确保内存足够继续运算。RDD是已被分区、只读的、不可变的并能够被并行操作的数据集合，只能通过在其它RDD执行确定的转换操作(如map、 join、filter和group by)而创建，然而这些限制使得实现容错的开销很低。与分布式共享内存系统需要付出高昂代价的检查点和回滚不同，RDD通过Lineage 来重建丢失的分区：一个RDD中包含了如何从其它RDD衍生所必需的相关信息，从而不需要检查点操作就可以重构丢失的数据分区。尽管RDD不是一个通用的共享内存抽象，但却具备了良好的描述能力、可伸缩性和可靠性，并能够广泛适用于数据并行类应用。
[0012] 相关文献：
[0013] [文献1]Huhtala Y， J，Porkka P，et al.TANE：an efficientalgorithm for discovering functional and approximatedependencies[J].The Computer Journal, 1999,42(2):100-111.
[0014] [文献2]Novelli N,Cicchetti R.Fun:An efficient algorithm for mining functional and embedded dependencies[C].Proc of the 8th Int Conf of Database Theory.New York:ACM,2001:189-203
[0015] [文献3]Hong Yao,Howard J,Hamilton.Mining functional dependencies from data[J].Data Mining and Knowledge Discovery,2008,16(2):197-219
[0016] [文献4]Wyss C,Giannella C,Robertson E.FastFDs:A heuristic-driven, depth-first algorithm for mining functional dependencies from relation instances[C]. Proc of the 3rd Int Conf on Data Warehousing and Knowledge Discovery.New York: ACM,2001:101-110
[0017] [文献5]Lopes S,Petit J,Lakhal L.Efficient discovery of functional dependencies and Armstrong relations[C].Proc of the 7th Int Conf on Extending Database Technology.New York:ACM,2000:350-364
[0018] [文献6]Ye Feiyue,Liu Jixue,Qian Jin,XueXiaofeng.A framework for mining functional dependencies from large distributed databases[C].Proc of 2010Int Conf on Artificial Intelligence and Computational
Intelligence.Alamitos,CA:IEEE, 2010:109-113.
Intelligence.Alamitos,CA:IEEE, 2010:109-113.
[0019] [文献7]李卫榜，李战怀，陈群，姜涛，刘海龙，潘巍.分布式大数据函数依赖发现[J].计算机研究与发展.2015(2):283-283.
[0020] [文献8]Shvachko K,Kuang H,Radia S,Chansler R.The hadoop distributed file system[C].In:Mass storage systems and technologies(MSST),2010IEEE 26th symposium on.Nevada:IEEE,2010.1-10.
[0021] [文献9]Dean J,Ghemawat S.MapReduce:simplified data processing on large clusters.In:Proceedings of the 6th conference onSymposium on Opearting Systems Design and Implementation[C].San Francisco:USENIX Association Berkeley,2004. 137-149.
[0022] [文献10]Vavilapalli VK,Murthy AC,Douglas C,Agarwal S,Konar M,Evans R, Graves T,Lowe J,Shah H,Seth S.Apache hadoopyarn:Yet another resource negotiator[C].In:Proceedings of the 4th annual Symposium on Cloud Computing. California ACM,2013.1-16.
[0023] [文献11]Zaharia M,Chowdhury M,Das T,Dave A,Ma J,McCauley M, Franklin MJ,Shenker S,Stoica I.Resilient distributed datasets:Afault-tolerant abstraction for in-memory cluster computing[C].In:Proceedings of the 9th USENIX conference on Networked SystemsDesign and Implementation.San Jose:
USENIX Association Berkeley,2012.1-14.
USENIX Association Berkeley,2012.1-14.
发明内容
[0024] 针对现有的函数依赖发现算法主要面向集中式数据的处理环境，以及现有基于Hadoop平台的处理算法具有较高IO开销和负载不均衡的问题，本发明提供了一种基于Spark平台的分布式大数据函数依赖发现方法。
[0025] 本发明所采用的技术方案是一种基于Spark平台的分布式大数据函数依赖发现方法，包括以下步骤：
[0027] 步骤2，生成属性集合的所有非空子集，包括通过数据库中的所有属性集合，生成含有所有非空子集的集合，为求解所有属性集合的等价类个数作准备；
[0028] 步骤3，累加各节点属性集合的等价类数量，通过等价类计算得到全局数据库的(属性集合，等价类数)集合；
[0029] 步骤4，迭代包含各属性集合的函数依赖关系，构建下一层候选函数依赖关系，判断各层函数依赖关系是否成立。
[0030] 而且，步骤1包括以下子步骤，
[0031] 步骤1.1，设置Spark集群节点，设置HDFS默认的Block大小调整分区数；
[0032] 步骤1.2，按照Spark集群的节点将整个数据集进行分区，并装载到Spark 运行环境当中。
[0033] 而且，步骤2的实现过程如下，
[0034] 按照所有属性的自由排列组合方式，计算出所有的非空子集属性，对于有n 个属n性的数据集来说，所有的非空子集数量为2-1。
[0035] 而且，步骤3的实现包括以下子步骤，
[0036] 步骤3.1，对于步骤2计算出的非空子集，逐条扫描每条数据，当发现新的数据时在哈希表中新建key值，value值标为1；
[0037] 步骤3.2，在逐行扫描数据时，如果遇到哈希表中已有的值，则将value值加1，直至扫描完毕，得到该非空子集的等价类；
[0038] 步骤3.3，依次迭代所有非空子集，得到该节点所有非空自己的等价类；
[0039] 步骤3.4，调用Spark的reducebykey算子，将各节点的所有属性集合进行累加，得到全局数据库的(属性集合，等价类数)。
[0040] 而且，步骤4的实现包括以下子步骤，
[0041] 步骤4.1，由输入函数依赖关系t生成下一层候选函数依赖关系得到集合γ，从步骤3得到的(属性集合、等价类个数)数组中查找每个候选函数依赖关系的左部和整体属性集合的等价类个数；
[0042] 步骤4.2，遍历集合γ中候选函数依赖关系，当遍历到一个候选函数依赖关系时，若该函数依赖关系左部属性集合的等价类个数大于或等于整体属性集合的等价类个数，表明该候选函数依赖关系在数据集中成立，此时将函数依赖关系左部作为输入返回步骤4.1，进行下一层迭代；反之，则该函数依赖关系不存在，进入步骤4.3；
[0043] 步骤4.3，此时函数依赖关系不存在，则对候选函数依赖集合进行剪枝，在集合γ中删除该关系及所有子关系，然后判断是否对集合γ中候选函数依赖关系遍历完成，是则进入步骤4.4，否则返回步骤4.2，继续遍历集合γ中候选函数依赖关系，从集合γ剩余候选函数依赖关系取一个进行同样处理；
[0044] 步骤4.4，此时当前的集合γ遍历完毕，若集合中每个关系都不成立，则此时输入函数依赖关系为最小函数依赖关系，将结果进行保存，然后进入步骤4.5；否则直接进入步骤4.5；
[0045] 步骤4.5，判断输入函数依赖关系是否包含所有属性集合，是则表明当前所有迭代已经完成，结束程序；否则表明当前函数依赖关系为步骤4.2迭代进入的下一层候选函数依赖关系，此时返回上一层迭代关系，继续遍历上层集合γ的候选函数依赖关系，执行步骤4.2。
[0046] 本发明针对当前函数依赖方法主要应用场合为传统集中式环境的执行现状，以及分布式平台环境下现有方法处理能力低效的问题，设计了基于属性集合等价类来发现函数依赖的方法和相应的剪枝策略，通过利用属性集合的等价类数量来判断函数依赖是否成立，最大限度的解决了传统计算模式下计算效率不高的问题，并充分利用Spark云计算平台的大规模并行计算能力，大幅度减小了函数依赖发现的时间。本发明的技术方案具有简单快速的特点，能够大幅度提高大数据环境下函数依赖的发现效率。附图说明
[0048] 图2为本发明实施例的数据分区示意图；
[0049] 图3为本发明实施例的属性集合所有非空子集的示意图；
[0050] 图4为本发明实施例的使用Spark的reducebykey算子累加各节点函数依赖的示意图；
[0051] 图5为本发明实施例的函数依赖不成立情况下的剪枝示意图。
具体实施方式
[0052] 为了便于本领域普通技术人员理解和实施本发明，下面结合附图及实施例对本发明作进一步的详细描述，应当理解，此处所描述的实施示例仅用于说明和解释本发明，并不用于限定本发明。
[0053] 本发明通过Spark的相关算子设计了合理的属性集合等价类，最大限度的解决了传统计算模式下计算效率不高的问题，同时使用Spark的大规模并行计算大幅度减小了函数依赖发现的时间。本发明的技术方案简单清晰，能够较好提高函数依赖发现的效率。
[0054] 本发明实施例的基于Spark平台的函数依赖发现方法的流程见图1，所有步骤可由本领域技术人员采用计算机软件技术实现流程自动运行。实施案例具体实现过程如下：
[0055] 步骤1：数据分区；
[0056] 根据Spark集群各节点分配的CPU内核数(虚拟CPU计算内核cores)对数据进行分区；
[0057] 步骤1的具体实现包括以下子步骤：
[0058] 步骤1.1：设置Spark集群节点，同时配置HDFS默认的Block(块)大小，一般默认设置64m，在这个基础上具体实施时可根据数据量大小进行调整，在节点配置很高、数据量很大时，可以设置128m甚至256m的Block大小，数据量较小的情况下可以将Block设置为32m；
[0059] 步骤1.2：按照Spark集群各节点CPU内核数，将整个数据集进行分区，节点CPU内核数越高，这个节点就可以分配更多的数据分区，节点的数据资源计算并发度也越高。分区划分后，将数据集装载到Spark运行环境当中。
[0060] 实施例中，首先将整个数据集按照Spark集群的节点设置进行分区，需要将数据集划分到三个节点上。实施例中，以包含5个元组的数据集为例，如表1 所示。
[0061] 表1
[0062]
[0063] 其中，Tuple为元组标识，Time为时间、Name为名称、Birthday为生日、 Supervisor为管理员。
[0064] 数据分区不涉及数据在节点上的重分布，分区中的数据仍是杂乱的，需要根据每个节点的计算能力来设置每个节点分配到的数据量。在具体设置过程中，通过各节点的CPU内核数来调整分区数，一般要求各节点的分区数大于或等于 CPU内核数，这样才能最大限度利用CPU资源，使每个分区的数据都能调用一个独立的CPU内核，从而提高整个Spark集群的计算效率，提高并行度。若各节点分区数小于CPU内核数，此时存在CPU内核未充分利用，影响Spark环境整体计算性能。实施例中，分区实施之后，三个分区包含的元组数分别为{t1、t2}， {t3}，{t4、t5}，如图2所示。
[0065] 步骤2：生成属性集合的所有非空子集，记为
[0066] 通过全局数据库(即整个数据集)中的所有属性集合，生成含有所有非空子集的集合，为求解所有属性集合的等价类数量作准备；
[0067] 步骤2的具体实现过程如下：
[0068] 按照所有属性的自由排列组合方式，计算出所有的非空子集属性，对于有n 个属性的数据集来说，所有的非空子集数量为2n-1。
[0069] 实施例中，对于所有属性集合而言，集合的所有非空子集包含了所有属性的自由排列组合，以图2中四个属性A、B、C、D为例，它的所有非空子集如图3 所示，包括ABCD、ABC、ABD、ACD、BCD、AB、AC、BC、BD、AD、CD、 A、B、C、D。对于有n个属性的属性集合，他们所有非空子集中包含n个属性的属性集合数量为 包含n-1个属性的属性集合数量为 依次类推，所有非空子集数量为
[0070]
[0071] 步骤3：累加各节点属性集合的等价类数量；
[0072] 通过等价类计算得到整个Spark平台数据库(全局数据库)的(属性集合，等价类数)集合；
[0073] 步骤3.1：对于步骤2计算出的非空子集，逐条扫描每条数据，当发现新的数据时，在哈希表中新建键值对，即(key，value)，属性值集合作为键(key)，它的值(value)设置1；
[0074] 步骤3.2：在逐行扫描数据时，如果遇到哈希表中已有的值，则将value加1，直至扫描完毕，得到该非空子集的等价类；
[0075] 步骤3.3：依次迭代所有非空子集，得到该节点所有非空子集的等价类；
[0076] 步骤3.4：调用Spark的reducebykey算子，将各节点的所有属性集合进行累加，得到全局数据库的(属性集合，等价类数)。
[0077] reducebykey算子是Spark的一种Action类算子，作用是通过传入一个相关函数来合并每个key对应的value的值，因此它能够合并位于不同节点上的(key， value)类的数据。
[0078] 实施例中，要判断函数依赖关系X→Y在数据库上是否成立，需要计算以属性X对数据库做划分得到的等价类个数，以及以属性X∪Y的集合对数据库做划分得到的等价类个数，这里的X和X∪Y即为属性集合。通过计算每个节点每个属性集合的等价类数量，就可以得到每个节点(属性集合，等价类数)的集合，然后通过各节点进行累加，即可得到全局数据库属性集合的等价类数量。例如，对表1数据中的属性集合BCD进行等价类划分，得到三个节点上的等价类数量如表2所示，即在每个节点上都能得到(属性集合，等价类数)的集合。
[0079] 表2
[0080]
[0081] 随后，在各个节点上，利用Spark的reducebykey算子，将相同的等价类按照key值进行累加，如表3所示。
[0082] 表3
[0083]
[0084] 具体每个节点计算等价类的计算结果如图4所示，其具体实施过程主要分为如下几步：
[0085] (1)按照步骤2当中所有属性的非空子集迭代每个节点的所有数据；
[0086] (2)在处理单个属性集时，将不同等价类分别进行计数，其中，属性值作为 key存在Spark的RDD当中；
[0087] (3)在Spark环境下，各个节点所有属性集的等价类数量进行同步处理。处理完成后，调用Spark的reducebykey算子，累加各节点不同属性集的相同等价类，得到(属性集合、等价类个数)数组。
[0088] 步骤4：迭代包含各属性集合的函数依赖关系，构建下一层候选函数依赖关系，判断各层函数依赖关系是否成立。
[0089] 此步骤为生成最终函数依赖关系的迭代过程，具体实施步骤如下：
[0090] (1)初始状态，由输入函数依赖关系t(此时包含所有属性集合)生成下一层候选函数依赖关系得到集合γ，从步骤3得到的(属性集合、等价类个数)数组中查找每个候选函数依赖关系的左部和整体属性集合的等价类个数；
[0091] (2)遍历集合γ中候选函数依赖关系。当遍历到一个候选函数依赖关系时，若该函数依赖关系左部属性集合的等价类个数大于或等于整体属性集合的等价类个数，即表明该候选函数依赖关系在数据集中成立，此时将函数依赖关系左部作为输入返回步骤(1)，进行下一层迭代；反之，则该函数依赖关系不存在，进入步骤(3)；
[0092] (3)此时函数依赖关系不存在，则对候选函数依赖集合进行剪枝，在集合γ中删除该关系及所有子关系，然后判断是否对集合γ中候选函数依赖关系遍历完成，是则进入步骤(4)，否则返回步骤(2)，继续遍历集合γ中候选函数依赖关系，从集合γ剩余候选函数依赖关系取一个进行同样处理；
[0093] (4)此时当前的集合γ遍历完毕，若集合中每个关系都不成立，则此时输入函数依赖关系为最小函数依赖关系，将结果进行保存，然后进入步骤(5)；否则直接进入步骤(5)；
[0094] (5)判断输入函数依赖关系是否包含所有属性集合，是则表明当前所有迭代已经完成，结束程序；否则表明当前函数依赖关系为步骤(2)迭代进入的下一层候选函数依赖关系，此时返回上一层迭代关系，继续遍历上层集合γ的候选函数依赖关系，返回执行步骤(2)。
[0095] 实施例具体实现过程的细节如表4，相关的变量说明如下：
[0096] 设X,Y是关系t的两个属性集合，当任意两个元组中的X属性值相同时，它们的Y属性值也相同，则称X函数决定Y，或Y函数依赖于X。由输入函数依赖关系t生成下一层候选函数依赖集合γ，此时γ为属于函数依赖关系t子集的所有候选函数依赖集合，其候选函数依赖用ti表示，且ti∈γ(i＝1,2,3…N)，ti:Xi→ Yi，其中，Xi为候选依赖ti的左部，Yi为候选依赖ti的右部，N为候选函数的个数。最终结果保存在最小函数依赖关系集合β当中。
[0097] 表4
[0098]
[0099] 在实施例中，对表1数据中的属性集合ABCD进行迭代，他的下一层候选函数依赖关系集合γ＝{BCD→A,ACD→B,ABD→C,ABC→D}，首先判断候选函数依赖BCD→A，若{BCD}的等价类数量与{ABCD}的等价类数量相等，则该候选函数依赖成立，此时将进行候选集{BCD}的进一步迭代；若{BCD}的等价类数量与{ABCD}的等价类数量不相等，则说明BCD→A不成立，此时则进行剪枝，不需要再对候选集{BCD}及其子关系进行迭代。这是因为当BCD→A不成立时，候选集{BCD}的子关系BC→D或者B→D肯定不成立。图5所示关系集合将BCD 进行剪枝后的所有子集，虚线表示将其从关系集合中剪枝。
[0100] 在对大规模数据集进行函数依赖发现的过程中，由于数据规模的庞大，对候选函数依赖关系的判断所耗费的时间是函数依赖发现的主要消耗时间。通过对关系集合的剪枝能够减少对候选函数依赖关系的判断，很大程度的减小发现代价，从而提高了函数依赖发现效率。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 一种基于CML的智能变电站设备网络结点连锁失效风险分析方法 | 2020-05-08 | 991 |
| 一种区块链共识方法及装置 | 2020-05-08 | 256 |
| 一种基于图数据库的建筑设计规范知识图谱构建方法 | 2020-05-08 | 337 |
| 一种基于RPL路由协议的IPv6无线传感网时间同步方法 | 2020-05-11 | 440 |
| 一种K8s平台的资源控制方法、装置及相关组件 | 2020-05-08 | 102 |
| 一种节点宕机修复方法、装置、电子设备及可读存储介质 | 2020-05-08 | 382 |
| 一种基于机器学习的应收账款兑付风险控制方法及系统 | 2020-05-08 | 180 |
| 一种基于图分析的反欺诈检测方法及检测系统 | 2020-05-08 | 591 |
| 直播视频的回看方法、装置、电子设备、系统及存储介质 | 2020-05-08 | 510 |
| 一种随机接入方法及装置 | 2020-05-08 | 413 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈