环保局统一污染源数据库方案书.doc

《环保局统一污染源数据库方案书.doc》由会员分享，可在线阅读，更多相关《环保局统一污染源数据库方案书.doc（53页珍藏版）》请在三一办公上搜索。

1、环保局统一污染源数据库方案书第一章.公司介绍7第二章.环保局信息系统分析82.1 环保局信息系统现状82.1.1产生的问题82.1.2 问题产生的原因92.1.3结论102.2 需求分析102.2.1“统一污染源数据库”定义102.2.2统一污染源数据库的数据102.2.3处室-系统-数据对应关系112.2.4各处室与统一污染源数据的关系122.2.5数据整合和集成需求122.3 统一污染源数据库实质上是一个部门级数据仓库.142.4 统一污染源数据库是环保局信息门户的先锋.152.5 需求的总结16统一数据16统一操作界面16统一认证17统一接口.17第三章.系统解决方案183.1 系统解决

2、方案原则183.1.1可扩充性183.1.2易维护性183.1.3安全性183.1.4合理性183.1.5开放性183.2 技术路线183.3业务体系结构193.3.1污染源数据内容233.3.2基础数据库243.3.3数据仓库243.3.4地理信息系统243.3.5信息门户综合发布系统253.3.6综合办公系统253.4技术体系结构25第四章 污染源统一数据库274.1 数据库设计274.1.1 数据库设计主线274.1.2 数据库规范化设计304.1.3 粒度设计324.1.4 元数据管理。324.1.5 性能优化344.2 ETL(抽取.转换.装载)354.2.1 抽取374.2.2 转

3、换和清洗384.2.3 装载384.2.4 自动调度394.3 OLAP(联机在线分析)394.4 表现层404.4.1 表现层结构404.4.2 表现层功能41第五章 信息门户设计435.1 信息门户的概念435.2 Athene信息门户系统.435.2.1底层数据信息存储445.2.2内容管理整合445.3 Athene信息门户特点.45第六章 其他功能设计476.1 外围接口设计476.1.2 接口分类.486.2 备份设计486.2.1日常备份486.2.2 计划内下线496.2.3 数据恢复49第七章 系统特点49第八章 项目的组织和实施508.1 组织机构及职责508.1.1项目经

4、理508.1.2专家顾问组508.1.3项目执行组508.1.4业务组508.1.5软件开发组518.1.6测试验收组518.1.7 文档组518.1.8支持组518.2 实施方法528.3 项目实施计划538.4培训计划538.4.1培训对象与目标：538.4.2培训内容54第九章 技术支持和服务55共同制订明确的服务和支持计划55系统维护的承诺55热线服务系统55客户档案管理55常规性维护服务55应用软件服务的承诺56技术转移56技术文档移交56第一章.公司介绍第二章.环保局信息系统分析2.1 环保局信息系统现状随着数据库技术的广泛运用，环保局信息系统的运营环境逐渐转化为以数据库为中心的运

5、营环境。同时因为环保局内部对数据的需求是多方面的，所以根据工作职能的不同而建立了部门级的数据库。比如监督处关注环保局环境监督管理，许可证的管理，因此建立了环保业务系统；监理所关注排污收费，现场检查，接受投诉纠纷等内容，因此建立了排污收费系统，监控中心系统；监测站关注监测数据所以有了监测系统；而由于根据不同环保局不同部门管理的现状，在监督处、监理所，各区分局内部都是用了同一套排污申报系统.随着环保局信息化建设的深入以及各部门的业务联系的需求，部门与部门之间的数据交互日益增多，比如在监理所的业务流程中需要监测站的监测数据，需要监督处的许可证数据；监督处需要察看监理所监测到的环保局违规数据；信息中心

6、需要将各部门的排污申报数据进行汇总，以供上层领导参考。于是环保局内部系统也都做出了数据抽取的努力和尝试，例如监理所系统中增加监测数据的接口、审批资料接口；结合gis系统建立了污染源信息汇总的一套查询系统以供内部使用等等。2.1.1产生的问题可以看出，随着数据的交互抽取，很可能会形成“蜘蛛网”现象，使得数据的抽取和访问显得错综复杂。这种演变不是人为制造的，而是自然演变的结果，如果不在体系结构上进行调整，“蜘蛛网”问题将会越来越严重。因为错综复杂的抽取与访问将会产生很多问题：2.1.1.1、数据分析的结果缺乏可靠性例如在环保局内部存在着多套排污申报系统，不同部门各自进行汇总的信息与统一汇总的信息经

