数据蒋堂 | 常规遍历语法

遍历可以说是最基本的集合运算了,比如求和、计数、寻找最大最小值等聚合运算,按条件过滤集合、根据集合成员生成另一个新集合,也都是遍历运算。集合化语法要求我们能用很短的语句(经常就只有一句,而不是若干语句构成的一段程序)来描述大部分遍历运算,这样我们需要考查遍历运算中可能出现的各种常见情况,并设计出合理自治的语法规则。

我们从简单到复杂来考查遍历运算中的可能情况,并讨论SQL语法在这方面的表现。

比如计算集合成员的合计。

这是最简单的情况,采用普通的函数语法风格就可以,将待遍历的集合作为参数获得返回值,比如sum(A)用于计算集成A成员的合计,当然也可以使用对象式的语法风格写成A.sum()。

比如我们不是要计算集合成员的合计,而是要计算平方和,那么这个平方该如何描述?

这就会用到我们在谈集合化语法时提到的lambda语法。平方这个运算本质上是一个函数,在遍历过程中它以被遍历集合的当前成员作为参数,返回该参数的平方。而lambda语法允许将这个函数以表达式的形式并一起写入整个计算遍历运算式,一个语句就可以完成。但这里就有一个问题,我们在这个lambda表达式中用什么标识符或符号表示这个当前成员呢?

显然,像普通函数那个先定义参数名不是个好办法,那会让lamdba表达式写得很臃肿,失去lambda语法的简洁性。尽管有些程序设计语言确实是这么做的,不过我们并不提倡。使用一个固定的标识符也不好,太长了用起来不方便,太短又很可能与其它局部变量重名导致歧义。我们提倡在这里使用一个特殊符号来完成这个目的。

比如使用~表示当前成员时,平方和就可以写成A.sum(~~),简单易懂。也可以分两步做,先计算出集合成员的平方构成一个新集合,再计算新集合的合计,写成类似A.(~~).sum()的形式,后一步不再需要~写法,前一步仍需要~写法来描述平方这个表达式函数。

但是,我们发现,被认为是集合化语言的SQL中并没有使用某个符号或标识符来表示当前遍历成员,那么SQL又是怎么解决上一部分的第二个问题的呢?

事实上,SQL并没有普通意义上可由任何成员构成的集合。SQL的集合就是表,而表的成员都是相同结构的记录。SQL体系中有记录这个概念,但并不能把记录作为一种数据类型来引用。如果我们要在SQL中针对一个单值成员的集合进行遍历,也只能把单值做成只有一个字段的记录,而针对这些记录构成的表进行遍历。所有计算都是针对某些字段进行的,而不能针对整条记录。

但这和SQL没有表示当前成员的符号有什么关系呢?

我们在前面说集合化语法时还提到,面向结构化数据计算的集合化语法需要有简洁的方式引用字段,SQL提供了可以直接引用字段的便捷机制,而SQL又只能计算字段,那就可以不必再提供引用当前成员(记录)的手段了。比如SQL中计算平方和一定是某个字段的平方和,而整条记录(集合成员)的平方则没有意义。

SQL牺牲了集合的表达能力而简化了语法。对于能够支持泛型成员构成集合的语言来讲,~写法就是必要的了。而且,如果用于结构化数据计算时,SQL这种可以直接字段的写法也要得到支持才会方便,计算某销售帐目的金额时写成"~.单价~.数量"显然不如写成"单价数量“更为简单直观,好的程序语言应当借鉴SQL这种风格。

遍历在本质上就是一个循环,而循环语句可能有多层,这样遍历也可能会有嵌套引用。比如计算A,B两个集合的交集,简单的算法就是遍历A的成员,看是不是在B集合中出现过(也是遍历),这就会涉及到两层的遍历。

这时候~写法就会产生歧义了,~到底是指A集合还是B集合的当前成员,这需要在语法规则上做一个明确的约定。

一般采用的是就近原则,即如果没有指明~是哪个集合的,那缺省认为是内层遍历集合的,而外层遍历集合的当前成员则需要显式地指出其从属于哪个集合。计算交集的表达式就可以写成A.select(B.count(~==A.~)>0),其中的~缺省表示B的当前成员,而另一个要显式地写成A.~以示区分。

面向结构化数据计算时可以直接引用字段名,这时也可能产生内外层的歧义,也可以适用于就近原则,SQL就是这样。当内外层表有相同字段名时,则缺省被认为是内存表的字段,引用外层表的同名字段时必须显式地写上表名;如果内外存表中没有相同字段名,则可以正确识别出来而不必书写表名。

遍历运算虽然很基本,但设计其语法时仍有一些注意事项。SQL在这方面总体表现不错,除了缺乏泛型成员的集合外,用于描述常规遍历运算还是比较方便简捷的。

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

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

时间: 2024-09-19 09:05:10

数据蒋堂 | 常规遍历语法的相关文章

【数据蒋堂】第21期:常规遍历语法

遍历可以说是最基本的集合运算了,比如求和.计数.寻找最大最小值等聚合运算,按条件过滤集合.根据集合成员生成另一个新集合,也都是遍历运算.集合化语法要求我们能用很短的语句(经常就只有一句,而不是若干语句构成的一段程序)来描述大部分遍历运算,这样我们需要考查遍历运算中可能出现的各种常见情况,并设计出合理自洽的语法规则. 我们从简单到复杂来考查遍历运算中的可能情况,并讨论SQL语法在这方面的表现. 1. 直接针对集合成员运算 比如计算集合成员的合计. 这是最简单的情况,采用普通的函数语法风格就可以,将

