預算友好型數據挖掘指南

與 API 功能每天都在變化的傳統應用程序編程不同，數據庫編程基本保持不變。 Microsoft Visual Studio .NET 的第一個版本於 2002 年 2 月發布，大約每兩年發布一個新版本，不包括 Service Pack 版本。 這種快速變化的步伐迫使 IT 人員每隔幾年就評估他們公司的應用程序，使他們的應用程序的功能完好無損，但使用完全不同的源代碼，以便與最新的技術和技術保持同步。

您的數據庫源代碼也不能這樣說。 SELECT / FROM / WHERE / GROUP BY的標準查詢，寫在 SQL 的早期，今天仍然有效。 當然，這並不意味著關係數據庫編程沒有任何進步。 有，而且它們比技術更符合邏輯。

從 Bill Inmon 和 Ralph Kimball 發表他們關於數據倉庫設計的理論開始，數據庫編程的進步一直集中在防止有價值信息的丟失和從數據中提取所有有價值的信息上。 一旦 Inmon 和 Kimball 將數據庫世界引入數據倉庫，對 ETL（提取/轉換/加載）工具進行了重大更改，使數據庫開發人員可以輕鬆訪問元數據以及來自非關係數據庫源的數據，這些數據很難使用在過去。 這增加了可用於提取有價值信息的數據量，並且可用數據的增加導致通過 OLAP 多維數據集和數據挖掘算法進行數據處理的進步。

將數據倉庫、OLAP 多維數據集和數據挖掘算法添加到您的數據庫架構中可以顯著簡化業務流程並闡明數據中的模式，否則您將永遠不知道存在這些模式。 自動化還可以對商業智能功能產生深遠的影響。

但是，在開始添加新工具和技術之前，應確保正確構建事務數據庫。

交易數據庫

事務數據庫是基礎，如果你的事務數據庫不可靠和不准確，那麼在上面添加任何東西都是災難的根源。

向數據庫添加額外層時要記住的重要一點是，所有項目都需要顯示投資回報，這就是為什麼最好在添加更多層之前充分利用當前架構的原因。 所有這些層都使用源自事務數據庫的數據。 在許多情況下，您只需查詢事務數據庫即可獲得相同的輸出。 當然，從數據倉庫或 OLAP 多維數據集讀取所有報告是理想的方法，但是當組織還沒有準備好應對這種複雜程度時，首先滿足其報告需求更為重要。 一旦滿足了基本的報告需求，就可以更容易地開始討論適當的數據倉庫（可能還有 OLAP 多維數據集）如何使其業務受益。

幾乎每個程序員都知道數據庫規範化的三個規則。 從事務數據庫讀取的存儲過程是優化的途徑。 要尋找的問題是可讀性、對同一個數據庫表的多次調用以及不必要的變量使用。

所有精英數據庫程序員都對其存儲過程的可讀性很挑剔。 數據庫專業人員格式化查詢的方式有一些共同點，這與應用程序開發人員不同。 通常，關鍵字和聚合函數使用大寫字母，而表名和字段名使用駝峰式或下劃線。 表別名與實際表名有一些相關性。 存儲過程各部分的對齊方式具有某種類型的塊模式。

下面是一個使用可讀格式的查詢示例。

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

接下來要查找的是查詢是否多次命中表。 在大多數查詢中，一個表只需要訪問一次，不包括您需要聚合另一個聚合函數的極少數情況。 這是一些應用程序程序員犯的另一個錯誤，可能是因為應用程序程序員從面向對象設計的角度來思考。

面向對象的設計為每個獨特的數據元素創建單獨的對象，但數據庫程序員需要從集合邏輯的角度進行思考。 僅僅因為查詢訪問表的次數比需要的次數多，並不意味著查詢產生的數據不准確，但是查詢的性能會受到影響。

另一個問題是每次連接時都會刪除或重複記錄，從而影響查詢的準確性。 變量的不必要使用是查詢是由應用程序開發人員開發的另一個標誌。 應用程序開發人員在其代碼中使用變量，而查詢很少需要使用變量，除非聲明為存儲過程的參數。 這再次表明開發人員沒有從集合邏輯的角度進行思考。

ETL（提取轉換負載）和報告

一旦客戶的事務數據庫具有正常運行的查詢，下一步就是簡化業務流程。

確定企業對 ETL 流程或自動報告的需求的最簡單方法是找出誰正在從事務數據庫中讀取數據，然後使用電子表格處理數據。 電子表格與數據庫表的結構相同。 兩者都包含行和列。 如果您有最終用戶自己處理數據，您應該問自己：“為什麼不能自動化該過程？”

自動化業務流程可以立即獲得投資回報，在進行更昂貴的項目（例如數據倉庫）之前應始終考慮這一點。 識別通過電子表格操縱數據的最終用戶可能聽起來很簡單，但這個過程有一個警告。

開發人員喜歡自動化流程； 這就是他們所做的。 最終用戶不一定喜歡自動化流程，尤其是當他們威脅到他們的工作時。 所以，不要天真地認為最終用戶會跑到你面前並確定可以自動化的日常任務。 您確實需要帶頭識別精簡機會。

