over在聚合函数和排名函数中的运用

OVER子句

  OVER子句用于为行为定义一个窗口(windows),以便进行特定的运算。可以把行的窗口简单地认为是运算将要操作的一个行的集合。例如,聚合函数和排名函数都是可以支持OVER子句的运算类型。由于OVER子句为这些函数提供了一个行的窗口,所以这些函数也称之为开窗函数。

  聚合函数的要点就是要对一组值进行聚合,聚合函数传统上一直以GROUP BY查询作为操作的上下文。在前面的“GROUP BY”子句的讨论中,我们知道在对数据进行分组以后,查询为每个组只返回一行;因此,也就是要限制所有的表达式为每个组只能返回一个值。

  聚合开窗函数使用OVER子句提供窗口作为上下文,对窗口中的一组值进行操作,而不是使用GROUP BY子句提供的上下文。这样就不必对数据进行分组,还能够在同一行中同时返回基础行的列和聚合列。为了理解OVER子句,现在考虑Sales.OrderValues视图,现在只要简单地把视图看作是一个表就可以了。Sales.OrderValues视图的每一行代表一个订单,包含订单ID(orderid),客户ID(custid)、雇员ID(empid)、承运人ID(shipperid)、订单日期(orderdate),以及订单价格(val)。

  带有空括号的OVER子句会提供所有行进行计算。这里的“所有行”并不一定是在FROM子句中出现的那些表中的所有行,而是在FROM、WHERE、GROUP BY,以及HAVING处理阶段完成后仍然可用的那些行。注意,只有在SELECT和ORDER BY处理阶段才允许使用OVER子句。这里只中点介绍在SELECT处理阶段如何使用OVER子句。例如,如果在对OrderValues视图进行查询的SELECT子句中指定了SUM(val) OVER()表达式,这个函数就会对SELECT阶段操作的所有行计算其总价格。

  如果查询在SELECT阶段之前没有过滤数据,也没有应用其他的逻辑阶段,这个表达式将返回OrderValues视图中所有行的总价格。如果想对行进行限制或分区,则可以使用PARTITION BY子句。例如,现在不想返回OrderValues中所有行的总价格,而只是想返回当前客户(和当前行具有相同custid的所有行)的总价格,则可以指定SUM(val) OVER(PARTITION BY custid)。

  以下查询可以返回OrderValues的所有行,并且演示了同时使用非分区和分区表达式的方法。此外,每一行除了基本列以外,查询还会返回所有行的总价格和当前客户的总价格:

   
   
1 SELECT orderid,custid,val, 2 SUM (val) OVER () AS totalvalue, 3 SUM (val) OVER (PARTITION BY custid) AS custtotalvalue 4 FROM Sales.OrderValues;

  这个查询返回以下结果:

  所有结果行的totalvalue列表示所有行的价格总数。custtotalvalue列表示所有行中与当前行具有相同custid值的那些行的价格总数。

  OVER子句的一个优点就是能够在返回基本列的同时,在同一行对它们进行聚合;也可以在表达式中混合使用基本列和聚合值列。例如,以下查询为OrderValues的每一行计算当前价格占总价格的百分比,以及当前价格占客户总价格的百分比。

   
   
