前言：一篇好文章的誕生，需要你不斷地搜集資料、整理思路，本站小編為你收集了豐富的數據分析設計主題范文，僅供參考，歡迎閱讀并收藏。

第1篇：數據分析設計范文

關鍵詞：類；DataLine；Translator；DataDrawer

航空設備數據分析一直是一個難題，因為數據按ICD協議上傳，需要轉化為可讀數據才能分析設備的運行狀態。但是設備的上傳速率一般在毫秒級，所以設備運行一個小時可以輸出上百兆的數據，人工分析這些數據費時費力且錯誤率高，容易錯過關鍵數據。

針對這種情況，作者設計了一種專門分析設備上傳數據的軟件（簡稱數據分析軟件）。使用數據分析軟件處理百萬行的數據只需要不到一分鐘的時間，而且該軟件可以將數據制成曲線，可以更容易地捕捉到關鍵數據。

1 數據分析軟件

數據分析軟件包含兩個模塊：數據轉換模塊和數據繪制模塊。

1.1 數據轉換模塊

1.1.1 時間類

航空設備上傳的數據一般以時間為基準，因此數據轉換時需要保留原始數據的時間信息，這樣才能將數據繪制成以時間為X軸的曲線。時間類的定義如圖1：

基類Time繼承了IComparable接口，所以Time類重載了 “！=”，” ”，”==”四個操作符，這樣Time類的對象之間可以比較大小，所以轉換后的數據可以按時間前后排序。

1.1.2 數據類

在數據分析軟件中，數據是以行為單位的，每一行數據有多個域，不同行數據的域名相同，域內的數據不同。數據行類定義如圖2。

DataLine的對象代表一行轉換后的數據，ToString接口可以將DataLine里存儲的數據以文本的形式輸出。DataLine是一個抽象類，需要用他的子類實例化對象。由圖可見，MLSData集成了DataLine類，在成員變量中加入了一個MLSTime的對象_time用以表示該行數據的上傳時間，并且可以用CompareTo接口比較兩個MLSData對象的時間先后。其實MLSData的CompareTo接口只是調用了成員變量_time的CompareTo，如圖3。

1.1.3 翻譯器類

翻譯器實現的功能是將一行原始數據轉換為可讀數據，翻譯器定義如圖4。

Translator是一個抽象類，其中定義了一個抽象函數Translate，這個函數有一個類型為String的形式參數data，并返回一個DataLine類（或其子類）的對象。其中data表示一行文本格式的原始數據，返回值DataLine表示轉換后的數據。當需要分析按新版本ICD協議上傳的數據時，只需創建一個新的Translator子類，并按ICD協議重寫Translate函數即可。

1.2 數據繪制模塊

數據繪制模塊類關系圖如圖5：

父類DataDrawer是一個抽象函數，他實現了繪制曲線的一些基本功能。子類MLSDrawer集成了DataDrawer的基本功能，并添加了數據段放大功能。MD_WarningLine添加了告警線的顯示功能，分析人員可以清晰地看到數據告警的位置，并針對該段數據進行分析。MultiLineDawer添加了多曲線繪制弄能，可以將多組數據的曲線繪制在同一坐標系內，讓分析人員可以進行多組數據間的交叉比對。

2 實際應用

如圖6，設備上傳數據經數據轉換模塊處理后輸出可讀數據。

數據繪制模塊讀取分析結果數據后，可以將結果中的一組或多組數據繪制成曲線。

在曲線繪制區域內拖動鼠標可已放大局部數據，如圖9。

3 結語

第2篇：數據分析設計范文

關鍵詞： 體育統計；SPSS；多因素；方差分析；正交試驗設計；數據分析

中圖分類號： G 8032文章編號：1009783X（2013）03028306文獻標志碼： A

在用三因素有交互作用的方差分析來研究運動強度、運動量和運動持續的時間對運動成績的影響時，對影響運動成績的3個因素各按3個水平進行試驗，見表1。如果進行全面搭配法方案安排試驗，此方案數據點分布的均勻性極好，因素和水平的搭配十分全面，唯一的缺點是試驗次數較多，為33×2=54次（指數3代表3個因素，底數3代表每因素有3個水平，×后面的2，表示重復一次試驗），如圖1所示。因素、水平數愈多，則試驗次數就愈多[1]。例如，作一個5因素3水平的不重復試驗，就需要35=243次試驗。試驗次數越多，就需要更多的人力、物力和財力作保證，而且需要占用更多的時間，這顯然是十分困難的。有時由于所需的時間太長，使試驗的條件發生改變，還會導致試驗失敗，即使試驗有了結果，但對運動訓練的實際指導意義也可能已經不太大了；因此，需要尋找一種合適的試驗設計方法。

對于如何去做試驗，怎樣才能做好試驗的問題是統計學很關注的一個問題。這就需要我們在做具體的試驗前，首先要做好試驗設計。

試驗設計的一個最重要的原則：在做試驗前，通過必要的事前考慮，作出合理周密的事先安排，從而在實際的試驗中，通過動用最少的人力、物力、財力及盡可能短的時間，以便用最少的試驗次數達到同做大量全面試驗等效的結果。

1.1.3因素和交互作用

選擇的正交表要能容納所考慮的因素和交互作用。為了對試驗結果進行方差分析或回歸分析，還必須至少留一個空白列，作為“誤差”列，在極差分析中要作為“其他因素”列處理。

1.1.4試驗精度

在同水平中取何種試驗次數的L表，取決于試驗精度的要求。如果試驗精度要求高，則宜取試驗次數多的L表。

1.1.5研究的成本

要根據研究的成本來決定適合的L表的選擇。若試驗費用很昂貴，或試驗的經費很有限，或人力和時間都比較緊張，則應選試驗次數少一些的L表。

1.1.6修正水平數

在按原來考慮的因素、水平和交互作用去選擇正交表時，如無正好適用的正交表可選，則簡便且可行的辦法是適當修改原定的水平數。

1.1.7適當選用大表

在對某些因素間的交互作用的影響是否確實存在沒有把握的情況下，如果條件許可，則應盡量選用大表，讓影響存在的可能性較大的因素和交互作用各占適當的列，在用方差分析進行顯著性檢驗時，就可得出結論。這樣既不增加太多試驗的工作量，又不致于漏掉重要的信息。

1.2正交試驗設計的基本步驟

1.2.1根據研究目的設計試驗因素和試驗指標

先根據研究課題來確定研究目的，再從專業的角度在眾多影響研究目的的因素中找出幾個主要影響因素，根據研究精度的要求和課題經費的情況確定因素的水平，一般在條件允許的前提下，主要影響因素的水平可以分得多一些，同時還將確定最能反映試驗目的的測試指標，以便通過對試驗結果的分析找出主、次影響因素。

3結論

1）正交試驗設計可有效地減少試驗次數，同時還可得到與做大量試驗等效的結論，可以節省大量的人力、物力，提高研究經費的使用效率。

2） 在SPSS17.0中，可以利用數據菜單中正交設計過程中的生成程序產生正交表，用顯示程序打印正交設計方案。由SPSS17.0產生的正交表同正交試驗設計書中的正交設計表不一定相同。在需要作極差分析的同時，還要考慮交互作用，應根據交互作用表作表頭設計。

3） 在不需要極差分析或極差分析中不需要考慮交互作用時，可直接采用SPSS17.0產生的正交表來安排試驗（但生成正交表時要考慮求交互作用時的試驗次數，即要根據因素數、水平數、交互作用安排在哪些列，來決定需要多大的正交表），也可直接用SPSS中多因素方差分析的方法來完成正交試驗設計的方差分析，同時可考慮交互作用。

4）在用SPSS17.0進行正交試驗設計分析可以代替手工計算。

由于篇幅有限，只討論了各因素等水平的情形，其他不等水平的混合設計，在SPSS中的實現方法是相同的。

參考文獻：

[1]劉達民，程巖.應用統計[M].北京：化學工業出版社，2004：153156.

[2]劉漢生，張寶玉.應用數理統計基礎[M].山西：山西科學教學出版社，1987：237266.

第3篇：數據分析設計范文

供電服務是供電企業的一項重要綜合管理指標。在供電服務管理實踐活動中，可以發現供電服務與營銷業務管控、電網運行、設備運維、供電能力、電建施工、員工素質、工作標準、管理者思維等諸多因素有關，如何將供電服務管理中存在著的諸多變化和離散因素，運用系統的科學的方法進行分析，尋求管理上的精細化和實現風險最小化，是各級供電企業所面臨的最迫切最現實的亟待解決的問題，最終實現客戶服務智能化、優質高效。

【關鍵詞】互聯網+ 大數據分析 供電服務 管控系統 設計與應用

