數據解決方案精選(九篇)

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

第1篇：數據解決方案范文

縱觀國內實施ERP系統終告失敗的企業，結合ERP的核心管理思想，可以將國內企業實施ERP系統失敗的原因劃分為項目管理的原因和技術管理的原因。

項目管理方面的原因或者是由于企業核心業務流程不合理，系統實施時并未對其進行充分合理優化，而僅僅套用了ERP供應商已有的功能模塊；或者是項目實施過程中缺乏系統控制；再者是部分企業領導層只是將ERP系統看成一種普通信息系統的引入，低估了實施系統的難度，導致實施過程中配合力度不夠，后續投資跟不上。

其實，在企業實施ERP系統的過程中，還存在著一個巨大的技術管理問題，就是企業未能有效地進行基礎數據的管理，這是導致企業ERP實施失敗的重要原因。

數據管理的缺陷

眾所周知，ERP之所以能幫助企業進行高效管理，必須是建立在對大量全面、準確、實時的企業數據的訪問、存儲和分析的基礎之上。而現在的一些ERP供應商為了減少成本，降低客戶的疑惑度，便淡化了對企業基礎數據結構的優化程度，基本忽略了對企業現有業務數據的整頓，只是從企業現有的零散和混亂的數據源中調用數據，來迎合其產品的數據輸入模塊，最終導致了企業基礎數據處理的嚴重缺陷。

首先，在企業實施ERP之前，沒有及時地調整企業基礎數據，為后來的系統數據管理紊亂埋下了隱患。通常，存在以下三方面的前臺數據操作問題：(1)數據輸入不規范，同一部門不同的成員有不同的數據輸入格式，造成數據不單一。(2)數據操作權限混亂，從而存在數據來源多，同一業務在不同部門的賦值不同。(3)企業本身一些業務不規范，沒有及時形成業務數據，導致在系統中的數據不完整。

其次，由于ERP涉及到財務、銷售和生產等各方面的數據，因此，數據結構復雜，數據源均來自于不同的二級部門，對于那些有一定發展歷史的企業，已經形成了較為穩定的、且各具特色的二級單位數據庫。由于在各個部門之間缺乏數據通道，各個二級單位的后臺數據庫都成為了“信息孤島”。如果在實施ERP系統的時候，不能很好地解決這一問題，就無法集成企業的基礎數據。

亮出三招

結合國內企業在實施ERP過程中存在的上述問題，作者認為可以圍繞企業基礎數據做出一系列的調整和管理，主要有以下三招。

整頓信息流

以現代企業管理為指導，以信息管理技術為工具，對企業現有的信息流進行整改，包括調整企業的職能模塊，優化企業業務流程。ERP項目上馬前，要充分了解企業信息流的情況，從企業權利結構方面入手，分析嚴重影響數據輸入、數據產生或數據管理等的原因，在調整企業職能模塊的基礎上，還需要優化企業業務流程。

構建數據管理模式

現在很多大型企業的二級單位已經建立起了相對穩定的業務子系統，同時具備自身的數據庫結構。但是，由于缺乏各部門之間的信息通道，所以，就形成了一個個“信息孤島”。

實施ERP也就是要解決這樣一個問題，即如何權衡效益和成本，綜合各個業務子系統的信息。全部重建固然可能達到最好的數據集成，但成本巨大；全面包容，又會造成數據平臺過多，數據格式過于分散，不能達到ERP系統的基本要求。因此，最重要的工作就是要先認真地考察各個業務子系統現有的數據結構，考慮其數據規模、數據庫本身結構、接口設計優劣狀況來確定哪些可以沿用不動，或變動較小。同時，應該明確規定各類數據的出處，保證特定數據具備確定的數據源，清理各部門之間數據管理重疊區，從而可以建立ERP的綜合數據管理模式。

第2篇：數據解決方案范文

“我們期待IBM信息管理軟件在即將到來的2012年呈現更加快速的增長，成為大數據時代中信息管理的利器。IBM一直提倡‘Think Big’，鼓勵自身深入思考、突破創新。在如今的大數據時代，我們對‘Think Big’有了嶄新的詮釋：Think of All Things That Big Data Makes Possible――深入思考并發掘大數據的無限可能，而這也正是IBM信息管理解決方案致力于為用戶創造的價值。”IBM軟件集團大中華區信息管理軟件總經理盧偉權表示。

這是一個不折不扣的“大數據時代”。據統計，全球90%的數據都是在過去兩年中生成的。為了應對數據大爆炸的挑戰，IBM推出針對大數據的全面解決方案，徹底突破了傳統數據倉庫和單一的數據管理體系，能夠為企業組織提供實時分析信息流和Internet范圍信息源的能力，實現更為經濟高效的大數據管理，并為在此之上的業務分析和洞察奠定堅實基礎。

