熱門論文
最新論文
銀行內部理財平臺信息管理系統的設計與實現
發布時間：2023-07-17 14:49
第一章 緒論 1
1.1 選題的背景和意義 1
1.2 研究現狀及發展趨勢 1
1.2.1理財系統簡介 1
1.2.2國外研究現狀 2
1.2.3國內研究現狀 3
1.3 主要研究目標與內容 5
1.4 論文的組織結構 5
第二章 系統相關技術 7
2.1 系統軟件架構 7
2.2J2EE 技術 8
2.3MYSQL 數據庫 9
2.3.1數據庫建模技術 9
2.3.2數據庫 SQL 注入 10
2.4MVC 開發模式 11
第三章 系統需求分析 13
3.1可行性分析 13
3.1.1 經濟可行性 13
3.1.2 操作可行性 13
3.1.3技術可行性 14
3.2理財平臺信息管理系統需求分析 14
3.2.1理財產品查詢功能 15
3.2.2產品額度管理功能 15
3.2.3系統報表管理功能 15
3.2.4系統信息查詢功能 15
3.3 系統非功能性需求分析 16
第四章 銀行內部理財平臺信息管理系統設計 17
4.1銀行內部理財平臺信息管理系統設計原則 17
4.2理財平臺信息管理系統整體設計 17
4.3理財平臺信息管理系統詳細設計 19
4.3.1產品查詢管理功能設計 19
4.3.2產品額度管理功能設計 19
4.3.3系統報表管理功能設計 20
4.3.4系統信息查詢功能設計 21
4.4數據庫設計 22
4.4.1數據庫概念模型設計 22
4.4.2E-R 圖設計 24
4.4.3數據庫表設計 24
第五章 銀行內部理財平臺信息管理系統實現 27
5.1理財產品查詢功能實現 27
5.2產品額度管理功能實現 27
5.3系統報表管理功能實現 28
5.3.1 自定義交叉報表功能 28
5.3.2網點理財產品銷售統計表 29
5.3.3網點理財產品銷售臺賬 30
5.4系統信息查詢功能實現 31
5.4.1客戶信息查詢 31
5.4.2客戶風險等級紀錄 32
5.4.3銷售歸屬查詢 33
5.4.4募集期明細實時查詢 34
5.4.5理財購買記錄查詢 34
第六章 系統測試 36
6.1系統功能測試 36
6.2系統性能測試 39
第七章 總結與展望 40
7.1 總結 40
7.2 展望 40
參考文獻 41
致 謝 43
學位論文獨創性聲明 44
學位論文知識產權權屬聲明 44
第一章 緒論
1.1選題的背景和意義
科技在發展，國家在進步，人們的收入也慢慢增加了，可支配收入也越來越 多，生活觀念也不再像之前那樣陳舊。所以，理財就成為了人們的首選，客戶對 理財的熱情和需求也在逐漸增強，大多數家庭的剩余資金已不再以單一存款的形 式放入銀行，而是慢慢地接觸銀行理財產品［1］。但是，金融行業也存在著一定的 風險，金融產品的價格和收益也不會一直保持穩定不變，它會隨著金融市場的變 化而變化，產品的價格和收益具有不確定性，所以，相對于單一存款的方式，人 們需要承擔一定的風險。由于人們都開始轉向理財產品，所以，銀行為了留住原 有的客戶，吸引新客戶，也開始注重發展理財產品，向客戶推出各種理財組合。 在這種形式下，一個好的理財平臺信息管理系統就可以為銀行和用戶帶來更多幫 助，在為銀行提高利潤的同時，還可以為用戶提供更好地服務［2］。
投資者為了獲取更多的收益，一般會將資金投放到多個理財產品上，這樣可 以降低投資的風險。由于我國的理財產品還處在發展初期，我國國民對理財的了 解還有待提高，相關的監管體制也需要進一步改革和完善，從而在降低風險的基 礎上提高人們的收益。本文所講述的理財平臺信息管理系統，不僅可以很好的應 對市場需求，還可以提高銀行的積極性和主動性，使理財產品的層次更高，更多 樣化，這也是理財產品管理的一個很好的方法。
1.2研究現狀及發展趨勢
1.2.1理財系統簡介
經濟發展給居民帶來了更高的個人收入，人們可以控制的個人財產總量穩步 增長，股票的流行使人們看到金融管理服務可以帶來巨大的收益。然而，與此同 時，財務管理中的風險也是客戶選擇財務管理時考慮的重要指標之一。金融產品 的出現給銀行和客戶帶來了新的刺激。傳統的銀行收入來源是儲蓄存款和貸款的 利息差額。隨著國家政策和盈利模式的變化，銀行的贏利方式發生改變，銀行間 的競爭越來越激烈。單純依靠儲蓄存款和貸款的經營模式不再能給銀行帶來利潤 ［3-4］。因此，銀行將贏利目光轉向了各種形式的金融產品，用來刺激客戶和利潤 的增長。
對于金融服務本身來說，用戶必須看到它們帶來的利潤和風險之間的關系。 理財產品相對于儲蓄存款的特點是，用戶可以通過冒險獲得更高的利潤。所以， 在理財產品和系統的設計過程中，不僅要考慮系統中的風險，還要考慮利率和價 格等多種因素所帶來的影響。通過對這些因素的綜合評價，我們將盡力規避風險， 制定合理的金融產品和服務。
與儲蓄存款相比，銀行理財資產是可以通過各種業務形式去流通的。在設計 和實施理財產品和管理系統時，必須考慮產品和用戶自身的特點［5］。根據客戶的 具體特點制定具體的財務管理計劃。
1.2.2國外研究現狀
在發達國家當中，很多銀行金融部門開始對理財問題進行研究和投放于金融 市場當中，在長期的發展過程中取得了一定的成就。銀行通過對理財產品進行研 究的主要目標就是找出影響客戶消費行為的因素，建立數據分析平臺來判斷對整 個行業的影響［6］。經濟學家莫迪里亞尼在長期的研究與實驗當中提出了基于經濟 學的生命周期理論，該理論很好的解釋了消費者的消費行為，其核心內容表示： 個人規劃自己的資金行為是一個長期的過程，并且是有計劃的進行消費和儲蓄， 在其生命周期理論當中其消費最佳的時期就是在生命周期內完成。另外一位經濟 學家 Anderson 認為銀行的聲譽以及整體實力和工作人員的服務態度、服務的費 用、親朋好友的推薦以及內部業務的方便性這些因素對客戶進行銀行選擇上面提 供了重要參考。邁克爾•波特提出，銀行需要根據自己的優勢和運營特點來對客 戶進行細分，將其更加科學的劃分不同客戶群體，對不同客戶群體制定不同產品， 更好地反映客戶的差異化要求［7］。與此同時，在發展的過程當中逐漸提升自己的 競爭優勢與核心競爭力，樹立自己的品牌價值，吸引更多的優質客戶加入以進一 步擴大市場。
佩帕德(Joe Peppard)指出，大部分財務管理系統的核心業務處于前臺、后臺 和客戶渠道管理當中，而當前的電子商務活動和客戶關系整合到客戶中心的核心 戰略當中。然而，在挖掘長期積累的客戶信息、金融產品選擇和管理數據，并通 過數據挖掘技術分析個人金融活動之后，發達國家［8］的研究已經開始。例如，以 美國第一國家銀行為代表的商業銀行在分析過程中使用數據挖掘技術，對信用卡 用戶的消費行為和習慣進行了深入分析。瑞士銀行和花旗銀行還將數據挖掘技術 引入用戶分析、產品管理和消費分析；匯豐銀行使用 KXEN 數據挖掘工具挖掘不 斷增長的客戶資料和數據，以發掘交叉銷售和滾動銷售［9］。然而，直到學者們開 始研究客戶關系管理系統，數據挖掘技術才真正得到重視。許多歐美銀行，如法 國興業銀行、蘇格蘭皇家銀行、美國商業銀行、德意志銀行、美洲銀行、荷蘭銀 行、澳大利亞國民銀行等，開始使用數據挖掘技術為自己的商業經營決策。總之， 隨著數據庫技術的日益成熟和數據倉庫的快速擴展，數據挖掘技術已經成為發達 國家和地區銀行重要的戰略決策方法之一。上述歐美銀行不僅擁有完善高效的數 據采集系統，而且在實踐過程中實際上已經完成了從知識到財富的轉化過程。
1.2.3國內研究現狀
對比國外一些銀行機構可以得知，國內銀行對個人理財業務的研究雖然時間 比較短，但是由于不斷努力在該領域也有一定的成就。陳繼紅、鄭振歐（2003） 在研究中指出個人理財服務是基于一套銀行的內外產品、綜合服務、信息科技、 服務環境以及營銷宣傳上進行多方面結合對其綜合考慮以及個性化服務。陳姍姍 （2003）在商業銀行的個人理財業務當中有所建樹，其主要思想是個人理財業務 如何選擇與設計數據挖掘的模型，最終在研究當中提出了個人理財客戶價值模 型、客戶滿意度以及客戶細分模型，該研究當中也存在不足，那就是沒有基于數 據挖掘技術對實際數據進行深入研究分析［10-11］。針對該研究，該論文基于大量個 人理財習慣以及銀行實際業務需求進行分析，設計開發銀行內部理財平臺信息管 理系統，并且針對海量用戶信息進行分析得出更符合市場需求的銀行理財平臺信 息管理系統。
魏敏、田蕾（2006）根據“家庭生命周期”的研究方法，把問卷的樣本針對 市場進行了細分，并且使用方差分析將諸如家庭生命周期和人口統計學的綜合指 數變量識別為其細分變量。該方法研究了四組客戶：重要客戶、一般客戶、潛在 客戶以及未來客戶。金融服務質量預期的差異以及各自財富管理服務的個性差異 ［12］。與此同時，針對這四類客戶對主要銀行理財以及財務管理工具的需求進行分 析，并根據市場需要制定針對性、差異化的營銷策略［13］。李江、魏敏（2006）根 據客戶本性和心理元素的特點，對個人理財客戶進行了市場細分。首先，根據個 人理財客戶的人格變量，采取因子分析法提取四個重要的人格特點。也就是說， 四個共同因素，然后選取這些共同因素的因子得分作為聚類變量，并進行聚類分 析，并將個人財富管理客戶分成三類。最后，對比了個人財富管理業務需求的差 別，人格特征的差別，客戶忠誠度差別以及三類客戶的心理特點［14］。李麗麗、陳 啟書等（2007）針對中國各項金融理財產品的市場可行性分析，針對國內商業銀 行理財產品的發展現狀，結合銀行的理財市場，得出小資本商業銀行可以專注低 資本投入，來獲取相對的高收益項目 ［15］。許多銀行不明白可以用哪種銀行服務 數據挖掘，并且他們不懂得用數據挖掘的力量來提高其銀行交易能力。 因此， 這種數據處理技術仍然處于紙面的概念層面，尚未采取行動。雖然一些規模比較 大的商業銀行早已經將數據挖掘技術應用到各項業務當中，但是針對用戶理財產 品進行數據挖掘以及數據分析還不夠深入，大多數銀行在個人理財數據挖掘方面 還有很大的提升空間。孫淑君，嚴樹超，許磊行，王璐（2007）基于計算機技術 進行分析商業銀行個人理財交易中的核心作用，借助當前大數據分析，基于數據 倉庫以及數據挖掘技術進行分析，其課題也是基于該技術對個人銀行理財系統數 據信息的設計方案［16］。葉彧佩（2009）在其研究當中核心就是研究消費者在銀行 理財產品購買的影響因素，其中在其影響因素主要有：產品利益、產品風險、銀 行品牌榮譽和銀行服務因素。影響理財產品的主要因素就是銀行的服務質量以及 信譽度，這些綜合因素將會決定消費者的購買導向。理財產品的滿意度對消費者 購買有很大的積極影響。最后，在商業銀行的個人理財產品的類型當中影響消費 者購買行為還是其產品的體驗以及對產品的滿意度上。黃國平（2009）針對國內 銀行業務進行分析，對比國外銀行業務分析出商業銀行業務產品從產品向發展模 式以客戶服務中心的綜合發展模式轉型期。在銀行財富管理發展當中，也是對外 環境問題以及銀行內部本身的概念［17-18］。劉曉剛（2011）對銀行個人理財數據進 行分析，并且總結近期銀行個人理財業務概況，總結了個人理財業務與銀行風險 控制的重要性。從銀行本身、政府以及金融監管機構的角度來看，提出了針對風 險相關的控制策略。劉操等（2012）在其研究當中，指出經濟發展要和金融市場 體系更加匹配，促進商業銀行個人理財業務的增長，讓銀行又獲得了新的利潤增 長點，但是快速發展下也存在一定的問題[19]。
總而言之，個人理財業務在整個銀行發展以及國家銀行當中占據著越來越重 要的位置，也是未來銀行利潤的增長點。隨著互聯網經濟以及金融的全面發展， 國內銀行的個人理財業務也得到了長足的發展。并且各個銀行內部也開始開發設 計銀行個人理財系統，對個人理財業務起到了很大的促進作用。基于金融大環境 的發展，結合國家各大銀行的業務需要，本文設計實現了銀行內部理財管理系統 [20]
o
1.3主要研究目標與內容
本論文通過對理財信息管理平臺以及現有產品的分析，設計實現一款新型的 銀行內部理財信息管理系統。本文在對相關系統進行研究以及調研之后分析了系 統的可行性因素，從系統需求分析、系統設計到實現進行逐步深入，完成系統開 發和測試。
該系統采用 B/S 架構進行設計實現，主要針對后臺進行數據處理，其頁面展 現使用了主流的 HTML+CSS 進行設計，對客戶及其相關功能進行詳細分析，詳細 設計實現了理財產品的查詢、產品額度管理、系統報表管理、系統信息查詢等功 能；在系統報表管理當中設計了自定義交叉報表、網點理財產品銷售統計報表和 網點理財產品銷售臺賬；在系統信息查詢功能實當中包括了客戶信息查詢、客戶 風險等級認證記錄、理財銷售歸屬查詢、募集期明細實時查詢和理財購買記錄查 詢。
通過對系統得實現，銀行內部管理人員可以更加有效的對理財項目進行管理 和對客戶信息進行管理，對理財產品交易進行分析統計，生成各種分析報表和系 統查詢報表。這些數據方便銀行為客戶提供更合理的理財服務，以及系統高效的 管理理財服務。
1.4論文的組織結構
論文主要是針對銀行內部理財平臺信息管理系統的設計與實現，通過借助計 算機語言，以及 J2EE 開發技術、 MVC 開發設計模式、 B/S 模式三層結構結合技 術、選擇關系型 MYSQL 數據庫技術，論文研究的內容結構具體劃分如下：
第一章為緒論，主要是對銀行內部理財平臺信息管理系統的背景、意義、國 內外研究現狀以及主要的研究內容進行介紹。
第二章是對論文涉及的相關技術進行介紹，主要是對J2EE技術、B/S開發模 式、MVC設計模式，以及MYSQL數據庫技術優勢與特點進行闡述，這些技術是 論文的研究基礎。
第三章為需求分析，對銀行內部理財平臺信息管理系統的可行性需求、總體 需求、功能需求、非功能性需求進行分析。
第四章是對銀行內部理財平臺信息管理系統設計，基于此平臺的可行性、功 能性、非功能性需求分析基礎上，對其進行了系統的總體設計，分別是系統開發 的框架與總體功能結構設計，通過銀行內部理財平臺信息管理系統設計的目標， 對系統核心功能中的產品查詢管理功能模塊、理財產品額度管理功能模塊、系統 報表管理功能模塊、系統信息查詢功等功能模塊以及系統的數據庫、與網絡安全 機制進行設計。
第五章是對銀行內部理財平臺信息管理系統的實現。實現銀行內部理財平臺 信息管理系統核心的功能，包括各個功能模塊的實現過程。接下來是對銀行內部 理財平臺信息管理系統的測試，主要針對系統提出測試方案、進行功能測試和系 統的性能測試，最終對測試結果進行分析。
最后，總結全文，并針對論文的問題提出展望。
第二章 系統相關技術
2.1系統軟件架構
B/S架構是一種基于服務器和在線瀏覽器的網絡結構模式，自WEB快速發展 后應運而生。基于 B/S 架構的系統客戶端不再需要對系統或者軟件進行頻繁的更 新操作，僅僅需要連接互聯網打開WEB瀏覽器即可，從而有效做到簡化客戶端的 計算機處理載荷。通過設置在前端的瀏覽器處理極少數事務邏輯，然后其余主要 的事務邏輯以及大量的數據處理操作都是通過服務器端進行實現。它基本的工作 方式總結為通過用戶所使用的瀏覽器發出對應的數據請求，服務器再判斷客戶端 請求，如果符合服務器端的請求要求，服務器端將會給客戶端一個數據響應，這 樣就可以實現客戶端與服務器端的數據交互。因此，基于B/S架構下的軟件或者 應用系統無需客戶端的更新維護，在一定程度上減少了系統維護的成本費用，而 且便于系統的更新和升級，系統升級只需要在服務器端完成操作即可，所有的數 據也不需要在客戶端進行存儲，可以為客戶端減少更多的負擔。主要的架構特點 還有分布性強以及共享性強［21］。但這種架構也存在不足，例如存在安全問題、對 服務器性能要求偏高、降低了所搭載的各軟件自身存在的個性化，最明顯的缺點 是因架構依存于瀏覽器而各瀏覽器間的差別大程度影響了網頁的兼容性即受程 序運行環境限制，其實際的工作原理圖如下圖所示：
圖 2-1 B/S 結構圖
2.2J2EE 技術
JAVA的J2EE是當年SUN公司開發的一款WEB產品，基于tomcat或者apache 服務器上進行解析和運行的，同時符合HTTP數據傳遞標準并且基于互聯網服務 器執行的嵌入式網頁腳本技術［22］。而J2EE是對JSP的進一步發展和集成，在數 據管理、功能性能和程序執行效率當中有JSP沒有的優勢。J2EE是基于其公司 自身框架進行開發和設計，并且在三層框架下可以更好地執行WEB應用程序，提 高程序的執行效率，再加上其編程語言依托于JAVA編程，借助其編程語言的面 向對象特性讓其可移植性越來越強，讓整個程序在動態交互的情況下實現客戶端 與服務端數據交互。同時J2EE完全基于HTTP下實現編程可以更好基于WEB數據 通信，在框架內部安裝了其服務端的 IIS 服務，在本地執行起來效率更高，隨著 ASP.NET 的版本不斷升高，其對應的功能以及框架版本也不斷在進行更新。
基于J2EE的WEB應用程序在進行開發過程中選擇了自己推出的開發平臺即 myeclipse的IED［23］。該開發平臺可以更好的實現基于JAVA下進行連接和組合， 在編譯和運行的時候執行效率非常高，可以在IDE下直接編譯運行。基于該平臺 的編程有自己的優勢并且在其操作系統下兼容性非常強大，可移植性比較強，在 整個軟件以及系統開發當中其團隊管理的核心作用試幫助開發者更好的實現項 目管理和符合現代軟件工程學的要求。基于Apache服務器進行運行WEB系統, Apache全稱Apache HTTP Server，是一種能在大多數計算機操作系統上運行的 開放源碼的服務器，它可以廣泛使用在各計算機平臺，具有很高的安全性能，成 為世界使用排名第一的Web服務器軟件。Apache網頁服務器是自PHP進入市場 后出現的典型配置亦是世界范圍內使用排名高居首位的Web服務器軟件，它是一 個開放源代碼的網頁服務器。此款軟件發布過多個版本，作為一個 web 服務器 軟件，它不僅做到了為 SSL 技術提供有效支持還可以同步做到支持多個虛擬主 機。
Apache遵循的是HTTP協議，默認端口號為80。Apache是web服務器的一 種，所以也是遵循 web 服務器端的工作流程：（1）通過瀏覽器向客戶端發送請 求（2）服務器開始解析請求（3）完成請求的動作，服務器給予一個響應（4） 關閉文件與網絡連接，結束會話。其Apache的優勢就是可以借助HTTP超文本 傳輸協議實現互聯網之間的數據通信，并且請求服務器端也是基于該協議下完成 的，在當前的 WEB 應用程序使用越來越廣發的時候，其基于 Apache 服務器的 數據傳輸使用更加廣泛。
2.3MYSQL 數據庫
MYSQL數據庫是一種輕量級應用非常廣泛的關系型數據庫，并且屬于自己 關系型數據庫管理系統，它可以實現多用戶、多線程操作和管理。存儲數據的核 心就是不同的關系數據表或者是視圖當中，這用在數據表存儲數據的時候可以提 升數據的訪問速度，再加上不同數據之間的關系在一定程度上增加了軟件數據管 理的靈活性［24］。同時，在對數據語句進行操作和存儲過程編程的時候，采用了當 前流行且標準化的 SQL 語句對數據庫進行操作和管理，可以通過執行標準的命令 語句進行各種操作，極大的提高了數據存儲、讀取以及各種操作的執行效率。當 前基于WEB應用程序的開發在數據存儲很大一部分選擇了 MYSQL數據庫，可以對 接各種開發語言以及達到了最佳優化，并且在開發的過程當中提供了豐富的開發 接口，功能變得極其強大，具備很好的向外擴展能力和向上的延伸能力，能夠很 好的滿足中小企業以及個人軟件的數據存儲。另外一優勢那就是MYSQL數據庫的 開源，讓其很多企業成為系統或者冉家開發的首選，其自身數據庫管理系統體現 小、成本低等優點泅。MYSQL數據庫管理系統將用戶訪問權限分為四個層次，目 的就是防止其發生獨占資源，可以設置其用戶的鏈接數目或者在單位時間限制用 戶訪問資源數來提高數據的安全性和數據庫的穩定性。由上述各項特點，共同成 就了 MYSQL這一軟件，使其成為了 WEB應用以及系統開發領域所被認可的， 最好 RDBMS 應用軟件之一，成功彌補了軟件所存在的某些不足之處。
2.3.1數據庫建模技術
數據建模的主要目的就是對當前使用各類數據的一個抽象過程，主要是為了 確定其所需要的數據使用范圍、組織形式等將其轉化為實際使用的數據庫，方便 進行管理和使用。經過對整個系統分析完成之后抽象出來的概念模型轉化為其物 理模型之后，在使用數據庫管理工具建立其實體以及實體之間的關系過程，這個 實體大部分指的數據庫內的數據表。同時，建模的是進行對數據庫信息系統進行 定義和分析相應實際需求，所以在數據庫建模的整個過程中應該了解其內部的實 際關系。
目前，從需求到實際需要的數據庫，主要分為三種類型。期中，用于數據信 息系統的數據模型是一個概念性的數據庫模型，本質上主要是記錄相關的數據的 一些技術規范。數據首先是用于討論使用者的最開始的需求，然后在進行分析處 理成為一個邏輯數據模型，其邏輯數據模型可以基于數據庫中的數據結構概念模 型實現［26］。總體來說一個概念模型的實現需要一個或者多個邏輯數據模型組成。 而在建立數據庫建模的最后一個步驟那就是邏輯數據模型到物流模型中到整個 訪問過程的性能和存儲的實際需要。數據庫建模的定義不單單是針對期中的數據 元素，也包括它們內部的結構以及結構之間的相互關系。
數據庫建模過程中的主要活動包括：數據的選擇確定及它們之間的相關關 系，實現過程；定義數據主要包括使用數據類型、數據存儲大小和是否設置數據 默認值；保證使用數據的有效性和完整性，主要是針對業務的要求規則和檢查正 確性；定義數據整個操作過程期中包括數據的各種檢查和備份；最終選擇數據存 儲技術，根據業務邏輯的實際需要選了其存儲技術，主要包括關系、分層和索引 等數據存儲技術。
2.3.2數據庫SQL注入
SQL 注入對整個系統安全威脅非常大，導致系統數據丟失和無用數據存儲 到系統當中導致整個系統崩潰。在 SQL 注入中進行分析主要產生的原因和棧溢 出、 XSS 等很多外界攻擊方法類似，大部分就是沒有得到系統檢測或者未允許用 戶輸入數據，當系統當中被執行的代碼的一個過程。據 SQL 注入的原因，其實 大部分是基于用戶提交的數據被數據庫系統進行編譯產生了系統開發者預期以 外的操作［27］。同業可以認為， SQL 注入的本質就是用戶輸入的數據，在進行對 SQL語句進行拼接的一個過程當中，超出了數據本身的作用，成為了 SQL語句 執行邏輯的一部分，然后通過數據庫系統進行執行，產生開發者預期以外效果的 過程。
所以從根本上放置SQL注入等類似攻擊的手段，還是避免數據生成的相關內 容變成代碼被執行，要進行分清楚程序代碼和數據的界限。對于 SQL 注入的情況 來說，大部分被執行的代碼都是通過數據庫的 SQL 解釋引擎進行編譯之后得到 的，所以要避免數據庫系統進行編譯我們輸入的數據信息，這樣就會很好的避免 SQL 注入攻擊。
當前主流的數據庫管理系統都會提供相應的SQL語句的預編譯和查詢參數 的綁定功能，在SQL語句中存放相應的標識符或者占位符［28］。然后通過占位符 來區分 SQL 語句，確認完成之后傳給數據庫進行編譯，最終執行的時候就會區 分出用戶輸入的數據，將相應輸入數據作為執行的相關參數傳遞給用戶，這樣在 實際的編寫程序代碼時候就可以很好的避免了 SQL的注入，提高了系統的穩定 性和安全性。
2.4MVC開發模式
銀行內部理財平臺信息管理系統照結構模型進行布局和設計，設計系統的總 體架構需要結合系統所收集到的用戶需求，在開始實施之前要對這些需求進行驗 證。主要可采用需求評審方法、需求原型評價方法、基于CASE工具的需求一致 性分析的方法對所獲取的需求進行設計的有效性、完整性、一致性等幾個方面的 有效性驗證。得出最終需求并付諸實踐，開發系統。將整個在線因為網站的架構 分為三層，通過這種方式將整個系統的功能模塊化處理。模塊化是好的系統設計 所遵循的一個基本準則，高層模塊從總體上把握需要實現的功能和問題，暫時隱 蔽一些微小的細節部分問題［29-30］。做好高層模塊設計后，可以從高層模塊出發逐 步向下細化模塊，在細化的過程中將需要處理的問題進行分解，即將難以處理的 復雜問題逐步分解為較小問題，再將實際問題細化后進行妥善處理最終解決高層 模塊暫時存在的復雜問題，這種方法可以減少解決問題的總工作量，節約系統開 發時間、提高問題處理效率，系統的整個MVC架構實現過程如下圖所示：
圖 2-2 MVC 流程圖
系統模塊化要做到信息隱蔽即當前模塊所包含的內容和信息不允許其他不 需要這些信息的模塊進行訪問交互，各個獨立的模塊間只交換為了完成系統功能 所必須進行交換的信息［31］。這樣做可以有效提高模塊的獨立性，便于對系統進行 后續維護可減少修改或維護操作時的影響面。信息隱蔽的同時要兼顧信息局部 化，把模塊間關系密切的軟件元素設計時物理地放得彼此靠近，這樣做的優點是 理解性好、可靠性好亦方便維護。
第三章 系統需求分析
3.1可行性分析
3.1.1經濟可行性
切實全面的可行性分析是具有前導性的必要工作，有利于系統開發后續內容 的展開與實踐。任何實際活動都有經濟方面的條件限制，所以進行經濟可行性分 析是第一位的。從課題的背景和意義分析中足以看出，傳統的銀行業務管理方式 已無法適應當今社會發展需求，為了更好、更準確地表達系統管理者的意愿，本 項目系統將運用現有軟件和相關專業技術，查閱相關知識書籍，合理選擇低投入 成本的科學有效開發方法進行系統開發。本次銀行內部管理系統的開發目的并非 盈利，所使用的開發語言和開發工具、數據庫都是免費開源產品，初始的運行搭 載平臺就是個人計算機且對配置要求不高，無需額外配置。運行環境亦是開源免 費、采用的B/S模式開發成本較低，整個過程沒有額外的費用投入且幾乎無風險。 可以判斷實現銀行內部管理系統的經濟可行性情況良好，系統開發可行。
3.1.2操作可行性
全網用戶對計算機的操作水平不同，操作習慣不同，從用戶角度出發，銀行 管理系統要設計簡潔清晰的用戶界面、設置簡單的操作，方便管理員進行管理。 從管理員角度思考操作需求，系統需要通過網頁跳轉到管理登錄界面，進行賬號 信息驗證，登錄系統后臺進行操作管理。開發階段，為了更好的開發管理系統可 將整個系統劃分為多個模塊進行實現設計并進行優化銜接也便于修改維護。
課題研究主要是為了解決現實生活中的問題，我們可以通過發調查表、實際 情況考察、查閱與本待開發系統有關資料等方式進行市場調研，充分了解用戶， 得出市場最需要的理財產品管理系統功能，將這些功能整合為一個系統。確立系 統開發的方向，應對用戶需求的不穩定性。在此項分析過程中，要檢查系統應用 過程是否涉及法律法規例如專利法、著作權法以及用戶操作規程等方面的問題， 確保系統合乎法律。因此，系統操作方便，實用性強且符合法律規定和市場需求， 該系統的操作可行性方面可行。
3.1.3技術可行性
依據系統的需求和對經濟可行性的分析，可以找到技術先進性與技術成熟度 的平衡點，降低技術風險和所需要的成本。采取實用的技術手段與合理的技術解 決方案是必要的，結合個人對軟件設計實現相關技術及知識的了解，本課題將致 力于實現一個基于 J2EE 銀行內部理財平臺信息管理系統。運用課程中學到的 JAVA、MYSQL以及Apache、B/S架構知識著力實現目標系統。
由于對所采用的技術把握程度有限，出于對課題系統實現的尊重和嚴謹的態 度。在系統實現過程中將借助互聯網查找可用資源、學習他人的開發經驗，將各 種渠道的資源進行整合、加以運用。采用可靠的設計方法，多方采集可用信息盡 可能簡化系統設計流程，篩選和使用收集到的數據建立完善系統數據庫。基于對 課程的學習了解，選用較為熟悉的技術和軟件，依托于互聯網他人開發經驗與相 關知識的吸納，保證系統開發的技術可行性。通過三項可行性分析確定項目的規 模和目標，可初步建立系統的高層邏輯模型，基于收集到的信息推導出將要進行 實踐的開發方法和方案，最后撰寫可行性研究報告作為系統開發的文檔資料保 存。
3.2理財平臺信息管理系統需求分析
理財業務作為銀行業務轉型、收入結構調整的重要途徑，是最近各大商業銀 行著力發展的重點。現如今開發的銀行內部理財平臺信息管理系統具備的功能有 產品查詢、額度管理、報表管理、信息查詢四大模塊，主要是查詢產品信息，對 理財產品的售出信息形成報表、查詢相關信息、額度信息等，管理員在后臺系統 中了解理財產品的所有信息，熟悉理財產品，對該平臺的規劃和目標如下：
（一） 管理員可以在理財平臺信息管理系統內查看所有發布的理財產品，通 過理財產品的售出信息來及時掌握理財走向。
（二） 理財平臺信息管理系統在性能上則要準確，數據及時更新，保證管理 員及時掌握理財產品的相關信息。
（三） 理財平臺信息管理系統能夠根據管理員要求，分析出一份報表，使得 管理員能夠及時準確的分析信息。
（四） 管理員能夠查看所有的客戶信息，對客戶信息有詳細了解。并且能夠 根據客戶的身份證號碼查詢到客戶所有在行購買的理財產品記錄。
功能如下所示：
3.2.1理財產品查詢功能
理財產品查詢就是用戶在登錄系統后，根據一些查詢條件，系統會自動篩選 出符合條件的理財產品。用戶在查詢之后，界面會顯示出符合條件的產品信息， 方便了解每一種理財產品。用戶要查詢時需要輸入產品代碼、開始日期和結束日 期，日期跨度不應太大。查詢信息包括產品的價格、產品狀態、產品起始日、產 品終止日、預計最高收益率、計劃募集金額、實際募集金額、收益類型等信息。
3.2.2產品額度管理功能
產品額度查詢就是用戶能夠根據理財產品關鍵詞進行搜索查詢，系統會自動 篩選出符合條件的產品額度信息，系統界面會顯示出符合條件的產品信息，比如 產品天數、當期產品總額度、產品代碼、已售額度、剩余額度、當期產品銷售網 點等信息。
3.2.3系統報表管理功能
系統報表管理是用戶可通過輸入產品代碼、產品天數、客戶類別、交易渠道、 交易狀態、客戶名稱、客戶年齡、客戶電話、攬存員工、購買金額、購買時間、 產品起息日、產品到期日等模塊篩選出自己需要的信息并自動形成EXCEL報表。 方便用戶瀏覽。用戶還可以通過輸入產品銷售的起止日期導出網點某一時間段的 理財總銷量，形成網點理財產品銷售統計表。并在網點理財產品銷售臺賬可查詢 每期理財產品的客戶姓名、購買金額、理財資金賬號、購買日期、身份證號、聯 系方式等信息。
3.2.4系統信息查詢功能
系統信息查詢分為客戶查詢，客戶風險等級認證記錄查詢、銷售歸屬查詢、 募集期明細實時查詢、理財購買記錄查詢五種查詢方式。客戶查詢，輸入身份證 號碼可以查詢客戶信息。客戶風險等級認證記錄查詢，輸入身份證號碼可以查詢 客戶所有風險認證記錄、認證時間以及當前風險等級。銷售歸屬查詢，輸入產品 代碼可以查詢當前產品銷售網點、營銷網點、營銷人等信息。募集期明細實時查 詢，輸入產品代碼可實時查詢當前理財銷售情況，包括客戶姓名、賬號、申購日 期、申購網點等。理財購買記錄查詢，輸入身份證號碼可以查詢某一客戶在我行 所有理財購買記錄。
3.3系統非功能性需求分析
理財平臺信息管理系統開發目標主要有以下幾點：
1．支持特定的理財產品的管理：可以支持對特定理財產品的查詢，額度查 詢、查詢已發布產品、根據產品信息自動形成 EXCEL 報表„„能夠對產品進行有 效管理，并能夠做好與未來的長期理財平臺信息管理系統的建設，滿足用戶的管 理需求。
2．系統界面清晰，操作方便快捷，系統面對不同的用戶，操作界面盡可能
簡單、快捷，便于用戶熟悉系統，提高系統的利用率和用戶使用系統的效率。
銀行內部理財平臺信息管理系統的性能應該滿足如下要求： 系統數據準確性：系統要按照業務邏輯與數據要求執行，兩者之間不能存有 沖突，用戶的每一次操作后的結果要與選擇的參數保持一致。
系統安全性：確保系統數據庫里的數據不被其他非法人員修改，并保證數據 安全可靠。確保系統在規定時間內正常運行。
系統的可擴展性：銀行內部理財平臺信息管理系統的功能，采用了靈活的架 構和技術手段進行實現，當銀行內的業務發生其他需求時，業務實體的變化、系 統的變化等，系統就應提供良好的功能，完整的、易于使用的系統，這就為之后 的銀行內部理財平臺信息管理系統的升級做必要的準備。
系統兼容性：系統應該兼容各個平臺的操作系統，使得系統在各個操作系統 上都能流暢運行。
系統響應時間：系統查詢理財產品時，會有緩沖時間，但系統的響應時間不 應太長，應有較好的響應時間和系統反應速率。
第四章 銀行內部理財平臺信息管理系統設計
4.1銀行內部理財平臺信息管理系統設計原則
在設計銀行內部理財平臺信息管理系統的過程中，要考慮網站的使用者以及 管理者對網站操作的熟悉程度，這樣才能幫助企業管理人員更好的對網站進行操 作和管理［33］。其系統設計要遵循如下幾個原則：
（1） 實用性原則
在對系統進行設置的時候，一定要考慮系統的實用性，尤其考慮系統的操作者 對系統操作熟悉程度，是否按照實際需求完成，是否將用戶需求放在首位等等實 用性的具體操作。
（2） 界面友好性原則 銀行內部理財平臺信息管理系統的界面設計要符合當前的主流設計框架，在
PC端設計完成之后，能夠自適應移動端設備，保證系統界面在多個終端都有好的 客戶體驗。
（3） 簡單易用性原則 在設計銀行內部理財平臺信息管理系統的過程中，要考慮系統管理人員的基
本情況保證系統是否能夠簡單實用，尤其是管理者平時接觸信息化產品比較少， 在設計完成之后，要有對應的幫助文檔和系統提示，保證操作者對系統操作簡單 易懂。
（4） 安全性原則 系統性能方面首先需要考慮系統的安全性，尤其是類似于銀行業務管理網站
對數據要求比較高的系統來說，更是需要進行好好的控制，讓企業數據得到有效 的保護，降低企業因數據丟失而造成的損失。
4.2理財平臺信息管理系統整體設計
理財平臺信息管理系統按照結構模型進行構局，系統分為三層：客戶端、業 務層、數據層。業務處理的關鍵部分就是業務核心邏輯，它主要承擔任務的處理，
內容是多層面的，包括提供相關數據的處理，數據庫的訪問、后期的服務器請求 等；業務邏輯層：本層主要為具體的業務邏輯，與具體的理財管理業務相關聯， 包含了具體的業務流程控制等；數據層：數據訪問層為業務邏輯層或客戶端提供 數據服務。這種三層的構架模式不僅增強了代碼的可重用性，并且具有良好的靈 活性和可擴展性，使得系統更為安全。
根據銀行內部理財平臺信息管理需求分析得出該系統的核心模塊主要由理 財產品查詢、理財信息額度查詢、報表管理和產品信息查詢等組成，在報表管理 模塊當中由自定義交叉報表、產品銷售統計表和產品銷售臺賬等子模塊組成；在 信息查詢模塊當中由客戶查詢、客戶風險等級認證記錄、銷售歸屬查詢、募集明 細實時查詢和理財購買記錄查詢等子模塊組成，其理財平臺信息管理系統整體設 計圖如下圖所示：
理財平臺信息管理系統”
圖 4-1 理財平臺信息管理系統整體結構圖
4.3理財平臺信息管理系統詳細設計
4.3.1產品查詢管理功能設計
產品查詢設計主要是方便管理員對理財產品進行查詢。在設計過程中會設計 不同的查詢條件，不同的查詢條件是針對理財產品本身進行，依據理財產品自身 特點進行設計，這樣可以保證管理員可以隨時隨地更加方便地查看理財產品的信 心，使得管理員可以更好地掌握理財產品的資料，方便銀行內部進行操作和查詢。
圖 4-2 產品查詢管理功能時序圖
4.3.2產品額度管理功能設計
理財產品額度管理主要對理財產品的額度設置和查詢功能，在理財產品額度 管理上面首先對不同產品的理財額度進行設置。系統在需求設計之前已經對不同 理財產品的額度做了設置，設置額度完成之后，對可以對理財產品不同額度進行 查詢，產品額度管理功能設計支持理財產品下的所有子產品共享理財產品的額度 設置，遵照發行行額度的設定文件、發行機構額度的設定、產品的額度查詢。在 管理員操作產品額度查詢的時候可以通過輸入理財產品代碼查詢當期產品總額 度、已售額度、剩余額度等。
圖 4-3 產品額度管理功能時序圖
4.3.3系統報表管理功能設計
系統報表管理功能的設計目的主要是為了讓管理員盡可以的根據需要的相 關信息進行自定義，比如理財產品的產品代碼、理財產品期限、產品額度和客戶 類別等子模塊進行篩選，然后由篩選出的數據信息形成相應的EXCEL報表。在 該模塊的功能設計上面主要由自定義交叉列表、網點理財產品銷售統計報表和網 點理財產品銷售臺賬子模塊組成。在自定義交叉報表模塊當中管理員可通過選擇 產品代碼、產品天數、客戶類別、交易渠道、交易狀態、客戶名稱、客戶年齡、 客戶電話、攬存員工、購買金額、購買時間、產品起息日、產品到期日等模塊篩 選出自己需要的信息并自動形成EXCEL報表；在網點理財產品銷售統計表模塊 當中管理員可以通過輸入產品銷售的起止日期導出網點某一時間段的理財總銷 量，以及不同類別下的理財銷售信息報表，在形成報表當中可以看到這一時間段 的產品下的銷售信息；在網點理財產品銷售臺賬模塊中管理員可查詢每期理財產 品的客戶姓名、購買金額、理財資金賬號、購買日期、身份證號、聯系方式等信 息。
圖 4-4 系統報表管理功能時序圖
4.3.4系統信息查詢功能設計
系統信息查詢功能模塊的設計其中主要包括以下子模塊：客戶查詢、客戶風 險等級認證記錄、銷售歸屬查詢、募集期明細實時查詢和理財購買記錄查詢組成， 在這些子模塊當中有不同的功能。在客戶信息查詢方面管理員輸入客戶的身份證 號碼對客戶進行查詢，同時可以輸入產品代號或者客戶的姓名進行關聯查詢；在 客戶風險等級認證記錄模塊當中首先進行查詢客戶信息，此次輸入客戶身份證號 碼進行查詢客戶所有風險認證記錄、認證時間以及當前風險等級等風險相關信 息；在銷售歸屬查詢模塊當中銀行對理財產品發行，然后由發行行分配到下屬銷 售網點進行銷售，基于該功能對其銷售歸屬信息進行查詢，在查詢的過程中輸入 產品代碼可以查詢當期產品銷售網點、營銷網點、營銷人等信息；在募集期明細 實時查詢模塊當中管理員輸入產品代碼可實時查詢當前理財銷售情況，包括客戶 姓名、賬號、申購日期、申購網點等查詢信息；在理財購買記錄查詢上管理員輸 入身份證號碼可以查詢某一客戶在我行所有理財購買記錄。
骨理員 客戶杳徇 霽八陽鴿幼認illiJ錄 銷害歸屬杳詢 斡掘期明 1細實時杳詢 理財購實記錄杳詢
份證號 I
返対認證記錄 I I I
I | 心川打y ； | I
1 i i i 1
| 返回IN屆地 |
I I 廬《Wi代碼 ! I I
fl i ■ ■ :
I I 理歲鑰偉信息 t I
I I \ 客戶身份證號~\ I
1 ! i ； f
, I I ';心5/」「心譏］ I
圖 4-5 系統報表管理功能時序圖
4.4數據庫設計
4.4.1數據庫概念模型設計
數據庫的概念模型其核心理念就是將世界當中的實體模型和系統以及軟件 轉變成數據庫模型的過程，該模型是基于用戶的視角進行觀察和查詢，并且在實 際應用當中可以查看系統數據的約束以及處理的需求，根據用戶實際需要最后來 生產一個反映用戶觀點的概念模型。目前，從需求到實際需要的數據庫，主要分 為三種類型。其中，用于數據信息系統的數據模型是一個概念性的數據庫模型， 本質上主要是記錄相關的數據的一些技術規范。數據首先是用于討論使用者的最 開始的需求，然后在進行分析處理成為一個邏輯數據模型，其邏輯數據模型可以 基于數據庫中的數據結構概念模型實現。總體來說一個概念模型的實現需要一個 或者多個邏輯數據模型組成。而在建立數據庫建模的最后一個步驟那就是邏輯數 據模型到物流模型中到整個訪問過程的性能和存儲的實際需要。數據庫建模的定 義不單單是針對期中的數據元素，也包括它們內部的結構以及結構之間的相互關 系。數據庫在建模的實際過程中需要進行不同階段的準備工作，其主要活動如下： 數據的實際要求以及它們之間的相關關系，實現的過程；在實際的要求當中需要
對數據進行定義包括數據類型、數據的存儲要求以及是否設置相應的默認值；針 對系統的實際要求要確保數據的有效性以及完整性，針對系統的業務流程以及要 求，檢測數據正確性；根據實際要求，定義數據時要確保數據的檢測以及備份工 作；最終選擇數據存儲技術，根據業務邏輯的實際需要選了其存儲技術，主要包 括關系、分層和索引等數據存儲技術［28］。
銀行內部理財平臺信息管理系統根據系統的需求分析得出系統的數據流程 圖和針對系統所需要的數據庫以及數據庫表之間的關系，然后系統數據進一步抽 象得出系統的全部視圖設計，由抽象數據以及數據模型下的數據之間關系得出系 統數據的 E-R 圖，其次根據系統的局部 E-R 圖進一步集成最終設局出基于系統 的全局 E-R 圖，最后得出系統的邏輯結構模型，根據數據庫的邏輯結構模型可 以看出數據庫下面各個表之間的關系。得出數據表之后，有了數據表的數據項和 數據結構之后，就可以設計出符合系統需求的實體，以及實體之間存在的關系， 這樣為后續的邏輯結構設計打下基礎。基于這些實體就可以得出模塊之間的數據 信息，以及之間的相互作用形成系統模塊下的數據流動。基于系統需求可以知道 實體主要包括：產品信息類、產品額度類、客戶信息類等實體。其系統概念模型 的執行流程如下圖所示：
需求分析 : :寸 DFD, DD
邏輯結構設計
圖 4-5 系統概念模型的執行流程圖
4.4.2E-R 圖設計
E-R 圖又叫做實體-聯系圖，它提供了表示實體類型、屬性和聯系的方法，是 用來描述現實世界的概念模型。銀行內部理財平臺信息管理系統將用 E-R 圖來展 現數據庫里聯系模式。在系統前期的需求分析當中得出系統的數據庫各個表的關 系。在E-R圖設計當中主要由以下實體組成：理財產品信息、理財產品額度、風
險等級認證記錄、系統客戶和募集期明細實體，在對應的實體當中有對應的屬性
圖 4-6 系統 E-R 圖
4.4.3數據庫表設計
理財平臺信息管理系統的所有數據信息要求存儲在本地數據庫服務器當中， 基于系統的特殊性其數據庫主體設計思想就是數據安全與權限管理，基于管理系 統要求該系統也是選擇了的MYSQL數據庫，該數據庫屬于典型的關系型數據庫 管理系統，因為銀行數據信息需要具有數據結構化、獨立性以及最低冗余度等要 求，其MYSQL都符合系統要求,并且該數據庫管理系統輕量級容易擴充和維護。 數據庫中的表是一種二維關系，在表內兩行的數據不能夠完全相同，即不能重復。 在這種關系型數據庫中，每一條記錄都有一個唯一的標識，一條記錄代表數據庫 表中的一行，數據庫的使用對于系統而言相當重要，所以要對數據庫加以規范， 讓數據庫的設計更加合理，更為可靠。為了能夠使理財平臺信息管理系統可靠的
運行，在建立表時將按照現在的相關關系型數據庫的理論進行創建。 以下是系統
對應一些表的創建：
1．理財產品信息表就是記錄產品的狀態 、代碼等詳細信息。如下表所示：
表 4-1 理財產品信息表
名稱 類型 長度 小數點 是否為空 是否主鍵
id varchar 20 0 否 是
Product code varchar 255 0 否 否
Product status varchar 255 0 是 否
Product Series varchar 255 0 是 否
Planned collection amount decimal 10 0 是 否
Actual collection decimal 10 0 是 否
Start day date 0 0 是 否
End day date 0 0 是 否
Product start day date 0 0 是 否
Product end day date 0 0 是 否
Expected rate varchar 255 0 是 否
2．客戶信息表就是記錄客戶的姓名、身份證號、年齡、聯系方式、購買日 期、客戶類別等詳細信息。如下表所示：
表 4-2 客戶信息表
名稱 類型 長度 小數點 是否為空 是否主鍵
id varchar 20 0 否 是
Name varchar 255 0 是 否
IDCard varchar 255 0 是 否
Age int 255 0 是 否
Phone varchar 255 0 是 否
Purchase amount decimal 10 0 是 否
Financial account number int 11 0 是 否
Date of purchase datetime 0 0 是 否
Product code varchar 255 0 是 否
Client category varchar 255 0 是 否
3．理財額度信息表就是記錄當期理財產品的已售額度、剩余額度、營銷人、 營銷網點等詳細信息。如下表所示：
表 4-3 理財額度信息表
名稱 類型 長度 小數點 是否為空 是否主鍵
id varchar 20 0 否 是
Product code varchar 255 0 是 否
Total product line decimal 10 0 是 否
Already sold line decimal 10 0 是 否
Surplus amount decimal 10 0 是 否
Sales outlets varchar 255 0 是 否
Marketing network varchar 255 0 是 否
Marketing person varchar 255 0 是 否
Product days int 11 0 是 否
4．風險等級認證記錄表就是記錄當前風險等級、認證時間、客戶身份證號 等詳細信息。如下表所示：
表 4-4 風險等級認證記錄表
名稱 類型 長度 小數點 是否為空 是否主鍵
id varchar 20 0 否 是
IDCard varchar 255 0 是 否
Risk certification varchar 255 0 是 否
Authentication time date 0 0 是 否
Current risk level varchar 255 0 是 否
5.募集期明細表就是記錄客戶姓名、 申購網點、 賬號等詳細信息。如下表
所示：
表 4-5 募集期明細表
名稱 類型 長度 小數點 是否為空 是否主鍵
id varchar 20 0 否 是
Name varchar 255 0 是 否
Product Code varchar 255 0 是 否
Account number int 11 0 是 否
Date of requisition datetime 0 0 是 否
Marketing outlets varchar 255 0 是 否
第五章 銀行內部理財平臺信息管理系統實現
5.1理財產品查詢功能實現
用戶進入系統之后，點擊理財產品查詢按鈕，系統會跳轉到理財產品查詢功 能的界面，用戶就可以查詢到銀行已發布的所有理財產品，并可以通過選擇產品 代碼、產品系列、產品狀態、收益類型四個模塊進行精確篩選。用戶輸入所要查 詢的條件后，點擊查詢按鈕，系統會自動根據用戶輸入的條件，連接到數據庫后， 從數據庫里篩選出符合條件的每條記錄，然后系統會把這些記錄以表格的形式顯 示到界面上，用戶便可以查看到所有的符合條件的產品信息。
圖5-1理財產品查詢功能實現頁面
5.2產品額度管理功能實現
用戶進入系統后，點擊產品額度管理按鈕之后，系統會自動跳轉到額度管理 的界面，用戶可以通過輸入產品代碼查詢當前產品總額度、已售額度、剩余額度 等信息。輸入之后點擊查詢按鈕，系統會調取數據庫的代碼，到數據庫內查找符 合條件的記錄，并通過系統內的代碼顯示到產品額度的界面上，用戶便可以查看 當期產品的額度。
2J
M 1 1 頁 .3 50*煩 v
豊錄用P：
題 I 廠廠廠廠陽 Moos "公
&|(5 e：so
圖5-2理財額度管理功能實現頁面
5.3系統報表管理功能實現
5.3.1 自定義交叉報表功能
用戶點擊報表管理后，系統會顯示自定義交叉報表、網點理財產品銷售統計 表、網點理財產品銷售臺賬三種報表形式。用戶點擊自定義交叉報表后，系統會 自動跳轉到自定義交叉報表的界面，用戶需要選擇產品代碼、產品天數、客戶類 別、交易渠道、交易狀態、客戶名稱、客戶年齡、客戶電話、攬存員工、購買金 額、購買時間、產品起息日、產品到期日等模塊篩選出自己需要的信息，選擇之 后，點擊確定，系統會根據用戶選擇進行下一步操作然后自動形成EXCEL報表。
該模塊在實現的過程中需要查看用戶點擊報表管理之后，系統會顯示自定義 交叉報表相關信息、網點理財產品銷售統計信息和網點理財產品銷售臺賬三種核 心報表形式顯示出來。在用戶點擊自定義交叉報表之后，系統會根據用戶觸發的 點擊事件進行自動跳轉到自定義交叉報表的界面當中，此時會看到該界面下的產 品代碼、產品天數、客戶類別、交易渠道、交易狀態、客戶名稱、客戶年齡、客 戶電話、攬存員工、購買金額、購買時間、產品起息日、產品到期日等屬性組成， 這些屬性將會存儲在數據庫的產品信息表當中。在實現的過程中會根據用戶信息 表的關聯進行讀取數據，基于J2EE的MVC三層編程原理，在業務邏輯層當中讀 取該報表數據下的基礎數據信息。數據信息讀取之后使用預編寫好的成句對數據
格式進行整理，這樣才可以滿足將數據信息以 EXCEL 表格的形式存儲，格式整理 完成之后針對用戶篩選的屬性值進行確認，然后由對應的屬性值作為查詢條件。
5.3.2網點理財產品銷售統計表
在網點理財產品銷售統計表模塊實現的過程當中，用戶進入該系統點擊報表 管理之后，可以看到網點理財產品銷售統計表模塊按鈕，此時點擊該按鈕系統就 會跳轉到對應的頁面當中。此時在該模塊的實現開發過程中預先實現了基于不同 條件的查詢，在使用該系統的時候，用戶可以對不同理財產品的銷售日期進行選 擇。此時的條件查詢是針對理財產品的銷售日期作為判斷條件，其實現原理就是 根據數據庫對應的理財產品銷售信息表當中獲取銷售日期，然后判斷用戶選擇的 起始和結束日期作為條件，然后查詢出對應的結果顯示到頁面當中。其整個理財 產品的查詢結果都是基于數據庫數據表信息進行查詢，然后得出在某一時間段的 理財總銷量，最后通過系統內部的代碼把銷量以表格的形式顯示到對應的界面當 中，從而根據預先開發的設計規則將查詢出的數據保存到對應的報表當中。
圖5-4網點理財產品銷售統計表功能實現頁面
5.3.3網點理財產品銷售臺賬
在網店理財產品銷售臺賬目模塊的實現當中，管理員用戶點擊報表管理之 后，然后從中選擇網點理財產品銷售臺賬按鈕，系統會自動跳轉到網點理財產品 銷售臺賬管理界面，用戶便能夠在此查詢每期理財產品的客戶姓名、購買金額、 理財資金賬號、購買日期、身份證號、聯系方式等信息。系統會根據理財產品的 名稱，連接到數據庫中，在數據庫里查詢到符合用戶輸入的信息，然后調取信息 到界面上。在實現的過程當中可與根據客戶的姓名、理財產品進行查詢相關的信 息。此時，在程序設計的時候基于產品名稱條件查詢信息之后，將其每期理財產 品的客戶姓名、購買金額等信息設置到查詢程序當中，然后根據匹配條件進行查 詢到對應的頁面當中。
圖5-5網點理財產品銷售臺功能實現頁面
5.4系統信息查詢功能實現
5.4.1 客戶信息查詢
用戶點擊信息查詢后，然后點擊客戶查詢，系統會自動跳轉到該頁面，用戶 在輸入身份證號之后，系統會把輸入的信息傳到數據庫中，在數據庫里根據輸入 的身份證號查詢到符合要求的客戶信息，系統調取到客戶的所有信息顯示到界面 上。其實現過程基于查詢的方式進行對數據表進行精準匹配查詢，基于MVC編程 方式，針對特定用戶輸入的特定查詢條件，執行數據查詢程序然后反饋到系統視 圖當中顯示到頁面當中，對于客戶的基本信息進行維護。同事，為了更好地對客 戶的進行管理，系統實現了一鍵存儲客戶信息功能這樣可以很好地保證系統管理 員對于大量客戶信息進行備份、更新和管理。
圖5-6客戶信息查詢功能實現頁面
5.4.2客戶風險等級紀錄
客戶風險等級是根據客戶綜合信息進行評判和跟蹤，評判是根據客戶之前的 金融信用積累信息進行綜合評定，在評定過程中根據銀行客戶風險等級評定細則 進行認定，跟蹤是長時間針對金融信用進行持續跟蹤，查看之后的某一個時間段 該客戶是否處于風險時期，進行對客戶進行標定。之后根據綜合評估信息進行評 判用戶的風險等級，將其風險等級記錄數據存儲在數據表當中，作為時刻更新和 保存風險等級數據信息的存儲媒介，用于之后銀行內部進行對客戶查詢和判斷， 用戶點擊信息查詢后，然后點擊客戶風險等級認證記錄按鈕，系統會自動跳轉到 該界面，用戶則要輸入客戶的身份證號，系統會把輸入的身份證號傳到數據庫中， 在數據庫查詢到符合要求的客戶的等級認證記錄，然后把客戶所有風險記錄、認 證時間以及當前風險記錄顯示到界面上。
essfflp： esHiHii 東js支行
iESTSSUt htt; //62 64 0 TI/nai>s/ext/r«saurcsE/inac«s/lafault/cri<Vli>adicis <if.. 詰 0 IntorMl J ” MOO* -:
歳開劃倉® 1瞬酬平臺信理耒. 昭8 -畫圖 | 刨◎ 0：52
圖5-7客戶風險等級記錄功能實現頁面
5.4.3銷售歸屬查詢
用戶點擊信息查詢后，然后點擊銷售歸屬查詢按鈕，系統會自動跳轉到該界 面，用戶則需要輸入產品代碼，系統會根據用戶輸入的產品代碼傳到數據庫中， 此時產品代碼在數據庫產品表當中，進行基于產品代碼查詢的時候是唯一性，幫 助產品可以實現更好的查詢。根據系統所編寫的代碼，在數據庫內查詢符合產品 代碼的相關信息，然后根據用戶需求，把當期產品銷售網點、營銷網點、營銷人 等信息顯示到界面上。管理員在對銷售信息進行歸屬查詢結果完成之后，將其查 詢結果存儲早本地的文檔當中，方便銀行內部人員查詢。
圖5-8銷售歸屬查詢功能實現頁面
5.4.4募集期明細實時查詢
用戶點擊信息查詢后，然后點擊募集期明細實時查詢按鈕，系統會自動跳轉 募集期明細實時查詢界面，根據理財產品特點此時在設置查詢條件的時候以理財 產品代碼為查詢條件。理財產品信息保存到數據庫理財產品數據表當中，根據數 據表當基本信息將其查詢出理財產品相關的屬性信息一塊查詢到頁面當中。在實 現的完成之后，系統管理員則需要輸入產品代碼，系統會根據用戶輸入的產品代 碼傳到數據庫中，系統會根據用戶輸入的產品代碼在數據庫內找到符合要求的信 息，系統內部代碼會把提取出的客戶姓名、賬號、申購日期、申購網點等顯示到 界面上。同時，根據查詢的數據可以保存到對應的本地文檔當中，方便以后對該 數據的使用。
圖5-9募集期明細實時查詢功能實現頁面
5.4.5理財購買記錄查詢
用戶點擊信息查詢后，然后點擊理財購買記錄查詢按鈕，系統會自動跳轉到 該界面，在理財購買記錄信息查詢的時候需要考慮到唯一識別的信息，由于理財 產品的信息特殊性必須進行實名制購買，所以為了唯一識別的信息在對購買記錄 查詢的時候將用戶的身份證號作為判斷條件，然后根據購買數據表的信息進行查 詢出來。在系統實際查詢的過程中此時管理員則需要輸入身份證號碼來搜索到客 戶在此銀行所有理財購買記錄，系統根據用戶輸入的身份證號碼到數據庫內查詢
到所有理財購買記錄，然后根據系統內部的代碼把查詢到的客戶所有理財購買記 錄顯示到界面上。
St錄用P：膠州膠州來路支行
|hUp://62.M.0.71/»w«/» 1 b Q Int«rn«l
”開貽1 e』 le理財平臺信息管理系.—m H -函圖 I 8:54
圖5-10理財購買記錄查詢功能實現頁面
第六章 系統測試
6.1系統功能測試
在軟件測試中主要的思想就是發現系統軟件當中的錯誤信息，在測試過程中 需要形成測試文檔，然后把測試文檔反饋給系統的實際開發人員，開發人員根據 文檔當中的錯誤信息對軟件系統進行修復，最終保證系統完整性和穩定性的過 程。
根據現代軟件工程學的基本原理，在不同階段對系統進行測試劃分，可以把 軟件系統測試分為單元測試、集成測試、系統測試和驗收測試。單元測試：由于 目前大部分軟件系統都是分模塊進行開發實現，此時的下料系統也是一樣按照不 同模塊進行開發和實現，確保每個模塊都可以按照軟件需求說明順利運行；集成 測試：對已經進行單元測試的模塊通過測試之后進行組裝起來，進行集成測試， 主要查看軟件設計的相關程序結構問題；確認測試：在進行完成單元測試和集成 測試之后，開發人員已經對之前的BUG進行修復，然后檢測整個系統軟件是否滿 足所有功能和性能；系統測試：這個過程主要是測試設計實現出來的軟件系統產 品是否能夠與其他部門進行兼容協調工作起來，主要是和硬件、數據庫和設備軟 件等結合起來；驗收測試：該階段就是針對用戶操作，結果就是讓真實的用戶對 系統進行使用查看是否出現問題，其中包括系統的功能和性能，以及是否按照軟 件需求說明書規定開發的結果［34-35］。其實無論哪個階段都需要分為兩種測試方 式,即白盒測試和黑盒測試。白盒測試主要是針對系統程序內部結構，而黑盒測 試主要是針對系統的功能進行測試，測試功能是否有問題。
銀行內部理財平臺信息管理系統的設計與實現使用的檢測方式是黑盒測試， 檢驗本次設計的銀行內部理財平臺信息管理系統的設計與實現的核心功能，測試 的內容包括該系統所有功能是否可以順利運行和使用，整個項目的測試流程如圖 6-1所示：
圖 6-1 測試流程
銀行內部理財平臺信息管理系統進行軟件測試要求必須結合需求說明書，將 滿足功能的測試需求全部標識，再按照軟件測試的步驟，逐一檢測到。測試系統 軟件步驟的主要環節有單元、集成、系統、驗收四個部分，其具體內容包括了對 銀行內部理財平臺信息管理系統的設計與實現界面、系統功能、性能測試、安裝 測試、安全性測試等。
功能測試對于管理員來說是極其重要的環節，管理員掌握行內所有的理財產 品，比如信息查詢，客戶查詢，額度查詢等基本功能都必須順暢無誤運行，系統 所對應的信息要和數據庫保持一致，數據庫內的數據不能出現錯誤。數據庫的測 試是為了保證數據的一致性，并對數據的存儲、輸出的正確性進行測試，在功能 測試中有黑盒測試和白盒測試兩個主要的測試方式。白盒測試是根據系統的內部 邏輯結構來設計測試用例，黑盒測試是基于系統的功能來設計測試用例。本文采 用了這兩種測試方式進行，進而保證系統功能的無誤完整性。如下表測試用例所
示:
表 6-1 銀行內部理財平臺信息管理系統功能測試用例表
模版業務 測試目的 模擬用戶行為 預期結果 實際結果
登錄 實現用戶 登錄理財 平臺信息 管理系統 進入登錄界面，輸入 正確的用戶名和密碼 進行登錄 登錄成功 登錄成功
已發布產品查 詢 實現用戶 對自己發 布的產品 進行查詢 輸入產品代碼，選擇 產品系列、產品狀態： 待售，收益類型：保 證收益型、進行查詢 顯示出該條詳細信 息 查詢成功
額度查詢 查詢出自
己的額度 輸入產品代碼，點擊 查詢按鈕 顯示出該產品的分
配總額度，可用額 度，已暫用額度，當 前級分配總額度 與預期結果一 致
網點理財產品
銷售統計表 導岀網站 理財產品 的銷售統 計表 輸入產品代碼，選擇 產品階段，選擇查詢 起止日期和結束日期 導出理財產品統計
表（分期次） 與預期結果一 致
網點理財產品 銷售臺賬 查詢岀所 有的銷售 臺賬表 點擊網點理財產品銷 售臺賬 顯示出所有的銷售
臺賬表 與預期結果一
致
客戶查詢 顯示岀要 查詢的客 戶信息 輸入證件號碼，點擊 查詢 查詢出該證件號的 詳細信息 與預期結果一
致
客戶風險等級 認證記錄 顯示岀所 有用戶信 息 點擊客戶風險等級認 證記錄 查詢出客戶證件號、 客戶姓名、本次認證 客戶等級風險、上次 認證客戶等級風險、 風險認證時間、操作 員姓名、終端號 與預期結果一
致
銷售歸屬查詢 查詢岀銷 售歸屬 輸入產品代碼，點擊 查詢 顯示出賬號、客戶名 稱、中購日期、中購 金額、銷售網點、歸 屬網點、銷售渠道、 營銷人等詳細信息 與預期結果一
致
募集期明細實
時查詢 查詢岀募
集期明細 輸入產品代碼，點擊 查詢 顯示出賬號、戶名、 中購網點、日期、聯 系方式、金額等詳細 信息 與預期結果一
致
理財購買記錄 查詢 查詢岀購 買理財產 品的記錄 輸入證件號碼、選擇 產品狀態、起始日期 和終止日期 顯示出該用戶所有 理財產品的詳細信
息 與預期結果一
致
6.2系統性能測試
系統性能測試對于系統正式投入運行之前非常重要，用戶登錄系統后，需要 通過系統和數據庫之間的聯系進行操作，但當一個特定的時間段有大量的產品信 息需要顯示到界面，對數據庫和系統的要求就會變高說。系統要根據用戶需要查 詢的信息在數據庫內進行篩選，需要處理大量的數據，這時候性能測試就可以避 免在正式投入使用時所面臨的系統癱瘓，網絡連接不順暢。系統性能測試的目的 就是讓系統在特定的條件下能夠正常運行，并且滿足我們所需要的條件，在測試 過程中，找出系統的不足，了解到系統容易出錯的地方，如果系統的信息發生混 亂或者負載，能夠保證數據恢復并且不丟失。
性能測試具有運用測試清單檢測銀行內部理財平臺信息管理系統的性能的 重要功能，檢驗該系統的性能與設計整體過程需求是否符合。在檢測銀行內部理 財平臺信息管理系統當中性能測試在意義十分重要，它負責測試的環節可以分為 銀行內部理財平臺信息管理系統的性能、強度、頻次也即負載等內容，具體環節 包括了負載測試、登錄速度測試、預期性能指標測試和用戶性能測試等［37-39］。業 務支撐系統性能測試可以按照該系統的響應時間、處理速度等要求從多個方面對 系統進行評價，設計出來的銀行內部理財平臺信息管理系統應與性能測試用例一 致,并達到測試要求［40］。測試銀行內部理財平臺信息管理系統性能的時候找到的 系統問題，需要按照當前的具體情況被劃分成銀行內部理財平臺信息管理系統缺 陷并記錄。
不同的系統所使用的測試標準也會不一樣，本次設計的銀行內部理財平臺信 息管理系統的檢測性能的標準是在一個時間段內能夠登錄并在網的總用戶數，按 照在線用戶數的總容量,核定測試用例的人數，并對測試用例的在線人數所處的 網絡速度測試，并評估，以免在線人數突增的緊急狀況下，服務器的負荷太大 ［41-42］
第七章 總結與展望
7.1總結
本文研究的銀行內部理財平臺信息管理系統的設計與實現，從軟件工程的角 度出發，首先介紹了銀行內部理財平臺信息管理系統的選題背景、意義、國內外 研究現狀、主要研究目標與內容以及本文的組織結構。接著主要講解了銀行內部 理財平臺信息管理系統所使用的技術，以及系統架構等，在開發時使用了 J2EE 技術、MYSQL數據庫以及B/S架構，系統的架構主要分為三層，分別為客戶端、 業務層、數據層。還進行了需求分析，從經濟、操作、技術上進行可行性分析。 然后進行了設計分析、系統測試。系統每個部分被分成了好幾個模塊，包括有產 品查詢、額度查詢、自定義交叉報表、網點理財產品銷售統計表、網點理財產品 銷售臺賬、客戶查詢、客戶風險等級認證記錄查詢、銷售歸屬查詢、募集期明細 實時查詢、理財購買記錄查詢模塊，本文對這些模塊進行了詳細描述和實現。
本文實現的銀行內部理財平臺信息管理系統大大提高了銀行內的資源利用 率，節省了大量的人力財力。為銀行以后的發展打下了堅實的基礎。
7.2展望
本文在研究過程中還存在很多不足，對現如今的計算機技術掌握的還不夠熟 練，所涉及到的部分也不完全。計算機技術是以后很多行業的主要方向，在后續 工作中，我會不斷地學習系統所需要的知識，更為熟練地使用系統架構，對系統 功能實現進行完善。使系統更加貼合實際要求，在用戶操作的時候，加入更多的 提示，降低用戶使用系統的難度。提高系統處理數據的速度，使得用戶操作更加 流暢。
參考文獻
[1]路星馳.銀行理財產品管理系統的設計[J].電腦知識與技術，2016, 12(34):104-107.
[2]張帥.我國商業銀行理財產品風險管理研究[D].財政部財政科學研究所，2012.
[3]陳繼紅，鄭振歐.香港銀行業個人理財服務發展的背景及內容比較[J].金融論壇， 2003, 8(11):46-50.
[4]詹晶.商業銀行理財產品綜合評價指標體系研究[J].現代商貿工業， 2012(12):98-100.
[5]農衛東.財富客戶銀行理財產品購買行為研究一基于建設銀行客戶關系管理系統(0CRM) 的應用分析[D].西南交通大學，2016.
[6]謝立英.基金及各類理財產品銷售管理系統[J].中國信用卡，2005(4):51-55.
[7]黃琮翔.關于加強商業銀行理財產品基礎資產投后管理的思考[J].時代金融， 2014(32):263-263.
[8]孫永.徽商銀行理財產品銷售管理系統設計與實現[D].大連理工大學,2016.
[9]路璐.基于J2EE的銀行營銷客戶管理系統的設計與實現[D].南開大學，2015.
[10]呂哲堯.某商業銀行銷售信息管理系統的設計與實現[J]. 2014.
[11]王積田，徐妍，王虹.我國商業銀行理財產品發展現狀及SWOT分析[J].中國經貿導 刊，2012(10):55-56.
[12]劉振蓮.銀行VIP客戶管理信息系統的設計與實現[D].吉林大學，2014.
[13]ClauBen A, Lohr S, Rosch D. An analytical approach for systematic risk sensitivity of structured finance products[J]. Review of Derivatives Research, 2014, 17(1):1-37.
[14]Das S R, Statman M. Options and structured products in behavioral portfolios[J]. Journal of Economic Dynamics & Control, 2013, 37(1):137-153.
[15]Deng G Guedj I, Mccann C J, et al. The Anatomy of Principal Protected Absolute Return Notes[J]. Social Science Electronic Publishing, 2012, 19(2):61-70.
[16]Dobeli B, Vanini P Stated and revealed investment decisions concerning retail structured products[J]. Journal of Banking & Finance, 2010, 34(6):1400-1411.
[17]Chen F Y. A Comparative Study of VaR Estimation for Structured Products[J]. Economics Research International, 2010, 2010(4).
[18]Fisher C, Malde S. Moral imagination or heuristic toolbox? Events and the risk assessment of structured 行nancial products in the financial bubble[J]. Business Ethics A European Review, 2011, 20(2):148-15 &
[19]Glasserman P, Heidelberger P, Shahabuddin P Variance Reduction Techniques for Estimating Value-at-Risk[J]. Management Science, 2000, 46(10):1349-1364.
[20]He P Option Portfolio Value at Risk Using Monte Carlo Simulation Under a Risk Neutral Stochastic Implied Volatility Model[J]. Global Journal of Business Research, 2012, 6.
[21]Hitting the right structured note[J]. Chartered Accountants Journal, 2012.
[22]Kalyvas L, Dritsakis N, Siriopoulos C, et al. Selecting Value-at-Risk methods according to their hidden characteristics[J]. Operational Research, 2004, 4(2):167.
[23]Wang R, Fan Z, Ma H, et al. Study on enterprise price risk management system[C]〃 International Conference on Educational & Network Technology. 2010.
[24]Larose D T. Discovering Knowledge in Data: An Introduction to Data Mining[M].
Wiley-Interscience, 2004.
[25]Witten I H, Frank E. Data mining: practical machine learning tools and techniques with Java implementations^]// Morgan Kaufmann Publishers Inc. 2000.
[26]Nisbet R, Nisbet R, Nisbet R. Handbook of Statistical Analysis and Data Mining Applications[M]〃 Handbook of statistical analysis and data mining applications. Academic Press/Elsevier, 2009:733-754.
[27]Han J. Data Mining: Concepts and Techniques[M]. Morgan Kaufmann Publishers Inc. 2005.
[28]Verhoef P C, Donkers B. Predicting customer potential value an application in the insurance industry[J]. Decision Support Systems, 2001, 32(2):189-199.
[29]Jonathan Fox, Suzanne Bartholomae, Jinkook Lee. Building the case for financial education[J]. The Journal of Consumer Affairs, 2005, 39(1):195-214.
[30]吳晨清，榮震華.用JSP/Servlet技術構建Web應用[J].計算機工程,2001, 27(1):170-172.
[31]林珠，李海威，楊柏藹.基于云存儲與J2EE架構的信息系統設計及應用[J].計算機 技術與發展，2017, 27(10):177-180.
[32]Mcgovern J, Tyagi S, Stevens M E, et al. Java Web Services Architecture[J]. 2003.
[33]Armstrong E. The Java Web services tutorial[M]// The Java Web services tutorial =. Higher Education Press, 2003:958-961.
[34]Snoep J L, Olivier B G Java Web Simulation (JWS); a web based database of kinetic models[J]. Molecular Biology Reports, 2002, 29(1-2):259-263.
[35]趙永屹，宿紅毅，胡韶輝.基于AJAX與J2EE的新型Web應用的設計與實現[J].計算 機工程與設計，2007, 28(1):189-192.
[36]王強兵，劉廣鐘.基于J2EE的Web企業計算[J].計算機工程，2002, 28(1):262-264.
[37]Nagappan R. Core Security Patterns: Best Practices and Strategies for J2EE, Web Services, and Identity Management[M]. 2005.
[38]謝學智，王璃屏，談鑒鋒，等.不可信系統平臺下的敏感信息管理系統[J].清華大學 學報：自然科學版，2015(11):1221-122&
[39]孫莉，李樹剛，陶瑩，等.基于B/S模式的質量信息管理系統設計與實現[J].上海交 通大學學報，2010(s1):175-177.
[40]王哲，田東林，黃平.基于Arc/Inf。軟件平臺的城鎮地籍管理信息系統設計[J].測 繪通報，2006, 2006(4):68-71.
[41]王宜峰，孫雨堯，蔣一琛.基于傅里葉變換的銀行觸發性理財產品定價[J].系統科 學與數學，2018, 38(2):236-246.
[42]郭云嫣，劉全海，冉慧敏.時空信息云平臺下數據管理及可視化方法[J].測繪科學， 2016, 41(10):100-105.
下一篇：沒有了
相關標簽:
