基于数据仓库和OLAP技术的环境污染数据分析结题报告.doc

中国矿业大学“大学生创新训练计划”项目结 题 验 收 报 告 书国家级 省级 校级自拟 校级重点 校级指导项 目 名 称 基于数据仓库和OLAP技术的环境污染数据分析项 目 编 号 201410290043X 立 项 时 间 2014年5月 计划完成时间 2015年5月 项目负责人 成炜琳 专 业 班 级 网络12-1班 联 系 电 话指 导 教 师 杨东平 填 表 时 间 2015年5月10 中国矿业大学教务部制项目名称利用与OLAP分析环境监测数据仓库项目编号201410290043X项目负责人成炜琳项目组其他成员苗清亮、孙浦朝、邹宇驰项目启动时间2014年5月项目计划完成时间2015年5月已用经费（元）1341剩余经费（元）159一、项目意义本次项目是在曾经参与过本类项目研究的计算机学院资深老师的指导下由网络工程专业同学完成，我们已经在传感器、单片机、无线网技术、数据结构、数据库等方面有一定的专业知识的积累，本身都已拥有一定的实地调研分析的经验，具备抓住主要矛盾、提出问题以及通过设计解决问题的能力。并且正在进行“基于大气P M 2.5测量的无线传感网络技术”的创新实验项目，在此项目中我们团队也同样得到了一些知识的积累和动手实践能力的培养。上一个创新实践项目中实时监测系统的建立，使大量空气质量与污染情况数据得以积累。为此，在此条件下，我们希望进一步建立数据仓库，学会并熟练运用使用OLAP技术对数据进行多维信息提取分析、针对特定问题的联机数据访问和处理。为环境管理部门提供给有效的决策支持以及通过实时监测智能系统公布空气质量信息，让人们对自己身处的城市环境有更深的了解，继而通过规范自身行为改善空气质量；二来积累的监测数据将成为城市空气质量的重要资料，为分析城市污染源、制定治污减排对策提供基础我们本着在实践中创新，在创新中得到锻炼的目的积极参与此次创新实践项目。二、项目创新点及特色空气质量监测问题是近年来的一个热门话题，而实时监测却是一个新兴的技术，通过数据仓库和利用联机分析技术使数据源结构化，在数据环境中实现实时监控系统的智能化，为相关环境保护部门提供决策参考。三、项目完成情况（1）建立一个环境实时监控系统的方法和技术。（2）建立基于实时监控系统数据的数据模型。（3）对大量历史环境空气检测数据建立数据仓库，并利用OLAP工具进行数据分析。一.概念模型设计：进行概念模型设计所要完成的工作为以下两点： 1.界定系统边界将数据分析的需求用系统边界的定义形式反映出来。界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。2.确定主要的主题域及其内容概念模型设计在基于PM2.5无线传感网络项目中收集到的环境监测结果的数据库的基础上建立了一个较为稳固的概念模型。在这一步中，要确定系统所包含的主题域，然后对每个主题域的内容进行较明确的描述，描述的内容包括：主题域的公共码键；主题域之间的联系；充分代表主题的属性组。并绘制出有关实体与属性、联系有关的E-R图模型。二.技术准备工作: 技术准备工作这一阶段的工作包括：技术评估，技术环境准备。这一阶段要实现的目的是：技术评估报告、软硬件配置方案、系统(软、硬件)总体设计方案。1 技术评估进行技术评估：确定数据仓库的各项性能指标。一般情况下，需要在这一步里确定的性能指标包括：管理大数据量数据的能力；（如在本项目中会从无线传感器网络传来很多关于大气监测的的数据）进行灵活数据存取的能力；根据数据模型重组数据的能力；透明的数据发送和接收能力；周期性成批装载数据的能力；可设定完成时间的作业管理能力。 2技术环境准备一旦数据仓库的体系化结构的模型大体建好后，下一步的工作就是确定我们应该怎样来装配这个体系化结构模型，主要是确定对软硬件配置的要求；我们主要考虑相关的问题： 预期在数据仓库上分析处理的数据量有多大? 如何减少或减轻竞争性存取程序的冲突? 数据仓库的数据量有多大? 进出数据仓库的数据通信量有多大?等等。根据这些考虑，我们就可以确定各 项软硬件的配备要求，并且在这一步工作结束时各项技术准备工作应已就绪，可以装载数据了。这些配备有： 网络； 进出数据仓库的界面(主要是数据查询和分析工具)。3. 管理数据仓库的软件，目前即选用数据库管理系统及有关的选件，购买的DBMS产品不能满足管理数据仓库需要的，还应考虑自己或软件集成商开发有关模块等等。三.逻辑模型设计在这一步里我们需要进行的工作主要有：1、分析主题域，确定当前要装载的主题；2、确定粒度层次划分；3、确定数据分割策略；4、关系模式定义。记录系统定义逻辑模型设计的成果是，对每个当前要装载的主题的逻辑实现进行定义，并将相关内容记录在数据仓库的元数据中，包括适当的粒度划分；合理的数据分割策略；适当的表划分；定义合适的数据来源等。项目的实际进程中，对应着上面的工作计划，把握以下几点：1、分析主题域在概念模型设计中，我们确定了几个基本的主题域，比如操场、食堂、公教、图书馆。但是，数据仓库的设计方法是 一个逐步求精的过程，在进行设计时，一般是一次一个主题或一次若干个主题地逐步完成的。所以，我们必须对概念模型设计步骤中确定的几个基本主题域进行分析，并选择首先要实施的主题域。选择第一个主题域所要考虑的是它可以选择足够大比如整个徐州市，以便使得围绕该主题域能建设成为一个可应用的系统；它也可以足够小比如学校，以便于开发和较快地实施。如果所选择的主题域很大并且很复杂，我们甚至可以针对它的一个有意义的子集来进行开发。在每一次的反馈过程中，都要进行主题域的分析。2、粒度层次划分数据仓库逻辑设计中要解决的一个重要问题是决定数据仓库的粒度划分层次，粒度层次划分适当与否直接影响到数据仓库中的数据量和所适合的查询类型。确定数据仓库的粒度划分，可以通过估算数据行数和所需的DASD数，再根据PM2.5的历史收集数据，来确定是采用单一粒度还是多重粒度，以及粒度划分的层次。3、确定数据分割策略在这一步里，要选择适当的数据分割的标准，一般要考虑以下几方面因素：数据量、数据分析处理的实际情况、简单易行以及粒度划分策略等。数据量的大小是决定是否进行数据分割和如何分割的主要因素，学校的PM2.5的数据收集和徐州市的PM2.5的数据收集情况就有所不同；数据分析处理的要求是选择数据分割标准的一个主要依据，因为数据分割是跟数据分析处理的对象紧密联系的；我们还要考虑到所选择的数据分割标准应是自然的、易于实施的：同时也要考虑数据分割的标准与粒度划分层次是适应的。 4、关系模式定义数据仓库的每个主题都是由多个表来实现的，这些表之间依靠主题的公共码键联系在一起，形成一个完整的主题。在概念模型设计时，我们就确定了数据仓库的基本主题，并对每个主题的公共码键、基本内容等做了描述在这一步里，我们将要对选定的当前实施的主题进行模式划分，形成多个表，并确定各个表的关系模式。四.物理模型设计:这一步所做的工作是确定数据的存储结构，确定索引策略，确定数据存放位置，确定存储分配。为了确定数据仓库实现的物理模型，要求我们在设计之初必须做到以下几方面：要全面了解所选用的DBMS，特别是存储结构和存取方法。了解传感器采集到的数据所处的存储环境、数据的使用频度、使用方式、数据规模以及响应时间要求等，这些是对时间和空间效率进行平衡和优化的重要依据。了解外部存储设备的特性，如分块原则，块大小的规定，设备的I/O特性等。1.通常为了确定数据的存储结构一个数据库管理系统往往都提供多种存储结构供设计人员选用，不同的存储结构有不同的实现方式，各有各的适用范围和优缺点。当然我们团队在选择合适的存储结构时应该权衡三个方面的主要因素：存取时间、存储空间利用率和维护代价。时间太长，让有限的空间装不下后面的数据，时间太短，影响我们对数据的操作。2.为了实现快速寻找需要的信息，我们需要借助索引。确定索引策略数据仓库的数据量很大，因而需要我们对数据的存取路径进行仔细的设计和选择。由于数据仓库的数据都是不常更新的，因而可以设计多种多样的索引结构来提高数据存取效率。在数据仓库中，我们可以尝试着对各个数据存储建立专用的、复杂的索引，以获得最高的存取效率，因为在数据仓库中收集到的传感器的数据是不常更新的，也就是说每个数据存储是稳定的，因而虽然建立专用的、复杂的索引有一定的代价，但一旦建立就几乎不需维护索引的代价。3.确定数据存放位置，同一个主题的数据并不要求存放在相同的介质上。（如在测量PM2.5时，我们得到一系列有效的信息，他们并不完全需要防止相同的介质上。在物理设计时，我们会按数据的重要程度、预计使用频率以及对响应时间的要求进行分类，并将不同类的数据分别存储在不同的存储设备中。重要程度高、经常存取并对响应时间要求高的数据就存放在高速存储设备上，如硬盘；存取频率低或对存取响应时间要求低的数据则可以放在低速存储设备上，如磁盘或磁带。当然在数据存放位置的问题上还要考虑到其它一些方法，如：决定是否进行合并一部分表；是否对一些经常性的应用建立数据序列；对常用的、不常修改的表或属性是否冗余存储。如果采用了这些技术，就要记入元数据。五.数据仓库生成：（2015年11月-2016年1月）数据仓库的生成在这一步里我们要做的工作是接口编程，数据装入。这一步工作我们将要实现的目的是，数据已经装入到数据仓库中，可以在其上建立数据仓库的应用，即DSS（数据支持系统）应用。 1.设计接口将操作型环境下的数据装载进入数据仓库环境，需要在两个不同环境的记录系统之间建立一个接口。在这一阶段的工作中，需要我们做的不仅仅是对数据进行抽取，但由于抽取并不是全部的工作，这一接口还应具有以下的功能： (1)从环境测得的完整的数据； (2)数据的基于时间的转换； (3)数据的凝聚； (4)对现有记录系统的有效扫描，以便以后进行追加。当然，考虑这些因素的同时，还要考虑到物理设计的一些因素和技术条件限制，因为根据这些内容和要求，在进行实验第五步时需要严格地制定规格说明，然后根据规格说明，进行接口编程。从操作型环境到数据仓库环境的数据接口编程的过程和一般的编程过程并无区别，它也包括伪码开发、编码、编译、检错、测试等步骤。六.数据仓库运行与维护：(这一步后续由使用数据者进行按需维护)（2016年1月-2016年5月）在这一步中所要做的工作有建立DSS应用，即使用数据仓库理解需求，调整和完善系统，维护数据仓库。数据仓库装入数据之后，下一步工作是：一方面，使用数据仓库中的数据服务于决策分析的目的，也就是在数据仓库中建立起DSS应用；另一方面，根据用户使用情况和反馈来的新的需求，开发人员进一步完善系统，并管理数据仓库的一些日常活动，如刷新数据仓库的当前详细数据、将过时的数据转化成历史数据、清除不再使用的数据、调整粒度级别等。我们把这一步骤称为数据仓库的使用与维护。 1 .建立DSS应用使用数据仓库，即开发DSS应用，与在操作型环境中的应用开发有着本质区别，开发DSS应用不同于联机事务处理应用开发的显著特点在于：DSS应用开发是从数据出发的；DSS应用的需求不能在开发初期明确了解；DSS应用开发是一个不断循环的过程，是启发式的开发。DSS应用开发的大致步骤如下：步骤l-确定所需的数据。为满足DSS应用的要求，我们必须从数据仓库中确定一个可能用到的数据范围。这是一个试探的过程。 2.编程抽取数据。根据上面得到的数据范围，编写一个抽取程序来获得这些数据。为适应分析需求多变的特点，要求所编写的抽取程序应该通用，易于修改。 3.合并数据。如果有多个数据抽取源，要将抽取来的数据进行合并、提炼，使数据符合分析处理的要求。 4.分析数据。在上步准备好的数据基础上进行分析处理，并看所得的结果是否满足了原始的要求，如果不能满足，则返回步骤1，开始新的一次循环，否则就准备最终分析结果报告。 5.回答问题。生成最终分析结果报告。-般情况下，最终的分析结果报告是在许多次的循环后得到的，因为一次分析处理很少是在一次循环后就完成的。 6.例行化、一次分析处理的最后、我们要决定是否将在上面已经建立的分析处理例行化。如建立的分析处理是重复进行的部门级的DSS应用，那么最好是将它例行化，这样在进行下一次同样的分析处理时，不必再重复上述六步的循环过程。而且，不断地积累这种例行处理，形成一个集合，我们就可以通过组合这些已有的处理来生成新的一个较大的复杂处理，或完成一个复杂处理的一部分。2 理解需求，改善和完善系统，维护数据仓库数据仓库的开发是逐步完善的原型法的开发方法，它要求：要尽快地让系统运行起来，尽早产生效益；要在系统运行或使用中，不断地理解需求，改善系统；不断地考虑新的需求，完善系统。维护数据仓库的工作主要是管理日常数据装入的工作，包括刷新数据仓库的当前详细数据，将过时的数据转化成历史数据.清除不再使用的数据，管理元数据，等等；另外，如何利用接口定期从操作型环境向数据仓库追加数据，确定数据仓库的数据刷新频率，等等。 其中有三点重点：（1） 数据仓库的建立 数据仓库层次结构图 1.数据源在本系统中主要分析中国矿业大学南湖校区的环境空气质量小时实时监测数据和重点污染源的小时监测数据所以数据仓库的数据来源主要有两个：一个是重点污染源数据库，另一个为环境空气质量数据库。另外，由于大气污染扩散与气象条件息息相关，所以气象监测数据库也是个重要的数据源。这里重点污染源先不考虑。（1）环境空气质量监测数据库 获取中国矿业大学南湖校区所有空气质量监测站的小时数据，数据来源主要有三个表： PM2.5小时检测表字段名称数据类型字段注释RecordIDChar记录号StationIDChar监测站点号DateIDDatetime时间PMCharPM2.5的监测值 空气检测站点基础信息表结构字段名称数据类型字段注释StationIDChar监测点号StationNameVachar(30)监测站点名称StddressVarchar(30)监测站点位置StationPortChar(4)站点对应串口号（2）气象监测数据库此数据来源用来获取中国矿业大学南湖校区每天每小时的气象监测数据，本系统中使用了“基于大气PM2.5测量的无线传感网络技术”项目中建设的空气质量监测站所监测的的气象数据。监测时间表字段名称数据类型字段注释DateIDDateTime时间TempReal温度WeatherChar天气 气象数据表字段名称数据类型时间码Bigint项目码Int监测点位码Int天气码Int监测点监测值Real2.数据仓库设计 数据仓库的主题是中国矿业大学南湖校区坏境空气质量和污染源小时实时监测数据，在本系统中现只分析环境空气的PM2.5的指数。这是我们的重点。 3.数据预处理数据仓库系统的另一个关键问题，是在选择了数据源并设计建立数据仓库结构后，如何选用合适的数据抽取和转换工具从数据源中抽取所需要的数据，根据业务需求对数据进行转换，包括检验、整理、加工和重新组织等步骤后存放到数据仓库中。由于在实践工作中，数据源往往来源于多个不同系统，数据之间多存在逻辑上的不一致，数据组织不合理，数据冗余、数据逻辑冲突、数据定义冲突等问题十分常见，因此数据 数据源在载入数据仓库之前必须进行额外的数据重新组织和转换加工。传统的数据库管理系统己无法完成这样的工作，必须采用专门的数据抽取和转换工具。专门的数据抽取和转换工具提供收集、转换和修订操作型数据的功能，并自动把数据转换后的数据装载到数据仓库指定的数据库中。一般来说，此类工具主要提供两方面的功能。首先，它们提供了流行的基本视窗的用户接口，便于用户方便地描述数据抽取和转换需求。数据转换包括对数据进行匹配、归并、排序、创建新的数据域、选择数据子集、聚簇数据、转换操作型数据等；其次，它们能够自动创建运行在数据源所在平台上的程序，自动执行数据抽取、检验和重新组织等功能。这些工具根据用户的输入建立有关元数据，其中描述了源数据和目标数据的格式，以及如何把数据转换为目标数据。本系统中采用SQL SERVER2008提供的数据转换服务工具和部分程序完成系统的数据抽取和转换任务，把污染源实时监测和空气质量实时监测数据库中的相关数据转换到环境空气监测分析数据库中。（二）数据的提取与分析1创建独立的数据准备区数据准备区是源数据进入数据仓库数据库的一个缓冲区。在此区域中，可以暂时存储源数据，并对其进行清理、转换等操作。最初装载数据仓库后，需要不断地利用数据准备区为更新数据仓库准备新数据。在环境监测分析数据仓库系统中，源数据并非实时同步地从各个数据源中抽取出来，而是根据各数据源系统的运行特点及其数据产生规律，定时异步地从各数据源抽取出数据放入数据准备区，经转换集成后，等待数据仓库刷新程序的装入。所以创建独立的数据准备区为数据仓库准备有利于保证数据仓库的完整性，同时可以提高数据仓库的管理效率。2抽取数据在创建了数据仓库数据库后，即开始抽取数据。其目的是使所有的源数据都具有通用且一致的格式，以准备装入数据仓库。源数据在抽取之前应进行数据的有效性检验，可以在源操作系统中执行错误检查，对监测到的错误数据首先予以更正。环境监测数据仓库的源数据因存在两个不同的数据源，两个数据库中的表结构有很大差异。如在空气质量监测数据库中，小时监测数据表以时间、站点号和项目号为关键字，一条记录对应一个站点某项目的小时监测数据；而在污染源监测数据苦衷，小时监测数据表以时间和站点号为关键字，一条纪录对应。此站点在这一小时的所有项目监测数据。3清理和转换数据从不同的数据源中抽取的数据驻留在数据准备区，在数据装入数据仓库之前完成清理和转换。数据清理即对数据按照标准进行格式化处理，清理工作应严格按照元数据的定义进行。数据转换将把运行系统中的数据转换为某种适合数据仓库设计的分离格式，包括把抽取的数据进行格式化和修改，并且导入到数据仓库中，成为更有用的或推导出的数据。4装载数据源数据经过在数据准备区清理转换后，便可载入到数据仓库数据库中。数据载入应选在系统相对空闲时完成，因为装载过程中通常涉及从源操作系统、数据准备区到数据仓库数据之间大量数据的传输，会显著增加所设计的数据库的处理负荷。分析数据装载到数据仓库数据库后，需验证事实表与其相关维的引用完整性，确保所有的记录都与维表中的适当记录相关，但不需要相反顺序的数据完整性，即维度表中的每个记录不必与事实数据表中的记录相关。（三）监测数据的实时分析与OLAP的应用1.监测数据的在线分析数据仓库与OLAP是密不可分的。数据仓库解决了企业从大量原始数据中组织维护所需数据的问题，但要使管理人员有效地使用信息，则要借助OLAP技术。OLAP主要通过多维方式来针对特定问题对联机数据分析查询，其实施关键有两点：一是OLAP服务器的设计，即如何组织来自多个不同数据源中的数据；二是OLAP服务器与前端软件的沟通，即多维数据分析这是OLAP技术的核心。2.监测数据OLAP的实现技术对于数据仓库中的综合性数据由两种组织方式：一是建立专用的多维数据库系统，形成基于多维数据的OLAP(MOALP)，二是仍然利用现有的关系数据库技术来模拟多维数据，形成基于关系数据的OLAP(ROLAP)。MOLAP将DB服务器层与应用层合二为一，DB或DW层负责数据存储、存取及检索；应用逻辑层负责所有OLAP需求的执行。来自不同事务处理系统的数据通过一系列批处理过程载入MDDB中，数据进入后，MDDB将自动建立索引并进预综合来提高查询和存取的性能。MOLAP结构简图如图所示。 （MOLAP结构简图）同专用的MDDB相比，关系数据尽管表达多维概念不大自然，但在目前关系数据库广泛应用的情况下也不失为一种应用可行的方案。ROLAP以关系数据库为核心，将多维数据库中的