7、常会不一致，这样在领导面前就会出现不一致，缺乏可靠性的数据。2.1.1.2、数据处理的效率低下在错综复杂的体系结构中，不同级别的数据库可能使用不同类型的数据库系统，环保局内部就存在了sqlserver，sybase，foxpro等等数据库，根据各种不同数据库的开发工具的不同，抽取程序应用的技术不同，因而难以集成。2.1.1.3、数据共享困难对于大量的数据不能提供一个统一的数据接口，不能采用一种通用的标准和规范（如使用不同的指标代码体系和编码体系），共享通用的数据源。随着业务的增加，管理人员的操作越来越复杂，操作越来越多，用户分散，相互联系程度低，信息相对封闭，共享程度低2.1.1.4、难以将数

8、据转化为信息此外，“蜘蛛网”式的结构还难以将数据转化为决策信息。因为每个数据库由于其数据量和业务处理的需求不同，同时对历史数据的存储时间也不同，因此以现有的数据库系统难以提供完整的历史数据。鉴于这样的原因，用户根本不可能从这些数据中提取出完整的信息。例如污染源执法系统所提供的数据就不能够满足统一污染源的需求。2.1.2 问题产生的原因最根本的原因是由于各业务系统建设和实施数据管理系统的阶段性、技术性以及其它经济和人为因素等因素影响，导致在发展过程中积累了大量采用不同存储方式的业务数据，包括采用的数据管理系统也大不相同，从简单的文件数据库到复杂的网络数据库，它们构成了环保局的异构数据源。这些分散

9、的不同业务的数据管理系统虽然能够满足业务数据存储和管理要求，但在许多情况下，为作出一个决策，可能需要访问分布在网络不同位置上的多个业务数据管理系统中的数据。环保局数据源异构性主要表现在两方面：2.1.2.1、系统异构即数据源所依赖的业务应用系统、数据库管理系统乃至操作系统之间的不同构成了系统异构。2.1.2.2、模式异构即数据源在存储模式上的不同。存储模式主要包括关系模式、对象模式、对象关系模式和文档嵌套模式等几种，其中关系模式（关系数据库）为主流存储模式。同时，即便是同一类存储模式，它们的模式结构可能也存在着差异。例如不同的关系数据管理系统的数据类型等方面并不是完全一致的，如DB2、Orac

10、le、Sybase、Informix、SQLServer、Foxpro等。2.1.2.3、来源异构即环保局内部数据源和外部数据源之间的异构。2.1.3结论异构数据源的整和、集成是环保局信息化建设过程经常遇到的一个现实问题。也是制约环保局各种应用信息系统建设和数据共享程度，以及信息化建设投资重复或负担重的一个重要因素。由此可知，解决好现阶段环保局信息系统整合的问题，必须要建立一套基于整体、集成各个业务异构数据源的综合信息仓库，包括信息基础数据库和一个强大的分布式应用系统。2.2 需求分析针对环保局现有整体系统结构比较复杂，业务系统多的情况，建立环境基础数据库及在该基础数据库上开展的分布式应用系统

11、需要对现有业务系统需求进行详细地分析。2.2.1“统一污染源数据库”定义“统一污染源数据库”可以从两方面来理解。首先，该系统是一“数据库”，其存储的数据包括了污染源的所有相关信息。将原有各个系统的数据进行收集和格式转化，实现数据的统一集中管理，以改善目前环境信息存在的利用率低、共享程度差等问题。其次，该系统注重的是“统一”，因为现有污染源相关的数据来源比较多，多处存在数据不一致的情况，因此有必要通过数据的抽取、过滤、转换成为统一的，标准的数据，并把原来面向事务的数据结构转化为面向分析和决策的结构，这样才能够使得数据共享变得有意义，同时也便于利用统一后的数据进行分析，统计，决策。从这一立场来看，

