从SQL出发看BIEE- 谨以此文向咖啡姐致敬！

        刚毕业的时候曾经被前辈误导，以为什么都要“精通”一些才好找工作，到最后是什么都懂一点点，什么都不精通，广度虽然有了但深度却没有，沦落到一个万能打杂的角色，个人能力提高和￥提升软弱无力。现在回头再看走过的路，应该是专精于一门技术，然后再涉猎其它相关的技术知识，应该从深度到广度这样的提升。

        作为一个半道入行BIEE的人来说，当初开始学BIEE是很痛苦的一段经历。曾经很困惑，如果从SQL的角度去理解，去看BIEE的相关功能，会否能够快速上手。查找N多文章，万能的度娘也瞎火了，天朝的网络如此干净，翻墙后面对26个认识的字母组合起来一知半解的E文，真是一个头两个大。苦于没有这方面的资料，只能依靠咖啡姐的视频教程入门后自己慢慢研究。

        希望诸君阅读后不会感觉浪费时间，那就大善。下面进入正题。
Part I: 数据库中的表和BIEE中的表

        话题1： 销售额500W
        在我们现实中，我们都会面对这样一个话题，针对“销售 500W”，我们会问出很多问题，单独看销售额500W，好像有意义，又没有意义，这个结果是表示好呢？还是不好呢？发生的主体是什么？
         如果是一个人一天的销售额，我们可能会有个感觉会很好；如果是一个公司呢？可能会觉得还凑合；如果公司10年销售额呢？又会觉得很差；
        如果放在数据库的一张表里，我们用SQL写就是select 500w from table
        如果在BIEE里面，本质也是一样，我们在分析里面，找到相关的表示表的字段，拖出来，然后BIEE会自动转换为逻辑SQL，然后转换为大体相同的SQL语法。
        那么这个 销售额500W到底是什么呢？其实也就是BIEE中我们说的事实表中用来统计的“度量”。

        话题2：小张销售额500W
        这个话题和话题1比较类似，多了个限定词“小张”，那么我们还会问出话题1类似的问题。这句话到底要表达什么意思？好的？坏的？
        如果是数据库里描述，我们可能是一张表就记录这段描述。如果不仅仅是小张呢？还有李四、王五、马六等等呢？我们可能会基于数据库的元组特性什么的，建立两张表，一张记录人员表，一张记录销售表，两表之间设置关联关系。如果人员有多个小张呢？于是引申出来人员ID来标识唯一的关系，然后对应的销售表记录对应的销售人员ID。
        那么用SQL伪代码应该是 select a.名称,b.销售额 from 人员表 a，销售表 b where a.ID=b.ID 
        换成BIEE呢？其实大体还是类似，物理层也是引入两张表，设置两张表的关系为a.ID=b.ID ，然后把a.名称,b.销售额拖至表示层，然后在前端answer里面展示 名称 销售额 ，即可达到类似SQL的查询效果。
        那么这个人员表又是什么呢？在BIEE里面我们称之为“维度”，也就是我们看问题的角度，我们引申一下，比如说小张在2015年1月份销售500w，那么我们可以多添加一个时间表，然后在销售表设置外键关联字段记录销售时间，在BIEE里面我们就可以把时间表称为“时间维”，这个时间维和人员维只是我们看问题角度，也可以说是维度，可以一次用一个维度来看度量，也可以一次多个维度来看度量。
        以目前的话题来说，那么以时间维的角度看就是2015年1月销售500w，以人员维的角度看就是IDXXX的小张销售500w，以时间维+人员维的角度来看就是IDXXX的小张在2015年1月销售500w。那么我们还可以引申出更多的维度，比如说IDXXX的小张于2015年1月在上海销售500w，引入地区维的概念；IDXXX的小张于2015年1月在上海销售某产品500w，引入产品维的概念；等等诸如此类的维度。
        
        话题3：小张、李四、王五等是一个公司的，分属不同的部门，各自有不同的上司A、B、C，上司还有另外的公司领导BOSS；地区如果按国内惯例就是国家-省-市-区县-村等等；
        这个话题就涉及到数据库中反映现实中的层级的概念以及归属的、父子的概念。
        假设现在要统计上面说的各自的上司A\B\C的销售情况，上司A\B\C本身属于员工，也会有业绩的，那么这个时候如果按员工层级统计，那么就是统计各自的销售额，这种情况很简单，关联人员表和销售表正常统计即可；
        如果统计上司A\B\C的时候，要求上司要包含下属的所有销售额，就好像统计公司BOSS的销售其实是包含所有的销售一样；这个时候，就需要根据上下级的从属关系，再加上其下属的所有销售额即可。
        当这样的需求产生的时候，我们一般有几种做法，一种是扩张人员表成层级表，增加各自员工的上级，我们的实例很简单，就3层，BOSS-->A\B\C-->小张、李四、王五等。这样就产生了层级的概念，A\B\C即是小张、李四等的第2层级，也是他们自己的第2层级，直接关联人员表和销售表，按第2层级统计销售额即可。
        第二种做法就是建立辅助关系表，记录人员的对应关系，保持原来的人员表不变化，然后通过关联人员表、对应关系表、销售表，统计需要的销售额即可。
        那么对应到BIEE的又是怎么样的情况呢？
        第一种就是普通的层级维的概念，按需要的层级统计需要的数据即可；
        第二中就是父子维的概念，我们的那张对应关系表就相当于BIEE中的父子关系表，根据这个关系和原来的人员表可以组成父子维，然后用父子维和销售事实表去统计所需数据即可。
        
        这里再提下BIEE中的不平衡维和越级维的概念
        拿地区表来举例。比如按理想中的情况下划分 国家-省-市-区县-村，那么每一级都有对应的层级，但实际上中国下面就直接是北京市，没有北京省的概念，那么在树形上就表现为所有的叶子节点不一定是最后一个层级，就是所有的叶子节点路径长度不是一样，就好像树没有长平衡的样子。这种情况在BIEE中称为不平衡维。
        再拿产品线的实例说明下情况，比如一般是产品线-->产品族-->产品的3个层级，但有些产品会直接挂在产品线下面，省略了产品族的这个层级，表现为所有的叶子节点是同一个层级，但中间层可能有断层。这种情况在BIEE中称为越级维。        
        针对上面情况，数据库我们可以把没有数据的节点空置出来，然后查询的时候仅仅列出所需的数据即可。
        但BIEE中层级维度有下钻的概念，如果某一级断了，没有数据，就下钻不到那一级数据了。这个时候就要勾选 那个不平衡维或越级维的选项，以特殊处理那部分数据。
        BIEE的维度还有个特殊的选项，时间维，那么这个为什么又单独拿出来作为一个属性来限定呢。
        其实时间维和普通的层级维是一样的概念，为什么单独拿出来，就是因为我们对于时间经常会有一些特殊的用途，比如针对年这个曾经，我们经常把今年和去年的度量数据做同比，或者这个月和上个月的度量数据做环比，以看趋势。如果让我们用SQL做同比或者环比的概念，我们肯定是先拿到各自需要对比的结果集，然后通过时间上的关系去关联对比度量数据。那么BIEE做的比较智能的东西就是通过时间函数的调用，在后台自动换算了完成这部分功能，所以增加了时间维的属性。如果你在BIEE的前端跟踪抓取执行的时间维函数的SQL可以看到，会有时间换算的部分代码。

        在这里扯一个概念。经常有人老是混淆同比和环比，其实很简单的。看字面就很好明白。同比就是相同的去比较，环比就是挨着的比较，好像一环套一环一样。比如一般我们2说015年5月的同比就是和2014年5月去比较；环比呢？2015年5月和2015年4月去比较就是2015年5月的环比。
        再扯一句，我们怎么区分一个表是事实表还是维表？在BIEE里面也就是我们设置表关联的时候，箭头指向，或者说是1：N的设置，1就是维表，N就是事实表，箭头的是维表，尾巴的就是事实表。而不是看是否有度量。其实有时候度量的概念也是比较让人糊涂的。比如说一个我们所谓的事实表还是可以拿去做维表用的，我们给它建立别名，让其自己和自己关联，这样一个是事实表，一个是维表。 
 
