数据库管理通用平台设计方案.docx

数据库管理通用平台设计方案.docx

《数据库管理通用平台设计方案.docx》由会员分享，可在线阅读，更多相关《数据库管理通用平台设计方案.docx（28页珍藏版）》请在冰豆网上搜索。

数据库管理通用平台设计方案

数据库管理通用平台设计方案

第一章绪论

1.1平台的需求分析

通用数据平台是一个支撑企业信息化数据集成的应用平台，需要在给企业用户提供便利、实用和强大的应用环境的同时，还提供统一信息交换，实现企业现有应用系统间数据的整合与集成。

企业信息化的过程就是要将企业运作处理的一切程序、资料变成信息资源，通过信息化的手段进行处理，这些信息资源就来源于企业的设计、工艺、生产、销售、采购等各个环节，完善这些环节的信息流的管理将直接加快企业处理信息的过程，从而提高企业的运行效率；而充分利用有效的信息工具，特别是采用统一的数据平台，可以加速企业的整个运作过程，从而达到降低成本的目的；在提高质量方面，信息工具所发挥的作用也是不可忽视的，它将大大减少人为处理过程中错误、误差，并提高准确率和精度。

在解决企业信息化的过程中，企业采用的信息化系统不尽相同，可能差异很大，包括系统的编写语言、开发工具、应用环境等等，通用数据平台所需解决的主要问题之一就是整合企业已有的数据资源，充分利用已有的信息，更好地为企业服务。

1.2总体功能目标

1.2.1支持异构数据库

支持国内外常用数据库异构；支持多库的网络分布，平台所联接的数据库可位于网络中不同的主机上支持不同类型数据库的热切换；平台所联接的数据库可在程序运行中更改，实现软切换。

连接和访问分布式数据库，提供数据的可靠传输，解决不同软硬件和网络环境中系统的通信问题，实现信息孤岛之间的联通。

1.2.2屏蔽数据库类型的差异性

对企业应用开发人员屏蔽不同数据库之间的差异。

开发人员只需要专注于业务需求，一次开发就可以应用于多种数据库系统，通过简单的配置就可以实现底层数据库的切换。

数据库可配置、定义，支持常用数据库：

SQL、ORACLE、VFP、ACCESS、EXCEL，以及国产数据库DM、OpenBASE等平台配置自动维护；由定义器完成平台的配置，数据库定义与具体类型无关；通过使用“库-视图-关联定义器”来实现基于平台的软件与数据库类型无关；能降低应用软件规划难度；实现大大减少应用软件的开发量。

1.2.3简化数据库访问

能结合配置和应用逻辑生成SQL语句；能根据部分新的要求产生完整的SQL语句；能产生复杂逻辑的SQL语句组合；能自动识别数据类型；生成符合格式的SQL语句；能提供尽可能多的错误拦截、识别、信息提示和存盘等功能。

实现对分布异构数据库的透明访问。

实现数据的集中和汇总，使不同格式、不同数据管理系统中的数据能够相互交流和转换。

保持已有系统的自治性，在使用数据应用开发平台的同时不影响已有系统的正常运行。

具有良好的开放性和适应性，能够适应向平台中增加新的数据库系统、数据库升级和企业业务需求变更等变化。

1.2.4实现多种业务逻辑

能动态生成和执行SQL语句；能产生和调用存储过程，由触发器等执行；调用底层API能获取数据库、表结构信息；实现动态业务逻辑变更提供面向对象的数据事务组件；供搭建应用程序构成复杂的数据服务逻辑。

1.2.5提供通用的数据管理方法

将常用的操作沉淀为程序资源，如：

插入、删除、更新、查找、筛选、统计等操作，规范数据操作接口；操作函数的参数格式统一，便于理解和可扩展；数据库升级只需改造平台，对应用程序几乎无影响；应用程序编程员不必太了解数据库技术；减少重复代码，实现一处维护多处受益。

1.3总体性能目标

通用数据平台要确保数据的有效性、机密性、完整性、安全性、可靠性，确保在日常维护或是意外崩溃时通用数据平台可以正常运转，确保系统单个服务故障不影响通用数据平台的运行。