目前，供電公司系統中存在著龐大的數據分析工作，利用數據分析結果進行有效的診斷分析，以更好地指導營銷服務，提升客戶服務功能，是供電公司必選的最佳途徑和手段，開發《基于互聯網+大數據分析模式創建供電服務管控系統》（ The design and application of electricity system managing which is basing on ten huge data analysis ），其核心依托設計是創建大數據分析模式的供電服務管控應用系統，融合拓展開發《開放式用電信息服務平臺的應用系統》{《開放式用電信息服務平臺》（The Opening Electricity Service Platform――簡稱：OEEP系統）}是基于互聯網模式、計算機通信技術、GIS地理信息系統、用電信息服務的開放式面向客戶端的信息平臺，通過開發利用計算機、手機智能式服務系統，在確保電網和營銷管理系統的安全前提下，鏈接供電生產系統、營銷服務系統與客戶端服務大數據系統信息共享，實現互聯網+多媒體的一體化開放式管控系統和公共服務平臺。

1 供電服務管控系統設計思路

1.1 供電服務管控應用系統設計

（1）建立與營銷系統完整鏈接的營銷服務主系統，基礎數據來源和依賴于營銷系統數據，分類建立不同功能模塊，設定客觀的量化指標，加入賽馬博弈競賽評分功能，客觀真實的反映出各層級供電單位供電服務業績，通過營銷服務在線管控系統實現綜合評價。

（2）搭建供電服務應用系統，實時實現首端與末端、縱向與橫向、分級管控的全方位管控和應用，開發手機客戶端APP下載到每個員工手機上，達到供電服務全天候、全過程的在線操作。

（3）主要實現功能：供電服務法規及政策、信息公開及、工單受理與流轉、服務指標體系、競賽積分系統、工作動態與經驗推介、綜合評價與獎懲。

（4）供電服務管控系統設計上，重點突出系統工程管理思維，力求規范化、標準化和可操作化，建立相應人性化管理的信息保障機制，對供電服務提升將會起到很好促進作用。

1.2 開放式用電信息服務平臺

（1）依托互聯網和計算機軟件技術，建立GIS地理和供電設備集成系統，實現模糊查詢實時鏈接。

（2）采用互聯網+模式，將95598客戶服務系統和營銷服務系統嵌入，經過數據研判分析，建立開放式的客戶端即時使用和交換界面。

（3）建設依托計算機通信系統拓展的電力多樣化、智能化的服務，通過多媒體系統、掌上APP、微信等客戶端系統，實時與金融、氣象、交通等其他資訊系統融合的通訊交換功效。

（4）借助電力系統的調度D5000系統、生產PMS系統、營銷MIS系統、用電信息采集系統等以及拓展的營配調貫通系統，實現全方位全天候的停電信息實時、設備故障查詢、客戶報修服務系統合一功能。

2 系統功能性設計界面

2.1 大數據系統性分析

（1）應用數理統計學原理和解析法開展供電服務大數據分析、篩選、研判操作，通過數據分析結論，以系統的管理理念、科學的管理方法揭示業務管控、運行過程、管理現象內在規律性問題，拓展供電服務領域措施和更大的提升空間。

（2）對供電服務管理的歸類統計和分析，可以達到過程清晰，由整體、局部到個性離散元素之間邏輯關系和關聯鏈接實現了閉環，便于發現問題，從而改進供電服務管理的統計方法和分析思路。

（3）在供電服務管理中，能把影響供電服務指標變化的因素，以及諸多因素影響的程度，進行量化和篩選出來，有效的解決了投訴事件分析的盲目性和無序性，增強了投訴事件分析和管理流程的針對性、目的性和規律性，提高了精細化管理水平和工作效率。

（4）把營銷服務活動過程中，具有規律性和關聯性的諸多離散因素及物理現象，以及過程化的實踐控制流程，建立數據分析的邏輯鏈接，進行分類歸納和運算分析，展現不同的管控對象所需要的應用界面、過程管控以及個性需求。

2.2 客戶信息服務平臺

（1）基于互聯網+模式與計算機網絡通信規約，將GIS地理系統為基本內核，實時進行導航鏈接，運用多媒體功能界面，在計算機終端和手機端加載運行。

（2）建立一個個不同數據結構的模型，設計若干程序模塊和接口，實現內置固化和跟蹤嵌入的方式，實時數據鏈接相關功能模塊，在不同的支撐界面進行靈活交互。

（3）鑒于信息安全管控要求，在確保電力網物理隔離和邏輯隔離滿足安全運行的情況下，在設計入口時設置唯一身份驗證和電子鑰匙，有條件的開放調度、生產和營銷系統數據接口，防止發生數據破壞和病毒侵害。

2.3 系統設計構架圖

如圖1、2、3所示。

3 系統功能及性價比

3.1 實現功能

（1）該系統實現跨專業海量的信息資源共享，系統公共管理和專業個性的管理，實現專業融合、互動和協同，可滿足各級供電公司和不同管理層級的人員管理需求。

（2）該系統可實現實時的在線研判、指揮和分析，實現各層級供電服務在線實時跟蹤管控，提升了工作時效性、針對性和真實性。

（3）開放式的用電信息服務突破傳統服務技術瓶頸，建立了客戶與供公司自由、方便、快捷的服務通道，對客戶訴求和業務辦理實現在時間和空間上的即時響應和一對一服務。

（4）該系統開發使用可實現供電公司各種系統資源的縱橫協同和拓展延伸，實現內部資源有效應用，最大限度的發揮各系統管理效益和經濟效益，資源高效利用提升了企業資產良性運行成效。

（5）該系統應用可提高工作效率，減輕和降低了人員繁重和重復的工作量，解放了一線人員勞動資源。

3.2 性價比分析

3.2.1 軟硬件投資

一次性投資該系統的開發費用較低，基本上是用于已有的各類系統的接口技術處理，實現諸多系統和平臺之間的鏈接，該系統軟件運維成本較低，除了已有的各類系統自身的運維費用外，該系統只需解決接口費用即可。

主系統需配置較高標準的新設備，各級工作站現按照統一標準配置計算機和交換機等設備，即可滿足使用。建議各級供電服務指揮中心建設不同規格的大屏幕監控工作室。

3.2.2 應用效益分析

（1）該系統開發后，實現了全省供電系統技術服務資源的整合高效利用，精細了管控過程和環節，評價客觀真實，公司的管理效益十分顯著。

第4篇：數據分析設計范文

很多設計師從來不看數據，要么是因為沒有數據可看，要么是根本不想看，但是也一樣把設計做的很好啊！設計本來就是有感性的一面，為什么非得要和數據扯上關系呢？

我們不妨先看看設計的本質是什么。設計不同于純粹的藝術，藝術源于藝術家對現實的觀察和思考，以及對這種觀察和思考的自我表達；設計天生就是為別人在做事情，縱然同樣需要觀察和思考，但是這種觀察和思考不是為了表現設計師的自我，而是為了更好地服務于某個用戶群，因而設計師了解用戶就變得非常重要。尤其是要了解用戶的目標、行為、態度等相關的情況，我們這里說的數據其實也就是對用戶的目標、行為、態度等情況的量化，因此，通過對這些數據的分析，我們可以更好地挖掘用戶的需求，進而為用戶提供更好地體驗。

簡單點說，設計是服務于用戶的，了解用戶才能更好地做設計，數據是了解用戶的一種途徑。

2、數據在項目中的作用有哪些？

要了解這個作用，我們先回到設計師看數據的主要場景，總結起來無外乎兩類：

一個是因為項目的需求，通過數據的論證，讓設計走得更從容，有理有據，而不是設計師自己的YY；

另外一個是日常監測的需求，自己做的產品，總要知道大概有多少人在用，使用的情況如何，用戶的行為和預期是否一致。也就是說要了解你的設計被使用的情況，否則你怎么知道設計的好不好，是不是達到了設計目標，是不是真的幫助用戶解決了問題。

先來分析下項目中看數據的場景。幾乎整個設計的過程都可能會用到數據，概括起來可以把這個過程切分成三部分：

第一部分：設計前數據幫你發現問題

所有設計開始之前的研究和分析，都是為了更明確用戶的需求，明確為什么要做這個設計？從業務的角度來看，這個產品對公司有何價值，此次設計要達到什么目的；從用戶的角度來看，這個產品對用戶有何價值，此次設計要為用戶解決什么問題；在了解業務訴求和用戶訴求的過程中，我們難免要用到數據，這個階段，數據的作用就是為了“發現問題”，看看設計可以解決什么問題，從而更佳明確設計的目標。

當然具體的工作中，多數設計師都比較糾結，既要考慮業務訴求，又要考慮用戶訴求，如果這兩者不能完全匹配的時候，我們該咋辦，是兩者的相加嗎？還是我們就只考慮用戶訴求，對業務訴求看看就行了。我個人的理解是，現實工作中我們都不是在追求最完美的設計，更多的是在做平衡，如果是一個用戶型的產品，比如偏向于為用戶提供某個功能的平臺，本身就是完全從用戶的角度出發，通過為用戶提供功能幫助用戶解決問題的，應該向用戶訴求靠攏多一些；如果是一個商業型的產品，比如偏向于為用戶提供某些內容的平臺，那么在為用戶提供主動查找的入口的同時，可以適度的向著業務發展需求傾斜，做適度的業務層面的引導；當然這個也不是絕對的，往往同一個平臺，同一個產品，在不同的發展階段也有不同的需求，如果是一個全新的產品，業務的生存就變得格外重要，這個時候設計應該多一些考慮業務訴求，先幫助業務生存，否則，這個產品都要掛了，還怎么為用戶提供服務呢？