12、“统一污染源数据库”可以看成是面向“污染源”主题的数据仓库的建立。2.2.2统一污染源数据库的数据统一污染源数据库的数据是原有业务系统中涉及到污染源信息的主要业务流程产生的数据，换句话说就是确定哪些信息内容需要纳入到统一污染源数据库，也就是在统一污染源数据库上集中管理的内容。通过对环保局内部系统的详细了解，我们初步确定了以下业务流程数据：从上图中可以看到统一污染源数据库应该包括的信息数据，这些数据分散在各个处室，不同处室不仅使用不同的系统，也有可能使用相同的系统单机版（比如排污申报软件）。2.2.3处室-系统-数据对应关系下图表明了上述污染源相关数据与环保局内各处室、业务系统的对应关系：上图每

13、一纵列中的绿色模块表示处室部门，黄色模块表示该部门该部门使用的业务系统，白色模块表示该业务系统中包含的与污染源相关的信息数据。由上面两张图可以大致归纳出统一污染源数据库需要集中管理的内容包括：1、污染源审批信息（审批清单、环保设施、产品原材料、验收信息）2、排污申报（水气声渣申报、水气声渣统计）3、排污许可证（排放量、年审信息）4、排污收费（每月每年排污费统计）5、现场检查（统计信息、投诉信息）6、污染源监测信息（监测报告）7、环境统计信息8、固体废物处理信息9、环境执法信息（限期整改、整治、罚款、停业 立案-审议-处罚决定）2.2.4各处室与统一污染源数据的关系当统一污染源数据库之后，各处室

14、可以：向统一污染源数据库提供其自身拥有的相关数据从统一数据库中得到更为一致性，全面的业务数据从统一数据库中得到其他处室提供的业务数据因此，从信息共享的角度来看，各处室对上述不同信息的关注程度是不一样的。下图中大致表明了各处室关注统一污染源数据库中的那些数据：2.2.5数据整合和集成需求对各处室的异构数据源数据进行整合、集成成为统一污染源数据库的目的是为环保局提供综合的、统一的、安全的、快捷的信息查询、数据挖掘和决策支持服务。为了满足这个需求条件，各处室整合、集成后的数据必须保证一定的集成性、完整性、一致性和访问安全性。2.2.5.1、集成性各种原先孤立的业务信息系统数据经过整合、集成后，应该达

15、到查询一个综合信息不必再到各个处室业务系统中进行分别查询和人工处理，只要在整合、集成后的数据信息仓库中就可以直接访问到，即整合、集成后的综合信息仓库的数据是各异构业务数据的有机集成和关联存储（整合、发掘出各业务数据间的内在关联关系），而不是简单、孤立的堆放在一个数据库系统里。2.2.5.2、完整性包括数据完整性和约束完整性两方面。数据完整性是指完整提取数据本身，约束完整性，约束是指数据与数据之间的关联关系，是唯一表征数据间逻辑的特征。保证约束的完整性是良好的数据发布和交换的前提，可以方便数据处理过程，提高效率。2.2.5.3、一致性不同业务信息资源之间存在着语义上的区别。这些语义上的不同会引起

16、各种不完整甚至错误信息的产生，从简单的名字语义冲突（不同的名字代表相同的概念），到复杂的结构语义冲突（不同的模型表达同样的信息）。语义冲突会带来数据集成结果的冗余，干扰数据处理、发布和交换。整合、集成后的数据应该根据一定的数据转换模式和商业规则进行统一数据结构和字段语义编码转换。2.2.5.4、访问安全性由于数据库资源可能归属不同的单位，各业务数据系统有着各自的用户权限管理模式，访问和安全管理很不方便，不能集中、统一管理，所以保证在访问异构数据源数据基础上保障原有数据库的权限不被侵犯，实现对原有数据源访问权限的隔离和控制，就需要设计基于整合、集成后的综合信息仓库的统一的用户安全管理模式来解决此

17、问题。 综上所述，异构数据源的整合与集成如下图所示：2.3 统一污染源数据库实质上是一个部门级数据仓库.在分析过程中,我们发现污染源统一数据库有以下的特点.1 面向决策分析的.2 污染源信息的集成性.3 面向污染源主题的4 相对稳定5 反映历史变化同时,我们注意到美国著名信息工程学家W.H.Inmon在建立数据仓库一书中对数据仓库做了如下定义：“数据仓库（Data Warehouse）是一个面向主题的、集成的、稳定的、包含历史数据的数据集合，它用于支持管理中的决策制定过程。”所谓主题，它是数据归类的标准，每个主题对应一个客观分析领域，如销售状况、人事状况、整个企业的利润状况等。它可以辅助决策集