平台提供系统运行日志，记录平台运行状况，提供平台维护工具；采用统一的标准数据总线及功能丰富、面向应用的集成代理机制，来确保平台具有足够的可扩展性。

通用数据平台适应国产主流的数据库：

DM、OpenBASE、KingBASE，以及国际主流数据库Oracle，MSSQLServer等。

1.3.1业务系统与数据库的分离

平台支持用户自定义业务系统的相应的功能，留出二次开发的接口供用户在平台的基础上进行开发。

如PDM等系统可以充分利用平台现有的接口，进行相关的业务系统的开发。

1.3.2实现不同应用

业务系统与平台部分分离，实现业务应用的动态启动和停止。

平台利用服务监听器这一机构可以实现：

当一个业务应用启动的时候，平台会将属于这个业务应用的用户数据源启动；当一个业务应用停止的时候，平台会将属于这个业务应用的用户数据源关闭。

1.3.3支持分布式应用

支持分布式运行方式，但只维护一份配置文件，平台使用配置管理器来统一读取系统的配置信息，平台的各种分布式的组件在启动的时候会自动连接到一个运行的配置管理器来获得必要的信息。

1.3.4集成化的平台管理工具

提供完善的图形化的管理工具，其中集成了对业务应用的所有功能进行管理，业务数据的备份/恢复，数据源的配置，用户的权限管理工具，数据库对象的创建/修改/删除。

1.3.5在线日志管理

平台日志系统要为用户提供独立可配置可扩展的日志输出机制。

基于通用数据平台进行二次开发的时候，对调试信息进行追踪记录。

定义好追踪等级，对平台事件进行归类，提供统一的事件代号。

平台运行过程中，对平台以及架构在平台之上的业务系统进行跟踪，记录重要的改变，并给出相应的恢复提示。

1.3.6分布式事务支持

平台的事务处理功能模块要保证在一个工作单元中的数据的完整性，构造平台自己的事务管理机制，简化分布式应用的构造，并且可以为用户提供跨多种数据库的分布式事务处理，实现了两阶段提交协议，保证数据的完整性和一致性。

1.3.7通用业务逻辑对象管理及其调用

平台使用通用对象模板技术，提供通用数据对象的定义、存储、编辑、查询、统计工具，统一规范、共用资源。

更好的进行资源的管理，为快速部署信息化领域的解决方案提供技术支持。

第二章通用数据平台体系结构

2.1体系架构

本课题基于对国产数据库技术的研究，从制造业信息化企业应用软件的需求入手，结合中小型制造业企业的特点，提出并实现了面向中小企业的基于国产数据库的制造业信息化应用软件集成理论和实现的技术路线。

项目构建基于国产数据库的通用数据平台，提供基于国外数据库和国产数据库的应用软件的整体解决方案。

通用数据平台架构在应用程序和数据库的中间，见图3.1。

负责应用程序与数据库服务器直接的通信，应用逻辑（SQL语句解析，数据提取，事务控制等）在通用数据平台这个中间层进行处理，业务逻辑在中间层进行维护和实现，避免了因业务变动而对众多应用程序产生的冲击。

图2.1基于国产数据库的制造业信息化应用软件的体系架构

2.2技术路线

课题立足于跟踪数据库应用技术的发展和研发数据库连接的通用数据平台技术——开目数据平台（KMDP）。

KMDP不仅要充分利用数据库的SQL、范式等标准访问不同的数据库，而且可以超越数据库的差异，通过一种统一的自然语言（KMSQL），识别数据库类型，充分利用不同数据库所提供的核心技术。

KMDP要能够为开目产品系列提供对数据库的分布、安全性、效率、面向业务的对象数据操作、数据分析、数据自维护、数据检验、数据库对象动态生成、数据柔性化等高级的一体化解决方案。

KMDP是一种服务于开目全线产品的通用开发平台和运行支撑平台，故总是跟踪数据库的最新技术，以满足开目产品发展的需要。

KMDP基于平台和组件化技术，通过ODBC/OLEDB/JDBC及其API访问数据库，它主要提供语义翻译、数据缓冲、错误拦截、业务数据批处理等预处理和后续处理功能。

2.3通用数据平台模式

图2.2构架在应用与数据库间的中间层数据平台模式