IBM中國開發中心信息管理首席架構師及大數據架構師陳奇博士表示：“洶涌而至的大數據時代帶來嚴峻的挑戰。然而，挑戰背后也蘊藏著無限的機遇。IBM可以幫助各行各業的客戶將其數據價值不斷延伸，為企業發掘發展動力。我們的大數據平臺愿景就是將大數據融入企業，通過IBM大數據解決方案和客戶端及合作伙伴解決方案，為用戶提供優化的大數據環境，更加積極及時、經濟高效地從規?；⒍鄻踊透咚倩瘮祿刑崛∮行в^點，幫助用戶獲得突破性的洞察力和價值，化挑戰為機遇，化大數據為高價值?！?/p>

IBM大數據解決方案實現了針對大數據管理的企業級可靠性和適應性實時分析，在行業中具有突出的優勢。其最廣泛的平臺與數據倉庫、數據庫、數據集成、業務流程管理等組件充分集成，得以將大數據融入企業，充分滿足各種業務需求，幫助企業穩步發展。

IBM大數據解決方案跨多個行業，能夠幫助多渠道客戶分析其觀點和體驗。目前已有數千家新客戶正在轉到應用IBM的大數據解決方案上，以便從最廣泛的大數據中獲取可執行的洞見。丹麥能源企業維斯塔斯（Vestas）通過使用IBM大數據軟件分析PB級別的天氣數據，改善風力渦輪機的放置位置，從而獲得最佳能量輸出效果，以前需要數周方可完成的分析現在僅需不到1個小時就可完成。

第3篇：數據解決方案范文

高密度是結構化布線設計的設計人員和顧問需要面對的強制性要求，而在降低布線基礎架構物理空間需求的同時保持功能性和靈活性是首要問題。認識到同時提高密度和管理性的需求，通過創新的設計流程，安普布線能夠為這些環境提供全套的解決方案。

安普布線基于在電信市場行業內的多年經驗，開發出了新一代的電纜管理和電纜布線產品。

安普布線Hi-D 系統是一套完整的下一代基礎架構硬件產品，用于提高布線性能、維護性和日常使用功能。在這款先進基礎架構的設計中，電氣和機械要求及使用和維護性要求均為重點考慮要素。

安普布線Hi-D 系統包括： 角型配線架、水平和垂直線纜管理、超長存儲、具有專有技術的側面管理、光纖配線架系統、自動等電位連接控制。這些產品的組合使得安普布線Hi-D 機架內可以達到極大的配線量。

安普布線 Hi-D 系統提供了極佳的電纜檢修和維護平臺，可以高效地執行移動、添加和變更工作，并具有連接處理可靠性。

安普布線Hi-D 的專業側面管理托架是一種可以重復使用的角托架，可以自動地適應正確的彎曲半徑。同時Hi-D 系統的良好空氣流動設計可以支持有源設備的運行，通過保持電纜遠離通風通道，可支持各種冷卻方式，提高設備的可靠性和空氣流動效率。

安普布線 Hi-D 高密度連接系統提供了多種降低運營費用的功能，提高投資回報率（ROI），其中一個就是重視工作任務的需求，以降低移動、添加、變更及故障排除所需的時間。

通過針對銅纜和光纖的零 U 電纜管理，客戶可以達到節約空間的目的。

新型安普布線 Optimate 布線系統提供了插入損耗和回波損耗非常低的 MPO － LC 分接盒。通過這些新型的高級 MPO 產品，數據中心所有者可以在 200 米的通道內最多可設計 6 個 MPO - LC 分接盒，同時仍可保證滿足 1 Gb 和 10 Gb 以太網、光纖通道和 Infiniband 等數據中心應用的插入損耗和回波損耗值，且不需要任何額外的有源設備，即可非常輕松地擴展通道或構建冗余路徑，這可縮減安裝費用，降低電源和冷卻需求和提供更高的移動、添加和變更靈活性。

安普布線 Optimate 還適用于標準 LC 連接器，在 100 米通道內最多允許連接 12 個連接器。

第4篇：數據解決方案范文

【關鍵詞】 數據容災 兩地三中心

故宮博物院，建立于1925年10月10日，是在明朝、清朝兩代皇宮及其收藏的基礎上建立起來的中國綜合性博物館，也是中國最大的古代文化藝術博物館，其文物收藏主要來源于清代宮中舊藏。

故宮博物院保存著各種文字、圖片、流媒體信息，數據存儲量大，種類多，隨著館藏的不斷積累和豐富，擁有一套完整的網絡數字化資源已經是最基本必不可少的基礎設施，其規模和使用水平已經成為衡量一個博物館現代化管理水平的一個重要依據。而作為越來越重要的博物館數據資源，其安全性將是重中之重。因此，針對超大容量的數字圖像信息、視音頻信息和標本數據的安全性，迫切需要一套大容量、高性能的存儲設備進行集中數據存儲，并建立起一套合理的容災方案，以便于管理、保存、易用的數字化資源存放，實現博物館數據資源的數據保護管理。

根據故宮博物院信息化建設規劃，將在數據集中的基礎上，建立容災備份中心，并在將來形成兩地三中心的數據容災方式。經過與故宮博物院領導和容災技術專家的交流，根據故宮博物院的業務需求和系統規劃提出容災系統解決方案。

