MDX语句

MDX语句（MultiDimensionalExpressions）是一种语言，支持多维对象与数据的定义和操作。它可以表达在线分析出来数据卡上的选择、计算和一些元数据定义等操作，并赋予用户表现查询结果的能力。

示例：

                                                                                    Dimension.FIXED_RAILWAY.lineNameId.lineNameId@^cubeName^ as LineId,            Dimension.FIXED_RAILWAY.lineNameId.lineName@^cubeName^ as Line,                            Dimension.FIXED_RAILWAY.lineNameId.lineNameId@^cubeName^ as LineId,            Dimension.FIXED_RAILWAY.lineNameId.lineName@^cubeName^ as Line,            Dimension.FIXED_RAILWAY.segmentId.segmentId@^cubeName^ as            RoadSectionId, Dimension.FIXED_RAILWAY.segmentId.segment@^cubeName^            as RoadSection,                                            Dimension.FIXED_RAILWAY.lineNameId.lineNameId@^cubeName^ as LineId,            Dimension.FIXED_RAILWAY.lineNameId.lineName@^cubeName^ as Line,            Dimension.FIXED_RAILWAY.provinceId.provinceId@^cubeName^ as            ProvinceId, Dimension.FIXED_RAILWAY.provinceId.province@^cubeName^            as Province,                            Dimension.FIXED_RAILWAY.lineNameId.lineNameId@^cubeName^ as LineId,            Dimension.FIXED_RAILWAY.lineNameId.lineName@^cubeName^ as Line,            Dimension.FIXED_RAILWAY.provinceId.provinceId@^cubeName^ as            ProvinceId, Dimension.FIXED_RAILWAY.provinceId.province@^cubeName^            as Province,            Dimension.FIXED_RAILWAY.prefectureId.prefectureId@^cubeName^ as            CityId, Dimension.FIXED_RAILWAY.prefectureId.prefecture@^cubeName^            as City,                            Dimension.User.VIPUser.IMSI@^cubeName^ as Imsi,            Dimension.User.VIPUser.UserId@^cubeName^ as UserId,            Dimension.User.VIPUser.UserName@^cubeName^ as VipInfo,                             Dimension.User.VIPUser.vipgroupid@^cubeName^ as VIPGROUPID,                                                                ^kpiSql[].value^^kpiSql[].subTreeNodes[].value^                                        ^invalidKpiFilter[].value^^invalidKpiFilter[].subTreeNodes[].value^                                            ORDERBY ^columnSort^                                                (Dimension.time@^cubeName^=]]>^timeRange[].beginDateTime^                and Dimension.time@^cubeName^^timeRange[].endDateTime^)                                                    (Dimension.FIXED_RAILWAY.linkId.linkId@^cubeName^ = ^queryCon.direction^             or             Dimension.FIXED_RAILWAY.linkId.linkId@^cubeName^ = 3)                                    Dimension.FIXED_RAILWAY.linkId.linkId@^cubeName^ in (1,2,3)                                        Dimension.rat.rat.rat@^cubeName^=^queryCon.rat^                                        (Dimension.rat.rat.rat@^cubeName^=^queryCon.rat^            or            Dimension.rat.rat.rat@^cubeName^= 100)                                        Dimension.Vendor.Vendor.Vendor@^cubeName^=^queryCon.vendor^                                        (Dimension.Vendor.Vendor.Vendor@^cubeName^=^queryCon.vendor^            or            Dimension.Vendor.Vendor.Vendor@^cubeName^= 100)                       select                 Dimension.rat.rat.rat@^cubeName^ as rat,        Dimension.Vendor.Vendor.Vendor@^cubeName^ as vendor,        Dimension.time.Day@^cubeName^ as date,                from ^cubeName^                    Dimension.rat.rat.rat@^cubeName^ in (2,3,4,100),            Dimension.Vendor.Vendor.Vendor@^cubeName^ in (0,100),                                               select                 Dimension.rat.rat.rat@^cubeName^ as rat,        Dimension.Vendor.Vendor.Vendor@^cubeName^ as vendor,        Dimension.FIXED_RAILWAY.lineNameId.lineNameId@^cubeName^ as lineId,        Dimension.FIXED_RAILWAY.lineNameId.lineName@^cubeName^ as line,        Dimension.FIXED_RAILWAY.segmentId.segmentId@^cubeName^ as roadSectionId,        Dimension.FIXED_RAILWAY.segmentId.segment@^cubeName^ as roadSection,                                    from ^cubeName^                    Dimension.rat.rat.rat@^cubeName^ in (2,3,4,100),            Dimension.Vendor.Vendor.Vendor@^cubeName^ in (0,100),                                           select                 Dimension.rat.rat.rat@^cubeName^ as rat,        Dimension.Vendor.Vendor.Vendor@^cubeName^ as vendor,        Dimension.FIXED_RAILWAY.prefectureId.prefectureId@^cubeName^ as cityId,        Dimension.FIXED_RAILWAY.prefectureId.prefecture@^cubeName^ as city,                        from ^cubeName^                    Dimension.rat.rat.rat@^cubeName^ in (2,3,4,100),            Dimension.Vendor.Vendor.Vendor@^cubeName^ in (0,100),                                BNF范式和EBNF范式1、什么是BNF范式,什么又是EBNF范式?（在学习中经常会碰到用BNF范式描述的规则，老是忘记每个符号确切的作用，现在把他们一一罗列如下，亲手记录的东西应该能记住吧。。。-__-|||） 答：巴科斯范式及其扩展(BNF & Augmented BNF)1)巴科斯范式：巴科斯范式(BNF: Backus-Naur Form 的缩写)是由 John Backus 和 Peter Naur 首先引入的用来描述计算机语言语法的符号集。现在，几乎每一位新编程语言书籍的作者都使用巴科斯范式来定义编程语言的语法规则。2)巴科斯范式的内容： 在双引号中的字("word")代表着这些字符本身。而double_quote用来代表双引号。 在双引号外的字（有可能有下划线）代表着语法部分。 < > : 内包含的为必选项。 [ ] : 内包含的为可选项。 { } : 内包含的为可重复0至无数次的项。 |  : 表示在其左右两边任选一项，相当于"OR"的意思。 ::= : 是“被定义为”的意思3)扩展的巴科斯范式(Augmented BNF):RFC2234 定义了扩展的巴科斯范式(ABNF)。近年来在Internet的定义中ABNF被广泛使用。ABNF做了更多的改进，比如说，在ABNF中，尖括号不再需要。4)EBNF的基本内容：   "..." : 术语符号   [...] : 选项:最多出现一次   {...} : 重复项: 任意次数，包括 0 次   (...) : 分组     |   : 并列选项，只能选一个   斜体字: 参数，在其它地方有解释 例子BNF应用较多，以下给出一个简单例子，这是用BNF来定义的Java语言中的For语句的实例： FOR_STATEMENT ::=       "for" "(" ( variable_declaration |   ( expression ";" ) | ";" )       [ expression ] ";"       [ expression ] ";"       ")" statement数据库范式数据库范式是数据库设计中必不可少的知识，没有对范式的理解，就无法设计出高效率、优雅的数据库。甚至设计出错误的数据库。而想要理解并掌握范式却并不是那 么容易。教科书中一般以关系代数的方法来解释数据库范式。这样做虽然能够十分准确的表达数据库范式，但比较抽象，不太直观，不便于理解，更难以记忆。       本文用较为直白的语言介绍范式，旨在便于理解和记忆，这样做可能会出现一些不精确的表述。但对于初学者应该是个不错的入门。我写下这些的目的主要是为了加强 记忆，其实我也比较菜，我希望当我对一些概念生疏的时候，回过头来看看自己写的笔记，可以快速地进入状态。如果你发现其中用错误，请指正。       下面开始进入正题：一、基础概念       要理解范式，首先必须对知道什么是关系数据库，如果你不知道，我可以简单的不能再简单的说一下：关系数据库就是用二维表来保存数据。表和表之间可以……（省略10W字）。然后你应该理解以下概念：••实体：现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”，它也可以是虚拟的，不如说“老师与学校的关系”。•属性：教科书上解释为：“实体所具有的某一特性”，由此可见，属性一开始是个逻辑概念，比如说，“性别”是“人”的一个属性。在关系数据库中，属性又是个物理概念，属性可以看作是“表的一列”。•元组：表中的一行就是一个元组。•分量：元组的某个属性值。在一个关系数据库中，它是一个操作原子，即关系数据库在做任何操作的时候，属性是“不可分的”。否则就不是关系数据库了。•码：表中可以唯一确定一个元组的某个属性（或者属性组），如果这样的码有不止一个，那么大家都叫候选码，我们从候选码中挑一个出来做老大，它就叫主码。•全码：如果一个码包含了所有的属性，这个码就是全码。•主属性：一个属性只要在任何一个候选码中出现过，这个属性就是主属性。•非主属性：与上面相反，没有在任何候选码中出现过，这个属性就是非主属性。•外码：一个属性（或属性组），它不是码，但是它别的表的码，它就是外码。二、6个范式好了，上面已经介绍了我们掌握范式所需要的全部基础概念，下面我们就来讲范式。首先要明白，范式的包含关系。一个数据库设计如果符合第二范式，一定也符合第一范式。如果符合第三范式，一定也符合第二范式…第一范式（1NF）：属性不可分。在前面我们已经介绍了属性值的概念，我们说，它是“不可分的”。而第一范式要求属性也不可分。那么它和属性值不可分有什么区别呢？给一个例子：nametelage大宝1361234567822小明13988776655010－123456721Ps：这个表中，属性值“分”了。nametelage手机座机大宝13612345678021－987654322小明13988776655010－123456721Ps：这个表中，属性 “分”了。这两种情况都不满足第一范式。不满足第一范式的数据库，不是关系数据库！所以，我们在任何关系数据库管理系统中，做不出这样的“表”来。第二范式（2NF）：符合1NF，并且，非主属性完全依赖于码。听起来好像很神秘，其实真的没什么。一 个候选码中的主属性也可能是好几个。如果一个主属性，它不能单独做为一个候选码，那么它也不能确定任何一个非主属性。给一个反例：我们考虑一个小学的教务 管理系统，学生上课指定一个老师，一本教材，一个教室，一个时间，大家都上课去吧，没有问题。那么数据库怎么设计？（学生上课表）学生课程老师老师职称教材教室上课时间小明一年级语文（上）大宝副教授《小学语文1》10114：30一个学生上一门课，一定在特定某个教室。所以有（学生，课程）－>教室一个学生上一门课，一定是特定某个老师教。所以有（学生，课程）－>老师一个学生上一门课，他老师的职称可以确定。所以有（学生，课程）－>老师职称一个学生上一门课，一定是特定某个教材。所以有（学生，课程）－>教材一个学生上一门课，一定在特定时间。所以有（学生，课程）－>上课时间因此（学生，课程）是一个码。然而，一个课程，一定指定了某个教材，一年级语文肯定用的是《小学语文1》，那么就有课程－>教材。（学生，课程）是个码，课程却决定了教材，这就叫做不完全依赖，或者说部分依赖。出现这样的情况，就不满足第二范式！有什么不好吗？你可以想想：1、校长要新增加一门课程叫“微积分”，教材是《大学数学》，怎么办？学生还没选课，而学生又是主属性，主属性不能空，课程怎么记录呢，教材记到哪呢? ……郁闷了吧?(插入异常)2、下学期没学生学一年级语文（上）了，学一年级语文（下）去了，那么表中将不存在一年级语文（上），也就没了《小学语文1》。这时候，校长问：一年级语文（上）用的什么教材啊？……郁闷了吧?(删除异常)3、校长说：一年级语文（上）换教材，换成《大学语文》。有10000个学生选了这么课，改动好大啊！改累死了……郁闷了吧？（修改异常）那应该怎么解决呢？投影分解，将一个表分解成两个或若干个表学生课程老师老师职称教室上课时间小明一年级语文（上）大宝副教授10114：30学生上课表新 课程教材一年级语文（上）《小学语文1》课程的表  第三范式（3NF）：符合2NF，并且，消除传递依赖上面的“学生上课表新”符合2NF，可以这样验证：两个主属性单独使用，不用确定其它四个非主属性的任何一个。但是它有传递依赖！在哪呢？问题就出在“老师”和“老师职称”这里。一个老师一定能确定一个老师职称。有什么问题吗？想想：1、老师升级了，变教授了，要改数据库，表中有N条，改了N次……（修改异常）2、没人选这个老师的课了，老师的职称也没了记录……（删除异常）3、新来一个老师，还没分配教什么课，他的职称记到哪？……（插入异常）那应该怎么解决呢？和上面一样，投影分解：学生课程老师教室上课时间小明一年级语文（上）大宝10114：30老师老师职称大宝副教授BC范式（BCNF）：符合3NF，并且，主属性不依赖于主属性若关系模式属于第一范式，且每个属性都不传递依赖于键码，则R属于BC范式。通常BC范式的条件有多种等价的表述：每个非平凡依赖的左边必须包含键码；每个决定因素必须包含键码。BC范式既检查非主属性，又检查主属性。当只检查非主属性时，就成了第三范式。满足BC范式的关系都必然满足第三范式。还可以这么说：若一个关系达到了第三范式，并且它只有一个候选码，或者它的每个候选码都是单属性，则该关系自然达到BC范式。一般，一个数据库设计符合3NF或BCNF就可以了。在BC范式以上还有第四范式、第五范式。第四范式：要求把同一表内的多对多关系删除。第五范式：从最终结构重新建立原始结构。但在绝大多数应用中不需要设计到这种程度。并且，某些情况下，过于范式化甚至会对数据库的逻辑可读性和使用效率起到阻碍。数据库中一定程度的冗余并不一定是坏事情。如果你对第四范式、第五范式感兴趣可以看一看专业教材，从头学起，并且忘记我说的一切，以免对你产生误导 数据库设计中的一些技巧1. 原始单据与实体之间的关系　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对 一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。　　〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。2. 主键与外键　一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什 么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示 实体之间的连接。3. 基本表的性质　　基本表与中间表、临时表不同，因为它具有如下四个特性：　　 (1) 原子性。基本表中的字段是不可再分解的。　　 (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。　　 (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。　　 (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。　　理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。4. 范式标准　　基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。　　〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。　　在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。　　表1 商品表的表结构　　商品名称 商品型号 单价 数量 金额　　电视机 29吋 2,500 40 100,000　　　　 5. 通俗地理解三个范式　　通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：　　第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；　　第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；　　第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。　　没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法 是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。　　 6. 要善于识别与正确处理多对多的关系　　若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关 系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识 别多对多的关系，但能处理多对多的关系。　　〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间 可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借 书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。　　 7. 主键PK的取值方法　　 PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。　　 8. 正确认识数据冗余　　主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。　　〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为 了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反 对低级冗余(重复性冗余)。　　 9. E--R图没有标准答案　　信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E--R图。 尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。　　 10. 视图技术在数据库设计中很有用　　与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。　　对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层 视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握 的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么？　　 11. 中间表、报表和临时表　　中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。　　 12. 完整性约束表现在三个方面　　域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。　　参照完整性：用PK、FK、表级触发器来实现。　　用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。　　 13. 防止数据库设计打补丁的方法是“三少原则”　　 (1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；　　 (2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；　　 (3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了 将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有 的人就是不习惯、不采纳、不执行。　　数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。　　提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据 库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个 数、属性的个数就会越少。　　提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大 杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。　　 “三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。　　 14. 提高数据库运行效率的办法　　在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：　　 (1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。　　 (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。　　 (3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。　　 (4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。　　 (5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。　　总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。　　上述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用1简介1.1简介MDX引擎基于元数据模型(cube模型)设计，对业务APP提供了与具体业务无关的查询语言，用于查询CUBE上的多维数据。MDX－Multi Dimension Expression即多维表达式，是由 Microsoft、 Hyperion 等公司发布的多维查询表达式，是 OLAP 高级分析所采用的查询语言之一。3.0平台的MDX语言借鉴了业界MDX的设计思路封装了CUBE数据的查询，但实现上进行了简化，与之有较大差异。1.2范围本文档为MDX的使用手册，详细说明了如何使用MDX语言操作CUBE中的数据。本文档仅描述MDX的语法及使用本文档的使用者为内部APP二次开发人员、测试人员、开发人员等。阅读本文档需具备一定数据挖掘的知识。可参考文档《olap.ppt》、以及《数据挖掘－概念与技术》2CUBE元数据模型2.1概述业务模型描述了MDX查询涉及到的模型，保证大家（包括MDX引擎的开发人员、MDX语句编写人员、测试人员、资料人员等）对于MDX理解的一致性。业务模型图如下： 详细说明请参考后续章节。MDX只需要表达Cube、维度、Counter、hierarchy等逻辑概念，不用关心数据如何存储在数据库中，以及存储在哪些表中2.2CUBECube（数据魔方）：多个维度和指标构成的逻辑模型。系统中可能包括一个或多个CubeCube与业务相关，但与APP不是一一对应的，Cube主要是从数据组织维度来定义和规划的，粒度会比较小Cube与专题相比，具有很大的灵活性。单个Cube为雪花或星型2.3Counter/KPI/KQICube指标数据的存储定义，为了支持上卷等能力，Counter不能是百分比、比率等指标，比如掉话率等，这些指标只能在MDX查询语句中通过自定义指标计算得到KPI/KQI： 在查询过程中，通过Counter计算而来，特殊地它也可以是一个Counter. 如果系统中没有预定义KPI/KQI，那么在MDX中的KPI名就对应到Cube中的Counter名说明：预定义KPI/KQI相关请参考3.0平台业务定制相关模块设计，MDX暂不支持预定义KPI/KQI查询2.4维度及level维度是属于某一个维度命名空间，可以在CUBE间重用。规则如下：每个维度包括一个或多个hierarchy，hierarchy用于表示一个树状的维度关系。一个hierarchy包含一个或多个level，level即层次，用以标识同一个hierarchy下不同粒度的维度成员。如下所示，时间维度不同level间关系如下： 从天可以到周、或从天到月，但周与月间并没有直接关系，即时间维度为树状结构。引入hierarchy可将树状的维度关系以线性的方式描述，方便配置和程序处理。时间维度可用两个hierarchy描述：Hierarchy1：15分钟－>小时->天->周。Hierarchy2：15分钟－>小时->天->月。注：除非特别说明，不能同时在MDX中同时引用不同hierarchy的不同level，比如select D.Time.month, D.Time.week就是非法的，但select D.Time.month, D.Time.day或select D.Time.week, D.Time.day就是合法的。在同一个hierarchy下，一个高level维度成员包含一个或多个低level的维度成员，即高level纬度成员与低level维度成员间为包含关系。每个level上包括0个、1个或多个维度成员实例，如RNC level包括RNC1、RNC2等，RNC1成员包含Cell1、Cell2等小区成员。每个维度成员用一个全局唯一的id或name来标识。2.5CUBE数据操作2.5.1钻取改变维的层次，变换分析的粒度，包括向下钻取（Drill-down）和向上钻取（Drill-up）/上卷(Roll-up)。下钻示例： 比如从网元的RNC level可以看到掉话率如图所示，RNC2掉话率较高，因此，需要深入分析一下RNC2下各小区的掉话情况，看到底是哪些小区的问题。上卷示例： 时间维度做了上卷，从小时粒度到天粒度。2.5.2切片在一部分维上选定值后，关心度量数据在剩余维上的分布。比如查看“RNC1 2011年8月15日的掉话次数”，RNC=RNC1、时间=”2011年8月15日”为切片确定了一组度量数据。示例如下： 如图所示，所有黄底数据在关心的范围内。3MDX语法定义及使用3.1语法定义3.1.1概述MDX语法使用EBNF范式定义如下，语法定义文件如下： 语法结构简要如下：Select Dimension, Counter specificationFrom Cube_Name  [Join-ON specification]Where slicer specification, [counter filter][GroupBy Counter specification][Top count by/Orderby counter specification  ASC/DESC] [rownum- specification]如上所示，MDX查询语句包括四部分：Select、From、where、Top/OrderBy和GroupBy。其中Top/Orderby、GroupBy是可选的，即在MDX语句可以不出现。MDX语句的限制：MDX语句是大小写不敏感的MDX语句不支持中文其功能分别如下：Select定义返回结果集的列From定义使用哪个cube, 或者是指定多个cube的联合查询Where定义切片条件，以及结果集过滤条件Top/orderby对结果集进行排序或取top X值GroupBy将指标（包括自定义指标）指定为分组字段rownum- specification 分页查询※说明： MDX暂不支持[Join-ON specification]多CUBE关联查询详细说明请参考后续章节。3.1.2数据定义在select、where、Top/Orderby中都将可能引用到某一个具体的维度、指标等数据。其语法定义如下：3.1.2.1维度Dimension维度的语法为：Dimension.维度名.维度level名.id或name。其规则如下：维度引用包括四部分内容，各部分以“.”逗号分割，其中：Dimension为关键字，标识维度；维度名标识维度；维度level名标识维度层次；id或name定义使用维度成员的id还是name，可选，默认为id，即Dimension.ne.rnc等同于Dimension.ne.rnc.id注：在cube的fact table中存放的一定是维度成员的id，为了提升查询速度，以及方便程序处理，MDX语句会自动做转换维度名、维度level名必须与CUBE中定义的名字完全一致维度名、维度level名是大小写不敏感的维度名、维度level名命名时支持A-Z、a-z、0-9、“_”字符不支持中文3.1.2.2Counter指标指标的语法为：表达式(Measure.KPI.Counter名) as 指标别名。其规则如下：原始指标通过“Measure.KPI.Counter名”引用，多个Cube存在重名的时候需要使用@关键字指明Counter所属的Cube可以通过as将基于表达式的指标计算重新命名为一个新的指标名，在MDX其他部分可以引用该指标别名。指标名、指标别名命名时支持A-Z、a-z、0-9、“.”、“_”字符不支持中文关于指标表达式请参考“指标计算表达式”。3.1.2.3常量3.1.2.3.1字符串常量字符串常量用双引号扩起来，比如“string”。3.1.2.3.2IntInt常量采用十进制数字表示，比如35、20。3.1.2.3.3百分比常量采用小数方式表示，比如5%用0.05表示。3.1.2.3.4浮点数十进制表示， 如0.12， 5.0等3.1.2.4时间及常量时间采用固定格式为YYYYMMDDHHMI的字符串，比如2011年8月16日14点20分表示为201108161420。时间常量格式如上，但不用双引号扩起，如201108161420、201108161430都是合法的。3.1.3操作符Counter指标通过算术或者逻辑运算符组合成为一个指标计算表达式，MDX支持运算符，如下优先级由低到高表1 MDX支持操作符运算符说明备注OR逻辑或逻辑运算符AND逻辑与逻辑运算符NOT非NOT 后表达式必须加括号()>,<,>=,<=,=,!=,<>,in,not in, between ..and大于、小于，大于等于、小于等于、等于、不等于比较运算+,-加/减算术运算*,/,%乘/除算术运算+,-正/负单元运算Case  when()括号3.1.4Select3.1.4.1语法定义定义需返回的结果集的列。包括维度表达式和指标表达式Select定义各列语法定义如下：Select [维度表达式]+ [,指标表达式] *其规则如下：至少要有1个字段，即至少有1列维度表达式列规则：可以为cube中的任意维度及任意level。如网元维度，可以是RNC或小区等可以定义一个或多个维度列，不同维度列可以是同一个维度同一个hierarchy的不同层次level，如Select Dimension.ne.rnc, Dimension.ne.cell，但不能是不同hierarchy的不同层次level，如Select Dimension.time.week, Dimension.time.month每个维度列只能有一个维度及level，仅支持维度函数，不支持算术和逻辑表达式指标表达式列规则：可以定义0个、一个或多个指标列指标可以为原始Counter指标或自定义指标MDX返回结果集遵循的规则MDX查询结果将以维度列作为分组字段进行二次汇总，即维度列都是分组字段二次汇总（上卷）时，对于各项指标默认为sum操作，因此，fact table不能定义百分比、平均等类型指标通过ToDimension关键字，也可以将某个指标指定为分组字段指标计算在二次汇总后进行计算3.1.4.2内置函数DistinctCountt函数DistinctCount (维度)  --  计算分组下的维度去重复后的个数Ddvl 函数Ddvl(维度, default_value)ddvl (dimension default value)函数用在SELECT子句的维度表达式中， 表示查询时候，维度表中无法关联找到对应的维度值，那么表达式的结果采用函数中第二个参数的值代替指标转换分组维度函数Todimension(Counter指标) 把“Counter指标”作为分组维度，单独为一个结果列，不能和其他操作符合用指标聚合函数CounterIfRaw(指标表达式)当”指标表达式”成立的时候，分组内统计值加一SumIfRaw(指标表达式1, 指标表达式2)当” 指标表达式2”成立的时候，分组内统计值累加” 指标表达式1”的结果MaxRaw(指标表达式)分组内获取” 指标表达式”的最大值MinRaw(指标表达式)分组内获取” 指标表达式”的最小值AVG(指标表达式)分组内获取” 指标表达式”的平均值BitorSumRaw(指标表达式)分组内“指标表达式”值按位或求和SumRaw(指标表达式)分组内获取” 指标表达式”值求和指标分段函数Split/SplitRaw(指标表达式，分段表达式，分段表达式...)Split表示先对Measure或Measure计算表达式进行汇总，然后对指标结果值进行分段，以分段为临时维度进行汇总，比如统计不同流量段（0-10M，10-100M，100M以上）的用户数，需先对用户的流量进行统计，然后分段进行统计SplitRaw把指标当作临时维度，把该指标值直接进行分段后进行统计，比如统计不同SQI值的用户数分布就使用SplitRaw，这个显然不能先把SQI值统计一下然后再分段分段表达式：分段范围 AS 分段名  --  如[3:10] AS ThreeToTen     开区间使用”()”,  闭区间使用”[]”, 正无穷和负无穷使用*     如:  SPLIT(TRAFFIC,  [0:10) AS LT10, [10:100) AS 10TO100, [100: *) AS GT100)  Dimension.time.Raw 特殊语义特殊的语义，如果Select有这一列，则表示查询原始指标，即MDX不再做二次汇总，也不再选择预汇总表进行查询3.1.4.3示例MDX查询返回的结果集是二维的，类似于table，table的各个字段与select的各个字段完全对应。如：Select  Dimension.user.IMSI, Measure.kpi.rrccount, Measure.kpi.releasecount, Measure.kpi.abreleasecount返回的结果集示例： IMSI为用户维度的IMSI层次，接入次数、正常释放次数、异常释放次数为指标。3.1.5From说明当前语句操作的CUBE对象，只允许一个CUBE对象，不支持多个CUBE join。可以指定系统中多个CUBE中的任意一个。如VIP业务就指定VIP CUBE。3.1.5.1查询一个Cube中的指标              From  Cube名即可3.1.5.2联合查询多个Cube内的指标(暂不支持)      需要使用Join On 关键字指定关联关系语法：From CubeName1  Join  CubeName2  On 关联条件                                                         (Join  CubeNameX… 关联条件)*关联条件： 只能在维度或者todimension(指标)作为关联条件， 多个条件之间用“,“分割 关联条件样例说明维度关联，只能用维度level的key进行关联Dimension.user.vip.imsi把两个Cube中的IMSI进行关联查询Todimension关联Todimension(measure.KPI.m1) = Todimension(measure. KPI .m2)把两个Cube按照M1和M2两个原始Counter进行关联混合关联Todimension(measure. KPI .m2) =  Dimension.user.vip.imsi@ CubeName1按照Cube2的M1指标和Cube1的imsi进行关联查询举例：From UPerformanceKPICube Join UMTSCellDeepCompCubeOn    Todimension(Measure. KPI. AccessTime) = dimension.time.raw@ UMTSCellDeepCompCube,   Dimension.user.vipuser.imsiWhere…Join选表规则：Join语法只会选择Cube中的基础表进行关联查询说明：[Nastar 之前的版本差异], 之前版本的MDX不支持多个Cube联合查询，而在Cube下建立多个MeasureGroup建模来实现，最新模型上不再支持MeasureGroup，需要把MeasureGroup切换到Cube，并利用多个Cube的联合查询实现相同功能兼容性,  如果之前带MeasureGroup的查询, MeasureGroup名会被当Cube来处理例如：Measure.MeasureGroupName.Counter将被转换为Measure.KPI.Counter@ MeasureGroupName      From 和 Join中的， Cube. MeasureGroupName被转换为 MeasureGroupNameMeasureGroupName在新的模型中必须对应一个Cube的名字       新写的MDX语句中不要使用老的语法规则!3.1.6WhereWhere的语法为：Where slicer specification, counter filter。slicer specification为切片条件，包括一个或多个维度成员计算表达式和0到多个todimension表达式；counter filter为指标结果集过滤条件，包括0个或1个指标结果集过滤表达式。所有表达式间通过逗号“，”分割。如：Select Dimension.NE.Cell, Measure.kpi.dropcount % Measure.kpi.totalcount as droprateWhere Dimension.NE.RNC.name IN (“RNC1”,”RNC2”,“RNC3”), Dimension.Time.Day>20110813 AND Dimension.Time.Day<20110815, Droprate > 0.05表示查询时间为2011年8月13日到2011年8月15日，RNC1、RNC2、RNC3掉话率>5％的小区及掉话率。其中“2011年8月13日到2011年8月15日，RNC1、RNC2、RNC3”为切片条件，“Droprate >  0.05”为结果集过滤条件。Where实际包括两部分：3.1.6.1切片条件slicer specification即确定维度成员，这个用于从Cube中选取满足切片条件的数据。slicer specification包含了多个维度成员计算表达式和Counter指标Todimension表达式切片条件遵循的规则为：切片可以同时对多个维度取不同的单元成员切片可以是任意维度的任意level级别。如对网元进行切片，可以是RNC1、RNC2，也可以是cell1、cell2可以同时对多个维度取不同切片，不同维度切片间以“,”分割，为And与逻辑。如Dimension.NE.Cell IN (1001,1002,1003), (Dimension.Time.Day>10 AND Dimension.Time.Day<13) 示例表达的是“Dimension.NE.Cell IN (1001,1002,1003) and (Dimension.Time.Day>10 AND Dimension.Time.Day<13)”，即cell为1001或1002或1003，且时间为10-13号时间维度切片只支持范围比较： >、<、>=、<=切片支持表达式计算，规则如下：包括：＝＝、!=、>、<、>=、<=、in、not in、AND、OR等。如Dimension.NE.Cell IN (1001,1002,1003) ，表示选取ID为1001、1002、1003小区的数据如Dimension.Time.Day>20110813 AND Dimension.Time.Day<20110815，表示选取时间段为10－13号的数据。单个维度成员计算表达式只能包括一个维度如“Dimension.NE.Cell IN (1001,1002,1003)”或“Dimension.Time.Day>20110813 AND Dimension.Time.Day<20110815是合法的但“Dimension.NE.Cell IN (1001,1002,1003) and Dimension.Time.Day>20110813”是非法的不同维度成员计算表达式间以逗号“，”分割Todimension(指标表达式)切片则没有约束，可以使用所有的运算符。 如:Todimenison(measure.kpi.m1 * measure.kpi.m2+100) > 1000 and  (Todimenison(measure.kpi.m3) < 100 OR Todimension.kpi.m4 = 1)在多个Cube联合查询的场景下，维度上可使用@关键字指定切片的目标Cube， 如不指定MDX引擎则对这次查询相关的所有Cube进行切片如：  Dimension.Time@ UMTSCellDeepComp > 201108130000Where中取维度成员时，其level可以与select中不同，比如select中需要返回网元维度的level为：小区，而where中网元维度的level为：RNC，如select Dimension.ne.cell, xxx from cube where Dimension.ne.RNC.name = “rnc1”3.1.6.2指标结果集过滤条件counter filterMDX查询语句可以包含一个结果集过滤条件，以对结果集进行过滤。指标结果集过滤条件可以看作是针对指标的切片条件其规则如下：指标结果集过滤条件支持表达式支持逻辑计算表达式，返回的是true或false支持In、Not in、与、或、大于、小于、大于等于、小于等于、等于、不等于等逻辑运算符支持指标变量、数字常量、字符串常量等如需要进行二次汇总，则是在二次汇总后对结果集进行过滤。如“查询2011年5月10日 全网（或成都地区）掉话率高于5%的RNC”需求，需对结果集进行过滤，其查询条件为“WHERE Dimension.Time.Day.ID=20110510, CallDropRate>0.05”，其中表达式“CallDropRate>0.05”为结果集过滤条件，针对RNC的掉话率进行过滤。指标过滤可使用别名， 如Select dimension.time.day  As Time,  dimension.ne.rnc.rncid, measure.kpi.accessFaildCnt/ measure.kpi.accessCnt  AS CallDropRate        From Cube        Where Dimension.Time >= 201105100000 and dimension.time <  201105110000                  ,  CallDropRate > 0.053.1.7OrderBy对结果集按照某一个或几个指标值进行排序。支持ASC（升序）、DESC（降序）Order… ON语法在维度分组内对指标进行排序， 结果保证order 中的维度值相同的记录是连续的，但并不保证是按字典序排列， 而在这个order中的维度分组内指标是按数字大小字典有序排列语法定义如下：Orderby dimension specifaction counter specifaction ASC/DESC或者Order  on dimension specifaction by counter  specifaction ASC/DESC语法规则如下：Orderby字句为可选的可以指定0个或多个维度作为排序分组维度可以针对0个或多个指标进行排序至少指定一个维度或者指标排序的维度和指标必须在Select字句中存在支持升序和降序。ASC表示升序，DESC表示降序当包含多个表达式时，表达式间用逗号“，”分割如 ： Orderby dimension.time.day,  measure.kpi.m1 ASC, measure.kpi.m2 DESC          Order on dimension.time.day by measure.kpi.m1 ASC, measure.kpi.m2 DESC当包含多个指标或表达式时，按照顺序优先级为由高到低，如orderby Measure.kpi.totalcount, measure.kpi.releasecount，优先按照totalcount进行排序，如果totalcount相同，则按照releasecount进行排序3.1.8Top对某个维度按照某个指标值（包括自定义指标）进行排序后，取top X结果 。支持ASC、DESC。语法定义如下：Top count ON  [dimension specifaction] by counter specifaction [ASC/DESC] [ABS]或Top count by [dimension specifaction]  counter specifaction [ASC/DESC] [ABS]语法规则如下：Top子句为可选的可以指定返回top数据的个数，即count，实际返回的记录行数会大于等于count，因为存在并列top的情况，比如top 10时，返回的记录行为12行，因为10、11、12等三行counter相等可以指定排序的一个或多个维度，即按照什么维度分组下进行排序当Select中定义了多个维度，部分维度不出现在top排序中时，表示将以这些维度为分组字段，分别求出top count记录示例如下：Select Dimension.Grid.xx, Dimension.NE.cell, Measure.kpi.MRCounts from RF_CUBE where … top 1 On Dimension.Grid.xx by Measure.kpi.MRCounts。Select中包括Dimension.Grid.xx、Dimension.NE.cell，top中仅包括Dimension.NE.cell，表示将返回每个栅格里MRCounts最多的cell Select Dimension.User.IMSI , Measure.kpi.flux from RF_CUBE where … top 10  by  Measure.kpi. flux , 表示返回流量排名前十的用户ABS (absolute)关键字则表示不重复计数，最终结果集中，每个分组下只保留TOP N行数据，即使分组中存在多行指标相等的情况。 这个关键字是可选的ABS/DESC 表示升序和降序， 也是可选的， 默认为降序3.1.9rownumrownum [>, >=] NUMBER and rownum [<, <= ] NUMBERrownum是关键字， NUMBER大于0表示获取结果集中的记录范围例如：rownum >= 1000 and rownum < 2000  表示获取结果集第1000到2000记录。Rownum是对MDX最终查询结果输出时进行过滤，不能提升MDX查询性能，分页查询性能和查询全部结果集性能相同3.4场景及示例3.4.1指标计算场景3.4.1.1场景1：计算RNC1、RNC2掉话率3.4.1.1.1场景说明查询2011年5月10日 RNC1、RNC2的掉话率。返回两列，网元、掉话率，网元包括RNC1、RNC2。3.4.1.1.2输入Cube定义如下： 3.4.1.1.3输出返回的结果集为： 3.4.1.1.4MDX语句SELECT Dimension.NE.RNC.Name as RNC, Dimension.Time.Day as day, Measure.KPI.DropCount％ Measure.KPI.TotalCount) as CallDropRateFROM MainCubeWHERE Dimension.NE.RNC.Name in(“RNC1”,”RNC2”),Dimension.Time.Day=201105103.4.1.1.5处理过程说明MDX语句先过滤出RNC1、RNC2在20110510的记录，进行上卷并计算出DropCount、TotalCount，最后计算出CallDropRate＝DropCount/ TotalCount3.4.2结果集过滤场景3.4.2.1场景13.4.2.1.1场景说明查询2011年5月10日 全网（或成都地区）掉话率高于5%的RNC。返回两列，网元RNC、掉话率。3.4.2.1.2输入Cube定义如下： 3.4.2.1.3输出MDX先计算出20110510所有RNC的CallDropRate掉话率，然后找出掉话率大于0.05的RNC，并返回，结果集示例如下： 3.4.2.1.4MDX语句SELECT Dimension.NE.RNC.name, (Measure.KPI.DropCount/ Measure.KPI.TotalCount) as CallDropRateFROM MainCubeWHERE  Dimension.Time.Day=20110510, CallDropRate>0.053.4.3Top使用场景3.4.3.1场景1：3.4.3.1.1场景说明查询2011年5月10日 全网（或成都地区或RNC1）掉话率前10位的小区Cell及各项指标。3.4.3.1.2输入Cube定义示例如下： 3.4.3.1.3输出结果集示例如下，共返回了11行，因为最后几个掉话率是相同的，并列top 10： 3.4.3.1.4MDX语句SELECT  Dimension.NE.Cell.Name as cell, (Measure.KPI.DropCount/ Measure.KPI.TotalCount) as CallDropRateFROM MainCubeWHERE Dimension.Time.Day=20110510,  Dimension.NE.RNC=”RNC1”Top 10 by  CallDropRate DESC3.4.3.2场景2：3.4.3.2.1场景说明查询2011年5月10日 RNC1各个cell流量前3位的用户。返回三列，cell、IMSI、流量3.4.3.2.2输入Cube定义示例如下： 3.4.3.2.3输出结果集返回示例，Cell4共返回了4行，因为最后两个用户并列top 3： 3.4.3.2.4MDX语句SELECT  Dimension.NE.Cell.CELLID as cell, Dimension.User.IMSI as IMSI, Measure.UKPI.Flux as FluxFROM MainCubeWHERE Dimension.Time.Day=20110510, Dimension.NE.RNC.name = “RNC1”Top 3 Dimension. NE.Cell. CELLID by DESC3.4.4临时维度场景3.4.4.1场景1：3.4.4.1.1场景说明统计支持EGPRS、支持1800M等能力的终端数。3.4.4.1.2输入Cube定义示例如下：3.4.4.1.3输出展现给用户的结果示例如下： 表示仅支持EGRPS的终端数为：12333；同时支持EGRPS、M1800的终端数为：244；仅支持M1800的终端数为：35553.4.4.1.4MDX语句因为终端能力目前有几十种，而且还在不断增加，如果定义成维度，维度的数量将极其庞大，如果定义成指标，而对于指标上卷时默认操作是sum，不能满足统计要求。因此，需要使用ToDimension，将某个指标指定为临时维度，统计时按照维度来处理，就可以满足要求。如下：Select ToDimension(Measure.kpi.SustainEGPRS) as EGPRS, ToDinemsion(Measure.Kpi.Sustain1800) as M1800, DistinctCount(Dimension.Terminal.IMEI) as TotalTermFrom MCubeWhere Dimension.time.day = 201111243.4.5指标分段统计场景3.4.5.1场景1：统计某个时间段流量使用情况3.4.5.1.1场景说明MBB业务，需要统计某个时间段流量使用分布情况。如统计2011年10月10日到2011年10月15日，不同流量情况下用户数。3.4.5.1.2输入Cube定义示例如下： 3.4.5.1.3输出展现给用户的结果示例如下： 3.4.5.1.4MDX语句要返回如上结果，实际需要先按照IMSI对用户一段时间的流量进行汇总，然后根据用户流量将用户进行分组，并计算用户数。因此使用Split关键字进行分段处理。其MDX语句如下：SELECT Split(Measure.Mbb.flux,  0:10000 , 10000:50000 , 50000:200000 , 200000:* ), DistinctCount (Dimension.user.imsi) from MBB_CUBE where Dimension.time > 20111010 and Dimension.time < 20111015。――切片条件3.4.5.2场景2：3.4.5.2.1场景说明通过每次呼叫的平均SQI，统计全网用户每天各次呼叫的SQI分布情况3.4.5.2.2输入Cube定义示例如下： 3.4.5.2.3输出展现给用户的结果示例如下，展现了每天不同SQI分段的用户数： 3.4.5.2.4MDX语句要返回如上结果，需要将SQI值作为临时维度进行处理，而不能将SQI值上卷，然后对SQI进行分段，并计算用户数。因此使用SplitRaw关键字进行分段处理。SELECT Dimension.Time.Day, SplitRaw(Measure.Mbb.flux,  0:10000 , 10000:50000 , 50000:200000 , 200000:*  ), DistinctCount (Dimension.user.imsi) from MBB_CUBE where Dimension.time > =20110101 and Dimension.time <= 201101023.4.6CountIf场景3.4.6.1场景1：3.4.6.1.1场景说明统计VIP用户所有成功接通的语音呼叫中短呼的次数大于3次的用户及短呼次数，即一次接通的语音呼叫的时长<短呼门限，则短呼次数+1，且短呼次数要大于3次3.4.6.1.2输入Cube定义示例如下： VIP fact 表中的数据为呼叫级counter。3.4.6.1.3输出展现给用户的结果示例如下： 3.4.6.1.4MDX语句本需求希望基于每次呼叫进行判断和统计，VIP fact table表中原始记录即满足了CountIF查询了要求，因此，使用CountIF(条件)。如下：Select Dimension.user.imsi, CountIfRaw(Measure.MeVip.Duration > 5) as ShortCallFrom VIPCubeWhere Dimension.time.day = 20111102, ShortCall >= 33.4.6.2场景2：3.4.6.2.1场景说明统计VIP用户每个小区在一段时间内每一个小时流量都大于100的用户数。3.4.6.2.2输入Cube定义示例如下： 3.4.6.2.3输出展现给用户的结果示例如下： 3.4.6.2.4MDX语句该需求希望基于Dimensino.Ne.Cell，Dimension.USER.IMSI,  DIM.Time.Hour三个维度统计flux的结果进行，其他维度(如业务类型)都被上卷掉了，即CountIF不是使用vip base fact table的RAW数据，而是table(Dimensino.Ne.Cell，Dimension.USER.IMSI,  DIM.Time.Hour, Measure.Flux)这样一个虚拟表的数据，即对该虚拟表的每一行进行条件判断，如果满足条件，则count＋1，因此MDX语句如下：Select Dimension.NE.CELL,CountIF(Measure.Flux>100,Dimension.NE.CELL, Dimension.USER.IMSI,  DIM.Time.Hour ) AS HighFluxUserCountFrom XXXCubeWhere Dimension.Time.Day >=20111112 and Dimension.Time.day <=20111114)3.4.7DistinctCount场景参见“指标分段统计场景”3.5与SQL比较相同点：1、语法结构一致，都支持select、from、where和order等不同点：1、MDX语法操作的是CUBE模型，即一条MDX查询语句会同时操作到CUBE中的fact table、维度等多个表中数据，而SQL操作的是表2、MDX语法更贴近Nastar等业务系统的查询业务，支持下钻、切片等参考资料清单：emptyempty