18、成多个部门不同系统的大量数据。所谓面向主题，是指数据仓库内的信息是按主题进行组织的，为按主题进行决策的过程提供信息。 所谓集成，是指数据仓库中的信息不是从各个业务处理系统中简单抽取出来的，而是经过系统加工、汇总和整理，以确保数据仓库内的信息是关于整个企业的一致的全局信息。 所谓稳定，是指一旦某个数据进入数据仓库，一般情况下将被长期保留，也就是数据仓库中一般有大量的插入和查询操作，但修改和删除操作很少。 所谓包含历史数据，是指数据仓库内的信息并不只是关于企业当时或某一时点的信息，而是系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程

19、和未来趋势做出定量分析和预测。这样,我们有理由认为,统一污染源数据库在应用的实质意义上就是基于污染源管理的部门级数据仓库.污染源数据仓库的建立主要是针对污染源的管理进行一系列的分析,以便于局领导作出有效的决策.将统一污染源数据库上升为污染源数据仓库的概念,有利于指导统一污染源数据库在整体上的规划,同时,利用数据仓库现有的开发技术,可以有效的确定用户需求,快速的开发出高效,稳定的产品.第一， 数据仓库有效集成了企业的业务数据，提供了标准的报表和图表的功能。数据仓库的报表和图表是关于整个企业集成信息的报表和图表，其中的数据可来源于不同的多个事务处理系统。从而为企业提供了按照主题的多方位的决策支持。

20、 第二， 数据仓库可以对分布在不同系统的业务数据进行清洗和加工。数据仓库的源数据可能来自许多异构的事务处理系统，它们具有不同的数据格式和数据存储管理组织，数据仓库可以按照面向主题的原则对这些数据进行清洗和加工，使它们成为统一格式的易于使用的支持决策的数据。 第三， 数据仓库支持多维分析。多维分析是通过把一个实体的多项重要的属性定义为多个维度，使得用户能方便地汇总数据集，简化了数据的分析处理逻辑，并能对不同维度值的数据进行比较，而维度则表示了对信息的不同理解角度，例如，时间和地理区域是经常采用的维度。应用多维分析可以在一个查询中对不同阶段的数据进行纵向或横向比较，这在决策过程中非常有用。 第四，

21、 数据仓库技术可以帮助企业决策者对企业未来状况作出预测。数据挖掘技术是数据仓库表现的关键技术。数据挖掘技术可以在已有数据中识别数据的模式，以帮助用户理解现有的信息，并在已有信息的基础上，对未来的状况作出预测。在数据仓库的基础上进行数据挖掘，就可以针对整个企业的状况和未来发展作出比较完整、合理、准确的分析和预测。 第五， 成功的数据仓库系统可以为企业带来高的投资回报。结合企业业务现状，数据仓库可以建立在原有运行系统之上，企业可以在以分主题方式对原来运行数据重组的基础之上，为了某种支持特定决策的需要，再跨主题进行数据重组，这就需要数据集市（Data Marts）了。数据集市是聚集的、面向主题的数据

22、仓库，它简单、灵活，并且建立速度更快，花费也更低廉。通常情况下，企业将建立一系列数据集市，用来处理一定范畴的问题，快速决策意味着企业可以对市场机会做出快速反应，这将为企业带来巨大的商业利益。2.4 统一污染源数据库是环保局信息门户的先锋.为了将污染源数据及其分析决策信息能够方便的让环保局内部所有相关人员访问使用，必须要一种大家都易于接受的方式来表现这些数据，在这点上，信息中心建议采用B/S结构，用浏览器作为系统的统一表达方式。同时，将来建设的系统在表现层上也都准备采用同样的表现形式，所以，一个综合的门户发布系统对于整体环境信息系统而言是必备的。而在统一污染源项目中将门户的概念提出是有利于整体系

23、统规划的，可以说污染源的门户发布系统就是整体环境信息系统的先锋。这样,我们可以知道,其实, 统一污染源数据库是环保局信息门户的先锋.环保局信息门户（Enterprise Information Portal），就是采用标准浏览器，如Internet Explorer，提供对环保局的Intranet和Extranet的单点访问，使每个人能通过统一界面访问经授权的环保局内部和外部信息，从而提高决策水平。环保局信息门户为环保局的各种使用者提供了一个统一的应用界面，使环保局的使用者可以根据自己的需要获得想要的信息，它是通过提供全面的信息和应用来支持决策和客户选择的，主要作用体现在： 第一， 环保局信息

