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

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

数据模型应满足三方面要求：一是能比较真实地模拟现实世界；二是容易为人所理解；三是便于在计算机上实现。数据结构、数据 *** 作和完整性约束是构成数据模型的三要素。数据模型主要包括网状模型、层次模型、关系模型等，它是按计算机系统的观点对数据建模，用于DBMS的实现。

121 层次模型

若用图来表示，层次模型是一棵倒立的树。在数据库中，满足以下条件的数据模型称为层次模型： ① 有且仅有一个结点无父结点，这个结点称为根结点； ② 其他结点有且仅有一个父结点。 根据层次模型的定义可以看到，这是一个典型的树型结构。结点层次从根开始定义，根为第一层，根的子结点为第二层，根为其子结点的父结点，同一父结点的子结点称为兄弟结点，没有子结点的结点称为叶结点。

122 网状模型

在现实世界中，事物之间的联系更多的是非层次关系的，用层次模型表示非树型结构是很不直接的，网状模型则可以克服这一弊病。网状模型是一个网络。在数据库中，满足以下两个条件的数据模型称为网状模型。 ① 允许一个以上的结点无父结点； ② 一个结点可以有多于一个的父结点。 从以上定义看出，网状模型构成了比层次结构复杂的网状结构。

123 关系模型

在关系模型中，数据的逻辑结构是一张二维表。

在数据库中，满足下列条件的二维表称为关系模型：

① 每一列中的分量是类型相同的数据；

② 列的顺序可以是任意的；

③ 行的顺序可以是任意的；

④ 表中的分量是不可再分割的最小数据项，即表中不允许有子表；

⑤ 表中的任意两行不能完全相同。

关系数据库采用关系模型作为数据的组织方式。 关系数据库因其严格的数学理论、使用简单灵活、数据独立性强等特点，而被公认为最有前途的一种数据库管理系统。它的发展十分迅速，目前已成为占据主导地位的数据库管理系统。自20世纪80年代以来，作为商品推出的数据库管理系统几乎都是关系型的，例如，Oracle，Sybase，Informix，Visual FoxPro等。

数据库管理系统常见的数据模型有层次模型、网状模型和关系模型 3种

数据模型是对现实世界数据的模拟，是一个研究工具，利用这个研究工具我们可以更好地把现实中的事物抽象为计算机可处理的数据。

层次模型：

层次模型以“树结构”表示数据之间的联系

层次模型是数据库系统最早使用的一种模型，它的数据结构是一棵“有向树”。根结点在最上端，层次最高，子结点在下，逐层排列。

层次模型的特征是：

在一个层次模型中的限制条件是：

（1）有且仅有一个节点，无父节点，它为树的根；（有且仅有一个结点没有双亲，该节点就是根结点。）

（2）其他节点有且仅有一个父节点。（根以外的其他结点有且仅有一个双亲结点）这就使得层次数据库系统只能直接处理一对多的实体关系。

（3）任何一个给定的记录值只有按照其路径查看时，才能显出它的全部意义，没有一个子女记录值能够脱离双亲记录值而独立存在。

比如：一个教师学生层次模型。该层次模型有4个记录类型，即实体。

被序列化后的对象存放到数据库中，或者将该对象对应的文件的路径存放到数据库中。

反序列化的时候按文件将代表对象的数据流读入内存，然后反序列化一个原来的对象就行了。

关于序列化和反序列化，可以参考这个例子。放在数据库中的情况，应该完全类似。

import javaioFileInputStream;

import javaioFileOutputStream;

import javaioObjectInputStream;

import javaioObjectOutputStream;

import javaioSerializable;

public class TestSerialization {

public static void main(String[] args) {

TestSerialization ts=new TestSerialization();

String serializationFile=tswriteObjectIntoFile(new KeyInfo("xm","xm'password"));

Systemoutprintln(tsgetObjectFromFile(serializationFile));

}

/

  对象序列化并写入到文件中

  @param info

 /

public String writeObjectIntoFile(KeyInfo info){

String objectFileName=SystemcurrentTimeMillis()+"-KeyInfo-Serializationout";

try {

FileOutputStream fos=new FileOutputStream(objectFileName);

ObjectOutputStream oos =new ObjectOutputStream(fos);

ooswriteObject(info);

oosflush();

oosclose();

} catch (Exception e) {

// TODO Auto-generated catch block

eprintStackTrace();

}

return SystemgetProperty("userdir")+Fileseparator+objectFileName;

}

/

  反序列化

  @param infoFile

  @return

 /

public KeyInfo getObjectFromFile(String infoFile){

try {

FileInputStream fis=new FileInputStream(infoFile);

ObjectInputStream ois=new ObjectInputStream(fis);

return (KeyInfo)oisreadObject();

} catch (Exception e) {

// TODO Auto-generated catch block

eprintStackTrace();

}

return null;

}

}

