数据库设计流程

数据库设计流程（推荐8篇）

数据库设计流程篇1

目前数据库设计一般分为6个阶段，即需求分析阶段，概念结构设计阶段，逻辑结构设计阶段，物理结构设计阶段，实施阶段，运行与维护阶段。

(1)需求分析阶段

需求分析阶段的主要任务是指通过充分调查现实世界要处理的对象, 详细了解计算机系统的工作情况, 明确用户的各种需求, 然后确定系统的各项功能。数据库系统不仅要按照当前的应用要求来设计, 而且必须充分考虑今后可能的扩充和改变。

(2)概念结构设计阶段

概念结构设计阶段的主要任务是将需求分析阶段所得到的用户需求抽象为概念模型, 而描述概念模型的具体工具主要是E-R 模型。

(3)逻辑结构设计阶段

逻辑结构设计阶段的主要任务是把概念结构设计阶段设计的基本E-R 模型转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。具体来说, 就是首先将概念结构转换为一般的关系、网状、层次模型, 然后将转换来的模型向特定DBMS 支持下的数据模型转换, 最后对数据模型进行优化。

(4)物理结构设计阶段

物理结构设计阶段的主要任务是为一个指定的逻辑数据模型选取一个符合应用要求的物理结构。具体来说, 就是首先确定数据库的物理结构, 即数据库的存取方法和存储结构;然后对数据库的物理结构进行评估, 评估的重点是存取时间的长短和存储空间的大小。

(5)实施阶段

实施阶段的主要任务是用RDBMS 提供的数据定义语言和其他实用程序将逻辑结构设计和物理结构设计的结果详细描述出来, 成为DBMS 可以接受的源代码;再经过系统调试产生目标模式, 最后完成数据的载入工作。

(6)运行与维护阶段

数据库设计流程篇2

数据库设计中需求分析阶段应综合各个用户的应用需求 (现实世界的需求) , 在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式 (信息世界模型) , 用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型, 形成数据库逻辑模式。

根据用户处理的要求, 安全性的考虑, 在基本表的基础上再建立必要的视图 (VIEW) 形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要, 进行物理存储安排, 设计索引, 形成数据库内模式。

1 需求分析阶段

需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。主要是采用跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录等方法, 对组织机构情况、各部门的业务活动情况进行调查, 从而协助用户明确对新系统的各种要求、确定新系统的边界。需求收集和分析工作输出应为数据字典描述的数据需求和数据流图描述的处理需求。具体要完成以下工作:

(1) 理解客户需求, 询问用户如何看待未来需求变化。让客户解释其需求, 而且随着开发的继续, 还要经常询问客户保证其需求仍然在开发的目的之中。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法 (Structured Analysis, 简称SA方法) 是从最上层的系统组织机构入手, 采用逐层分解的方式分析系统, 并把每一层用数据流图和数据字典作出描述。

(2) 了解企业业务可以在以后的开发阶段节约大量的时间。

(3) 重视输入输出。

在定义数据库表和字段需求 (输入) 时, 首先应检查现有的或者已经设计出的报表、查询和视图 (输出) 以决定为了支持这些输出哪些是必要的表和字段。

(4) 创建数据字典和E-R图表

E-R图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用, 而数据字典是各类数据描述的集合, 它是关于数据库中数据的描述, 即元数据, 而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分 (至少应该包含每个字段的数据类型和在每个表内的主外键) , 用以说明每个字段的用途以及任何可能存在的别名。

(5) 定义标准的对象命名规范

数据库各种对象的命名必须规范。确定变量、数据库对象、触发器、存储过程等的命名规则。

在需求阶段应注意三点:

(1) 考虑到可能的扩充和修改, 应做到易于修改和扩展。

(2) 强调客户参与:更好地理解客户的需求, 了解客户对程序安全性和完整性的要求, 以及用户的处理需求。而且随着开发的继续, 还要经常询问客户保证其需求仍然在开发的目的之中。

(3) 维护一套共享的系统设计和说明书文档, 为所有的信息而开发和维护一个公共资料库。包含:设计会议记录, 口头更改需求记录和最终的所有说明书, 包括功能、技术、测试等各方面的内容。

2 概念结构设计阶段

通过对用户需求进行综合、归纳与抽象, 形成一个独立于具体DBMS的概念模型, 可以用E-R图表示。

概念模型特点:

(1) 较强的语言表达能力, 能够直接、方便地表达各种语义。

(2) 简单、清晰并易于理解, 便于用户与设计人员之间的交流。

概念模型设计的一种常用方法为IDEF1X方法, 它是把实体-联系方法应用到语义数据模型中的一种语义模型化技术, 用于建立系统信息模型。

使用IDEF1X方法创建E-R模型的步骤如下所示:

2.1 工程初始化

从目的描述和范围描述开始, 确定建模目标, 开发建模计划, 组织建模队伍, 收集源材料, 制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果、业务流程、原有系统的输入输出、各种报表、收集原始数据, 形成基本数据资料表。

2.2 实体定义

实体集成员都有一个共同的特征和属性集, 可以从收集的源材料———基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语, 如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来, 从而初步找出潜在的实体, 形成初步实体表。

2.3 定义联系

IDEF1X模型中只允许二元联系, n元联系必须定义为n个二元联系。根据实际的业务需求和规则, 使用实体联系矩阵来标识实体间的二元关系, 然后根据实际情况确定出连接关系的势、关系名和说明, 确定关系类型, 是标识关系、非标识关系 (强制的或可选的) 还是非确定关系、分类关系。

2.4 定义码

通过引入交叉实体除去上一阶段产生的非确定关系, 然后从非交叉实体和独立实体开始标识侯选码属性, 以便唯一识别每个实体的实例, 再从侯选码中确定主码。为了确定主码和关系的有效性, 通过非空规则和非多值规则来保证。找出误认的确定关系, 将实体进一步分解, 最后构造出IDEF1X模型的键基视图 (KB图) 。

2.5 定义属性

从源数据表中抽取说明性的名词开发出属性表, 确定属性的所有者。定义非主码属性, 检查属性的非空规则及非多值规则。检查完全依赖函数规则和非传递依赖规则, 保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。

2.6 定义其他对象和规则

定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。

3 逻辑结构设计阶段

将概念结构转换为某个DBMS所支持的数据模型, 并对其进行优化。设计逻辑结构应该选择适于描述与表达相应概念结构的数据模型, 然后选择合适的DBMS。