當然，好的設計師總是能在業務和用戶之間找到巧妙的平衡，找到二者的交集，舉個例子，假如這個產品這個階段就是要做用戶規模，而用戶訴求是享受個性化的服務，看似完全不關的兩個訴求，實際上我們完全可以通過更好的個性化服務提升用戶滿意度，獲得好的用戶口碑，再間接地借助用戶口碑提升產品的用戶規模，這二者之間并不是完全的不相干，更多的時候看能否找到他們的關聯性，抓住階段性的設計目標。

通過一個具體的例子看看如何利用數據來發現問題？數據代表的是用戶的目標、行為和態度，但是單獨看一個數字是沒辦法發現問題的，數據的對比是最簡單有效地手段。我們知道交易關系買家所產生的交易對1688網站有著非常重要的意義，我們想提升交易關系型買家的交易體驗，但是不知道從何入手，因此做了大量的數據分析。交易關系買家是通過什么方式找到老賣家?不同路徑的轉化率如何?不同用戶查找方式與轉化率有什么差異?

首先，通過用戶群的細分，我們發現，交易關系買家通過搜索支付訂單轉化率是搜索整體支付訂單轉化率的2倍。因此，在搜索結果中增加老買家標簽，方便找到老賣家。

此外，我們還發現，普通會員、1-2星會員等級，是提升交易關系交易的關鍵用戶。通過以上的數據分析，我們找到了目前主要的一些問題，圍繞著這些問題，后續做了優化方案。

第二部分：設計中數據幫你判斷思路

因為設計師的個人經驗不同，創造性思維不同，因此不同的設計師面對同一個問題，解決方案也很可能差別較大，即便是同一個設計師也會想到不同的解決方案，到底哪個方案更合適，有些情況下數據可以給你參考意見，為你提供“判斷思路”，協助你做決策；條條大路通羅馬，但是哪一條路才是當前最合適的呢？

通過一個具體的例子看看如何利用數據來判斷思路？有一個批發類的電商網站(1688.com)的頻道首頁(ye.1688.com)，我們發現用戶的轉化率很低，就去研究了數據，然后結合了對典型用戶做的用戶訪談的結論，最后發現轉化率底的原因其實很簡單，這個頻道的首頁入口主要是來源于整個網站的首頁，而整個網站的首頁是一個全行業品類的頁面，用戶如果是女裝行業的買家，她從一個全品類的首頁點擊一個鏈接進入另一個全品類的頁面，再艱難的找到女裝這個類目，再點擊進入List頁面查看商品，這個路徑是非常深的，那么怎么解決這個問題呢？那就是要避免做女裝的用戶從網站首頁進入這個頻道之后還要再次選擇女裝類目，才能看到女裝的商品！

解決這個問題的思路有哪些？可以在網站首頁增加入口，讓用戶直接點擊女裝類目進入頻道首頁，給用戶展示女裝商品；可以在用戶進入頻道首頁之后，根據行業偏好的個性化數據來推薦商品，推薦的不準確，用戶也可以去定制；到底哪個更靠譜？兩個思路各有利弊，鑒于前一個思路需要有外部依賴，要改動網站首頁，所以我們內心都很期望后一個思路能跑通，但是怎么知道這個思路行不行？首先我們需要知道行業的個性化推薦能覆蓋多大的人群，又有多少的人愿意去定制行業偏好？

對于普通的網站來說這個可能是一個不夠明確的問題，但是1688.com是一個會員用戶早就過億的B類電商網站，有著如此龐大的用戶規模，較高的用戶覆蓋率，這就意味著對用戶行為數據的積累，再者B類的用戶有一個顯著地特征就是在一個較長的時間里，行業的偏好相對比較穩定，如果是一個主營女裝的買家，那么她的偏好一般會以女裝為主，不會超出服裝的范圍，最多會有少量的服裝周邊配套的采購。

如上圖，通過行業偏好的個性化算法，我們追蹤了一段時間來訪這個頻道首頁(ye.1688.com)的用戶數據，我們發現大約2/3的用戶是有著非常明確的行業偏好的，那么這基本可以斷定做行業偏好的個性化推薦是靠譜的！但是剩下的1/3用戶愿意去定制行業偏好嗎？我們當時因為時間原因，無法直接從這1/3無明確偏好的用戶中去判斷他們是否愿意定制偏好，但是通過整個用戶群的問卷抽樣調查發現，大約3成的用戶表示定制行業偏好是很好的服務，基于這些情況，我們判定基于行業偏好的個性化推薦能夠解決絕大部分用戶的行業偏好問題，提升了內容的相關性。這個方案最終上線后，實際上有大約10%的人真正找到定制入口并且產生了定制行為，70%的人不用定制，實現了默認的精準推薦。

第三部分：設計后數據幫你驗證方案

我們的設計方案到底做的好不好呢？衡量標準就是看設計方案是否能夠達成設計目標？這也需要數據來量化，通常會用GSM的模型來支撐設計的驗證。G(Goal)設計目標、S(Signal)現象信號、M(Metric)衡量指標，所謂的設計目標，就是要確定設計要達成什么結果，要解決什么問題；衡量指標，我們不能憑空猜想，必須建立在設計目標的基礎上，先假設設計目標會實現，那么會出現什么現象或信號呢？列舉出所有的現象或信號，選擇我們可以監控的到的，然后對這個現象或信號產品進行量化，自然就得到了衡量指標，但是指標的波動幅度往往要依賴經驗來定。

比如說，某個產品的設計目標是通過設計的引導，讓更多的買家產生購買，想象一下，如果設計目標實現了，會有什么現象呢？可能會有更多的人有購買意愿，看了商品詳情頁，點擊了購買按鈕等等，最終也產生了購買，那么，衡量指標是哪個？設計只是改變了商品信息的呈現方式，并不能改變商品本身的質量或背后的服務，所以我們應該重點考察設計是否強化了引導，提升了購買意愿，是否激發了用戶進一步了解的行為，主要是指瀏覽行為，最典型的就是到達了商品列表頁或者商品詳情頁等，量化的結果就是看又進一步行為的用戶的比例；

通過一個具體的例子看看如何利用數據來驗證你的設計方案是否達成設計目標。曾經有一個找產地的功能模塊，我們在設計前進行了調研，用戶告訴我們他們需要找產地，而且比較習慣于用地圖來找產地，我們欣喜若狂，照著這個方向做了個產地直達的樓層，我們堅信用戶告訴我們的肯定是對的！但是這樣的設計真的能達到幫助用戶高效找產地的需求嗎？來看下面的數據分析。

用戶的目標不是要找產地嗎？還告訴我們用地圖找產地很符合他們的習慣呢？為什么上線后，用戶卻不怎么使用這個版塊？？？我看到這個數據非常的意外，一時之間根本摸不著頭腦，后來再去看了看這個板塊的熱力圖，一下子恍然大悟。通過數據分析得出，地圖縱然符合用戶習慣，但是才這么狹小的地圖上進行如此復雜的操作，其效率是非常底下的，因此將地圖找產地的功能保留下來，只是不作為默認的方式，采用了按照熱門的、區域的、附近的、可搜索的、地圖的方式綜合承載，最后取得了較好的效果！

3、如何利用數據做日常監控？

作為一個設計師，你的作品上線后，有多少人用？這些用戶是誰？有什么特征？用戶具體是怎么在使用你的產品的？你的設計是否還有優化的空間？如何才能為用戶打造更好的使用體驗？怎么才能知道這些數據好不好，有沒有問題呢？主要是靠比較、靠經驗，靠對這個產品長期跟進產生的直覺，只有在對這個產品非常熟悉的前提下，你才有可能對數據的變化給予比較靠譜的解讀。

日常監控中用于發現問題的主要手段就是做數據的對比，但是如何具體的作對比呢？主要有三種最常用的最簡單的對比方式：a、橫向比較，和類似的產品去比較，看相對的狀況，進而推測出自身是否存在問題；b、縱向比較，和自己的過去比較，看看從歷史的發展規律中是否能得到某些啟發，主要是看自身的變化趨勢；c、用戶細分，這個就是把用戶按照不同的分析需要，拆分來之后來看數據，看看各個群體之間的差異在哪里，有沒有一部分用戶和其他用戶表現出不同的行為，進而找到問題所在。當然除了這三種常用的對比之外，我們還可以做一些配套的定性研究，進而把問題搞得更透徹。一些統計學的工具有時候也能起到作用，比如說用SPSS做數據的因子分析、聚類分析等等，也可以有一些意想不到的收獲。

