試論基于olap技術的圖書銷售智能分析系統(tǒng)

目 次1 緒論1.1 引言隨著在數據庫中存儲的數據越來越多，人們已經不滿足于僅僅用計算機來實現業(yè)務的電子化，而希望從已有的數據中提煉出信息服務于決策人員。在這種情況下。OLAP作為一種強有力的分析和決策工具，被越來越多的沒、部門使用，同時在OLAP技術上也進行了許多工作。但是主要工作都是集中在如何有效對數據進行分析上。OLAP的數據倉庫是為了解決能從大量的數據中得到有用的信息而做出了很大的貢獻。對于一個企業(yè)而言，每天都要面臨著大量的決策問題，隨著企業(yè)市場競爭的加劇和信息社會需求的發(fā)展，企業(yè)從大量數據中提取所需的各類信息就顯得越來越重要了，傳統(tǒng)的數據庫技術是單一的數據庫資源，他適合操作型事務處理，但對分析型處理的能力較弱。近幾年來，在信息技術領域興起并日益成熟的數據倉庫技術以其面向主題組織、存儲海量信息，以及在線分析支持組織機構管理決策等優(yōu)秀功能成為和應用的熱點。數據倉庫系統(tǒng)的基本功能是：數據獲取、數據存儲和管理、信息的訪問。其最終目的是把分散的、不利于訪問的數據轉換成集中、統(tǒng)一、隨時可用的信息，即為了決策目標將不同形式的數據集合成為一種特殊的格式，建立起一種新的數據存儲體系，使數據操作環(huán)境與數據分析環(huán)境相到分離。數據倉庫利用了計算機和信息技術（IT）的最新發(fā)展，把那些大量的，分散的企業(yè)數據進行集成，并從中把企業(yè)決策所需要的信息分離出來，借助OLAP利用存儲在數據倉庫中的數據，去進行各種分析操作，并以較為直觀易懂的形式將結果返回給用戶，能更加有效地支持企業(yè)的分析和決策，從而提高決策的質量與速度。1.2 WEB環(huán)境下的OLAP技術的背景和歷史現狀WWW（World Wide web）技術的問世，給Internet帶來了新的活力，也得到全世界的認可和信賴。隨著WEB的普及，人們之間的信息溝通更加的快捷和方便。WEB上的訪問數據庫也得到了日益廣泛的應用，使數據庫技術不斷地發(fā)展和更新。近年來，隨著企業(yè)信息化的飛速發(fā)展。企業(yè)擁有大量業(yè)務數據，但難以及時有效的利用數據信息用來給管理者做決策工作。數據倉庫技術的運用使這個問題迎刃而解，數據倉庫正是由數據庫演化而來是為了更好的處理和維護WEB上的龐大的訪問數據和企業(yè)中的業(yè)務數據。不僅如此，數據倉庫技術還有另一方面的用處即使如何讓經營管理者更好的使用數據信息來做決策工作，從而給企業(yè)管理者或經營者帶來經濟效益。為了實現這樣的目的還要把OLAP技術運用于數據倉庫技術上面。OLAP技術作為一種強大有力的分析和決策工具，被越來越多的企業(yè)管理者和經營者使用。為了在OLAP技術上得到更有效的數據信息，并使用了體系結構即是C/S結構。在C/S體系結構中使用OLAP技術已經暴露出很多問題。為了解決這樣的問題而進行對WEB環(huán)境下的OLAP技術的研究和實現。在數據庫發(fā)展的早期，因為數據量不大而使數據庫技術的查詢功能和操作功能沒得到明顯的區(qū)分。但是隨著數據庫規(guī)模的擴大，人們對數據的要求也有了其他的想法，比如想取得以往的歷史數據來做決策工作使在激烈的社會經營中取得勝利。管理者或經營用戶要想拿到這樣的歷史性有用處的數據信息必須經過復雜的查詢才能得到，特別是那些高層人員更需要這樣有決定性的數據信息來做決策工作。在數據倉庫中使用OLAP技術正好讓這樣工作得到滿足。但是現在傳統(tǒng)的基于C/S結構的OLAP體系結構卻帶來很多問題。傳統(tǒng)的基于C/S結構的OLAP體系結構，其基本流程是由熟悉數據庫結構的系統(tǒng)管理員對數據庫結構進行分析，根據其業(yè)務知識將數據庫中的表及字段映射為多維結構，構造由多維結構構成的超立方體，然后根據用戶分析員在使用過程中的要求對多維視圖進行修改，從而再次構造超立方體，如此循環(huán)往復。這種結構在使用過程中暴露出了不少的問題：如首先，顧客使用一次而要進行一次安裝和配置，使維護工作量大大的增加。其次，對存放在顧客端的報告的修改也是很復雜的。再者，其安全性也是很薄弱的。OLAP技術是一種對數據進行多維查詢的工具，主要是給管理者和經營者等決策性人員使用的，所以需求是多變性的。C/S結構不適應需求的多變性所帶來的要求，而有足夠靈活性的Internet/Intranet的3層結構適應了OLAP技術對需求的多變性的要求。2 系統(tǒng)設計的技術創(chuàng)新2.1 數據倉庫技術根據數據倉庫概念的含義，數據倉庫擁有以下四個特點：（1）面向主題。操作型數據庫的數據組織面向事務處理任務，各個業(yè)務系統(tǒng)之間各自分離，而數據倉庫中的數據是按照一定的主題域進行組織。主題是一個抽象的概念，是指用戶使用數據倉庫進行決策時所關心的重點方面，一個主題通常與多個操作型信息系統(tǒng)相關。（2）集成的。面向事務處理的操作型數據庫通常與某些特定的應用相關，數據庫之間相互獨立，并且往往是異構的。而數據倉庫中的數據是在對原有分散的數據庫數據抽取、清理的基礎上經過系統(tǒng)加工、匯總和整理得到的，必須消除數據源中的不一致性，以保證數據倉庫內的信息是關于整個企業(yè)的一致的全局信息。 （3）相對穩(wěn)定的。操作型數據庫中的數據通常實時更新，數據根據需要及時發(fā)生變化。數據倉庫的數據主要供企業(yè)決策分析之用，所涉及的數據操作主要是數據查詢，一旦某個數據進入數據倉庫以后，一般情況下將被長期保留，也就是數據倉庫中一般有大量的查詢操作，但修改和刪除操作很少，通常只需要定期的加載、刷新。（4）反映歷史變化。操作型數據庫主要關心當前某一個時間段內的數據，而數據倉庫中的數據通常包含歷史信息，系統(tǒng)記錄了企業(yè)從過去某一時點(如開始應用數據倉庫的時點)到目前的各個階段的信息，通過這些信息，可以對企業(yè)的發(fā)展歷程和未來趨勢做出定量分析和預測。企業(yè)數據倉庫的建設，是以現有企業(yè)業(yè)務系統(tǒng)和大量業(yè)務數據的積累為基礎。數據倉庫不是靜態(tài)的概念，只有把信息及時交給需要這些信息的使用者，供他們做出改善其業(yè)務經營的決策，信息才能發(fā)揮作用，信息才有意義。而把信息加以整理歸納和重組，并及時提供給相應的管理決策人員，是數據倉庫的根本任務。因此，從產業(yè)界的角度看，數據倉庫建設是一個工程，是一個過程。如圖2.1.1所示。圖2.1.1數據倉庫體系結構圖數據源：是數據倉庫系統(tǒng)的基礎，是整個系統(tǒng)的數據源泉。通常包括企業(yè)內部信息和外部信息。內部信息包括存放于RDBMS中的各種業(yè)務處理數據和各類文檔數據。外部信息包括各類法律法規(guī)、市場信息和競爭對手的信息等等；數據的存儲與管理：是整個數據倉庫系統(tǒng)的核心。數據倉庫的真正關鍵是數據的存儲和管理。數據倉庫的組織管理方式決定了它有別于傳統(tǒng)數據庫，同時也決定了其對外部數據的表現形式。要決定采用什么產品和技術來建立數據倉庫的核心，則需要從數據倉庫的技術特點著手分析。針對現有各業(yè)務系統(tǒng)的數據，進行抽取、清理，并有效集成，按照主題進行組織。數據倉庫按照數據的覆蓋范圍可以分為企業(yè)級數據倉庫和部門級數據倉庫（通常稱為數據集市）。 OLAP服務器：對分析需要的數據進行有效集成，按多維模型予以組織，以便進行多角度、多層次的分析，并發(fā)現趨勢。其具體實現可以分為：ROLAP、MOLAP和HOLAP。ROLAP基本數據和聚合數據均存放在RDBMS之中；MOLAP基本數據和聚合數據均存放于多維數據庫中；HOLAP基本數據存放于RDBMS之中，聚合數據存放于多維數據庫中。前端工具：主要包括各種報表工具、查詢工具、數據分析工具、數據挖掘工具以及各種基于數據倉庫或數據集市的應用開發(fā)工具。其中數據分析工具主要針對OLAP服務器，報表工具、數據挖掘工具主要針對數據倉庫。2.2 OLAP 技術聯機分析處理（OLAP）主要有兩個特點，一是在線性（On-Line），表現為對用戶請求的快速響應和交互式操作，它的實現是由Client/Server這種體系結構來完成的，二是多維分析（Multi-dimensional）,這也是OLAP技術的核心所在。OLAP的在線性體現在于用戶的交互響應和快速響應，多維性則體現在它建立在多維視圖的基礎上，對數據進行由淺到深的分析。OLAP的用戶是企業(yè)中的專業(yè)分析人員及管理決策人員，他們在分析業(yè)務經營的數據時，從不同的角度來審視業(yè)務的衡量指標是一種很自然的思考模式。例如分析銷售數據，可能會綜合時間周期，產品類別，分銷渠道，區(qū)域分布，客戶等多種因素來考慮。這些分析角度雖然可以通過報表來反映，但是每一個分析的角度可以生成一張報表，各個分析角度的不同組合又可以生成不同的報表，使得IT人員的工作量相當大，而且往往難以跟上管理決策人員思考的步伐。所以OLAP的多維性較好地滿足了企業(yè)管理人員的需要。管理人員可對OLAP進行操作，即對多維數據集中的數據進行切片，切塊，旋轉，上卷和下鉆操作，以對數據進行分析，讓用戶多角度、多側面地去觀察數據倉庫中的數據，從而深入了解數據倉庫中數據所蘊含的信息，并找出隱含在數據中的商業(yè)模式。根據綜合性數據的組織方式的不同，目前常見的OLAP主要有基于多維數據庫的MOLAP及基于關系數據庫的ROLAP兩種。MOLAP是以多維的方式組織和存儲數據，ROLAP則利用現有的關系數據庫技術來模擬多維數據。在數據倉庫應用中，OLAP工具一般是數據倉庫應用的前端工具，同時OLAP工具還可以配合數據挖掘進行使用，增加決策分析預測功能。數據倉庫的基本任務是使用獲得的數據來進行大量的分析，以生成支持用戶制定戰(zhàn)略決策的信息。為了讓數據倉庫能作有意義的分析，數據必須以某種方法被映射，以便用戶能利用一些數據來分析隨著時間變化各商業(yè)維度的關鍵指標的數值。2.3 數據挖掘的技術數據挖掘是一種數據分析工具，它從大量的、不完全的、有噪聲的、模糊的、隨機的數據中提取人們感興趣的數據模式、數據的普遍關系及其隱含在其中的、人們事先不知道的、但又是潛在有用的信息和知識，提取的知識表示為概念、規(guī)則、規(guī)律、模式等形式，其目的是幫助決策者尋找數據間潛在的關聯，發(fā)現被忽略的要素，而這些信息對預測趨勢和決策行為將起到一定的支持作用。數據庫中的數據挖掘是一個多步驟的處理過程，這些步驟有：（1）數據定義階段，主要了解相關領域的有關情況，熟悉背景知識，弄清楚用戶決策分析對信息的要求。（2）數據提取階段，根據要求從數據庫中提取相關的數據。（3）數據預處理階段，主要對前一階段產生的數據進行再加工，檢查數據的完整性及數據的一致性，對其中的噪音數據進行處理，對缺損的數據進行填補。（4）數據挖掘階段，主要是運用選定的知識發(fā)現算法，從數據中提取出用戶所需要的知識，這些知識可以用一種特定的方式表示或使用一些常用的表示方式。（5）知識評估階段，將發(fā)現的知識以用戶能了解的方式呈現，根據需要對知識發(fā)現過程中的某些處理階段進行優(yōu)化，知道滿足要求。2.4 OLAP與數據挖掘的關系（1）OLAP與數據挖掘都屬于分析型工具，兩者的區(qū)別在于：數據挖掘的分析過程是自動的，用戶不必提出確切的問題，只需用挖掘工具去挖掘隱藏在海量數據中的模式并預測未來的趨勢，這種方式有利于發(fā)現未知的事實，但缺乏引導的數據挖掘，往往所發(fā)現的許多模式實用性很差。OLAP是一種自上而下、不斷深入的驗證型分析工具，它常常以用戶的假設為基礎對數據查詢與分析，進而提取出相關的信息。所以OLAP在數據分析方面存在著一定的局限性，即數據倉庫的結構設計的模式不同決定了OLAP對數據的分析效果與分析層次；同時由于OLAP是用戶驅動的，用戶對所分析問題認識和理解程度在一定程度上會影響到最終的分析結果。從對數據分析的角度看。OLAP位于較淺的層次；由于數據挖掘可以發(fā)現OLAP所不能發(fā)現的更為復雜而細致的信息，因而處于相對較高的層次。（2）OLAP與數據挖掘的相互作用體現在以下幾個方面：OLAP與數據挖掘同作為數據分析工具，二者相比互有優(yōu)劣。數據挖掘結果的無法預測性及挖掘結果是否有效等不足，決定了數據挖掘需要另外一個分析工具作輔助，對其結果進行驗證。OLAP是針對多維數據庫而開發(fā)的分析工具，可以對多維數據進行較為全面的映射。所以在數據倉庫的基礎上，OLAP與數據挖掘有了結合的可能，即數據挖掘的結果可以通過OLAP進行驗證，數據挖掘在有驗證的前提下，其挖掘結果將呈現螺旋式上升的過程，逐步從模糊、混沌走向清晰、客觀，進而表現為有價值的知識。成功的數據挖掘需要對數據進行探索性的分析。挖掘所需的數據范圍也許只是數據倉庫的一部分，在此意義上，OLAP對多維數據的鉆取、旋轉等操作同樣可以應用于數據挖掘的過程中，作為基于數據倉庫挖掘的引導步驟。3 系統(tǒng)解決方案3.1 在WEB環(huán)境下OLAP技術的研究長久以來，對數據庫的操作都有兩種不同的應用方式。一種是日常的對數據的操作型應用，另一種是對數據的查詢型應用。這兩種應用有著很大的區(qū)別，如表3.1.1。操作型應用查詢型應用涉及的表或字段不多涉及大量的表和字段以增刪操作為主，查詢量少不修改數據，但進行大量的查詢以業(yè)務人員使用為主，主要是細節(jié)信息面向管理人員或決策人員，關注匯總信息和導出信息使用當前數據可能用到大量的歷史信息表3.1.1兩種應用的區(qū)別在數據庫發(fā)展的早期，因為數據量不大，查詢型應用和操作型應用的區(qū)別還不太明顯。但隨著數據庫規(guī)模的逐漸增大，人們希望利用已經有的歷史數據來使自己在激烈的競爭中取勝，分析人員經常是希望從多個不同的角度來觀察一個或多個指標的值，并且希望從中找到這些指標之間的關系，這些要求導致查詢復雜度越來越高，特別是這些查詢請求是分析人員在分析過程中根據顯示的數據而實時產生的。這樣的要求是業(yè)務系統(tǒng)無法勝任的。而OLAP技術就能夠解決這樣的查詢要求。OLAP操作最主要的一點是要給分析人員提供一個多維數據超立方體，分析人員不需要了解實際的數據庫結構，他所看見的是與其習慣的企業(yè)邏輯結構相似的多維結構。根據他所關注的目的的不同，在多維結構內今昔感多維操作，如鉆取、上挖、漂移、切片、切塊等。數據庫管理人員的責任就是根據企業(yè)的組織結構和實際使用人員的要求，在已經有的數據倉庫上構造多維數據庫及多維視圖。傳統(tǒng)的基于C/S結構的OLAP體系機構，其基本流程是由熟悉數據庫結構的系統(tǒng)管理員對數據庫結構進行分析，根據其業(yè)務知識將數據庫中的表及字段映射為多維結構，構造由多維結構構成的超立方體，然后根據用戶分析人員在使用過程中的要求對多維視圖進行修改，從而再次構造超立方體，如此循環(huán)往復。這種結構在使用過程中暴露出了不少的問題：（1）在每一個客戶端都要安裝和配置多維查詢軟件。維護工作量很大；（2）報告內容要根據使用者在使用過程中碰到的要求進行修改，因此要維護客戶端的報告內容一致也是很復雜的；（3）因為報告存放在客戶端。因此可能會被修改，從而安全性也很不好。出現這些問題的根本原因是沒有注意到OLAP的特殊性：OLAP作為一個多維查詢工具，不同于傳統(tǒng)的業(yè)務系統(tǒng)，主要是給管理和決策人員使用的，需求是多變的，所以IT人員不可能依次設計出符合分析人員要求的超立方體，需要在使用過程中根據要求對超立方體不斷進行調整和修改，但是這種多變性是C/S結構所不能適應的。而且有基于Internet/Intranet的3層結構才具有足夠的靈活性。WEB服務器負責完成瀏覽器與OLAP服務器，數據倉庫系統(tǒng)之間的通信連接。如圖3.1.1所示。一般來說，WEB服務器通過使用CGI腳本、WEB服務器API、應用API和數據庫API等，管理瀏覽器的通信。在瀏覽器端，通過HTML、DMX、ActiveX控件、C#.NET來完成與用戶的交互截面和控件。在實現基于WEB的OLAP應用時，往往采用自頂向下的設計。首先要確定用戶如何在瀏覽器中的到報表信息，然后再給出一系列的過程完成基于瀏覽器的OLAP操作。這些過程應當包括發(fā)布信息，提供HTTP對數據庫或應用服務器的動態(tài)數據請求，設計支持分析功能的界面。在客戶端基于WEB瀏覽器的OLAP報表被分為幾個層次，其中包括沒有分析功能的靜態(tài)報表和能夠進行分析的OLAP應用界面，如維的旋轉，數據的鉆取等。另外，特別要提到的是，標準的HTML界面缺乏操作的靈活與方便。C#.NET和ActiveX控件的使用會大大提高用戶截面的友好程度，用戶通過簡單的操作就可以完成“旋轉”、“鉆取”的操作。數據倉庫系統(tǒng)OLAP服務器WEB服務器客戶瀏覽器 CGI API C#.NET、ActiveX 控件圖3.1.1基于WEB的OLAP結構圖3.2 在WEB環(huán)境下OLAP技術的實現方案OLAP專門用于支持復雜的決策分析，支持信息管理和業(yè)務管理人員決策活動的一種決策分析工具。它可以根據分析人員的要求，迅速、靈活地對大量數據進行復雜的查詢處理，并且以直觀的、容易理解的形式將查詢結果提供給各種決策人員，使他們迅速、準確地掌握企業(yè)的運營情況，了解市場需求。而要進行OLAP多維數據分析就需要根據分析需求，同時結合數據倉庫中的數據結構和特點建立OLAP多維模型。以超市銷售系統(tǒng)為例子，并對該例子的OLAP銷售多維模型進行了設計，如圖3.2.1。時間編號年季度月日食品編號時間編號客戶編號食品名稱銷售數量銷售額平均價格食品編號食品類別編號食品名稱客戶編號區(qū)域編號客戶名稱食品類別編號食品類別名稱區(qū)域編號省市 銷售事實表 食品維表 食品類別維表 客戶維表 區(qū)域維表 時間維表 圖3.2.1 超市銷售分析的OLAP模型從圖中可以看出在超市銷售分析的OLAP模型中有一個銷售事實表，在該事實表中每個元組只存儲了一些指向各個維表的指針（即外鍵，時間編號、食品編號、客戶編號等）和一些相應的測量數據（度量值），銷售數量、銷售額和平均價格，而與這些外鍵相對應的主鍵則分別存放不同的維表中（時間維表、客戶維表、食品維表等）。對事實表的查詢就是獲取指向維表的指針，當對事實表的查詢與對維表的查詢結合起來的時候，就可以檢索大量的信息。一個完整的基于WEB的OLAP銷售分析系統(tǒng)由三方面組成。第一，提取、清洗數據組成數據倉庫；第二利用OLAP引擎建立相應的銷售分析的OLAP立方體；第三使用前端開發(fā)工具，在WEB上訪問OLAP立方體中包含的對象和集合。這里選用了SQL SERVER 2005 Analysis Services作為數據倉庫支撐平臺，SQL SERVER 2005的Analysis Services 是一個管理多維數據集的服務器，數據源并抽取數據，實現高效地將客戶數據加載到客戶數據倉庫中；服務器支持MDOLAP、ROLAP和HOLAP三種存儲模式，用戶自己定義使用的存儲模式，定義各個維度并建立銷售多維數據集，從而完成整個銷售過程。文檔由本人精心搜集和整理，喜歡大家用得上，非常感謝你的瀏覽與下載。凡本廠職工應熱愛電廠、熱愛崗位、熱愛本職工作，發(fā)揚“團結務實、爭創(chuàng)一流，立足崗位，愛廠敬業(yè)，盡職盡責，不斷提高工作質量和工作效率，圓滿完成各項生產和工作任務，為華能的建設和發(fā)展作出貢獻2019整理的各行業(yè)企管，經濟，房產，策劃，方案等工作范文，希望你用得上，不足之處請指正4 圖書銷售分析系統(tǒng)的總體設計和實現4.1 系統(tǒng)的功能本系統(tǒng)的功能可以劃分為會員分析和圖書分析兩大部分(如圖4.1.1圖書小時分析系統(tǒng)功能結構圖。圖書銷售分析系統(tǒng)會員分析圖書分析分析會員級別分析會員消費分析會員類型分析圖書推薦銷售趨勢分析銷售關聯分析圖書銷量分析圖書定價分析圖4.1.1圖書銷售分析系統(tǒng)功能結構圖其中會員分析是對書店注冊會員的信息進行分析，具體功包括：（1）會員級別分析：根據會員的個人信息來預測該會員最有可能成為哪級會員。（2）會員消費分析：根據會員的個人信息來預測該會員在書店的消費類型。（3）會員類型分析：根據會員的個人信息和消費記錄來對會員進行自動分類。（4）圖書推薦：根據會員的以往購書記錄來向推薦其他可能感興趣的圖書。其中圖書分析則是對書店圖書的信息進行分析，具體功能包括：（1）銷售趨勢分析：根據圖書的歷史銷售信息來預測未來的銷售額。（2）圖書銷量分：根據圖書的基本信息來預測其銷量。（3）銷售關聯分析：分析哪些圖書經常會被一同銷售。（4）圖書定價分析：根據圖書的基本信息來估算定價。4.2 數據源設計4.2.1 數據庫設計 數據庫邏輯設計根據系統(tǒng)的需求分析定義系統(tǒng)中的實體，并采用E-R圖來（如圖2.2.1圖書銷售E-R圖）表現實體之間的邏輯關系。在關系圖中主要有會員和圖書兩個實體，會員買書的一些情況和推薦書的情況。圖書中包含了圖書的銷售量等相關信息。會員會員號姓名入會時間級別生日地區(qū)地址性別電話郵箱積分圖書國際標準圖書號圖書號光盤書名存儲量出版社出版日期價格上架時間頁數條碼號買書推薦書銷售數據銷售量會員號銷售時間推薦數據書號類型折扣情況級別折扣率NNNN級別號 圖4.2.1圖書銷售E-R圖 數據庫結構設計在邏輯設計的基礎上，進行了結構設計，數據庫的設計主要有五個數據表和三個視圖，下面分別對五個數據表和三個視圖進行說明。（1）會員表：主要是記錄會員的姓名、性別、地址、電話號碼、會員號、會員的級別、會員的入會時間。這些對視圖進行查詢有很大用處，同時對分析進行預測提供了可靠的信息資源。（2）圖書表：主要是記錄圖書的名字、出版社、出版時間、國際標準圖書號、內帶光盤、存儲量、上架日期、條碼、價格、書的頁數（3）買書的記錄表：主要記錄會員買書的情況，里面記錄會員的會員號、買書的時間、買書消費額。（4）折扣表：主要是記錄會員的級別所打的折扣。表內包括級別和折扣率。（5）圖書銷售情況表：主要記錄圖書銷售的情況。主要記錄圖書號、圖書的銷售額、圖書銷售的數量、圖書銷售的折扣。（6）圖書視圖：主要是進行圖書與會員的綜合查詢，它包含了圖書的基本信息和銷售情況匯總。（7）圖書銷售視圖：主要是對圖書的銷售情況的綜合查詢，它包含了圖書的銷售細明信息。（8）圖書每周銷售視圖：主要是對圖書進行每周的銷售情況的綜合查詢，它包含了圖書每周銷售銷量的信息。以下是五個數據表：表4.2.1會員表、表4.2.2圖書表、表4.2.3買書的記錄表、表4.2.4折扣表、表4.2.5圖書銷售表。列名數據類型允許空IDIntNameNvarchar(20)LevelsSmallintYRegTimeSmalldatetimeYGenderBitYBirthdaySmalldatetimeYDegreeNvarchar(20)YAreaNvarchar(20)YAddressNvarchar(256)YTelephoneNvarchar(50)YEmailNvarchar(50)YScoreIntY表4.2.1會員表列名數據類型允許空IDIntISBNNchar(10)NameNvarchar(256)CategoryIDIntYAuthorNvarchar(100)YPressNvarchar(50)YPublishDateSmalldatetimeYPriceSmallmoneyPagesSmallintYBarcodeNchar(13)CDBitYStorageIntYShelfDateSmalldatetimeY表4.2.2圖書表列名數據類型允許空IDIntCustomerIDIntYSumSmallmoneyYTimesmalldatetime表4.2.3買書的記錄表列名數據類型允許空LevelsIntDiscountFloat表4.2.4折扣表列名數據類型允許空IDIntSellIDIntBookIDIntNumberIntDiscountFloatYSumSmallmoneyY表4.2.5圖書銷售表以下是三個視圖表：表4.2.6圖書視圖、表4.2.7圖書銷售視圖、表4.2.8圖書每周銷售視圖。列別名表輸出排序類型排序順序分組依據篩選器IDBookY 升序1Group ByNameBookYGroup ByCategoryBookCategoryYGroup ByPressBookYGroup ByPriceBookYGroup ByRagesBookYGroup ByCDBookYGroup ByNumberSellNumberSellItemYSumSumSellSumSellItemYSumShelfDateBookYGroup By表4.2.6圖書視圖表4.2.6圖書視圖的綜合查詢的內部代碼為：SELECT TOP(100) PERCENT dbo.Book.ID, dbo.Book.Name, dbo.BookCategory.Category, dbo.Book.Press, dbo.Book.Price, dbo.Book.Pages, dbo.Book.CD,SUM(dbo.SellItem.Number) AS SellNumber,SUM(dbo.SellItem.Sum) AS SellSum, dbo.Book.ShelfDateFROM dbo.Book INNER JOINdbo.BookCategory ON dbo.Book.CategoryID = dbo.BookCategory.ID INNER JOINdbo.SellItem ON dbo.Book.ID = dbo.SellItem.BookIDGROUP BY dbo.Book.ID, dbo.Book.Name, dbo.BookCategory.Category, dbo.Book.Press, dbo.Book.Price, dbo.Book.Pages, dbo.Book.CD,dbo.Book.ShelfDateORDER BY dbo.Book.ID列別名表輸出排序類型排序順序分組依據篩選器IDSellItemYIDSellIDSellYCustomerIDSellYTimeSellYBookIDSellItemYISBNBookYNameBookYPressBookYPriceBookYNumberSellItemYDiscountSellItemYSumSellItemY表4.2.7圖書銷售視圖表4.2.7圖書銷售視圖的內部代碼和關系圖（圖2.2.2圖書銷售關系圖）：SELECT dbo.SellItem.ID, dbo.Sell.ID AS SellID, dbo.Sell.CustomerID, dbo.Sell.Time, dbo.SellItem.BookID, dbo.Book.ISBN, dbo.Book.Name, dbo.Book.Press, dbo.Book.Price, dbo.SellItem.Number, dbo.SellItem.Discount, dbo.SellItem.SumFROM dbo.Sell INNER JOIN dbo.SellItem ON dbo.SellItem.SellID = dbo.Sell.ID INNER JOIN dbo.Book ON dbo.Book.ID = dbo.SellItem.BookID圖4.2.2圖書銷售關系圖列別名表輸出排序類型排序順序分組依據DATEPART(week,dbo.sell.Time)WeekY升序1Group ByIDBookY升序2Group BySumSellSumSellItemYSum表4.2.8圖書每周銷售視圖表2.2.8圖書每周銷售視圖的內部代碼為：SELECT TOP (100) PERCENT DATEPART(week, dbo.Sell.Time) AS Week, dbo.Book.ID, SUM(dbo.SellItem.Sum) AS SellSumFROM dbo.Sell INNER JOIN dbo.SellItem ON dbo.Sell.ID = dbo.SellItem.SellID INNER JOIN dbo.Book ON dbo.SellItem.BookID = dbo.Book.IDGROUP BY DATEPART(week, dbo.Sell.Time), dbo.Book.IDORDER BY Week, dbo.Book.ID 設計好了以上的表和視圖是為了對其中的數據進行預測和分析，這些創(chuàng)建給以后的實現部分做了很好的鋪墊。4.2.2 圖書銷售 Analysis Services 設計 數據源設計 在數據源設計運用了數據挖掘技術，首先用“數據源向導”將數據中表2.2.1會員表、表2.2.6圖書視圖、表2.2.7圖書銷售視圖、表2.2.8圖書每周銷售視圖加入項目的數據源試圖中。其中會員表中存儲了書店注冊會員的基本個人信息；同時為了支持數據的分析，設計中還要向會員表中增加兩個計算列。兩個計算列分別為Age和DayConsume。它們的表達式分別為“YEAR(GETDATE()-YEAR(dbo.Customer.Birthday)”和“CAST(Score AS Decimal)/DATEDIFF(DAY,RegTime,GETDATE()” 是用來計算會員的年齡和會員的積分除以其注冊天數以得到該會員的日平均消費金額。合理地使用計算列，能夠大大方便挖掘結構和挖掘模型的創(chuàng)建，同時避免修改源數據庫中的基礎表格和視圖。在Analysis Services項目中也需要向圖書表中加入兩個計算器分別DaySellNumber和DaySellSum，計算表達式為：“SellNumber/DATEDIFF(DAY,ShelfDate,GETDATE()”、“SellSum/DATEDIFF(DAY,ShelfDate,GETDATE()”。它們是用來計算圖書日均銷量。為了對會員購書的有關信息進行挖掘，在數據源視圖中還應將會員表和圖書銷售視圖關聯起來。如圖4.2.3數據源視圖圖書銷售圖。如圖4.2.3數據源視圖圖書銷售圖數據源的設計對以后數據挖掘起到決定的作用。在本設計中使用了多個數據挖掘的方法。這些方法大大方便了界面的分析和預測。管理者通過預測的信息知道內部圖書銷售的各個情況和了解會員的相關活動信息。 本系統(tǒng)設計的挖掘模型（1）貝葉斯挖掘模型：是用來對會員級別的分析。主要運用了“Microsoft Nave Bayes”挖掘技術對數據源視圖中的會員表作為事例對Levels和DayConsume列作為可預測列進行預測。（2）決策樹挖掘模型：來分析會員的消費水平最有可能處在哪個區(qū)間，主要運用“Microsoft 決策樹”挖掘技術對數據源視圖中的會員表作為事例對Levels進行忽略，而對DayConsume進行可預測。（3）聚類分析挖掘模型：是用來分析會員的年齡和學歷進行分析。是忽略Area、Levels、Gender,而Age和Degree作為輸入列對DayConsume進行預測。（4）關聯規(guī)則挖掘模型：用于分析會員與圖書之間的關聯，進而向會員推薦其他可能感興趣圖書。在設計中用會員表作為事例表嵌套圖書銷售表，Gender、Age、Degree、Area作為輸入列，BookSell進行預測。（5）時序挖掘模型：是用于圖書的分析，用每周銷售視圖來做事例，ID和 Week作為輸入鍵對SellSum進行預測。（6）神經網絡挖掘模型：是預測新書的銷量，圖書表作為事例，Category、Press、Price、Pages和CD列進行輸入，對DaySellNumber進行預測。（7）順序分析挖掘模型：用于實現圖書銷售的關聯分析，會員表作為事例，圖書銷售表銷售表作為嵌套表，對Name進行預測。（8）線性回歸挖掘模型：是對圖書價格的預測，圖書表作為事例,Pages為輸入列，對Price進行預測。4.3系統(tǒng)界面設計4.3.1會員信息分析界面設計 對于會員信息分析的Windows窗體設計視圖如圖4.3.1所示。在對應的窗體類CustomerAnalysisForm.cs中定義了如下成員字段： protected SqlConnection _connDatabase; protected AdomdConnection _connAnalysis;protected AdomdCommand _cmd;其中前兩個數據連接對象分別指向SQL Server數據庫BookSell和Analysis Server數據庫，后一個數據命令對象則用于在Analysis Services數據庫上執(zhí)行DMX查詢對象的創(chuàng)建都在窗體的構造函數中完成：public CustomerAnalysisForm(SqlConnection connectionDatabase, AdomdConnection connectionAnalysis) _connDatabase = connectionDatabase; _connAnalysis = connectionAnalysis; _cmd = _connAnalysis.CreateCommand(); InitializeComponent(); 窗體在初始化和關閉將打開和關閉相應的數據連接；窗體的初始化過程同時還使用SQL數據命令將所有會員的ID號載入到“會員編號”組合框（cmbcustomerID）中：private void CustomerAnalysisForm_Load(object sender, EventArgs e) SqlCommand cmd1 = new SqlCommand(SELECT DISTINCT ID FROM Customer ORDER BY ID, _connDatabase); SqlDataReader reader1 = cmd1.ExecuteReader(); while (reader1.Read() cmbCustomerID.Items.Add(reader10); reader1.Close(); dgvLevels.AutoGenerateColumns = false; 圖4.3.1會員分析窗體CustomerAnalysisForm選擇會員編號并按下“載入會員信息”按鈕后，程序將再次通過SQL命令來讀取會員的個人信息，并顯示在窗體上部的各個控件中： private void btnLoadInfo_Click(object sender, EventArgs e) if (cmbCustomerID.Text = ) MessageBox.Show(會員編號不能為空, 錯誤, MessageBoxButtons.OK, MessageBoxIcon.Error); return; SqlCommand cmd1 = _connDatabase.CreateCommand(); cmd1.CommandText = SELECT Birthday, Area, Degree, Gender, RegTime, Levels, Score FROM Customer WHERE ID= + cmbCustomerID.Text; SqlDataReader reader1 = cmd1.ExecuteReader(); if (reader1.Read() dtpBirthday.Value = (DateTime)reader10; if (reader11 != DBNull.Value) cmbArea.Text = reader11.ToString(); if (reader12 != DBNull.Value) cmbDegree.Text = reader12.ToString(); if (bool)reader13) rdbMale.Checked = true; else rdbFemale.Checked = true; dtpRegTime.Value = (DateTime)reader14; cmbLevel.Text = reader15.ToString(); nudScore.Value = (int)reader16; reader1.Close(); 窗體下部是一個TabControl容器控件，它的4個TabPage頁分別用于實現會員的級別分析、消費分析、類型分析和圖書推薦功能。當用戶按下“會員級別”標簽頁中的“預測”按鈕后，程序首先根據相關輸入來構造DXM預測查詢字符串，而后調用貝葉斯模型CustomerLevels來預測會員級別:private void btnPredictLevels_Click(object sender, EventArgs e) if (cmbArea.Text = | cmbDegree.Text = ) MessageBox.Show(地區(qū)或學歷不能為空, 錯誤, MessageBoxButtons.OK, Mes