24、门户(EIP)是将Web技术与环保局的运作过程相集成的解决方案，它提供了一个单独的网关来访问信息和应用。环保局门户可以对未组织的信息进行编目和跟踪，也可以访问国际互连网上的内容，并根据用户的需求和在环保局中的角色来过滤这些内容。一个门户通过开放和封闭的网络，提供了数据和信息的传递，使用户更方便地来了解有关的信息。 第二， 环保局信息门户能够将存储在数据库、数据仓库和文件中的数据转换为可用的信息。它可以使你在环保局内和环保局外快速地改变信息，并通过浏览器传送信息。分散的公司通过网络连接在一起，加上最新型的信息传递方式，这就意味着在很短的时间内，获取正确的信息，传送给正确的用户，从而提高生产率。

25、第三， 环保局信息门户提供了一个对传统的个人桌面工作模式的改进方法，可以在通过简便的方法定制出的图形化的用户界面下进行工作（就像目前的商业门户，如Netcenter），能够实现信息的有效处理和系统的稳定性，就如同在原来的应用和信息系统下独立工作一样可以这么说，数据仓库为环保局提供了一个统一的数据视图，而环保局信息门户则为环保局提供了一个统一的应用界面，使他们方便快捷地访问数据仓库，进一步加速决策速度，提高决策水平。环保局信息门户的贡献不只在于帮助环保局了解手中大量信息的意义，更重要的是使他们能够应付那些由于分散的信息资源和处理过程维护能力下降而产生的问题。环保局信息门户能够通过超越现在的分散的

26、应用环境实现这个目标，把原来不同的相互关系连接到一起，形成广泛的、相互关联的应用环境，从而缩短环保局响应时间。环保局数据仓库系统是环保局信息门户的基石，为环保局信息门户的建立提供了一个完整的基础框架和统一的数据视图；而环保局信息门户的建立是对环保局数据仓库系统查询、检索、集成等功能的优化，二者是相辅相成的、统一的、都是为环保局的决策信息系统服务的，也是环保局实现电子政务关键因素。 综上所诉,统一污染源数据库项目的建设是基于污染源数据仓库的环保局信息门户的建设.我们将站在数据仓库的高度,利用数据仓库的技术,结合当前环保局当前的状况,对环保局统一污染源数据库作出规划2.5 需求的总结我们可以把环保

27、局的需求分为四个统一统一数据关于污染源的统一数据库.统一操作界面要求以后统一的操作界面.统一认证用户,外部应用程序有统一的认证机制,实现单点认证.统一接口.外部应用程序有统一的调用接口第三章.系统解决方案3.1 系统解决方案原则3.1.1可扩充性可扩充原则能够最大限度地保护原有资源，就是原来已经建设好的业务系统。统一污染源数据库平台将最大限度地兼容其他业务系统的数据，但并不干涉原有系统的业务数据。同时将来新开展的业务系统也可以将其相关信息数据纳入其中，而不改动其业务流程。3.1.2易维护性由信息中心统一管理的集中数据库可以根据各处室需求统一的开发报表，分析数据等操作，通过灵活的数据库维护工具，

28、数据分析工具能够做到统一数据库的易维护效果。3.1.3安全性利用工业强度级别的关系型数据库建设统一污染源数据库，在污染源数据库的应用系统中根据实际情况设置用户权限以达到数据级别的安全性。3.1.4合理性根据环保局现有业务系统的现实状况进行分析，对数据的不一致性作出合理判断，提供用户自我判断数据合理性功能。3.1.5开放性系统着眼于环保局环境信息系统的整体规划角度来看待污染源项目，提出多个崭新观念，其开放性便于将来整体平台的深入建设。3.2 技术路线.为了充分的保证环保局现有系统的投资,以及以后系统的扩充能力,在综合考虑了环保局的现状以后,我们确定了以统一的平台为基本的集成平台,以信息门户的构建