第5篇：數據分析設計范文

關鍵詞:系統設計;信息分析;Oracle數據庫;數據結構;GIS

中圖分類號:TP311.13文獻標識碼:A 文章編號:1009-3044(2010)08-1800-04

The System Design of Information Analysis Database for Changqing Oilfield

LI Juan, GUO Kang-liang, HE Zhen-ming, TANG Jun, YAN Ke-wei

(Department of Geosciences, Yangtze University, Jingzhou 434023, China)

Abstract: Changqing Oilfield information analysis database system using ORACLE database, GIS (geographic information system) technology on the original field information storage, graphical management, and through mathematical analysis to accomplish the production information analysis, obtained laws to assist in the future the work of decision making. Development through information analysis system will make that field information management more scientific and convenient.

Key words: system design; information analysis; Oracle databases; data structures; GIS

隨著當今計算機數據庫和數據倉庫,GIS等技術的發展,利用大量的、全面的生產歷史數據,將其存儲在數據(倉)庫中,進行新數據的錄入、歷史數據的分類提取。然后借助相關數學方法對生產信息進行科學的數據分析,進而總結規律。GIS圖形化管理工具的運用也能幫助直觀、便捷的處理各類信息。這些先進的技術必將給油田的發展帶來二次的飛越。油田信息化將大大提升油田生產、管理水平,為油田生產發揮巨大的效益,成為公認的增強企業競爭力的有效途徑。

1 系統需求分析

1.1 數據管理需求

油田信息化建設是改變傳統的油田生產經營模式,以一種全新的數字化作業方式代替傳統的手工或半手工的工作方式。油田的管理首先要對油田的各類海量信息數據進行管理。數據是油田的資產和寶貴的財富,但由于以前是人工管理,現在存在了資料的保存介質多樣、數據格式多樣、數據冗余、數據管理繁瑣、數據應用不便、不能共享等各種問題。系統將以數據庫技術,地理空間信息為基礎,直觀合理、科學便捷的實現油田地質研究、數據管理、自動化監控、經營管理、部門管理等。

1.2 生產需求

長慶油田屬于低滲透砂巖氣藏,這類氣藏具有孔隙度低、滲透率低,含水飽和度高,氣水關系負雜、非均質性強、氣體流動啟動壓力高、單井產量低等特點,壓裂是這類低滲透砂巖氣藏開發的主要手段。只有搞好氣井的壓裂,使其發揮最大的經濟效益,才能真正提高油氣田的產量。因此做好壓裂前各項技術的準備,如選井選層及綜合地質研究,為優化施工設計提供地質依據。壓裂以后做好壓裂效果評價,正確科學的對壓裂效果的各項數據進行分析,從而選擇最佳的壓裂施工方案[1]。系統可以將油井的復雜性整體客觀地展示給管理者,用戶可以把復雜的壓裂數據和地質情況轉換成直觀的分析曲線,可簡單便捷的確定分析油藏,直接設計井位和壓裂開發方案,可以實現桌面化的油田研究、管理、指揮和決策,能夠獲得不同思路的建模和模擬結果,從而達到降低風險,優化決策的效果[2]。

2 系統體系結構

計算機應用結構分為:Client/ Server(客戶機/服務器)結構、Browser/Server(瀏覽器/服務器)結構。

2.1 Client/Server模式

C/S模式是基于網絡技術發展起來的一種新型體系結構的信息處理模式,具有較強的信息共享能力。這種結構的配置較為靈活,每個用戶具有較強的獨立性。但需要在每一個Client端安裝特定的應用程序,限制了Client端的靈活性,而且存在Client端跨多平臺時不靈活的問題,因此這種結構具有一定的局限性。C/S網絡運行模式操作復雜,對系統維護人員要求高。這樣對于一般的部門往往會出現因為管理人員的維護不當而使系統出錯甚至使系統崩潰。另外C/S方式對網絡要求比較高,一般適用于局域網內部使用。

2.2 Browser/Server模式

B/S結構擴展了客戶機/服務器的概念,使開發者只需將注意力集中到Web服務器端后臺應用的開發,省去了客戶端前臺交互界面軟件的開發,上網用戶使用通用的多媒體瀏覽器(如IE)就可進行信息訪問和交流,數據操作和程序運行都在服務器中完成,實現客戶端的零安裝和零維護。這不僅可節省開發費用和加快開發進度,更重要的是實現了跨越多平臺的開發。由于數據訪問是實時的,當多用戶并發訪問、傳輸數據量較大時,易造成網絡堵塞,降低訪問速度。

鑒于B/S方式和C/S方式各具優缺點,系統采用以B/S為主,C/S為輔的網絡結構模式進行系統結構管理(見圖1),為各部門業務的開展提供可行的解決方案。對于信息室,由于要負責數據更新和系統的維護等工作,涉及大量數據的處理,提供C/S模式,以充分利用其具有良好的人/機交互能力,對圖形數據具有很強的處理和編輯能力,對于空間數據的存取效率高的特點,方便用戶開展管理工作[3]。對于各處室業務人員日常辦公,由于辦公地點分布地域廣、工作人員的素質差異較大,為其提供B/S模式,通過局域網訪問信息中心。所有日常辦公操作可通過瀏覽器完成,可大大降低對基層人員的計算機技術要求。

3 系統功能設計

數據庫系統在功能結構上由服務器、管理平臺和客戶端三部分組成,管理平臺和客戶端通過TCP/IP協議與服務器相連。服務器主要用于數據庫的存儲、數據庫信息調用的服務。并選用國際通用的、能提供對大塊數據體支持的Oracle數據庫產品,能夠很好地滿足分布式網絡數據庫要求。管理平臺與客戶端是兩個相對獨立的部分,都通過內部網絡與服務器相連,通過軟件平臺調用服務器上數據庫的信息。功能模塊的設計上,按照功能的不同主要分成了三個部分:基礎資料的管理部分,圖件數字化部分,分析決策部分;其中各個部分又依照具體功能分成了不同的子系統來實現具體功能。子系統包括數據庫管理與顯示子系統、基礎數據統計查詢子系統、數理統計方法庫管理子系統、壓裂措施選取輔助決策子系統、數據接口子系統、生產分析結果管理子系統、圖件數字化子系統、專題地質圖件繪制子系統等等。

3.1 基礎資料管理部分

主要包括用戶管理、日志管理、系統維護、基礎應用管理、數據顯示等功能模塊來負責對以往的油田各項信息資料數據進行存取、錄入、更新以及維護。這部分主要是借助ORACLE數據庫各種功能的來管理和實現,類似一般的數據庫管理。

3.2 圖件數字化部分

主要是采用C/S結構,基于地理信息系統(GIS)組件二次開發,圖件數字化子系統實現了地圖顯示與瀏覽、圖像導入、圖像校正、空間參照系的設置、圖形輸入與編輯、常用數據接口、圖件排版與輸出等功能。并且聯同ORACLE查詢功能來實現圖形與屬性互操作的管理、查詢、修改功能。

3.3 分析決策部分

這部分是整個系統的關鍵,建立服務于壓裂效果評價與措施選擇的方法庫,為基礎資料的綜合分析和挖掘提供技術支撐。借助了相關的數學分析方法能夠對各類生產數據進行多元回歸分析(線性、非線性)、主成份分析、因子分析等方法綜合研究。其中運用了神經網絡、數據挖掘等技術對于分析油層參數、措施參數與措施效果之間的協同復雜關系,為措施效果評價、措施參數優化提供技術支撐。

由于壓裂效果與其影響參數之間大多呈復雜的非線性關系,這種關系難以用傳統的數學表達式來描繪;又由于各因素對壓裂效果的影響程度不同,而且某些因素之間存在交叉影響現象。因而可以用人工神經網絡方法來解決這類高度復雜的非線性問題。在處理參數間的復雜非線性關系時,利用網絡上各神經元的參數(即復雜的網絡結構)來表達知識,而不是用傳統數學中的簡單表達式;通過調節網絡中各節點與節點之間的連接系數(即參數的權值大小)來解決參數存在的重復和主次現象[4]。

4 數據庫結構設計

4.1 數據庫需求分析

數據庫是本系統的基礎,將實現系統中各種空間、屬性數據的統一管理與維護,支持系統中各項業務的正常運行。總體上,本系統數據庫中的數據應包括基礎數據、業務數據、分析成果數據三大部分。基礎數據由地理空間數據、系統管理數據、組織機構數據、工程基礎數據組成;業務數據主要由長慶石油勘探局井下技術作業處生產信息系統中的壓裂、試井、分析生產數據構成,另外還包括收集整理測井成果數據。分析成果數據是該系統的核心數據,通過運用本系統提供的分析方法與工具對現有油層數據、測井數據、試井數據等評價分析獲得,是系統進行壓裂效果評價和壓裂方案設計的數據基礎。

4.2 數據庫系統設計