将E-R图转换为关系模型, 实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式, 这种转换一般遵循如下原则:

(1) 一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。

(2) 一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。

(3) 一个1:n联系可以转换为一个独立的关系模式, 也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式, 则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性, 而关系的码为n端实体的码。

(4) 一个1:1联系可以转换为一个独立的关系模式, 也可以与任意一端对应的关系模式合并。

(5) 三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。

(6) 同一实体集的实体间的联系, 即自联系, 也可按上述1:1、1:n和m:n三种情况分别处理。

(7) 具有相同码的关系模式可合并。

为了进一步提高数据库应用系统的性能, 通常以规范化理论为指导, 还应该适当地修改、调整数据模型的结构, 即数据模型的优化。确定数据依赖, 消除冗余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准, 即:

表内的每一个值都只能被表达一次。

表内的每一行都应该被唯一地标识 (有唯一键) 。

表内不应该存储依赖于其他键的非键信息。

4 数据库物理设计阶段

为逻辑数据模型选取一个最适合应用环境的物理结构 (包括存储结构和存取方法) 。根据DBMS特点和处理的需要, 进行物理存储安排, 设计索引, 形成数据库内模式。

5 数据库实施阶段

运用DBMS提供的数据语言及其宿主语言 (例如C) , 根据逻辑和物理设计的结果建立数据库, 编制与调试应用程序, 组织数据入库, 并进行试运行。数据库实施主要包括:用DDL定义数据库结构、组织数据入库、编制与调试应用程序、数据库试运行。

6 数据库运行和维护阶段

数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。包括:数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

摘要：数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境, 构造最优的数据库模式, 建立数据库及其应用系统, 有效存储数据, 满足用户信息要求和处理要求。

数据库设计流程篇3

摘要：随着高校数字校园的快速发展，校内业务系统间共享数据的需求愈发强烈，高校数据共享平台因此成为数字校园建设的关键基础设施。高校数据共享平台仅仅依靠技术手段实现存在许多问题，需要从业务流程的角度来分析和设计。本文通过对高校数据共享平台建设目标及当前存在问题的分析，设计了基于业务流程的高校数据共享平台建设模型。该模型阐释了如何从业务流程的角度，分析和设计信息流、数据流，满足高校不同部门业务信息系统间数据的可靠共享和管理部门的决策支持。该模型能较好地解决高校当前数据共享平台建设中数据共享流程不畅、共享数据管理困难、责任主体不清、决策支持难实现等难题，为高校数据共享平台建设提供新的思路和借鉴。

关键词：业务流程；高校数据共享平台；数据集成；信息孤岛

中图分类号：G40-05 文献标志码：A 文章编号：1673-8454（2016）11-0093-04

一、引言

1.研究背景

当前各高校在数字校园建设中，取得了丰硕成果，软硬件基础设施有了很大的提升，建成了如OA、人事系统、教务系统、资产系统、一卡通系统等众多业务信息系统，提高了工作效率，增强了工作人员的信息素养，并在学校管理人员中营建了良好的信息化建设的氛围。而在此过程中，数据共享平台由于其基础性、全局性的特点，成为数字校园建设的关键基础设施。

高校数据共享平台相关的文献很多，虽然名称不同，建设方案各异，但基本目标是一致的。一般而言，数据共享平台主要有两个目标：一是解决“信息孤岛”的问题；二是实现决策支持。“信息孤岛”是由于各业务系统建设时间不同，架构不同，相互之间缺乏共享机制造成的。决策支持则是希望数据共享平台能提供全局性的信息报表，以利于决策层掌握全校的真实情况，从而科学决策。针对这两个目标，现有文献多从技术上提出相应的解决方案。如俞春等[1]提出建设数据共享交换平台，然后根据用户需求选择数据集成工具。周学理[2]提出建设共享数据库中心，并在共享数据库基础上实现决策支持。于宁等[4]则提出建设基于数据仓库的高校决策支持系统。这些技术上的方案，为数据共享平台的构建提供了技术上的可行性，但在实际建设中仍存在许多亟需解决的问题。

2.高校数据共享平台建设中存在的问题

（1）数据共享流程不畅

信息管理部门往往将数据共享看作技术工作，不去设计共享流程，或者只设计数据库之间的共享流程，没有把业务部门考虑进来，无法建立全面的数据共享流程。其结果是共享数据的内容并不是业务部门所想要的内容，进而降低业务部门对共享数据的信任度。

（2）共享数据管理困难

共享数据存储于共享数据库中，其管理不但需要数据库管理知识，而且需要业务知识，这对业务人员和信息管理人员均有难度；而且由于数据集成不直观，各种集成参数设定后很难更改，不利于后期的运维管理。

（3）责任主体不清

这主要表现在数据共享是业务部门与信息管理部门之间共同完成的工作，但由于业务部门不懂技术，而信息管理部门不懂业务，导致认识不统一。业务部门往往把数据共享看作是信息管理部门应该解决的技术问题，但实际上数据共享主要是业务部门应该解决的业务问题。

（4）决策支持难实现

一般而言，决策支持需要有数据仓库的支持，而数据仓库所需要的软硬件环境又远远高于共享数据库，而且建设周期长，协调部门多。而直接在共享库中实现决策支持功能，会导致业务复杂，增加数据共享难度，不利于决策支持业务的独立性。

3.企业应用集成及其启示

企业应用集成EAI（Enterprise Application Integration），一般是指将企业内部多个不同数据源和相互分离的应用系统进行协同自动化处理的解决方案，其功能主要是协调企业现有和将来的应用程序、数据及员工与合作伙伴之间的互动[5]。EAI最初是为了解决企业内部多个新系统与旧系统的集成问题，一般采用星型集成架构，通过分布式对象中间件技术来实现信息集成。由于传统的EAI技术局限于数据和信息层面的集成，难以实现企业业务流程的自动处理、管理和监控，因此，有学者[5]提出了基于业务流程整合的第二代EAI技术。第二代EAI技术采用Web Service技术，通过对企业业务流程的全面分析管理，满足企业与客户、合作伙伴之间的业务需求，实现端到端的业务流程，顺畅企业内外的数据流、信息流和业务流。

目前的高校数据共享平台建设侧重于数据层面，相当于第一代EAI，所遇问题也与之相似。因此第二代EAI对数字校园建设中的数据共享平台建设具有良好的借鉴作用。高校数据共享平台应从业务流程的角度，通过建立高校数据共享业务，强调业务主体责任，解决目前高校数据共享平台建设中存在的问题。

