银行atm业务数据库设计

A. 银行如何建设企业级数据库基础逻辑数据模型

前言:逻辑数据模型LDM是一种图形化的展现方式，一般采用面向对象的设计方法，有效组织来源多样的各种业务数据，使用统一的逻辑语言描述业务。借助相对抽象、逻辑统一且结构稳健的结构，实现数据仓库系统所要求的数据存储目标，支持大量的分析应用，是实现业务智能的重要基础，同时也是数据管理分析的工具和交流的有效手段。 需要强调的是，数据仓库逻辑数据模型特指数据仓库系统的核心基础模型，在搭建企业级数据仓库系统时，需要充分了解和分析种前台业务处理系统和应用，在此基础上进行有效的重组和整合，为各种分析应用(如客户关系管理、风险管理等)提供单一的、整合的数据基础，保证全行不同业务部门从不同的视角都可以使用统一的数据实现各自的分析需求。——担负这种数据重组和整合任务的数据模型称为数据仓库系统的“基础逻辑数据模型”。 基础逻辑数据模型建设好之后，银行可根据不同的分析应用需要(如客户关系管理、绩效考核、风险管理等)，根据应用产品和功能设计不同的分析应用模型，包含具体的、特定的分析逻辑，往往这种模型中都含有较多加工处理的成分。——这种为实现特定用途而设计的数据模型称为数据仓库系统的“应用数据模型”。 因此，不夸张地说核心基础数据模型建设的成败性会影响到整个数据仓库系统的建设乃至后续各种分析应用，应引起银行科技建设和业务分析人员的高度重视。 本文尝试从银行建设基础逻辑数据模型的角度出发，分析、探讨建设过程中应该考虑的主要因素、建设的方法以及注意的问题。 一、整体规划、明确目标、合理定位 银行建设数据仓库系统时应充分明确建设目标，核心的逻辑数据模型是对银行业务的高度抽象、能够提供对关键业务数据的组织和整理，建立一套完整、统一、规范的标准，以便进行各类分析。一个好的核心基础数据数据模型应该满足以下条件: 概念上:具有高度抽象的、中性的、可共享的的概念，可有效、全面、完整地适应与涵盖银行现有的业务范畴以及数据范围;不针对某个特别的应用而设计; 结构上:应是稳定的、灵活的、可扩展的;能以满足第三范式的方法构建模型，存放最详尽的数据，保证足够的灵活性，适应复杂的实际业务情况，在业务发生变化或者新增数据源时易于扩展;核心结构在很长时间内应保持稳定性，便于回答不断产生、不断变化且无法预先定义的业务问题; 表现形式:应是规范的，易懂的;包括各类命名规范，业务规则定义，度量方式等。使用统一的业务语言进行模型设计，易于业务人员的理解和使用;也有利于IT部门和业务部门人员的沟通; 数据仓库系统的建设目的和方法不同于传统业务系统，其开发建设方式也有所不同，它的建设绝不是一蹴而就的事情，不能期望一朝一夕就可以全部完成，比较成熟的建设步骤应该是分阶段实施，逐步进行完善和增强因此作为项目起步的LDM建设对于规范和推动整个数据仓库系统的建设都将起到一个很好的促进。整个建设过程最关键的阶段就是项目的最初阶段，应将工作重心放在搭建模型框架、建立模型设计思想和培养模型设计人员三个方面。 明确了建设目标，具体实施应该如何开展呢? 二、审慎选择、量体裁衣、度身定做 银行在明确建设目标之后，如何选择具体的实施策略、制定设计的阶段和步骤呢?常见的主要有以下两种: 第一种:自主研发:银行根据以往的业务经验提炼本行业务的关键主题;再设计出本行的概念模型;然后通过具体的业务反复论证，同时考虑将来的分析需求进行基础逻辑数据模型的详细设计。 这种方法可以快速启动，完全依托本行的业务元素和规则，使用行内技术人员和业务人员比较熟悉的语言进行模型的设计，具有很好的适用性。但是整个建设周期比较长，同时往往由于经验不足等原因给项目带来一些不可控的风险，由于参与人员经验的不足，不能够站在全行的高度，从管理分析的角度去理解所有的业务以及相应的数据，造成一些局限性。 第二种:依托业成熟产品进行客户化:银行研究不同的业界模型产品，从中选择一个作为蓝本，结合本行的业务数据和应用系统进行具体的定制化。 这种方法的建设周期短、风险小，同时也能够很好地借鉴成熟的逻辑数据模型中蕴涵的经营管理理念。但是银行需要研究和比较多个业界流行的逻辑数据模型，熟悉各自的设计思想和理念，并从中挑选一个适合本行的模型产品进行客户化。 从国际、国内商业银行建设数据仓库系统的经验和案例来看，为了保证项目的成功实施，避免和控制项目风险，他们几乎都选择了第二种方法:客户化。那银行在面对众多逻辑数据模型产品进行选择的过程中主要应该都关注一些什么样的内容呢? 产品层面: 覆盖范围:模型产品应能够适合、涵盖银行的所有业务范围，可以在单一模型中能支撑金零售银行、公司业务、保险、信用卡、经纪、证券和电子商务等，满足未来混业经营的需要; 对业务发展的适应性:模型产品应有高度的概括和归纳，既满足范式化要求，又具有足够的灵活性，在扩展业务、新增品种或改变规则时，模型通过简单的调整和扩展即可适应; 对应用的支撑和扩充:模型产品不应偏向某个部门或某些专业的特定应用，要能够支持绩效管理、客户关系管理、资产负债管理、资金财务管理、风险管理等应用，并与国际金融业完全接轨，从数据接口层面支撑业界监管需要; 模型的开放性:模型产品应有清晰、严谨的模型架构，满足模块化和结构化的设计要求，真正实现数据一次导入，多次使用; 转化成物理数据模型的方便性:LDM设计完成，进行一些物理化的定义之后就可以直接利用建模工具平滑地完成物理模型设计。 服务层面: 客户化方法与能力:逻辑数据模型必须有经过实际项目验证过的客户化方法论做指导，明确严格的工作步骤、流程、任务分配，并提供必要模板; 业绩经验与表现:应具有国际化大型(特别是国内)商业银行相关项目和领域的成功实施案例;在行业内具有良好的信誉和业绩; 全球支持能力:全球专职研发团队——各国家地区的具体实施团队;高级建模顾问——高级金融行业顾问; 不难看出，上述这些考核的方面都是和将来的实施密切相关的。的确，一个成熟的优秀的模型产品，如果没有得到成功的实施，最终也不能为银行创造效益。下一部分主要讨论在实施过程中的关键因素。 三、关键成功因素 (1)参与人员的业务经验 LDM的设计和实施不是一个纯粹的技术问题，需要参与人员具有较高的银行业务修养和素质，设计人员应能够凭借丰富的业务经验和知识，将散落在各种不同业务系统以及日常经营管理中的各种数据元素进行高度的抽象和概况，形成本行的几个主题域(如当事人、协议、产品、事件等)，用以清晰地表达业务逻辑和关系。同时，他们也必须时刻以目标(建设数据仓库系统)为导向，有选择地从前台业务系统中抽取相关的数据信息进行映射。 (2)设计团队的沟通机制 逻辑数据模型的设计过程本身就是一个不断发现问题、解决问题的过程，不可能某一个人就能够掌握庞杂银行业务中的点点滴滴，因此需要整个项目团队的密切配合。每个设计人员都必应具有良好的学习沟通能力，能够对建模工作达成共识，根据所定义的结构，将具体的业务数据映射到模型中，同时进行一些修改和校正。 (3)银行内部IT管理的水平 LDM设计过程中很大量的工作都是对现有业务系统的分析，包括对系统架构和功能的梳理、业务规则和关键业务元素的提炼、系统之间的逻辑关系等，并结合样本数据初步了解数据质量。如果没有一套有效的管理模式和有力的技术支持，如果没有现有业务系统的完备资料;如果没有快速问题反馈和解决机制，LDM的建设只能是空谈，因此这给银行内部IT管理水平提出了很高的要求。 (4)模型的管理和维护 在LDM整个建设周期内还应高度重视维护和管理工作，必需有严格的建模技术规范做指导和约束，包括命名、描述、版本控制等。随着时间的推移和项目建设阶段和目标的变化，为了使建成的基础数据模型具有持续的生命力，应在建设的所有阶段把涉及的建模规范内容文档化并强制执行;在人员发生变动时规定新参与人员应严格遵守这些规范，不能另行编制，保证前后的一致性。 总结: 尽管LDM仅仅是一个逻辑的概念，数据仓库系统需要在逻辑数据模型的指导下，进行真正的物理实施，将把分散在不同平台、以不同方式组织的各种业务数据以及部分外部信息经过清洗和转化，在保证数据一致性、准确性和实效性的前提下，开发各种应用，奠定实现银行商业智能的重要基础。 但是可以看到，通过数据仓库系统逻辑数据模型的设计，将有利于对银行现有业务过程的全局认识和系统把握，同时还能够从整体上对全行使用的操作型业务系统进行回顾，从而提供改造和完善的建议，最终探索出一条符合银行自身业务实际发展要求的分析型应用系统的道路，为数据仓库系统的建设奠定坚实的基础。