1 SELECT orderid, 2 ROW_NUMBER() OVER ( ORDER BY val) AS rownum, 3 RANK() OVER ( ORDER BY val) AS rank, 4 DENSE_RANK() OVER ( ORDER BY val) AS dense_rank, 5 NTILE( 10 ) OVER ( ORDER BY val) AS ntile 6 FROM Sales.OrderValues 7 ORDER BY val;

  该查询会生成以下输出:

  ROW_NUMBER函数用于为查询的结果集中的各行分配递增的序列号,其逻辑顺序通过OVER子句中的ORDER BY语句进行指定。在我们的查询例子中,逻辑顺序基于的是val列;因此,从输出中可以看到,随着订单价格的增加,行号也随之增加。不过,即使订单价格没有增加,行号也会依然增加。所以,如果ROW_NUMBER函数的ORDER BY不能唯一确定行的顺序(如前面这个例子所示),查询结果就是不确定的。也就是说,查询可能返回多个正确的结果。例如,可以看到订单价格为36.00的两行,它们的行号分别是7和8。如果这些行的顺序发生了变化,结果都可以认为是正确的。如果想让行号计算值是确定的,则必须在ORDER BY列表中添加元素,让它具有唯一性;也就是说,要让ORDER BY子句中列出的元素能够唯一地确定各个行。例如,可以在ORDER BY列表中增加orderid作为附加属性,这样,行号计算结果就成为确定的。

  前面提过,即使行的排序值相同,ROW_NUMBER函数也一定为其生成唯一的行号值。如果想以同样的方式对排序值中的相同值进行更多的处理,可以考虑使用RANK或DENSE_RANK函数。这两个函数与ROW_NUMBER类似,但它们为具有相同逻辑排序值的所有行生成同样的排名。RANK和DENSE_RANK的区别是:RANK表示之前有多少行具有更低的排序值,而DENSE_RANK则表示之前有多少个更低的排序值。例如,在我们的查询例子中,rank列为9表示前面有8行具有更小的排序值,dense_rank列为9表示前面有8个更小的不同排序值。

  NTILE函数可以把结果中的行关联到组(tile,相当于由行组成的指定数目的组),并为每一行分配一个所属的组的编号。NTILE函数接受一个表示组的数量的输入参数,并要在OVER子句中指定逻辑顺序。我们的查询例子有830行,请求将其分成10组;因此,组的大小就是83(830除以10)。逻辑排序基于的是val列,这意味着价格最低的83行将分在第1组,接下来的83行将分在第2组,在接下来的83行将分在第3组,以此类推。NTILE函数在逻辑上需要依赖于ROW_NUMBER函数。整个过程是先根据对val的排序结果,为每一行分配行号;在基于前面计算好的组的大小83行,将第1行到第83行分配到第1组,将第84行到第166行分配到第2组,以此类推。如果组数无法整除表的行数,余数(remainder)中的每一行会被分配到最前面的每个组。例如,假设有102行,请求分成5组,那么前两组将有21行而不是20行。

  和聚合开窗函数类似,排名函数也支持在OVER子句中使用PARTITION BY语句。以排名计算作为背景,理解PARTITION BY子句的含义可能要更容易些。例如,与在整个集合中分配行号不同,表达式ROW_NUMBER() OVER(PARTITION BY custid ORDER BY val)为各行中具有相同custid的子集独立地分配行号。在以下查询中使用了这个表达式:

   
   
1 SELECT DISTINCT val,ROW_NUMBER() OVER ( ORDER BY val) AS rownum 2 FROM Sales.OrderValues;

  输出结果如下所示:

  ROW_NUMBER函数是在DISTINCT子句之前处理的。首先,为OrderValues视图中的830行分配唯一的行号。接着再处理DISTINCT子句,所以这时不会有任何重复的行要删除。可以认为在同一SELECT子句中不能同时指定DISTINCT和ROW_NUMBER是一个最佳实践原则,因为DISTINCT子句在这种情况下不起任何作用。如果想要为795个唯一值分配行号,那就需要采用其他不同的解决办法。例如,因为GROUP BY阶段是在SELECT阶段之前处理的,可以使用以下查询:

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


什么是设计模式一套被反复使用、多数人知晓的、经过分类编目的、代码 设计经验 的总结;使用设计模式是为了 可重用 代码、让代码 更容易 被他人理解、保证代码 可靠性;设计模式使代码编制  真正工程化;设计模式使软件工程的 基石脉络, 如同大厦的结构一样;并不直接用来完成代码的编写,而是 描述 在各种不同情况下,要怎么解决问题的一种方案;能使不稳定依赖于相对稳定、具体依赖于相对抽象,避免引
单一职责原则定义(Single Responsibility Principle,SRP)一个对象应该只包含 单一的职责,并且该职责被完整地封装在一个类中。Every  Object should have  a single responsibility, and that responsibility should be entirely encapsulated by t
动态代理和CGLib代理分不清吗,看看这篇文章,写的非常好,强烈推荐。原文截图*************************************************************************************************************************原文文本************
适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题,总结出来的一套通用的解决方案。
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容易使用。
单例模式(Singleton Design Pattern)保证一个类只能有一个实例,并提供一个全局访问点。
组合模式可以将对象组合成树形结构来表示“整体-部分”的层次结构,使得客户可以用一致的方式处理个别对象和对象组合。
装饰者模式能够更灵活的,动态的给对象添加其它功能,而不需要修改任何现有的底层代码。
观察者模式(Observer Design Pattern)定义了对象之间的一对多依赖,当对象状态改变的时候,所有依赖者都会自动收到通知。
代理模式为对象提供一个代理,来控制对该对象的访问。代理模式在不改变原始类代码的情况下,通过引入代理类来给原始类附加功能。
工厂模式(Factory Design Pattern)可细分为三种,分别是简单工厂,工厂方法和抽象工厂,它们都是为了更好的创建对象。
状态模式允许对象在内部状态改变时,改变它的行为,对象看起来好像改变了它的类。
命令模式将请求封装为对象,能够支持请求的排队执行、记录日志、撤销等功能。
备忘录模式(Memento Pattern)保存一个对象的某个状态,以便在适当的时候恢复对象。备忘录模式属于行为型模式。 基本介绍 **意图:**在不破坏封装性的前提下,捕获一个对象的内部状态,并在该
顾名思义,责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为
享元模式(Flyweight Pattern)(轻量级)(共享元素)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结