主题数据库建设规范(参考)
项目编号INFO-115-C01
文档编号TR-REC-01中国科学院数据应用环境建设与服务
主题数据库建设规范
（征求意见稿）
（2009.06.19完善版）
中国科学院计算机网络信息中心科学数据中心
2009年6月
目录
1适用范围 (1)
2术语与定义 (1)
3主题数据库基本要求 (2)
4总体架构 (3)
5内容组织 (4)
5.1数据库类型约定 (5)
5.2概念体系 (5)
5.2.1概念体系的要求 (7)
5.2.2概念体系的构造方法 (7)
5.2.3概念体系和概念树的表达 (7)
5.3逻辑数据库 (9)
5.3.1逻辑数据库的要求 (11)
5.3.2逻辑数据库的构建 (11)
5.4物理数据组织 (13)
5.4.1专业库内容整理 (14)
5.4.2建立映射转换规则 (14)
5.5元数据 (15)
5.5.1非关系型数据对象的元数据 (15)
5.5.2专业库的元数据 (16)
5.5.3逻辑数据库的元数据 (16)
5.5.4主题数据库的元数据 (17)
6技术架构和接口规范 (18)
6.1专业库 (19)
6.1.1功能要求 (19)
6.1.2应用系统与工具要求 (19)
6.1.3接口规范 (20)
6.2主题数据库 (21)
6.2.1功能要求 (21)
6.2.3接口规范 (23)
6.3数据中心 (26)
6.3.1功能要求 (26)
6.3.2应用系统与工具 (27)
6.3.3接口规范 (27)
6.4接口格式要求 (29)
6.4.1通用格式定义 (29)
6.4.2开放接口的安全性要求 (30)
7服务 (31)
7.1服务对象 (31)
7.2服务方式与要求 (31)
7.2.1在线发布方式 (32)
7.2.2离线发布方式 (33)
7.3数据交换格式 (33)
7.4共享分级分类设置 (33)
7.5其他服务要求 (33)
7.6服务案例 (34)
8运行维护 (35)
8.1运维人员 (35)
8.2基础运行环境 (35)
8.2.1机房 (35)
8.2.2互联网接入环境 (36)
8.2.3网络服务器与存储设备 (36)
8.3运行 (36)
8.3.1运行模式 (36)
8.3.2日志管理 (36)
8.4安全保障和故障处理 (38)
8.4.1基础设施安全 (38)
8.4.2软件安全 (38)
8.4.4非技术防护措施 (39)
8.4.5故障处理 (39)
8.5备份和恢复 (40)
8.6主题数据库的质量 (40)
附录A（规范性附录）标准实施一致性测试 (42)
A.1内容组织 (42)
A.1.1数据集名称及标识符 (42)
A.1.2概念体系 (43)
A.1.3逻辑数据库 (43)
A.1.4物理数据组织 (43)
A.1.5关系型数据集 (43)
A.1.6非关系型数据对象 (44)
A.2技术架构与接口规范 (44)
A.3服务 (44)
A.4共享 (45)
A.5运行维护 (45)
A.6主题数据库质量 (45)
主题数据库建设规范
1适用范围
本规范定义了主题数据库的总体架构，规定了主题数据库在内容组织、技术实现方面需要完成的工作和需要满足的要求，并提出了对主题数据库在运行维护和服务方面的要求。
本规范适用于中国科学院数据应用环境建设与服务项目中主题数据库的建设。
2术语与定义
2.1主题数据库
面向特定学科或应用领域，由若干逻辑相关的数据资源按照统一的标准规范整合形成，具有系统性和完整性，并通过统一的系统提供一站式服务的数据库。
2.2概念体系
依据一定的知识结构组织起来的一个概念集合，其中的每个概念反映一定范围内的某些数据资源所具有的共同属性（或特征）。
2.3概念树
在概念体系的基础上建立起来的一个树状的（即依照层次、等级逐步展开的）、用于数据资源目录浏览式查询的知识编码结构。概念体系范围内的每一种内容或特征的数据资源，都可以在这一概念树中具有相应的位置；用户可以通过这一概念树，查检所需要的数据资源。
2.4逻辑数据库
将分布在一个或多个专业库中的、具有相同内容特征的数据整合形成的数据库，它可以是物理的，也可以是逻辑的。
若被整合的数据分布在不同的专业库中，它们通常是异构的，或者描述了同类实体在不同方面的属性。逻辑数据库的数据模型是在对这些数据进行分析的基础上为这些数据所描述的事物规定一个统一的数据模型，不同专业库中的相关数据可以通过一定的转换达到与该数据模型相符。
2.5索引库
按照逻辑数据库对检索服务及其结果概要显示的需求和设计，通过抽取和转换专业库中
有关数据形成的数据库。索引库中除包含用于被整合数据的统一检索和概要显示的字段外，还必须包含指针字段，用于存储被整合数据的访问地址。
2.6元数据
描述数据及其环境的数据。
在主题数据库系统中，元数据主要支持以下五类系统管理功能：
●描述主题数据库的内容；
●定义被整合进入主题数据库的数据和主题数据库整合形成的数据；
●记录数据整合形成的映射转换机理；
●集中管理数据集成使用的物理参数；
●客观详实记录数据质量相关活动。
3主题数据库基本要求
主题数据库建设过程中，应采用“数据应用环境建设与服务”项目发布的有关标准规范，以及相关的国家标准、国际标准、学科领域标准规范或其应用方案，完成资源体系的规划、概念体系的构建、数据库公共模式的确定，以及数据资源的加工、整理或增建；主题数据库在实现用户统一管理、认证和访问控制的基础上，为用户提供统一的服务系统，提供一站式服务。其间应特别实现以下基本要求：
1.主题数据库具有合理的概念体系，能够正确反应该主题领域内数据的有关知识及知
识之间的关系，并基于该体系形成结构合理、层次清晰的多级（三级以上）概念树。
2.根据数据资源内容特征及内容特征之间的关系将专业库合理地重新组织成若干逻
辑数据库，基于逻辑数据库的公共数据模型实现资源的加工、整合和增建，并组织
为相应概念树叶子节点的内容。基于逻辑数据库检索字段及其内容建立集中的索引
库，同时建立包括系统元数据、核心元数据和领域元数据的元数据库，并注册到数
据中心门户系统。
3.建立统一的主题数据库服务系统，为用户提供一站式服务。
a)主题数据库服务系统具有与概念树结构一致的资源导航目录，为用户提供目录
浏览式数据资源查询服务。
b)主题数据库服务系统具有统一的用户管理、认证和访问控制，保证用户在登陆
后能够在整个系统内自由获取与其身份一致的服务，无需再次登陆或身份认
证。
c)主题数据库服务系统基于元数据提供对数据资源的直接访问，用户获取服务时
感觉不到跨网站或系统的物理跳转，获得数据的过程与模式在系统内是完全一
样的，并具有相同的数据展示风格。
4.对数据中心门户系统开放符合规范的接口，以支持通过数据中心门户系统实现对数
据资源的访问。
上述主题数据库建设基本要求，是本规范关于内容组织、技术架构和接口规范、运维与服务等具体内容的概括，所有基本要求的满足情况可以通过本规范附录A“标准实施一致性测试”确认。
4总体架构
主题数据库基于给定学科或应用领域内数据资源的相关性，通过从分布式物理层数据到集中式逻辑层数据的映射转换和内容组织实现异构数据的有机整合，并通过主题数据库门户为用户提供一站式资源发现和访问服务，支持领域内研究人员对这些数据的应用需求。主题数据库的服务还应集成到数据中心门户系统，以便用户通过数据中心门户系统统一发现和访问到主题数据库服务系统中所有的资源。
并研制每个类目下数据应共同遵守的公共数据模型，而专业库的内容均据此进行组织，并参照公共数据模型整理和关联，实现域内数据资源内容层面跨越不同建设者、所有者、管理者的集成整合。
主题数据库的建设技术为主题数据库的内容组织提供了实现支持，是主题数据库建设的技术保障。建库技术主要为主题数据库的实现提供异构数据资源整合、数据管理与服务、元数据的生成和管理、用户认证与授权、服务监控以及专业库、主题数据库、数据中心三者之间的信息交互与通信等方面的支持，保证专业库建设单位、主题数据库牵头承建单位以及数据中心三个层面资源整合、任务目标和服务功能的实现。
运维和服务是保障建成的主题数据库发挥出其价值的重要工作。通过机制、环境、人员等在安全保障和故障处理、备份和恢复、数据更新等方面的高水平运维，以保证主题数据库正常稳定的对外服务，且服务过程中应紧密结合资源特点配置支撑队伍，特别应面向领域内关键项目的需求提供定向的数据服务支持。
5内容组织
主题数据库面向给定的学科或应用领域，根据领域科研人员所共同认可的概念体系组织主题数据库，并归纳每个类目之下数据应共同遵守的公共数据模型。主题数据库内专业库的内容按此架构分门别类，并参照公共数据模型整理和关联，从而达成主题域内数据资源内容层面跨越不同建设者、所有者、管理者的集成整合。
主题数据库内容组织包括概念组织、逻辑数据和物理数据三个层次：
●概念组织层：按照领域内科研人员的共识构建概念体系，实现对主题数据库内数据
资源的顶层组织。概念体系由一组概念和概念之间的关系组成，每个概念表达明确
的涵义。一般而言，基于概念体系构建的概念树的根节点对应于主题数据库，而叶
子节点对应于逻辑数据库。
●逻辑数据层：每个逻辑数据库整合主题数据库内的同类数据资源，无论它们原本以
什么形式保存在什么地方。逻辑数据库根据专业库的共性内容（对于非关系型数据
对象而言，应为其元数据的共性内容）建立公共模型，并基于映射关系实现专业库
内容的获取，从而达成不同来源的数据资源的集成。
●物理数据层：物理数据层承担存储与提供实际数据的职能，由一系列内容相关的专
业库构成，这组资源可能根据内容要求进行了规范化加工整理，并通过与逻辑数据
库的映射转换规则建立联系。
5.1数据库类型约定
主题数据库管理的科学数据类型各异，各有特色。为便于阐述，本规范将专业库归纳为以下两个类型：
●关系型数据库：建立在关系模型基础上的数据库。
●非关系型数据对象：不可关系化的数据，如文件型数据，文档等。
本规范列举之条款，无特别注明的，可同时适用于关系型数据库和非关系型数据对象两种类型，专门针对关系型数据库（或非关系型数据对象）的内容均在章节前加以注明，非关系型数据对象（或关系型数据库）可不必遵守，读者在阅读过程中请加以区别。
主题数据库的数据形式应有正确合理的选择，一般而言应符合学科领域常用的主流数据格式，在满足这一原则的前提下，因关系型数据库的整合深入程度高于非关系型数据对象，在能使用关系型数据库管理的场合应尽可能使用关系型数据库进行管理。
5.2概念体系
主题数据库按照领域内科研人员的共识构建概念体系，实现对主题数据库内数据资源的顶层组织和索引。概念体系按照编制形式，可以分为等级列举式、分面组配式和列举组配式三种。
等级列举式概念体系将所有的概念组织成一个树状结构，按照划分的等次，逐级列出详尽的子概念。在这种概念体系中，同一分支的同层级概念之间构成并列关系，而不同层级概念之间构成上下位关系。例如，国标GB/T13745《学科分类与代码》、用于图书分类的《中国图书馆图书分类法》，都是等级列举式概念体系。
分面组配式概念体系依据分析兼综合的原则构建，放弃了详尽列举的做法，代之以简单概念组配形成复杂概念的方式。其基本思想是任何复杂概念都可以分解为若干基本概念；同时，它们也可以通过相应基本概念的组合加以表达。根据这一点，分面组配式概念体系在编制时，只需要按照范畴列出各种基本概念，而在使用时，根据对数据资源的分析结果，通过
相应概念的组配表达数据资源的主题内容。例如，可以根据美术作品涉及的特征，将“美术作品”这一概念分解为以下表所示的分面，按范畴设置基本概念，而在标引某一具体美术作品时，将不同分面中的有关概念进行组配，即可标示出对该作品主题内容的分析结果。
地区分面体裁分面时代分面题材分面
E1中国D1油画C1古代B1人物
E2英国D2水彩画C2近代B2山水
E3法国D3水墨画C3现代B3花鸟
E4德国D4素描C4当代B4静物……………………
列举组配式概念体系是一种在概念等级列举的基础上，广泛采用各种分面组配方法的概念体系，也可称为混合式概念体系。
在上述三种概念体系中，等级列举式概念体系是使用最普遍的。对于主题数据库而言，如果所构建的概念体系是等级列举式的，那么，可以将之直接作为本规范所要求的概念树使用；而如果所构建的概念体系是分面组配式的或者列举组配式的，那么，需要在概念体系的基础上构建出等级式层层展开的概念树，以支持主题数据库服务系统中数据资源目录浏览式查询服务的实现。
对于等级列举式概念体系，为了将其编制得系统、简练，同时又达到概念详尽划分的目的，允许在其中使用共性区分表。在概念体系展开时，不少概念的进一步划分往往采用相同的划分标准，并得到相同的子概念。例如，在生态学领域，在“陆地生态系统”概念下，可以区分出“森林生态系统”、“农田生态系统”、“草地生态系统”、“荒漠生态系统”等子概念，按照数据资源所针对的生态要素，上述每个子概念可进一步区分出相同的子概念：水、土、气、生、综合。可以将这些共性子概念抽出，单独编列成表，供有关概念进一步区分时使用。这种由共性子概念构成，供有关概念共同使用的表，称为共性区分表，也称为复分表、副表、辅助表。1
一般而言，主题数据库的概念体系是基于主题域内数据资源内容的内在特征建立起来的概念树，主题数据库中每一个逻辑数据库对应于概念树中的一个或多个节点并表达对应含义。通过构建主题数据库概念树可以实现对数据资源最基本的分类和导航，同时，借助于参照科学合理的概念体系组织数据可以有效提升数据资源对主题域知识覆盖的完整性、对相关概念的内容一致性。
概念树由一组节点和节点之间的关联关系组成。
节点：概念树的每个节点应表达一个明确的逻辑涵义；
根节点对应于主题数据库的主题概念；
叶子节点则一般对应于一个逻辑数据库粒度的概念。
1共性区分表实际上是分面组配的一种基本使用形式。在等级列举式概念体系中利用共性区分表处理共性区分问题的好处在于：缩小概念体系的篇幅；增强概念体系中有关概念划分的规律性。
●关联：树中每个节点可以存在父节点和子节点；
父子位节点之间的常见抽象主要包括分类、聚集和概括三种：
●分类：父节点是子节点的类型，子节点是父节点的对象，子节点对象具有
父节点描述的共同特性或行为；
●聚集：父节点由子节点组成，子节点是父节点的组成部分，是父节点的成
员；
●概括：父节点是子节点的超集，子节点是父节点的子集，概括具有继承性
特性，子类继承超类定义的所有抽象。
5.2.1概念体系的要求
主题数据库概念体系应满足以下条件：
●每个主题数据库至少应提供概念树，也可额外建立其他形式的概念体系；
●概念树应具有一定权威性，为领域内科研人员关于概念体系建设的共识性理解。对
此承建单位应在相关设计文档中提供佐证或依据；
●概念树应以尊重客观规律为主，其叶节点应该是对专业库内容的归纳而非简单的一
一对应；
●概念体系中每次分叉都应遵循相同的原则。
●概念体系确保主题数据库内容完整科学、且与具体应用无关。
5.2.2概念体系的构造方法
概念体系的构造有自顶向下和自底向上两种方式。
自顶向下方法从大的角度入手，复杂的大问题分解为相对简单的小问题，找出每个问题的关键、重点所在，然后用精确的思维定性、定量地去描述问题。其核心本质是"分解"。对于主题数据库概念体系而言就是，从主题数据库总体概念入手不断向下分解，直到全部概念都可落实为逻辑层数据库。
自底向上方法从数据资源入手，首先考虑可以归纳形成的逻辑层数据库有哪些，然后按照分类方法逐步进行“归约”，直至升华为主题数据库。
自顶向下和自底向上方法也可结合进行。
5.2.3概念体系和概念树的表达
主题数据库可以采取关系数据库、xml或者其他编码方式来表达其概念体系，为了保证每个主题数据库的概念体系能够为数据中心门户系统所识别，要求主题数据库在表达概念体系中的每个概念时，必须定义以下两个属性：
编码(id)每个概念的编码应具有唯一标识性，能够将其与概念体系中的其他概念相区分。
名称(title)
可选的属性包括：
引用共同区分表(usec)在等级列举式概念体系中，对于采用了共同区分表的概念，需要定义“引用共同区分表”这一属性
备注(note)
对于等级列举式概念体系，要求采用层累标记制为其概念编码，概念的编码应体现出每个概念在概念体系中所处的层级。编码规则如下：
●对于非共同区分表中的概念，其编码采用“.”分法表示出其在概念体系中所处的
等级。例如，使用“A”表示根节点，“A.01”、“A.02”、“A.03”、……表示根节点
下的一级子节点，“A.01.01”、“A.01.02”、“A.01.03”、……表示子节点“A.01”下
的二级子节点。
●共同区分表中的概念必须以“C”作为概念编码的第一个字符，且编码的第二个字
符应能够体现出其与哪些概念是属于同一共同区分表的，与哪些是属于不同共同区
分表的。例如，使用CA01、CA02、CA03、CA04、……作为一个共同区分表中包
含的概念的编码，使用CB01、CB02、CB03、……作为另一个共同区分表中包含
的概念的编码。
●非共同区分表中的概念的编码（这里特指去掉其上位概念的编码后的部分）不得以
“C”和“F”作为首字符。
对于分面组配式概念体系，要求的概念编码规则如下：
●以F作为每个概念编码的首字符，且每个概念的编码中不能使用“.”字符。
●对于每个分面中的概念，其编码的第二个字符应能够体现出其与哪些概念是属于同一分面的，与哪些是属于不同分面的。例如，FA001，FA002，FA003、……作为一个分面中包含的概念的编码，而FB001，FB002，FB003，FB004，……作为另一个分面中包含的概念的编码。
对于列举组配式概念体系，要求综合采用前面两种编码规则。对于非组配用概念，按照等级列举式概念体系编码规则编码，对于组配用概念，则按照分面组配式概念体系编码规则编码。
对于概念树而言，其中的两个节点即使具有相同的名称，但由于其所处位置的不同，其含义也将是不同的。要求概念树中每个节点的编码充分体现出其在书中所处的位置，也就是说，对于每个节点，其编码中都需要包含其上位节点的编码。具体编码方法如下：
●对于等级列举式概念体系基础上形成的概念树，由非共性区分表中的概念形成的节
点，其编码直接使用相应概念的编码；由共性区分表中的概念形成的节点，其编码
是上位节点的编码和相应概念的编码的合并，两者之间通过“.”连接。例如，在
前述共性区分表的举例中，“森林生态系统”、“农田生态系统”、“草地生态系统”、“荒漠生态系统”的编码分别是“A.003.001”、“A.003.002”、“A.003.003”、
“A.003.004”，由“水”、“土壤”、“气候”、“生物”、“综合”几个概念构成的共性
区分表中，各概念的编码分别是“CB001”、“CB002”、“CB003”、“CB004”和
“CB005”，那么，在概念树中，“森林生态系统”节点的编码还是“A.003.001”，
而其下的“水”子节点的编码是“A.003.001.CB001”，“土壤”子节点的编码是
“A.003.001.CB002”，依次类推。
●对于分面组配式概念体系基础上形成的概念树，每个节点的编码都是其上位节点的
编码和概念体系中相应概念的编码的合并，两者之间通过“.”连接。
●对于列举组配式概念体系基础上形成的概念树，综合使用上述两种编码方法。
主题数据库承建单位在创建了概念树并以某种计算机可解析和处理的方式保存和管理之后，必须在数据中心开发的资源与服务注册系统中进行注册，并开放符合6.2.3节“接口规范”的接口，以便概念体系从主题数据库服务系统向数据中心门户系统的同步。
主题数据库服务系统基于概念体系实现的数据资源目录浏览式查询服务，也必须在数据中心开发的资源与服务注册系统中进行注册。
5.3逻辑数据库
主题数据库中应包含若干个按照概念体系组织起来的逻辑数据库。每个逻辑数据库整合主题数据库中一组内容具有共性的数据，主题数据库通过归纳这些数据（对于非关系型数据对象的情况，是其元数据）的共性内容形成公共数据模型，并通过建立数据模型与专业数据库之间的映射关系形成关联，从而形成对同类数据在内容层面的整合集成。
这种整合不是对数据简单的物理聚集，而是通过整合后，数据可按具有统一模型的索引库进行联合检索或更深层次的整合应用，为用户提供统一的数据视图，使用户感觉就像使用单一的数据库一样。
图3逻辑数据库
逻辑数据库公共数据模型包含为了实现公共检索和概览而建立的各专业库应共同具备的数据集合。
●对于关系型数据库的情况，这组公共数据集是被整合各专业库数据内容的共有属
性；
●对于非关系型数据对象的情况，因为数据整合一般难以深入到数据文件内部，本规
范要求非关系型专业库先建立元数据库管理其数据文件，这个元数据库是关系型
的。逻辑数据库的公共数据集应是被整合非关系型专业库中的元数据库的共有属
性。关于非关系型专业库元数据的详细要求参见5.4.1“专业库内容整理”
图4非关系型数据集的逻辑数据库
索引库都是关系型的，按照公共数据模型约定的格式建立，并通过抽取专业库中对应的内容形成。
索引库可以利用专业库的系统元数据及专业库和逻辑数据库公共数据模型之间的映射信息自动抽取生成记录。
5.3.1逻辑数据库的要求
逻辑数据库应满足以下条件：
●主题数据库服务系统中必须建有索引库；
●每个逻辑数据库应对应于概念树中的一个或若干叶子节点；
●每个逻辑数据库必须建立逻辑数据库公共数据模型，如果专业领域内有内容相关的
标准规范，模型应遵循这些规范或对其提供良好的兼容性，承建单位提交相关文档
时应对数据的规范化情况有所分析；
●对于关系型数据库的情况，主要考虑遵照的是相关的数据标准或公约；
●对于非关系型数据对象的情况，主要应考虑遵照的是相关的元数据标准。
●主题数据库实现索引库与专业库内容的同步更新；
●索引库应向数据中心门户系统开放符合6.2.3节“接口规范”要求的接口；
●逻辑数据库原则上应该是若干专业库通过整合形成的，单个专业库直接作为逻辑数
据库必须满足以下条件：
●该专业库的结构完全符合逻辑数据库对应概念节点的应用要求；
●该专业库对主题数据库内同类资源的覆盖比较完整。
●对于关系型数据库的情况，索引库中除必须包含的公共索引字段内容外，还必须包
含访问专业库中完整数据记录的指针/地址
●对于非关系型数据对象的情况，索引库中除必须包含的公共索引字段内容外，还必
须包含访问专业库中完整数据记录或原始文件的指针/地址；
5.3.2逻辑数据库的构建
构建逻辑数据库在内容组织方面的核心工作是确定逻辑数据库的内容和建立索引库的公共数据模型。
5.3.2.1逻辑数据库内容确定
逻辑数据库的内容基于以下分析确定：
●逻辑数据库需求分析
由于主题数据库应用无关的特性，数据需求分析的主要内容包括：
◆相关的学科背景知识
◆数据内容已有的数据标准规范
◆相似的权威性数据库的内容分析
对于非关系型数据对象的情况，还应注重相关领域已有的元数据标准规范。
●专业库内容分析
确定专业库内容（对于非关系型数据对象的情况，是其元数据库内容）可以产生
共性的内容和范围，
内容确定是用户视角的分析，对于每个数据元素除了取舍以外，仅对数据元素在使用、处理和呈现方面的特性进行考虑。分析结果应形成如下表格：
元素名描述范例可检索概要
显示
备注
5.3.2.2逻辑数据库公共数据模型
逻辑数据库共同的内容确定后即可将这些内容建立关系，并纳入统一的公共数据模型。构建逻辑数据库的核心工作是建立良好的逻辑数据库公共数据模型。公共数据模型是逻辑数据库整合应用的基础。
逻辑数据库公共数据模型是按照逻辑数据库应用需求分析建立的部分数据的公共数据模型，所有参与整合的专业库（对于非关系型数据对象的情况，此处应为其元数据库）均需包含或通过加工转换可以得到符合该模型要求的数据内容。
公共数据模型的描述可以使用实体-关系模型、UML或者XML Schema等常用的建模语言。
逻辑数据库公共数据模型应具备如下特征
●公共数据模型的内容应有一定的丰富程度，
?对于关系型数据库的情况，至少应支持对逻辑数据库描述对象常用信息的公共
检索；
?对于非关系型数据对象的情况，至少应包含数据对象常用的公共元数据。
建模者认为条件具备的情况下可适当扩大公共数据模型的范围以谋求更多数据内
容的规范性；
●模型应为学科领域内的共识性内容，符合学科科研人员的表述习惯，使用常用的命
名，规则和度量方式等，若在该领域已存在相关内容的数据规范或元数据规范，建
议公共数据模型遵守这些规范或至少在结构上对其保持良好的兼容性；
●逻辑数据库公共数据模型不应针对某个特别的应用而设计；
●公共数据模型应具有良好的结构，一般而言应满足第三范式的要求，每个逻辑数据
库应有一定的规范性，如实体命名、属性命名规范等；
●公共数据模型不依赖于具体的系统实现，可以对不同数据库系统保存的资源数据库
提供兼容性。
公共数据模型分析
通常逻辑数据库公共数据模型的内容包括三个部分：数据结构、数据操作、数据约束。
●数据结构：主要描述数据的类型、内容、性质以及数据间的联系等。数据结构是数
据模型的基础，数据操作和约束都建立在数据结构上。不同的数据结构具有不同的
操作和约束。
●数据操作：主要描述在相应的数据结构上的操作类型和操作方式。
●数据约束：数据模型中的数据约束主要描述数据结构内数据间的语法、词义联系、
他们之间的制约和依存关系，以及数据动态变化的规则，以保证数据的正确、有效
和相容。
具体而言应包括以下内容：
●实体
●属性
●关系
●约束条件
公共数据模型的表达
分析工作完成的成果应体现为实体关系图和数据字典，数据字典如下：
数据字典
表名：ID：
字段名ID定义数据类型约束条件
表名：ID：
字段名ID定义数据类型约束条件
5.4物理数据组织
专业库通过与逻辑数据库的公共数据模型建立映射关系，不同专业库中的内容按照映射转换规则抽取形成符合公共数据模型的索引库，实现数据整合。主题数据库的数据在物理上不限制其存储方式，可以采用集中式存储也可以采用分布式存储。
主题数据库的数据内容组织主要包括专业库的内容整理和建立映射转换规则两个部分。
5.4.1专业库内容整理
专业库往往存在数据质量或结构方面的问题，因此需对专业库内的部分内容加以规整。数据内容整理的方法包括抽取、清洗、转换、规约等。
规范不强制要求每个专业库必须进行数据整理，以能否按照映射规则形成符合逻辑数据库填充率要求的内容为准。
此外，对于非关系型数据对象的情况，如果数据使用的格式不是学科领域常用的数据格式，承建单位应尽可能将其转化为常用的文件格式。
对于非关系型数据对象的情况，还应为专业库建立元数据库进行管理，这个元数据库应使用关系型数据库管理，元数据的描述粒度应为文件或文件集合，每条记录应包含访问文件（或文件集合）的指针/地址。非关系型数据对象元数据库内容的详细约定参见5.5.1“非关系型数据对象元数据”。
5.4.2建立映射转换规则
逻辑数据库公共数据模型建立以后，专业库应建立与公共数据模型之间的映射规则。
映射规则的建立包括两部分内容：映射关系的建立和转换规则的建立。
5.4.2.1映射关系
映射规则不是简单的对应关系，根据实际迁移的源和目的结构，还可能包含字段的拆分、合并等。专业库和逻辑数据库的映射关系具有层次结构，对于用实体关系模型表达的公共数据模型而言，映射体现在实体层面和属性层面。
●实体映射：按公共数据模型中实体的属性来源和拆分的情况，源表和目的表在数量
上可分为一对一映射，一对多映射，多对一映射，多对多映射。
●字段映射：关系可以分为3种，即直接映射、主键映射和外键映射。其中：主键映
射是为了保证专业库中主外键约束在逻辑数据库中被保留，外键映射是保证逻辑数
据库实体表中外键字段能够从专业库表中对应字段正确迁移。直接映射就是专业库
表中的字段直接映射到公共数据模型表中的字段上，不发生拆分、合并等运算。
●类型映射：数据类型在不同的实现方法当中存在不同的具体表达，类型映射的两端
可能是该实现方法下的一个数据类型，也可能是一个数据类型加格式约束。
5.4.2.2数据转换
数据从专业库（或其元数据库）中抽取出来往往不能直接对应到逻辑数据库当中，而需
要一系列的变换和运算。凡此类变换应对其详细的变换规则加以明确。数据转换的常见情况包括以下三类：
●字段类型转换：指含义相同的字段在转换过程中的字段类型发生了变化；
●合并：专业库中的多个字段，经过算术运算或逻辑运算后，形成主题数据库公共数
据模型中的一个字段。合并也可能包括字符型字段值的连接；
●拆分：是指专业库中一个字段经算术或逻辑运算后，对应到主题数据库公共数据模
型当中的多个字段，或该字段为字符型字段值拆分成若干个子串后，每个子串对应
于主题数据库公共数据模型当中的一个字段。
5.4.2.3映射转换的表达
每个映射关系都可以表达为一个来源、对象和生产式的三元组。
●对象：被映射端对象的集合，对象可以是基础层级（字段层面的，变量）的也可以
是基础层级对象组成的集合，如果存在非基础层级的对象，其映射规则最终应落实
到基础层级；
●来源：每个对象在源端对应的数据来源；
●生产式：源端的数据来源均可按照生产式进行加工，并形成符合目标端数据模型要
求的对象内容。
映射关系可按如下的表格建立说明：
映射ID对象标识来源生产式
5.5元数据
在本规范中，为了消除元数据概念的多义性，统一各个主题数据库的相关参建人员的认识，将元数据特别限定为：描述数据集及其环境特征的数据。
5.5.1非关系型数据对象的元数据
对于非关系型数据对象，对其组织管理有如下要求：
a)必须建立有元数据库来对非关系型数据对象进行管理，保证用户能够通过元数
据查找到相应的文件或文件集合。
b)可以用相同的元数据元素集描述的非关系型数据对象，使用同一个元数据库进
行管理。
c)所有的非关系型数据对象，必须有揭示其内容特征的元数据元素，同时必须包
含：
●唯一标识符
●访问地址
5.5.2专业库的元数据
在主题数据库服务系统中，应建立一个用来保存和管理专业库元数据的元数据库2。为专业库建立元数据的目的在于：对主题数据库整合集成的资源进行有效管理；与专业库和逻辑数据库公共数据模型之间映射适配器相配合，支持索引库的生成。
对于专业库，要求其元数据必须包含系统元数据和核心元数据：
1)系统元数据：主要描述专业库的有关连接信息，元数据元素包括：
●数据库连接主机IP
●端口号
●数据库名
●用户名
●密码
●Web Service服务地址
2)核心元数据：主要描述专业库的基本内容特征、外部特征和结构特征，符合核心元
数据规范的规定。专业库的核心元数据必须包含以下元数据元素：
●唯一标识符
●标题
●关键词
●摘要
●类型
●创建者
●URL
保存专业库元数据的元数据库必须向数据中心门户系统开放符合6.1.3节“接口规范”要求的接口，以便同步到数据中心门户系统。
5.5.3逻辑数据库的元数据
在主题数据库服务系统中，应建立一个保存和管理逻辑数据库元数据的元数据库3。为逻辑数据库建立元数据的目的在于：对逻辑数据库进行有效管理；与概念树配合，支持数据
2可以使用一个元数据库来保存和管理专业库的元数据及逻辑数据库的元数据。
3同2。
软件工程-数据库设计规范与命名规则
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： 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模型的步骤如下所示:
ORACLE数据库安全规范
数据库安全规范
1概述 1.1适用范围 本规范明确了Oracle数据库安全配置方面的基本要求。 1.2符号和缩略语 2 ORACLE安全配置要求 本规范所指的设备为ORACLE数据库。本规范提出的安全配置要求，在未特别说明的情况下，均适用于ORACLE数据库。 本规范从ORACLE数据库的认证授权功能和其它自身安全配置功能提出安全要求。 2.1账号 ORACLE应提供账号管理及认证授权功能，并应满足以下各项要求。 2.1.1按用户分配帐号
2.1.2删除或锁定无关帐号 2.1.3用户权限最小化 要求内容 在数据库权限配置能力内，根据用户的业务需要，配置其所需的最小权
限。
grant 权限 to user name; revoke 权限 from user name; 2、补充操作说明 用第一条命令给用户赋相应的最小权限 用第二条命令收回用户多余的权限 业务测试正常 4、检测操作 业务测试正常 5、补充说明 2.1.4使用ROLE 管理对象的权限 1. 使用Create Role 命令创建角色。 2.使用用Grant 命令将相应的系统、对象或 Role 的权限赋予应用用户。 2、补充操作说明 对应用用户不要赋予 DBA Role 或不必要的权限。 4、检测操作 1.以DBA 用户登陆到 sqlplus 中。 2.通过查询 dba_role_privs 、dba_sys_privs 和 dba_tab_privs 等视图来检查 是否使用ROLE 来管理对象权限。 5、补充说明 操作指南 1、参考配置操作 检测方法 3、判定条件 要求内容 使用数据库角色（ROLE ）来管理对象的权限。 操作指南 1、参考配置操作 检测方法 3、判定条件
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.专题数据库应用系统向数据中心提供访问完整数据记
系统界面设计规范
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。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
Oracle数据库安全配置规范华为
目录 1概述 (2) 1.1适用范围 (2) 1.2内部适用性说明 .......................................................................................................... 错误！未定义书签。 1.3外部引用说明 .............................................................................................................. 错误！未定义书签。 1.4术语和定义 .................................................................................................................. 错误！未定义书签。 1.5符号和缩略语 (2) 2ORACLE安全配置要求 (2) 2.1账号 (2) 2.2口令 (7) 2.3日志 (11) 2.4其他 (13)
1概述 1.1适用范围 本规范明确了Oracle数据库安全配置方面的基本要求。 1.2符号和缩略语 2ORACLE安全配置要求 本规范所指的设备为ORACLE数据库。本规范提出的安全配置要求，在未特别说明的情况下，均适用于ORACLE数据库。 本规范从ORACLE数据库的认证授权功能、安全日志功能，和其他自身安全配置功能提出安全要求。 2.1账号 ORACLE应提供账号管理及认证授权功能，并应满足以下各项要求。 2.1.1按用户分配帐号
数据库设计方法、规范与技巧
数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个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 第零步——初始化工程
Oracle数据库安全配置规范
Oracle数据库安全配置规范 1概述 1.1目的 本规范明确了oraclｅ数据库安全配置方面的基本要求。为了提高oｒacｌe数据库的安全性而提出的。 1.2范围 本规范适用于XＸXXＸ适用的oraｃle数据库版本。 2配置标准 2.1账号管理及认证授权 2.1.1按照用户分配账号 [目的]应按照用户分配账号，避免不同用户共享账号。 [具体配置] create user abc1 identifiｅd ｂｙｐasswoｒd1； crｅatｅｕser abc2 iｄentｉｆｉｅｄｂy password2; 建立role，并给role授权，把roｌe赋给不同的用户删除无关账号。 [检测操作]
2.1.2删除无用账号 [目的］应删除或锁定与数据库运行、维护等工作无关的账号。 [具体配置] aｌter user usernamｅｌock; dｒop user uｓername cａscａde; ［检测操作] 2.1.3限制DBＡ远程登入 ［目的]限制具备数据库超级管理员（SYSＤＢA）权限的用户远程登录。 [具体配置] 1.在spｆile中设置RＥMOTE_LOＧIN_PＡSSＷORDFIＬE=ＮＯNE来禁止 SYSDBA用户从远程登陆。 2.在sqlnet.orａ中设置SQLNET.AUTHＥＮＴICATIＯＮ_ＳＥRＶICES=NONE来 禁用SYSＤBA角色的自动登入。 [检测操作] 1.以Oraｃle用户登入到系统中。 2.以sｑlpｌｕｓ‘/asｓyｓdbａ’登入到sqlpｌｕs环境中。 3.使用shoｗｐarameter 命令来检查参数REMOTE＿ＬOGIN_PASSWORDFＩ ＬE是否设置为NＯNE。Show pａrametｅr REMOTE＿LOＧIN_ＰASSWORDF ＩLＥ
人口基础数据库建设规范
竭诚为您提供优质文档/双击可除人口基础数据库建设规范 篇一：全员人口数据库建设培训手册 入户调查———信息卡登记填写篇 以下几个率，我们各级检查中是要考核的，数据库的建设必须达到如下指标： 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。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。 关联 关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多三种关联形式。 关系模型 关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在 关系模型中，实体与实体间的联系都是用关系来表示的。 视图 视图是一个定制的虚拟表。可以是本地的、远程的或带参数的；其数据可以 来源于一个或多个表，或者其他视图；它是可更新的，可以引用远程表；它可以 更新数据源。视图是基于数据库的，因此，创建视图的前必须有数据库。 外键 外键是一个关系中的一组属性（一个或多个列），它同时也是某种（相同的 或其它的）关系中的主键。它是关系之间的逻辑链接。 约束
数据库运行管理规范
数据库运行管理规范 1总则 1.1为规范XX公司信息通信分公司（以下简称“公司”）信息系统的数据库管理和配置方法，保障信息系统稳定安全地运行，特制订本办法。 2适用范围 本规范中所定义的数据管理内容，特指存放在信息系统数据库中的数据，对于存放在其他介质的数据管理，参照相关管理办法执行。 3数据库管理员主要职责 3.1负责对数据库系统进行合理配置、测试、调整，最大限度地发挥设备资源优势。负责数据库的安全运行。 3.2负责定期对所管辖的数据库系统的配置进行可用性，可靠性，性能以及安全检查。 3.3负责定期对所管辖的数据库系统的可用性，可靠性，性能以及安全的配置方法进行修订和完善。 3.4负责对所管辖的数据库系统运行过程中出现的问题及时处理解决。 3.5负责对所管辖数据库系统的数据一致性和完整性，并协助应用开发人员、使用操作等相关人员做好相关的配置、检查等工作。 3.6负责做好数据库系统及数据的备份和恢复工作。 4数据库的日常管理工作 4.1每日的管理工作 4.1.1数据库管理员每天登录到服务器操作系统，进行如下检查工 作： (1)检查所有的数据库实例状态以及所有与数据库相关的后台进程。
(2)检查数据库网络的连通与否，比如查看监听器（listener）的状态、网络能否ping通其它的计算机、应用系统的客户端能否连通服务器等等。 (3)检查磁盘空间的使用情况。如果剩余的空间不足 20% ，需要删除不用的文件以释放空间。 (4)查看告警文件有无异常。 (5)根据数据库系统的特点，检查其它的日志文件中的内容，发现异常要及时加以处理。 (6)检查cpu、内存及IO等的状态。 4.2数据库管理的每月工作 (1)收集数据库的性能统计数据，检查高速缓存区命中率、资源争用等统计信息，若不理想，设法加以分析改善。 (2)检查数据对象存储空间碎片情况，必要时加以调整。 (3)比较分析数据库系统和操作系统的CPU，内存，网络，及硬盘的利用率，以此确定出近期将可能出现的资源争夺趋势，必要时加以调整，以避免系统资源的争夺，如果调整还达不到要求，须考虑增加新资源。 (4)检查每日数据库管理工作的执行情况，用户、数据对象存储空间增加删改的记录是否齐全，备份记录、维护记录是否齐全，不足的及时补上。 4.3数据库管理的每年工作 (1)逐项检查每日、每月数据库管理工作的执行情况。用户、数据对象存储空间增加删改的记录是否齐全，备份记录、维护记录是否齐全，不足的及时补上。 (2)对数据库系统运行的情况作出统计。 (3)分析运行状况资源消耗的趋势，作好新一年的计划。 5数据库的安全管理 5.1数据库环境安 5.1.1物理环境安全
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_"前缀 + "站点名_"前缀及其所服务的应用名称命名。