Part II：表和表之间的连接
        在数据库中你可以不定义表和表之间的关系，在语句中指明表和表之间的关联条件即可。如果不在语句指定连接关系，那么就是笛卡尔积的形式展示数据。当然你也可以在数据库指定表和表之间的关联关系，那么就设置表和表之间的外键关联。
        在BIEE中，因为在前端仅仅拖动一个个字段就完成了这个过程，那么表和表之间的关系是在哪里定义呢？难道也是笛卡尔积的形式？肯定是有地方定义的。这个地方就是RPD的物理层。物理层就是定义表和表之间关系的地方。
        这个时候有人会问，为什么大拿一个个都建议我要先建立别名，然后再设置表关联呢？
        当初我也曾经有这样的疑问，后来随着接触的越来越多，逐渐就不会问这样的问题。举个例子，我们常见的订单表，一张订单记录可能记录了订单产生日期，供应商应预计送货日期，订单收货日期等等。而我们的时间表就一张，我们在数据库要一次展现这3个时间，那么从事实表出数据即可。可如果都要把时间换算成不是事实表存储的形式呢？比如说事实表存储的是20150405这样的，需要展示的是2015年4月5日，本年第几周等等附加时间属性呢？这个时候用SQL来编写就是把时间表做各个别名，然后各自关联事实表取出需要的数据。那么BIEE也是进行了这样的设置操作，需要几个时间表代表几个意思就建立几个时间维表或者建立几个时间维别名表去关联事实表。
        别名表仅仅是这样的作用么？如果当你的RPD的表上到一个数量级的时候，你想查找某个表的时候，你头估计会大一圈的。这个时候别名表就可以起到很好的作用，比如按项目建立文件夹，然后把各个别名表归来拖至项目文件夹。别名表按某规则排序，这样查找起来就会很方便。当然还有时候，数据库的表名称不能很好的代表实体的意思，我们可以在别名中很好的标识，让我们更容易识别出该表。
        