二、高校数据共享业务流程分析

1.高校数据共享业务结构

业务是指管理中必要且逻辑上相关的、为了完成某种管理功能的一系列相关的活动。业务流程是指为完成某一目标或任务而进行的一系列逻辑相关的跨越时间和空间的业务活动的有序集合[6]。一项完整的业务流程要涉及到多个部门和多项数据。对于数据共享业务流程，业务人员、系统开发人员、信息管理人员有着不同的理解。业务人员理解的业务流程是部门间的业务数据传递，是把本部门的一部分可以共享的数据以各种形式传递给其他部门，同时本部门接收其他部门提供的共享数据。系统开发人员理解的是数据处理过程以及两个业务信息系统之间共享数据的导入与导出。信息管理人员理解的是数据库间共享数据的推送或拉取。因此，数据共享业务其实是一种分层结构，如图1所示。

由图1可以看出，高校数据共享流程在业务层表现为业务部门之间以表格文件为载体传输数据。在信息层，表现为数据共享通过双方业务信息系统实现数据的输入、编码、以表格为载体的数据共享、数据解码、数据使用的过程。在数据层，则表现为业务数据库间的数据集成，这是传统意义上的数据共享流程，只需要明确数据源和目标数据库，即可实现对数据的集成。通过分析共享数据业务结构，有利于从各个角度去设计具体的共享流程，明确各方责任。

2.高校数据共享业务流程

现有高校数据共享的相关文献[1-4]中对于数据共享的实现大多局限于数据集成过程，以数据源开始，以目标数据库结束，这样集成的结果把数据共享业务局限于数据管理部门内部，导致数据共享整体业务不流畅，业务责任主体不清晰等问题。而从业务流程角度来看，数据共享业务应该从业务实际需求出发，通过供需双方的交流，实现数据共享。数据共享业务流程建立的步骤可以作如图2所示设计。

第一步：业务部门双方确认数据共享业务流程。在业务流程确定中，需要业务部门双方就共享数据的方式进行沟通，形成共享表格，并能在初次共享时提供确认的全部数据，使共享数据能够显性化，使双方对共享数据有直观而清晰的理解。

第二步：业务部门各自确认信息流。一旦数据共享业务建立后，双方应对数据共享信息流进行确认，确认双方信息系统中是否都具有产生相关数据的功能及数据表。

第三步：信息管理部门提供数据共享技术支持。信息管理部门根据业务部门的数据共享业务流程，在信息流确认的基础上，进行数据流的设计和实施。

三、基于业务流程的高校数据共享平台建设模型设计

1.高校数据共享平台建设模型

高校数据共享业务流程涉及到业务部门、信息管理部门以及系统开发人员，因此设计数据共享平台需要考虑到不同层次的需求，由上及下，逐步确定业务流程中数据共享的业务细节和技术需求。高校数据共享层次可以分为业务层、信息层、数据层，三层之间相互流通，层层对应，信息层是业务层的映射，数据层是信息层的映射。数据共享平台具体建设模型如图3所示。

该模型把高校数据共享平台建设分为三个层次：业务层、信息层、数据层。每一层对应不同的流程结构，反映不同层次人员的工作视角。

（1）业务层

业务层主要包括业务部门、信息管理部门、决策部门及其相互间的业务流。业务层主要任务是实现业务流程的设计，明确数据共享和决策支持的主体责任。

业务部门是高校管理的具体业务承担者，在日常的工作中相互之间存在各种形式的业务往来，如工作协调和信息共享，而这种业务往来在信息环境下仍然存在。依托数据共享平台进行数据共享，只是改变了业务往来的形式，但并未改变其业务内容。信息管理部门通过共享数据库来管理全校共享数据资源。信息管理部门对数据共享行为进行业务化，使之成为自身的业务范畴，从而为进一步开发共享数据管理系统，以可视化的形式管理共享数据奠定基础。决策部门是数据仓库的直接使用部门和规划部门，决策部门提供数据仓库设计所需要的报表格式，并对数据来源做出安排，决定数据仓库服务的范围，并通过决策支持系统实现界面化操作和管理。业务流则是指业务流程中业务信息的传递，即两部门在实际工作中，不依赖于信息系统而相互共享数据的方式。例如在人事系统与房产系统的人事数据共享中，资产部门与人事部门应该首先具有共享数据的业务流，有专人负责，有数据的载体。在业务流中，数据载体可以是电子表格、纸质材料、甚至是口头表述。

（2）信息层

信息层包括业务系统、共享数据管理系统、决策支持系统及其相互间的信息流。信息层主要任务是实现信息系统对数据共享业务流程的支持，在业务管理系统中具有明确的功能模块，并建设共享数据管理系统和决策支持系统。

业务系统实现业务数据的处理，提供需要共享的数据格式，同时接收其他业务系统提供的共享数据。共享数据管理系统实现对共享数据的管理，提供可视化的手段和监督。决策支持系统在数据仓库的支持下，完成决策模型设计、决策数据分析、决策信息展现。决策支持系统是对数据仓库的可视化展现，并能够支持以不同的角度审视数据，以支持决策。信息流是指信息的传播与流动，是业务流程在信息系统中的实现，并将业务流程以功能形式呈现出来。在具体表现上，信息流表现为能产生共享数据列表的功能。例如在人事系统中，能够将人员数据导出为EXCEL文件的功能，在其数据层有相应的视图或表。

（3）数据层

数据层是数据共享平台建设的核心，包括三个基本部分：共享数据库、数据集成工具集、数据仓库。数据层的主要任务是建设共享数据库、数据仓库，选择适当集成工具，实现数据集成。

共享数据库用于存储基础性数据，如人事、学生信息。这些数据的需求关系是1对多关系，一般由一个部门提供，多个部门使用，因此必须按照信息标准存放于共享数据库。数据仓库用于存储按决策需求而专门设计的决策类数据，例如年度教工统计数据、学生统计数据、办学条件等，这些数据主要服务于决策支持。数据集成工具集则为业务数据库、共享数据库、数据仓库三者之间的数据抽取、转换、装载提供技术支持。

2.关键业务系统

（1）共享数据管理系统

