有人总结了olap发展的5大瓶颈
1.OLAP产品封闭性——前端功能的受限和不易集成；
2.MDX不如SQL普及——无论在学习资源还是普及程度上，SQL还是拥有最多人群的数据查询技术；
3.xOLAP满足不了大数据的分析——大数据环境中不能满足第三原则（高速响应）；
4.OLAP预建模瓶颈——当业务需求变化快或业务关联更新时，模型需IT人员重构，较低变更效率影响了使用感受；
5.OLAP可视化能力弱——可视化能力不够。
前面6-9节，我整理了静态的mdx语句。静态mdx总结还有缺失，后面慢慢补充。为解决OLAP预建模瓶颈，我理解就是要动态建模，实现上，就是要动态构建mdx语句，我们在动态构建sql上，有较多的经验，这里我们把动态构建sql先总结一遍，然后，再总结动态构建mdx。
动态构建sql
前期准备：
定义数据元（字段）--->数据集---->定义数据集间关系
数据元
界面
添加数据元：
这里，数据元区域的可选择项目为单据主表区、单据明细区，因为我们单据主要都是主从结构的。
来源类型分为：
显示方式：
这里，引用系统字段后面就是硬编码写死的。
引用表字段的应用，举个例子，医院里很多单据需要引用病人的基本信息，基本信息是病人首次入院的时候，登记的，这个时候，就可以运用引用表字段了。
当初老夫设计这套体系的时候，其实是有点想把整个系统往云应用方面引导的，但实践过程中，一直不是太成功，也没有时间深入推进。
我想，这是个古老的东西了，20年前就有了，这次总结后，还是搞新的东西去吧。
表结构：
实现方式：略
后期需要改进的地方？我们定义数据元属性的地方是写死的，不过，如果不需要改动，也无所谓。其他问题？
数据集：
定义表及表字段
界面：
编辑数据集：
新增加数据集：
数据集定义中，有个“是否为票据”选项，可以定的更为抽象一点，方便对定义的表的用途进行分类。例如，可以另外弄一个字典表，方便读取？
这里有个编辑数据元信息按钮，点击弹出如下界面：
这里弹出一个数据集所有字段，主要方便一次性调整是否可见、是否主键等，
关联表名、关联字段，实际应用中，放弃了，为什么放弃使用，原因?忘记了。
外键的目的在于：保持数据一致性，完整性，主要目的是控制存储在外键表中的数据。 使两张表形成关联，外键只能引用外表中的列的值或使用空值。
表结构：
实现：
这里要干2件事情：
1、动态创建表
- 动态创建表sql，动态拼sql,要拼字段名称、字段类型、长度、默认值、是否为空等5个要素。
- 动态创建备注 comSql，因为有多条表注释信息，因此把它放到一个集合中，批量提交数据库执行。
- 动态创建约束，这里加了三类约束：主键约束、非空约束、外键约束。联合主键好像完全没有考虑？后面如果还有机会用到类似的东西，还是要完善一下这一点，其实，设计上参考数据库本身的设计就行，而不是简单的在此勾选，一个补救的办法是，单独弄一个联合主键的维护界面，反正都是alter语句。
2、保存数据集元数据信息
动态创建表语句如下：
我们把数据类型放到了字典表中，这样做的目的，当初是为了匹配不通过大的数据库，动态创建表语句当中，数据类型就是查的这个字段表。
问题：
数据集列表是否需要分个类，这样，当表有成千上万的时候，方便管理？
数据集间的关系：
界面：
表结构：
实现：略
问题：
数据集关系列表缺少查询！如果关系条目多，查询不方便。
这里定义了数据元、数据集，只是定义了表结构，还要和业务挂钩。
我们这边的业务就是票种，得把票种和数据集关联起来：
存储票种和数据集关联的表结构：