系統選用結構化系統開發方法。這種方法的突出優點就是它強調系統開發過程的整體性和全局性,強調在整體優化的前提下來考慮具體的分析設計問題,即自頂向下的觀點,是一種目前廣泛被采用的系統開發方法[5]。數據庫是本系統的基礎,將實現系統中各種空間、屬性數據的統一管理與維護,支持系統中各項業務的正常運行。

從數據的形式來說,本系統數據庫中既包含傳統一維表格數據又包括新采集的二維圖形數據。為了便于二者的管理和維護,需要設計統一的數據模型將二者有機的組織在一起統一管理、統一維護[4]。利用國產GIS軟件MapGIS空間數據引擎SDE提供的強大功能,可實現圖形和屬性數據在商業數據庫軟件ORACLE中的統一存儲和管理,同時也保證了本系統數據庫與井下處生產信息系統數據庫的兼容性。從數據的來源與用途來看,本系統數據可分為基礎數據、業務數據、分析成果數據三大部分,因此,邏輯上劃分為基礎數據庫、業務數據庫、分析成果數據庫三個子庫。

1)基礎數據

基礎數據包括維護系統和系統業務運行的各項基礎數據,包括工程基礎數據、地理空間數據、組織機構基礎數據、系統管理數據等。

2)業務數據

業務數據是井下處生產過程中所涉及的生產設計、生產記錄和生產成果數據,主要包括壓酸擠數據、測試試井數據、生產分析結果數據、測井綜合數據等。

3)分析成果數據

分析成果數據是本系統中用于支持壓裂效果評價與方案優選的數據基礎,包括評價分析樣本數據、評價分析因素相關系數數據、評價分析方法數據、評價分析成果數據。

4.3 數據表結構設計

每一口井的信息種類不盡相同,同時,每一口井的單個信息可能有多次測量。并且測井信息在不斷的更新中。這就要求數據庫有良好的可擴充性,在統一了測井信息數據格式的基礎上,在ORACLE數據庫系統的支持下,采用嵌套表的方法可較好地解決這一問題[6]。另一方面由于數據庫中井的數量龐大。這就要求測井信息數據庫有良好的結,達到盡量提高效率的原則。基于此,設計了如圖3所示的數據庫表結構形式[7]。

4.4 數據信息關系設計

系統采用當前應用最為廣泛的基于關系表的存儲方式,并采用星型存儲模式,這種模式可為數據倉庫提供優越的數據檢索和分析功能。在創建數據倉庫的過程中,選定的主題為壓裂效果無阻流量,在數據倉庫中存在維表和事實表,兩種表間利用維的ID連接[8]。

5 系統的關鍵技術路線

5.1 面向對象的系統分析和設計(OOA&D)方法

系統分析與設計將采用面向對象的系統分析與設計(OOA&D)方法,確保系統設計與開發符合軟件工程的規范,開發出規范化的、具有較高可移植性、可靠性的軟件,提高系統開發的效率。

5.2 采用關系數據庫管理空間數據和屬性數據

當前地理信息系統(GIS)技術發展的最新趨勢是采用關系數據庫或對象關系數據庫管理空間數據和屬性數據,可以充分利用關系數據庫管理系統(RDBMS)的數據管理功能,利用結構化查詢語言(SQL)對空間與非空間數據進行操作,同時可以利用關系數據庫的海量數據管理、事務處理(Transaction)、記錄鎖定、并發控制、數據倉庫等功能,使空間數據與非空間數據一體化集成。系統將采用關系數據庫管理空間數據和屬性數據,確保空間和非空間數據的一體化集成。

5.3 全組件式GIS技術應用

GIS融入IT除了將空間數據交到關系數據庫中進行管理以外,開發客戶端時,還要考慮使用全組件式的GIS。全組件式GIS軟件將GIS的功能從數據輸入、編輯、處理(建立拓撲關系)、查詢顯示、分析和制圖輸出全部封裝成組件,可以根據用戶需要,自由定制操作方式和界面。用戶可以將GIS組件和其他組件放在一起,采用通用的開發平臺,如Visual Basic、Delphi、Power Builder、C#等,而不再受GIS二次開發語言限制。從而極大地方便了二次開發,同時增強了二次開發的擴展能力,使得后續應用系統的開發與基礎數據的銜接變得方便簡單[7]。

5.4 數據挖掘技術的應用

數據挖掘能自動在大型數據庫里面找尋潛在的預測信息。傳統上需要很多專家來進行分析的問題,現在可以快速而直接地從數據中間找到答案。數據挖掘工具可以根據過去大量的數據找出其中最有可能對將來的發展最有價值的信息,并辨認出那些隱藏著的模式。數據挖掘技術可以讓現有的軟件和硬件更加自動化,并且可以在升級的或者新開發的平臺上執行[9]。

5.5 神經網絡技術的應用

人工神經網絡就是模擬人思維的直觀性思維:1)信息是通過神經元上的興奮模式分布儲在網絡上;2)信息處理是通過神經元之間同時相互作用的動態過程來完成的。這是一個非線性動力學系統,其特色在于信息的分布式存儲和并行協同處理。雖然單個神經元的結構極其簡單,功能有限,但大量神經元構成的網絡系統所能實現的行為卻是極其豐富多彩的。神經網絡方法能很好地解決多因素的非線性問題[8]。

6 結束語

在系統的開發過程中要具體的考慮到數據庫表的各項數據內容的結構,設置方便開放的數據接口,方便系統的二次開發與維護。各類數據平臺和軟硬件要更加通用和開放。

參考文獻:

[1] 肖昆.低滲透氣藏壓裂效果評價方法研究[D].成都:西南石油學院,2003.

[2] 劉擁軍,楊永發,朱春紅.長慶油田測井信息數據庫的系統設計[J].測井技術,2005,26(3).

[3] 張曉林,侯寶穩,吳寶江.數據庫系統管理與應用[M].北京:清華大學出版社,2007.

[4] 吳亞紅,李秀生.人工神經網在壓裂選井及選層中的應用[J].石油大學學報,2001(25).

[5] 王曉蓮,顧娟,王穎,等.大慶油田測井數據庫系統設計[J].油氣田地面工程,2007,26(2).

[6] 袁鵬飛.ORACLE8i數據庫高級應用開發技術[M].北京:人民郵電出版社,2000.

[7] 張帆.基于.Net 平臺WebGIS系統的研究與實現[D].長沙:中南大學,2008.

第6篇：數據分析設計范文

關鍵詞：Hadoop 市政設施監控 大數據

中圖分類號：TP31 文獻標識碼：A 文章編號：1674-098X（2016）10（b）-0076-02

Hadoop作為一種有效的大數據技術，在數據處理和網絡系統中得到了有效的應用，對提高大數據分析處理效果具有重要作用。根據Hadoop技術的概念及內容實際，掌握Hadoop的體系架構特點，對于構建大數據處理系統是十分重要的。結合市政設施監控系統的數據處理需求，應用Hadoop構建市政設施監控系統，對于提高市政設施監控系統的運行效果和滿足市政設施監控系統的數據處理需要具有重要意義。為此，應開展Hadoop大數據系統的研究。

1 Hadoop的概念及內容

Hadoop是一個用java語言實現的軟件框架，在由大量計算機組成的集群中運行海量數據的分布式計算，它可以讓應用程序支持上千個節點和PB級別的數據。Hadoop是項目的總稱，主要是由分布式存儲（HDFS）、分布式計算（MapReduce）等組成。

Hadoop作為一種有效的大數據處理技術，其主要優點分為4個方面。

1.1 可擴展

Hadoop技術在實際應用過程中，可以根據所構建系統的需求進行必要的擴展。具體功能可以在原有大數據處理的基礎上進行增減，以滿足所構建系統的實際需求為準。這一功能是Hadoop的主要優勢，擴大了Hadoop技術的應用范圍。

1.2 經濟

Hadoop技術在應用過程中，整體應用成本較低。由于Hadoop具備了較好的可擴展性，在系統的構建中可以作為基礎技術進行應用，在Hadoop基礎上有效接入其他系統，避免了系統重建導致的資源浪費，有效地提高了系統的構建效果。

1.3 可靠

Hadoop技術在多年的應用過程中，被證明是一種可靠的大數據處理技術。這種技術不但可以有效地提高數據的處理速度，同時還能與其他系統進行無縫對接，提高信息數據的處理能力，滿足系統運算和數據處理需要。因此，較高的可靠性保證了Hadoop能夠得到有效應用。

1.4 高效

Hadoop技術的突出優點是數據處理速度較快。其不但可以在較短的時間內加快數據處理速度，同時也會根據系統的現實需求制定個性化的數據處理模式，提高系統的響應速度，保證數據處理速度能夠達到預期目標，提高數據處理的整體效果。

2 Hadoop的體系架構

從Hadoop技術的應用來看，通常Hadoop的體系架構比較特殊，除了要設定功能模塊之外，還要使模塊具備一定的接入特性。

