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

《环保局统一污染源数据库方案书》由会员分享，可在线阅读，更多相关《环保局统一污染源数据库方案书（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 数据刷新等。最初只使用一部分数据来生成第一个主题域，使得设计人员能够轻易且迅速地对已做工作进行调整，而且能够尽

47、早地提交到下一步骤，即数据仓库的使用和维护。这样既可以在经济上最快地得到回报，又能够通过最终用户的使用、尽早发现一些问题并提出新的需求，然后反馈给设计人员，设计人员继续对系统改进、扩展。4.1.2 数据库规范化设计数据仓库的建模方法 逻辑建模是数据仓库实施中的重要一环,因为它能直接反映出业务部门的需求,同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF,即 Third Normal Form)和星型模式 (Star-Schema)。什么是第三范式 范式是数据库逻辑模型设计的基本理论,一个关系模型可以从第一范式到第五范式进行无损分解,这个过程也称为规范化

48、(Normalize)。在数据仓库的模型设计中目前一般采用第三范式,它有非常严格的数学定义。如果从其表达的含义来看,一个符合第三范式的关系必须具有以下三个条件: 1. 每个属性的值唯一,不具有多义性; 2. 每个非主属性必须完全依赖于整个主键,而非主键的一部分; 3. 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去。 可以看到,第三范式的定义基本上是围绕主键与非主属性之间的关系而作出的。如果只满足第一个条件,则称为第一范式;如果满足前面两个条件,则称为第二范式,依此类推。因此,各级范式是向下兼容的。 什么是星型模式 星型模式是一种多维的数据关系,它由一个事实

49、表(Fact Table)和一组维表(Dimens ion Table)组成。每个维表都有一个维作为主键,所有这些维则组合成事实表的主键,换言之,事实表主键的每个元素都是维表的外键。事实表的非主属性称为事实 (Fact),它们一般都是数值或其他可以进行计算的数据;而维大都是文字、时间等类型的数据。 第三范式和星型模式在统一污染源数据库中的应用 大多数人在设计中央数据仓库的逻辑模型时,都按照第三范式来设计;而在进行物理实施时,则由于数据库引擎的限制,不得不对逻辑模型进行不规范处理 (De-Normalize), 以提高系统的响应速度,这当然是以增加系统的复杂度、维护工作量、磁盘使用比率 (指原始

50、数据与磁盘大小的比率)并降低系统执行动态查询能力为代价的。 根据数据仓库的测试标准 TPC-D规范,在数据仓库系统中,对数据库引擎最大的挑战主要是这样几种操作:多表连接、表的累计、数据排序、大量数据的扫描。下面列出了一些 DBMS在实际系统中针对这些困难所采用的折衷处理办法: 1、 如何避免多表连接:在设计模型时对表进行合并,即所谓的预连接 (Pre-Join)。当数据规模小时,也可以采用星型模式, 这样能提高系统速度,但增加了数据冗余量。 2、 如何避免表的累计:在模型中增加有关小计数据 (Summarized Data)的项。这样也增加了数据冗余,而且如果某项问题不在预建的累计项内,需临时

51、调整。 3、 如何避免数据排序:对数据事先排序。但随着数据仓库系统的运行,不断有新的数据加入,数据库管理员的工作将大大增加。大量的时间将用于对系统的整理,系统的可用性随之降低。 4、 如何避免大表扫描:通过使用大量的索引,可以避免对大量数据进行扫描。但这也将增加系统的复杂程度,降低系统进行动态查询的能力。 这些措施大都属于不规范处理。根据上面的讨论,当把规范的系统逻辑模型进行物理实施时,由于数据库引擎的限制,常常需要进行不规范处理。举例来说,当系统数据量很小 ,比如只有几个 GB时,进行多表连接之类复杂查询的响应时间是可以忍受的。但是设想一下,如果数据量扩展到很大,到几百 GB,甚至上 TB,

