有人總結了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、保存數據集元數據信息
動態創建表語句如下：
我們把數據類型放到了字典表中，這樣做的目的，當初是爲了匹配不通過大的數據庫，動態創建表語句當中，數據類型就是查的這個字段表。
問題：
數據集列表是否需要分個類，這樣，當表有成千上萬的時候，方便管理？
數據集間的關係：
界面：
表結構：
實現：略
問題：
數據集關係列表缺少查詢！如果關係條目多，查詢不方便。
這裏定義了數據元、數據集，只是定義了表結構，還要和業務掛鉤。
我們這邊的業務就是票種，得把票種和數據集關聯起來：
存儲票種和數據集關聯的表結構：