29、为基本框架.整合已有的业务系统,同时,要考虑到各种系统以后的接口,充分保证系统的扩充性.同时,为了保证环保局系统的先进型和稳定性,我们采用当今先进的J2EE结构, 3.3业务体系结构根据对环保局内部信息系统的信息调研，我们将在统一污染源数据库项目中采用以下的系统体系结构：3.3.1污染源数据内容从环保局原有业务系统中提取的数据来源大致有两处：一是国家环保总局下发的一系列环境软件，更污染源相关的有排污申报系统，环境统计系统，城考系统等；二是环保局针对自身业务特点细节开发的业务系统，主要有监督处的环保业务系统，监理所的监控中心系统，排污收费系统，监测站的监测系统等等。在上图中描述了这些业务系统分别

30、提供了那些与污染源相关的信息数据，这些数据就是统一污染源数据库需要抽取的业务数据。3.3.2基础数据库基础数据库是环保局整体环境信息系统的重要基础，主要包括“统一污染源”和“环境质量”，这里提到的基础数据库指的都是统一污染源数据库，数据也是与污染源相关的数据。根据环保局信息化建设的安排，将来可将“环境质量”也纳入到其中。基础数据库为各处室提供了共享的、全面的、权威的污染源信息。3.3.3数据仓库前面提到，随着环保局总体电子政务应用需求的发展，产生了信息“蜘蛛网”的问题，要解决这样的问题，必须将用于事务处理的数据环境和用于数据分析的数据环境分离开，所以我们在统一污染源数据库基础上建立了数据仓库应

31、用。从图中我们可以看出，数据处理被分为操作型处理和分析型处理（或信息型处理）两大类。操作型处理以各个业务系统的数据库为中心进行环保局日常的业务处理；分析型处理以统一污染源数据库、数据仓库为中心分析数据背后的关联和规律，为环保局的决策提供可靠有效的数据。所以操作型系统的使用人员通常是具体操作的部门人员，比如监督处、监理所等，处理的数据通常是业务的细节信息，其目标是实现环保局的业务运营；而分析型系统的使用人员通常是中高层的管理者或者从事数据分析的工作人员。分析型系统包含了环保局宏观信息而非具体细节，其目的是为环保局的决策者提供支持信息。操作型处理和分析型处理的分离，划清了数据处理的分析型环境与操作

32、型环境之间的界限，从而由原来数据库为中心的数据环境发展成为以数据库为中心的业务处理系统和以数据仓库为基础的分析系统。以数据库为中心的业务处理系统和以数据仓库为基础的分析系统的基础上，就可以建立商业智能(Business Intelligence)BI系统作为商业智能系统中的核心部分，决策支持系统具备下列功能：1、多维信息查询2、OLAP在线分析处理3、数据挖掘4、趋势预测3.3.4地理信息系统统一污染源数据库的上层应用之一是与GIS系统结合进行开发，把污染源的各种完整信息同地理位置和有关的视图结合起来，并可根据各处室需要对这些信息进行分析，把结果交由有关领导和部门作为决策的参考。GIS的空间分

33、析功能需要有大量的基础数据,其中工业污染源数据是必备数据之一，在污染源数据库设计中，我们强调了数据库系统与现有ARC/INFO、MAPOBJECT等GIS系统的结合，污染源数据库将环保局内部各部门积累的大量数据进行统一，并对这些属性数据进行处理和加工从而实现了数据的查询、统计和分析，GIS系统在此基础上利用其自身的空间方式就可以很好把污染源排放、治理、达标状况表现出来。3.3.5信息门户综合发布系统全面的内容整合环保局门户平台可以集成现有的应用系统，包括环保局的各种业务系统、一站式单点登录可使得用户一次登录自动访问所有授权的企业级应用软件系统，无需记忆多种登录过程、ID或口令。并作为环保局统一

34、的工作和沟通平台.3.3.6综合办公系统统一污染源数据库项目中产生的应用信息，如数据的查询，分析结果，报表等内容可以便利、无缝的与Athene环保局整体电子政务方案中的综合办公系统交换数据，为将来环保局的建设提供了可扩展性。3.4技术体系结构根据上述业务体系结构的特点，我们设计了下图所示的技术体系结构：我们在统一污染软数据库上进行数据挖掘及OLAP分析，得到查询结果或者统计报表数据，然后配合XML中间件技术将这些数据转化为标准XML格式信息， 通过XSLT(可扩展样式表转换)将XML数据转换成为系统中的处理格式信息，这些信息通过安全认证后，以servlet,jsp的形式生成网页表现出来。第四章

