数据库建设规范
目录
1. 前言 (2)
2. 范围 (2)
3. 术语和定义 (2)
3.1范式 (2)
3.2关联 (2)
3.3关系模型 (2)
3.4视图 (3)
3.5外键 (3)
3.6约束 (3)
3.7主键 (3)
4. 命名规范 (3)
4.1规范约定 (3)
4.2表名 (4)
4.3视图 (4)
4.4存储过程 (4)
4.5函数 (4)
4.6触发器 (4)
4.7字段 (4)
4.8索引 (4)
5. 数据库建设过程规范 (5)
5.1概述 (5)
5.2需求分析阶段 (6)
5.2.1需求调查 (6)
5.2.2内容分析 (6)
5.3概念结构设计阶段 (6)
5.2.1定义实体 (7)
5.3.3定义关系 (7)
5.3.4定义属性 (7)
5.3.5定义键 (7)
5.3.6定义索引 (8)
5.3.7定义其他对象和规则 (8)
5.4逻辑结构设计阶段 (8)
5.5数据库物理设计阶段 (9)
5.6实施、运行、维护规范 (10)
6. 数据库建设安全性规范 (11)
6.1概述 (11)
6.2完整性设计 (11)
6.3物理安全 (13)
6.4访问控制 (13)
6.5数据备份 (14)
1. 前言
数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
本规范通过数据建库的命名、结构、建库过程及安全性措施等几个技术方面进行约定，目的就是提供一套规范、合理、科学的建库技术体系，应用系统提供建库技术参考。
2. 范围
本规范主要从关系数据库的命名、关系和结构以及建设过程等几个方面来规定数据库设计应遵循的规范。
3. 术语和定义
3.1范式
关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。满足最低要求的叫第一范式，简称 1NF。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。
3.2关联
关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多三种关联形式。
3.3关系模型
关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在
关系模型中，实体与实体间的联系都是用关系来表示的。
3.4视图
视图是一个定制的虚拟表。可以是本地的、远程的或带参数的；其数据可以
来源于一个或多个表，或者其他视图；它是可更新的，可以引用远程表；它可以
更新数据源。视图是基于数据库的，因此，创建视图的前必须有数据库。
3.5外键
外键是一个关系中的一组属性（一个或多个列），它同时也是某种（相同的
或其它的）关系中的主键。它是关系之间的逻辑链接。
3.6约束
数据库管理系统必须提供一种机制来检查数据库中的数据，看其是否满足语
义规定的条件，这些加在数据库数据之上的语义规范，称为约束。约束又可以分
为完整性约束、唯一性约束等。
3.7主键
每张表都应该包含相同的一个或一组字段，它们都是保存在表中的、每一条
记录的唯一标识，通常这些字段（即主键）需要在建立数据表时就设定并标记。
4. 命名规范
4.1规范约定
命名采用 26个英文字母（一律大写）和 0－9这十个自然数，加上下划线“_”
组成，共 63个字符，不能出现其他字符（注释除外）。
数据库对象包括表、视图、存储过程、函数、触发器、字段、数据库文档。
对象名字由前缀和实体名称组成，长度不超过 30个字符。前缀描述对象类型，
实体名称包括系统标识等信息尽量详尽描述实体的内容，不以数字或下划线开头，对象名称中的标识用下划线“_”进行分隔。其中“[]”内的内容表示是可选内容。
4.2表名
T_[<系统标识>_][<…….> _] <表标识>
如：T_NPCP_ORDER
4.3视图
V_ [<系统标识>_][<…….> _] <视图标识>
如：V_NPCP_ORDER
4.4存储过程
P_ [<系统标识>][<…….> _]<存储过程标识>[_<存储过程行为标识>] 如：P_NPCP_ORDER_ADD
4.5函数
F_ [<系统标识>_][<…….> _]<函数标识>[_<函数行为标识>]
如：F_NPCP_ORDER_ADD
4.6触发器
TR_ [<系统标识>][<表标识>_][<…….> _]<触发标识>
如：TR_NPCP_ORDER_ADD
4.7字段
[<外键表标识>_][<…….> _]<字段标识>
如：ORDER_ID
4.8索引
IN_[<系统标识>_][<表标识>_][<…….> _]<索引标识>
如：IN_NPCP_ORDER_NAME
5. 数据库建设过程规范
5.1概述
建库过程建议参考以下的建库流程如图 1所示。
需求分析阶段综合各科学数据用户的应用需求，形成规范的需求调查表、需求规格书、功能需求表。
概念设计阶段形成独立于机器特点、独立于各个数据库管理系统产品的概念模式，用E-R图来描述。
逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图形成数据的外模式。
数据可以分为两大类：关系数据和非关系数据，在物理设计阶段根据数据库管理系统的特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
最后进行数据（或元数据）录入。建库过程的每一步都是对其前一步
骤的检验，对于发现的错误或偏差需要进行及时的评估，并进行修正完善。对由
于数据库的设计而在应用当中的造成的不良影响及出现数据误差等现象进行修
缮、更新、完善。
图 1数据库建设过程
5.2需求分析阶段
需求分析阶段可以分为两个步骤：需求调查和内容分析。数据大概分为两类数据：关系型数据和非关系型数据（如文件，文档）。在需求分析阶段可以对这两种数据进行不同的处理和分析。
5.2.1需求调查
数据信息来源有以下几种方法，分析系统需求分析报告书，组织调查会，咨询业务专家。
非关系型数据要分析哪几类类型，如文件的格式。
5.2.2内容分析
需求收集和分析，结果得到数据字典描述的数据需求，数据流图描述的处理需求。
表1 数据字典规范模式
图2 数据流图的表达方式
5.3概念结构设计阶段
这个阶段的任务确定建模目标，开发建模计划，组织建模队伍，收集数据资源，制定约束和规范。
5.2.1定义实体
找出潜在的实体，形成初步实体表，然后再进行必要的调整。满足下述两条准则的事物，一般均可作为属性对待。
（1）作为“属性”，不能再具有需要描述的性质。“属性”必须是不可分的数据项，不能包含其他属性。
（2）“属性”不能与其他实体具有联系，即 E－R图中所表示的联系是实体之问的联系。
5.3.3定义关系
模型中只允许二元联系，n元联系必须定义为 n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。即在这一步工作中确定任意有关联的两个实体之间的关系类型。
5.3.4定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主键属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主键属性必须依赖于主键、整个主键、仅仅是主键。
5.3.5定义键
通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选键属性，以便唯一识别每个实体的实例，再从侯选键中确定主键。为了确定主键和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出 IDEF1X模型的键基视图，确定关系中的主键和外键等。键选择规范：
1)键设计原则：为关联字段创建外键;所有的键都必须唯一;避免使用复合键;外键
总是关联唯一的键字段。
2)使用系统生成的主键,设计数据库的时候采用系统生成的键作为主键，那么实际
控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
3)不要采用用户可编辑的字段作键(不让主键具有可更新性)在确定采用什么字段
作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可
编辑的字段作为键。
4)可选键有时可做主键,把可选键进一步用做主键，可以拥有建立强大索引的能力。
5.3.6定义索引
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可
以采用索引技术得到解决。
1）如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（或这
组）属性上建立索引（或组合索引）；
2）如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个
属性上建立索引；
3）如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这
个（或这组）属性上建立索引；
4）逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的
非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何
进行访问，还有这些访问是否主要用作读写。
5)大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它
们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
6)不要索引 MEMO(备注)字段，不要索引大型字段（有很多字符），这样作
会让索引占用太多的存储空间。
7)不要索引常用的小型表。不要为小型数据表设置任何键，假如它们经常
有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫
描表空间消耗更多的时间。
5.3.7定义其他对象和规则
定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发
器、存储过程、视图、角色、同义词、序列等对象信息。
最后形成的概念模型用 E-R图进行表示。
5.4逻辑结构设计阶段
将概念结构转换为某个数据库管理系统所支持的数据模型（例如关系模
型），并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构
的数据模型，然后选择最合适的数据库管理系统，形成数据库文档。
将 E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的
联系转化为关系模式。关系模型的逻辑结构是一组关系模式的集合。E-R图则
是由实体、实体的属性和实体之间的联系三个要素组成的。所以将 E-R图转换
为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模
式，这种转换要遵循如下规范原则：
1）一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的
标识对应关系模型的候选码。
2）一个 m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联
系本身的属性均转换为关系的属性。而关系模型的候选码为各实体标识的组合。
3）一个 1:n联系可以转换为一个独立的关系模式，也可以与 n端对应的关
系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的标识
以及联系本身的属性均转换为关系的属性，而关系的码为 n端实体的码。
4）一个 1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应
的关系模式合并。
5）三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元
联系相连的各实体的标识以及联系本身的属性均转换为关系的属性。而关系模型
的候选码为各实体码的组合。
6）同一实体集的实体间的联系，即自联系，也可按上述 1:1、1:n和 m:n三
种情况分别处理。
7）具有相同码的关系模式可合并。为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为 3NF的标准，即：表内的每一个值都只能被表达一次。表内的每一行都应该被唯一的标识（有唯一键）。表内不应该存储依赖于其他键的非键信息。
对所有的快捷方式、命名规范、限制和函数都要编制文档。采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。对数据库文档化，或者在数据库自身的内部或者单独建立文档。
为加快数据库设计速度，目前有很多数据库辅助工具（CASE工具），如Rational公司的Rational Rose，CA公司Erwin和Bpwin，Sybase公司的owerDesigner以及 Oracle公司的 Oracle Designer等。设计人员可根据需要选用相应的数据库设计建模工具。
5.5数据库物理设计阶段
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要
求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细
致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的数据库管理系统，主要是从定量
估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比
较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修
改设计。
规范规定，物理设计当中在遵循数据库设计范式的基础之上，规定科学数据
库建库时除数据库设计所遵循的范式外的一些适用规范：
1)所有数据记录都要有 ID序列字段，ID号由数据库自动生成，以标识记录。
2)所有记录都要有“更新时间”字段，记录标识数据更新情况。
3)对于主-明细表结构，设计对应的视图将两表连接用于查询。
4)可以取消主外键关联，通过对应的程序来维护数据一致性。
5)类别和状态的多选：多选分为必选（1..n）和可选（0..n）。如是必选，在设计时
要有说明，在程序实现中应有控制和检查。两个可选的类别或状态表可以合并为一
个表，再与引用此表的主表形成多对多的关系。
5.6实施、运行、维护规范
运用数据库管理系统提供的数据语言（例如 SQL）及其宿主语言（例如
JAVA），根据逻辑设计和物理设计的结果建科学数据库，编制与调试应用程序，
组织科学数据入库，并进行试运行。规范规定：SQL关键词全部大写，比如
SELECT,UPDATE,FROM,ORDER,BY等。
数据库实施主要包括以下工作：用 DDL定义数据库结构、组织数据入库、
编制与调试应用程序、数据库试运行。建立或者修订数据库之后，必须用用户新
输入的数据测试数据字段。
所有的sql语句要最进性能分析，和压力测试。并且需要提交测试报告。
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中
必须不断地对其进行评价、调整与修改，定期提交运行监测报告。包括：数据库
的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、
数据库的重组织和重构造。
6. 数据库建设安全性规范
6.1概述
随着数据库技术的不断进步，信息安全问题也日益突出，数据库的安全性也更加受到重视。建设科学数据库中，很多科学数据都是不可再现的，甚至是长期积累获得的成果，失不可得，因此科学数据的安全性显得尤为重要。
安全策略主要是维护科学数据信息的完整性、保密性和可用性。科学数据库的安全建设规范主要是物理安全、访问控制、数据备份等。同其它数据资源相同，科学数据库数据的安全威胁主要来自三个方面：非人为破坏，比如地震等；人为的非主动破坏，比如误操作；人为主动破坏，比如黑客入侵。对于非人为破坏，主要只能依靠定期备份或者热备份等，并在相隔物理距离外保护备份。本规范主要讨论对于人为破坏的安全性规范。
6.2完整性设计
1）完整性实现机制：
实体完整性：每个数据实体都要有主键，即每条数据记录都要有唯一标识以
区分不同记录。
父表中插入数据：父表中插入数据，要看有哪些受限条件，以及注意插入父
表数据时还有没有其他的辅助数据输入。如添加化学品数据基本信息时，要注意
其成分信息的添加和关联。
父表中更新数据：同样需要注意级联更新和受限条件的更新。
用户定义完整性：数据字段的可选性（是否非空）以及数据检查等。
2）用约束强制数据完整性
完整性约束条件作用的对象可以是关系、元组、列三种。其中列约束主要是
列的类型、取值范围、精度、排序等约束条件。元组的约束是元组中各个字段间
的联系的约束。关系的约束是若干元组间、关系集合上以及关系之间的联系的约
束。完整性约束条件涉及的这三类对象，其状态可以是静态的，也可以是动态的。
（1）静态列级约束
静态列级约束是对一个列的取值域的说明，这是最常用也最容易实现的一类
完整性约束，包括以下几方面：
。
。
。
,空值表示未定义或未知的值，它与零值和空格不同。有的列允许空值，
有的则不允许。
,例如关于列的排序说明，组合列等。
（2）静态元组约束
一个元组是由若干个列值组成的，静态元组约束就是规定元组的各个列之间
的约束关系。例如订货关系中包含发货量、订货量等列，规定发货量不得超过订
货量；又如教师关系中包含职称、工资等列，规定教授的工资不低于 1000元
（3）静态关系约束
在一个关系的各个元组之间或者若干关系之间常常存在各种联系或约束。常
见的静态关系约束有：
实体完整性约束和参照完整性约束：实体完整性约束和参照完整性约束是关系模型的两个极其重要的约束，称为关系的两个不变性。
统计约束。即字段值与关系中多个元组的统计值之间的约束关系。例如规定部门经理的工资不得高于本部门职工平均工资的 5倍，不得低于本部门职工平均工资的 2倍。这里，本部门职工的平均工资是一个统计值。
（4）动态列级约束
动态列级约束是修改列定义或列值时应满足的约束条件；包括下面两方面：
修改列定义时的约束，例如，将允许空值的列改为不允许空值时，如果该列目前已存在空值，则拒绝这种修改。
修改列值时的约束,修改列值有时需要参照其旧值，并且新旧值之间需要满足某种约束条件。例如，职工工资调整不得低于其原来工资，学生年龄只能增长等。
（5）动态元组约束
动态元组约束是指修改元组的值时元组中各个字段间需要满足某种约束条件。例如职工工资调整时新工资不得低于原工资＋工龄*1.5等。
（6）动态关系约束
动态关系约束是加在关系变化前后状态上的限制条件，例如事务一致性、原
子性等约束条件。
3）强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4）使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： 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适用范围 本规范明确了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）开发规范 作者: 简朝阳 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.采集对象包括社会调查、统计分析、案例集成、基础文献等一手数据和原始资料。 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.专题数据库应用系统向数据中心提供访问完整数据记
数据库设计和编码规范 Version
目录
简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。
6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：
目录 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数据库安全配置规范 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、数据库更新及时率（出生或者是四术发生变动时，
数据库是否及时变更，数据库中出生和四术的上报日期与实际的出生日期和实际避孕措施开始日期的变更不应超过三个月或者是更短日期，否则视为不及时） 以上各项指标的高低是关系到全员人口数据库建设成败与否的关键因素。 只有信息采集达到上述标准要求，才能为下一步全员录入奠定基础。 下面将全员人口信息采集步骤详细叙述如下： 一、全员人口数据库要求实现以房管人，内蒙采集规范对房屋的编码要求如下： 内蒙至村级编码示意图：（系统中已经固定编码） 村级至户级示意图：（小区至户未固定编码） 二、具体到平房或楼房中编码规则如下： 如图：这个平房小区共有三排： 第一排共一列，这一列有三院，一院大门向东开，一院里有三户人家，二院大门向南，院内有两户人家，三院有一户人家； 第二排共两列，第一列共一院，院内有两户人家，第二列共有两院，第一院有两户人家，第二院有一户人家； 第三排共一列，这一列有两院人家，第一院有两户，第二院有一户。 那么这个小区内的房屋编码依次为：
项目编号：××× 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.使用utf8mb4字符集 2.所有表、字段必须写清中文注释 3.金额字段禁止使用小数存储（单位：分） 4.禁止使用字段属性隐式转换（如：“WHERE ms_no = 1234”ms_no为字符串类型） 5.尽量不使用负向查询（NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等） 6.禁止使用外键，如有完整性约束，需要应用程序控制 7.禁止使用程序配置文件内的账号访问线上数据库 8.禁止非DBA对线上数据库进行写操作 9.开发、测试、线上环境分离 10.所以提交的SQL语句必须经过测试 11.禁止存储大文件或大照片 12.库名、表名、字段名：小写，下划线分割，不超过32个字符，必须见名知意，禁止拼 音英文混用 13.表必须有主键 14.必须把字段定义为NOT NULL并设置默认值 15.必须使用varchar（20）来存储手机号 16.单表索引控制在5个以内，单索引字段数不许超过5个 a)索引的使用。? b)(1) 尽量避免对索引列进行计算。如计算较多，请提请管理员建立函数索引。? c)(2) 尽量注意比较值与索引列数据类型的一致性。? d)(3) 对于复合索引，SQL语句必须使用主索引列? e)(4) 索引中，尽量避免使用NULL。? f)(5) 对于索引的比较，尽量避免使用NOT=（!=）? g)(6) 查询列和排序列与索引列次序保持一致 (7) 禁止在更新频繁、区分度不高（如：性别）的字段上建立索引 (8) 建立组合索引，必须把区分度高的字段放在前面 17.禁止使用SELECT * ，只获取必要的字段 18.禁止使用INSERT INTO t_xxx VALUES(xxx)，必须指定插入的列名 19.禁止在WHERE条件的属性上使用函数或表达式 20.禁止%开头的模糊查询 21.禁止使用OR条件 22.应用程序必须捕获SQL异常，并作出相应处理 23.逻辑删除代替物理删除 24.选择最有效的表名、查询条件顺序（从右到左） 25.减少访问数据库的次数 26.SQL中的关键字均使用大写字母，数据表最好起别名 27.查询条件中“>=”代替“>” 28.等号两边使用空格，逗号后使用空格 29.多表操作必须使用别名 30.整条语句必须写明注释，关键逻辑单独书写注释，说明算法、功能 a)注释风格：注释单独成行、放在语句前面。? b)(1) 应对不易理解的分支条件表达式加注释；? c)(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物理环境安全
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概述 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) ，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容
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_"前缀 + "站点名_"前缀及其所服务的应用名称命名。
版/次：2015.11.19 数据库管理规 编制：钱凌杰 审核： 批准： 分发号： XXX信息科技 2015年11月
目录 一、总则 (4) 二、适用围 (4) 三、数据库管理员主要职责 (4) 四、数据库的日常管理工作 (4) 4.1每日的管理工作 (4) 4.2数据库管理的每月工作 (5) 4.3数据库管理的每年工作 (5) 五、数据库的安全管理 (6) 5.1数据库环境安全 (6) 5.2数据库系统安装、启动与更新时的安全规定 (6) 5.3安全和口令策略 (7) 5.4访问控制 (9) 5.5紧急事故的处理 (9) 5.6数据库文件管理 (10) 5.7数据库安全管理 (10) 六、备份与恢复 (10) 6.1备份方式及策略 (11) 6.2备份要求 (11) 6.3恢复的管理 (12) 6.4对长期保存的备份进行校验 (13) 6.5异地容灾备份 (13) 七、日志及监控审计 (13) 7.1审计围 (13) 7.2日志保存 (13) 7.3日志访问 (14) 7.4安全审计 (14) 八、数据存放、归档管理 (14) 九、附则 (15)
一、总则 为规XXX信息科技（以下简称“公司”）信息系统的数据库管理和配置方法，保障信息系统稳定安全地运行，特制订本办法。 二、适用围 本规中所定义的数据管理容，特指存放在信息系统数据库中的数据，对于存放在其他介质的数据管理，参照相关管理办法执行。 三、数据库管理员主要职责 1、负责对数据库系统进行合理配置、测试、调整，最大限度地发挥设备资源优势。负责数据库的安全运行。 2、负责定期对所管辖的数据库系统的配置进行可用性，可靠性，性能以及安全检查。 3、负责定期对所管辖的数据库系统的可用性，可靠性，性能以及安全的配置方法进行修订和完善。 4、负责对所管辖的数据库系统运行过程中出现的问题及时处理解决。 5、负责对所管辖数据库系统的数据一致性和完整性，并协助应用开发人员、使用操作等相关人员做好相关的配置、检查等工作。 6、负责做好数据库系统及数据的备份和恢复工作。
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。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。 关联 关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间 和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多三种关联形式。 关系模型 关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在
Sybase数据库安全配置规范
1.概述 1.1. 目的 本规范明确了Sybase数据库安全配置方面的基本要求。为了提高Sybase数据库的安全性而提出的。 1.2. 范围 本规范适用于XXXX使用的Sybase数据库版本。
2.配置标准 2.1. 通用安全设置 2.1.1.操作系统检查 【目的】检查Sybase安装目录的访问权限，保证只有系统管理员才能访问。 【具体配置】 改变Sybase注册表 KLM\Software\Sybase中的权限键值。 2.1.2.服务器信息 【目的】列举网路上的远程服务器。 【具体配置】 exec sp_helpserver 检查输出内容： 网络密码加密： "net password encryption" = true "net password encryption" = false 安全机制： "rpc security model A" 不提供安全机制 “rpc security model B” 提供不同的安全服务，如互相认证、消息加密、完整 性校验等。 列举特定服务器的信息： exec sp_helpdb 2.1. 3.登录信息 【目的】检查认证模式是否开启和默认登陆。 【具体配置】 检查认证模式是否开启： exec sp_loginconfig "login mode" 0 – 标准模式 1 – 集成模式 2 – 混合模式 标准认证模式： 默认的认证模式。Sybase使用自己的数据库（master数据库中的syslogins 表）来认证用户。Windows NT/2000的管理员如果没有正确的帐户也不能