zoukankan      html  css  js  c++  java
  • 透视表与传统意义上的表

    通常来说OLTP系统里无论什么样的查询语句查询出的结果都是一个二维的表,OLAP里一个MDX抛出去返回过来的大多数都是一个透视表.这篇文章阐述本人对其的理解并且简要的说说他们的不同.

    概念阐述:

    OLTP:联机事务处理,就是我们通常所说的业务系统,实现数据库增删查改的那些操作.

    OLAP:联机分析处理,专门做分析用的,这里特指多维数据集.

    从结构上来说,我们传统意义所说的表与透视表示不同的.如果说表是一个平面的结构的话,那么透视表就是一个比较复杂的多维结构.

    举个例子,针对于人口信息系统,我们可以抽象出一些这样的信息:

    行政区划,婚姻状况,兵役状况,户口类型,就用这些信息来阐述了.

    OLTP系统里,我们可以很容易的统计所有婚姻情况的人数,或者所有兵役状况的人数,或者所有户口类型的人数,但是统计行政区划的人数可能就不容易了,因为行政区划通常分三个层次:--.这样的查询语句写起来,写起来简单,但你往往无法确定用户到底是要按照什么方式来统计,??还是区?.OLTP里你可以把婚姻状况,兵役状况,户口类型这样的信息作为一个字段进行查询,但是如果用户不告诉你行政区划到底是按省还是市或者区的方式进行查询的话,你这个查询语句写起来就很为难,因为很明显直接把行政区划作为一个字段全部把其列出来这样的查询意义不大,除非具体制定哪个省或者哪个市或者哪个区.而在OLAP系统中,我们通常就不用考虑这些,直接把行政区划放上取,用户就直接可以根据自己的需要查看自己想要查看的信息.

    在这里面再说说数据仓库系统里的几个概念(个人理解,欢迎来拍砖):

    先说粒度,粒度在网上和教科书中有很多种解释方法,不过说的都很抽象,在这里,,我们可以简单的理解为信息的精确程度,和小学里学的小数点后面精确到第多少位差不多.比如时间,老百姓记录天气温度以天为单位就可以了,而对于气象部门就不能以天为单位观察,记录和测量温度情况,可能要精确到小时或者分秒.在上面所说的人口信息系统里面,对于行政区划这样一个信息,通常精确到区的单位,比如吉林省长春市高新技术开发区.

    有粒度了然后自然就会产生层次这个概念.对于没有层次的信息谈论粒度也就没什么意义了,好比一个团队里终究是需要一个项目经理来管理,然后项目经理往上还有领导.那么好比行政区划这个信息,基本上就是一个省管理若干个市,一个市管理若干个区.层次最底层的就是其粒度.

    再回过头来看传统意义表与透视表的区别.传统意义上的表上,如果把行和列理解成不同的轴的话,那么我们会发现,这些轴都只有一个层次,比如兵役状况或婚姻状况,而透视表就不同了,其轴上的信息可能是具有很多层次的,比如行政区划.

    所以透视表的其中一个魅力就在于,用户可以根据当前看到的信息逐层的查看细节,假如我查看全国人口分布情况,这时候行政区划肯定是以省为单位列举出来的,然后要看吉林省下的人口分布情况,点下吉林省,吉林省下的各个市的人口分布境况就列举出来了,然后我再想看长春市,于是长春市各区的人口情况就都列举出来了.而这样一个功能对很多用户来说都有很强的吸引力.

    透视表的这些特性,我们传统意义上的表也可以通过SQL查询实现,因为在现在奇人辈出的年代,用汇编语言都能实现面向对象,所以我们不能绝对的说什么东西是不可能的,只不过在这种查询细节的实现中,SQL语句写的方式就要复杂那么一点.

    另外也是因为这样的区别,在透视表上实现DrillThrough to Detail这样的功能,直接从数据库里查就变得很不合适(本段为个人观点,欢迎拍砖),相比之下从多维数据集本身钻取就合适很多.关于这个问题,很多从事业务系统开发的老项目经理都和我争论过为什么不直接走数据库查询,因为他们觉得把一些细节数据聚合到多维数据集中似乎有点不大合适.但是,因为透视表中一个轴上的信息很有可能是带有很多层次的,比如一个透视表的一个轴上放置着行政区划信息,当前层次是省,我要看这个省下有哪些人(注意不是有多少人了),那么如果是走多维数据集里的DrillThrough函数的话,系统会自动把这个省下的所有市和区的数目都加到一起然后返回一个平面数据过来.而如果这个查询是要在数据库里实现的话,那么把这个省下的所有市以及关联到的所有区的信息都返回回来,可想而知这个查询会有多复杂.说到头来就好比我们写程序一样,既然有人替我们实现了一个接口下的所有方法了,那么我们就没有必要再去自己实现那个接口了,除非是极特殊的情况,否则直接拿已经实现好的来调用就行了.

    另外一个比较有意思的概念.我们知道在OLTPOLAP系统相对应的T-SQLMDX中,都有Where这么个筛选功能,OLTP中的就不用多说了,值得一说的是MDX中的这个Where.在数据仓库中有切片切块这两个概念,刚开始接触这个技术的时候,看书上描述的概念很是抽象,尽管有图,但后来发现,其关键处就是在于,切片是Where后面只有一个筛选条件,而切块后面是多个筛选条件.于是就诞生出了这两个概念.而在T-SQL中的Where似乎就没有这么多说道.特意拿出来说一下,因为这是从学电脑那天开始接触相关的知识和概念,感觉最有意思的其中之一.不过也所谓简约不简单(好像是哪句广告词),毕竟传统意义上的表与透视表有着很多不同,所以想要从一个抽象的角度来理解还是不那么容易的.

    以上是对于某一知识点的一些个人的理解,相关的概念就和文言文一样,看起来累,想要转化成白话文还需要一翻功夫,关键还是大家在一起交流,所以写出来一来算是分享,二来希望得到境界更高的前辈们帮我纠正错误,三是希望能看到二中所提到的前辈们对于某些细节的个人理解,这些我相信对于个人以及大家一定会有帮助.博客园里讨论商业智能的朋友不是很多,不过还是很高兴能看到更多的朋友参与进来,活跃社区里的气氛.

  • 相关阅读:
    《人类简史》八、融合统一(下)——宗教的法则、历史的混沌
    《今日简史》七、融合统一(中)——帝国的愿景
    《人类简史》六、融合统一(上)——历史的方向、金钱的味道
    《人类简史》五、监狱高墙——想象构建的秩序
    设计模式之职责链模式(Chain of Responsibility)
    设计模式之代理模式(Proxy)
    设计模式之享元模式(FlyWeight)
    设计模式之外观模式(Facade)
    设计模式之装饰模式(Decorator)
    设计模式之组合模式(Composite)
  • 原文地址:https://www.cnblogs.com/aspnetx/p/850309.html
Copyright © 2011-2022 走看看