B. 求帮忙做一个银行数据库 Oracle

功能一：
create database bank;
功能二：
create table userinfo(
customerID number(10) not null,
customerName varchar2(10) not null,
PID char(18) not null,
telephone char(11) not null,
address varchar2(255) not null
);
create table cardinfo(
cardID varchar2(19) not null,
cardCustomerID number(10) not null,
curtype char(3) not null,
savingtype char(4) not null,
openDate date not null,
openmoney number(10,2) not null,
blance number(10,2) not null,
password char(6) not null,
isreportLoss char(2) not null
);
create table transinfo(
id number(15) not null,
transcustomerID number(10) not null,
transcardID varchar2(19) not null,
transdate date not null,
transmoney number(10,2) not null,
transtype char(4) not null,
remark varchar2(255) not null
);
功能三：
alter table userinfo add constraint pk_userinfo primary key (customerID);
alter table userinfo add constraint ck_PID check(length(PID)=18);
alter table cardinfo add constraint pk_cardinfo primary key (cardID);
alter table cardinfo add constraint fk_CustomerID_card foreign key cardCustomerID references userinfo(customerID);
alter table transinfo add constraint pk_transinfo primary key (id);
alter table transinfo add constraint fk_CustomerID_trans foreign key cardCustomerID references userinfo(customerID);
alter table transinfo add constraint fk_transcardID_trans foreign key cardCustomerID references cardinfo(cardID);
功能四：
insert into userinfo values(1,'张三','123456789012345671','13012345671','地址1');
insert into userinfo values(2,'李四','123456789012345672','13012345672','地址2');
insert into userinfo values(3,'王五','123456789012345673','13012345673','地址3');
insert into cardinfo values('1234567890123456789',1,'RMB','活期',sysdate,5.04,5.04,'123456','否');
insert into cardinfo values('1234567890123456788',2,'JPY','活期',sysdate,3.22,3.22,'123457','否');
insert into cardinfo values('1234567890123456787',3,'USA','定期',sysdate,6.78,6.78,'123458','否');
insert into transinfo values(1,1,'1234567890123456789',sysdate,0.23,'存入','存钱');
insert into transinfo values(2,2,'1234567890123456788',sysdate,1.27,'支取','取钱');
insert into transinfo values(3,3,'1234567890123456787',sysdate,2.34,'存入','存钱');
功能五：
select transcardID,transmoney from transinfo where to_char(transdate,'mm')=to_char(sysdate,'mm') and transmoney=max(transmoney);
功能六：
create procere p_c
is
cursor cr is
select b.cardID,a.customerName,a.telephone from userinfo a,cardinfo b where a.customerID=b.cardCustomerID and to_char(sysdate,'dd') in ('28','29','30','31') and b.blance<200;
cur_info cr;
begin
for cur_info in cr loop
dbms_output.put_line('卡号：' || cur_info.cardID || '&&' || '姓名：' || cur_info.customerName || '电话：' || cur_info.telephone);
end loop;
end p_c;