52、一个表中的记录往往有几百万、几千万,甚至更多,这时进行多表连接这样的复杂查询,响应时间长得不可忍受。这时就有必要把几个表合并,尽量减少表的连接操作。当然,不规范处理的程度取决于数据库引擎的并行处理能力。不规范处理的阶段 现在来讨论一下,当不得不选择不规范处理时,应在哪个阶段进行。由于中央数据仓库的数据模型反映了整个企业的业务运行规律,在这里进行不规范处理容易影响整个系统,不利于今后的扩展。 而且不规范处理产生的数据冗余将使整个系统的数据量迅速增加,这将增加 DBA的工作量和系统投资。因此,当系统性能下降而进行不规范处理时,比较好的办法是选择问题较集中的部门数据集市实施这种措施。这样既能有效地改

53、善系统性能,又不至于影响整个系统。在国外一些成功的大型企业级数据仓库案例中,基本上都是采用这种方法。 那么,在中央数据仓库中是否可以采用星型模式来进行模型设计呢?我们知道,星型模式中有一个事实表和一组维表,我们可以把事实看成是各个维交叉点上的值。例如,一个汽车厂在研究其销售情况时可以考察汽车的型号、颜色、代理商等多种因素,这些因素就是维,而销售量就是事实。这种多维模型能迅速给出基于各个维的报表,这些维必须事先确定。 星型模式之所以速度快,在于针对各个维作了大量的预处理,如按照维进行预先的统计、分类、排序等。在上面的例子中,就是按照汽车的型号、颜色、代理商进行预先的销售量统计。因此,在星型模式设

54、计的数据仓库中,作报表的速度虽然很快,但由于存在大量的预处理,其建模过程相对来说就比较慢。当业务问题发生变化,原来的维不能满足要求时,需要增加新的维。由于事实表的主键由所有维表的主键组成,这种维的变动将是非常复杂、非常耗时的。星型模式另一个显著的缺点是数据的冗余量很大。综合这些讨论,不难得出结论,星型模式比较适合于预先定义好的问题,如需要产生大量报表的场合;而不适合于动态查询多、系统可扩展能力要求高或者数据量很大的场合。因此,星型模式在一些要求大量报表的部门数据集市中有较多的应用。 上面讨论了数据仓库模型设计中常用的两种方法。在数据仓库的应用环境中,主要有两种负载:一种是回答重复性的问题;另一

55、种是回答交互性的问题。动态查询具有较明显的交互性特征,即在一个问题答案的基础上进行进一步的探索,这种交互过程常称为数据挖掘 (Data Mining)或者知识探索 (Knowledge Discovery)。对于以第一种负载为主的部门数据集市,当数据量不大、报表较固定时可以采用星型模式;对于中央数据仓库,考虑到系统的可扩展能力、投资成本和易于管理等多种因素,最好采用第三范式。根据我们对环保局的业务的分析，我们知道，在统一污染源数据库中，大量的查询是基于固定的，重复性质的查询和报表工作，同样的，也会具有少量的即席查询，所以，我们对统一污染源的建模方面，将以第三范式为主，同时，在可以预见的查询和分

56、析主题上，采取适当的数据冗余。使用星型模式，增加系统的处理能力和反映能力。4.1.3 粒度设计数据仓库中的数据分为四个级别：早期细节级、当前细节级、轻度综合级、高度综合级。源数据经过综合后，首先进入当前细节级，并根据具体需要进行进一步的综合，从而进入轻度综合级乃至高度综合级，老化的数据将进入早期细节级由此可见，数据仓库中存在着不同的综合级别，一般称之为粒度。粒度越大，表示细节程度越低，综合程度越高.粒度是数据仓库的重要概念。粒度是对数据仓库中的数据的综合程度高低的一个度量，它既影响数据仓库中的数据量的多少，也影响数据仓库所能回答询问的种类。在数据仓库中，多维粒度是必不可少的。由于数据仓库的主要

57、作用是DSS分析，因而绝大多数查询都基于一定程度的综合数据之上的，只有极少数查询涉及到细节。所以应该将大粒度数据存储于快速设备如磁盘上，小粒度数据存于低速设备如磁带上。 在统一污染源的分析中，我们发现，统一污染源既要保存当前业务系统的细节，也要保存深度处理后的数据，所以，我们决定，在统一污染源的粒度设计中，我们采取两重标准，在当前业务数据的处理中，我们将采用小粒度，尽量的保证当前的业务细节，同时，在一些综合的数据上，我们采取大粒度设计，使得查询的速度可以大大的加快，同时，也有利于环保局对总体的把握。4.1.4 元数据管理。按照传统的定义，元数据（Metadata）是关于数据的数据。在数据仓库系