class KeyInfo implements Serializable {

/

 /

private static final long serialVersionUID = 1L;//如果更改了KeyInfo的任何地方，改变这个值。反序列就不会成功。

public String user;

public String pwd ;

/

  @return the user

 /

public String getUser() {

return user;

}

/

  @param user the user to set

 /

public void setUser(String user) {

thisuser = user;

}

/

  @return the pwd

 /

public String getPwd() {

return pwd;

}

/

  @param pwd the pwd to set

 /

public void setPwd(String pwd) {

thispwd = pwd;

}

public KeyInfo(String user, String pwd) {

super();

thisuser = user;

thispwd = pwd;

}

public KeyInfo() {

super();

// TODO Auto-generated constructor stub

}

/ (non-Javadoc)

  @see javalangObject#toString()

 /

@Override

public String toString() {

return "KeyInfo [user=" + user + ", pwd=" + pwd + "]";

}

大致的讲主要是根据用户的需求，然后设计数据库的E-R模型，然后将E-R模型图转换为各种表，并对其进行数据库设计范式（范式因不同书籍有不同）的审核，然后进行数据库的实施，然后运行维护。

一句话来讲就是将用户的需求变成带有各种关系的表，以及其它的数据库结构，然后供编程使用

具体如下：

按照规范设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下六个阶段

（1）需求分析。

（2）概念设计。

（3）逻辑设计。

（4）物理设计。

（5）数据库实施。

（6）数据库运行和维护。

5．1．1需求分析阶段

进行数据库设计首先必须准确了解与分析用户需求，包括数据与处理需求。需求分析是整个设计过程的基础，是最困难、最耗时的一步。作为“地基”的需求分析是否做得充分与准确，决定了在其上构建“数据库大厦”的速度与质量。需求分析做得不好，可能会导致整个数据库重新设计，因此，务必引起高度重视。

5．1．2概念模型设计阶段

在概念设计阶段，设计人员仅从用户角度看待数据及其处理要求和约束，产生一个反映用户观点的概念模式，也称为“组织模式”。概念模式能充分反映现实世界中实体间的联系，又是各种基本数据模型的共同基础，易于向关系模型转换。这样做有以下好处：

（1）数据库设计各阶段的任务相对单一化，设计复杂程度得到降低，便于组织管理。

（2）概念模式不受特定DBMS的限制，也独立于存储安排，因而比逻辑设计得到的模式更为稳定。

（3）概念模式不含具体的DBMS所附加的技术细节，更容易为用户所理解，因而能准确地反映用户的信息需求。

概念模型设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型。如采用基于E-R模型的数据库设计方法，该阶段即将所设计的对象抽象出E-R模型；如采用用户视图法，则应设计出不同的用户视图。

5．1．3逻辑模型设计阶段

逻辑模型设计阶段的任务是将概念模型设计阶段得到的基本E-R图，转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。如采用基于E-R模型的数据库设计方法，该阶段就是将所设计的E-R模型转换为某个DBMS所支持的数据模型；如采用用户视图法，则应进行表的规范化，列出所有的关键字以及用数据结构图描述表集合中的约束与联系，汇总各用户视图的设计结果，将所有的用户视图合成一个复杂的数据库系统。

5．1．4数据库物理设计阶段

数据库的物理结构主要指数据库的存储记录格式、存储记录安排和存取方法。显然，数据库的物理设计完全依赖于给定的硬件环境和数据库产品。在关系模型系统中，物理设计比较简单一些，因为文件形式是单记录类型文件，仅包含索引机制、空间大小、块的大小等内容。

物理设计可分五步完成，前三步涉及到物理结构设计，后两步涉及到约束和具体的程序设计：

（1）存储记录结构设计：包括记录的组成、数据项的类型、长度，以及逻辑记录到存储记录的映射。

（2）确定数据存放位置：可以把经常同时被访问的数据组合在一起，“记录聚簇（cluster）”技术能满足这个要求。

（3）存取方法的设计：存取路径分为主存取路径及辅存取路径，前者用于主键检索，后者用于辅助键检索。

（4）完整性和安全性考虑：设计者应在完整性、安全性、有效性和效率方面进行分析，作出权衡。

（5）程序设计：在逻辑数据库结构确定后，应用程序设计就应当随之开始。物理数据独立性的目的是消除由于物理结构的改变而引起对应用程序的修改。当物理独立性未得到保证时，可能会引发对程序的修改。

数据库物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构，包括存储结构和存取方法。

5．1．5数据库实施阶段

根据逻辑设计和物理设计的结果，在计算机系统上建立起实际数据库结构、装入数据、测试和试运行的过程称为数据库的实施阶段。实施阶段主要有三项工作。

（1）建立实际数据库结构。对描述逻辑设计和物理设计结果的程序即“源模式”，经DBMS编译成目标模式并执行后，便建立了实际的数据库结构。

（2）装入试验数据对应用程序进行调试。试验数据可以是实际数据，也可由手工生成或用随机数发生器生成。应使测试数据尽可能覆盖现实世界的各种情况。

（3）装入实际数据，进入试运行状态。测量系统的性能指标，是否符合设计目标。如果不符，则返回到前面，修改数据库的物理模型设计甚至逻辑模型设计。

5．1．6数据库运行和维护阶段

数据库系统正式运行，标志着数据库设计与应用开发工作的结束和维护阶段的开始。运行维护阶段的主要任务有四项：

（1）维护数据库的安全性与完整性：检查系统安全性是否受到侵犯，及时调整授权和密码，实施系统转储与备份，发生故障后及时恢复。

（2）监测并改善数据库运行性能：对数据库的存储空间状况及响应时间进行分析评价，结合用户反应确定改进措施。

（3）根据用户要求对数据库现有功能进行扩充。

（4）及时改正运行中发现的系统错误。

实体-联系模型（简称E-R模型）是由PPChen于1976年首先提出的。它提供不受任何DBMS约束的面向用户的表达方法，在数据库设计中被广泛用作数据建模的工具。E-R数据模型问世后，经历了许多修改和扩充，这儿仅介绍基本的E-R数据模型。

1221 E-R模型的结构

E-R模型的构成成分是实体集、属性和联系集，其表示方法如下：

（1） 实体集用矩形框表示，矩形框内写上实体名。

（2） 实体的属性用椭圆框表示，框内写上属性名，并用无向边与其实体集相连。

（3） 实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1—1、1—M或M—M。

因此，E-R模型也称为E-R图。例如系、学生和课程的联系的E-R模型

系、学生和课程作为实体集；一个系有多个学生，而一个学生仅属于一个系，所以系和课程之间是一对多的联系；一个学生可以选修多门课程，而一门课程有多个学生选修，所以学生和课程之间是多对多的联系。

1222 E-R模型对几种特殊的实体联系的表示

E-R模型在表示复杂实体和实体之间的复杂联系方面有较强的能力。除了可以明确表示二个实体集之间1—1、1—M或M—M的联系。还可以：

（1） 表示三个以上的实体集之间的联系。

例如，一个售货员（Salesperson）可以将多种商品（Goods）售给一个顾客（Customer），而一个售货员也可以将一种商品售给多个顾客；一个顾客的一种商品可以由多个售货员经售。售货员、商品和顾客三个实体集之间的联系是多对多的三元联系，其E-R模型表（2） 表示一个实体集内部的联系

例如，雇员（EMP）这个实体集中，总经理下设多个部门经理，而部门经理下面有多个雇员。因此，雇员这个实体集中实体之间存在一对多的联系，其E-R模型如图112所示。

（3） 表示二个实体集之间的多种联系

例如，雇员（EMP）和设备（EQUIP）之间可以有多种联系，一种联系是一个设备可以由多个雇员 *** 作(operation)，另一种联系是一个雇员可以维修(maintain)多个设备，其E-R模型1223 作E-R图的步骤

（1） 确定实体和实体的属性

（2） 确定实体之间的联系及联系的类型

（3） 给实体和联系加上属性

如何划分实体及其属性有两个原则可作参考：一是作为实体属性的事物本身没有再需要刻画的特征而且和其它实体没有联系。二是属性的一个值可以和多个实体对应，而不是相反。尽管E-R模型中的属性可以是单值属性也可以是多值属性，为简单计，多值属性常常被作为多个属性或作为一个实体（见第6章弱实体）。

例如，职工和部门，一般情况下，一个部门有多个职工，而一个职工仅属于一个部门。所以职工应作为实体，而部门既可作为职工的属性——部门本身仅有一个名称；也可以作为实体——部门具有部门号、部门名称及电话等，　再如，职工和工种，一个工种有多个职工，而一个职工仅属于一个工种，所以职工应作为实体，而工种既可作为职工的属性——工种本身仅有一个名称；也可以作为实体——工种和其它实体，例如和劳保用品有联系，如图115所示。

如何划分实体和联系也有一个原则可作参考：当描述发生在实体集之间的行为时，采用联系集。例如，读者和图书之间的借、还书行为，顾客和商品之间的购买行为，均应该作为联系集。

如何划分联系的属性：一是发生联系的实体的标识属性应作为联系的缺省属性，二是和联系中的所有实体都有关的属性。例如，学生和课程的选课联系中的成绩属性，顾客、商品和雇员之间的销售联系中的商品的数量等。

以上就是关于银行如何建设企业级数据库基础逻辑数据模型全部的内容，包括:银行如何建设企业级数据库基础逻辑数据模型、数据库逻辑模型类型、数据库模型的支持性说明文档怎样写等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！