数据蒋堂 | 从SQL语法看离散性

所谓离散性,是指集合的成员可以游离在集合之外存在并参与运算,游离成员还可以再组成新的集合.从离散性的解释上可以知道,离散性是针对集合而言的一种能力,离开集合概念单独谈离散性就没有意义了. 离散性是个很简单的特性,几乎所有支持结构(对象)的高级语言都天然支持,比如我们用Java时都可以把数组成员取出来单独计算,也可以再次组成新的数组进行集合运算(不过Java几乎没有提供集合运算类库). 但是SQL的离散性却很差. SQL体系中有记录的概念,但并没有显式的记录数据类型.单条记录被SQL作为只有一条记

【数据蒋堂】第28期:迭代聚合语法

我们讨论过的常规聚合运算如SUM/COUNT和非常规聚合运算如maxp/top,都是事先设计好的聚合函数.但如果我们想实现一个以前没有定义过的运算怎么办?是否可以用已有的语法和函数组合出来?比如想做连乘运算,显然这也算是一种聚合. 要设计这样的语法方案,我们来看看这些聚合结果值是如何被程序计算出来的. SUM:先设置一个初始值0,然后遍历集合的每个成员,每次将成员值加到初始值上,直到成员被遍历完.COUNT:设置初始值0,遍历集合成员,每次碰到非空成员将初始值加1,直到遍历完.AVERAGE:这

【数据蒋堂】第19期:从SQL语法看集合化

SQL作为最常用的结构化数据计算语言,虽然在做一些细致处理时不太方便,但用于描述基本运算还是比Java等高级语言要简单许多.这是因为SQL是一种集合化的语言,而Java等语言不是.我们下面从SQL的语法上看集合化语言的一些特征,为了方便讨论,我们就用Java作为参照语言,其它高级语言是类似的. 集合运算能力 结构化数据经常是批量(以集合形式)出现的,为了方便地计算这类数据,程序设计语言有必要提供足够的集合运算能力. Java等高级语言则没有直接提供集合运算类库,虽然也有数组(相当于集合)数据类型

【数据蒋堂】第20期:从SQL语法看离散性

所谓离散性,是指集合的成员可以游离在集合之外存在并参与运算,游离成员还可以再组成新的集合.从离散性的解释上可以知道,离散性是针对集合而言的一种能力,离开集合概念单独谈离散性就没有意义了. 离散性是个很简单的特性,几乎所有支持结构(对象)的高级语言都天然支持,比如我们用Java时都可以把数组成员取出来单独计算,也可以再次组成新的数组进行集合运算(不过Java几乎没有提供集合运算类库). 但是SQL的离散性却很差. SQL体系中有记录的概念,但并没有显式的记录数据类型.单条记录被SQL作为只有一条记

【数据蒋堂】第18期:SQL用作大数据计算语法好吗?

当前的大数据平台在处理结构化数据时大都仍然以提供SQL语法为主流.兼容SQL的好处是很明显的,SQL的应用非常广泛,会SQL的程序员很多,如果继续采用SQL则可以避免许多学习成本.支持SQL的前端软件也很多,使用SQL的大数据平台很容易融入这个现成的生态圈中.大数据平台打算替代的传统数据库也是SQL语法的,这样兼容性会很好,移植成本相对较低. 但继续使用SQL也有缺点,最大的问题就是难以获得大数据计算最需要的高性能. 我们在前面的文章中提到过,SQL中缺乏一些必要的数据类型和运算定义,这使得某些

数据蒋堂 | SQL用作大数据计算语法好吗?

当前的大数据平台在处理结构化数据时大都仍然以提供SQL语法为主流.兼容SQL的好处是很明显的,SQL的应用非常广泛,会SQL的程序员很多,如果继续采用SQL则可以避免许多学习成本.支持SQL的前端软件也很多,使用SQL的大数据平台很容易融入这个现成的生态圈中.大数据平台打算替代的传统数据库也是SQL语法的,这样兼容性会很好,移植成本相对较低. 但继续使用SQL也有缺点,最大的问题就是难以获得大数据计算最需要的高性能. 我们在前面的文章中提到过,SQL中缺乏一些必要的数据类型和运算定义,这使得某些

数据蒋堂 | 有序分组

我们知道,SQL延用了数学上的无序集合概念,所以SQL的分组并不关注过待分组集合中成员的次序.我们在前面讨论过的等值分组和非等值分组,也都没有关注过这个问题,分组规则都是建立在本身的成员取值本身上.但如果我们要拓展SQL,以有序集合为考虑对象时,那就必须考虑成员次序对分组的影响了,而且,现实业务中有大量的有序分组应用场景. 一个简单的例子:将一个班的学生平均分成三份(假定人数能被3整除).按我们在前面所说的分组定义,这也可以看成是一种分组,但这个运算在SQL中却很难写出来,因为分组依据和成员取值

【数据蒋堂】第27期:非常规聚合

标准SQL中提供了五种最常用的聚合运算:SUM/COUNT/AVG/MIN/MAX.观察这几个运算,我们发现它们都可以看成是一个以集合为参数返回单值的函数,我们就先把这个共同点理解为聚合运算的定义,把集合变成单值,多个值变成一个值,也就是发生了"聚合",所以叫聚合运算. 那么很显然,有集合的时候就可以应用聚合运算了,所以SUM/COUNT这些运算可以针对一个数据表(记录集合)实施. 分组运算的结果是一批分组子集,那么每个子集上也可以应用聚合运算,这也就是SQL的分组运算了.其实针对全集