⑴ 银行数据分析系统都有哪些是自己搭,还是用第三方的
银行数据分析系统都是比较复杂的，我是不推荐自己搭建的，因为会花费大量的人力和物力，所以还是使用第三方的系统比较省事省力。银行数据分析系统有：
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 关系型数据库转型的重点方向， 目前已上线数百套系统。