（土木工程专业论文）市政管网综合信息平台关键技术研究.pdf

0 i 卜 独创性声明 本人声明所呈交的论文是我个人在导师指导下进行的研究工作及取得的研 究成果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他 人已经发表或撰写过的研究成果，也不包含为获得北京工业大学或其它教育机构 的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均 已在论文中作了明确的说明并表示了谢意。 签名：夸 日期： 2 夕j f o 关于论文使用授权的说明 本人完全了解北京工业大学有关保留、使用学位论文的规定，即：学校有权 保留送交论文的复印件，允许论文被查阅和借阅；学校可以公布论文的全部或部 分内容，可以采用影印、缩印或其他复制手段保存论文。 ( 保密的论文在解密后应遵守此规定) 躲李氆 翩躲爵匕嗍“，。 北京工业大学工学硕士学位论文 摘要 随着我国经济建设的高速发展，城市基础设施建设和改造速度的加快，人口 规模的不断扩大，城市市政设施越来越庞大，从而对城市市政管网的规划建设、 信息化管理及应急抢修等提出了更高的要求。 市政管网一般历史较长，数量较大，而且在城市建设过程中，在对部分老管 线进行更新改造的同时，又铺设了新的管线，使得许多管线铺设情况复杂、资料 不清，而现在国内大部分市政部门还停留在采用绘制图纸的办法来管理现有的市 政设施资料。市政信息分散、查询不便、效率低、信息量大、存储不易、纸质的 资料保存困难、自然损坏现象严重、保存质量不高是目前纸质图纸档案信息管理 的集中问题。 市政管网综合信息平台是利用地理信息系统、可视化监控系统等计算机技术 和手段，对市政设施及相关系统的各方面数据进行全方位的信息化处理，从而形 成对市政行业的相关系统进行数字网络化管理、服务。市政管网综合信息平台建 设的主要内容是将市政公用设施纳入统一的信息网络平台，进行数据的分析和处 理，为市政设施的日常管理、养护和维修、对突发事件实施应急指挥处理、优化 管理工作的调度决策提供依据和指导，做出科学决策。 本文主要研究了构建市政管网综合信息平台的关键技术。提出了多层异构分 布式数据库架构体系，构建了市政管网综合数据库，并介绍了基于市政管网综合 数据库进行规划、设计、管理三方面应用的实例。 关键词：市政工程；地理信息系统；可视化 北京工业大学工学硕士学位论文 a b s t r a c t w i t ht h er a p i dd e v e l o p m e n to fc h j n a se c o n o m i cc o n s t r u c t i o n 。u r b a ni n f r a s t r u c t u r e d e v e l o p m e n ta n dt n a n s f b r m a t i o na c c e l e r a t e s ，廿1 ep o p u i a t i o ns i z ec o n t n u e st oe x p a n d ， m o r e a n dm o r ei a r g eu r b a nu t i i t i e st ot h eu r b a np i a n n i n ga n dc o n s t r u c t i o no f m u n i c i p a lp i p en e t w o r k ，i n f o r r l l a “o nm a n a g e m e n ta n de m e r g e n c yn p a ir ，e t c p u t f o n ，a r dh i g h e r 陀q u i r e m e n t s m u n i c i p a ip i p en e t 、o r kg e n e r a yo l d er ，l a r g e rq u a n t i t y ：b u ta i s oi nt h ep r o c e s s0 f u r b a nc o n s t r u c t l o n ，s o m eo ft h eo i dp i p e l i n e si nt h er e n o v a t o no ft h es a m et i m e ， l a y i n gan e wp i p e n e ，p i p e n ei a y i n gs om a n yc o m p l i c a t e di n f 6 r m a t o nc i e ar a n dn o w d o m e s t i cm o s tm u n i c i p a | i t i e ss t 川a tb yd r a w i n gd r a w i n ga p p r o a c ht oi n f o r m a t i o n m a n a g e m e n to fe x i s t i n gm u n i c i p a lf a c i | i t j e s m u n i c i p a ls e i c e si n f o r m a t - o n i s s c a t t e n d ，c h e c kt h ei n c o n v e n i e n c e ，i o we f f i c i e n c y ，i a r g ea m o u n to fi n f o r m a t i o ns t o r e d i sn o te a s y ，p a p e 卜b a s e di n f o r m a t i o ni sh a r d ， n a t u r a id a m a g ei ss e r i o u s ，j st h e p r e s e r v a t o no fh i g hq u a t yd r a w i n gp a p e rf | e sc e n t 陷i i z e di n f o r m a t i o nm a n a g e m e n t i s s u e s m u n i c i p a ic o m p r e h e n s i v ei n f o r m a t i o np i a 们r mi st h eu s eo fg e o g 陷p h i ci n f o n l l a “o n s y s t e m s ，v i s u a lm o n t o r n gs y s t e m s ，c o m p u t e rt e c h n o i o g ya n dt h em e a n s ，m u n i c i p a i f a c i l i t i e sa n dr e l a t e ds y s t e m si n a “a s p e c t so fc o m p r e h e n s i v ed a t a ，j n f o r m a “o n p r o c e s s i n g ，t of o r mt h em u n i c j p a ii n d u s t 吖r e l a t e ds y s t e m sf o rd i g 怕ln e t w o r k s m a n a g e m e n t ，s e n ，i c e m u n i c i p a ic o m p 陀h e n s i v ej n f o r m a t i o np i a t f o r mt ot h em a i n c o n t e n t so fm u n i c i p a iu t i h t i e s i n t oau n j f _ e di n f b r m a t 0 nn e t w o n p i a 怕盯t 1f o rd a t a a n a l y s i sa n dp r o c e s s i n go fm u n i c i p a i f a c i t j e sf 6 rt h ed a i l ym a n a g e m e n t ，m a i n t e n a n c e a n d r e p a i r 0 f e m e r g e n c yc o n t i n g e n c yc o m m a n dp r o c e s s i n g ， o p t i m i z i n g t h e m a n a g e m e n to fp r o v i d et h eb a s i sf b rs c h e d u n gd e c i s i o n sa n dg u i d a n c e ，t om a k e s c i e n t l f i cd e c i s i o n s t h i sp a p e rs t u d i e st h ec o n s t r u c t o no fm u n i c i p a lk e yt e c h n o i o g yi n t e g r a t e di n f o r m a t i o n p i a t i o r m p r o p o s e dm u i t i - i a y e rs t r u c t u r eo fh e t e r o g e n e o u sd i s t r j b u t e dd a t a b a s e s y s t e m ， a n db u i ta九1 p r e h e n s i v ed a t a b a s eo fm u n i c i p a i p i p en e t 、 ，o r k ， a n d i n t r i ) d u c e dac o m p r e h e n s i v ed a t a b a s eo nm u n i c i p a ip i p en e t w o r kp i a n n i n g ，d e s j g n ， m a n a g e m e n t ，t h r e ee x a m p l e so ft h ea p p i j c a t i o n j k e y w o r d s ：m 硼【i c i p a le n 百n e 锄g g i ss u a l i z a t i o n i i 北京工业大学工学硕士学位论文 目录 摘要i a b s 仃a c t i i 第1 章绪论1 1 1研究背景与意义- 1 1 2 国内外研究现状1 1 2 1 数据库系统发展1 1 2 2地理信息系统2 1 2 - 3 市政信息化管理发展3 1 3 课题的来源和内容。3 1 3 1本课题的来源3 1 3 2 主要研究内容3 第2 章多层异构分布式数据库架构5 2 1架构5 2 2 功能5 2 3 本章小结7 第3 章市政管网综合数据库构建9 3 1 需求分析一1 0 3 2概念结构设计1 0 3 3 1 概念结构设计的方法步骤1 0 3 3 2 数据抽象、局部视图的设计和视图集成1 1 3 3 3 概念结构设计的步骤1 2 3 3 逻辑结构设计1 5 3 3 1 e r 图到关系模式的转换1 5 3 3 2 关系模式的优化一1 6 - 3 3 3 用户子模式设计1 6 3 4 物理结构设计1 7 3 5 本章小结一1 8 北京工业大学工学硕十学位论文 第4 章市政管网综合数据库数据转换一1 9 ， 4 1 中间层结构2 0 ， 4 2 客户端2 0 4 3 服务端2 0 4 4 数据转换流程2 0 4 5 本章小结2 6 第5 章应用实例。2 7 5 1 管理分析实例2 7 5 1 1 项目背景2 7 5 1 2 管理分析应用2 7 5 2 设计分析实例3 0 5 2 1 项目背景3 0 5 2 2 设计分析应用3 0 5 3 规划分析实例：3 2 5 3 1 项目背景3 2 5 3 2 规划分析应用3 2 5 4 本章小结3 5 第6 章结论与展望3 7 参考文献3 9 攻读硕士学位期间所发表的学术论文4 1 - 蜀【 谢4 3 第1 章绪论 第1 章绪论 1 1研究背景与意义 城市管网系统是重要的城市基础设施，随着城市建设进程的加快，市政设施 也得到了迅速的发展。随之带来了大量复杂、繁琐的管理工作，原来仅凭经验、 图纸的管理方法已不能适应当前的市政管理的需要。系统在市政设施基础资料的 数字化、现代化、动态信息的自动化、信息化的基础上，实现市政设施数字化信 息管理、管理调度、事故处理、规划设计的自动化，并逐步扩大规模、开发功能 模块、实现排水系统的数字化、智能化的专家管理运营调度系统，对市政设施进 行科学的长期规划、合理安排、准确调度、水力状况模拟已成为城市市政系统发 展的一种趋势。 市政设施信息化管理系统建设是利用地理信息系统( g i s ) 、可视化监控系统 等计算机技术和手段，对市政设施及相关系统的各方面数据进行全方位的信息化 处理，从而形成对市政行业的相关系统进行数字网络化管理、服务。市政设施信 息化管理系统建设的主要内容是将市政公用设施纳入统一的信息网络平台，进行 数据的分析和处理，为市政设施的日常管理、养护和维修、对突发事件实施应急 指挥处理、优化管理工作的调度决策提供依据和指导，做出科学决策。 1 2国内外研究现状 1 2 1 数据库系统发展 数据库系统的核心是数据模型，数据模型的发展经历了格式化数据模型包括 层次模型、网状模型、关系数据模型两个阶段，正在走向面向对象的数据模型等 非传统数据模型的新阶段。从数据模型的发展来看，数据库技术的发展相应也经 历了三个阶段l l j ： ( 1 ) 第一代数据库系统 2 0 世纪7 0 年代，以网状模型、层次模型为代表的第一代数据库得到发展， 实现了数据集中控制和共享。支持三级模式的体系结构外模式、模式、内模式， 用存取路径来表示数据之间的联系，有独立的数据定义语言，但数据一经定义就 不易修改，体现出一定局限性。 ( 2 ) 第二代数据库系统 2 0 世纪8 0 年代，以关系模型为代表的关系数据库，由关系数据结构、关系 操作集合、关系完整性约束三部分构成，不仅简单，清晰，而且有关系代数作为 语言模型，有关系理论作为理论基础，因此具有很好的发展形式。关系数据库系 统的发展也促进了数据库系统的小型化。典型代表有：1 9 7 6 年，i b ms a n j o s e 研 北京t 业大学t 学硕士学位论文 究室推出的s y s t 锄r 和加州大学伯克利分校的i n g r e s 关系数据库。 ( 3 ) 新一代数据库系统 2 0 世纪8 0 年代末9 0 年代初，开发新一代数据库以处理除常规数据外的数 据，比如对图形、图像、声音、视频等多媒体数据、动态数据、空间数据、知识 信息以及各种复杂对象等非常规数据提供新的数据处理功能，为此提出了许多新 概念、新思想、新方法。比如分布式数据库、w 曲数据库、面向对象数据库、并 行数据库、多媒体数据库、主动数据库、数据仓库、工程数据库、空间数据库等。 1 2 2 地理信息系统 g i s ( g e o g r a l 湎ci n f o n n a t i o ns y s t e m ) 即地理信息系统，是在计算机软、硬 件系统支持下，对现实世界( 资源、设备与环境) 各类空间数据及采集、储存、管 理、运算、分析、显示和描述关于这些空间数据特性的技术系统，它是集计算机 科学、地理学、测绘遥感学、环境科学、城市科学、空间科学、信息科学和管理 科学为一体的。它作为新兴边缘学科迅速地兴起和发展起来。地理信息系统中“地 理的概念并不等同于简单的地理学概念，而是广义地指地理坐标参照系统中的 坐标数据、属性数据以及由此演义出来的知识。 在应用需求和技术进步的双重驱动下，g i s 软件技术体系得到迅速发展。当 今g i s 蓬勃发展，g i s 的发展趋势就是组件化，这也是g i s 的重要发展方向之一。 从发展历程看，g i s 可以划分为几个重要发展阶段：g i s 模块、集成式g i s 、模 块化g i s 和核心式g i s 。这些g i s 软件需要另外的g i s 二次开发语言，并且开 发出来的系统扩展性不好，不能很好的满足给排水行业的需求。目前，c o m g i s 和w 曲g i s 是g i s 日益明显的发展趋势。c o m g i s 逐渐成为开发c s 模式应用系 统客户端的首选g i s 软件，它的各组件之间可以自由、灵活地重组，并且具有方 便的标准接口和可视化的界面，不需要另外的g i s 开发语言，只需按照m i c r o s o r 的a c t i v e x 控件标准开发接口，实现g i s 的基本功能函数，使g i s 软件开发简 化，而且增强了软件的可扩展性。g i s 软件系统开发者，不必掌握其它的g i s 开 发语言，只需熟悉基于w i n d o w s 平台的通用开发环境，以及c o m g i s 各个控件 的属性、方法和事件，就可以完成应用系统的开发和集成【2 1 。 c o m g i s 具有高效的系统无缝集成功能，将专业模型、c o m g i s 控件、其它 控件在统一的界面下紧密地结合；利用c o m g i s 就不需要专门的g i s 开发语言； 由于用户使用c o m g i s 的控件可以象使用其它a c t i v e x 控件一样，非专业的g i s 用户也能对g i s 进行应用开发工作，大大降低了系统开发的复杂程度和成本【3 】。 c o m g i s 基于标准的组件式平台，这些组件式平台主要有m i c r o s o r 的 c o m ( c o m p o n e n to b j e c tm o d e l ，组件对象模型) d c o m ( d i s 伍b u t e dc o m p o n e 1 1 _ t o b j e c tm o d e l ，分布式组件对象模型) 和o m g 的c o r b a ( c o m m o n0 l b j e c tr e q u e s t b r o k e r 心c 1 1 i t e 眦e ，公共对象请求代理体系结构) ，目前占市场领导地位的是 2 第1 章绪论 m i c r o s o r c o m d c o m 。m i c r o s o ：【推出了基于c o m d c o m 的a c t i v e x 技术，标 准组件a c t i v e x 控件在当今可视化程序设计中应用最为广泛。新一代的c o m g i s 也大都是a c t i v e x 控件或者其前身o l e 控件。c o m g i s 代表着当今g i s 发展的 潮流。本系统是基于c o m a c t i v e x 规范的c o m g i s 开发的【4 1 。 纵观g i s 软件的发展历程，组件化是一个非常重要的趋势，研究这一技术， 对于我国g i s 产业的发展具有重要意义。而其中c o m g i s 在与m i s 耦合、i n t e m e t 应用、降低开发成本和复杂程度等方面，具有明显优势【5 】。同时也打破了以往少 数厂商垄断g i s 基础软件的局面，小型研究机构和厂商有机会打入g i s 基础软 件市场，来提供专业组件。我国g i s 基础软件起步较晚，c o m g i s 技术为我国 g i s 基础软件的开发提供非常难得的机会。 1 2 3 市政信息化管理发展 目前发达国家已经将市政管理运用以计算机技术、通信技术实现了数字化。 我国发达地区如广州、北京已经拉起了开始建设“数字市政的帷幕，已经在日 常的市政管理、应急救灾、规划决策、园林环保、市政执法等方面发挥了极其巨 大的作用。城市的管理必将实现数字化、智能化、信息化，必将形成对市政公用 行业实行数字网络化管理、服务与决策的信息体系。通过对市政系统数字化、网 络化、可视化、优化决策支持等手段，可以大大提高管理水平，提高工作效率， 节能降耗，具有重大的经济效益和社会效益。 1 3 课题的来源和内容 1 3 1 本课题的来源 本研究课题来源于“十一五”国家科技支撑计划“城市市政管网规划建设与 运营管理关键技术研究与示范( 2 0 0 6 b a j l 6 8 0 4 ) ”的子课题“城市市政管网信息 管理系统及可视化动态管理系统研究”。 1 3 2 主要研究内容 1 市政管网综合信息平台架构体系 2 市政管网综合数据库的构建 3 市政管网综合数据库数据转换 北京工业大学t 学硕+ 学位论文 4 第2 章多层异构分布式数据架构 第2 章多层异构分布式数据库架构 随着城市化进程的不断发展，对传统的城市管理方法提出了新的挑战，采用 先进的数字化技术应对市政管网系统的突发事件，是城市科学法发展的需要。 2 1传统方式 涉及城市市政管网基础信息的单位有自来水公司、排水公司、供热公司和燃 气公司等，目前市政管网综合信息平台的构建方式是将各个部门的数据收集到一 起，通过重新组织，构建出一套新的管网综合数据库系统。这种方式的缺点主要 是产生很多重复性的工作，更新数据也十分繁琐，容易产生数据冗余。 2 2多层异构分布式架构 采用多层、异构、分布式数据库技术可以将分布在不同部门的信息资源进行 整合。通过计算机网络技术实现应用范围的扩充，数据库应用建立于计算机网络 之上。 城市市政管网是由给水管网、排水管网、燃气管网、热力管网、电力管网、 通信管网构成的，不同类型管网的管理权属于不同的职能部门( 例如自来水公司、 排水公司等) ，各职能部门内又分成各子部门( 例如各水务分公司等) 。这些子部 门是城市市政管网数据信息的第一收集者，也就是整个多层异构分布式架构体系 的最底层结构部分。各职能部门是数据信息的第二收集者，信息平台是数据的最 终收集者，通过定期的数据汇总更新，将分布在各个位置的数据源汇总到信息平 台。信息平台对汇总的数据进行面向不同用户的分析工作。使得信息平台能够对 分布在不同位置的数据库系统进行统一管理。将数据按实际需要在网络上分布存 储，原始基础数据的录入、校核与更新都由资产管理部门实施，采用分布式管理 模式实现数据的集中式处理，这项可以保证数据的精确性和实时性，避免多头进 行数据采集，数据不吻合与更新困难等问题。 由于各个职能部门所使用的数据库系统不一定是统一的，所以构架数据库综 合平台的关键在于建立一个信息平台数据转换平台，将不同来源的数据库管理系 统进行统一化，将来自不同数据源的数据统一成信息平台的数据库格式，并在该 数据库的基础上，利用信息平台数据库应用接口平台，为各种应用服务提供的数 据库接口。架构图见图2 1 。 2 3功能 1 规划分析 规划部门可以通过信息平台查看现有设施布置隋况。例如通过查看道路纵断 面图察看现有管线的布置情况，从而解决管线综合问题。 北京工业大学工学硕士学位论文 2 设计分析 设计部门可以通过信息平台使用模型对已有管网进行设计校核。 3 管理分析 管理部门可以通过信息平台检查基础设施的使用状况等。 ” 第2 章多层异构分布式数据架构 2 4本章小结 本章介绍了多层异构分布式数据库的架构与功能。通过使用多层异构分布式 的数据库架构方式，使得信息平台与各职能部门成为一个整体，减少了不必要的 数据冗余。使得信息平台能够对分布在不同位置的数据库系统进行统一管理。 7 北京f t 业大学工学硕士学位论文 8 第3 章市政管网综合数据库构建 第3 章市政管网综合数据库构建 数据库设计步骤包括： 1 需求分析阶段 进行数据库设计首先必须准确了解与分析用户需求( 包括数据与处理) 。需 求分析是整个设计过程的基础，是最困难、最耗时的一步。作为基础的需求分析 是否做得充分与准确，决定了在其上构建数据库大厦的速度与质量。需求分析做 得不好，甚至会导致整个数据库设计返工重做。 2 概念结构设计阶段 概念结构设计是整个数据库设计的关键，它通过对用户需求进行综合、归纳 与抽象，形成一个独立于具体的数据库管理系统( d b m s ) 的概念模型。 3 逻辑结构设计阶段 逻辑结构设计将概念结构转换为某个d b m s 所支持的数据模型，并对其进行 优化。 4 物理结构设计阶段 数据库物理设计是为逻辑数据模型选取一个最适合应用环境的物理结构( 包 括存储结构和存取方法) 。 设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述四个阶 段的不断反复的过程。见图3 1 。 图3 1 数据库应用程序的生存周期的各个阶段 北京t 业大学工学硕士学位论文 3 1需求分析 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要 求、安全性与完整性要求。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法，而最常 用的是自顶向下的方法，这是一种简单实用的方法： 自顶向下的结构化分析方法( s t m c t u r e da n a l v s i s ，简称s a 方法) 从最上层 的系统组织机构入手，采用逐层分解的方式分析系统，并且把每一层用数据流图 和数据字典描述。数据流图表达了数据和处理过程的关系。系统中的数据则借助 数据字典( d a t 扣i c t i o n a 巧，简称d d ) 来描述。 在通过s a 方法分析系统时，设计者首先要把系统抽象成如下形式：( 见图 3 - 2 ) 图3 2 系统抽象 然后将处理功能的具体内容分解为若干子功能，再将各个子功能继续分解， 直到把系统的工作过程表达清楚为止。在处理功能逐步分解的同时，它们所用的 数据也逐级分解，形成若干次的数据流图。数据流图表达了数据和处理过程的关 系。 在对整个模块的功能进行抽象描述后，就该用数据字典来描述各类数据了， 对数据库设计来讲，数据字典是进行数据收集和数据分析所获得的主要成果。数 据字典是各类数据描述的集合。数据字典是关于数据库中数据的描述，即元数据， 而不是数据本身。数据本身将存放在物理数据库中，由数据库管理系统管理。数 据字典有助于这些数据的进一步管理和控制，为设计人员和数据库管理员在数据 库设计、实现和运行阶段控制有关数据提供依据【6 】。 数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部 分【_ 丌。数据项是不可再分的数据单位。系统中所有的使用的数据，都必须使用数 据字典来进行描述【引。 3 2 概念结构设计 3 2 1 概念结构设计的方法步骤 设计概念结构通常有四类方法【9 】： 自顶向下。即首先定义全局概念结构的框架，然后逐步细化。 第3 苹市政管网综合数据库构建 自底向上。即首先定义各局部应用的概念结构，然后将它们集成起来，得到 全局概念结构。 逐步扩张。首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方 式逐步生成其他概念结构，直至总体概念结构。 混合策略。即将自顶向下和自底向上相结合，用自顶向下策略设计一个全局 概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。 其中最经常采用的策略是自底向上方法。即自顶向下地进行需求分析，然后 再自底向上地设计概念结构。但无论采用哪种方法，一般都以实体联系模型为工 具来描述概念结构。 自底向上的概念结构设计方法，这种方法是首先定义各局部应用的概念结 构，然后将它们集成，得到全局的概念结构，如图3 3 所示。 3 2 2 数据抽象、局部视图的设计和视图集成 概念结构是对现实世界的一种抽象。即对实际的人、物、事和概念进行人为 处理，抽取所关心的共同特性，并将其用概念加以描述，组成模型。数据抽象一 般分为三种：分类、聚集和概括【l 们。 ( 1 ) 分类 定义某一类概念作为现实世界中一组对象的类型，具有某些共同的特性和行 为。e r 模型中，实体型就是这种抽象。 ( 2 ) 聚集 定义某一类型的组成成分。e r 模型中若干属性的聚集组成了实体型。 ( 3 ) 概括 定义了类型之间的一种子集联系。即把实体分为若干子类。 北京工业大学工学硕士学位论文 图3 3 自底向上的概念结构设计 3 2 - 3 概念结构设计的步骤 概念结构设计的第一步就是利用抽象对需求分析阶段收集到的数据进行分 类组织，形成实体、属性，确定联系，设计e r 图。设计e r 图步骤如副1 1 】： 需求分析 概念结构设计 图3 - 4 设计e r 图的步骤 ( 1 ) 选择局部应用， 在需求分析阶段，我们已对应用环境和要求进行了详尽的调查分析，并用多 层数据流图和数据字典描述了整个系统。设计分e r 图的第一步，就是要根据系 第3 章市政管网综合数据库构建 统的具体情况，在多层数据流图中选择一个适当层次的数据流图，让这组图中每 一部分对应一个局部应用，即可以用这一层次的数据流图为出发点，设计分e r 图。 由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映 系统中局部应用的子系统组成，因此人们往往以中层数据流图作为设计分e 。r 图 的依据【1 2 】。 ( 2 ) 逐一设计分e r 图 每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数 据字典中。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定 局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。 现实世界中一组具有某些共同特征和行为的对象可以抽象为一个实体【1 3 1 。对 象类型的组成成份可以抽象为实体的属性。同一事物，在一种应用环境中作为“属 性 ；在另一种应用环境中就必须作为“实体 。 一般说来，在给定的应用环境中【1 4 】：属性不能再具有需要描述的性质。即属 性必须是不可分的数据项，不能再由另一些属性组成。联系只发生在实体之间。 符合上述两条特性的事物一般作为属性对待。为了简化e r 图的处置，现实世界 中的事物凡能够作为属性对待的，应尽量作为属性。 ( 3 ) 分e r 图的集成 各子系统的分e r 图设计好以后，下一步就是要将所有的分e r 图综合成 一个系统的总e r 图。集成一般采用逐步累积的方式，即首先集成两个局部视图 ( 通常是比较关键的两个局部视图) ，以后每次将一个新的局部视图集成进来。 当然，如果局部视图比较简单，也可以一次集成多个分e r 图【l5 1 。 一般说来，视图集成可以有两种方式：多个分e r 图一次集成；逐步集成， 用累加的方式，一次集成两个分e r 图。 第一种方法比较复杂，做起来难度较大。第二种方法每次只集成两个分e r 图，可以降低复杂度。不论采用哪种方式，每次集成可以先解决各分e r 图之间 的冲突，将各分e r 图合并起来生成初步e r 图，然后对其进行修改，消除不 必要的冗余，生成基本e r 图。 集成局部e r 图都需要两步：1 ) 合并，修改与重构。合并分e r 图，生 成初步e r 图。各个局部应用所面向的问题不同，且通常是由不同的设计人员 进行局部视图设计，这就导致各个分e r 图之间必定会存在许多不一致的地方， 因此合并分e r 图时并不能简单地将各个分e r 图画到一起，而是必须着力 消除各个分e r 图中的不一致，以形成一个能为全系统中所有用户共同接受的 统一的概念模型。合理消除各分e r 图的冲突是合并分e r 图的主要工作与 关键所在【l6 1 。各分e r 图之间的冲突主要有三类：属性冲突、命名冲突与结构 冲突【r 7 1 。属性冲突：属性域冲突，即属性值的类型、取值范围或取值集合不同。 1 3 北京工业大学工学硕士学位论文 属性取值单位冲突。命名冲突：同名异义，即不同意义的对象在不同的局部应用 中具有相同的名字。异名同义，即同一意义的对象在不同的局部应用中具有不同 的名字。命名冲突可能发生在实体、联系一级上，也可能发生在属性一级上。其 中属性的命名冲突更为常见。结构冲突：同一对象在不同应用中具有不同的抽象。 解决方法通常是把属性变换为实体或把实体变换为属性，使同一对象具有相同的 抽象。但变换时仍要遵循前面的区分属性和实体的准则。 同一实体在不同局部视图中所包含的属性不完全相同，或者属性的排列次序 不完全相同。这是很常见的一类冲突，原因是不同的局部应用关心的是该实体的 不同侧面。解决方法是使该实体的属性取各分e r 图中属性的并集，再适当设 计属性的次序【1 8 】。 实体之间的联系在不同局部视图中呈现不同的类型。例如，实体e l 与e 2 在局部应用a 中多对多联系，而在局部应用b 中是一对多联系；又如在局部应 一“ 用x 中e l 与e 2 发生联系，而在局部应用y 中e 1 、e 2 、e 3 三者之间有联系。 解决方法是根据应用的语义对实体联系的类型进行综合或调整【1 9 】。 2 ) 修改与重构，生成最终e r 图 分e r 图经过合并生成的是初步e r 图。之所以称其为初步e r 图， 是因为其中可能存在冗余的数据和冗余的实体问联系。所谓冗余的数据是指可由 基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余数据和冗 余联系容易破坏数据库的完整性，给数据库维护增加困难，因此得到初步e r 图后，还应当进一步检查e r 图中是否存在冗余，如果存在则一般应设法予以 消除【2 0 1 。 修改、重构初步e r 图以消除冗余主要采用分析方法，即以数据字典和数 据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。并 不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高某些应用的效 率，不得不以冗余信息作为代价【2 。因此在设计数据库概念结构时，哪些冗余信 息必须消除，哪些冗余信息允许存在，需要根据用户的整体需求来确定。 视图集成后形成一个整体的数据库概念结构，对该整体概念结构还必须进一 步验证，确保它能够满足下列条件： 。 整体概念结构内部必须具有一致性，即不能存在互相矛盾的表达。 整体概念结构能准确地反映原来的每个视图结构，包括属性、实体及实体间 的联系。 整体概念结构能满足需求分析阶段所确定的所有需求。 整体概念结构最终还应当提交给用户，征求用户和有关人员的意见，进行评 审、修改和优化，然后把它确定下来，作为数据库的概念结构，作为进一步设计 数据库的依据。 第3 章市政管网综合数据库构建 3 3逻辑结构设计 逻辑结构设计的任务就是把概念结构设计阶段设计好的基本e r 图转换为 与选用的具体机器上的d b m s 产品所支持的数据模型相符合的逻辑结构。从理 论上讲，设计逻辑结构应该选择最适于描述与表达相应要领结构的数据模型，然 后对支持这种数据模型的各种d b m s 进行比较，综合考虑性能、价格等各种因 素，从中选出最合适的d b m s 。目前d b m s 产品一般只支持关系、网状、层次 三种模型中的某一种，对某一种数据模型，各个机器系统又有许多不同的限制， 提供不同的环境与工具。所以逻辑结构设计分为下面几个步骤：将概念结构向一 般关系模型转化；将第一步得到的结构向特定的d b m s 支持下的数据模型转换； 依据应用的需求和具体的d b m s 的特征进行调整与完善。 3 3 1e r 图到关系模式的转换 e r 图向关系模型的转化要解决的总是如何将实体和实体间的联系转换为 关系模式，如何确定这些关系模式的属性和码。关系模型的逻辑结构是一组关系 模式的集合。而e r 图则是由实体、实体的属性和实体之间的联系三个要素组 成的。所以将e r 图转换为关系模型实际上就是要将实体、实体的属性和实体 之间的联系转化为关系模式，这种转换一般遵循如下原则【2 2 】： ( 1 ) 一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体 的码就是关系的码。 ( 2 ) 一个m ：n 联系转换为一个关系模式。与该联系相连的各实体的码以 及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。 ( 3 ) 一个1 ：n 联系可以转换为一个独立的关系模式，也可以与n 端对应 的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的 码以及联系本身的属性转换为关系的属性，而关系的码为n 端实体的码。 ( 4 ) 一个1 ：l 联系可以转换为一个独立的关系模式，也可以与任意一端 对应的关系模式合并【2 3 1 。如果转换为一个独立的关系模式，则与该联系相连的各 实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的 候选码。如果与某一端对应的关系模式合并，则需要在该关系模式的属性中加入 另一个关系模式的码和联系本身的属性。 ( 5 ) 三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多 元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码 为各实体码的组合。 ( 6 )同一实体集的实体间的联系，即自联系，也可按上述1 ：1 ，1 ：n ， m ：n 三种情况分别处理。 ( 7 ) 具有相同码的关系模式可合并。为了减少系统中的关系个数，如果两 个关系模式具有相同的主码，可以考虑将他们合并为一个关系模式。合并方法是 北京工业大学t 学硕士学位论文 将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义 属性( 可能同名也可能不同名) ，并适当调整属性的次序。 形成了一般的数据模型后，下一步就是向特定的d b m s 规定的模型转换。 设计人员必须熟悉所用d b m s 的功能与限制。这一步是依赖于机器的，不能给 出一个普遍的规则，但对于关系数据库说来，这一步一般不会遇到什么困难。 3 3 2 关系模式的优化 数据模型的调整和完善：数据库逻辑设计的结果不是唯一的。在逻辑结构设 计基本完成之后，再根据应用需要对设计结构进行适当的修改和调整以期进一步 完善设计，提高应用系统的性能。关系数据模型的优化通常以规范化理论为指导。 方法如下： 确定数据依赖，即按需求分析阶段所得到的语义，分别写出每个关系模式内 部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。对于各个关系模 式之间的数据依赖进行极小化处理，消除冗余的联系【2 4 1 。 按照数据依赖的理论对关系模式逐一进行分析，考查是否存在部分函数依 赖、传递函数依赖、多值依赖，确定某个关系模式分别属于第几范式。 按照需求分析阶段得到的种种应用对数据处理的要求，分析对于这样的应用 环境这些模式是否合适，确定是否要对它们进行合并或分解。对关系模式进行必 要的分解或合并。 根据“8 0 2 0 原则，即一个大关系中，经常被使用的数据只是关系的一部分， 约2 0 ，所以可以把经常使用的数据分解出来，形成一个子关系。 另外并不是规范化程度越高的越优。当一个应用的查询中经常涉及到两个或 多个关系模式的属性时，系统必须经常地进行联接运算，而联接运算的代价是相 当高的，可以说关系模型低效的主要原因就是做联接运算引起的，因此在这种情 况下，第二范式甚至第一范式也许是最好的。所以对于一个具体应用来说，到底 规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊才能决定。但 就一般而论，第三范式也就足够了【2 5 1 。 3 3 3 用户子模式设计 根据局部应用需求结合d b m s 特点设计用户子模式。 前面根据用户需求设计了局部应用视图，这种局部应用视图只是概念模型， 用e r 图表示。在将要领模型转换为逻辑模型后，即生成了整个应用系统的模 式后，还应当根据局部应用需求，结合具体d b m s 的特点，设计用户的外模式。 目前关系数据库管理系统一般都提供了视图概念，支持用户的虚拟视图。现在一 般多用户的