2.4通用数据平台主要模块以及工作流程

通用数据平台的最主要的目的是在分布异构数据库之上为用户提供一个开放的、统一的信息处理环境，允许用户使用统一的接口存取分布、异构的多个数据库上的数据。

整个通用数据平台采用客户-通用数据平台-服务器三层体系结构。

一个完整的应用系统分为三层：

用户应用层（CAPP、PDM等应用程序，应用程序接口）、数据服务层（存储过程解析/转换、数据库备份与恢复、安全管理、数据管理、模式管理、数据库代理）和基础设施层（平台引擎）。

用户应用层包括用户在平台基础上建立起来的应用系统（开目PDM等应用软件系统），以及在应用和通用数据平台之间的应用程序接口；数据服务层为用户应用提供透明数据访问和存取服务，是应用和分布数据库之间的桥梁；基础设施层包括平台引擎中的内存对象、SQL解析等。

通用数据平台的最终目的是在用户应用层和基础设施层之间建立透明的服务，处于中间层次的数据服务层是系统的关键。

通用数据平台在分布异构数据库系统之上建立了一套全局模式，在顶层为用户提供一个统一的视图，底层数据库的分布和异构对顶层用户是透明的，用户可以像使用一个数据库一样使用分布异构数据系统[12]。

用户对局部数据库的操作通过统一的用户视图进行，操作以全局事务的形式提交给平台系统。

全局事务使用全局模式表示，是针对全局数据进行的操作。

通用数据平台的框架见图3.3。

通用数据平台的主要模块如下：

2.4.1平台引擎

通用平台的基础设施，在内存中以通用对象模板来组织内存对象，实现通用数据平台的SQL解析，对异构数据库的数据对象提供通用的操作。

2.4.2异种数据库存储过程解析/转换

以自定义的KMSQL中性语言为基础，实现异种数据库存储过程之间的相互转换，实现一次编写，各数据库环境下运行。

2.4.3数据库备份与恢复模块

基于平台引擎的内存数据对象，以及内存索引对象，定义了一套通用的数据对象模板，并定义了一种通用的数据文件，用于存储异构数据库的数据。

基于对象模板和通用数据文件实现了异种数据库之间数据的导入/导出。

2.4.4安全管理模块

以RBAC（Role-BasedAccessControl-RBAC）模型为基础，实现对异构数据库数据的访问权限控制，防止非法用户越权访问数据。

2.4.5其它模块

数据管理、模式管理、数据库代理等模块实现对异构数据库数据的一般业务逻辑

操作，包括数据创建与删除等。

2.4.6平台工作流程

平台的工作过程如下：

用户应用使用内嵌SQL语句的高级程序语言向平台提交数据服务请求，查询管理器的语言解释器模块根据全局模式对服务请求语句进行分析和验证，经过完整性检查和初步的优化后得到全局查询计划。

全局查询计划是使用全局模式表示的，必须分解到相应的局部数据库去执行，这部分工作由查询分解器完成。

当一个局部数据库的查询语言与全局查询语言不同时，还需要进行查询转换。

经过查询转换后得到了可以在局部数据库执行的一系列子查询，这些子查询经过事务处理器的协调，得到了和原全局查询等价的事务系列，这些事务系列送交各局部数据库执行，返回的数据经由数据管理器进行合并等操作，最后返回给用户应用程序。

图2.3应用开发平台的框架（主要模块），以及各模块间的相互关系

第三章元数据库的设计与实现

任何一个管理信息系统访问数据库方式无非就是查询、增加、删除、修改等几类操作，所不同的只是所访问具体数据的实际意义不同而已。

所谓的数据库通用平台就是抛开具体的查询、增加、删除、修改，设计出一个适合各种不同意义数据的通用平台，这样在进行具体的访问时，只需要调用这个通用平台并配置相应的参数，就可以实现所需要的功能。

对于这样的访问方式，传统意义的数据库设计满足不了，因为传统的数据库设计都是针对于具体的数据设计的。

这里就引入了元数据的概念。

元数据是关于数据的数据。

它是一种广泛存在的现象，在许多领域有其具体的定义和应用。

在软件开发领域，元数据被定义为:

在程序中不是被加工的对象，而是通过其值的改变来改变程序的行为的数据。