目前共享数据管理中一个很大的问题是数据的可视化不足，只有数据库管理人员在数据库中查看，而不能在界面化的操作方式下为业务人员所见。这样就导致共享数据的黑盒化，业务人员看不到共享数据，就不能理解业务数据如何被共享的一个过程，从而难以做到对数据的责任。而共享数据管理系统可以将共享数据以界面化的方式展现出来，而且可以通过授权，使业务人员能够看到共享数据的情况，了解数据共享的进度，从而增强数据共享的信心和责任感。

（2）决策支持系统

高校决策支持系统相关研究很多，但由于业务和技术两个方面的原因，一直难以有效应用。在业务方面，决策支持需要管理人员认可，而目前的决策技术过于抽象化，直观性不足，缺少知识库的支持。在技术上，主要是决策系统所依赖的技术，如数据挖掘、OLAP等，在应用于具体的业务时千差万别，难以有效地对建模结果进行有效解释，不利于管理人员理解。而决策支持系统建设就是要综合数据仓库、数据挖掘和知识管理的理论和方法，使用决策展示更明确、指标更明晰、结果更易懂、效果更明显。

3.模型特点

（1）突出业务部门的主体地位

该模型明确业务责任，确定业务活动流程，将不可见的数据共享活动外化为可见的数据共享业务，更能为业务人员所接受和理解，有利于推进数据共享业务建立，从而解决了业务流程不畅、责任主体不清的问题。

（2）共享数据库与数据仓库分离

该模型将共享数据库与数据仓库分离，有利于厘清信息管理部门与决策部门的责任，而且有利于实现各自的功能。共享数据库解决“信息孤岛”的问题，而数据仓库解决决策支持的问题。决策部门负责对学校全局数据的分析处理根据决策需求制定，推进数据仓库技术在高校智慧校园中的应用。信息管理部门承担共享数据库的管理和建设。这样就能解决共享管理困难、决策支持难实现的问题。

（3）构建数据集成工具集

数据集成工具集为不同的数据集成需求提供了多种选择手段。数据集成是业务流程的体现，是数据共享平台设计的核心。数据集成工具集随着技术的进步，需求的变化，业务流程的改变，应能够不断地改进和扩充。

四、结束语

高校数据共享平台，首要目的是实现数据共享，其次实现决策支持，核心是数据集成。数据集成是数据共享业务流程的集中体现。数据共享流程受到需求部门对源数据的理解程度的影响，从业务的角度设计数据集成非常重要。数据共享业务的建立需要明确的责任分工和清晰的业务流程。总之，基于业务流程的高校数据共享平台建设模型，有利于数据共享过程业务化，厘清部门责任，增强数据共享过程的可管理性，夯实决策支持的基础。

参考文献：

[1]俞春，袁芳，刘乃嘉，王茜.高校数据共享与交换技术的应用研究[J].实验技术与管理，2012，29（11）：109-112.

[2]周学理.高校数字化校园共享数据库中心的设计与实现[D].辽宁：东北大学，2008.

[3]丁智君.高校数据化校园的数据中心平台建设[D].上海：复旦大学，2009.

[4]于宁，王行言，罗念龙.高校教学决策支持系统数据仓库的研究与实现[J].计算机工程与设计，2006，27（20）：3853-3857.

[5]黄向平，吴春旭，张兮.基于业务流程整合的企业应用集成[J].计算机系统应用，2006，15（7）：45-48.

[6]史俊.业务流程的共性与可变性研究[D].湖北：华中科技大学，2007.

[7]谢小轩，张浩，夏敬华，王坚，李琦.企业应用集成综述[J].计算机工程与应用，2002，38（22）：1-5.

[8]（美）William A. Ruh， Francis X. Maginnis， William J. Brown著.张博，杨丽君等译.企业应用集成[M].北京：机械工业出版社，2003.

数据库设计流程篇4

1)检索速度慢、效率低因为图书馆的藏书种类多、数量多，将藏书准确地分门别类，快速检索，手工进行非常困难往往是终于查到了二伟的信息，馆中没有此书或已被别人借走。图书馆的规模越大，这个问题越突出。2)借书、还书工作量大借书、还书频率越大，说明图书馆的作用越大，然而随之而来的大量的借书、还书登记、实存图书的更新以及借出图书超期、遗失等的处理，其工作量之大，往往是人工操作所难以胜任的。而且经常会出现这样那样的差错。3)图书统计工作难、藏书更新不能及时完成。图书馆的图书应根据科学技术的发展和教学工作的需要及时添加和更新，然而由于藏书数量及图书种类越来越多，加上自然损耗，人为破坏，使图书的统计工作难以及时完成，藏书的更新也就很难有针对性地进行，藏书的知识结构得不到良好地控制。我校也是一所发展中的高校，近儿年的发展速度很快，图书馆的规模和藏书数量也不断的扩大，为了解决海量图书的管理问题，改变传统的管理方式也是迫在眉睫了。图书馆借书流程

1、图书管理员1录入图书清单并保存图书信息

2、读者根据自己列出的带借书清单，查看图书借阅状态，并得到图书索引表

3、图书管理员2扫描一卡通查看读者信息，得到读者已借图书清单，并审核借书权限

若是有效权限单，则进行接触操作并更新读者与图书信息若是无效权限单，则返给读者已下是业务流程图图书管理员1图书清单录入图书信息图书信息库读者信息库图书管理员1图书管理员2读者待借图书清单查看图书借阅状态图书索引表扫描一卡通并查看读者信息读者借阅信息单读者

图书馆管理系统数据流程图及数据字典一．图书采编系统流程图

P1_11采编人员图书采编信息（D01）图书采编信息采编管理（D01）图书表图书采编系统流程图

数据流编号：D01 数据流名称：图书采编信息简述：图书采编信息

数据流来源：图书购买后，由图书馆采编人员整理后，输入计算机

数据流去向：采编管理模块。图书采编信息将采编数据存入数据库（图书表）数据流组成：图书编码，图书类别，书名，作者，出版社，出版日期，单价，购买数量

数据流量：300本/日高峰流量：800本/日

二．图书管理系统零层数据流程图

P0读者管理信息图书馆管理员图书采编信息书目查询图书借阅图书馆管理信息系统图书借阅预定读者库存图书查询借阅情况统计图书管理系统零层数据流程图

三．图书借阅系统数据流程图

P2_14图书归还处理填写归还记录（D16）读者库还书记录（D15）归还修改在库数量（D17）读者库图书馆管理员图书借阅（D02）P2_11检查读者身份有效P2_13填写供阅记录（D03）借阅库填写借阅库、修改图书库借阅修改在库（D04）图书库读者库图书借阅系统数据流程图

