It was concluded five major bottleneck in the development of olap
Limited and not easily integrated front-end functionality - 1.OLAP product closed;
2.MDX not as good as the popularity of SQL - or in terms of popularity on the Learning Resources, SQL still has the largest population data query technology;
3.xOLAP not satisfy the large analysis of the data - big data environments can not satisfy the third principle (high-speed response);
4.OLAP pre modeling bottlenecks - when rapid changes in business requirements or business related updates, IT staff need to reconstruct the model, low efficiency change affect the use of feelings;
5.OLAP visualization weak - visualization capabilities not enough.
6-9 the previous sections, I compiled static mdx statement. Static mdx summary also missing, supplementary slowly behind. To solve the bottleneck OLAP pre-modeling, dynamic modeling is to understand me, the realization, is to build a dynamic mdx statement, we build on the dynamic sql, there is more experience, we are here to build the dynamic sql first summarize again, and then and then summarize dynamically build mdx.
Dynamically building sql
Preparation:
Definition data element (field) ---> dataset ----> define the relationship between the data set
Data Elements
interface
Adding data elements:
Here, meta data region selectable items for the main document table area, the document list area, because we are mainly primary documents from the structure.
Source types are divided into:
Display method:
Here, the reference field behind the system is hard-coded to write to die.
Application reference table fields, for example, the hospital many documents need to refer to the patient's basic information, basic information about the patient is first hospitalized when registered, this time, you can use the reference table fields.
当初老夫设计这套体系的时候，其实是有点想把整个系统往云应用方面引导的，但实践过程中，一直不是太成功，也没有时间深入推进。
我想，这是个古老的东西了，20年前就有了，这次总结后，还是搞新的东西去吧。
表结构：
实现方式：略
后期需要改进的地方？我们定义数据元属性的地方是写死的，不过，如果不需要改动，也无所谓。其他问题？
数据集：
定义表及表字段
界面：
编辑数据集：
新增加数据集：
数据集定义中，有个“是否为票据”选项，可以定的更为抽象一点，方便对定义的表的用途进行分类。例如，可以另外弄一个字典表，方便读取？
这里有个编辑数据元信息按钮，点击弹出如下界面：
这里弹出一个数据集所有字段，主要方便一次性调整是否可见、是否主键等，
关联表名、关联字段，实际应用中，放弃了，为什么放弃使用，原因?忘记了。
外键的目的在于：保持数据一致性，完整性，主要目的是控制存储在外键表中的数据。 使两张表形成关联，外键只能引用外表中的列的值或使用空值。
表结构：
实现：
这里要干2件事情：
1、动态创建表
- 动态创建表sql，动态拼sql,要拼字段名称、字段类型、长度、默认值、是否为空等5个要素。
- 动态创建备注 comSql，因为有多条表注释信息，因此把它放到一个集合中，批量提交数据库执行。
- 动态创建约束，这里加了三类约束：主键约束、非空约束、外键约束。联合主键好像完全没有考虑？后面如果还有机会用到类似的东西，还是要完善一下这一点，其实，设计上参考数据库本身的设计就行，而不是简单的在此勾选，一个补救的办法是，单独弄一个联合主键的维护界面，反正都是alter语句。
2、保存数据集元数据信息
动态创建表语句如下：
我们把数据类型放到了字典表中，这样做的目的，当初是为了匹配不通过大的数据库，动态创建表语句当中，数据类型就是查的这个字段表。
问题：
数据集列表是否需要分个类，这样，当表有成千上万的时候，方便管理？
数据集间的关系：
界面：
表结构：
实现：略
问题：
数据集关系列表缺少查询！如果关系条目多，查询不方便。
这里定义了数据元、数据集，只是定义了表结构，还要和业务挂钩。
我们这边的业务就是票种，得把票种和数据集关联起来：
存储票种和数据集关联的表结构：