地质勘查规划数据库建设规范
地质勘查规划数据库建设规范（Regulation For Establishing Geological Perambulation Programming Database）
国土资源部信息中心
目次
前言 ................................................................................ II 引言 ............................................................................... III
1 范围 (1)
2 规范性引用文件 (1)
3 术语和定义 (1)
4 基本要求 (2)
5 数据源 (3)
6 数据库建设 (3)
7 数据库成果内容及要求 (7)
8 数据质量控制与评价 (12)
9 检查验收及评价 (14)
附录1 （规范性附录）图式图例 (16)
附录2 （规范性附录）地质勘查规划数据库提交成果清单 (23)
附录3 （规范性附录）国土资源部地质勘查规划元数据信息采集表 (24)
附录4 （资料性附录）地质勘查规划数据库成果质量检查记录表 (32)
前言
为指导和规范各省按照《地质勘查规划数据库标准》进行数据库建设，特编写本规范。本规范对数据采集、整理、建库及检查等过程做了规范性描述，并明确提交成果的要求，是地质勘查规划数据库建设的指导性文件。
本标准由国土资源部提出并归口。
本标准起草单位：略。
本标准主要起草人：略。
本标准由国土资源部负责解释。
引言
为指导全国省级地质勘查规划数据库建设，规范建库的内容、程序、方法及成果要求，保证数据库质量，依据《中华人民共和国矿产资源法》及其实施细则以及规划管理的有关法律法规、技术标准，以《地质勘查规划成果技术要求》为基础，结合《地质勘查规划数据库标准》（征求意见稿），参照相关领域信息系统建设规范及信息技术要求，制定本规范。
本规范重点从建库的数据采集整理、格式转换到成果检查验收阶段的工作流程进行规范，明确提交最终成果的内容形式和检查验收的指标体系、方法程序，详细规定了元数据的填写形式。全国省级地质勘查规划数据库建设按本规范执行，地（市）级地质勘查规划数据库可参照本规范执行。
地方各部门和各生产单位，必要时可根据实际情况，对本规范未尽事宜制定补充规定，但不能与本规范相抵触，补充规定需报国土资源部批准后实施。
地质勘查规划数据库建设规范
1 范围
本规范适用于全国范围内省级地质勘查规划数据库的建设工作。地（市）级地质勘查规划数据库可参照本规范执行。
2 规范性引用文件
下列规范所包含的内容，通过本规范的引用而构成本规范的组成部分。凡注明日期的引用文件，其以后被修订的新版本及修改单（不包括勘误的内容）中的内容均不适用本规范，然而，鼓励根据本规范达成协议的各方研究是否可使用这些文件的最新版本。凡未注明日期的引用文件，其最新版本适用于本规范。
GB/T 13989—92 国家基本比例尺地形图分幅和编号
（GB/T14512—93）《1:1000000 地形图编绘规范及图式》
（GB/T17695—1999）《地图用公共信息图形符号通用符号》
（GB958-1999）《区域地质图图例》
（DZ/T0519—95）《1:500000 1:1000000省（市、区）地质图地理底图编绘规范》等标准TD/T 1016 国土资源信息核心元数据库标准
TD/T XXXX—200X 国土资源数据库标准及建设规范编制指南（送审稿）
DD2006—07 地质数据质量检查与评价（中国地质调查局地质调查技术标准）国土资源部矿产资源规划数据库建设指南（修订本）（以下简称《矿规指南》）国土资源部地质勘查规划数据库标准（征求意见稿）（以下简称《标准》）国土资源部省级地质勘查规划成果技术要求（2007年）（以下简称《技术要求》）国土资源部信息中心国土资源数据库整合技术要求（金土工程试行稿）
国土资源部信息中心国土资源基础数据库检查验收规范（试行）
3 术语和定义
本规范采用以下术语及定义。
3.1 实体 Entity
地质勘查规划所描述的一种真实现象或客观存在。
3.2 要素 Feature
真实世界现象的抽象。
3.3 类 Class
相似要素的集合。
3.4 属性 Attribute
一个实体或目标的数量或质量特征描述。
3.5 矢量数据 Vector Data
以坐标或坐标串表示的空间点、线、面等图形数据及与其相联系的有关属性数据的总称。
3.6 拓扑 Topology
对相连或相邻的点、线、面、体之间关系的科学阐述。特指那种在连续投影变换下保持不变的对象性质。
3.7 编码 Coding
将信息分类的结果用一种易于被计算机和人识别的符号体系表示出来的过程，是人们统一认识、统一观点、相互交换信息的一种技术手段。编码的直接产物是代码。
3.8 标识码 Identification Code
在要素分类的基础上,用以对某一类数据中某个实体进行唯一标识的代码。
3.9 空间数据结构 Spatial Data Structure
指空间数据在计算机内的组织和编码形式，它是一种适合于计算机存储、管理和处理空间数据的逻辑结构，是实体的空间排列和相互关系的抽象描述。
3.10 元数据 metadata
关于数据的数据，用于描述数据的内容、覆盖范围、质量、管理方式、数据的所有者、数据的提供方式等有关的信息。
3.11 质量评价 quality valuate
按照一定的规则和方法，对数据质量检查的结果进行评价并得出结论的过程。
4 基本要求
4.1 人员要求
配备一定数量具有相当管理水平、技术水平的人员，包括项目负责人、技术负责人、专业质量检查员、班组长、作业员以及数据库应用负责人，明确其分工职责，并在建库前进行专业基本知识及计算机知识的培训，制定建库技术方案和实施方案。
4.2 软、硬件要求
4.2.1 软件要求
本规范中数据库建设工作流程适用的GIS软件平台为MapGIS 6.5和ArcGIS9.0，或者两者的更高版本。
4.2.2 硬件要求
计算机：Pentium4 3G以上CPU， 512MB以上内存， 4GB以上剩余硬盘空间，显存128M 以上显卡。
4.3 管理制度要求
在建库过程中，数据库建设单位要归纳记载各种问题及其处理情况，填写作业情况记载表。实现自检、互检、抽检三级质量监控制度，以保证数据库建设成果的质量。
4.4 数学基础要求
4.4.1 MapGis数据需要提供以下二种坐标系数据
（1）平面直角坐标系：6度分带、高斯-克吕格投影、北京54椭球参数、1∶25或1∶50万比例尺。
（2）将平面直角坐标系投影变换为大地经纬度坐标系：以度为单位。
4.4.2 ArcGis数据需要提供
以度为单位的大地经纬度坐标系数据。
4.5 数据内容与结构的要求
根据《标准》的要求设计数据库结构，如根据本省规划成果的具体情况，需要增加图层、属性表、属性表字段、规划附表、自编代码或调整数据项长度等内容的在数据整理记录表和元数据文件中对增加的内容作详细的描述，并报经国土资源部信息中心同意。
5 数据源
与矿产资源规划数据库相同的基础地质要素以及地层、构造、矿产地分布等空间数据，直接复制采用经过国土资源主管部门检查验收的数据，并检查核对其数据的数学基础精度、拓扑关系的一致性以及数据源的现势性等；地质勘查规划信息由规划编制单位提供经国土资源部审核批准的纸质资料和电子数据。
6 数据库建设
6.1 数据库建设的技术流程
数据库建设主要包括三个阶段：资料收集和预处理阶段、数据采集和整理阶段以及数据入库阶段。见图1。
注：已经按照《技术要求》完成规划数据采集的，形成了包括规划成果图在内的规划电子成果，其工作流程可从6.3.4数据整理开始，通过格式转换完成数据库建库。
图1 数据库建设工作流程图
6.2 资料收集和预处理阶段
6.2.1 资料收集
根据《技术要求》收集和整理各种规划资料，主要包括图件、规划附表和文字资料等地质勘查规划所涉及的三类成果资料，同时尽可能收集《标准》涉及的所有内容。规划编制单位和数据库承担单位为同一单位时，可采取规划编制与建库资料收集、建库准备同时进行的方式，在图件制作、表格制作以及文本编制过程中尽量考虑建库的技术要求，为建库提供合格的电子数据。规划编制单位和数据库承担单位不是同一单位，需要从以下几个方面考虑收集资料：
（1）图件资料：主要有基础地理底图，基础地质底图，成矿区划图，基础地质调查规划图，矿产勘查规划图，地质灾害、地质环境和地下水调查评价与监测规划图以及其它需要的图件（如成矿预测图、矿产资源分布图等）。
（2）空间数据资料：矿产资源规划数据库中可共用的空间图形数据以及尽可能齐全的地质勘查规划电子数据。
（3）规划附表资料：矿产资源储量表，主要矿产资源潜力分析及需求预测表，基础地质调查工作程度表，主要矿区（床）资源储量基本情况表，主要矿产资源潜力预测表，基础性地质调查规划表，矿产资源调查评价规划表，矿产资源调查评价规划工作区表，矿产资源勘查规划表，矿产资源勘查规划工作区表，危机矿山接替资源勘查规划表，地质灾害、地质环境和地下水调查评价与监测规划表，地质资料开发利用项目规划表等，地质勘查规划项目准入条件指标表。
（4）文字资料：主要是相关文件、规划文本、规划编制说明、规划基础研究报告、规划专题研究报告、相关规范和标准等。
（5）其它资料：可以有遥感影像以及图片、图像或多媒体资料。
6.2.2 资料预处理
数据预处理就是在全面收集资料的基础上，对资料进行系统的分析研究、综合整理及筛选等。所有资料分为空间数据和非空间数据两大类。空间数据包括矢量数据和光栅图件，也可是纸质图件，同时规划区以及其它信息的坐标信息在此处也可归为空间数据。这些数据经过建库过程最终成为满足《标准》要求的空间数据库。非空间数据主要是有关的表格、文件以及相关规范和标准等。
6.2.2.1 空间图形数据
对地质勘查规划成果电子数据中相关的空间图层数据进行筛选，并严格检查其数据质量，修改处理不正确的空间拓扑关系、不合精度的套合关系、不正确或不统一的数学基础、不合要求的接边关系等问题。
6.2.2.2 非空间数据
对地质勘查规划成果电子数据中相关的非空间数据进行筛选，包括规划附表、成果附表以及文档等。综合分析研究空间图层数据的属性能否从相对应的附表、成果附表或文档得到信息。
6.3 数据采集和数据整理阶段
主要工作内容是按照《标准》进行数据挑选和生成，建立分层文件并标准化命名。基础地理部分可采用国家基础地理信息中心发布的1∶50万、1∶25万、1∶10万等空间数据作为基础，根据规划需要进行补充和删减；基础地质部分可依据中国地质调查局制作的1∶50万、1∶20万等地质图数据库进行适当简化；或将矿产资源规划数据库中已有的可用基础空间数据，根据《标准》分层整理。其它相关图件可采用图形扫描矢量化，经过点线编辑、图面检查、图形校正、建立拓扑（对于公共弧段建立统一的拓朴关系，其他无公共弧段的单独图层可分层建立）等过程完成。规划专题图层可由图形扫描矢量化等上述步骤进行输入，如果收集到有拐点坐标的规划资料，则必须使用GIS软件中的空间多边形及点位生成功能自动生成空间多边形及点位的矢量数据。
6.3.1 空间数据采集和分层处理
（1）对矿产资源规划数据库中已有的基础空间数据，可以根据《标准》分层导入并整理；对仅收集到图件资料的情形，可通过图形扫描矢量化，用GIS软件编辑点、线、面，并建立拓扑关系，按《标准》分层要求，分别存入相应图层文件。
（2）对于新采集、处理的图形数据，要将其与从矿产资源规划数据库复制过来的图形数据进行公共弧段套合检查，对不套合或套合精度未达要求的图形数据进行处理，以达建库要求。
（3）因成矿区带和重要成矿远景区图层为按矿类或矿种划分，不可避免的造成区重叠。《标准》中允许这类区重叠，对其图层不要求“多边形要素相互不能重叠”这一拓扑规则。6.3.2 建立图层属性结构
按照《标准》的要求，分别建立各图层的属性结构。
6.3.3 属性数据录入
按照《标准》规定的要求，录入经省厅审核批准的地质勘查规划成果和图件的属性数据。属性的录入可以在GIS软件中进行，也可在数据库管理软件中直接录入，经属性一致性检查后，再与图形库挂接。对于《标准》中“约束条件”项中规定的必填项，需保证数据的完整性。
6.3.4 数据整理
6.3.4.1 空间数据要素分层整理
（1）按照《标准》要求进行，对矿产资源规划数据库中复制过来的空间数据进行整理，整理内容主要包括：检查数据分层，规范分层文件命名，修改完善属性结构及其填写属性值等。
（2）对已经按照《省级地质勘查规划成果技术要求》完成采集的规划数据，以及已形成了包括规划成果图在内的成果数据，进行空间数据的分层整理，包括：规范分层文件命名，修改完善属性结构及其填写属性值等。
（3）对详细整理后的空间数据进行数据投影变换和属性挂接，完成单一GIS平台上的初始建库。
注1：注记层应以图件上与规划实施和空间定位有关的注记为主，如XX矿种调查评价区、XX矿产资源勘查规划区以及长江、黄河等一级河流和重要交通干线名称、主要油气管线名称等。
注2：岩石地层注记内容的上下角标按统一方式进行，即：上标用↑表示；下标用↓表示；还原用→表示。如：C12则表示为C↓1↑2。
6.3.4.2 规划附表结构的整理
形成附表数据的过程一方面通过收集资料整理录入；另一方面，部分资料在空间数据库建设阶段作为属性内容已录入空间数据图层，此时可以直接导出整理为规划附表数据库，不必重复录入。导出的规划附表，需按本规范要求转换为Access数据库表格式，按《标准》进行规划附表结构的整理。根据经省级国土资源部门审核批准的规划指标（或规划纸质资料）检查数据的正确性，检查图数的一致性，修改不一致的内容，确实无法达到一致的应予以说明，并报主管部门认可。
6.3.4.3 元数据数据库建设
在空间数据库和表格、文档数据库完成后，即进行《元数据信息采集表》填写，完成检查和修改后在Access数据库中按照《标准》要求建立元数据属性表，按照《元数据信息采集表》
的内容进行属性录入。同样，元数据属性表建立录入内容后，要参照《元数据信息采集表》进行数据一致性检查，完成检查修改后形成元数据数据库。
6.3.4.4 数据库内容的扩展
空间数据的属性结构和规划附表数据结构应严格按照《标准》定义。如根据本省规划成果的具体情况，在数据库中增加图层、属性表、属性表字段、规划附表、自编代码或调整数据项长度等内容的，须在数据整理记录表和元数据文件中对增加的内容作详细的描述，包括内容、类型、结构、大小、数据说明等（其中增加的数据项应放在表的最后），并将上述内容及时反馈给信息中心有关人员。
6.4 数据入库阶段
数据入库主要是将空间数据和属性数据根据关键字段进行挂接并检查，将规划文档、规划附表等导入数据库，且保证数据库运行正常，统计、查询、检索无误。
6.5 空间数据格式转换
本次建库的提交成果中涉及三种格式的空间数据库：MapGIS格式、ArcGIS Personal Geodatabase（以下简称为Geodatabase）格式及ArcGIS Shapefile（以下简称为Shape）格式。如果空间数据库建库流程是在MapGIS平台上进行，则最终成果需向ArcGIS成果转换，同时需要提交MapGIS成果；如果空间数据库建库流程在ArcGIS平台上进行，成果只需要提交ArcGIS 成果。
7 数据库成果内容及要求
7.1 成果提交资料目录
（1）空间数据：
ArcGIS平台下建库：提交ArcGIS Shapefile 或ArcGIS Personal Geodatabase格式数据（以度为单位的大地经纬度坐标数据）。
MapGIS平台下建库：提交ArcGIS Shapefile 或ArcGIS Personal Geodatabase格式数据，同时提交MapGIS格式的成果数据（以度为单位的地理坐标系数据）。
（2）规划文档：包括总体规划文本、编制说明、规划研究报告以及其它文档资料（Word 格式和Html 两种格式）。
（3）附表：包括规划附表和成果附表，前者按 ACCESS和DBF两种格式，后者按Excel 表格文件。
（4）数据采集表（Word格式），元数据入库数据（ACCESS和DBF两种格式）。
（5）自编代码字典（ACCESS格式），需标明所属数据项名称。
（6）规划附图成果图文件（MapGIS格式），含工程、图层和系统库文件。
7.2 成果提交形式及内容
汇交数据文件按表1进行物理存储，存储介质为光盘。在提交成果之前，要进行全面查杀毒，确保数据安全。
表1 汇交数据文件形式表
7.3 地质勘查规划数据库成果提交要求
7.3.1 空间图形数据
按《标准》中5.1 空间要素分层中的表3 要求提供。
说明：因个别省的规划成果形成较早，其勘查规划区的划分与最新的《技术要求》不一致，如划分为：能源矿产重点勘查区、非能源重要矿产重点勘查区、能源矿产一般勘查区、非能源重要矿产一般勘查区、其他矿产勘查区。在表3的基础上增加上述勘查规划区及相应的勘查规划工作区图层。
勘查规划区及相应的勘查规划工作区属性表名分别为：KANGHQNZD、KANGZQNZD；KANGHQFZD、KANGZQFZD；KANGHQNYB、KANGZQNYB；KANGHQFYB、KANGZQFYB；KANGHQQYB 、KANGZQQYB。
勘查规划工作区目标矿产属性表名为在勘查规划工作区表名后加“_KC”表示。
勘查规划区及相应的勘查规划工作区注记图层属性表名为：KANGHQNZDZJ、KANGZQNZDZJ；KANGHQFZDZJ、KANGZQFZDZJ；KANGHQNYBZJ、KANGZQNYBZJ；KANGHQFYBZJ、KANGZQFYBZJ；KANGHQQYBZJ、KANGZQQYBZJ。
勘查规划区、勘查规划工作区及勘查规划工作区目标矿产表的属性结构分别对应《标准》中表33～35。注记表的属性结构同《标准》表38。
7.3.2 图件输出要求
7.3.2.1 规划成果图件包括下列基本图件：
（1）成矿区划图
a）主要内容：
Ⅰ简化的地质图
Ⅱ矿产勘查工作程度
Ⅲ成矿区带划分及重要成矿远景区
b）构图主要图层和成果附表：
Ⅰ基础地质、勘查现状要素图层：《标准》表3中的DC、YT、DZJX、DUC、KCJD、CKQD以及CKYJQ等图层及其相应注记图层；
Ⅱ主要成果附表。
（2）基础地质调查规划图
a）主要内容：
Ⅰ基础地质调查工作程度
Ⅱ基础地质调查规划
b）构图主要图层和成果附表
Ⅰ基础地质、勘查现状要素图层：按《标准》表3中的DC、YT、DZJX、DUC、
XZ******等图层及其相应注记图层；
Ⅱ规划要素图层：按《标准》表3中的GHQ*****等图层及其相应注记图层。
Ⅲ主要成果附表。
（3）矿产勘查规划图
a）主要内容：
Ⅰ重要成矿远景分区
Ⅱ矿产资源调查评价规划
Ⅲ能源矿产勘查规划（非必选）
Ⅳ非能源重要矿产勘查规划（非必选）
Ⅴ其他矿产勘查规划（非必选）
Ⅵ矿山接替资源勘查规划
Ⅶ国家出资矿产勘查规划
Ⅷ鼓励、限制、禁止及允许矿产勘查规划
b）构图主要图层和成果附表
Ⅰ基础地质、勘查现状要素层：《标准》表3中的DC、YT、DZJX、DUC、CKQD以及KCJD等图层及其相应注记图层；
Ⅱ规划要素层：《标准》表3中的DCPJGHQ、JTKCGH、KANGHQJZ、KANGHQXZ、KANGZQXZ、KANGHQGL、KANGZQGL、KANGHQYX以及KANGZQYX等图层（或KANGHQNZD、KANGZQNZD、KANGHQFZD、KANGZQFZD、KANGHQNYB、KANGZQNYB、KANGHQFYB、KANGZQFYB、KANGHQQYB 、KANGZQQYB图层）及其相应注记图层。
Ⅲ主要成果附表
（4）地质灾害、地质环境和地下水调查评价与监测规划图
a）主要内容：
Ⅰ地质灾害调查评价规划
Ⅱ地质环境调查（含矿山环境、地质遗迹调查）规划
Ⅲ地下水调查评价规划
Ⅳ地质环境监测规划
b）构图主要图层和成果附表
Ⅰ基础地质、勘查现状要素层：《标准》表3中的DC、YT、DZJX、DUC等图层；
Ⅱ规划要素层：《标准》表3中的DHGHDZ、DHGHXZ、DHGHMZ以及DHGHZJ等图层。
Ⅲ主要成果附表
注1：规划图件以1:50万地理底图为基本底图，比例尺可根据省（区、市）行政区面积扩大为1:25万。
注2：各省（区、市）根据实际需要，可增加图件、对上述规划图件增加内容或对图件予以归并或拆分，也可根据实际情况编制各专题勘查规划图。
注3：各成果图件中《技术要求》未规定的部分内容，本规范中对其构图图层或内容作了较为详细的描述，以更完整、直观地反映现状和规划成果，但不作为必须添加的图层或内容。
7.3.2.2 图外要素及图式图例要求
（1）图外主要要素
图名、坐标系及高程系、成图比例尺、制图单位全称、说明（含调绘时间、制图时间）、辅助说明以及图例等。
（2）图式图例
图面各要素的颜色、图案、线型等表示的形式及范例，请参见附录E。
7.3.3 规划附表成果内容
按《标准》中表40规划附表内容表中的要求提供。
7.3.4 规划文本输出要求
规划文本、编制说明以及规划研究专题报告：要求电子文档的内容和排版与经省级国土资源主管部门审核批准的纸质资料一致。
7.3.5 建库承担单位建库报告要求
数据库建库报告包括自检报告、工作报告和技术报告。
7.3.5.1 自检报告内容要求
（1）自检内容：建库过程中形成的每个步骤。
（2）自检主要方法和程序：自检应100%检查，应将上述检查内容逐一检查。
（3）自检结果。
7.3.5.2 数据库建设工作报告内容要求
（1）项目概述
a) 建库省基本情况简介（含地理位置、面积、人口、经济和辖区划分等内容）。
b) 承担建库单位基本情况简介（含软、硬件环境，人员，单位性质等内容）。
c) 原始资料基本情况简介。
d) 建库投入（含建库起止日期、人员及工天、经费等）。
（2）建库工作的组织实施
a) 项目管理方式（组织模式等）。
b) 质量控制管理。
c) 经费支出管理。
（3）建库主要成果
a) 数据成果。
b) 图件与表格成果。
c) 文字成果（含电子文档）。
（4）存在的问题及建议
主要是协调管理方面的问题（不含技术问题）。
（5）数据库成果应用设想
7.3.5.3 数据库建设技术报告内容要求
（1）建库概述
a) 建库背景及技术准备。
b) 建库依据。
c) 主要技术路线。
d) 软、硬件环境。
（2）数据采集处理（含方法及质量控制）
a) 技术流程。
b) 资料预处理。
c) 数据采集与整理。
Ⅰ数据输入
Ⅱ坐标转换
Ⅲ数据检查整理
Ⅳ数据综合编辑处理
Ⅴ数据分层
Ⅵ属性录入
Ⅶ数据格式转换
Ⅷ数据入库
（3）存在问题及解决方案
Ⅰ已解决的问题及处理方法。
Ⅱ未解决的问题及建议。
8 数据质量控制与评价
8.1 数据质量控制基本要求
为保证地质勘查规划数据库质量，需按三级检查要求进行质量控制。
（1）一级检查：作业组自查、互检。要求 100 ％的全面检查。
（2）二级检查：是在作业组自查、互检的基础上，由项目负责人或项目质检人员对作业组生产的数据进行100 ％的全面检查。
（3）三级检查：是在二级检查的基础上，对作业组生产的数据进行的再一次检查。三级检查由生产单位的质量管理部门或质检员负责，按抽样比例进行检查。
对每级检查发现的问题应进行全面修改，并经复检通过后方可提交下一级检查或验收。8.2 数据质量控制与评价的方法
为了确保数据质量，并对其进行质量控制和评价，本规范建议可依据《国土资源数据库数据质量检查验收规范》的方式方法和方案规则对所建数据库质量进行检查控制以及评价，并可参照其中的“市级矿产资源总体规划数据库整合成果检查验收示例”对地质勘查规划数据库数据质量进行控制与评价。
8.3 检查主要内容和方式方法
根据《国土资源数据库数据质量检查验收规范》对检查项以及数据质量元素的规定，结合本项目的具体情况，确定检查内容及相应的检查方式方法。
8.3.1 成果提交形式检查
（1）检查数据文件命名及目录存放检查：检查成果内容目录存放是否符合规范要求。
（2）成果数据完整性检查：图层完整性检查（包括图层子表）：检查遗漏或冗余的图层；自定义图层；规划附表及元数据完整性检查，自定义附表；规划文本完整性检查。
（3）数据文件存储格式检查：检查是否符合规范要求。
8.3.2 空间数据质量检查
1、图层数据检查，包括：
（1）投影方式与坐标系统检查：图层空间位置的正确性，主要检查空间坐标的正确性；
（2）拓扑关系检查：图形数据拓扑关系的正确性，主要检查是否有多余的多边形碎片及多余的弧段，孤立的点、线要素是否合理，悬挂的线要素是否合理。
（3）几何精度检查：图层之间逻辑关系的一致性，主要检查各图层之间应当相互重叠的点、线、面是否能保持基本一致，作到不扭结、不交叉、不裂缝等；
（4）图层图元数据完整性检查：主要检查空间实体、符号、注记等的完整性。
（5）检查要素分层的正确性及各要素图层关系的正确性，包括图层与子图层的关联关系。
2、属性数据检查，包括检查：
（1）图层属性数据（包括子表数据数据）结构完整性检查：根据《标准》检查遗漏或冗余的字段；
（2）图层属性数据（包括子表数据数据）结构正确性检查：根据《标准》检查字段代码、字段类型、字段长度等是否正确；
（3）图层属性数据字段内容完整性检查：检查字段内容为空值是否合理；
（4）图层属性数据字段内容正确性检查：检查代码型数据项填写内容的正确性；可以标准化或具唯一性数据项填写内容的正确性；具有逻辑关系的数据项填写内容的正确性，说明性字段内容的合理性。如“目标标识码”的唯一性，最小基本单元属性内容的正确性。
（5）图元与属性对应关系的正确性检查。
（6）检查主表与子表的关联关系的正确合理性。
8.3.3 表格数据检查，包括对规划附表及元数据表进行检查
1、规划附表（包括子表），检查：
（1）结构完整性：字段是否缺失、是否有自定义、结构顺序是否错位；
（2）结构正确性：字段代码、字段类型、字段长度是否符合标准；
（3）字段内容完整性：关键字段内容是否为空；
（4）字段内容正确性：字段值是否正确，是否符合取值范围；
（5）检查主表与子表的关联关系的正确合理性。
2、元数据，主要检查：
（1）结构完整性：字段是否缺失、是否有自定义、结构顺序是否错位；
（2）结构正确性：字段代码、字段类型、字段长度是否符合标准；
（3）字段内容完整性：关键字段内容是否为空；
（4）字段内容正确性：字段值是否正确，是否符合取值范围；
（5）根据规范中要求填写的元素据采集表检查元数据的录入是否正确。
8.3.4 文档的检查
包括对规划文本、编制说明、研究报告、元数据文档及本次建库过程中新增的文档资料（工作方案、技术方案、工作报告、技术报告以及项目过程中的相关说明）等进行检查：
1、规划文档，如规划文本、编制说明以及研究报告等检查：对照经审批后的纸质报告检查电子文档内容，要求不缺漏，逻辑清晰，文档内容描述准确；文档结构符合相关规范标准。
2、建库过程中新增的文档资料，如建库工作报告、技术报告等检查：符合本《规范》要求。
8.3.5 空间图层数据与非空间数据对应关系的检查
1、依据《标准》中图1所指引的关系检查与空间数据关联的规划附表与其对应图层的关系的正确性；根据规划成果附表内容，按图层中图元编号的对应关系，对图元进行检查。
2、检查与空间数据相关联的规划附表与其对应图层的一致性：图层属性内容与表格数据内容的对应性检查，与空间图层对应的规划附表主要有：基础地质调查工作程度表，矿产勘查工作程度表，主要矿产资源潜力预测表，基础地质调查规划表，矿产资源调查评价规划区表，矿产资源调查评价规划工作区表，矿产资源勘查规划区表，矿产资源勘查规划工作区表，危机矿山接替资源勘查规划表，地质灾害、地质环境和地下水调查评价与监测规划表。按照《标准》中图1所描述的关系检查。
8.3.6 图件电子文件质量检查
依据审批后的规划附图，对比用提交的图层成果数据绘制的规划专题图数据库数据进行图面质量检查，发现错误及时修改完善，直至准确无误。
9 检查验收及评价
9.1 成果检查与验收
9.1.1 检查验收目的
规范地质勘查规划数据库建设，保证数据库建设质量，为规划实施提供高质量的数据基础。
9.1.2 检查验收的依据
主管单位对承担单位提交的数据库可参照《国土资源数据库数据质量检查验收规范》按通过与不通过判定数据质量的评价方法或按优秀、良好、合格与不合格判定数据质量的评价方法进行检查验收。
9.1.3 检查、验收制度
建立建库承担单位自检，省级预检、验收和国家级抽查三级检查验收制度。预检、验收本着实事求是、公平、公正、公开的原则，以保证验收工作的科学性和严肃性，参加检查工作的人员，若有可能影响工作的公正、公开，则应回避。
9.1.3.1 自检制度
为保证地质勘查规划数据库成果质量，每个阶段或重要技术环节完成后必须认真检查。建库承担单位应建立作业人员和技术人员之间的自检、互检以及审校人员的审核等检查制度。9.1.3.2 预检验收制度
由项目承担单位向省级建库主管部门提出书面预检申请，经过审查同意后，由项目组织实施单位，组织专家进行预检，并提交预检报告。
由省级建库主管部门负责将本辖区内预检通过的地质勘查规划数据库成果和其预检报告进行汇总，并向国家级建库主管部门提交验收申请。
国家级建库主管部门组织有关单位和技术人员对申请验收的成果进行检查验收。
9.1.4 成果验收程序
地质勘查规划数据库验收程序如下：
（1）由建库承担单位提交预检申请，并连同自检报告、建库技术报告和建库工作报告以及所有的数据库建设成果一并报省级建库主管部门。
（2）省级建库主管部门和有关单位组织人员成立成果预检组，按照本规范和《标准》进行预检。
（3）省级建库主管部门组织验收评委对提交的地质勘查规划数据库成果进行全面的检查，如有必要可请项目实施负责人向评委做说明，评委提出预检结果；
（4）检查验收以《标准》、本规范以及有关标准规范为依据，凡按规定进行数据库建设并达到质量要求的项目即为合格。
（5）如果成果验收不合格，将验收意见返回承担单位，对数据进行修改完善后，再次提交验收，直至验收合格。详见图2 成果验收流程图。
9.2 预检和验收的内容
预检和验收的内容包括地质勘查规划数据库、图件、规划附表、文字报告以及元数据五部分。检查的重点和方法依据第8章。
9.3 预检报告和验收意见
地质勘查规划数据库建设成果经过预检和验收程序后由预检组和验收组提交预检报告和验收意见。验收专家组根据《地质勘查规划数据库成果数据检查记录表》行评价打分。
图2 成果验收流程图
附录1
（规范性附录）
图式图例
1.1 基本要素内容及其图式图例参考依据
1.1.1地理要素
图式图例参考《1:1000000 地形图编绘规范及图式》（GB/T 14512—93）、《地图用公共信息图形符号通用符号》（GB/T 17695—1999）、《1:500000 1:1000000省（市、区）地质图地理底图编绘规范》（DZ/T 0519—95）等标准。
1.1.2地质要素
图式图例参照《区域地质图图例》（GB 958-1999）
1.1.3专题规划要素
（1）矿种符号按照《区域地质图图例》（GB 958-1999）。规模以符号大小表示。
（2）以绿色框或绿色填充符号表示矿产资源鼓励勘查区、黄色框或黄色填充符号表示矿产资源限制勘查区、红色框或红色填充符号表示矿产资源禁止勘查区，以便与矿产资源总体规划图件的表示相一致。
11.4 主要规划图件的具体要素内容
1.1.4.1 成矿区划图
（1）地理要素
主要河流、县级以上行政区界线、县级以上城市（县城）、主要中心镇名称、主要铁路、
公路等基础设施；
（2）地质要素
以数字地质图（淡化或素图）为工作底图（或以相应矿产资源规划的地质基础数据为底图），标明主要地层界线、岩体、断裂等；
（3）成矿区划要素
包括成矿区带划分、重要成矿远景区、以及成矿预测区。
1.1.4.2 基础地质调查规划图
（1）地理要素（与成矿区划图相同）
（2）地质要素：与成矿区划图基本相同，各省（区、市）根据实际情况选择适当比例尺数字地质图为工作底图（或以相应矿产资源规划的地质基础数据为底图），标明重要成矿区带、主要成矿远景区、主要地层界线、岩体、断裂以及调查评价和勘查工作程度现状等；
（3）基础地质调查规划要素：全面反映基础性、公益性地质调查和矿产资源调查评价工作程度。矿区（床）标明规划区编号、规划区名称、工作方法、工作期限等。
1.1.4.3 矿产勘查规划图
（1）地理要素（与成矿区划图相同）
软件工程-数据库设计规范与命名规则
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。 C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis， 简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术， 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:
海洋信息工程标准术语
海洋信息工程标准术语 1 海洋信息采集与管理 1.1 海洋信息ocean information 海洋活动中产生或涉及的各类信息的总称。 1.2 海洋资料marine materials 海洋工作中形成的文字、图表、声像、电磁和光媒等介质形式的海洋信息。 1.3 海洋数据marine data 各类海洋调查、观测、监测、探测、实（试）验、检验和统计等所获得的数据。 1.4 海洋基础数据marine basic data 反映海洋自然和社会属性基本状况及变化规律的数据。包括岸线、海岸带、海岛、海洋水体、海底、深海、大洋、极地海域的海洋地理、地质地貌、地球物理、物理海洋与海洋气象、海洋生物与生态、海洋化学、海洋遥感和海洋经济等学科的基础数据，以及海洋资源、沿海行政区、人工岛、海上人工设施和海底管线等的数据。 1.5 海洋空间数据marine spatial data 描述海洋地理实体的位置、形状、大小、分布、地理特征及相互间拓扑关系的数据。 1.6 海洋属性数据marine attribute data 描述海洋地理实体质量和数量特征的数据。 1.7 海洋元数据marine metadata 描述海洋信息来源、内容、质量状况和其他特性的数据。 1.8 海洋实时数据real-time marine data 数据采集时同步向用户分发或储存的海洋数据。 1.9 海洋延时数据delayed marine data 数据采集后延迟一定时间向用户分发或储存的海洋数据。 1.10 海洋信息标准ocean information standards 对海洋信息活动或其结果相关的重复性事物和概念所做的统一规定的文件。 1.11 海洋信息化marine informatization 应用现代信息技术，开发和利用海洋信息资源，促进海洋信息交流与共享，提升海洋各项工作效率和效益的过程。 1.12 海洋信息采集ocean information acquisition
MySQL数据库开发规范1.3
平安金融科技数据库（MySQL）开发规范 作者: 简朝阳 Last Updated: 25/02/14 19:30:18 历史修订记录： 版本修订人修订时间修订内容 1.0 1.1 李海军2013-03-11 增加部分说明及修改 1.2 李海军2013-07-29 增加连接池使用说明和memory引擎的控制 1.3 李海军2014-02-25 增加了char类型，修改了timestamp的使用场合。 说明 ?本规范包含平安金融科技使用MySQL 数据库时所需要遵循的所有对象设计（数据库，表，字段），所需要遵循的命名，对象设计，SQL 编写等的规范约定。 ?所有内容都为必须严格执行的项目，执行过程中有任何疑问，请联系DBA Team 取得帮助。 概述 ?禁止明文传播数据库帐号和密码。 ?禁止开发工程师通过应用帐号登录生产数据库。 ?禁止应用在服务器安装MySQL客户端（可以安装开发包）。 ?禁止开发人员在SQL中添加Hint，Hint只能由DBA审核后添加。 ?禁止使用悲观锁定，即读锁select … for update。 ?禁止在开发代码中使用DDL语句，比如truncate，alter table … 等。 ?禁止DML语句的where条件中包含恒真条件（如：1=1）。
1. 命名规范 总则 ?数据库对象名仅可包含小写英文字母、数字、下划线（_）三类字符，并以英文字母开头。 ?数据库对象命名禁止使用MySQL保留字。 ?多个单词之间用下划线（_）分隔。 ?对象名称长度若超过限制，则使用简写/缩写命名。 1.1. 数据库命名 ?数据库以"db_"前缀+ "站点名_"前缀及其所服务的应用名称命名。 1.2. 表命名 ?所属同一模块的表必须以模块名作为前缀命名。 ?历史数据表在原表基础上增加"_his"后缀命名。 1.3. 字段命名 ?布尔意义的字段以"_flag"作为后缀，前接动词。如：表示逻辑删除意义的字段可命名为delete_flag。 ?各表间相同意义的字段（如：作为连接关系的引用字段）使用相同的字段名。 1.4. 索引命名 ?唯一索引以uk_tablename_columnnames 方式命名 ?普通索引以idx_tablename_columnnames 方式命名 ?组合索引以idx_tablename_column1_column2... 方式命名 示例 ?站点名：maymay ?模块名：order ； ?数据表：item； ?字段组成：order_item_id,add_time,raw_update_time,c1,c2,c3,c4,c5 ?标准数据库名：db_maymay_order； ?标准数据表名：order_item； ?历史数据表名：order_item_his；
城市公共基础数据库建设参考方案
城市公共基础数据库建设参考方案
城市基础数据库系统建设方案
1.系统概述 长期以来，政府各部门内部拥有着大量城市基础数据资源，但由于管理分散，制度规范不健全，造成重复采集、口径多乱、数出多门；各部门的指标数据自成体系，标准不一，共享程度较差。随着政府向“经济调节、市场监管、社会管理和公共服务”管理职能的转变，就要求必须能够全面、准确掌握全地区经济社会发展态势，强化政府部门掌控决策信息资源的能力，政府部门间信息资源整合与共享需求越来越紧密，但当前部门间信息共享多是点对点方式，
没有统一的数据交换管理平台。因此各部门对加快解决数据资源分散管理、数据共享不足的问题需求十分迫切，需要建立城市基础数据库（以下简称智慧城市公共基础数据库）系统以解决以上问题。 依托智慧城市公共基础数据库系统的建设，可以实现各委办局、各所辖地区的经济社会综合数据采集交换，为各部门提供更广泛的信息共享支持，一方面数据信息从各委办局、各所辖地区整合接入，另一方面也为政府和这些接入部门提供全面的共享服务。同时，以智慧城市公共基础数据库指标体系建立为基础，整合来自各委办局和各所辖地区的、经过审核转换处理的数据资源，可实现对经济社会信息的统一和集中存储，确保数据的唯一性和准确性，为今后政府工作提供一致的基础数据支持。 数据整合共享只是手段，数据分析服务才是目的。依托智慧城市公共基础数据库系统建设，可有效整合各政府部门所掌握的全市经济社会信息资源，满足政府业务对统一数据资源共享需要，进而提升形势分析预测水平，对政府在发展规划、投资布局、资源环境、管理创新、科学决策等业务提供强有力支持，提高了政府部门掌控全市经济社会发展态势能力。 2.建设目标 1）建立科学合理的智慧城市公共基础数据库指标体系，力求全面反映地区经济和社会发展的总体情况： 2）有组织、有计划、持续地对政府统计部门、政府各部门以及国民经济行业管理部门负责统计的关系到地区经济与社会发展的信息资源进行收集、整合，建立全地区城市信息资源共建、共享的统一管理机制； 3）依托地区电子政务基础设施，充分利用现代信息技术，以科学的地区宏观经济和社会发展指标体系为基础，建设支持政府宏观经济管理和社会和谐发展的基础数据库系统，提高信息资源的建设、管理和共建共享能力； 4）为地区经济建设和社会和谐发展提供一致的城市基础数据，为各类应用系统建设提供基础数据支持，满足政府管理决策、部门信息共享和社会公共服务“三个层次”的需求。
专题数据库建设推荐标准规范
专题数据库建设推荐标准规范 （一）数据采集规范 1.数据来源包括在人文社会科学研究过程中采集、加工和积累的研究数据。 2.采集对象包括社会调查、统计分析、案例集成、基础文献等一手数据和原始资料。 3.数据类型包括数值、文本、图片、音频、视频和空间数据等。 4.采集方式包括自动采集、半自动采集和手工采集等。 （二）数据加工规范 1.数字对象唯一标识符规范采用《我国数字图书馆标准规范建设》项目（CDLS）所推荐的唯一标识符体系以及数据中心规定的相关标准。 2.专题数据库的核心元数据应符合《TR-REC-014数据集核心元数据规范》及数据中心的相关要求。 3.音频资料描述元数据规范及著录规则，遵循《CDLS-S05-031音频资料描述元数据规范》和《CDLS-S05-032音频资料元数据著录规则》所推荐的一系列相关标准以及数据中心规定的相关标准。 4.其它资料描述元数据规范及著录规则，遵循《我国数字图书馆标准规范建设》项目（CDLS）所推荐的一系列相关标准及数据中心规定的相关标准。
5.各类接口所实现服务的标识应符合《TR-REC-017资源唯一标识规范》的相关规范要求。 6.文本、图片、音频、视频等各类型数据能够转换为数据中心规定的数字文件格式。 7.专题数据库数据的加工过程需严格执行两重审核制度，保证数据格式符合规定标准。 （三）数据库系统规范 1.专题数据库系统平台必须使用正版数据库管理系统软件，推荐使用关系数据库管理系统，遵守SQL语言系列标准。 2.专题数据库系统平台应具备数据备份及容灾机制，重要数据应进行异地备份。 3.专题数据库系统平台应具备一定的扩充能力，系统的模块化程度高，软件维护方便。 4.专题数据库系统平台应遵循中国国家标准GB/T 20273-2006《数据库管理系统安全技术要求》，具有切实可行的安全保护和保密措施，确保数据永久安全。 （四）专题数据库应用系统规范 1.专题数据库应用系统至少包括数据采集、数据加工、数据检测、数据浏览、数据检索、用户管理和数据维护七大类功能。 2.专题数据库应用系统至少支持开放数据访问接口、开放索引数据收割接口和开放服务状态监控接口三类功能接口。 3.专题数据库应用系统向数据中心提供访问完整数据记
海洋数据库建设规范方案
地球科学数据共享材料八 海洋科学数据库建设规 （讨论稿） 中科院海洋科学研究所 地球科学数据共享政策与规研究组 2004年5月
目录 1．前言 (2) 2．海洋科学数据库建设总体要求 (2) 2．1 海洋科学数据库总体框架构建 (2) 2．2 具体的数据库的建库规 (2) 2．2．1 术语定义 (2) 2．2．2 具体数据库的建库流程 (3) 2．2．3 具体数据库建设目标 (3) 2．2．4 数据库文档 (3) 海洋数据库建设规实例：中国近海和西北太平洋温盐声密数据库建设规 (4) 1．前言 (4) 2．中国近海和西北太平洋温盐声密数据库建设规 (5) 2．1适应围 (5) 2．2引用标准 (5) 2．3技术术语定义/解释 (5) 2．4 编码、属性表命名规则 (7) 2．5 元数据标准 (8) 2．6 文档格式 (8) 2．7 数据库建设流程 (8) 2．8 数据质量控制 (10) 2．9 数据库汇交（集成）（汇交至的方法和途径等） (13)
1.前言 海洋科学是一门综合性的学科，涵盖物理海洋学、海洋地质学、海洋生物学、海洋化学等多个学科，研究工作中所涉及、积累的数据也是多种多样各不相同，如物理海洋方面水文数据是记录着某一经纬度、某一时间、某一航次、某一深度的海水温度、盐度和密度信息；海洋地质方面基础地质数据记录着某一区域海底深度及海底地貌等信息；而海洋生物方面又可能是某一物种或某一标本的属性等，因此各方面的数据库建设也各不相同，建设规也就各不相同。 根据这种情况作为海洋科学数据库的建库单位，一方面我们对整体的数据库建设有建设规（总体要求）；另一方面，要求每一个具体的数据库要通过建库的工作确定各自的规和标准，这个规、标准是代表海洋所水平的，基本也就是代表科学院水平的，而且要求进行必要的鉴定工作成为国家水平的。 2.海洋科学数据库建设总体要求 2．1 海洋科学数据库总体框架构建 海洋科学数据库可以粗略地分成海洋水文子库、海洋地质子库和海洋生物子库三个部分，每个部分又包含了自成系统的多个具体的数据库。确定海洋科学数据库的整体框架，（从总结中摘录），使海洋科学数据库建和服务设成为日常性的工作。 2．2 具体的数据库的建库规 2．2．1 术语定义 源数据集：具体数据库建库的数据来源，不拘于数据格式的、不断增长的数据集合。 标准数据集：产生于源数据集，经过数据格式的统一，经过数据排重和质量控制后产生的数据集合，最直接的入库数据。 排重：在数据集中排除重复数据的过程。
系统界面设计规范
B/S 系统界面设计规范 1.引言 界面美观、操作易用性、维护成本低是评价B/S系统的关键。本规范参考了一些成熟产品科学的开发方法，将开发过程中的方式、规则等强行的约束。希望藉此来提高用户操作感受，提升B/S产品的质量。 1.1. 编写目的 广义的界面概念包含了除页面布局设计之外，交互性的设计，及人体工程学方面的研究。本规范制订的依据从广义概念出发，总结以往项目的成败经验，目的是从整体上提升公司B/S类产品的质量、开发效率。从以技术为中心发展为以客户为中心，将类似项目成功的经验继承和积累下来，将B/S系统与C/S系统开发过程上的区别降低到仅显示控制的极小的层面。新的开发方式强调分层，规范出界面设计人员做什么，服务器编程人员做什么，这样就把页面和控制代码两个层面清晰的分开。 1.2. 背景 B/S模式系统以其易部署、易扩展、能够高度集成各种技术的特点，在公司产品线中占越来越大的比重，.Net、J2ee等技术的发展更是将B/S系统的开发和桌面应用程序开发的工程方法统一起来，突出服务器端技术，这些变革要求界面设计人员和服务器端编程人员可以应用更加科学的方法合作，团队的合作方式甚至决定了一个系统开发的成败。目前公司较多的服务器端编程人员仍然处于“后ASP 时代”的开发方式，表现为前台页面仍然与服务器代码高度的关联，带来的后果是重复建设、高昂的维护成本或失去控制的项目，没有充分的发挥出集成开发工具的优势。在以往的开发方式下界面设计侧重在静态页面的建设上，每个页面作为一个独立的模块来处理，在页面交互中则是程序员根据自己的习惯来控制，程序对个人的编程风格的依赖很强，这些在以往开发WEB站点的方式扩展到B/S系统有时是不正确的，甚至是背道而弛的，当然也不利于规模化的团队合作。 1.3. 定义 术语定义： 效果图：由界面设计人员设计的页面效果图，综合了概要设计的业务需要和整个站点的风格，它规定了页面布局上的每个细节。 容器：即HTML 标记的嵌套结构，如在表格->行->单元格内放置图片，那么可以认为单元格是放置图片的容器。 样式表：即级联式样式表CSS，它是W3C机构在HTML标记语言上扩展的格式语言。 非标准交互控件：是通过标准控件组合、扩展等方法以提高特定业务执行效率而进行封装的控件，或概括为用户根据以往的操作经验不能够直接领会出操作方式的交互控件。 2. 界面设计规范细则 总体目标 以规范作为基本原则，在此框架内进行合理的扩展和变化，将站点内的每个模块服从于整个站点，模块页面与“高内聚”的控制代码紧密的结合在一起，同时对应于应用程序基于系统的架构分析。 2.1. 通用原则 1 界面色彩要求：计算机屏幕的发光成像和普通视觉成像有很大的不同，应该注意这种
数据库设计和编码规范
数据库设计和编码规范 Version
目录
简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
DB44／T 1399-2014 自然保护区数据库建设技术规范
ICS 65.021.01 B 60 备案号：44768-2015 DB44广东省地方标准 DB44/T 1399—2014 自然保护区数据库建设技术规范Technical Specification for Construction of Database in Nature Reserves 2014-08-18 发布2014-11-18 实施
广东省质量技术监督局发布
DB44/T 1399—2014 前言 本标准按照GB/T 1.1－2009的规定编写。 本标准由广东省自然保护区管理办公室提出。 本标准由广东省林业厅归口。 本标准首次发布。 Ⅰ
DB44/T 1399—2014 自然保护区数据库建设技术规范 1范围 本标准规定了自然保护区数据库分类与组织、数据库命名、数据字典和数据管理等技术要求。 本标准适用于广东省各级林业行政主管部门管理的自然保护区数据库建设。 2规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。 LY/T 1662.2 林业数字矢量基础地理数据标准 LY/T 1662.7 数字林业标准与规范第7部分—数据库建库标准 LY/T 1662.9 数字林业标准与规范第9部分—数据库管理规范 LY/T 1662.10 数字林业标准与规范第10部分—元数据标准 3术语和定义 下列术语和定义适用于本文件。 3.1 数据库 database 在计算机存储设备上合理存放的相互关联的数据集合。 3.2 数据集 dataset 可以标识的数据集合。数据集可以是数据库，也可以是数据库的一个（逻辑组成）部分。 3.3 数据表data table 在关系型数据库中，具有行列特征的一个结构，数据表是代表关系的基本结构或管理数据文件的部分。 3.4 数据字典 data dictionary 数据库中的一个特殊数据库，它所包含的是“关于数据的数据”，即有关数据库系统中各种描述信息的集合。例如模式、文件、程序、作业、数据项定义和属性描述等。 3.5 元数据 metadata 关于数据的数据，用于描述数据的内容、覆盖范围、质量、管理方式、数据的所有者、数据的提
数据库设计方法、规范与技巧
数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝ 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示: 2.1 第零步——初始化工程
人口基础数据库建设规范
竭诚为您提供优质文档/双击可除人口基础数据库建设规范 篇一：全员人口数据库建设培训手册 入户调查———信息卡登记填写篇 以下几个率，我们各级检查中是要考核的，数据库的建设必须达到如下指标： 1、全员人口个案信息覆盖率要求达到95% 口个案信息覆盖率=去除重复个案后数据库包含人口数/应纳入全员库人口总数×100% 应纳入全员库人口包括本地户籍人口（含流出人口）与流入人口。 2、准确率（已采集信息正确的人数占已采集所有人数的比例）（具体计算可能要通过逻辑审核或者是实地调查核与信息卡数据库核对结果计算）95%以上。 3、项目完整率（每人约有50项采集内容，其中每人已采集项目与总项目数的比例）（在实际计算中可能选择其中几项必须填写项来计算，如逻辑审核中重点核实的缺少必填写项目审核） 4、数据库更新及时率（出生或者是四术发生变动时，
数据库是否及时变更，数据库中出生和四术的上报日期与实际的出生日期和实际避孕措施开始日期的变更不应超过三个月或者是更短日期，否则视为不及时） 以上各项指标的高低是关系到全员人口数据库建设成败与否的关键因素。 只有信息采集达到上述标准要求，才能为下一步全员录入奠定基础。 下面将全员人口信息采集步骤详细叙述如下： 一、全员人口数据库要求实现以房管人，内蒙采集规范对房屋的编码要求如下： 内蒙至村级编码示意图：（系统中已经固定编码） 村级至户级示意图：（小区至户未固定编码） 二、具体到平房或楼房中编码规则如下： 如图：这个平房小区共有三排： 第一排共一列，这一列有三院，一院大门向东开，一院里有三户人家，二院大门向南，院内有两户人家，三院有一户人家； 第二排共两列，第一列共一院，院内有两户人家，第二列共有两院，第一院有两户人家，第二院有一户人家； 第三排共一列，这一列有两院人家，第一院有两户，第二院有一户。 那么这个小区内的房屋编码依次为：
Oracle数据库开发规范
项目编号：××× xxx Oracle数据库开发规范 Oracle DB Development Standardization
审批信息： 签字/日期 审核 审批 目录 1 概述 4 1.1 编写目的 4 1.2 文档约定 4 1.3 预期的读者和阅读建议 4 1.4 参考文献 5 2 数据库对象命名 6 2.1 命名总体原则 6 2.2 表名 6 2.3 视图 6 2.4 同义词 6 2.5 序列7 2.6 索引7 2.7 存储过程7 2.8 存储函数8 2.9 存储程序包8 2.10 触发器8 2.11 字段8 2.12 其他9 3 设计规范9 3.1 范围9 3.2 表空间9 3.3 字符集10 3.4 主外键约束10 3.5 分区表10 3.6 RAC下的序列设计10 3.7 字段10 3.8 表结构设计11 3.9 索引设计11 3.10 临时表11 4 SQL编写规范 12 4.1 书写规范12 4.2 SQL语句的索引使用13 4.3 SQL语句降低系统负荷 15 5 PL/SQL编程规范18
5.1 书写规范18 5.2 常用数据库操作语句编码规范19 5.3 常用过程控制结构20 5.4 Condition 21 5.5 Cursor 22 5.6 变量定义与赋值22 5.7 过程与函数调用23 5.8 例外处理(Exception) 23 5.9 例外处理的错误消息24 5.10 注释(Comment) 25 5.11 应用调试控制27 5.12 并发控制27 5.13 代码测试、维护29 1 概述 1.1 编写目的 为规范软件开发人员的Oracle数据库开发提供参考依据和统一标准。 1.2 文档约定 说明本文档中所用到的专用术语定义或解释，缩略词定义。 1.3 预期的读者和阅读建议 本文档适用于所有开发员。 1.4 参考文献 列出有关的参考文件，如： a．属于本项目的其他已发表文件； b．本文件中各处引用的文档资料。 列出这些文件的标题、作者，说明能够得到这些文件资料的来源。 2 数据库对象命名 2.1 命名总体原则 本规范所涉及数据库对象主要是指表、视图、同义词、索引、序列、存储过程、函数、触发器等； 命名应使用富有意义的英文词汇，尽量避免使用缩写，多个单词组成的，中间以下划线分割；避免使用Oracle的保留字或关键字，如LEVEL和TYPE； 各表之间相关列名尽量同名； 除数据库模式对象名称长度为1－8个字符，其余对象名称均要求不超过30个字符； 命名只能使用大写英文字母，数字和下划线，且以英文字母开头。 2.2 表名 规则：XXX_MMM_DDDD 说明：XXX代表子系统或模块名称（2-3个字母构成）； MMM代表子模块名称（2-3个字母构成，根据实际情况可以没有）； DDDD为表的简称含义，使用英文单词或词组构成，可包括下划线，但不得使用汉语拼音。 示例：PO_HEADERS_ALL 2.3 视图 规则：XXX_MMM_DDDD_V 说明：XXX代表子系统或模块名称（2-3个字母构成）；
城市公共基础数据库建设方案.
城市基础数据库系统建设方案
1.系统概述 长期以来，政府各部门内部拥有着大量城市基础数据资源，但由于管理分散，制度规范不健全，造成重复采集、口径多乱、数出多门；各部门的指标数据自成体系，标准不一，共享程度较差。随着政府向“经济调节、市场监管、社会管理和公共服务”管理职能的转变，就要求必须能够全面、准确掌握全地区经济社会发展态势，强化政府部门掌控决策信息资源的能力，政府部门间信息资源整合与共享需求越来越紧密，但当前部门间信息共享多是点对点方式，没有统一的数据交换管理平台。因此各部门对加快解决数据资源分散管理、数据共享不足的问题需求十分迫切，需要建立城市基础数据库（以下简称智慧城市公共基础数据库）系统以解决以上问题。 依托智慧城市公共基础数据库系统的建设，可以实现各委办局、各所辖地区的经济社会综合数据采集交换，为各部门提供更广泛的信息共享支持，一方面数据信息从各委办局、各所辖地区整合接入，另一方面也为政府和这些接入部门提供全面的共享服务。同时，以智慧城市公共基础数据库指标体系建立为基础，整合来自各委办局和各所辖地区的、经过审核转换处理的数据资源，可实现对经济社会信息的统一和集中存储，确保数据的唯一性和准确性，为今后政府工作提供一致的基础数据支持。 数据整合共享只是手段，数据分析服务才是目的。依托智慧城市公共基础数据库系统建设，可有效整合各政府部门所掌握的全市经济社会信息资源，满足政府业务对统一数据资源共享需要，进而提升形势分析预测水平，对政府在发展规划、投资布局、资源环境、管理创新、科学决策等业务提供强有力支持，提高了政府部门掌控全市经济社会发展态势能力。 2.建设目标 1）建立科学合理的智慧城市公共基础数据库指标体系，力求全面反映地区经济和社会发展的总体情况： 2）有组织、有计划、持续地对政府统计部门、政府各部门以及国民经济行业管理部门负责统计的关系到地区经济与社会发展的信息资源进行收集、整合，
数据库建设规范
数据库建设规范 目录 1. 前言 2 2. 范围 3 3. 术语和定义3 范式3 关联3 关系模型 3 视图3 外键3 约束3 主键4 4. 命名规范 4 规范约定 4 表名4 视图4 存储过程 4 函数4 触发器 5 字段5 索引5 5. 数据库建设过程规范 5
概述5 需求分析阶段 6 需求调查 6 内容分析 6 概念结构设计阶段7 定义实体 7 定义关系 7 定义属性 7 定义键8 定义索引 8 定义其他对象和规则9 逻辑结构设计阶段9 数据库物理设计阶段10 实施、运行、维护规范11 6. 数据库建设安全性规范11 概述12 完整性设计12 物理安全 14 访问控制 14 数据备份 15 前言
数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 本规范通过数据建库的命名、结构、建库过程及安全性措施等几个技术方面进行约定，目的就是提供一套规范、合理、科学的建库技术体系，应用系统提供建库技术参考。 范围 本规范主要从关系数据库的命名、关系和结构以及建设过程等几个方面来规定数据库设计应遵循的规范。 术语和定义 范式 关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称1NF。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。 关联 关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多三种关联形式。 关系模型 关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在 关系模型中，实体与实体间的联系都是用关系来表示的。 视图 视图是一个定制的虚拟表。可以是本地的、远程的或带参数的；其数据可以 来源于一个或多个表，或者其他视图；它是可更新的，可以引用远程表；它可以 更新数据源。视图是基于数据库的，因此，创建视图的前必须有数据库。 外键 外键是一个关系中的一组属性（一个或多个列），它同时也是某种（相同的 或其它的）关系中的主键。它是关系之间的逻辑链接。 约束
Greenplum数据库设计开发规范
G r e e n p l u m数据库设 计开发规范 集团企业公司编码：（LL3698-KKI1269-TM2483-LUI12689-ITT289-
目录
第一章前言 1.1文档目的 随着Greenplum数据库的正式上线使用。为了保证Greenplum 数据仓库系统平台的平稳运行，保证系统的可靠性、稳定性、可维护性和高性能。特制定本开发规范，以规范基于Greenplum数据库平台的相关应用开发，提高开发质量。 1.2预期读者 Greenplum数据仓库平台应用的设计与开发人员； Greenplum 数据仓库平台的系统管理人员和数据库管理员； Greenplum 数据仓库平台的运行维护人员； 1.3参考资料 参考Greenplum4.3.x版本官方指引： 《GPDB43AdminGuide.pdf》 《GPDB43RefGuide.pdf》 《GPDB43UtilityGuide.pdf》
第二章设计规范 2.1数据库对象数量 数据库对象类型包括数据表、视图、函数、序列、索引等等，在Greenplum数据库中，系统元数据同时保存在Master 服务器和Segment 服务器上，过多的数据库对象会造成系统元数据的膨胀，而过多的系统元数据造成系统运行逐步变慢；同时，类似数据库的备份、恢复、扩容等较大型的操作都导致效率变慢。因此，依据GreenplumDB产品的最佳时间，单个数据库的对象数量，应控制在10万以内。 GP数据库的对象包括：表、视图、索引、分区子表、外部表等。 如果数据表的数量太多，建议按应用域进行分库，尽量将单个数据库的表数量控制在10万以内，可以在一个集群中创建多个数据库。 【备注】：在Greenplum数据库中，一张分区表，在数据库中存储为一张父表、每张分区子表都是一张独立的库表；例如：一张按月进行分区的存储一年数据的表，如果含默认分区，共14张表。 2.2表创建规范 为了避免数据库表数量太多，避免单个数据表的数据量过大，给系统的运行和使用带来困难，在Greenplum数据库中需遵循如下的表创建规范： 1、GP系统表中保存的表名称都是以小写保存。通常SQL语句中表名对大小写不敏感。但不允许在建表语句中使用双引号（“”）包括表
天然林保护工程基础数据库内容规范
天然林保护工程基础数据库内容规范 1 主题内容与适用范围 本标准给出了国家天然林保护工程（以下简称天然林保护工程）数据的组织和结构，包括5 个数据集：工程本底数据、工程建设数据集、资金情况数据集、人员分流数据集、其他数据集。给出了天然林保护工程数据集、数据表、数据项的命名。适用于林业科学数据共享中天然林保护工程数据的组织和管理。 2 编制依据 本技术规范参考了以下技术资料。国家林业局《国家森林资源连续清查主要技术规定》 （1994）；国家林业局《森林资源规划设计调查主要技术规定》（2002 年6月征求意见《数字林业标准与规范》（一）；国家林业局《林业统计年鉴》 3 术语和定义 天然林保护工程the program on natural forest protection 天然林保护工程以从根本上遏制生态环境恶化，保护生物多样性，促进社会、经济的可持续发展为宗旨；以对天然林的重新分类和区划，调整森林资源经营方向，促进天然林资源的保护、培育和发展为措施，以维护和改善生态环境，满足社会和国民经济发展对林产品的需求为根本目的。工程总投入1064 亿元。工程范围初步确定为云南省、四川省、重庆市、贵州省、湖南省、湖北省、江西省、山西省、陕西省、甘肃省、青海省、宁夏回族自治区、新疆维吾尔自治区（含生产建设兵团）、内蒙古自治区、吉林省、黑龙江省（含大兴安岭）、海南省、河南省等18 个省（区、市）的重点国有森工企业及长江、黄河中上游等地区生态地位重要的地方森工企业、采育场和以采伐天然林为经济支柱的国有林业局（场）、集体林场。
4天然林保护数据数据组织和结构 4.1层次结构 天然林保护工程数据包括5个数据集：工程本底数据、工程建设数据集、资 金情况数据集、人员分流数据集、其他数据集。数据组织和结构图如图 4.1。 图4.1天然林保护工程数据组织和层次 4.2区域层次和时间序列 天然林保护工程数据按照区域层次和时间序列进行组织。其结构如图 4.2 所示。 图4.2数据的区域层次和时间序列 5天然林保护数据库内容结构标准 5.1数据库组织和命名 数据库的组织遵循数据库建库标准”，按照数据库、数据集、数据表的方 式进行。其命名遵循森林资源非空间数据库命名遵循数据库建库标准”(DF
数据库设计规范
1概述 1.1 目的 软件研发数据库设计规范作为数据库设计的操作规范， 详细描述了数据库设计过程及结果，用于指导系统设计人员 正确理解和开展数据库设计。 1.2 适用范围 1.3 术语定义 DBMS：数据库管理系统，常用的商业 DBMS有 Oracle, SQL Server, DB2 等。 数据库设计：数据库设计是在给定的应用场景下，构造 适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体- 关系 (Entity-RelationShip, 简称 E-R) 理论为基础，并对这一理论进 行了扩充。它从用户的观点出发对信息进行建模，主要 用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用 Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产 品支持的数据模型，如关系模型，形成数据库逻辑模式。可
以用 Sybase PowerDesigner工具直接建立逻辑数据模型 （ LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用 Sybase PowerDesigner 工具直接建立物理数据模型（ PDM），或者通过 CDM / LDM 转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应 用系统的性能要求。 紧凑性：例如能用 char(10) 的就不要用 char(20) ，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容
MySQL数据库开发规范精编WORD版
M y S Q L数据库开发规 范精编W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】
平安金融科技数据库（MySQL）开发规范 作者: 简朝阳 Last Updated: 25/02/14 19:30:18 历史修订记录： 修订时间修订内容 版本修订人 1.0 1.1李海军2013-03-11增加部分说明及修改 1.2李海军2013-07-29增加连接池使用说明和memory引擎的控制 增加了char类型，修改了timestamp的使用 1.3李海军2014-02-25 场合。 说明 本规范包含平安金融科技使用 MySQL 数据库时所需要遵循的所有对象设计（数据库，表，字段），所需要遵循的命名，对象设计，SQL 编写等的规范约定。 所有内容都为必须严格执行的项目，执行过程中有任何疑问，请联系 DBA Team 取得帮助。
概述 禁止明文传播数据库帐号和密码。 禁止开发工程师通过应用帐号登录生产数据库。 禁止应用在服务器安装MySQL客户端（可以安装开发包）。 禁止开发人员在SQL中添加 Hint，Hint只能由DBA审核后添加。 禁止使用悲观锁定，即读锁select … for update。 禁止在开发代码中使用DDL语句，比如 truncate，alter table … 等。 禁止DML语句的where条件中包含恒真条件（如：1=1）。 1. 命名规范 总则 数据库对象名仅可包含小写英文字母、数字、下划线（_）三类字符，并以英文字母开头。 数据库对象命名禁止使用MySQL保留字。 多个单词之间用下划线（_）分隔。 对象名称长度若超过限制，则使用简写/缩写命名。 1.1. 数据库命名 数据库以"db_"前缀 + "站点名_"前缀及其所服务的应用名称命名。
数据库建设规范.doc
v1.0可编辑可修改 数据库建设规范 目录 1.前言 (3) 2.范围 (3) 3.术语和定义 (3) 范式 (3) 关联 (3) 关系模型 (3) 视图 (4) 外键 (4) 约束 (4) 主键 (4) 4.命名规范 (4) 规范约定 (4) 表名 (5) 视图 (5) 存储过程 (5) 函数 (5) 触发器 (5) 字段 (6) 索引 (6)
v1.0可编辑可修改 5.数据库建设过程规范. (6) 概述 (6) 需求分析阶段 (7) 需求调查 (7) 内容分析 (8) 概念结构设计阶段 (8) 定义实体 (8) 定义关系 (9) 定义属性 (9) 定义键 (9) 定义索引 (10) 定义其他对象和规则 (11) 逻辑结构设计阶段 (11) 数据库物理设计阶段 (12) 实施、运行、维护规范 (13) 6.数据库建设安全性规范. (14) 概述 (14) 完整性设计 (14) 物理安全 (17) 访问控制 (17) 数据备份 (18)
1.前言 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境， 构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 本规范通过数据建库的命名、结构、建库过程及安全性措施等几个技术方面进行约定， 目的就是提供一套规范、合理、科学的建库技术体系，应用系统提供建库技术参考。 2.范围 本规范主要从关系数据库的命名、关系和结构以及建设过程等几个方面来规定数据库设计应遵循的规范。 3.术语和定义 范式 关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称 1NF。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。 关联 关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间 和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多三种关联形式。 关系模型 关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在