1 故宮博物院容災方案系統需求

1.1 系統現狀

故宮博物院主要信息系統系統包括辦公系統、業務系統以及數據采集、加工和利用系統。辦公系統和業務系統主要以服務器為主的運行模式，部門系統采用了數據集中存儲的方案。數據采集、加工和利用系統通過NAS存儲作為臨時存儲介質，對加工完成的數據通過FC SAN的架構統一的存儲到專門的系統核心存儲設備中。

對于數據保護方案部分，通過NBU備份軟件，將重要的數據備份到帶庫或者是磁盤陣列中。

如何為上述業務系統提供災難備份支持，確保了業務系統的7×24×365的業務連續性，實現了無數據丟失的災難備份系統。將是故宮博物院信息系統下一步的建設目標。

1.2 建設目標

根據故宮博物院現行的容災規劃，容災項目建設分成兩個部分：

（1）同城容災規劃：故宮中心機房：主數據中心，用于業務的生產運行，作為集中監控中心。北京同城容災機房：同城備份數據中心，用于在主數據中心出現短期無法解決的故障或非區域性災難時，將部分業務或全部應用系統切換到同城備份數據中心。

（2）異地容災規劃：異地容災機房：異地備份數據中心，用于北京發生區域性災難發生時，在較短的時間內進行關鍵的業務應用系統恢復。

3 故宮博物院數據保護方案

在對故宮博物院生產中心現有環境進行細致分析的基礎上，充分了解異地災備與同城災備建設的系統需求，嚴格遵循故宮博物院數據保護規劃的容災策略和設計原則，本容災方案，包含異地災備和同城災備總體方案，涵蓋生產中心存儲整合，以及同城災備中心、異地災備中心建設幾個主要部分。

3.1 故宮博物院數據同城容災方案

我們在規劃災難恢復方案時，首先應根據具體業務要求明確災難恢復方案所要達到的目標。因為不同的災難恢復目標，會有不同的災難恢復技術實現方案，以及炯然不同的投資規模和運行成本。通過存儲設備的MirrorView同步鏡像方案，實現同城容災。

MirrorView的實施和主機、操作系統、數據庫透明，即不占用主機、操作系統、數據庫。而且不同的主機、操作系統、數據庫可以通過一套MirrorView實現容災。MirrorView同時支持雙向的容災互備。MirrorView用來復制基于SAN存儲網絡的數據。（見圖1）

在異地容災建設過程中，可根據實際情況進行分步實施。

針對故宮博物院的需求，建議采用基于存儲陣列的Mirror View中心容災方案。在北京生產中心和同城災備中心，建議采用基于存儲陣列的無數據丟失的Mirror同步容災方案。這種方案能夠在保障生產系統正常運行、性能不受影響的前提下，實現數據0丟失。

3.2 故宮博物院數據異地容災方案

為了進一步提高數據安全性的保護，故宮博物院在實現同城容災的基礎上建立兩地三中心的異地災備中心，防范區域級的災難。根據故宮博物院的信息化發展規劃，先建設北京同城容災中心的基礎上，規劃建設異地容災中心；最終形成2地3中心的容災架構（見圖2）。

這樣一個同城災備加上異地災備的三中心災備方案，根據容災規劃，生產數據中心作為總行生產中心，運行絕大部分業務系統，并且作為集中的監控中心。同城備份中心實現與生產中心應用級的災備功能，確保RTO和RPO范圍內的業務持續運行，防御非區域性災難。異地數據容災中心實現數據級的備份，常規情況下用于測試系統，用于防御重大區域性災難。

在北京生產中心和同城災備中心到異地災備中心之間建立基于磁盤陣列的Mirror異步數據復制，實現無距離限制、無數據丟失的遠程數據備份方案。

生產中心的磁盤陣列與同城災備中心磁盤陣列保持同步關系。同城災備中心與異地備份中心間磁盤陣列為異步關系。

在正常運行時，將生產中心的存儲系統設置成源磁盤，將同城災備中心的存儲系統設置成目標磁盤，這樣源磁盤中的數據就會在MirrorView的管理下通過數據備份通道鏡像至目標磁盤之上，Mirror同步方式可以保證寫入磁盤的數據絕對不會丟失。

當生產系統發生災難性故障時，利用同城災備中心同步的Mirror備份數據和同城災備中心的備份機，可有效的將生產數據恢復到完全一致的生產狀態。

與此同時同城災備中心MirrorView將實時傳送至異地的災備中心，保證同城區災難備份系統完整性和遠程備份系統的有效性、自動化。

災難備份系統在災難發生后能否快速接替或恢復系統工作，使業務系統盡快恢復運行，需要強有力的組織、管理工作和多種規程予以保障。得當的組織管理工作、訓練有素的人員可以大大縮短恢復的時間，組織管理工作是災難恢復工作中的重要一環。