它在运行过程中起着以解释方式控制程序行为的作用。

在程序的不同位置配置不同值的元数据，就可以得到与原来等价的程序行为。

元数据描述数据的结构和意义，就象描述应用程序和进程的结构和意义一样。

元数据是抽象概念。

当人们描述现实世界的现象时，就会产生抽象信息，这些抽象信息便可以看作是元数据。

例如，在描述风、雨和阳光这些自然现象时，就需要使用”天气“这类抽象概念。

还可以通过定义温度、降水量和湿度等概念对天气作进一步的抽象概括。

在数据设计过程中，也使用抽象术语描述现实世界的各种现象。

在本系统中元数据库存储了数据库通用支撑层的控制和描述信息，包括关于菜单结构、服务关联、数据处理和访问的控制以及客户端显示等方面的元数据。

是整个平台能够实现统一处理的基础和关键部分。

在元数据库中包含的关键数据表有服务元数据表、组织结构元数据表、基表查询元数据表、基表查询列信息数据表等，下面分别介绍。

3.1服务元数据表

服务元数据表是一记录每一个服务的描述信息。

其表结构如表4-1所示。

表3-1服务元数据表

表3-1服务元数据表（续）

在这个表里，服务标识码是主键，唯一标识了每一个定制的服务，通过这个服务标识码的命名必须遵循提前约定的规则，使服务处理模块能根据服务标识码确定要操作的基表;服务名称、服务描述记录了一些辅助的描述信息;服务相对路径和服务文件名记录了提供服务的程序地址。

当系统需要添加新功能时，首先通过通用平台提供的定制界面进行定制，也就是设置相应参数，然后将这些参数保存到这个表里，这样就为以后的服务处理模块提供了入口参数。

3.2组织结构元数据表

组织结构元数据表主要记录关于管理信息系统菜单结构以及与服务关联的信息，为菜单的自动生成和处理提供参数数据，系统中每一条菜单项在组织结构元数据表中对应一条记录说明。

其表结构如表3-2所示。

表3-2组织结构元数据表

表3-2组织结构元数据表（续）

其中菜单项标识码是主键，唯一标识每个菜单项;菜单采用树型结构，所以用父结点标识码记录上一级菜单，结点顺序号和菜单名称记录了菜单在客户端展现的情况;节点类型记录了菜单的类别，如根节点、中间节点、叶子节点等不同的节点类型。

服务标识码提供了与服务元数据表相关联的接口，也就是菜单所对应的服务。

通过数据库表之间的关联关系，找到菜单所对应的服务的元数据，通过这些元数据，就能对菜单进行统一的显示和处理。

3.3基表查询元数据表

基表查询元数据表是为了定制查询服务而建立的表结构。

该表主要存储了每一个查询服务与基表或视图之间的映射关系。

其表结构如表3-3所示。

表3-3基表查询元数据表

每一类查询在此表中有一条记录说明，表中的查询标识字段是主键，唯一标识每一类查询。

查询表名记录要访问的基表或视图，其它字段都是记录与查询相关的辅助信息，比如查询涉及到的某些隐含查询条件等等。

3.4基表查询列信息数据表

基表查询列信息数据表定义了每一个查询服务中各列与相应的基表各列之间的一一映射关系。

也就是说这个表中记录了查询的结果显示在客户端的具体形式的控制信息，比如:

数据类型、长度、取值范围等等详细信息。

具体的表结构如表4-4所示。

表3-4基表查询列信息数据表

表3—4基表查询列信息数据表（续）

基表查询列信息数据表与基表查询元数据表之间通过查询标识关联，是多对一的关系。

基表查询元数据表记录了定制的服务与基表之间的映射关系，但查询毕竟是要对基表中的相关字段进行处理，所以就用基表查询列信息数据表记录基表中每一列查询的详细信息数据，在要查询的基表中有多少列，基表查询列信息数据表中就会有多少个表与之对应，因而是一对多的关系。

在一个管理信息系统中的查询会因需求的不同而不同，因而基表查询列信息数据表是元数据库中最复杂的一个表。

可以把表中的信息分成四类:

一类是一般性信息:

列名、列序号、列描述、列数据类型、列长度、列小数位等。

