数据蒋堂 | 怎样生成有关联的测试数据

640?wx_fmt=png

作者:蒋步星

来源:数据蒋堂

本文共1500字,建议阅读7分钟
如何在多表情况下生成大规模测试数据时还能保证合理的关联性呢?

640?wx_fmt=png
在向用户推荐新的数据处理技术,特别是涉及性能优化的场景时,经常会碰到生成测试数据的需求。毕竟,新方案要经过验证才能提交,而优化过程也不是一次就做完的,需要多次不断的迭代改进,这就需要有一套好的测试数据才能实施。

用户常常也会提供一些例子数据,但一般不会很多。如果只是验证算法正确性,那用这些少量数据经常也可以了,但如果是验证性能,就还需要足够大的数据量才行。而用户的数据常常比较敏感,很多情况下不可能把全量数据提供出来,而且,数据量太大时也不合适搬来搬去。所以,最好还是能自己造出测试数据,特别地,还要根据用户提供的例子数据来造。
如果只是单个表(比如多维分析的场景),那还相对简单。把例子数据复制n遍到期望的规模,或者干脆随机生成,过程中注意对主键进行一些处理保证不重复(比如不断地加1,具体手段视数据类型而定),大多数情况也够用。但如果涉及到多个关联表就麻烦了,因为运算中可能涉及JOIN,简单复制例子数据,可能导致JOIN结果集和例子数据的规模相近,而完全随机生成则很可能就关联不上使得JOIN结果集是个空集,下一步的运算就会建立在一个虚假的小结果集上,严重误导性能测试的结果。

那么,该如何在多表情况下生成大规模测试数据时还能保证合理的关联性呢?


分析数据结构与关联关系


说白了,就是画出E-R图,搞清各个表之间的引用关系,特别是要搞清谁是谁的外键。

我们以前在讲JOIN运算时说过,数据库表的关联关系可以分成外键、同维、主子三种情况。传统的E-R图并没有这么明确的区分,但在这里我们就需要做这件事情了。根据关联字段是否是表的主键(或部分主键)就可以区分出来。同一个表同时是两个表的子表时,我们把这两个主表看成子表的外键表,而不作为主子表处理,这样能保证没有子表有多个主表。这个问题在讨论以前JOIN简化和提速时不需要涉及,但这里要提出来。
有时用户会明确给出数据结构和E-R图,那直接使用就可以了。有时候只会给一批用于运算SQL语句,这就要从其中的JOIN子句来分析,根据JOIN字段是否是表的主键(或部分主键)可以判断是哪种关联。如果发生这三种之外的情况(比如出现非主键和非主键JOIN的多对多情况),那多半是用户的SQL语句很错了,要明确指出来。
有些外键是隐含的关系,比如身份证号中有个日期和地区码,如果运算中有从身份证号提供这些部分信息的动作,那也需要把这些隐含的关联关系找出来,相当于把身证份号这样的字段拆成几段。日期本身也有类似的隐含关系,它本身是一个外键字段,但一般数据库中都很少会有一个日期表来作为它的指向表,这个也需要补充出来。在单表生成测试数据时也有这类问题。


排定次序


知道了关联关系后,就可以排定生成数据的次序了。

我们把同维表看成一个逻辑表一起处理,主子表中的子表则依附于主表先隐藏起来,子表的其它外键表也被视为主表的外键表,等主表处理完再来处理子表。这样,关联关系中就只剩外键表。

现在,我们先给每个表标上数字1。然后,对于每个表,如果它有的所有外键表的标号最大值为n,则把它本身的标号改成n+1,反复执行此动作直到所有标号不再变动为止。

这个动作能执行结束的前提是E-R图中没有有向圈(A表是B表的外键表时从B表画一条指向A表有向边),这个要求对绝大多数数据库结构来讲都是满足的。有时会发生某个表自己是自己外键表的现象,这时在标号时忽略这个外键关系就可以了。但如果发生涉及多个表的有向圈时的情况就复杂多了,我们这里限于篇幅不讨论这种情况了,毕竟也非常罕见。


按次序生成测试数据


现在,根据表的标号从小到大的次序去生成数据就行了。

在为标号为n+1的表生成数据时,它引用的外键表的标号都不超过n,已经被生成了,则它的外键值从这些已经生成的表的主键中随机取就可以了。

同维表可以一起生成,子表则等待主表完成后再生成,如果有多个子表之间还有引用关系(很罕见了,多个子表都较为少见),也可以用上面的办法再排出次序来生成。


专栏作者简介

640?

润乾软件创始人、首席科学家


清华大学计算机硕士,中国大数据产业生态联盟专家委员,著有《非线性报表模型原理》等,1989年,中国首个国际奥林匹克数学竞赛团体冠军成员,个人金牌;2000年,创立润乾公司;2004年,首次在润乾报表中提出非线性报表模型,完美解决了中国式复杂报表制表难题,目前该模型已经成为报表行业的标准;2014年,经过7年开发,润乾软件发布不依赖关系代数模型的计算引擎——集算器,有效地提高了复杂结构化大数据计算的开发和运算效率;2015年,润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”;2016、2017年,荣获中国电子信息产业发展研究院评选的“中国软件和信息服务业十大领军人物”;2017年度中国数据大工匠、数据领域专业技术讲堂《数据蒋堂》创办者。


数据蒋堂

《数据蒋堂》的作者蒋步星,从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞,虚拟与现实的相互交织,产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点,站在研发人员的角度从浅入深,进行全方位、360度无死角深度剖析;对于一些业内观点,站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展,站在业内专家角度给予预测和推断。静下心来认真研读你会发现,《数据蒋堂》的文章,有的会让用户避免重复前人走过的弯路,有的会让攻城狮面对扎心的难题茅塞顿开,有的会为初入行业的读者提供一把开启数据世界的钥匙,有的甚至会让业内专家大跌眼镜,产生思想交锋。


数据蒋堂第二年往期回顾:

数据蒋堂 | 莫非我就是被时代呼唤的数学人

数据蒋堂 | SQL是描述性语言?

数据蒋堂 | 存储和计算技术的选择

数据蒋堂 | 人工智能中的“人工”

数据蒋堂 | 中国报表漫谈

数据蒋堂 | 内存数据集产生的隐性成本

数据蒋堂 | 多维分析预汇总的功能盲区

数据蒋堂 | 多维分析预汇总的存储容量

数据蒋堂 | 多维分析预汇总的方案探讨

数据蒋堂 | 数据库的封闭性

数据蒋堂 | 内存数据集产生的隐性成本

数据蒋堂 | 前半有序的大数据排序

数据蒋堂 | “后半”有序的分组

数据蒋堂 | 时序数据从分表到分库

数据蒋堂 | BI系统的前置计算

数据蒋堂 | 性能优化是个手艺活

数据蒋堂 | 数据分布背后的逻辑

数据蒋堂 | 从一道招聘考题谈起

数据蒋堂 | 为什么我们需要C程序员

数据蒋堂 | 报表工具的SQL植入风险

数据蒋堂 | 内置的数据无法实现高性能

640?wx_fmt=jpeg

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值