35、 污染源统一数据库4.1 数据库设计在本系统中中.污染源数据库的设计是整个系统的重点和难点,如何保证高效的,准确的对现有数据的集成,是直接影响到决策图标是否正确,以后新的业务系统是否稳定和准确的关键,同时, 污染源数据库的高效在线处理能力也是对以后新的业务系统性能上起着至关重要的影响.下面从以下几个方面来论述污染源统一数据库的建设.4.1.1 数据库设计主线在污染源统一数据库中,我们发现,贯穿整个污染源统一数据库业务点有两个,污染源和排污单位,利用这两点.可以完整的理解现在污染源统一数据库中的业务行为,对整个数据库设计起到关键的统领作用.4.1.1.1概念模型设计进行概念模型设计所要完成的工作

36、是： 界定统一污染源数据库系统边界 确定统一污染源数据库主要的主题域及其内容 概念模型设计的成果是，在原有的业务数据库的基础上建立了一个较为稳固的概念模型。因为统一污染源数据库是对原有业务数据库系统中的数据进行集成和重组而形成的数据集合，所以统一污染源数据库的概念模型设计，首先要对原有业务数据库系统加以分析理解，看在原有的业务数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立统一污染源数据库的概念模型。一方面，通过原有的业务数据库的设计文档以及在数据字典中的数据库关系模式，可以对现有的业务数据库中的内容有一个完整而清晰的认识；另一方面，统一污染源数据库的概念模型

37、是面向全局建立的，它为集成来自各个面向业务的数据库的数据提供了统一的概念视图。 概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1. 界定系统的边界 统一污染源数据库是面向决策分析的数据库，我们无法在统一污染源数据库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了我们的面前： l 要做的决策类型有哪些? l 各个处室需要的数据是什么?l 以后可能会有怎么样的业务系统接入到本统一污染源数据库?l 可能需要怎么样的数据接口?l 决策者感兴趣的是什么问题? l 这些问题需要什么样的信息? l 要得到这些信息需要包含原有数据库系统的哪些部

38、分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是统一污染源数据库系统设计的需求分析.2. 确定主要的主题域 在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确的描述，描述的内容包括： l 主题域的公共码键； l 主题域之间的联系； l 充分代表主题的属性组。 4.1.1.2 逻辑模型设计 在这一步里进行的工作主要有： l 分析主题域，确定当前要装载的主题； l 确定粒度层次划分； l 确定数据分割策略； l 关系模式定义； l 记录系统定义 逻辑模型设计的成果是，对每个当前要装载的主

39、题的逻辑实现进行定义，并将相关内容记录在数据仓库的元数据中，包括： l 适当的粒度划分； l 合理的数据分割策略； l 适当的表划分； l 定义合适的数据来源等。 1. 分析主题域 在概念模型设计中，我们确定了几个基本的主题域，但是，统一污染源的设计方法是一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的。所以，我们必须对概念模型设计步骤中确定的几个基本主题域进行分析，并选择首先要实施的主题域。选择第一个主题域所要考虑的是它要足够大，以便使得该主题域能建设成为一个可应用的系统；它还要足够小，以便于开发和较快地实施。如果所选择的主题域很大并且很复杂，我们甚至可以针对

40、它的一个有意义的子集来进行开发。在每一次的反馈过程中，都要进行主题域的分析。 2. 粒度层次划分 数据仓库逻辑设计中要解决的一个重要问题是决定统一污染源的粒度划分层次，粒度层次划分适当与否直接影响到统一污染源中的数据量和所适合的查询类型。确定统一污染源的粒度划分，可以通过估算数据行数和所需的DASD数，来确定是采用单一粒度还是多重粒度，以及粒度划分的层次。 3. 确定数据分割策略 在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方面因素：数据量(而非记录行数)、数据分析处理的实际情况、简单易行以及粒度划分策略等。数据量的大小是决定是否进行数据分割和如何分割的主要因素；数据分析处理的要求

41、是选择数据分割标准的一个主要依据，因为数据分割是跟数据分析处理的对象紧密联系的；我们还要考虑到所选择的数据分割标准应是自然的、易于实施的：同时也要考虑数据分割的标准与粒度划分层次是适应的。 4. 关系模式定义 统一污染源的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，我们就确定了统一污染源的基本主题，并对每个主题的公共码键、基本内容等做了描述在这一步里，我们将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。 4.1.1.3 物理模型设计 这一步所做的工作是确定数据的存储结构，确定索引策略，确定数据存放位置，