这些基本与基表中的信息一致。

第二类是与查询条件相关的数据。

查询条件列标志，用于描述与列相关的查询条件约束:

是否作为查询条件，精确查询还是模糊查询等等。

这些信息分别用不同的值表示。

超级链接类型和超级链接查询标识是定义是否需要根据此列深入查询详细内容，如果需要则定义超级链接查询主键和超级链接查询值列。

第三类是定义在客户端显示的字段及其显示形式。

浏览标志定义了该列是否需要在查询结果中显示出来。

当在屏幕上此列位置显示的结果不是这列存储的原始信息，而是需要根据此列进行转换的信息时，就用到了列类型、查找表主列、查找表名、查找表结果列这几个字段。

比如性别，在数据库基本信息表中，用数字0或1表示男女性别，但是当显示在客户端时，如果还是用0,1表示性别，对客户来说界面就不友好，这时就需要转换成汉字形式。

初值、查询条件初值分别是在查询页面和更新页面中所显示出的初值。

还有显示对齐方式、显示颜色等级等字段为此列在显示时的一些细节信息。

第四类是为字段的修改做准备的，主要有修改标志这个字段。

如果要修改表中的某一个字段，就定义这个修改列标志。

第四章数据库通用平台的设计与实现

数据库通用平台的关键部分除了元数据库的设计外，还有数据库通用支撑层。

这个支撑层是介于数据库层和应用层之间的一个中间层，也可以说这个支撑层是数据库与实际应用之间的一个桥梁。

无论是在开发一个新的管理信息系统还是为己有的系统增加新功能，只要按照数据库通用平台的规则配置相应的参数，该平台就能自动的连接数据库，进行数据处理，开发者并不需要去关心数据库详细操作。

这样就会减少很多重复编码，给开发者、系统维护者带来了极大的方便。

数据库通用支撑层主要包括基础模块、服务定制模块和服务处理模块三大部分。

基础模块主要功能是数据库的连接、关闭，所有对数据库的操作都是基于这个模块。

服务定制主要是为管理信息系统的开发人员和系统维护人员设置的。

对于开发一个新系统的情况，需要先把定制服务模块移植到系统中，然后再根据需求分析在定制服务模块进行相关的定制，服务处理模块就会根据这些定制信息进行处理并在前台展现出来;对于系统维护的情况来说，定制服务模块已经包含在系统里，只要定制新加的功能就可以了。

服务处理模块的功能就是在系统运行时，根据服务定制模块定制的参数（这些参数保存在元数据库中）进行统一处理。

下面分别介绍这三个模块的设计与实现。

本通用平台虽然是一个相对独立的构件，但在应用中必须与具体的管理信息系统集成才能实现其功能，所以关于本平台的测试信息将在第六章介绍。

4.1数据库接入技术

应用程序与后台数据库的交互是通过数据库的接入技术来实现的，对于管理信息系统来说，访问数据库是最重要的一个环节。

各种开发工具或者程序设计语言连接数据库的技术不一样，现今有很多的组件来实现，使得数据库的访问和操作变得更加高效和快捷。

在本数据库通用平台中，访问数据库是通过JDBCLJavaDatabaseConnectivity）接口进行的。

JDBC是一种可用于执行SQL语句的Java语言的数据库访问接口，它由一些Java语言编写的类和界面组成。

JDBC为数据库应用开发人员、数据库前台工具开发人员提供了一种标准的应用程序设计接口，使开发人员可以用纯Java语言编写完整的数据库应用程序。

由于Java语言与平台无关，所以利用JDBCAPI写成的访问数据库的程序具有很好的通用性，移植方便。

通过使用JDBC，开发人员可以很方便地将SQL语句传送给几乎任何一种数据库。

用JDBC写的程序能够自动地将SQL语句传送给相应的数据库管理系统（DBMS。

不但如此使用Java编写的应用程序可以在任何支持Java的平台上运行，不必在不同的平台上编写不同的应用。

Java和JDBC的结合可以让开发人员在开发数据库应用时真正实现“WriteOnce，RunEverywhere!

"

Java具有健壮、安全、易用等特性，而且支持自动网上下载，本质上是一种很好的数据库应用的编程语言。