C. 大型数据库的设计原则与开发技巧

随着计算机技术越来越广泛地应用于国民经济的各个领域 在计算机硬件不断微型化的同时 应用系统向着复杂化 大型化的方向发展 数据库是整个系统的核心 它的设计直接关系系统执行的效率和系统的稳定性 因此在软件系统开发中 数据库设计应遵循必要的数据库范式理论 以减少冗余 保证数据的完整性与正确性 只有在合适的数据库产品上设计出合理的数据库模型 才能降低整个系统的编程和维护难度 提高系统的实际运行效率 虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库 但对于一个包含大型数据库的软件项目 就必须有一套完整的设计原则与技巧

一 成立数据小组

大型数据库数据元素多 在设计上有必要成立专门的数据小组 由于数据库设计者不一定是使用者 对系统设计中的数据元素不可能考虑周全 数据库设计出来后 往往难以找到所需的库表 因此数据小组最好由熟悉业务的项目骨干组成

数据小组的职能并非是设计数据库 而是通过需求分析 在参考其他相似系统的基础上 提取系统的基本数据元素 担负对数据库的审核 审核内容包括审核新的数据库元素是否完全 能否实现全部业务需求 对旧数据库（如果存在旧系统）的分析及数据转换 数据库设计的审核 控制及必要调整

二 设计原则

规范命名 所有的库名 表名 域名必须遵循统一的命名规则 并进行必要说明 以方便设计 维护 查询