数据流编号：D02 数据流名称：借书借阅简述：借书证数据流来源：用户将借书证交给借书员，借书员经过审查后将相关信息输入计算机

数据流去向：P2_11检查读者身份

数据流组成：借阅日期+书名+读者账号+读者姓名+借阅数量等数据流量：800个/日高峰流量：3000个/日

数据流编号：D03 数据流名称：填写借阅记录简述：填入借阅表的记录

数据流来源：P2_13检查合格的借阅图书信息录入到借阅库中数据流去向：借阅库

数据流组成：借阅号+借阅日期+书名+图书编码+读者姓名+读者账号+还书日期+借阅数量+状态等

数据流编号：D04 数据流名称：借阅修改在库简述：修改的借阅记录

数据流来源：P2_13将借阅的图书的记录录入到图书库数据流去向：图书库

数据流组成：借阅号+借阅日期+书名+图书编码+读者姓名+读者账号+还书日期+借阅数量+状态等

数据流编号：D15 数据流名称：还书记录

简述：所还图书进行入库记录数据流来源：图书馆管理板块

数据流去向：图书馆归还处理模块

数据流组成：图书编号+图书名+借阅证号等

数据流编号：D16 数据流名称：填写归还记录

简述：管理员填写归还图书馆的图书记录数据流来源：图书馆归还处理模块数据流去向：读者库模块

数据流组成：图书编号+图书名+管理员编号+日期等

数据流编号：D17 数据流名称：归还修改在库数量

简述：图书归还后该书在读者库的记录数据流来源：图书馆归还处理模块数据流去向：读者库模块

数据流组成：图书编号+图书名+管理员编号+日期等

四．图书维护系统数据流程图

P6_11读者库图书维护需求（D18）库存图书统计（D19）图书库图书维护借阅情况统计（D20）图书馆管理员借阅库读者情况统计（D21）图书维护系统数据流程图

数据流编号：D18 数据流名称：图书维护需求

简述：对目前读者库图书进行维护数据流来源：图书管理模块数据流去向：图书维护模块数据流组成：管理员编号+图书编号+图书名+条形码号+出版社+出版日期+入库日期+作者+单价+数量等

数据流编号：D19 数据流名称：库存图书统计

简述：对目前读者库内存书进行统计数据流来源：图书管理模块数据流去向：图书维护模块

数据流组成：图书编号+图书名+条形码号+出版社+出版日期+入库日期+作者+单价+数量等

数据流编号： D20 数据流名称：借阅情况统计

简述：对目前外借的、不在读者库的图书进行统计数据流来源：图书管理模块数据流去向：图书维护模块

数据流组成：图书编号+图书名+条形码号+出版社+出版日期+出库日期+作者+单价+数量+借阅证号等

数据流编号：D21 数据流名称：读者情况统计

简述：对借阅者进行统计数据流来源：图书管理模块数据流去向：图书维护模块

数据流组成：借阅证号+图书名+条形码号+出版社+出版日期+出库日期+作者+单价+数量+金额+借阅期限等

五．图书馆查询系统流程图

图书检索要求（D05）P3-11读者D05图书检索结果D06检索处理D06 图书库图书馆查询系统流程图

数据流编号：D05 数据流名称：图书检索要求

简述：读者要求求得图书检索信息数据流来源：读者输入的检索要求数据流去向：图书库以及检索处理系统数据流组成：图书名+图书编号等

数据流编号：D06 数据流名称：图书检索结果

简述：读者经过在检索系统终端输入检索信息后由检索系统返回的结果数据流来源：检索系统数据流去向：读者

数据流组成：图书名+图书编号+图书索引号+图书所在的书架编号等

六．读者管理系统数据流程图

借阅管理员读者登录信息（D22）读者查询（D24）读者查询结果（D25）P7_11读者登录检查读者信息（D23）读者表读者管理系统数据流程图

数据流编号：D22 数据流名称：读者登陆信息

简述：图书管理员对读者登陆信息进行检查数据流来源：图书管理模块数据流去向：检查读者登陆模块

数据流组成：管理员编号+借阅证号等

数据流编号：D23 数据流名称：读者信息

简述：图书管理员对读者登陆信息进行记录数据流来源：检查读者登陆模块数据流去向：读者表数据流组成：借阅证号等

数据流编号：D24 数据流名称：读者查询

简述：借阅管理员输入的读者登录信息数据流来源：借阅管理员

数据流去向：读者登录检查系统数据流组成：读者姓名+读者编号等

数据流编号：D25 数据流名称：读者查询结果

简述：登录系统在检查读者输入的读者信息后返回个借阅管理员的结果数据流来源：登录系统数据流去向：借阅管理员

数据流组成：读者姓名+编号等

七．电子读物系统数据流程图

P8_11电子读物查询要求（D13）电子读物查询结果（D14）读者电子读物处理检索信息电子读物库检索结果读者表电子读物系统数据流程图

数据流编号：D13 数据流名称：电子读物查询要求简述：读者需要查询的图书信息数据流来源：读者

数据流去向：电子读物处理模块

数据流组成：图书编号+图书名+出版社等数据流编号：D14 数据流名称：电子读物查询结果

简述：电子读物处理模块对读者输入的反馈数据流来源：电子读物处理模块数据流去向：读者

数据流组成：图书内容+图书所在网站超连接等

八．图书馆管理系统数据流程图

驾校信息管理系统数据流程图篇5

学员信息0驾校学员信息管理系统教练信息学员查询评价管理管理人员教练查询申报审核、统计分析

第二层数据库

1学员信息基本信息管理学员信息2教练信息教练信息车辆信息约车学员报名考试教练管理人员考试、训练管理评价信息3提交评价评价处理审核第三层数据库

学员信息学员信息1.1学员信息管理管理学员信息1.2学员教练教练信息管理教练信息管理管理人员车辆信息报修/报废申请1.3教练信息管理车辆信息车辆信息管理

训练安排学车预约2.1培训管理预约表学员学员信息教练信息管理人员教练考试安排2.2考试管理报名表报名考试考试信息提交评价3.1提交评价处理3.2待审核信息评价信息审核学员教练信息管理人员撤销评价3.3评价信息撤销评价处理评价信息

第四层数据库