第5篇：數據解決方案范文

[關鍵詞] Oracle數據庫；備份；恢復；方案

doi ： 10 . 3969 / j . issn . 1673 - 0194 . 2016. 07. 088

[中圖分類號] TP315 [文獻標識碼] A [文章編號] 1673 - 0194（2016）07- 0189- 02

1 引 言

隨著油田廣域網的深入應用，油田開發生產管理、經營管理等信息數據急劇增加，并已成為寶貴的資產。企業給類信息在企業全部資產中所占的比例越來越大，在企業的網絡系統中，寶貴的已經不是企業所購置的各種硬件設備，而是企業在長期發展過程中所積累下來的各類數據。人們也認識到企業內部信息安全的重要性。為了確保企業網絡重要信息的安全，保證采油廠各項油田開發、科研、生產管理以及經營管理等工作的順利開展，網絡重要信息的備份和恢復是采油廠企業網絡建設和應用過程中必須解決好的重要問題。

分析和總結多年來網絡建設經驗，網絡信息的損失和丟失主要有以下三個方面的原因。

（1）來自自然界的破壞，其程度將是災難性的。

（2）來自計算機和網絡系統的硬件和軟件本身的故障。

（3）來自人為的因素，如“黑客”的攻擊、病毒的發作、商業機密的盜取、內部人員的蓄意破壞以及人為的操作失誤等等，這些往往是數據和系統破壞的最主要原因，而且對于企業來說更是防不勝防，所造成的損失和影響也將無法預料和估計。

數據備份將達到以下目的：

（1）企業內部重要業務資料的自動化存儲管理。

（2）簡化備份復雜性，節省人力資源，提高工作效率。

（3）確保數據存放安全，并有效集中管理。

（4）避免人為錯誤及自然災害的破壞，提高數據資料的正確性。

（5）快速、準確進行數據恢復，提高服務品質并提升形象。

2 采油廠Oracle數據庫服務器現狀

目前采油廠服務器包括數據庫服務器、Web服務器等，主要存儲油田開發數據，形成采油廠數據中心。數據庫采用目前比較先進的Oracle數據庫。

采油廠開發數據庫包括開發動、靜態、井下作業、采油工程等數據庫，數據主要以Oracle數據庫形式存儲，數據庫服務器每天24小時運轉。大量的油田開發數據每天從采油小隊、作業小隊、聯合站等上傳到礦服務器，經加工處理后，采油礦上傳至廠級及油田公司級Oracle服務器，數據在油田內共享。

基于Oracle數據庫開發的專業軟件已應用在各個專業領域中，比較典型的有油田生產管理、作業生產管理、采油工程生產管理等分析系統。

3 數據庫服務器備份恢復解決方案探討

Oracle本身提供的備份和恢復方式，在數據量不大，操作系統種類單一，服務器數量有限的情況下，不失為一種既經濟又簡明的備份手段。但隨著企業計算機規模的擴大，數據量幾何級的增長及分布式網絡環境的普遍應用。企業將業務信息分布在不同的機器及操作平臺上，用于數據存儲和提供數據服務的服務器逐漸增多，因此要建立一套高效的數據庫備份和恢復方案，自動地、實時地在線備份和恢復，以便能在服務器發生故障后，快速恢復，減少停機時間，不影響生產，保證數據的高可用性。

根據采油廠數據庫應用情況，根據數據庫用戶級別不同，將采用不同的備份方案，實現Oracle數據庫系統的自動備份和自動恢復。因此硬件與自動備份軟件集成的方案將適用于廠級Oracle數據庫服務器和各專業級Oracle數據庫服務器自動備份和恢復。

常用的備份軟件有多種，目前采油廠使用最多的，如Veritas公司的NetBackup、Legato NetWorker、CA ARCserve、HP OpenView OmnibackII、IBM ADSM等。它們都具有自動定時備份管理、備份介質自動管理，數據庫在線備份管理等功能。

經過充分的分析論證，備份軟件首選Veritas公司的備份軟件，它比較適合采油廠數據庫的系統環境和具體需求。

對于Oracle的備份與恢復，VERITAS提供了一套在增加可用性的同時簡化數據庫備份與恢復的解決方案（NetBackup Exec）。備份系統能根據用戶的實際需求，對備份的數據進行自定義，并以圖形界面方式根據需要設置備份時間表，備份系統將自動啟動備份作業，無需人工干預。自動備份作業可自定，包括一次備份作業、每周的某幾日、每月的第幾天等項目。計劃設定好后，備份作業就按計劃自動進行。

在網絡環境中選擇一臺應用服務器作為網絡數據備份服務器，并安裝網絡數據存儲管理服務器端軟件NetBackup Exec，并在備份服務器上連接一臺大容量存儲設備（磁帶庫、光盤庫），網絡環境中需要進行數據備份管理的服務器上安裝NetBackup Exec客戶端軟件，在備份服務器上利用NetBackup Exec 的管理控制臺設置自動運行的作業，如，在晚上10：00自動備份所有的Oracle數據庫，備份服務器在那一時刻就會自動的進行備份作業。通過設置不同的備份作業，可以實現各種不同的備份策略，如增量備份和系統全備份，實現自動的無人職守備份的功能。通過局域網將數據集中備份到與備份服務器連接的存儲設備上，實現對網絡的數據備份進行集中管理，實現自動化的備份、文件歸檔、數據分級存儲。