控制字段的引用 在设计时 可以选择适当的数据库设计管理工具 以方便开发人员的分布式设计和数据小组的集中审核管理 采用统一的命名规则 如果设计的字段已经存在 可直接引用 否则 应重新设计

库表重复控制 在设计过程中 如果发现大部分字段都已存在 开发人员应怀疑所设计的库表是否已存在 通过对字段所在库表及相应设计人员的查询 可以确认库表是否确实重复

并发控制 设计中应进行并发控制 即对于同一个库表 在同一时间只有一个人有控制权 其他人只能进行查询

必要的讨论 数据库设计完成后 数据小组应与相关人员进行讨论 通过讨论来熟悉数据库 从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息

数据小组的审核 库表的定版 修改最终都要通过数据小组的审核 以保证符合必要的要求

头文件处理 每次数据修改后 数据小组要对相应的头文件进行修改（可由管理软件自动完成） 并通知相关的开发人员 以便进行相应的程序修改

三 设计技巧

分类拆分数据量大的表 对于经常使用的表（如某些参数表或代码对照表） 由于其使用频率很高 要尽量减少表中的记录数量 例如 银行的户主账表原来设计成一张表 虽然可以方便程序的设计与维护 但经过分析发现 由于数据量太大 会影响数据的迅速定位 如果将户主账表分别设计为活期户主账 定期户主账及对公户主账等 则可以大大提高查询效率

索引设计 对于大的数据库表 合理的索引能够提高整个数据库的操作效率 在索引设计中 索引字段应挑选重复值较少的字段 在对建有复合索引的字段进行检索时 应注意按照复合索引字段建立的顺序进行 例如 如果对一个 万多条记录的流水表以日期和流水号为序建立复合索引 由于在该表中日期的重复值接近整个表的记录数 用流水号进行查询所用的时间接近 秒 而如果以流水号为索引字段建立索引进行相同的查询 所用时间不到 秒 因此在大型数据库设计中 只有进行合理的索引字段选择 才能有效提高整个数据库的操作效率

数据操作的优化 在大型数据库中 如何提高数据操作效率值得关注 例如 每在数据库流水表中增加一笔业务 就必须从流水控制表中取出流水号 并将其流水号的数值加一 正常情况下 单笔操作的反应速度尚属正常 但当用它进行批量业务处理时 速度会明显减慢 经过分析发现 每次对流水控制表中的流水号数值加一时都要锁定该表 而该表却是整个系统操作的核心 有可能在操作时被其他进程锁定 因而使整个事务操作速度变慢 对这一问题的解决的办法是 根据批量业务的总笔数批量申请流水号 并对流水控制表进行一次更新 即可提高批量业务处理的速度 另一个例子是对插表的优化 对于大批量的业务处理 如果在插入数据库表时用普通的Insert语句 速度会很慢 其原因在于 每次插表都要进行一次I/O操作 花费较长的时间 改进后 可以用Put语句等缓冲区形式等满页后再进行I/O操作 从而提高效率 对大的数据库表进行删除时 一般会直接用Delete语句 这个语句虽然可以进行小表操作 但对大表却会因带来大事务而导致删除速度很慢甚至失败 解决的方法是去掉事务 但更有效的办法是先进行Drop操作再进行重建

数据库参数的调整 数据库参数的调整是一个经验不断积累的过程 应由有经验的系统管理员完成 以Informix数据库为例 记录锁的数目太少会造成锁表的失败 逻辑日志的文件数目太少会造成插入大表失败等 这些问题都应根据实际情况进行必要的调整

必要的工具 在整个数据库的开发与设计过程中 可以先开发一些小的应用工具 如自动生成库表的头文件 插入数据的初始化 数据插入的函数封装 错误跟踪或自动显示等 以此提高数据库的设计与开发效率

避免长事务 对单个大表的删除或插入操作会带来大事务 解决的办法是对参数进行调整 也可以在插入时对文件进行分割 对于一个由一系列小事务顺序操作共同构成的长事务（如银行交易系统的日终交易） 可以由一系列操作完成整个事务 但其缺点是有可能因整个事务太大而使不能完成 或者 由于偶然的意外而使事务重做所需的时间太长 较好的解决方法是 把整个事务分解成几个较小的事务 再由应用程序控制整个系统的流程 这样 如果其中某个事务不成功 则只需重做该事务 因而既可节约时间 又可避免长事务

适当超前 计算机技术发展日新月异 数据库的设计必须具有一定前瞻性 不但要满足当前的应用要求 还要考虑未来的业务发展 同时必须有利于扩展或增加应用系统的处理功能