学员学员信息表1.1.1添加学员信息1.1.4教练查询处理管理人员信息修改表1.1.2修改学员信息学员信息1.1.3删除学员信息个人信息1.2.1添加教练信息教练信息教练1.2.21.2.4查询处理管理人员信息变更表修改教练信息教练信息离职表1.2.3删除教练信息 1.3.5报修车辆信息表1.3.1添加车辆信息教练信息报修单报修单1.3.2修改车辆信息车辆信息教练管理人员车辆信息报废单1.3.3删除车辆信息报废单1.3.6申请报废1.3.4查询处理

教练信息学员信息2.1.1预约申请学车安排训练安排2.1.2预约成功2.1.3预约失败2.1.8同意更换教练2.1.6撤销教练申请撤销预约请求2.1.4撤销预约申请预约信息预约表教练信息2.1.7不同意更换教练2.1.5更换教练申请预约请求预约信息培训信息管理员申请表学员教练同意不同意

数据库设计流程篇6

顾客信息查询药品信息查询输入查询信息信息查询供应商信息查询库存药品查询信息查询程序显示信息营业状况统计入库记录出库记录药品入库管理员库存管理药品出库入库管理程序更新库存出库管理程序药品信息输入信息基础信息管理顾客信息信息处理程序更新数据库供货商信息药品销售日常业务销售退货销售员顾客信息信息查询药品信息药品销售程序药品结账程序确认出售药品出库记录储存销售记录药品退货程序确认退货药品入库记录储存销售记录更新数据库信息查询程序显示信息输入查询信息图一：拟开发系统流程图

药品存库存记录交给顾客发票顾客购买药品信息前台人员查找填写发票记录药品销售更新库存销售额记录待退药品发票信息销售员核实退货填写退货信息药品退货记录更新库存信息顾客、药品信息记录表顾客、药品信息查询条件前台人员查找搜寻待查信息信息显示管理员查找供应商查询供应商、顾客、药品信息记录表营业状况查询管理员查找搜寻待查信息信息显示库存药品查询供应商、顾客、药品信息记录表进货的药品管理员管理入库药品管理员记录药品信息更新库存记录顾客退货的药品退货药品过期药品管理员管理出库药品管理员记录药品出库信息销售额记账更新的出库存记录已售药品供应商、顾客、药品信息记录表待更新的信息管理员查找处理待更新的信息新供应商、顾客、药品信息记录表图二：手工系统流程图 D1用户信息表D2角色权限表1用户登录信息合法性检查2权限检查进入系统3处理事务

图三：药品信息管理系统顶层数据流图

重新登录反馈信息1.1用户名密码检查用户登录信息登录信息2.1权限检查D1用户信息表

用户

登录信息2.1角色获取信户用2.2权限获取进入系统D2角色权限表息

数据库设计流程篇7

1 数据库建设概况

1.1 目的和任务

第二轮矿产资源规划建库目的是全面查清矿产资源利用状况, 掌握真实的矿产基础数据, 并对调查成果实行信息化、网络化管理, 建立和完善矿产调查、矿产统计和登记制度, 实现矿产资源调查信息的社会化服务, 满足经济社会发展及国土资源管理信息“一张图”的需要。为实现高效、准确的动态国土资源管理工作奠定基础, 为用途管制、统筹规划全县矿产资源勘查与开发活动, 合理调控矿产资源开发总量, 优化矿产资源开发利用布局及其结构, 更好地节约和综合利用矿产资源, 加强矿山环境保护与恢复治理, 为进一步加强矿产资源管理和宏观调控提供依据。

第二轮矿产资源规划建库任务是建立第二轮矿产资源规划数据集, 包括基础地理信息、基础地质信息、矿产资源规划专题信息、注记信息和其他信息等内容, 集图形、属性、表格和文档资料等数据为一体的、互联共享的资源调查数据库。

1.2 数据库建设依据

GB/T 2260《中华人民共和国行政区划代码》;

GB/T 17798-1999《地球空间数据交换格式》;

GB/T 13923-92《国土基础信息数据分类与代码》;

GB/T 17766-1999《固体矿产资源/储量分类》;

GB/T 13989-92《国家基本比例尺地形图分幅和编号》;

GB/T 9649-88《地质矿产术语分类代码》;

DZ/T 0197-1997《数字化地质图图层及属性文件格式》;

GX199900X-200X《国土资源信息高层分类编码及数据文件命》;

国土资发[2000]133号《矿产资源储量规模划分标准》;

国土资发[2004]208号《关于调整部分矿种矿山生产建设规模标准的通知》、国土资发[2005]119号《关于开展省级矿山环境保护与治理规划编制工作的通知》;

国土资厅发[2007]38号《第二轮省级矿产资源总体规划编制要点》;

国土资发[2007]230号《省级矿产资源总体规划成果要求》;

国土资厅发[2007]139号《省级矿产资源总体规划编制技术指南》;

DZ/T0226-2010《矿产资源规划数据库标准》。

2 数据库总体设计

2.1 数据库建设的主要步骤

第一阶段为建库准备:主要包括建库方案制定、人员准备、数据源准备、软硬件准备、管理制度建立等;

第二阶段为数据采集与处理:主要包括基础地理、地质信息和专题信息等各要素的采集、编辑、处理和检查等;

第三阶段为数据入库:主要包括变化数据更新、数据格式转换、属性处理。

第四阶段为数据库检查:主要包括数据分层及表结构、数据拓扑关系、属性完整和正确、图层要素的完整性、数据库逻辑结构等;

第五阶段为成果汇交:主要包括数据成果、文字成果、图件成果和表格成果的汇交。

2.2 数据库逻辑结构

数据库逻辑结构见图1。

2.3 数据库内容

数据库内容和分层的依据是《矿产资源规划数据库标准》, 数据库主要内容如下: (1) 基础地理信息数据:包括定位基础、行政区、行政界线、地貌等。 (2) 基础地质信息数据:包括地层、岩体、主要构造和重要成矿区带、主要成矿远景区等。 (3) 矿产资源规划专题信息数据:包括矿产资源现状、开发利用状况、调查评价与勘查规划、开发与保护规划、生态环境规划、规划附表、规划文档等。 (4) 注记信息数据:包括地名注记、水系注记、交通注记、地形注记、地质要素注记、规划要素注记、其他注记等。 (5) 其它信息数据:包括图面整饰、其他数据。 (6) 元数据:包括矿产规划数据库元数据。

2.4 数据库技术指标