具體的功能模塊特點如下。

Pig是一個基于Hadoop的大規模數據分析平臺，Pig為復雜的海量數據并行計算提供了一個簡易的操作和編程接口。

Chukwa是基于Hadoop的集群監控系統。

Hive是基于Hadoop的一個工具，提供完整的sql查詢功能，可以將sql語句轉換為MapRedce任務進行運行。

ZooKeeper是高效的、可擴展的協調系統，存儲和協調關鍵共享狀態。

HBase是一個分布式文件系統，有著高容錯性的特點。

MapRedce是一種編程模型，用于大規模數據集的并行運算。

基于對Hadoop的了解，Hadoop在體系架構中用到了多種輔助工具和子系統，在整體體系結構上并不復雜，實現難度較低，具備了與其他系統有效集成的優點。在功能系統構建過程中，基本能夠滿足實際需求，對降低系統構建難度具有重要作用。

同時，Hadoop在體系架構中采取了分層架構的方式，這種模式不但具有一定的突出性，同時還能夠解決功能系統構建過程中存在的系統接入問題。對降低功能系統的接入難度和提高功能系統的接入效果具有重要作用。因此，利用Hadoop構建大數據分析系統是重要措施。

除此之外，Hadoop具備了與其他系統對接的優勢，可以在系統構建過程中，根據系統的實際特點和功能需要，構建相對應的大數據處理系統，提高系統的數據處理能力，保證系統在數據處理過程中，能夠在整體有效性上得到全面提升。

3 基于Hadoop的市政設施監控系統的構建

基于Hadoop的特點以及市政設施監控系統的構建需要，利用Hadoop構建市政設施監控系統，應當做好系統的總體設計和功能設定。

在市政設施監控系統構建過程中，基于Hadoop的特點和優勢，應當采取典型的系統架構模式進行系統構建，并根據Hadoop的系統架構需要對系統結構M行調整，使市政設施監控系統在科學性和合理性上滿足實際需要，提高系統的構建質量。

考慮到市政設施監控系統的數據處理量較大的特點，在應用Hadoop技術之后，應當根據Hadoop的算法對市政設施監控系統的數據進行有效處理，保證市政設施監控系統在數據處理速度上能夠達到預期目標，提高數據處理質量。

在此基礎上，應發揮Hadoop大數據處理技術的優勢，根據市政設施監控的實際特點，設置數據處理功能目標，指導Hadoop大數據處理技術的應用，保證Hadoop大數據處理技術在應用過程中能夠提高數據處理效果。因此，在具體的系統構建中，應突出數據處理速度目標。

在市政設施監控系統中，該系統利用先進的視頻監控、智能識別和信息技術手段，增加可管理空間、時間和范圍，不斷提升管理廣度、深度和精細度。整個系統由信息綜合應用平臺、信號控制系統、視頻監控系統、智能卡口系統、電子警察系統、信息采集系統、信息系統等組成。

最后，在系統構建完成之后，應對Hadoop大數據技術構建的監控系統與其他監控系統相對比，重點比對數據處理速度和數據處理量，總結Hadoop技術的優勢，為市政監控系統的構建提供良好的系統支持和技術支持。

4 結語

通過該文的分析可知，在市政設施監控系統構建過程中，有效地應用Hadoop技術，不但可以構建完善的大數據處理中心，同時還能解決市政設施監控系統中存在的數據處理速度慢和數據處理量大的問題。因此，應對Hadoop技術有正確的認識，做到正確分析Hadoop的優勢和特點，并在市政設施監控系統的構建中有效應用Hadoop技術，提高市政設施監控系統的構建效果，滿足市政設施監控系統的構建需要。

參考文獻

[1] 廉捷，周欣，曹偉，等.新浪微博數據挖掘方案[J].清華大學學報：自然科學版，2011（10）：1300-1305.

[2] 何忠育.分布式社會網絡分析支撐系統研究與應用[D].廣東工業大學，2011.

第7篇：數據分析設計范文

【關鍵詞】 區域 健康數據 檢測 報警

一、引言

近年來，隨著信息技術的高速發展，信息化醫療服務的模式成為研究熱點，人們利用網絡資源獲得醫療服務及醫療資訊，不用去醫院與醫生面對面會診也可以達到看病就診的目的，極大地提高了醫療衛生資源的利用率。目前，已有部分國家將D信息化醫療服務投入使用中，并獲得了良好的效果，全世界使用信息化醫療服務的人也越來越多[1-2]。隨著互聯網的普及，尤其是無線網絡和 4G 技術的發展，以及各種計算機軟、硬件技術的日趨完善，信息化醫療服務將得到廣泛的應用，成為 21 世紀最有前景的產業之一。

二、需求與可行性分析

我國老齡化現象愈發嚴重。老年人由于機體功能下降，容易引發各種慢性或突發性疾病。針對我國國情，有限的衛生資源仍然集中在疾病的治療上。對于老人而言，存在著行動難、無陪護、看病難等諸多客觀問題，任何的醫療養老機構、人員無法長時間做到24小時對所有的老人進行實時監護并給出相應的健康指導意見。為了解決上述問題，面向老人的健康監護系統的研究目標為：被監測者在社區的無線網絡覆蓋范圍之中，可實時監測老人健康數據并將數據傳輸到控制中心。

檢測數據正常則存儲備案，以備日后作統計分析、預防；當老人突發狀況，系統采集數據異常，區域控制中心顯示數據、發生地理位置并警報響起，提示醫護人員在第一時間做出反應，避免錯過最佳處理、救治時機；同時控制中心系統自動向突發狀況老人的第一聯系人手機推送消息，報告相關情況。系統的研發力促達到24小時不間斷的數據采集和檢測系統，形成個人―家庭―社區的初級醫療服務供給體系，真正做到以預防為主、防治結合。

研發過程中所使用的單片機，傳感器等設備材料價格低廉耗、費資金較少、仿照中國科學院實施“海云工程”，并推出低成本的健康服務[3]，保證產品市場化利潤空間。實施過程中，擬解決軟件與硬件問題，所采用的java+sevlet開發技術、嵌入式開發技術以及移動app開發技術均為成熟技術，在技術上，不存在瓶頸。調研充分前提下研究方案完全可行。

三、系統的分析與設計

3.1系統模塊結構

根據需求，進行分析設計，劃分模塊如圖1所示[4]。

3.2系統網絡結構設計

根據系統需求、技術可行性以及現實情況，設計網絡拓撲結構如圖2所示。

3.3主要功能

（1）終端檢測模塊。由醫學領域專家制定生命體征數據標準，開發監測心率、血氧、體溫等模塊。對設備佩戴者進行實時監測并將檢測數據通過網絡傳送到數據分析處理中心。

（2）數據分析處理模塊。接收終端數據進行分析處理；如果數據一切再醫學領域專家設定的標準范圍之內則正常存儲以備分析預防，如果處在異常狀態下則根據設定數據匹配危險系數給出信號。

（3）數據推送模塊的功能為當數據分析處理模塊信號為高危時啟動數據推送功能，將高危人當前生理狀態通過消息或短信的方式傳送給其第一負責人。

（4）報警模塊的功能為當數據分析處理模塊信號為非正常狀態時給予響鈴等報警提示。醫護人員根據報警的具體類型采取相信行動、避免錯過最佳的援助、救治的時間。

3.4系統目標

首先使得老人在固定區域內可自由活動不影響實時監測生命體征數據、理想誤差；其次，當數據發生異常報警時，上位機軟件顯示出當前一個時間段各項生命體征各項數據，并指出報警地點，醫護人員可以根據現實異常數據大致判斷原因并第一時間趕往現場實施處理、救治，從根本上解決老人“無人管”或“管得晚”的問題，系統達到國內先進水平。

四、總結

國內外面向社區老人的健康監護研究，局限在有線設備并將被監測者束縛在很小局部范圍內，限制了實時性和使用便捷性，基于Zigbee無線傳感器網絡的健康監護系統的研究具有研究方向和內容的創新性。

參 考 文 獻

[1]饒克勤.我國醫療衛生體制改革與政策思考[J].中國執業藥師，2008，5（12）：9-12

[2]劉林森.信息化時代的信息化醫療服務[J].上海信息化，2010，（01）：84-87

第8篇：數據分析設計范文

關鍵詞：成績數據倉庫；OLAP；多維數據集；數據透視表；數據透視圖

中圖分類號：TP391文獻標識碼：A文章編號：1009-3044(2012)13-2944-05

The Design and Implementation of OLAP Data Warehouse of Student Score Analysis

HUANG Yu-da1,2，LI Xiang-qian2

(1.College of Computer Science and Technology，Southwest University of Science and Technology，Mianyang 621010，China；2. Information and Engineering Department，Zhoukou Vocational and Technical College, Zhoukou 466000, China)