Part III: 语句级 
        数据库的一个常见的语句我们都知道有select、from、where、group by、order by等。那么对应在BIEE中就是select对应分析中的字段列表；from就对应字段列表对应的表，会在BIEE后台自动转换的时候添加上；where子句对应分析中的过滤器；group by对应我们在rpd中逻辑层设置的度量的级别；order by对应我们在分析中字段中设置的排序；
        有人也许会问我们用的select的是RPD的表示层的数据，BIEE会自动转换成物理层映射的列，那么还要RPD的逻辑层做什么？
        存在即是合理的，为什么是三层，不是两层或者四层呢？其实逻辑层起到了一个包装、定义的功能。比如我们在SQL语句中，经常会写把某几个表关联的结果集，然后再和某些表关联去取某些数据，或者设置某表和某表左关联取某些数据。这些都是在RPD中的逻辑层设置的。那些你看着很神奇的功能都是在这里默默的做着后台支持工作的。
        先说我们熟悉的SQL，from ( TABLEA A JOIN TABLE B ON A.ID=B.ID) C JOIN TABLED D ON......
       看到上面的语句是不是很熟悉，我们期望把TABLEA和TABLEB关联起来看成是表C，然后再和TABLED去关联，那么 “把TABLEA和TABLEB关联起来看成是表C” 这个玩意就是在RPD的逻辑层设置的，我们在BIEE中叫逻辑表源，比如你拖了TABLEA，然后再把TABLEB拖至逻辑表源TABLEA上，这个时候就会弹出来一个窗口让你设置两个表之间的关联关系，在这里可以设置内连接，左连接，右连接之类。然后你把逻辑表源TABLEA修改成C，这样就和SQL的效果是一致的了，当然你还可以依照上面的步骤把TABLED也拖进去集成。
        再说包装的概念。比如原来在SQL中我们这样写 select ....(a+b)*c/d*100....当然在BIEE中我们就有两个选择，一个就是在前端的分析中列公式中这样写(a+b)*c/d*100，如果有100个这样的地方就需要写这样的公式100次，如果某天这个公式要修改为(a+b+3)*c/d*100，那么你可以哭了，如果你不知道要修改100出，只修改了99处，恭喜你，中奖了。那么避免的方法就是在RPD的逻辑层把(a+b)*c/d*100定义为一个新的逻辑列G，然后拖至表示层展示，在原来需要(a+b)*c/d*100的地方用G代替，如果公式变更了，在RPD逻辑层把G对应的公式变更即可。
       至于说把公式落在后台RPD中还是落在前台的列公式中，这个还是仁者见仁智者见智的。落在前台就比较可以清晰的反映出公式逻辑，但修改的时候就比较麻烦，容易遗漏，落在后台就看不到公式逻辑，但修改就不会容易遗漏。
        再说定义的概念。如果我们要某个字段针对某个级别的汇总，我们会在SQL中先按那个级别Group By，然后再使用，那么在BIEE中就是在度量中指定对应某个维度的某个层级即可。在前端展现其对字段时候，BIEE会自动转换做到这样功能。但这里要记得一点，展示的层级比度量定义的层级低，那么度量的层级会覆盖展示的层级，展示的层级比度量的定义的层级高，那么度量定义的层级会被覆盖。举个例子，如果设置某字段A，聚合规则为SUM，针对时间维设置了月份级别；那么如果页面展示日期为天和字段A，这个时候，该月每天后面的字段A值是相同的，比如1月是某个相同的值，2月是某个值；如果页面展示日期为年和字段A，这个时候，年后面的A是按年级别展示汇总的，年的级别比月高，覆盖掉了A的定义的级别。这个原理其实在SQL中也是同样的逻辑，自己脑补下日月年层级对应事实表的数据记录统计，或者手工写下子查询实现吧。
        这里叨一句为什么所有的维表都要建立维度呢？一个是为了更好的设置度量对应的汇总级别，另外一个就是在前端展示hierarchy层级列。那有人又会问了，为什么要把建立的维度拖到表示层呢？其实就是为了在前端展示hierarchy层级列或者在前端使用时间序列函数。如果不把时间维的hierarchy列拖至表示层，那么只能在RPD的逻辑层使用时间序列函数，在前端是使用不了时间序列函数的，这个时候如果你强制在列公式写时间维级别，会报错的。