42、确定存储分配。 确定统一污染源实现的物理模型，我们必须做到以下几方面： l 要全面了解所选用的数据库管理系统，特别是存储结构和存取方法。 l 了解数据环境、数据的使用频度、使用方式、数据规模以及响应时间要求等，这些是对时间和空间效率进行平衡和优化的重要依据。 l 了解外部存储设备的特性，如分块原则，块大小的规定，设备的IO特性等。 1. 确定数据的存储结构 一个数据库管理系统往往都提供多种存储结构供设计人员选用，不同的存储结构有不同的实现方式，各有各的适用范围和优缺点，我们在选择合适的存储结构时应该权衡三个方面的主要因素：存取时间、存储空间利用率和维护代价。 2. 确定索引策略 统一污染源的数

43、据量很大，因而需要对数据的存取路径进行仔细的设计和选择。由于数据仓库的数据都是不常更新的，因而可以设计多种多样的索引结构来提高数据存取效率。 在数据仓库中，设计人员可以考虑对各个数据存储建立专用的、复杂的索引，以获得最高的存取效率，因为在数据仓库中的数据是不常更新的，也就是说每个数据存储是稳定的，因而虽然建立专用的、复杂的索引有一定的代价，但一旦建立就几乎不需维护索引的代价。 3. 确定数据存放位置 在物理设计时，我们常常要按数据的重要程度、使用频率以及对响应时间的要求进行分类，并将不同类的数据分别存储在不同的存储设备中。重要程度高、经常存取并对响应时间要求高的数据就存放在高速存储设备上，如硬

44、盘；存取频率低或对存取响应时间要求低的数据则可以放在低速存储设备上，如磁盘或磁带。 数据存放位置的确定还要考虑到其它一些方法，如：决定是否进行合并表；是否对一些经常性的应用建立数据序列；对常用的、不常修改的表或属性是否冗余存储。如果采用了这些技术，就要记入元数据。 4. 确定存储分配 许多数据库管理系统提供了一些存储分配的参数供设计者进行物理优化处理，如：块的尺寸、缓冲区的大小和个数等等，它们都要在物理设计时确定。这同创建数据库系统时的考虑是一样的。 4.1.1.4 统一污染源数据库的生成 在这一步里所要做的工作是接口编程，数据装入。 这一步工作的成果是，数据已经装入到数据仓库中，可以在其上建

45、立统一污染源的应用，即DSS应用。 1. 设计接口 将操作型环境下的数据装载进入数据仓库环境，需要在两个不同环境的记录系统之间建立一个接口。乍一看，建立和设计这个接口，似乎只要编制一个抽取程序就可以了，事实上，在这一阶段的工作中，的确对数据进行了抽取，但抽取并不是全部的工作，这一接口还应具有以下的功能： l 从面向应用和操作的环境生成完整的数据； l 数据的基于时间的转换； l 数据的凝聚； l 对现有记录系统的有效扫描，以便以后进行追加。 当然，考虑这些因素的同时，还要考虑到物理设计的一些因素和技术条件限制，根据这些内容，严格地制定规格说明，然后根据规格说明，进行接口编程。从操作型环境到数据

46、仓库环境的数据接口编程的过程和一般的编程过程并无区别，它也包括伪码开发、编码、编译、检错、测试等步骤。 在接口编程中，要注意： l 保持高效性，这也是一般的编程所要求的； l 要保存完整的文档记录； l 要灵活，易于改动； l 要能完整、准确地完成从操作型环境到数据仓库环境的数据抽取、转换与集成。 2. 数据装入 在这一步里所进行的就是运行接口程序，将数据装入到数据仓库中。主要的工作是： l 确定数据装入的次序； l 清除无效或错误数据； l 数据“老化” ； l 数据粒度管理； l 数据刷新等。最初只使用一部分数据来生成第一个主题域，使得设计人员能够轻易且迅速地对已做工作进行调整，而且能够尽早地提交到下一步骤，即数据仓库的使用和维护。这样既可以在经济上最快地得到回报，又能够通过最终用户的使用、尽早发现一些问题并提出新的需求，然后反馈给设计人员，设计人员继续对系统改进、扩展。4.1.2 数据库规范化设计数据仓库的建模方法 逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star