Abstract: In response to the situation that a lot of student achievement data Stored in a transactional database are scattered, inconsistent, and independent,using Sql Server 2008 BI Business Intelligence platform and three-tier modeling approach to build an analysis-oriented student achievement data warehouse.The creating of multidimensional datasets，OLAP analysis ,and OLAP analysis results’showing by means of the pivottable and pivotchart of EXCEL 2007 front tool Provide strong support for Educational administrators in Decision analysis, the forecasting of teaching trend and the formulation of management measures.

Key words: score data warehouse; OLAP; multidimensional datasets; pivottable; pivotchart

目前，無論是與學生成績直接相關的教務管理系統還是與學生成績間接相關的學籍管理系統（存儲學生基本信息）和人事管理系統（存儲教師基本信息）等都已經積累了大量數據。但對這些數據的使用平時基本上都限于一些單方面分析且難以被再次利用，不僅缺乏一些相應技術對它們加以綜合分析[1]，而且這些系統由于相應業務不同導致相應的平臺、開發工具、數據庫系統等都不盡相同，可以說互相之間各自為政且缺乏科學、統一的協調和規劃。然而各院校為提高教學質量，對大量教學決策信息的需求顯得更為迫切。另外，數據倉庫是從歷史和發展的角度來組織和存儲數據[2]，是面向主題且為決策分析提供服務，而且學生成績數據也比較符合數據倉庫一些特征，如面向主題（成績分析）、相對穩定（每學期一次考試）、隨時間變化（學年學期）等。因此將與學生成績相關的一些數據庫系統中大量歷史數據加以預

處理后載入數據倉庫，可充分利用其中的多維數據分析技術（如OLAP）及數據挖掘工具等對倉庫中數據加以智能化分析處理，從而更好地為教學管理者提供決策服務。

本文采用微軟公司的Microsoft Visual Studio 2008中的Sql Server Management Studio平臺來構建學生成績倉庫，采用Microsoft Sql Server 2008中的Sql Server Business Intelligence Development Studio平臺工具來建立BI項目并實現多維數據集的創建、OLAP分析功能。

1成績數據倉庫的三層建模

本文采用通用的自頂向下、逐步細化的倉庫建模方式即三層建模，依次為：概念模型設計、邏輯模型設計、物理模型設計[3]。

1.1概念模型設計

概念模型設計是一種面向全局的、較高抽象層次上的設計，該階段主要任務是確定系統中主要主題域及其內容[4]。考慮到學生成績特點及影響因素，該文把學生成績分析作為主題來建立成績數據倉庫，倉庫中包含學生學籍信息、課程信息、教師信息、班級信息、專業信息、系別信息、學年學期信息和學生成績信息共八個方面的數據，將學生成績作為關鍵性能指標并將除學生成績信息以外的另外七個方面的信息作為維度數據，所有數據都分別來自學生學籍管理系統、教務管理系統和人事管理系統。

1.2邏輯模型設計

由于本文需建立的成績倉庫的維度數并不是太多而且數據量并非很大即不會占用較多存儲空間，所以針對關系模式的定義以及較高查詢效率的需求，這里決定采用星型邏輯模型，如圖1所示。

圖1成績數據倉庫星型邏輯模型

1.3物理模型設計

目前由于大部分數據倉庫都是基于關系型數據庫而且數據的最終管理及存放都是由相應數據庫系統來處理的，所以這里的物理模型設計就主要考慮關于物理數據庫的一些模型設計，如數據的索引、存儲及其結構等[5]。

本文設計的數據倉庫的核心數據庫是微軟的SQL SERVER 2008企業版關系型數據庫管理系統。對實體表的主外鍵均建立索引以提高響應速度。

2數據ETL過程實現

本文采用筆者所在工作單位—周口職業技術學院幾年來的學生成績相關數據作為數據源。考慮到2007年以前尚未全面啟用教務管理系統、時間略顯倉促及數據收集和預處理需花費大量時間、精力，所以數據源范圍暫先定于信息工程系、機電系和財經系三個系的07級、08級、09級學生成績數據。

2.1數據的抽取及清洗

在確定了成績倉庫中事實表及各個維度表的具體結果模型之后，就需要以這些結構模型為重要參考依據分別從各自對應的業務型數據庫系統中進一步抽取相關數據并經過預處理后再載入成績倉庫。

數據的清洗主要是對數據中的雜質、噪聲、不一致、不規范、遺漏等情況加以處理。一般應視各自具體情況區別對待，不要一律刪除。比如對于某名學生，若有少量課程成績遺漏或出現0-100范圍外的個別噪聲數據則應考慮取平均成績替代；若遺漏課程成績門數較多（4門以上）或因學籍異動造成其數據無法有效參與比較，為保證分析的可靠性則應考慮刪除。另外對于一些關于教師、課程、班級、專業維度信息數據的缺失或出現不一致的情況則進一步核實后加以填充。如有重修或補考成績則均采用正考即首次成績。

2.2數據的轉換

對于考查課中的“優”、“良”、“中”、“差”四個層次，為了便于統一分析，應向百分制轉換。這里對應關系為：“優”-90、“良”-80、“中”-70、“差”-50。此外，對于源數據表中各屬性名、類型及長度都要統一設置并與成績倉庫中對應的維度表及事實表保持一致。

2.3數據的加載

上述各環節工作處理完畢后，接下來就是最后一步即數據的加載。首先在Sql Server 2008 Management Studio環境下建立一個名為“StudentMA”的數據庫，然后利用Sql Server中的數據導入功能將已整理好的8個數據表導入到新建的數據庫中，如圖2所示。在載入目標成績數據倉庫數據庫后，還需根據星型邏輯結構和物理結構的具體設計來設置好各表主/外鍵并為其建立相應索引。

3多維數據集的創建及OLAP技術的應用

3.1多維數據集的創建

進入Sql Server 2008 Business Intelligence Development Studio集成環境后，新建一個名為“學生成績多維分析”的Analysis Service即SSAS項目，然后使用“解決方案資源管理器”來分別創建項目的“數據源”、“數據源視圖”、“多維數據集”。其中“數據源”所對應的連接字符串代碼為：

Provider=SQLNCLI10.1；Data Source=SWUST-573110AE0；

圖2預處理后數據源導入SQL SERVER 2008

Integrated Security=SSPI；Initial Catalog=studentMA

另外，為了滿足決策分析的需要，還需要再通過添加“平均成績”計算成員來新增度量值，新建的“平均成績”計算變量（avg? Score）所對應的MDX語句為：

CREATE MEMBER CURRENTCUBE.[Measures].avgScore AS round([Measures].[Score]/[Measures].[Score計數],0), VISIBLE = 1；

創建后的多維數據集視圖如圖3所示。

圖3成功創建后的多維數據集

最后，對SSAS項目“學生成績多維分析”加以部署和處理操作，部署并處理成功的結果如圖4所示。

3.2多維分析及OLAP技術的應用實現

首先可利用SSAS自帶的“瀏覽器”功能進行多維分析和OLAP操作[6]。在“瀏覽器”界面中，可根據用戶的OLAP處理要求來對創建的CUBE加以自由組合其中的維度，只需將左側窗口界面中的目標對象如維度、維度成員、度量值成員等直接拖動到窗口右側的顯示區域相應位置后即可查看OLAP處理結果。如果要進行數據篩選則需要將篩選條件所涉及到的相應維度名或其成員值拖放到右側窗口上方的篩選字段指定區域。如圖5所示。

另外，由于Microsoft Excel 2007全面支持Sql Server2008的SSAS服務，目前其作為微軟前端展現工具中的一個重要組件已在商業智能方面得到了較為廣泛的應用[7]。Excel 2007中的數據透視表和數據透視圖可直接訪問SSAS項目中對應多維數據集，這樣就不必開發應用程序即可快速而靈活地生成各種圖表及報表。因此可利用該組件來進行多維分析并展現分析結果。

下面通過Excel 2007中的數據透視表來進行多維分析。可在透視表窗口任意組合一些度量值和維度，直接拖動到EXCEL表格模型的相應行列中即可自動生成所需表格數據。如果想以數據透視圖方式來展示數據則只需點擊工具欄中的柱狀小圖標即可立即生成對應的透視圖。在某些情況下，透視圖的顯示效果要比透視表會更加直觀，如圖6、7、8所示。

其中圖6為教師、課程、班級所有學年學期信息的匯總顯示，細節區域內容為班級人數和平均分；圖7為信息工程系建筑設計技術專業在2009年第二學期教師、課程、班級及平均分信息匯總顯示；圖8為信息工程系道路橋梁工程技術專業在所有學年學期的教師、課程、班級及平均分信息匯總顯示。

圖4項目成功處理示意圖

圖5多維分析結果展示

圖6利用PivotTables功能在EXCEL前臺展示多維分析結果

圖7利用EXCEL前臺透視圖功能展示多維分析結果一

圖8利用EXCEL前臺透視圖功能展示多維分析結果二

4結束語