它所需要的是Java应用如何同各种各样的数据库连接，JDBC正是实现这种连接的关键。

1.JDBC的任务

简单地说，JDBC能完成下列三件事:

1）与数据库建立连接;

2）向数据库发送SQL语句;

3）处理数据库返回的结果。

2.JDBC:

一种底层的API

JDBC是一种底层AP1，这意味着它将直接调用SQL命令。

JDBC完全能胜任这个任务，而且比其它数据库互联更加容易实现。

同时它也是构造高层AFI和数据库开发工具的基础。

高层API和数据库开发工具应该是用户界面更加友好，使用更加方便，更易于理解的。

但所有这样的API将最终被翻译为象JDBC这样的底层API。

目前两种基于JDBC的高层API正处在开发阶段。

3.JDBC两层模型和三层模型

JDBC支持两层模型，也支持三层模型访问数据库。

两层模型中，一个JavaApplet或者一个Java应用直接同数据库连接。

这就需要能直接被访问的数据库进行连接的JDBC驱动器。

用户的SQL语句被传送给数据库，而这些语句执行的结果将被传回给用户。

在三层模型中，命令将被发送到服务的“中间层”，而“中间层”将SQL语句发送到数据库。

数据库处理SQL语句并将结果返回“中间层”，然后“中间层”将它们返回用户。

“中间层”一个优势是可以进行对访问的控制并协同数据库的更新，另一个优势就是如果有一个“中间层”用户就可以使用一个易用的高层的API，这个API可以由“中间层”进行转换，转换成底层的调用。

而且，在许多情况下，三层模型可以提供更好的性能。

JDBC是允许从一个java“中间层”访问数据库的接口。

使用JDBC连接数据库方式如图4-1所示:

图4-1JDBC连接数据库方式

在JDBC中，连接通过java.sql.Connection接口实现。

连接是通过调用驱动程序的Connection（连接）方法获得的。

创建一个连接后，可以调用它的方法获得和设置连接选项、管理事务和创建statement（语句）对象。

4.2基础模块

在JavaBean中每一次需要数据库操作时都要进行一系列相同的操作:

设置驱动程序，连接数据库，生成一条SQL语句，对数据进行处理，最后断开与数据库的连接。

将这些操作全部放到每一个JavaBean中是非常繁琐的，因此有必要把数据库的连接和断开放到一个独立的JavaBean中，在其它JavaBean中需要对数据库操作时，可以利用面向对象设计方法的继承机制，只要继承这个基础模块，就可以直接调用这个基础模块提供的函数完成数据库连接、断开操作、数据处理等，不用再写相应的代码，只要组织出不同的SQL语句就可以了。

从而提高了代码的重用性。

由于每一条SQL操作语句都要使用JavaBean连接数据库，当JSP页面或者JavaBean需要频繁访问数据库时，必然频繁的连接与断开数据库。

一般管理信息系统是面向很多用户的，对系统频繁的访问更是显得很突出，连接数据库不仅要开销一定的通信和内存资源，还必须完成用户验证、安全上下文配置等任务，因而往往成为最为耗时的操作。

为了提高系统效率，本通用平台采用了数据库连接池。

所谓数据库连接池就是一个存储数据库连接的容器，当应用程序需要连接数据库时，就直接从连接池中获取一个连接，当使用结束时，再将连接归还给连接池。

这样一个数据库连接可以被很多应用程序的实例共享，无需每次与数据库交互时都进行数据库的连接和断开，可以大大提高访问数据库的速度。

一个数据库连接池应具备以下功能:

1.连接池能够存储多个有效连接;

2.能够为其它方法提供有效连接;

3.能够验证连接是否正常;

4.能够取回使用过的连接;

5.如果连接池中没有可用连接，而此时使用中的连接数小于最大连接数，那么就创建新的连接提供给应用程序;

6.连接池关闭时关闭所有连接。

本系统中连接的数据库都是使用JDBC驱动器的，数据库连接池是由Web服务器Weblogic提供的。

Weblogic为开发人员提供了用来处理数据库连接的JDBC驱动程序，使每个数据库客户端共同分享一个或一个以上的数据库连接，从而可以提高程序的执行效率和减轻数据库服务器的负担。

We