如果你有一個目標，想獲得所有這些數據的可操作的見解，并一直在收集。那么，你如何確定模型的數據，以便實際上可以獲得這些見解，并回答你的業務問題?你的計劃。當規劃階段不充分或不完全，其結果是可怕的。那么分析和性能、數據完整性和安全性的問題接踵而至，將會使日常的維護和發展的成本達到了不必要的水平。

在這篇文章中，介紹了人們在數據準備分析建模時出現的一些常見的錯誤。如果被忽視，這些錯誤可能會阻礙你的分析，并影響你的見解。

讓我們從使用的工具或技術方面避免三種常見的數據建模的錯誤開始，然后再到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.錯誤的粒度級別

在分析中，粒度是指可以讓我們看到的數據細節的水平。例如，以時間和銷售規模為例，在產品推出的網上業務。粒度是多么小的一個時間框架，我們可以看一下。我們可以看看每小時，每分鐘，甚至每秒的交易數量嗎?如果我們有數據，看看每一秒發生多少交易，每秒的交易，這將是粒度。如果我們所擁有的數據是每小時為單位，那么我們的粒度將是每小時的交易。這不僅適用于時間維度。可是以參考一些類似每次訪問成本，例如醫生的辦公室或每個郵政編碼的客戶。

這是需要一個很好的平衡的問題。你可能有太多的無關數據，可能是難以讓最終用戶駕馭，這可能是一個企業管理人員更感興趣的大局。但是數據太少，又不能看到你需要的細節，此外，商業智能平臺的性能可能會受到影響，特別是當與傳統的商業智能工具(值得注意的是，這不應該是一個問題，因為使用現代數據分析工具具有較強的數據處理能力)。

這一點很重要，要記住，不僅在規劃分析和數據模型，但是當你認為哪些數據值得捕獲和儲存。畢竟，如果你實際上并沒有擁有它，那就不能分析數據。

并不是所有的措施都在硬數據中發現。有許多情況下，派生或計算將是必要的分析。然而，并非規劃在數據模型中，這些派生值可能是一個代價昂貴的錯誤。當運行分析查詢遺留系統，使得許多計算可以為基礎設施，減緩了整個過程。此外，它可能會導致一些主要值的不一致。

正如前面提到的，這是用較少的Sisense問題，自芯片 技術可以進行這些計算特設的，沒有耗盡計算機的RAM資源。但是，如果您使用的是舊版本還是內存系統，根據情況有幾個方法來處理很多派生值。當有衍生值，將不斷地或者用于報告或分析的目的引用的值，它可以是謹慎在ETL過程中進行這些計算，并將其存儲。另外，如果計算出的值是計算密集的(即復合式)，也可能是存儲所導出的值是個好主意。

除了當把它們存放與不存儲他們，而不是規劃派生值會影響你的分析。尤其是在金融領域的指標，即計算獲得該指標將是主觀的。這取決于該公司和他們的方法，該公式被用于一個特定的度量。如果不使用一個一致的公式，這將會有一個數據完整性和一致性問題，將會破壞任何分析。

最好是采用適當的業務部門檢查，以確保一致性的實現。規劃派生值可以幫助你分析，并改善未來業績。

6.維度層次結構

維層次結構可以威脅任何分析。有時，沒有明確的方法來確定一個特定的維度是否是一個層次結構的一部分。其他時間的業務目標的分析錯的關系。這是需要進一步調查的時候。如果層次結構還不清楚，需要花時間去接觸業務人員，可以清理數據，以及是如何使用的。這可能是大企業高度隔離的問題。如果沒有咨詢許多部門，它可能會很難正確地映射你的數據模型。

如果不采取正確的層次結構，分析可能會受到嚴重阻礙。一個實例將是創建一個用于制造公司上層管理的儀表板。如果工廠位置層級沒有正確映射，用戶將無法深入數據。當然，這只是一個簡單的例子。而數據模型不正確維度的層次結構，還需要過于復雜的查詢來獲得所需要的分析信息，創建屬性關系不一致，甚至防止一些分析被完全執行。

在你的分析過程需要移動之前，最好是規劃出你的數據模型和正確的層次結構。

7.忽略小數據源

不可避免的是，關鍵的業務數據存儲在各種各樣的地方。數據存儲在電子表格、數據庫、筆記本電腦、移動設備、備忘錄、收據等，也許相當大的一部分可遇不可求，對于從所有的這些“信息孤島”的數據采集分析。一個大的錯誤是基于一個不完整的數據集，忽略這些較小的數據源得出結論。

這對于規模較小的公司來說，并不具備一個連接各部門和集中的數據強大的基礎設施，更是如此，還是因為加入多個數據源仍然是一個IT處理過程，不能由用戶進行處理。小企業可以以指數速率增長，而與數據收集保持同步增長，通常讓人頭疼的一件事。因此，在企業運行分析的時候，它有許多信息孤島，需要包括準確的結果。

例如，采用電子表格是行政助理使用跟蹤客戶和通信進行客戶分析的關鍵。離開了電子表格，可能無法實現重要的連接。它可能是唯一的記錄，而可能來自兩個不同的來源的兩個客戶的名字實際上是同一個客戶。這種事情可能讓人頭痛。

人們的底線是，一定要采取從這些數據源識別和收集數據的時間。它可以創造或打破您的分析。

結論

你可能已經注意到，當涉及到你的數據分析建模時，就有一個共同的主題，那就是規劃。花時間來規劃你分析的目標，并合并來自許多來源的數據。如果使用得當，數據建模變得更加容易，你的數據會分析生成更可靠，可操作的見解。

你的規劃階段應包括以上列出的要點。這也應當比實際建模時間長得多。人們要抽出時間來設置一些標準，收集所有的數據，確定各種資源的目標。