Part IV:变量 
        数据库中的变量就没有什么可说的了。谁用谁知道。
        在BIEE中有表示变量、请求变量、资料库变量、静态变量、动态变量、初始化块等相关概念；
        先说表示变量，根据字面意思，表示变量就是表示某个东西的变量，就好像我们在数据定义i表示4一样，那么在变量的生效范围内i就和4划上了等号。那么在BIEE的页面中，表示变量也大体是这个意思，如果你在提示器定了一个变量，那么在下面的分析就可以使用该变量的值。
        请求变量，根据字面意思就是请求了以某变量来代表某个东西，如果你请求了，后台服务器给你了反馈，这样就完成了一个请求的过程。请求变量大体也完成了这样的功能。BIEE中请求变量就是在前端页面中定义了某请求变量，后端PRD中使用同名变量定义某度量，然后在前端使用该度量的时候，就完成了一个请求变量的过程。前端-->RPD解析-->反馈到前端实现。
        资料库变量，根据字面意思就知道是资料档案库的变量。资料档案库你不知道是什么？那么再去补习下基本功课吧。
        资料库变量又分为静态变量和动态变量。根据字面意思很好理解的了。静态变量就是一经定义就不会变化的。动态变量就是虽然经过定义，但其结果值会实时变化的。
        那么初始化块又是什么意思呢？就好像我们在数据库中定义一个变量，如果你要使用，也要经过初始化赋值一样，那么在BIEE中初始化块就大体相当于这样的功能。比如你在数据库定义了变量，然后通过select表某字段值赋值给该变量。那么BIEE中的静态变量和动态变量也是这样来的。通过在初始化块中定义的语句来给变量初始化。

暂时写这么多吧。本机的BIEE环境被我重做系统干掉了，回头我抽空补图。 
再次表示感谢！谨以此文向咖啡姐致敬！