本文利用Sql Server 2008 Management Studio及Sql Server 2008 BI平臺成功構建了學生成績數據倉庫并建立了數據集市，然后進行了OLAP即聯機分析處理，最后利用Microsoft Excel 2007前臺工具中的數據透視表及數據透視圖組件對OLAP分析結果進行了直觀展示，為管理者進行科學決策分析提供了重要決策依據。另外，增加數據倉庫中的成績數據量以及對成績倉庫中的數據進行深入挖掘分析將是筆者下一步主要研究內容。

參考文獻：

[1]魏麗,王雁苓.高校學生成績分析數據倉庫的建立[J].吉林省教育學院學報,2010(6):42-43.

[2] Jiawei Han,Micheline Kamber.范明,等,譯.數據挖掘概念與技術[M].北京:機械工業出版社,2007.

[3]羅躍國.高校教務系統數據倉庫的建模及應用[J].長江大學學報:自然科學版,2009(3):235-237.

[4]王麗珍,周麗華.數據倉庫與數據挖掘原理及應用[M].北京:科學出版社,2005.

[5]陳文偉.數據倉庫與數據挖掘教程[M].北京:清華大學出版社,2006.

第9篇：數據分析設計范文

關鍵詞：海量數據 NoSQL數據庫 高并發處理

中圖分類號：TP311 文獻標識碼：A 文章編號：1007-9416（2015）07-0000-00

1 引言

針對海量移動應用數據構建一套可行的統計分析系統，從基本的數據統計，到深入的數據分析、挖掘，可以為移動互聯網企業提供全方位的海量數據解決方案，幫助開發者更好的了解市場動向，了解用戶的使用習慣和需求，從而創造出更有價值的移動應用。

2 系統分析設計

本系統的用戶為移動應用開發者，系統的最終目的是為開發者們提供一個應用數據的統計分析平臺，為開發者提供實時的用戶統計數據和應用統計數據，開發者可以利用這些有價值的數據對應用進行調整，從而更好地適應不斷變化的市場需求。系統主要完成應用趨勢分析，版本分析，渠道分析，用戶參與度分析和終端屬性統計五部分。應用趨勢分析提供對新增用戶、活躍用戶、留存用戶和應用啟動次數的統計分析功能，開發者從這些數據中了解當前應用的用戶情況，判斷出未來趨勢。版本分析提供對當前應用所有版本的統計分析，開發者可以從中了解目前市場上的版本分布情況，從而可以對版本的更新迭代做出調整。渠道分析提供對當前應用各市場下載量的統計分析數據，開發者可以從中分析出各市場的推廣情況如何，從而有針對性的調整應用的推廣策略。

系統分為數據服務器、移動終端和WEB展示端三部分來完成，其整體的功能結構圖如圖1所示。在實現的過程中充分考慮解決海量數據處理的問題。通過使用非關系數據庫NoSQL，Epoll技術及數據庫優化技術解決高并發請求，有效地緩解了海量數據對整個系統的壓力。系統整體在Linux系統下完成開發，綜合運用當前主流高效的開發工具和技術。

數據服務器部分是整個系統的核心部分。數據接收模塊負責從移動終端獲取用戶數據和應用數據，數據緩存模塊用于緩存接收到的數據，數據存儲模塊負責向數據庫從存儲基礎數據，數據統計分析模塊負責對基礎用戶數據進行統計分析操作，處理后的數據用于網站端顯示。移動終端部分用于獲取數據。基于XML語言對Android界面進行設計，通過對系統函數和XML解析獲取用戶數據和應用數據，后將數據通過TCP/IP協議發送給服務器端，若網絡不允許則將數據臨時緩存，等待下一次發送請求。網站展示端向開發者展示最終的統計分析數據。頁面設計模塊使用CSS對整體風格進行控制，繪圖模塊使用highcharts，使用php和javascript向highcharts填充數據。

3 系統總體設計與實現

本系統分為數據處理服務器，移動終端，WEB展示端三部分來完成。其中移動終端負責采集用戶數據和應用數據，將采集到的數據通過網絡傳輸給數據處理服務器。數據處理服務器一遍負責存儲數據，一遍對數據進行統計和分析。統計和分析的結果通過相應WEB端網站的請求反饋給開發者。整體的開發都在Linux系統下完成，移動終端部分使用Android平臺，使用Java語言進行開發。數據服務器使用Python進行開發，數據接收部分使用Linux下GCC庫，使用C++編寫，數據庫使用MongoDB。WEB展示端使用PHP語言進行開發，整體風格使用Bootstrap框架。同時使用Git作為版本控制工具，用GitHub作為版本容器，方便團隊協作和代碼更迭。

3.1 數據處理服務器架構

數據處理服務器需要實現數據接收、數據緩存、數據存儲和數據處理四部分功能。

數據處理服務器負責接收移動終端發送過來的用戶數據，通過高并發處理手段緩存到本地。數據庫處理程序負責從緩存文件中讀取數據插入到數據庫中。數據庫處理程序同時需要對基礎數據進行統計和分析處理，存儲到相應集合空間去。數據接收部分需要解決高并發請求。移動終端與服務器之間的通信使用TCP/IP協議，使用非阻塞的Socket連接來輪詢用戶請求。整體的底層架構使用Epoll庫，能夠很好的支持萬級別的并發量。數據緩存部分使用文件直接緩存。為了避免文件同時讀寫的鎖定問題，文件緩存按照一定的時間間隔寫入不同的文件中去。使用腳本文件拷貝寫入完成的數據文件到另外的文件夾用于向數據庫中寫入，寫入完成之后再將文件刪除。腳本使用python語言編寫。數據寫入部分也使用python進行編寫，數據采用非關系數據庫MongoDB。非關系數據庫在解決海量數據處理的問題上有著獨有的優勢，降低了程序與代碼的耦合度，同時還保證了數據存儲的可靠性。使用python處理數據寫入時需要用到MongoDB的python語言驅動，一般用pymongo即可。數據處理部分也使用python編寫。程序從MongoDB中讀取完數據之后，按照業務邏輯的要求對數據經行統計和分析。比如統計出某一應用一天的啟動次數。將這些統計數據存入到新的集合中去，留作網站展示端進行檢索。這樣可以大大減少網站端實時搜索對數據服務器造成的壓力。

3.2 移動終端架構

移動終端分為數據獲取、數據緩存、數據傳輸和界面設計四部分。移動終端整體架構使用MVC設計模式。前端界面設計使用XML進行配置，控制層將獲取到的數據一部分送至前端顯示，一部分送至數據服務器進行存儲。數據緩存使用SQLite保存未能發送至服務器的用戶數據。數據獲取指獲取用戶設備參數和用戶應用數據，設備參數包括設備的型號、分辨率、入網方式、內容服務商、系統版本號等，用戶應用數據包括應用的包名、版本號、啟動時間、使用時長、渠道信息、頁面訪問路徑等。數據緩存部分主要為了保證數據的完整性，因為用戶的設備并不能時刻保持網絡接入。當用戶處于離線狀態時，使用SQLite保存用戶信息。當用戶再次啟動時檢測是否有網絡接入，當發現網絡接入時將上一次的數據發送出去，同時清空SQLite數據庫。數據傳輸使用TCP/IP協議向數據庫服務器發送數據包。因為數據庫采用NoSQL數據庫，NoSQL數據庫的存儲格式為BSON（BSON是對JSON格式的二進制化），因此在數據發送之前需要將數據序列化為JSON格式。數據發送時需檢測數據是否正常發送，如果沒有正常發送則進行重發操作。界面設計采用Android標準開發模式，使用XML文件配置界面。頂部使用Google官方庫ActionBar，中間部分為ListView組件，ListView的每個Item都為一個數據，表示移動終端獲取到的某個變量。

3.3 網站展示端

網站展示端包括前端設計、數據處理和數據報表三部分。

前端設計以美觀大方為目標，使用twitter前端開源框架Bootstrap。Bootstrap提供了優雅的HTML和CSS書寫規范，它由Less寫成，Less是一種優美的動態CSS語言。使用Ajax、jQuery、Javascript等前端技術，融入最新的HTML5、CSS3結構設計，優化UI的整體表現。數據處理使用PHP和 javascript。使用PHP語言的MongoDB驅動連接數據庫，獲取數據庫中相應的數據，格式化成json數據之后再送給前端的javascript層。Javascript與前臺界面經行交互，控制前臺界面的展示效果。數據報表部分是整個網站展示端的核心，主要用戶想用戶展示各種類型的統計分析數據。包括柱狀圖、折線圖、餅圖等。圖形的繪制使用開源項目Highcharts。Highcharts是一個使用純javascript編寫的圖標庫，可以便捷的在WEB網站顯示交互性的圖表。

參考文獻

[1] 譚磊.New Internet：大數據挖掘[M].北京：電子工業出版社，2013（2）：13.

[2] 艾榮榮.基于電信統計分析平臺的關鍵性指標分析系統設計與實現[D].西安：西安電子科技大學，2010.2-4.