58、统中，元数据可以帮助数据仓库管理员和数据仓库的开发人员非常方便地找到他们所关心的数据；元数据是描述数据仓库内数据的结构和建立方法的数据，可将其按用途的不同分为两类：技术元数据（Technical Metadata）和业务元数据（Business Metadata）。技术元数据是存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据，它主要包括以下信息：数据仓库结构的描述，包括仓库模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容；业务系统、数据仓库和数据集市的体系结构和模式汇总用的算法，包括度量和维定义算法，数据粒度、主题领域、聚集、汇总、预定义的查询与报告；由

59、操作环境到数据仓库环境的映射，包括源数据和它们的内容、数据分割、数据提取、清理、转换规则和数据刷新规则、安全（用户授权和存取控制）。业务元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够“读懂”数据仓库中的数据。业务元数据主要包括以下信息：使用者的业务术语所表达的数据模型、对象名和属性名；访问数据的原则和数据的来源；系统所提供的分析方法以及公式和报表的信息；具体包括以下信息：企业概念模型：这是业务元数据所应提供的重要的信息，它表示企业数据模型的高层信息、整个企业的业务概念和相互关系。以这个企业模型为基础，不懂数据库技术和SQL语

60、句的业务人员对数据仓库中的数据也能做到心中有数。多维数据模型：这是企业概念模型的重要组成部分，它告诉业务分析人员在数据集市当中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。这里的数据立方体表示某主题领域业务事实表和维表的多维组织形式。业务概念模型和物理数据之间的依赖：以上提到的业务元数据只是表示出了数据的业务视图，这些业务视图与实际的数据仓库或数据库、多维数据库中的表、字段、维、层次等之间的对应关系也应该在元数据知识库中有所体现。元数据在数据分析中，充当充当这相当主要的作用，如下图元数据知识库业务元数据技术元数据即席查询OLAP分析数据挖掘企业数据模型、多维数据模型数据仓库RDBMS

61、外部数据源操作环境层数据仓库层业务层数据仓库系统的一般体系结构其中，第一层（操作环境层）是指整个企业内有关业务的OLTP系统和一些外部数据源；第二层是通过把第一层的相关数据抽取到一个中心区而组成的数据仓库层；第三层是为了完成对业务数据的分析而由各种工具组成的业务层。图中左边的部分是元数据管理，它起到了承上启下的作用，具体体现在以下几个方面：(1) 元数据是进行数据集成所必需的数据仓库最大的特点就是它的集成性。这一特点不仅体现在它所包含的数据上，还体现在实施数据仓库项目的过程当中。一方面，从各个数据源中抽取的数据要按照一定的模式存入数据仓库中，这些数据源与数据仓库中数据的对应关系及转换规则都要存

62、储在元数据知识库中；另一方面，在数据仓库项目实施过程中，直接建立数据仓库往往费时、费力，因此在实践当中，人们可能会按照统一的数据模型，首先建设数据集市，然后在各个数据集市的基础上再建设数据仓库。不过，当数据集市数量增多时很容易形成“蜘蛛网”现象，而元数据管理是解决“蜘蛛网”的关键。如果在建立数据集市的过程中，注意了元数据管理，在集成到数据仓库中时就会比较顺利；相反，如果在建设数据集市的过程中忽视了元数据管理，那么最后的集成过程就会很困难，甚至不可能实现。(2) 元数据定义的语义层可以帮助最终用户理解数据仓库中的数据最终用户不可能象数据仓库系统管理员或开发人员那样熟悉数据库技术，因此迫切需要有一个“翻译”，能够使他们清晰地理解数据仓库中数据的含意。元数据可以实现业务模型与数据模型之间的映射，因而可以把数据以用户需要的方式“翻译”出来，从而帮助最终用户理解和使用数据。(3) 元数据是保证数据质量的关键数据仓库或数据集市建立好以后，使用者在使用的时候，常常会产生对数据的怀疑。这些怀疑往往是由于底层的数据对于用户来说是不“透明”的，使用者很自然地对结果产生怀疑。而借助元数据管理系统，最终的使用者对各个数据的来龙去脉以及数据抽取和转换的规则都会很方便地得到，这样他们自然会对数据具有信心；当然也