2.4.1数学基础。 (1) 坐标系:采用”1980西安坐标系“; (2) 高程基准:采用”1985国家高程基准“;2.4.2矿产规划利用分类。矿产规划利用分类采用《国土基础信息数据分类与代码》 (GB/T 13923-92) 和《固体矿产资源/储量分类》 (GB/T 17766-1999) 进行分类并归类合并。

3 软件和硬件的准备工作

3.1 软件准备 (见表1)

3.2 硬件准备

硬件平台包括网络设备 (如服务器、机柜、交换机、网络集线器、调制解调器、光纤线路、网络线路、UPS电源等) 、计算机、数据输入输出设备 (如数字化仪、扫描仪、绘图仪、打印机等) 、数据储存设备 (如磁盘、光盘) 等。

4 数据采集与处理

严格按照《矿产资源规划数据库标准》进行数据挑选和生成, 建立分层文件并标准化命名。

4.1 基础地理

采用国家测绘局发布的1∶50万、1∶25万、1∶5万等空间数据作为基础, 根据规划需要进行补充和删减。

4.2 基础地质

可依据中国地质调查局制作的1∶50万、1∶20万等地质图数据库进行适当简化。对1:10000外业标绘调查底图进行扫描数字化并矢量化。使用软件的专用模块分别对线状要素、点状要素和注记进行分层矢量化采集, 同时录入属性数据。

4.3 规划专题图层

可由图形扫描矢量化进行输入, 如果收集到有拐点坐标的规划资料, 则必须使用GIS软件中的空间多边形及点位生成功能自动生成空间多边形及点位的矢量数据。地层、岩体、断层等基础地质图层可直接引用相应比例尺的地质图数据库数据, 字段内容根据《矿产资源规划数据库标准》严格要求。为体现不同区域在客观现实上的独立完整性, 本次建库工作保留空间数据中面状要素的重叠, 同时在数据检查过程中, 对此类图层的拓扑检查可忽略“多边形要素相互不能重叠”原则。其它类似图层, 根据情况可采用此处理方式, 但必须在数据检查表中列出。补测新增地物数据, 经在AUTOCAD中准确数据定位后, 经数据转换导入, 经检查正确合格后, 形成内业建库人员新增地物补测的数据采集资料。

5 质量管理与检查

为了保证数据库成果质量, 严格按照《测绘作业控制程序对作业》和《矿产资源规划数据库标准》执行, 建立起作业人员自检、互检等质量检查的检查制度。把全面质量管理贯穿始终, 建立起数据预处理、数据录入、数据处理、建库等全过程保障体系。当修改完成后的数据以区为单位的基础入库数据进行100%的检查, 主要内容: (1) 要素位置的精度检查:线型、符号采集的位置必须正确, 不跑线 (图上0.1mm以内) 。按中心点、中心线数字化的要素, 其位置必须准确。共边元素必须严格捕捉结点。不同层的公共边必须完全重合。 (2) 属性检查:按属性表规定对采集地类及权属的属性进行检查, 看属性值是否漏赋或赋值错误, 检查各项要素所赋的属性项的正确性以及编码位数的正确性。所有属性数据必须通过系统提供的工具逐个进行检查。 (3) 数据完整性检查:数据完整性主要检查分层的完整性、实体类型的完整、属性数据的完整性及注记的完整性, 各要素的采集不得有缺漏、错误和重复采集。检查面状地类是否闭合, 线状地类及权属界线是否连续, 属性数据是否完整, 注记是否完整等。 (4) 逻辑一致性检查:检查相关属性值是否矛盾; (5) 要素关系检查:确保重要要素之间关系正确并忠实调绘原图, 层与层间不得出现整体平移, 权属界线与面状地类、宗地与权属界线、权属界线与权属界址点的连接关系是否正确, 应严格按照数据采集的技术要求处理各种地类关系。确保要素拓朴关系正确。

结束语

针对贵州省瓮安县没有自己的矿产规划数据库, 提出利用Mapgis建立矿产规划数据库, 并且取得了良好的效果。对其他地方建设的矿产规划数据库有一定的实用价值。只是将Mapgis数据转入Sheape文件的属性过程中存在数据丢失的现象, 这应在后续的研究中加以改进。

参考文献

[1]李铁钢, 高占普.市级国土资源管理部门“一张图”建设应注意的问题[J].国土资源, 2010 (3) , 49.

[2]刘臻, 任效颖.全国矿产资源规划信息数据库及管理系统构建[J].国土资源信息化, 2012 (2) , 39-43.

数据库设计流程篇8

关键字：数据构面；属性录入；建立拓扑关系；数据投影变换；数据格式转

城市和工程建设一般需要大比例尺地形图，其中比例尺为1：500和1：1000的地形图一般用平板仪、经纬仪或全站仪等测绘。大比例尺城市地形图数据是城市空间信息基础设施最重要的基础数据之一，是数字城市的重要组成部分。随着我国经济的发展和城市建设的加快，大比例尺城市地形图在城市规划和管理中的作用越来越重要。因此，针对数据的特点和应用需求，如何高效快速地组织与管理这些数据是一个值得关注与研究的问题。

大比例尺城市地形图对客观世界的抽象概括程度低，表达细化，结构零散，数据量大，一般以图幅为单位进行管理，由于数据获取、数据处理等方面的原因，跨图幅的空间目标往往被分割成不同子目标。

大比例尺地图数据处理的关键问题，在上世纪70年代以来历经了两个发展阶段：文件系统阶段和数据库系统阶段。大比例尺地形数据管理只能使用在文件系统水平上。有序列文件、直接存取文件、关键字存取文件等几个文件类型。系统文件有着较多的弱点，只有几个应用程序存在于数据文件中，其中管理功能存在弱点，空间浪费较多，同时文件也不容易扩充，修改起来较非时间。计算机硬件提供了大容量的直接存取设备磁盘，随着计算机软件系统提供了数据库，与此同时大比例尺地形的管理数据也跟着进入了数据库阶段。

复杂的模型数据、数据构造的组织存储和管理是大比例尺地形数据管理的基本管理特点。数据库中的各种数据只能按照规定的数据进行组织、存储、管理，只有这样才能确保共享数据的完整性得到合理的发挥，用户才能够直接与数据打交道。

