假如你有一個方針，想得到所有這些數據的可操縱的看法，并一直在收集。那么，你如何確定模子的數據，以便實際上可以得到這些看法，并答復你的業務問題？你的打算。當籌劃階段不充實或不完全，其功效是可駭的。那么闡明和機能、數據完整性和安詳性的問題接踵而至，將會使日常的維護和成長的本錢到達了不須要的程度。

在這篇文章中，先容了人們在數據籌備闡明建模時呈現的一些常見的錯誤。假如被忽視，這些錯誤大概會阻礙你的闡明，并影響你的看法。

讓我們從利用的東西或技能方面制止三種常見的數據建模的錯誤開始，然后再到OLAP多維數據集和傳統的BI平臺上事情時大多碰著的4個問題。

制止常見的建模錯誤

（1）開始實施時沒有明晰的動作打算

當涉及到的闡明，如數據客棧或Elasticube建模數據資源，至關重要的是要籌劃出它的方針是什么。有幾個原因，但主要的主題是，你不能有效地操作您的闡明資源，假如你沒有為他們的方針。設計一個數據模子，將答允企業用戶舉辦觀測，如網絡流量和選擇，如為了闡明產物銷售模子，網絡流量和選擇的價值將遠遠差異。

最好的做法是為每個打算運行闡明規模舉辦籌劃，設計，并分派資源。這應該在貿易智能（BI）項目籌劃階段和全面的需求獲取進程中完成。當談到實施變動闡明方針時，就會發此刻機能，安詳性和可行性的明明改進。

將過多的數據包羅到一個資源這是大概的，回收傳統的東西大概會導致查詢時間和闡明慢下來；但縱然回收SiSense這樣一個平臺，優化那些復雜而差異的數據集機能時，仍然需要小心制止存儲問題，數據復制，以及不須要的開銷。在另一方面，沒有包羅所有須要的數據來答復你的業務方針中列出的問題，這是更糟糕的。

這一步的籌劃將使你識別闡明模子的總體方針，并確保正確的數據，包羅每個資源。

（2）沒有充實利用署理鍵

當闡明來自多個來歷的數據時，確保數據具有獨一標識符的一種風行的計策是提供署理鍵。然而，這并不老是須要的，或選擇利用替代密鑰是一種精采的做法。許多時候，數據有自然鍵（數據是一個獨一的值），而不消替代。這些值，如客戶的ID，社會安詳號碼，或已經在利用的生意業務數據作為主密鑰的復合鍵，是不變的，足以保存所有的根基密鑰需要的特性。

在這里，有幾點要緊記：署理鍵不該該與數據有干系。也就是說，它不該該受業務法則的限制。這些法則可以跟著時間的推移而改變，并泛起以前的獨一的值。

署理鍵不該該的數據的干系。也就是說，它不該該受業務法則。這些法則可以隨時間改變和泛起先前獨一值非獨一。

主鍵應該是相當緊湊，大的，巨大的，3個或更多個字段的組合鍵大概是貧苦的。假如自然鍵候選者是緊湊和不變的獨一值，這大概沒有來由添加署理鍵。

當利用署理鍵，打算系統老是利用雷同的技能生成獨一值，UUID，GUID，或max（）+1.這將確保任何署理鍵確實是獨一的。

署理鍵存在某一行標志奇特而不提供業務內容。這是他們提供的代價。它們不該該被用于查詢，并顯示給終端用戶。假如是這樣，你此刻已經引入了一個業務內容，不該存在的數據的干系。從頭思量你的模子和查詢。

（3）不妥的定名尺度

假如定名尺度不妥，大概會影響與任何數據相關的勾當。這是籌劃闡明資源的數據模子的一個重要步調。跳過這一步大概會導致許多不須要的貧苦和荊棘。來自多個源的搜集數據時，這是出格真實。

數據的主要基本是一致的。這應該擴展到所提供的表、列、約束、法子等的名稱，以遵循一個尺度的定名約定，其長處變得很是迅速。假如你試圖建設闡明的查詢，但你的表和法子在他們的名字后頭沒有任何邏輯，這將很難遵循。譬喻，假如你有這些表：

Production_MaterialsCosts

productionMachinesMaterialVendors

它大概是堅苦的，但并不是不行能的，知道這些是如何標志的，或是他們是什么，而不是每一次尋找他們。在數據模子中有一致性要更容易得多。這大概看起來像：

Production_MaterialsMaterial_Vendors

Production_MachinesMaterial_Costs

這是一個更好的方法來保持你的數據闡明處于正軌，并為數據模子提供一致性。

有跡象表白，在定名尺度中尚有很多利用的尺度要領。挑選一個適合您的組織事情并實現它，這是較量容易的。因此沒有須要回收奇特的定名約定。假如您是數據架構師，第一次建設闡明框架，這是你的責任，以實現一個對將來的闡明師遵循的尺度。假如不這樣做是一種嚴重的疏忽。

（4）利用傳統東西事情時常見的錯誤

回收傳統的BI東西或RAM麋集型內存系統事情時，以下的錯誤價錢大概是極其昂貴的，SiSense用戶擔保快速高效的芯片數據引擎不再是一個問題。

（5）錯誤的粒度級別