備份軟件也提供完善的災難恢復手段，能將備份硬件的優良特性完全發揮出來，使備份和災難恢復時間極大地縮短，實現網絡數據備份的全自動智能化管理。針對災難恢復，小到磁盤陣列出錯，大到整個機房受損，NetBackup不但能根據主備份異地進行完全恢復或部分恢復，而且能夠在遠端（或庫外）恢復應用或整個計算機服務器。它能夠自動創建主要備份的拷貝，這個拷貝磁帶既可以在異地磁帶庫，也可以是作為庫外管理的本地磁帶。庫外管理體現在，可以記錄介質的有效存放地點，無須人工記錄。

借助這樣的備份系統，可以實現：跨平臺數據的集中管理、應用數據的全自動備份、對介質的有效管理、數據的自動恢復、歷史數據歸檔、數據庫聯機備份、備份數據流程等等。

第6篇：數據解決方案范文

針對基金行業的發展趨勢及各基金公司的信息化現狀,廣州安正軟件科技有限公司(簡稱廣州安正,英文名稱BusinessMatrix)經過對基金行業業務的提煉,融合數據倉庫、商業智能等技術,開發了基金行業數據中心解決方案,將基金公司累積的大量離散數據資產,整合形成統一的數據中心,再基于可信、靈活的數據中心,實現數據知識化,完成數據價值鏈建設,從而輔助日常運作,支撐管理決策。BusinessMatrix基金行業數據中心解決方案包括以下內容:

整合數據,搭建基礎數據中心

數據中心的首要任務是整合TA、直銷、呼叫中心、估值、投資交易等系統數據,通過數據建模,經歷一系列的數據清洗、轉換過程,整合形成企業統一數據中心。

數據中心通過對企業層面數據的統一和規范,利用ETL工具對“臟數據”進行處理,確保數據的準確性、完整性和一致性;同時,通過數據倉庫的數據建模技術和數據分層技術,支持業務的各種數據和信息需要,以應對未來需求的變更與擴展,保證數據的靈活性與高擴展性。

搭建信息應用體系

數據中心利用BI工具開發、生成一系列業務報表、OLAP分析、儀表盤等信息資源,為用戶日常業務提供支持。生成的各種報表通過信息門戶集中,實現了便利的信息分類瀏覽功能。

通過BI前端工具對數據的展現加工,融合管理思維、模型與方法,面向業務實現數據知識化,便捷企業管理者對業務的洞察、分析與預測,可信的數據支撐可靠的分析與決策。

各種類型的信息資源最終被信息服務門戶分類管理,并實現向業務用戶的快捷傳遞,包括系統查閱、郵件、短信、移動應用等多種方式,還可與OA等業務系統整合,實現信息在OA等系統上的,方便業務用戶的使用。

建立信息資源管理平臺

基金行業數據中心需從多個業務系統數據源整合數據,經過一系列的清洗、轉換過程,并通過多種前端應用工具將數據轉換為報表、分析等應用。整個過程中,涉及的業務系統眾多,數據結構復雜,如何確保數據中心的穩健運行,并在問題發生時及時地解決問題,以滿足業務對信息的需要,成為數據中心不可回避的一個重要問題;同時,數據中心涉及源系統、數據倉庫、數據集市、報表、分析、儀表盤等方方面面的數據相關資產,如何管理這些資產,確保這些數據資產更好地為業務起到支撐作用,是數據中心面臨的又一個重要課題。

廣州安正在解決方案中整合了自主開發的信息資源管理系統,整體地管理企業所有數據相關的資產,并管理數據流動的過程,全面管理了技術元數據、業務元數據以及過程元數據。同時,信息資源管理系統全面管理與監控數據中心的運行,確保數據價值鏈的高可用性。

第7篇：數據解決方案范文

>> BPEL系統開發中異構數據處理的解決方案 一種海量數據處理平臺的解決方案 基于SOA的異構數據集成解決方案 異構系統中的三維CAD的解決方案 CAN總線系統開發關鍵問題及解決方案 電子商務系統中的大數據處理 電力自動化系統中的數據處理 富士通與萊卡合作開發圖像處理系統解決方案 多元企業標準數據處理分析編寫系統的開發設計 企業數據處理在軟件系統的研究和開發應用 就業通平臺異構數據集成與解決方案 音頻系統中的噪聲和解決方案 大型警務數據處理系統中的數據分流平臺設計 水處理系統在冬季運行過程中遇到的問題及解決方案 遙感圖像處理系統ENVI及其在MODIS數據處理中的應用 IT系統數據信息安全解決方案解析 數據庫雙機熱備份系統解決方案 基于ExcelVBA的數據處理軟件開發 基帶SoC的系統解決方案 基于智能移動終端的數據監控系統的解決方案 常見問題解答 當前所在位置：.