大比例尺地形数据是管理数据类型的主要方式，其中空间位置数据、专题属性数据是是各种制图要素的两大类型。空间位置数据可以归纳为点、线、面。线是基本，点是线的坐标点，面是由线围成的。三者之间可以概括为弧段节点模型。二维表中点的特征主要包括点序号和用户识别号，以及它们所对应的专题属性数据项；二维表中线的特征主要包括线序号、用户识别号、起始节点号和终止节点号。专题属性对应的数据项是线的长度；面的特征是二维表中的主要特征，包括多边形序号、用户识别号、周长、面积以及各自对应的专题属性数据项。

建立拓扑关系、数据投影变换、数据格式转换等工序，整理地形图的步骤大体有以下几步：

1、首先地图数据库、图形特征层、分区和命名、文件索引结构是确定地图数据库的要素层，其次要建立控制点文件，数据库的基本框架形成是必不可少的。

2、描述數据的信息、图形特征需要一个与之相对应的数据字典，编写数据字典规定出了图形特征层的详细属性。

3、在确定的系统规模和数据量估算基础上必须依靠机助地图制图系统的支持，地图数据库才能合理地得以利用。，系统硬件和配套软件才能合理的建立和实施。

4、建库范围和使用目标的确立、查询的方式以及数据库大致规模的完成期限。

5、广泛的资料源调查，编制目标资料的评价表，确定基本地图，估算数据量，最后登记造册。

6、净化数字文件，按照确定的数据库框架插入规定的位置。

7、资料编辑加工。

8、联机编辑和脱机编辑两种方式反复检查同时采用、修改，产生净化的数字文件，从而实现图形数字的转换，做好插入数据库前的准备工作。

9、定位查询、定性查询和逻辑查询是地图数据库提供的各种查询方式和显示方式，要及时地更新数据库，以确保数据库中数据的时效性和可靠性。

10、对数据库进行实际测量和评价还应该返回核对原始资料，再重新组织入库，进而确保数据库的数据质量。

如何对数据进行预处理？

（1）删除伪结点：删除图面上伪结点；

（2）删除复合线多余点：删除图面中复合线上的多余点；

（3）删除重复实体：删除完全重复的实体。

构面数据需要对要素进行构面。要素构面核查通过后，表达为多边形的基本类型。以下是cass软件的构面功能介绍：

①手动跟踪：构面将连续不断的复合线连接起来构成一个面，像花坛、道路边线、房屋的边线等等这些断开的线，可以经过手动构面，将它们围成的领域构造出来；

②搜索封闭：自主搜索某一图层上重复围成的领域，并自动生成房界面。

③要素构面完成后，运行“封闭检查”功能。该功能的面状地物封闭检查是入库前所必须进行的步骤。

大比例尺数据管理需要建立拓扑关系，建立拓扑关系的具体方法如下：

①数据转入arcgis系统由于后期将对cass软件成果数据新建拓扑关系和检查拓扑关系，因此建立arcgis geodatabase数据库，将cass软件成果数据转入至arcgis geodatabase数据库。

②应用cass软件的shp文件接口输出shp格式，将cass软件的成果数据转换为shp格式的点、线、面简单要素类型数据，再将shp格式数据转入arcgis geodatabase数据库中。

③cass软件成果数据转入arcgis数据库后，按《城市地理空间框架数据标准（cjj 103-2004）》要素类型定义重组分类。

④由于arcgis数据库对数据有较高的要求，如图形实体放错图层、代码值错误、面状地物不封闭即有悬挂点、伪节点等错误均不能转入arcgis系统数据库。因此，还需要进行arcgis拓扑关系检查。

nlc202309012351

拓扑关系检查拓扑是 gis 在数据管理和完整性方面的关键要求。通常，拓扑数据模型通过将空间对象（点、线和面要素）表示为拓扑原始数据（节点、面和边）的基础图表来管理空间关系。这些原始数据（连同它们彼此之间及其所表示的要素边界之间的关系）通过在拓扑元素的平面图表中表示要素几何进行定义。拓扑用于确保空间关系的数据质量并帮助进行数据编译。

创建拓扑规则后，进行拓扑检查，在容限内进行修改调整数据。利用ArcCatalog中所提供的规则，建立好拓扑关系后，就可以在ArcCatalog软件中打开拓扑规则，根据提示进行修改错误。ArcCatalog软件拓扑检查功能有对线拓扑（删除重复线、相交线断点等）、线拓扑生成面、共享编辑、拓扑错误显示、创建合理的拓扑规则，进行拓扑错误的重新验证，刷新错误记录。

数据格式和投影转换

数据格式转换由于采用Geodatabase作为后期地理信息数据处理的平台，因此最終成果的数据格式转换非常方便，将Geodatabase数据库中的要素数据按feature Geodatabase 或 feature class导出为shp格式文件，即完成最终成果数据的格式转化。

导致坐标缩放倍数的原因可能是投影参数中单位的变换，举例来说如果当前投影参数为毫米，则目标投影参数为米，那么坐标会自动缩小5000倍，如果目标投影参数比例尺为1：5000，会是相同的效果。如果地理坐标不是直接转成，也可以进行“输入编辑----整图变换----其它”的功能。

如果在MapGIS的主界面选择菜单项，进入文件界面转换，再进行“图形处理”→“文件转换”，然后在主菜单中选择“文件”，这时候就可以选择要装入的文件类型〔点数据、线数据、面数据），最后在装入完文件之后，选择菜单“输出”，并根据所装入的文件类型提示选择输出点的数据，线的数据或者面的数据进行E00格式。

转换某种坐标信息数据源向另一坐标系统进行的投影方法，并进行修改源数据中的x值和y值。具有空间参考价值的创构时，对空间的参考定义做了详细的分析。那么该数据集的地理坐标系统或投影坐标系统便没有了坐标系统的详细地理数据，在生产应用的过程中就是没有一点可利用的意义了，只不过对数据格式转换和转库过程中可能会造成坐标系统信息的丢失，也可能会在创建数据库的内容时忽略了坐标系统的定义。故而需要对没有坐标系统的信息数据集进行坐标系统定义，在不改变当前数据集中x值 y值的特征的情况下，对该数据集进行指定坐标系统信息。

参考文献：

[1] 《城市地理空间框架数据标准（cjj 103-2004）》

[2]吴秀芹、张洪岩、张正祥、李瑞改、董贵华.arcgis9地理信息系统应用与实践.北京.清华大学出版社.2007

[3]潘正风、数字测图原理与方法[M].武汉大学出版社.2004

[4]龚健雅。地理信息系统基础[M].北京：科学出版社.2001

【数据库设计流程】推荐阅读：