2019/10/12
Tabular Data Model 主要資料結構設計概念是使用傳統的關聯式資料庫 (RDB) 架構,透過 Table-Relationship 的設計概念為主軸來設計資料模型。
SSAS 建立的 Tabular Model 專案大致上長得像這個樣子,如下圖:
會選擇 Tabular Data Model 的原因大致上有下列幾點:
Tabular model 較成熟(會先選擇):因為 Tabular Model 延續 RDB 的設計架構與概念,所以是一個較為成熟的技術架構。
Tabular model 較多 modeling features available:因為延續 RDB 資料庫架構的設計,所以提供了較多的模型設計與分析功能。
較多人有 relational background or Excel experiment (Tabular concept):目前 IT 技術人員或資訊系統開發人員較為熟悉的資料庫架構就是 RDB,Entity-Relation 的資料架構設計方法也較為大家所熟悉。
Tabular is easy to build and faster to deliver (easier, fast, agile, lean, fast query, fast deliver, ...) [Multidimensional 比較雄偉,莊嚴]:表格式資料模型比較簡單容易,能夠較為快速的開發和建置資料模型架構。
DAX is a strong calculation language (reusability in the model) – easier to get start & learning:Tabular Model 使用的開發設計語言是 DAX,資訊技術人員能較快的學習。
使用 Visual Studio + SQL Server Data Tools 來開發表格式資料模型 (Tabular Model) 的開發設計步驟如下:
為什麼這裡會出現 Azure 雲端服務呢?因為 Azure Analysis Services (AAS) 是基於 SQL Server Analysis Services 而搭建起來的 Azure 全託管雲端服務,這裡會提起這個服務,原因是 Azure 的 AAS 雲端服務只 support 表格式資料模型 (Tabular Data Model),相容的 SSAS Tabular model 是 Level 1200 以上,可以連接到 on-premises (Gateway) 整合規劃架構,可以使用的開發工具和地端的 SSAS 一樣。
可以連接到 SSAS 或是 AAS 的報表設計工具有下列三種:(查詢資料模型則必須使用 MDX 或是 DAX 查詢語言)
總結一下結論,在資料模型上面,表格式模型 (Tabular Model) 和多維度模型 (Multidimensional models),這兩種資料模型各有各的優缺點,各自有他們的強項和弱點,所以,企業組織應該視自己的需求選擇適合的資料模型架構,就我們的經驗上來說,我們建議資料模型開發人員能夠先以自己足夠的知識和經驗去選擇資料模型,然後強烈建議先做小範圍的 POC 驗證,再來小心選擇適當的資料模型設計方法,這樣才能漸進式的挑選出適當的資料模型架構。
PS : Tabular Model 是目前市面上較為通行的資料模型架構,因為 IT 相關的技術人員還是比較熟悉 Table-Relation 的關聯是資料結構設計方式,簡單快速,容易上手,而且,依照目前企業的資料數據平台主導方向還是以 IT 為主,所以 Tabular Data Model 就成為大家選擇的優先選項了。