[3] Geminiuc K.面向服務的方法在業務規則開發中的運用[EB/OL]..

[4] Business Process Execution Language for Web Services Version 1.1[EB/OL].(2003-05). /developerworks/library/specification/ws-bpel/.

[5] Rosenberg F,Dustdar S.Business Rules Integration in BPEL-A Service-Oriented Approach[C].Proceedings of the Seventh IEEE International Conference on E-Commerce Technology (CEC’05),2005:476-479.

[6] Ali S,Soh B,Torabi T.A Novel Approach Toward Integration of Rules Into Business Processes Using An Agent-Oriented Framework[C].IEEE Transactions on Industrial InforMatics,2006,2:145-154.

第8篇：數據解決方案范文

P鍵詞： 實體動態屬性；數據庫設計；關系數據庫；非關系數據庫

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2017）05-0009-02

1 問題的提出

隨著大數據時代的來臨，結構化數據、半結構化數據與非結構化數據已廣泛存在于各個軟件應用中。任何移動應用和系統都離不開數據庫進行存儲數據，而數據的復雜性給它們的開發帶來了困難和挑戰。

在現實生活中，社會現實中的萬事成物都是一個動態系統。隨著時間的推移和事情的發展，各種實體都會發展變化，具體體現在實體屬性的變化上，因此，我們稱之為實體的動態屬性[1]。例如，在一款銀行績效考核系統中的客戶經理實體，隨著業務的發展，客戶經理的其考核內容也會發生變化，會有存款業績、貸款業務、基金業績、是否投訴等不斷增加，也會產生相對應的業績數值，這些不斷業績都稱為該客戶經理實體的動態性，詳情如表1客戶經理實體2017年1月份業務需求表所示。

在實際的項目開發中，固定數量的、明確的實體屬性，有利于軟件設計與開發人員進行項目開發。但是，動態屬性的實體，由于實體屬性的個數未知，屬性名稱未知，在系統運行過程中，根據業務的需要，隨時增添新的屬性，因此，給項目開發人員帶來了困難和挑戰。筆者在數據庫設計方面經過長期的實踐，探索出了針對該問題的實體的動態屬性在數據庫設計中的解決方法，希望對有相同需要的數據庫設計人員或軟件開發人提供一點參考價值。

2 定義相關數據結構

數據庫中的數據結構與數據對象的數據類型、內容、性質有關的，是對數據對象的一個靜態描述。為了便于說明，還以上述績效考核系統中的客戶經理實體為例進行描述。該客戶經理實體包括存款業績、貸款業務、基金業績、是否投訴等屬性，其在關系數據庫中可以定義成相關字段，具體詳細結構描述如下：

Create Table ClientManager（

CName nvarchar（50）， //姓名字段

CDeposit decimal（18， 2）， //存款業績字段

CLoan decimal（18， 2）， //貸款業績字段

CFund decimal（18， 2）， //基金業績字段

CIsComplain nvarchar（2）， //是否投訴字段

... //未知屬性字段

）

很顯然，由于實體未知屬性的存在，上述結構中的字段不明確，這樣的設計在目前的數據庫技術中不能得以實現。

3 關系數據庫中實體的設計方法

目前，市場要流行的關系型數據庫門類眾多，有甲骨文公司的Oracle、MySQL，有微軟公司的SQL Server，還有針對移動應用的SQLite。下面針對上述實體的動態屬性問題，給出兩種關系型數據庫的解決方法。

3.1 采用改行為列

為了改變上述字段不明確的問題，從表1中可以看出是二維表中的字段不明確，采用以行來代替列的形式，就可以把未知的列的值作為一條記錄存儲于表中，這樣，就可以根據需求動態滿足字段的增加或減少，解決該問題。但是，這樣需要解決兩個問題，一個是屬性名的問題和另一個屬性值的問題。因此，行轉為列的形式中，二維表中需要屬性名和屬性值兩列。具體的在客戶經理實體中，定義為經理姓名、業績名稱和業績額，具體詳細結構描述如下：

Create Table ClientManager（

CName nvarchar（50）， //經理姓名

CAchieveName nvarchar（50）， //業績名稱字段

CAchieveValue nvarchar（50） //業績額字段

）

在關系數據庫中，客戶經理的實體二維表中的業績和業績額從以行的形式轉為以列的形式，但是，表中的記錄數據增加，其具體形式如表2客戶經理實體行轉成列后的樣式表所示。

3.2 采用兩個關系實體