一個構建良好的 ETL 系統還應該提供將事務數據庫中加載的所有數據回溯到原始源文件的能力。 這是數據庫架構的關鍵部分。 如果您不知道添加每條記錄的確切日期/時間以及添加記錄的源名稱（用戶名或文件名），那麼您就沒有準備好處理加載到事務數據庫中的錯誤數據。 您應該問自己：“如果有人向我們發送了錯誤文件怎麼辦？” 您需要多長時間才能識別出其中的記錄？

數據倉庫

數據倉庫設計有兩種理論。 Inmon 和 Kimball 理論之間的區別可以總結如下：

Inmon 的理論是首先開發一個數據倉庫，然後構建維度數據集市，以便從數據倉庫中進行報告。 Kimball 理論是首先開髮用於報告的維度數據集市，然後將它們合併在一起以創建數據倉庫。

您總是希望為客戶提供最快的投資回報。 構建數據集市是一個簡單的過程。 您首先獲取報表背後的查詢，然後將它們從返回結果集更改為將結果集存儲在永久表中。 您只需添加TRUNCATE TABLE名； 在原始SELECT關鍵字之前INSERT INTO表名。 一旦你有了一些功能性的數據集市表，就應該確定合併數據集市的機會； 查找使用相同表列表的報表查詢，然後合併字段列表。 這需要更複雜的查詢，尤其是當表列表增加時。 但是，只要您徹底測試查詢，就可以在不中斷正常業務流程的情況下進行每次增量更改。

每次對 Kimball 數據倉庫設計進行增強時，您都有機會向客戶展示 ROI。 這是因為首先構建數據倉庫，而報表數據集市是從靜態數據倉庫構建的。 因此，您在數據倉庫項目的早期就承擔了大部分成本。

OLAP 多維數據集

OLAP 多維數據集可以通過提供具有快速響應時間的聚合數據、針對最終用戶的特別下鑽功能和數據挖掘來使組織受益。 當您擁有適當的 OLAP 多維數據集時，您可以從數據中提取每一點價值。 OLAP 多維數據集構建在數據倉庫之上，但它使用與標準數據庫 SQL 不同的語言 MDX。 它還需要比數據庫服務器更多的配置工作。 這種複雜性使 OLAP 項目變得昂貴，而且很難找到有經驗的 MDX 開發人員。

數據架構師有時會看到現有的 OLAP 多維數據集，只不過是一個使用多維數據集的簡單儀表板，沒有一個無法被 SQL 查詢、數據倉庫或預製報告替代的流程。 OLAP 多維數據集可以提供比預設報告更快的響應時間，但在大多數情況下，差異可以忽略不計。 您還可以從向下鑽取功能中受益，但是，在向最終用戶提供向下鑽取功能之前，最好使用提供類似臨時界面的預製報告。

這允許您記錄最終用戶正在運行的即席查詢，然後您可以識別最終用戶沒有意識到可以創建的新預製報告。 由於在開發 OLAP 多維數據集時響應時間和向下鑽取的改進通常都很小，因此在客戶需要可以處理相關數據挖掘的數據庫架構之前，沒有必要向客戶推薦它。 這是您真正可以給客戶留下深刻印象並向他們展示他們的業務的一些東西，如果沒有強大的數據庫架構，他們可能永遠不會知道。

如前所述，構建 OLAP 多維數據集可能具有挑戰性。 考慮混合 OLAP 多維數據集是個好策略。 Microsoft Excel 的 PowerPivot 提供了易於使用的數據挖掘工具，而沒有成熟的 OLAP 多維數據集的複雜性。 混合的主要缺點是它沒有相同的響應時間。 但是，一個很大的優勢是，與使用 MDX 相比，使用 Excel 創建數據挖掘報告更容易。 數據挖掘時，有三種有用的報告。 我們可以看看一些現實世界的例子以及如何解釋它們。

所有這些報告均來自作者構建的自動日內交易應用程序。

可視化報告

散點圖報告

散點圖報告是比較兩個變量的詳細程度報告。 為實際點添加顏色和大小有助於可視化與這些變量相關的實際結果。

盒須報告

此報告總結了散點圖報告中的 x 和 y 值。 x 軸值被離散到一組桶中。

每個晶須（線）的末端代表異常值。 黃色和淺藍色條表示上限和下限一個標準偏差範圍。

線性回歸模型

此報告顯示 x 和 y 軸值之間的相關性，以及線條的平滑度，可以用數學公式表示。 包含 R 平方值以顯示相關性的可靠性。

結論

隨著公司的發展，通常您的數據庫也會增長。

大多數組織最初不需要數據庫專業人士或專門的數據科學公司來處理他們的需求。 相反，他們讓 IT 員工承擔多項職責，或者俗話說，“身兼數職”。 這在一定程度上有效，但最終，您需要聘請專家。

本文檔中列出的項目是識別您可能沒有意識到的數據庫問題的快速簡便的方法。 希望它還涵蓋瞭如何構建一流的數據挖掘工具，而無需在昂貴的軟件許可證上花費大量資金。 通過這種方式，您將更好地了解通過向 IT 員工添加數據庫專業人員可以使您的組織受益多少。