1. 一個資料庫設計問題
顧客(姓名,地址,電話,身份證號,客戶號,顧客狀態,申請時間,開戶行),主鍵為客戶號
帳戶信息(客戶號,銀行帳號,身份證號,余額,交易次數,帳戶狀態,開戶時間)，主鍵為銀行帳號,外鍵為客戶號
交易記錄(流水號,銀行帳號,交易金額,交易時間)，主鍵為流水號,外鍵為銀行帳號
顧客記錄可能存在相同姓名相同身份證號相同開戶行申請的情況，但客戶號是唯一的，一個顧客理論上對應多個帳戶信息(有可能多次開戶,銀行帳號是唯一的)，一個帳戶信息對應多個交易記錄（可以通過銀行帳號查詢相應明細）
本人不才，對這個不是太懂，希望有高人指點
ps:2樓不用畫er圖，余額不能放在顧客表裡面,只需要用專用的工具例如PD或ERWIN將物理模式和邏輯模式輸入，然後逆向工程導出建表sql即可
2. 匯豐銀行、花旗銀行、工商銀行、中國銀行、建設銀行、招商銀行等各大銀行所用的資料庫系統
該系統是針對"國家開發銀行基礎資料庫系統招標書"的具體要求，結合我公司在資料庫和數據倉庫方面的開發經驗、系統集成能力與技術優勢，組織該方面專家進行多次討論，並充分考慮國家開發銀行實際情況和我們在金融行業數據倉庫的建設經驗，最終構建國家開發銀行基礎資料庫系統。在該系統中，我們採用最先進和完善的IBM數據倉庫系列產品，結合具有豐富表現力的COGNOS公司前端展現工具，集成三層體系結構（Multi-tier）技術，融合WEB方式，最終為開發銀行開發建設一個技術上先進、業務應用成熟、功能完善、性能穩定的基礎資料庫系統，並在此基礎上考慮到系統的未來擴展。
系統簡介
國家開發銀行基礎資料庫系統的總體架構包括數據管理層、應用控制層和用戶界面層三個部分。數據管理層負責管理國家開發銀行各個層次的數據；應用控制層負責處理基於基礎資料庫系統的應用系統業務控制邏輯；用戶界面層處理用戶人機交互介面，將用戶介面與復雜的業務控制邏輯分開，負責將業務信息以一種用戶友好的一致方式提供給用戶。
1、數據管理層
國家開發銀行基礎資料庫系統中，需要管理不同層次的數據：
實時易變的數據：
由國家開發銀行日常業務的操作型應用系統創建和管理。
高質量的一致性數據：
通過對存放在國家開發銀行不同業務應用系統中的數據進行基本的代碼轉換和不一致問題的處理，得到國家開發銀行統一業務視圖的綜合數據。
派生數據：
是在一致性數據基礎上不同程度的聚集產生的數據。
元數據：
元數據是關於以上幾類數據的描述性數據，是國家開發銀行企業級的信息目錄。元數據描述和定位數據元素的來龍去脈：數據來自何處，如何轉換，抽取頻率怎樣，去哪兒，數據倉庫正是通過對元數據的有效管理，為數據工作者尋找、理解和利用上述幾類數據提供方便。
數據管理層採用DB－ODS－DW三層體系結構來管理以上各類數據。其中DB指實時易變的數據和外部數據，ODS（Operational Data Store，操作數據儲存）包括高質量的一致性數據和派生數據，DW（Data Warehouse，數據倉庫）包含歷史的高質量一致性數據和派生數據。
ODS作為一個中間層次，一方面，它包含企業全局一致的、細節的數據，可以進行全局操作型處理；另一方面，它又是一種面向主題的、集成的數據環境，適合完成日常報表和決策的數據處理分析。可見，ODS一方面支持業務性操作，另一方面面向主題。所謂主題是指國家開發銀行業務發展中所關注的業務對象，比如項目開發、信貸管理和資金管理，是在較高層次上將數據歸類，將來自各部門的原始數據做一個從面向應用到面向主題的轉變，即整個系統的設計將按照業務對象進行，而不是按照行政框架設計。在主題之下放置與該主題相關的各種基礎數據，組合在一起就是基礎數據源。基礎數據源是整個ODS的核心，存儲著最為基礎的非派生數據。從上面分析可看出，建設數據倉庫的第一步是建設基礎數據源。這就要求對國家開發銀行相關部門的業務流程和需求進行分析，通過對來自會計信息系統的數據和外部錄入數據進行清洗、抽取和轉換來解決數據的不一致性、分散性、完整性及異構問題。
面向主題和集成性使得ODS的數據在靜態特徵上很接近DW中的數據。但是，在ODS與DW之間仍然有許多基本的、重要的差別。首先，ODS主要保存近期數據，而DW大量是長期保存並可重復查詢的歷史數據。其二，ODS支持面向記錄的聯機刷新，滿足國家開發銀行全局應用的需要，包括企業級的OLTP；而DW中的基礎數據是不可修改的。其三是向ODS數據倉庫DW提供一致的數據環境以供抽取。DW則主要用於長期趨勢分析或戰略決策。
1）數據源
國家開發銀行業務系統數據
國家開發銀行的業務處理系統包括已經投入運行的（會計核算系統）、正在建設的（信貸管理和非現場稽核）和准備建設的各個業務處理系統。這些系統的數據周期性地形成增量文件，由資料庫抽取代理程序（Agent）抽取到總行操作資料庫中（ODS）。
外部數據
外部數據，根據業務需求可以載入到總行操作資料庫中（ODS），也可以直接載入到數據倉庫中。
補充數據
補充數據，由手工輸入或接收程序倒入。
2）基礎數據收集
為了提高基礎數據收集的效率和質量，需要綜合考慮業務需求、數據量、數據載入周期和技術基礎設施多種因素，制定切實可行的數據抽取、凈化、轉換和載入策略,並選擇合適的工具輔助基礎數據收集。
對於國家開發銀行現有業務應用系統管理的數據，應盡力區分存量數據、增量數據和變更的數據（比如，可以通過增加觸發器來得到變更的數據），因為在廣域網環境下，存量數據的抽取、傳輸和載入，增加網路的壓力，是不可取的。而且不管選擇哪種資料庫，資料庫管理系統的大量數據載入速度有限，大量數據載入一般會影響其他用戶對資料庫的操作。
在網路帶寬許可的情況下，總行的ODS收集存儲各分行詳細的業務數據，各分行的詳細業務數據通過數據收集代理（Agent）自動抽取到總行。數據抽取、傳輸和載入的策略是，第一次數據初始化的時候，進行存量數據的批量載入，以後則進行增量數據和變更數據的載入。載入周期是按小時、天、月或季度和年來載入，取決於業務需求。
隨著業務的發展，詳細業務數據量的增大，超出網路帶寬的負荷，建議各分行設置ODS收集存儲各自詳細的業務數據，總行ODS收集存儲各分行經過聚集的業務數據，以減少抽取、傳輸和載入的數據量。
可視化數據倉庫管理器（IBM Visual Warehouse）是IBM公司推出的一個創建和維護數據倉庫的集成工具，可以定義、創建、管理、監控和維護數據倉庫，也可以自動地把異質數據源抽取到中央集成的數據倉庫管理環境中來，它採用分布式的客戶/伺服器（Client/Server）體系結構，包括如下幾個部分：
數據倉庫伺服器（Visual Warehouse Server）
數據倉庫管理員（Visual Warehouse Administrative Clients）
數據倉庫代理（Visual Warehouse Agents）
控制資料庫（Control Database）
數據倉庫（目標資料庫，Target Database）
數據倉庫伺服器運行於Windows NT操作系統之上，監控和管理數據倉庫的處理過程，提供基於時間的和基於事件的調度機制，並且也控制數據倉庫代理的活動。
數據倉庫代理在數據倉庫伺服器的控制下，處理源數據的存取、過濾、傳輸和把數據載入到目標數據倉庫中。數據倉庫代理可以運行在NT、AIX、OS/400、OS/2、SUN不同的系統平台上。為了提高處理效率和可擴展性，一般在數據源和目標數據倉庫所在的機器都安裝數據倉庫代理。
控制資料庫由數據倉庫管理員產生並被數據倉庫代理所利用。可視化數據倉庫管理器把所有的元數據都存儲在控制資料庫中，控制資料庫還可以被一個元數據管理工具集成管理（該工具稱為Dataguide，是可視化數據倉庫管理器的組件之一）。
雖然數據抽取、傳輸和載入自動化的機制可以選擇合適的工具來實現，但針對實際數據環境的數據抽取、轉換和凈化需要自行設計程序，因為實際數據的非標准化和數據轉換的復雜性，數據抽取、轉換和凈化的商品化工具在實際應用中達不到預期效果。
2、總行ODS
總行ODS由兩層數據組成，一層為基礎數據源，是國家開發銀行業務產生的最基礎的非派生的數據；另一層為二次匯總數據。二次匯總數據放置於項目受理、貸款管理和資金管理三個模塊中，直接為項目受理、貸款管理和資金管理三個業務子系統提供數據支持。基礎數據源中的數據主要從會計信息系統中轉換而來，同時又有一部分基礎數據來自於外部數據錄入。
3. 銀行如何建設企業級資料庫基礎邏輯數據模型
前言:邏輯數據模型LDM是一種圖形化的展現方式，一般採用面向對象的設計方法，有效組織來源多樣的各種業務數據，使用統一的邏輯語言描述業務。藉助相對抽象、邏輯統一且結構穩健的結構，實現數據倉庫系統所要求的數據存儲目標，支持大量的分析應用，是實現業務智能的重要基礎，同時也是數據管理分析的工具和交流的有效手段。 需要強調的是，數據倉庫邏輯數據模型特指數據倉庫系統的核心基礎模型，在搭建企業級數據倉庫系統時，需要充分了解和分析種前台業務處理系統和應用，在此基礎上進行有效的重組和整合，為各種分析應用(如客戶關系管理、風險管理等)提供單一的、整合的數據基礎，保證全行不同業務部門從不同的視角都可以使用統一的數據實現各自的分析需求。——擔負這種數據重組和整合任務的數據模型稱為數據倉庫系統的「基礎邏輯數據模型」。 基礎邏輯數據模型建設好之後，銀行可根據不同的分析應用需要(如客戶關系管理、績效考核、風險管理等)，根據應用產品和功能設計不同的分析應用模型，包含具體的、特定的分析邏輯，往往這種模型中都含有較多加工處理的成分。——這種為實現特定用途而設計的數據模型稱為數據倉庫系統的「應用數據模型」。 因此，不誇張地說核心基礎數據模型建設的成敗性會影響到整個數據倉庫系統的建設乃至後續各種分析應用，應引起銀行科技建設和業務分析人員的高度重視。 本文嘗試從銀行建設基礎邏輯數據模型的角度出發，分析、探討建設過程中應該考慮的主要因素、建設的方法以及注意的問題。 一、整體規劃、明確目標、合理定位 銀行建設數據倉庫系統時應充分明確建設目標，核心的邏輯數據模型是對銀行業務的高度抽象、能夠提供對關鍵業務數據的組織和整理，建立一套完整、統一、規范的標准，以便進行各類分析。一個好的核心基礎數據數據模型應該滿足以下條件: 概念上:具有高度抽象的、中性的、可共享的的概念，可有效、全面、完整地適應與涵蓋銀行現有的業務范疇以及數據范圍;不針對某個特別的應用而設計; 結構上:應是穩定的、靈活的、可擴展的;能以滿足第三範式的方法構建模型，存放最詳盡的數據，保證足夠的靈活性，適應復雜的實際業務情況，在業務發生變化或者新增數據源時易於擴展;核心結構在很長時間內應保持穩定性，便於回答不斷產生、不斷變化且無法預先定義的業務問題; 表現形式:應是規范的，易懂的;包括各類命名規范，業務規則定義，度量方式等。使用統一的業務語言進行模型設計，易於業務人員的理解和使用;也有利於IT部門和業務部門人員的溝通; 數據倉庫系統的建設目的和方法不同於傳統業務系統，其開發建設方式也有所不同，它的建設絕不是一蹴而就的事情，不能期望一朝一夕就可以全部完成，比較成熟的建設步驟應該是分階段實施，逐步進行完善和增強因此作為項目起步的LDM建設對於規范和推動整個數據倉庫系統的建設都將起到一個很好的促進。整個建設過程最關鍵的階段就是項目的最初階段，應將工作重心放在搭建模型框架、建立模型設計思想和培養模型設計人員三個方面。 明確了建設目標，具體實施應該如何開展呢? 二、審慎選擇、量體裁衣、度身定做 銀行在明確建設目標之後，如何選擇具體的實施策略、制定設計的階段和步驟呢?常見的主要有以下兩種: 第一種:自主研發:銀行根據以往的業務經驗提煉本行業務的關鍵主題;再設計出本行的概念模型;然後通過具體的業務反復論證，同時考慮將來的分析需求進行基礎邏輯數據模型的詳細設計。 這種方法可以快速啟動，完全依託本行的業務元素和規則，使用行內技術人員和業務人員比較熟悉的語言進行模型的設計，具有很好的適用性。但是整個建設周期比較長，同時往往由於經驗不足等原因給項目帶來一些不可控的風險，由於參與人員經驗的不足，不能夠站在全行的高度，從管理分析的角度去理解所有的業務以及相應的數據，造成一些局限性。 第二種:依託業成熟產品進行客戶化:銀行研究不同的業界模型產品，從中選擇一個作為藍本，結合本行的業務數據和應用系統進行具體的定製化。 這種方法的建設周期短、風險小，同時也能夠很好地借鑒成熟的邏輯數據模型中蘊涵的經營管理理念。但是銀行需要研究和比較多個業界流行的邏輯數據模型，熟悉各自的設計思想和理念，並從中挑選一個適合本行的模型產品進行客戶化。 從國際、國內商業銀行建設數據倉庫系統的經驗和案例來看，為了保證項目的成功實施，避免和控制項目風險，他們幾乎都選擇了第二種方法:客戶化。那銀行在面對眾多邏輯數據模型產品進行選擇的過程中主要應該都關注一些什麼樣的內容呢? 產品層面: 覆蓋范圍:模型產品應能夠適合、涵蓋銀行的所有業務范圍，可以在單一模型中能支撐金零售銀行、公司業務、保險、信用卡、經紀、證券和電子商務等，滿足未來混業經營的需要; 對業務發展的適應性:模型產品應有高度的概括和歸納，既滿足範式化要求，又具有足夠的靈活性，在擴展業務、新增品種或改變規則時，模型通過簡單的調整和擴展即可適應; 對應用的支撐和擴充:模型產品不應偏向某個部門或某些專業的特定應用，要能夠支持績效管理、客戶關系管理、資產負債管理、資金財務管理、風險管理等應用，並與國際金融業完全接軌，從數據介面層面支撐業界監管需要; 模型的開放性:模型產品應有清晰、嚴謹的模型架構，滿足模塊化和結構化的設計要求，真正實現數據一次導入，多次使用; 轉化成物理數據模型的方便性:LDM設計完成，進行一些物理化的定義之後就可以直接利用建模工具平滑地完成物理模型設計。 服務層面: 客戶化方法與能力:邏輯數據模型必須有經過實際項目驗證過的客戶化方法論做指導，明確嚴格的工作步驟、流程、任務分配，並提供必要模板; 業績經驗與表現:應具有國際化大型(特別是國內)商業銀行相關項目和領域的成功實施案例;在行業內具有良好的信譽和業績; 全球支持能力:全球專職研發團隊——各國家地區的具體實施團隊;高級建模顧問——高級金融行業顧問; 不難看出，上述這些考核的方面都是和將來的實施密切相關的。的確，一個成熟的優秀的模型產品，如果沒有得到成功的實施，最終也不能為銀行創造效益。下一部分主要討論在實施過程中的關鍵因素。 三、關鍵成功因素 (1)參與人員的業務經驗 LDM的設計和實施不是一個純粹的技術問題，需要參與人員具有較高的銀行業務修養和素質，設計人員應能夠憑借豐富的業務經驗和知識，將散落在各種不同業務系統以及日常經營管理中的各種數據元素進行高度的抽象和概況，形成本行的幾個主題域(如當事人、協議、產品、事件等)，用以清晰地表達業務邏輯和關系。同時，他們也必須時刻以目標(建設數據倉庫系統)為導向，有選擇地從前台業務系統中抽取相關的數據信息進行映射。 (2)設計團隊的溝通機制 邏輯數據模型的設計過程本身就是一個不斷發現問題、解決問題的過程，不可能某一個人就能夠掌握龐雜銀行業務中的點點滴滴，因此需要整個項目團隊的密切配合。每個設計人員都必應具有良好的學習溝通能力，能夠對建模工作達成共識，根據所定義的結構，將具體的業務數據映射到模型中，同時進行一些修改和校正。 (3)銀行內部IT管理的水平 LDM設計過程中很大量的工作都是對現有業務系統的分析，包括對系統架構和功能的梳理、業務規則和關鍵業務元素的提煉、系統之間的邏輯關系等，並結合樣本數據初步了解數據質量。如果沒有一套有效的管理模式和有力的技術支持，如果沒有現有業務系統的完備資料;如果沒有快速問題反饋和解決機制，LDM的建設只能是空談，因此這給銀行內部IT管理水平提出了很高的要求。 (4)模型的管理和維護 在LDM整個建設周期內還應高度重視維護和管理工作，必需有嚴格的建模技術規范做指導和約束，包括命名、描述、版本控制等。隨著時間的推移和項目建設階段和目標的變化，為了使建成的基礎數據模型具有持續的生命力，應在建設的所有階段把涉及的建模規范內容文檔化並強制執行;在人員發生變動時規定新參與人員應嚴格遵守這些規范，不能另行編制，保證前後的一致性。 總結: 盡管LDM僅僅是一個邏輯的概念，數據倉庫系統需要在邏輯數據模型的指導下，進行真正的物理實施，將把分散在不同平台、以不同方式組織的各種業務數據以及部分外部信息經過清洗和轉化，在保證數據一致性、准確性和實效性的前提下，開發各種應用，奠定實現銀行商業智能的重要基礎。 但是可以看到，通過數據倉庫系統邏輯數據模型的設計，將有利於對銀行現有業務過程的全局認識和系統把握，同時還能夠從整體上對全行使用的操作型業務系統進行回顧，從而提供改造和完善的建議，最終探索出一條符合銀行自身業務實際發展要求的分析型應用系統的道路，為數據倉庫系統的建設奠定堅實的基礎。
4. 銀行數據分析系統都有哪些是自己搭,還是用第三方的
銀行數據分析系統都是比較復雜的，我是不推薦自己搭建的，因為會花費大量的人力和物力，所以還是使用第三方的系統比較省事省力。銀行數據分析系統有：
1、思邁特軟體Smartbi：具有前端數據分析，對接各種業務資料庫，數據倉庫和大數據平台，滿足各種數據分析應用需求。
2、永洪科技：是一家專業從事數據管理（包括ETL，DWD，DWA）和數據價值發掘（包括BI）的高科技企業 。
3、Cloudera：成立於2008年，是一家為企業和大型機構在尋求解決棘手的大數據問題時，往往會使用開源軟體基礎架構Hadoop的服務。
思邁特軟體Smartbi經過十餘年的發展，已在金融、電信、政 府、製造等行業獲得近2000家客戶認可，在眾多的客戶中獲得了很好的口碑，並獲得了投資機構的青睞。在金融行業，全球財富500強的10家國內銀行中，有8家選用了思邁特軟體Smartbi；國內12家股份制銀行，已覆蓋8家。思邁特軟體Smartbi經過多年持續自主研發，凝聚大量商業智能最佳實踐經驗，整合了各行業的數據分析和決策支持的功能需求。滿足最終用戶在企業級報表、數據可視化分析、自助探索分析、數據挖掘建模、AI智能分析等大數據分析需求。
思邁特軟體Smartbi個人用戶全功能模塊長期免費試用
馬上免費體驗:Smartbi一站式大數據分析平台
5. 資料庫高手請進——關於銀行儲蓄系統問題
....要是設計好了,就可以自己開銀行