采用行轉為列的方式能夠適應簡單屬性值全都一個數據類型的動態屬性的問題，比如，例子中的業績額全為數值類型，開發人員在進行開發實現功能時可以進行統一計算。但是，如果屬性不是一個統一的類型，比如例子中的業績額有數值類型的，還有字符類型的。這種情況下，程序開發人員，在進行數據取值時，要有目的的進行運算，而在例子中屬性值的數據類型不明確，給開發人員帶來了麻煩。解決這種復雜的情況，可以增加一個實體表對屬性值的取值詳細信息進行描述，而將在該實體中將上一個實體的屬性名作為外鍵，這樣，就能夠保證數據的一致性。在例子中，在客戶經理實體的基礎上，增加一個業績設置實體，其字段有業績名稱、業績額的取值類型、業績額的取值長度、業績額的取值精度，具體表述所下：

Create Table AchieveSet（

AchieveName nvarchar（50）， //業績名稱字段

AValueDataType nvarchar（50）， //業績額的取值類型

AValueLength int， //業績額的取值長度

AValuePrecision int //業績額的取值精度

）

綜上所述，通過行轉列的方式，解決屬性值同一類型的動態屬性問題；通過兩個實體來解決屬性值非同一類型的復雜的動態屬性問題。程序開發人員可以根據不同的需求，采用不同的方法對系統進行開發。

4 非關系數據庫實體的設計方法

隨著技術的發展，對半結構化、非結構化的數據進行處理，出現了NoSQL數據管理技術的發展。下面結合非關系數據技術，給出兩種解決動態屬性問題的解決方法。

4.1 采用HBase模型

HBase是一個分布式的，面向列族進行存儲的數據庫[4]。在HBase數據庫中，動態屬性可以采用它的數據模型來進行實現。定義一個屬性列族，而在該列族中根據需要可以任意動態放入子列即可。具體操作是定義一個客戶經理實體，在該實體中創建一個業績列族，通過行鍵來存儲客戶經理實體記錄中的經理名稱，具體描述如下：

create ‘ClientManager’，'CAchieve'

其中，ClientManager’是客戶經理實體，'CAchieve'是客戶經理的業績。

實體表創建完成后，可以進行操作，進行存儲記錄數據，其操作如下：

put 'ClientManager'，'張三'，'CAchieve：存款業績'，'10000'

put 'ClientManager'，'張三'，'CAchieve：是否投訴'，'是'

put 'ClientManager'，'李四'，'CAchieve：基金業績'，'10500'

...

其中，張三、李四列使用的是HBase行鍵，'CAchieve'冒號后面是動態屬性。

4.2 采用MongoDB模型

MongoDB稻菘饈遣捎夢牡怠⒓合和數據庫三部分來對數據進行組織[5]。在MongoDB數據庫中，動態屬性可以采用它的數據模型來實現，根據其文檔的機制來進行實現。在例子中，采用定義一個客戶經理實體的集合，在集合中插入定義好的記錄文檔，具體操作如下：

db.createCollection（"'ClientManager'"）； //定義客戶經理集合

db.ClientManager.insert（{"name"："李四"，"存款業績"：10000"，是否投訴"：是}）

db.ClientManager.insert（{"name"："李四"，"基金業績"：11000，"是否投訴"：是}）

其中，大括號{}內的數據是文檔信息，存儲客戶經理信息，而每一鍵值對記錄該客戶經理實體的績效信息，比如，"存款業績"：10000"等。每個文檔內中的鍵值對中的鍵可以不相同，這樣，就達到了實現動態屬性的要求。

5 總結

截止到目前為止，關系型數據庫理論和非關系型數據庫理論并存，而且他們都已經發展得很成熟，在市場上廣泛應用。作者從實際開發一款績效考核系統中，考核指標不斷變化的實際需求出發，調研和總結當前市場上幾種處理實體屬性不斷變化的解決方案。根據不同的方案可選擇不同的數據庫技術，在開發實施過程中需要相應的技術條件和設備條件。總之，希望給后來者的學習和工作提供一些建議和幫助。

參考文獻：

[1] 唐小剛，譚石強.一種實體屬性非確定的關系數據庫設計方法[J]. 湘南學院學報，2006（4）.

[2] 李華娟.關系型數據庫設計之實踐技巧[J].電子技術與軟件工程，2016（1）.

[3] 李長春.動態字段在VFP中的設計與實現[J].計算機時代，1999（7）.

第9篇：數據解決方案范文

關鍵詞： 大數據；精準營銷

中圖分類號：TP311 文獻標識碼：A 文章編號：1009-3044（2015）29-0007-03

大數據作為一種新興的數據處理技術，最早可追溯到20世紀80年代的美國。如今，商業銀行在信息化的迅速發展中，產生了大量的業務數據、中間數據和非結構化數據等。大數據需要做的就是從這些海量數據中提取出有價值的信息，為商業銀行的各類決策提供參考和服務。匯豐、花旗和瑞士銀行是數據挖掘技術應用的先行者。在國內的商業銀行中，大數據的思想和技術也已逐步開始在業務中獲得實踐和嘗試。

基于大數據的精準營銷方案是利用大數據平臺的模型分析結果，挖掘潛出在客戶，實現可持續的營銷計劃。

1 應用基礎

1）物理基礎。利用Hadoop平臺作為大數據架構的物理基礎，首先需要對商業銀行整體的數據量作出評估，計算出需要設置的節點個數。在此基礎上確定Hadoop中的每一塊組件是否適合并能滿足目前及未來的業務處理需求。Hadoop的物理架構如圖1所示。

2）數據基礎。商業銀行需要在對內外部數據梳理、清洗、整合和建立映射的基礎上，將各類不同數據關聯成為一個有機整體，并構建統一的數據劃分維度體系，以此作為大數據平臺的數據基礎。

數據基礎基礎主要由四大部分組成：數據采集模塊、數據冗余模塊、維度定義模塊、并行分析模塊，如圖2所示。

2 應用需求分析

為獲得更好的精準營銷效果，并實現全流程的精準營銷解決方案。整體的應用目標是希望依托大數據平臺的分析結果在線獲取客戶的各類信息，再通過模型分析、客戶個性化需求、不同產品的特點等，在客戶與產品之間建立精準的對應關系。在業務操作上，還應當能幫助客戶經理對客戶做出準入判斷、提供營銷方案、實現限額管理、定價指導等智能決策信息。這些應用目標可以拆分成如下應用需求：

1）客戶挖掘功能。精準營銷的首要目的就是尋找目標客戶，只有尋找到精準的營銷對象才可能實現最終的精準營銷結果?？蛻敉诰蚬δ軕攺牟煌嵌取⒉煌肋M行挖掘，最大程度發掘潛在客戶群。

2）智能決策引擎。在獲得客戶挖掘結果后，精準營銷應用的下一步功能應當是針對具體客戶，提供一整套智能決策方案，包括客戶準入判斷、產品推薦、定價指導等。對于集團客戶、上下游客戶或關聯方客戶等，還應當能夠提出整體的營銷計劃。

3）業務統一工作平臺。精準營銷系統除了可以提供精準營銷的方案、計劃等決策結果，還應配備完整的業務操作平成業務實現。業務統一工作平臺可以實現整個精準營銷從客戶挖掘直至業務完成的各工作環節，最大化程度縮短業務操作流程、減少貸前調查復雜程度，實現精準營銷的“一站式”操作。

4）全生命周期的營銷計劃。精準營銷的應用不應只以單次營銷為目標，而是應當從縱向和橫向兩個方向提供持久的精準營銷計劃?？v向的可持續是指跟隨客戶的成長過程，在客戶不同時期提供適時提供客戶需要的產品和服務；橫向的可持續是指通過集團客戶、上下游客戶和其他關聯方客戶不斷挖掘目標客戶，擴大精準營銷范圍。

3 系統功能詳述

下面針對應用需求分析，從系統實現上把應用需求分解到系統功能點上進行詳細描述。

1）客戶類型初分。對于不同類型的目標客戶，精準營銷模型應當給出具有針對性的營銷方案。因此需要對大數據平臺里的所有客戶進行類型的區分。建立合理的客戶類型初分體系是精準營銷的基礎?？蛻纛愋统醴挚梢园凑請D3給出的體系進行劃分。

值得指出的是，在精準營銷應用中，對公客戶和零售客戶并非完彼此獨立。完備的精準營銷應用應當具備從對公客戶中挖掘零售客戶或從零售客戶中挖掘對公客戶的功能。

2）準入客戶篩選?？蛻魷嗜牒Y選是對客戶質量進行把關的工具，良好的客戶準入篩選標準是確保客戶質量、引導客戶結構的保障。實踐中考慮根據大數據平臺的黑白灰名單對客戶的準入進行判定：原則上白名單客戶屬于精準營銷判定的推薦客戶；黑名單客戶則是禁止準入的客戶；灰名單客戶可設為風險提示類客戶。

3）客戶信息整合及驗證。利用大數據平臺打通內外部數據、不同業務數據、不同結構數據之間的壁壘，形成以客戶為中心的“一戶一條”數據記錄。

為確保精準營銷結果的準確性，還應建立嚴密的客戶信息驗證機制。客戶信息校驗包含兩方面：一是錯誤信息的驗證，如同一企業在不同系統中的行業分類存在差異，大數據平臺將設置校驗規則判定哪一來源數據正確，并自動用正確數據覆蓋錯誤數據；二是數據時效的驗證，如大數據平臺有多個來源提供某個企業的營業執照有效期，系統將自動獲取最新的日期作為改企業的營業執照有效期。

4）客戶及場景標簽設定。根據精準營銷的不同角度設定不同類別的標簽，標簽應當具有靈活性，可以隨著業務發展和精準營銷場景的變換隨時增減或改變。標簽的設定主要包含以下幾類：

客戶標簽： 主要區分客戶的屬性特征，如職業信息可設定諸如企業高管、普通白領、職場新人、全職媽媽、小企業主等。

事件標簽：主要根據客戶生活場景或者銀行業務場景設定標簽，如對于客戶生活場景可能出現的標簽包括買房、買車、裝修、出國等。