⑴ 銀行數據分析系統都有哪些是自己搭,還是用第三方的
銀行數據分析系統都是比較復雜的，我是不推薦自己搭建的，因為會花費大量的人力和物力，所以還是使用第三方的系統比較省事省力。銀行數據分析系統有：
1、思邁特軟體Smartbi：具有前端數據分析，對接各種業務資料庫，數據倉庫和大數據平台，滿足各種數據分析應用需求。
2、永洪科技：是一家專業從事數據管理（包括ETL，DWD，DWA）和數據價值發掘（包括BI）的高科技企業 。
3、Cloudera：成立於2008年，是一家為企業和大型機構在尋求解決棘手的大數據問題時，往往會使用開源軟體基礎架構Hadoop的服務。
思邁特軟體Smartbi經過十餘年的發展，已在金融、電信、政 府、製造等行業獲得近2000家客戶認可，在眾多的客戶中獲得了很好的口碑，並獲得了投資機構的青睞。在金融行業，全球財富500強的10家國內銀行中，有8家選用了思邁特軟體Smartbi；國內12家股份制銀行，已覆蓋8家。思邁特軟體Smartbi經過多年持續自主研發，凝聚大量商業智能最佳實踐經驗，整合了各行業的數據分析和決策支持的功能需求。滿足最終用戶在企業級報表、數據可視化分析、自助探索分析、數據挖掘建模、AI智能分析等大數據分析需求。
思邁特軟體Smartbi個人用戶全功能模塊長期免費試用
馬上免費體驗:Smartbi一站式大數據分析平台
⑵ 銀行的數據倉庫，ODS，歷史庫的區別和聯系
銀行的數據倉庫，ODS，歷史庫的區別和聯系
關系資料庫：是建立在關系模型基礎上的資料庫。藉助於集合代數等概念和方法來處理資料庫中的數據。 數據倉庫：是在企業管理和決策中面向主題的、集成的、與時間相關的、不可修改的數據集合。 區別：資料庫是面向事務的設計，數據倉庫是面向主題.
⑶ 銀行用的是什麼資料庫
oracle,db2,sysbase這是銀行的首選。
⑷ 銀行資料庫的兩個關系
關系型資料庫和非關系型資料庫。
首先從大的框架進行對比，關系型資料庫和非關系型資料庫之間的區別，以及兩者使用的場景，這兩種資料庫理論上不應被用來進行對比，兩者的側重點不同。
非關系型資料庫理的論誕生，其實也是因為傳統的資料庫在某些日益增長的數據量需求面前顯得稍微乏力。
⑸ 國內銀行系統用美國甲骨文Oracle資料庫不怕泄密嗎
典型的總有刁民想害朕的心態[靈光一閃]
的確是這樣。國內銀行和金融公司已經在做替換成國產資料庫的工作了。但是還要花一些時間。
順帶說明一下，oracle資料庫美國本土的安全水位是非常高的。只是美國出口限制，導致出口到中國的只是低安全級別的版本。中國國產資料庫在軍工航天電力水利早已應用，都達到了頂級安全標准。
我是金融行業的碼農，也算是有一定的發言權吧。
在資料庫方面，金融領域用到的有Oracle和sqlServer等商業軟體，也有Mysql、Redis等開源軟體。這些軟體有個令人沮喪的共同點， 很少有國產自主研發資料庫 。
隨著互聯網的飛速發展，信息化浪潮席捲各個行業。效率的大幅提升，徹底顛覆了既有的工作模式。率先擁抱變革的企業收獲了巨大收益，讓後來者羨慕嫉妒恨。
信息技術不管發展如何，都繞不開數據存儲，數據存儲以關系型資料庫最符合人的思維方式。關系型資料庫中的翹楚無疑是Oracle資料庫。
再回到題主的泄密問題，即Oracle資料庫安全么？我的答案是 即安全又不安全 。之所以安全因為它是最好關系型資料庫，常見的指標如易用性、穩定性、可用性、可恢復性都有完整的解決方案。之所以不安全是因為它是國外的閉源軟體，是否有安全隱患，國人不得而知。
技術上不可控，我們怎麼才能避免呢？答案是從管理上從嚴控制。
首先，在IT世界，有一個叫做物理隔離，國內銀行的機房網路架構採用的是比較傳統的內網+DMZ的形式，在兩者之間採用專業的防火牆進行連接並安全隔離。DMZ到外網也有一道防火牆。所有的數據存儲和加工必須在內網。
再加上內網登陸各種限制，跳板機，訪問許可權，動態密鑰。
想發個版本都累死，還想把數據弄出來，不太可能。
至於這幾年去IOE，最後也就去了IBM的大機，Oracle資料庫照樣大規模使用，EMC的存儲就更不用說了。
總之一句話，安全使用美國佬技術！累死金融IT民工！
泄密到不存在，一般國內銀行用Oracle的同時都會購買Oracle的維護服務，除非甲骨文不想做中國的生意了。當然因為中美關系的問題，一些行已經開始從周邊系統逐漸開始改造使用國產資料庫，比如華為的高斯200，同時國內的國有軟體企業也在部署研發國產的資料庫，公司名就不說了，反正確實有這個安排。
真的是個好問題，國家核心系統從什麼開始決心拋棄windows。銀行系統數據太過龐大復雜，上了賊船，下船太難太難了。
首先需要明白，銀行的風控部門是銀行體系內具有極度話語權的部門，也是最核心的部門之一。資產是否實現保值增值，以及銀行資產的安全性，也是風控部門重點工作之一。
所以，你能想到的這個問題，銀行的相關部門早就已經想到了，而且肯定做了不少的分析工作。
從網路上來說，銀行的核心主機系統，包括資料庫，都是在銀行內網運行的，並不會直接接入互聯網，這個一般的銀行設備，比如ATM等自助終端都是如此，所以安全性肯定是銀行最關注的焦點。
從安全性來說，銀行的IT部門會對所有出入網路的數據進行分析。就連一個最基本的新開一個網路IP或者埠，都要經過層層的審批和把關，不是隨隨便便就給開通的。我曾經在某個銀行短期出差，當時兩台設備只給了一個IP和埠，我們找銀行客戶申請多開通一個，到我把工作做完，大概一個星期多一點的時間，這個居然都沒審批完成。
另外，如上所說的銀行對流經網路的所有數據都會進行嚴格的監控。比如我們之前有一台設備在銀行網路內運行，一般情況下都會把不必要的組件或程序全部刪除。但那台機器由於設置原因，在更新程序時默認對外連接了微軟的伺服器，很快就被監控出來，銀行IT部門還要求我們給出詳細報告，就是所謂的RCA，Root cause analysis，也就是根源分析。
說了這么多，應該明白銀行為什麼總Oracle不怕數據泄密了吧。當然，早期的時候也沒有其他資料庫可以選擇，基本上就是Oracle, Sybase,DB2,以及微軟的SQLServer。但是銀行的資料庫要求存儲容量大，存儲速度快，且可靠性要求極高，不能出現宕機這樣的情況，這對銀行業務來說是非常致命的。
但隨著我國 科技 的發展，最近Oracle的日子不好過了，去年已經關閉了中國研發中心，幾百名工程師被遣散，隨著我國去IOE的浪潮，越來越多的銀行開始考慮國產國產資料庫和開源資料庫，以前ORACLE獨霸天下的日子已經不存在了。
不怕。
物理上是對外隔離的， 架構上也有大量技術手段確保數據的安全。
但是自主可控的趨勢不可阻擋。
內網，物理隔離。外網用啥都沒用，想搞你不過是時間問題。
國內銀行系統用的資料庫很多， 核心系統一般都用老牌的商業資料庫DB2、Oracle 。其他系統也有用Mysql、MongoDB等其他資料庫。至於數據泄露嗎？銀行當然也怕。但是，就綜合考慮來看，目前Oracle等商業資料庫依然是最佳選擇，將來可能會一步一步提高安全等級。
1、穩定是首要選項我們都知道，銀行是金融系統的重要機構。它們的系統不能夠隨便出問題，一出問題影響整個 社會 。所以， 對銀行來說，穩定是擺在首要位置的 。任何創新都必須以此為前提。而DB2、Oracle這些商業資料庫軟體，首先能夠滿足銀行的穩定性要求。
而在中國，銀行是比較早有信息化的單位。但剛開始，沒有任何經驗的時候，只能是跟歐美國家學習模仿。外企銀行基本都是採用oracle、DB2來做核心系統。中國自然是採用國外相同的方案。大部分銀行也就採用了當時比較流行的一整套IBM大型機、小型機硬體，配套DB2、Oracle資料庫來做。
2、安全實現手段①、廠家信譽
一直用DB2、Oracle作為核心資料庫。對銀行來說，已經是最佳選擇。因為，在過去，國產根本就沒有什麼拿得出手的資料庫可以使用。銀行自然也只能用業界最好的資料庫，而且Oracle、DB2這類大品牌的資料庫，在全球范圍應用都很廣。廠家自然也要注意保障安全，否則出了問題，全世界都受影響。
②、技術控制
除了廠家的信譽保障外，銀行在技術上做了很多安全措施。首先， 內外網是物理隔離的 。這樣，實時連接資料庫的攻擊是很難實現的了。其次，在防止數據泄露這一塊，銀行當然也是有很多的技術手段控制的。至少，外網需要的數據是從內網的網閘擺渡過去的。能擺渡什麼數據出去，也是銀行嚴格控制的。最後， 資料庫里的敏感數據，也是加密存儲的 。同時，網路上還 部署了一系列網路安全設備來 保障系統的安全。
銀行現在雖然有很多的技術手段來保障信息安全，但是，DB2、Oracle始終是國外閉源商業資料庫軟體。如果軟體存在漏洞或者後門，對銀行來說也是一個大風險。加上國際形勢風雲變化，所以，銀行也還是會有擔心泄密問題，這就意味著銀行的安全體系還需要升級。
那該如何升級安全呢？除了系統過等級保護外，也一直在倡導用安全可靠的軟體。這就意味著需要逐步從Oracle、DB2等商業軟體走向開源、或者國產等資料庫軟體。不過，銀行的穩定性還是不能忽略的，所以， 銀行也就只能逐步 探索 ，逐步提升安全。同時，國產資料庫發展也還有很長一段路要走 。
總結總之，早些年銀行從穩定和安全出發，Oracle、DB2等商業資料庫是最佳選擇。這些年，隨著國際形勢的變化和技術的發展，銀行也在逐步提升安全等級。將來也會逐步替換Oracle、DB2等商業資料庫軟體。
⑹ 中國的銀行一般用什麼資料庫系統
銀行用的是oracle 甲骨文資料庫 支持72種操作系統
號稱是世界上最好的資料庫系統 是一項非常專業的技術
⑺ 銀行如何建設企業級資料庫基礎邏輯數據模型
前言:邏輯數據模型LDM是一種圖形化的展現方式，一般採用面向對象的設計方法，有效組織來源多樣的各種業務數據，使用統一的邏輯語言描述業務。藉助相對抽象、邏輯統一且結構穩健的結構，實現數據倉庫系統所要求的數據存儲目標，支持大量的分析應用，是實現業務智能的重要基礎，同時也是數據管理分析的工具和交流的有效手段。 需要強調的是，數據倉庫邏輯數據模型特指數據倉庫系統的核心基礎模型，在搭建企業級數據倉庫系統時，需要充分了解和分析種前台業務處理系統和應用，在此基礎上進行有效的重組和整合，為各種分析應用(如客戶關系管理、風險管理等)提供單一的、整合的數據基礎，保證全行不同業務部門從不同的視角都可以使用統一的數據實現各自的分析需求。——擔負這種數據重組和整合任務的數據模型稱為數據倉庫系統的「基礎邏輯數據模型」。 基礎邏輯數據模型建設好之後，銀行可根據不同的分析應用需要(如客戶關系管理、績效考核、風險管理等)，根據應用產品和功能設計不同的分析應用模型，包含具體的、特定的分析邏輯，往往這種模型中都含有較多加工處理的成分。——這種為實現特定用途而設計的數據模型稱為數據倉庫系統的「應用數據模型」。 因此，不誇張地說核心基礎數據模型建設的成敗性會影響到整個數據倉庫系統的建設乃至後續各種分析應用，應引起銀行科技建設和業務分析人員的高度重視。 本文嘗試從銀行建設基礎邏輯數據模型的角度出發，分析、探討建設過程中應該考慮的主要因素、建設的方法以及注意的問題。 一、整體規劃、明確目標、合理定位 銀行建設數據倉庫系統時應充分明確建設目標，核心的邏輯數據模型是對銀行業務的高度抽象、能夠提供對關鍵業務數據的組織和整理，建立一套完整、統一、規范的標准，以便進行各類分析。一個好的核心基礎數據數據模型應該滿足以下條件: 概念上:具有高度抽象的、中性的、可共享的的概念，可有效、全面、完整地適應與涵蓋銀行現有的業務范疇以及數據范圍;不針對某個特別的應用而設計; 結構上:應是穩定的、靈活的、可擴展的;能以滿足第三範式的方法構建模型，存放最詳盡的數據，保證足夠的靈活性，適應復雜的實際業務情況，在業務發生變化或者新增數據源時易於擴展;核心結構在很長時間內應保持穩定性，便於回答不斷產生、不斷變化且無法預先定義的業務問題; 表現形式:應是規范的，易懂的;包括各類命名規范，業務規則定義，度量方式等。使用統一的業務語言進行模型設計，易於業務人員的理解和使用;也有利於IT部門和業務部門人員的溝通; 數據倉庫系統的建設目的和方法不同於傳統業務系統，其開發建設方式也有所不同，它的建設絕不是一蹴而就的事情，不能期望一朝一夕就可以全部完成，比較成熟的建設步驟應該是分階段實施，逐步進行完善和增強因此作為項目起步的LDM建設對於規范和推動整個數據倉庫系統的建設都將起到一個很好的促進。整個建設過程最關鍵的階段就是項目的最初階段，應將工作重心放在搭建模型框架、建立模型設計思想和培養模型設計人員三個方面。 明確了建設目標，具體實施應該如何開展呢? 二、審慎選擇、量體裁衣、度身定做 銀行在明確建設目標之後，如何選擇具體的實施策略、制定設計的階段和步驟呢?常見的主要有以下兩種: 第一種:自主研發:銀行根據以往的業務經驗提煉本行業務的關鍵主題;再設計出本行的概念模型;然後通過具體的業務反復論證，同時考慮將來的分析需求進行基礎邏輯數據模型的詳細設計。 這種方法可以快速啟動，完全依託本行的業務元素和規則，使用行內技術人員和業務人員比較熟悉的語言進行模型的設計，具有很好的適用性。但是整個建設周期比較長，同時往往由於經驗不足等原因給項目帶來一些不可控的風險，由於參與人員經驗的不足，不能夠站在全行的高度，從管理分析的角度去理解所有的業務以及相應的數據，造成一些局限性。 第二種:依託業成熟產品進行客戶化:銀行研究不同的業界模型產品，從中選擇一個作為藍本，結合本行的業務數據和應用系統進行具體的定製化。 這種方法的建設周期短、風險小，同時也能夠很好地借鑒成熟的邏輯數據模型中蘊涵的經營管理理念。但是銀行需要研究和比較多個業界流行的邏輯數據模型，熟悉各自的設計思想和理念，並從中挑選一個適合本行的模型產品進行客戶化。 從國際、國內商業銀行建設數據倉庫系統的經驗和案例來看，為了保證項目的成功實施，避免和控制項目風險，他們幾乎都選擇了第二種方法:客戶化。那銀行在面對眾多邏輯數據模型產品進行選擇的過程中主要應該都關注一些什麼樣的內容呢? 產品層面: 覆蓋范圍:模型產品應能夠適合、涵蓋銀行的所有業務范圍，可以在單一模型中能支撐金零售銀行、公司業務、保險、信用卡、經紀、證券和電子商務等，滿足未來混業經營的需要; 對業務發展的適應性:模型產品應有高度的概括和歸納，既滿足範式化要求，又具有足夠的靈活性，在擴展業務、新增品種或改變規則時，模型通過簡單的調整和擴展即可適應; 對應用的支撐和擴充:模型產品不應偏向某個部門或某些專業的特定應用，要能夠支持績效管理、客戶關系管理、資產負債管理、資金財務管理、風險管理等應用，並與國際金融業完全接軌，從數據介面層面支撐業界監管需要; 模型的開放性:模型產品應有清晰、嚴謹的模型架構，滿足模塊化和結構化的設計要求，真正實現數據一次導入，多次使用; 轉化成物理數據模型的方便性:LDM設計完成，進行一些物理化的定義之後就可以直接利用建模工具平滑地完成物理模型設計。 服務層面: 客戶化方法與能力:邏輯數據模型必須有經過實際項目驗證過的客戶化方法論做指導，明確嚴格的工作步驟、流程、任務分配，並提供必要模板; 業績經驗與表現:應具有國際化大型(特別是國內)商業銀行相關項目和領域的成功實施案例;在行業內具有良好的信譽和業績; 全球支持能力:全球專職研發團隊——各國家地區的具體實施團隊;高級建模顧問——高級金融行業顧問; 不難看出，上述這些考核的方面都是和將來的實施密切相關的。的確，一個成熟的優秀的模型產品，如果沒有得到成功的實施，最終也不能為銀行創造效益。下一部分主要討論在實施過程中的關鍵因素。 三、關鍵成功因素 (1)參與人員的業務經驗 LDM的設計和實施不是一個純粹的技術問題，需要參與人員具有較高的銀行業務修養和素質，設計人員應能夠憑借豐富的業務經驗和知識，將散落在各種不同業務系統以及日常經營管理中的各種數據元素進行高度的抽象和概況，形成本行的幾個主題域(如當事人、協議、產品、事件等)，用以清晰地表達業務邏輯和關系。同時，他們也必須時刻以目標(建設數據倉庫系統)為導向，有選擇地從前台業務系統中抽取相關的數據信息進行映射。 (2)設計團隊的溝通機制 邏輯數據模型的設計過程本身就是一個不斷發現問題、解決問題的過程，不可能某一個人就能夠掌握龐雜銀行業務中的點點滴滴，因此需要整個項目團隊的密切配合。每個設計人員都必應具有良好的學習溝通能力，能夠對建模工作達成共識，根據所定義的結構，將具體的業務數據映射到模型中，同時進行一些修改和校正。 (3)銀行內部IT管理的水平 LDM設計過程中很大量的工作都是對現有業務系統的分析，包括對系統架構和功能的梳理、業務規則和關鍵業務元素的提煉、系統之間的邏輯關系等，並結合樣本數據初步了解數據質量。如果沒有一套有效的管理模式和有力的技術支持，如果沒有現有業務系統的完備資料;如果沒有快速問題反饋和解決機制，LDM的建設只能是空談，因此這給銀行內部IT管理水平提出了很高的要求。 (4)模型的管理和維護 在LDM整個建設周期內還應高度重視維護和管理工作，必需有嚴格的建模技術規范做指導和約束，包括命名、描述、版本控制等。隨著時間的推移和項目建設階段和目標的變化，為了使建成的基礎數據模型具有持續的生命力，應在建設的所有階段把涉及的建模規范內容文檔化並強制執行;在人員發生變動時規定新參與人員應嚴格遵守這些規范，不能另行編制，保證前後的一致性。 總結: 盡管LDM僅僅是一個邏輯的概念，數據倉庫系統需要在邏輯數據模型的指導下，進行真正的物理實施，將把分散在不同平台、以不同方式組織的各種業務數據以及部分外部信息經過清洗和轉化，在保證數據一致性、准確性和實效性的前提下，開發各種應用，奠定實現銀行商業智能的重要基礎。 但是可以看到，通過數據倉庫系統邏輯數據模型的設計，將有利於對銀行現有業務過程的全局認識和系統把握，同時還能夠從整體上對全行使用的操作型業務系統進行回顧，從而提供改造和完善的建議，最終探索出一條符合銀行自身業務實際發展要求的分析型應用系統的道路，為數據倉庫系統的建設奠定堅實的基礎。
⑻ 國內銀行系統用Oracle資料庫不怕泄密嗎
典型的總有刁民想害朕的心態[靈光一閃]
泄密到不存在，一般國內銀行用Oracle的同時都會購買Oracle的維護服務，除非甲骨文不想做中國的生意了。當然因為中美關系的問題，一些行已經開始從周邊系統逐漸開始改造使用國產資料庫，比如華為的高斯200，同時國內的國有軟體企業也在部署研發國產的資料庫，公司名就不說了，反正確實有這個安排。
真的是個好問題，國家核心系統從什麼開始決心拋棄windows。銀行系統數據太過龐大復雜，上了賊船，下船太難太難了。
我是金融行業的碼農，也算是有一定的發言權吧。
在資料庫方面，金融領域用到的有Oracle和SQLServer等商業軟體，也有Mysql、Redis等開源軟體。這些軟體有個令人沮喪的共同點， 很少有國產自主研發資料庫 。
隨著互聯網的飛速發展，信息化浪潮席捲各個行業。效率的大幅提升，徹底顛覆了既有的工作模式。率先擁抱變革的企業收獲了巨大收益，讓後來者羨慕嫉妒恨。
信息技術不管發展如何，都繞不開數據存儲，數據存儲以關系型資料庫最符合人的思維方式。關系型資料庫中的翹楚無疑是Oracle資料庫。
再回到題主的泄密問題，即Oracle資料庫安全么？我的答案是 即安全又不安全 。之所以安全因為它是最好關系型資料庫，常見的指標如易用性、穩定性、可用性、可恢復性都有完整的解決方案。之所以不安全是因為它是國外的閉源軟體，是否有安全隱患，國人不得而知。
技術上不可控，我們怎麼才能避免呢？答案是從管理上從嚴控制。
不怕。
物理上是對外隔離的， 架構上也有大量技術手段確保數據的安全。
但是自主可控的趨勢不可阻擋。
內網，物理隔離。外網用啥都沒用，想搞你不過是時間問題。
國內銀行系統用的資料庫很多， 核心系統一般都用老牌的商業資料庫DB2、Oracle 。其他系統也有用Mysql、MongoDB等其他資料庫。至於數據泄露嗎？銀行當然也怕。但是，就綜合考慮來看，目前Oracle等商業資料庫依然是最佳選擇，將來可能會一步一步提高安全等級。
1、穩定是首要選項我們都知道，銀行是金融系統的重要機構。它們的系統不能夠隨便出問題，一出問題影響整個 社會 。所以， 對銀行來說，穩定是擺在首要位置的 。任何創新都必須以此為前提。而DB2、Oracle這些商業資料庫軟體，首先能夠滿足銀行的穩定性要求。
而在中國，銀行是比較早有信息化的單位。但剛開始，沒有任何經驗的時候，只能是跟歐美國家學習模仿。外企銀行基本都是採用oracle、DB2來做核心系統。中國自然是採用國外相同的方案。大部分銀行也就採用了當時比較流行的一整套IBM大型機、小型機硬體，配套DB2、Oracle資料庫來做。
2、安全實現手段①、廠家信譽
一直用DB2、Oracle作為核心資料庫。對銀行來說，已經是最佳選擇。因為，在過去，國產根本就沒有什麼拿得出手的資料庫可以使用。銀行自然也只能用業界最好的資料庫，而且Oracle、DB2這類大品牌的資料庫，在全球范圍應用都很廣。廠家自然也要注意保障安全，否則出了問題，全世界都受影響。
②、技術控制
除了廠家的信譽保障外，銀行在技術上做了很多安全措施。首先， 內外網是物理隔離的 。這樣，實時連接資料庫的攻擊是很難實現的了。其次，在防止數據泄露這一塊，銀行當然也是有很多的技術手段控制的。至少，外網需要的數據是從內網的網閘擺渡過去的。能擺渡什麼數據出去，也是銀行嚴格控制的。最後， 資料庫里的敏感數據，也是加密存儲的 。同時，網路上還 部署了一系列網路安全設備來 保障系統的安全。
銀行現在雖然有很多的技術手段來保障信息安全，但是，DB2、Oracle始終是國外閉源商業資料庫軟體。如果軟體存在漏洞或者後門，對銀行來說也是一個大風險。加上國際形勢風雲變化，所以，銀行也還是會有擔心泄密問題，這就意味著銀行的安全體系還需要升級。
那該如何升級安全呢？除了系統過等級保護外，也一直在倡導用安全可靠的軟體。這就意味著需要逐步從Oracle、DB2等商業軟體走向開源、或者國產等資料庫軟體。不過，銀行的穩定性還是不能忽略的，所以， 銀行也就只能逐步 探索 ，逐步提升安全。同時，國產資料庫發展也還有很長一段路要走 。
總結總之，早些年銀行從穩定和安全出發，Oracle、DB2等商業資料庫是最佳選擇。這些年，隨著國際形勢的變化和技術的發展，銀行也在逐步提升安全等級。將來也會逐步替換Oracle、DB2等商業資料庫軟體。
這是個系統的問題。
有些朋友說物理隔離，目前看應該做不到100％隔離。銀行數據中心就是提供服務的，隔離了怎麼提供服務？各個分行，網點，ATM都是要聯網的，都是要訪問資料庫的，只是許可權不同。
歸結起來就是數據安全和資料庫系統，計算機系統，網路系統，以及工作人員都是相關的，必須全方位防護。
資料庫系統，國產化當然是必須的，但是國產資料庫系統就沒有漏洞嗎？不故意竊取數據，難保不因失誤而失竊。這個要加強測試。
計算機系統，包括軟體和硬體，同樣道理。
網路方面，銀行應該是租用運營商的線路(虛擬專網，VPN)實現網點互聯。出點和入點之間加密傳輸。如果加密演算法沒有被破解，秘鑰沒有暴露，一般沒問題。但畢竟還是有」如果」的。
人的問題更大一些，買通一個人不太難吧？這個要通過層層審核，相互制衡，以及思想政治工作來防範。
所以說信息系統的安全防護是全方位的。
要使用SWIFT ,國際資金清算系統，就必須與國際接軌，所以必須用Oracl。
林鄭太太被制裁，信用卡不能用，工資都發現金，使用也是現金，那麼多的國行，沒有一家敢接盤。
有別的選擇嗎。
⑼ 中國建設銀行用什麼資料庫
核心系統（core banking）應該用的是DB2，但外圍應用有別的資料庫，比如網銀好像是oracle。
⑽ 各大銀行都使用什麼資料庫
使用的資料庫類型較多，既有傳統的商用資料庫，包括 DB2、Oracle 、SQL Server 等，又有開源資料庫如 MySQL 等 ; 既有關系型資料庫，又有非結構化的比如 Hadoop、Spark 平台，還有基於 Redis 的分布式緩存平台用於關系型資料庫補充。
工商銀行核心業務系統多跑在 DB2、Oracle 之上。在開源 MySQL 應用方面，工商銀行重點推進在人工智慧、物聯網等創新領域廣泛使用，並匹配銀行特點在架構部署、參數調優等方面進行多項創新，成為後續 OLTP 關系型資料庫轉型的重點方向， 目前已上線數百套系統。