地球科学数据共享材料八
海洋科学数据库建设规范
（讨论稿）
中科院青岛海洋科学研究所
地球科学数据共享政策与规范研究组
2004年5月
目录
1前言 (1)
2 ?海洋科学数据库建设总体要求 (2)
2 . 1海洋科学数据库总体框架构建 2
2 . 2具体的数据库的建库规范 2
2. 2. 1术语定义2
2. 2. 2具体数据库的建库流程 2
2. 2. 3具体数据库建设目标 3
2. 2. 4数据库文档3
海洋数据库建设规范实例：中国近海和西北太平洋温盐声密数据库建设规范...?. (3)
1 .前言 .............................................................. . (3)
2.中国近海和西北太平洋温盐声密数据库建设规范 .............................. . (4)
2 . 1适应范围4
2 . 2引用标准4
2 . 3技术术语定义/解释5
2. 4编码、属性表命名规则7
2 . 5元数据标准8
2 . 6文档格式8
2 . 7数据库建设流程8
2 . 8数据质量控制9
2 . 9数据库汇交（集成）（汇交至的方法和途径等）12
1.刖言
海洋科学是一门综合性的学科，涵盖物理海洋学、海洋地质学、海洋生物学、海洋化学等多个学科，研究工作中所涉及、积累的数据也是多种多样各不相同，如物理海洋方面水文数据是记录着某一经纬度、某一时间、某一航次、某一深度的海水温度、盐度和密度信息；海洋地质方面基础地质数据记录着某一区域海底深度及海底地貌等信息；而海洋生物方面又可能是某一物种或某一标本的属性等，因此
各方面的数据库建设也各不相同，建设规范也就
具体数据库
各不相同
根据这种情况作为海洋科学数据库的建库单位，一方面我们对整体的数据库建设有建设 规范（总体要求）；另一方面，要求每一个具体的数据库要通过建库的工作确定各自的规范 和标准，这个规范、标准是代表海洋所水平的，基本也就是代表科学院水平的，而且要求进 行必要的鉴定工作成为国家水平的。
2.海洋科学数据库建设总体要求
2 .1海洋科学数据库总体框架构建
海洋科学数据库可以粗略地分成海洋水文子库、海洋地质子库和海洋生物子库三个部 分，每个部分又包含了自成系统的多个具体的数据库。确定海洋科学数据库的整体框架， （从总结中摘录），使海洋科学数据库建和服务设成为日常性的工作。
2 . 2具体的数据库的建库规范
2. 2. 1术语定义
源数据集：具体数据库建库的数据来源，不拘于数据格式的、不断增长的数据集合。
标准数据集：产生于源数据集，经过数据格式的统一，经过数据排重和质量控制后产生 的数据集合，最直接的入库数据。
排重：在数据集中排除重复数据的过程。
质量控制：在经过排重的数据集中排除非法数据的过程。
专业性检索方法：指专业科学研究所习惯的数据库的检索途径，包括检索关键字。
专业性检索结果：指专业科学研究所习惯的数据库的检索结果，包括可视结果和标准的 数据文件（能够直接用于专业研究的标准数据文件）。
2 . 2. 2具体数据库的建库流程
2 . 2. 3具体数据库建设目标
建成三个数据实体源数据集标准数据集数据库
形成五个数据处理标准（专家鉴定）数据格式标准数据排重方法
数据质量控制方法专业性数据检索方法专业性数据检索结果
数据库的元数据建设
建立B/S结构的数据库检索手段
2 . 2. 4数据库文档
海洋数据库建设规范实例：中国近海和西北太平洋温盐声密数据库建
设规范
1.冃言
海洋信息是海洋科研、教案、工程设计、规划管理、环境测报及评价、海洋经济可持续发展和军事海洋环境条件保证等的主要依据，因此海洋科学数据的收集、处理和数据库建设具有重大的社会科学意义和紧迫的国家需求。众所周知，物理海洋学是海洋科学研究和应用的基础，以海水温度、盐度、密度等参数为核心的海洋水文数据则是气候和海洋环境生态研究、环境预报和评价、工程设计、减灾防灾及军事海洋环境条件保证等的主要背景信息。我国渤、黄、东、南海是世界大洋的一部分，其变化相互联系，并深受世界大洋的影响。要研究和预测中国近海和邻近大洋的海洋环境变化，必须进行大范围的长期、同步海洋观测。进行这样的海洋调查需要巨大投资，任何一个单位、部门、甚至国家都不可能单靠自己的调查力量或依据未经系统整理的数据去开展大规模海洋研究工作。因此，海洋水文数据库建设不但有重要的使用价值，还具有昂贵的产出价值和显著的社会共有性，同时必须依据科学合理的建设规范来进行。
国际海洋水文信息是海洋水文数据库的主要数据源。国际海洋水文数据种类繁多，时间序列长，空间分布广，信息量巨大，且积累速度快。这些数据分别来自全球几十个国家和地区；使用的观测仪器千差万别；资料的整理方法各不相同；导出参数的计算方法和公式各异；由实测层数据内插标准层的方法也各有长短；甚至采用的数据处理标准和编码，以及记录的资料的格式也仍在统一过程中。因此，规范化的建库方法和标准化的建设流程，以及先进的排重技术和严谨的质控方法都是保证建设合理、适用的海洋信息管理系统的前提条件。
本规范是在总结海洋数据库体系中有代表性的“中国近海和西北太平洋温盐声密数据库”的多年
建库经验的基础上逐步发展完善起来的。本规范的创新及特色之处包括：通用的0DSF1数据输入/输出格式、统一的数据排重程序、标准的数据质控方法、规范的数据库建设流程和全套国内外通用代码。它不仅指导了该数据库的建设，同时对海洋科学其他数据库的建设有借鉴作用。
2 ?中国近海和西北太平洋温盐声密数据库建设规范
2 . 1适应范围
本规范适用于海洋物理(含温、盐、密、声、流、浪、潮)、海洋气象和化学数据库建设中的相关数据处理工作及相关数据库建设。
2. 2引用标准
国家标准：
(1) GB12763.1- 91 海洋调查规范海洋调查规范总则
(2) GB12763.7- 91 海洋调查规范海洋调查资料处理
(3) GB12763.3- 91 海洋调查规范海洋气象观测
(4) GB12763.4- 91 海洋调查规范海洋化学要素观测
(5) GB12763.5- 91 海洋调查规范海洋声、光要素调查
(6) GB12763.2- 91 海洋调查规范海洋水文观测
(7) GB12763.6- 91 海洋调查规范海洋生物调查
(8) GB3100~3102-82 量和单位
(9) GB/T17839-1999 警戒潮位核定方法
(10 ) GB/T 1.1 —1993 标准化工作导则
(11)GB1232—1998海道测量规范
(12)GB17501-1998 海洋工程地形测量规范
(13) GB/T14158-93 区域水文地质工程、地质环境、地质综合勘察规范(比例尺
1: 50000)
(14) GB/T 17798—1999 地球空间数据交换格式
(15)GB 12409-90 地理格网
(16)GB/T GB2808-81 全数字式日期表示法
GB/T 12763.1-2007 海洋调查规范第 1 部分：总则GB/T 12763.2-2007 海；洋调查规范第 2 部分：海洋羊水文观测GB/T 12763.3-2007 海；洋调查规范第 3 部分：海洋羊气象观测
GB/T 12763.4-2007 海洋调查规范第 4 部分：海水化学要素调查
GB/T 12763.5-2007 海洋调查规范第 5 部分：海洋声、光要素调查GB/T 12763.6-2007 海洋羊调查规范第 6 部分：海洋羊生物调查GB/T 12763.7-2007 海洋调查规范第7 部分：海洋调查资料交换GB/T 12763.8-2007 海洋调查规范第8 部分:海洋地质地球物理调查GB/T 12763.9-2007 海洋调查规范第9 部分：海洋生态调查指南
GB/T 12763.10-2007 海洋今调查规范第10 部分:海底地形地貌调查GB/T 12763.11-2007 海洋调查规范第11部分：海洋工程地质调查
2 . 3技术术语定义/解释
2.3.1主子表结构和数据分组
(1)主子表结构：通过关联字段使主、子表对应，以解决数据记录表头和观测层数据存、取的
速度问题；主子表结构是数据记录“一对多”关系的具体体现。
(2)数据分组：根据数据的某些特征将数据存储在不同的数据库对象中；检索时，只需要根据
数据特征来定位数据，并快速得到查询结果。
2.3.2数据查询
(1)网格数据查询：在显示网格数据信息时，直接读取和调用数据统计信息的过程。数据统计
信息是在进行数据维护时生成的，并存储到单独的数据库对象中。
(2)鼠标点击查询：鼠标点击事件发生时，系统先通过中间数据定位查找结果，然后再将查询
结果反馈给应用程序的全过程。中间数据是在数据维护过程中生成的，将基本数据中的某些信息进行提炼，并存储到单独的数据库对象中。
2.3.3数据定位
确定数据所在位置(测站)的技术和过程，包括：
(1)“极值”定位：依照网格数据的统计结果、根据统计网格编号和经、纬度值，查询检索到
该网格中的极值存在于特定测站的技术和过程。
(2)“站次ID”定位：通过给定的经、纬度和站次ID，检索和查阅该测站全部信息的过程。
(3)“航迹图”定位：使用航次信息绘制的航迹或断面图去诊断和定位“有疑问”资料的技术
和过程。
(4)模糊定位：由于鼠标点击定位时，“点击点”与“真实数据点”之间存在位置上
的差异，“模糊定位”是帮助用户查找到距“点击点”处最近的数据点的技术。
2.3.4数据格式参数化
把数据格式以“自定义参数的形式”设计在程序中，统计调用时，通过函数名称进行调度的技术。
2.3.5相关参数“函数化”
将数据类型、观测参数、航次信息等先以函数的形式存放在数据表中，然后在程序运行中通过函数进行转换以便达到只改变列表，不改动程序，就能容易达到预期的变更目的之技术。
2.3.6数据库对象命名
将参数直接写在数据表中，通过数据表的名称来判断和定位数据，并缩小检索范围，以解决参数快
速准确存取的技术。
2.3.7 元数据（metadata）
描述某类数据的属性、特征、时、空变化范围及其质量、精度等相关信息的集合。
2.3.8编码
将信息分类的结果用一种易于被计算机和人识别的符号体系表示出来的过程，是人们统一认识、统一观点、相互交换信息的一种技术手段。编码的直接产物是代码。
2.3.9空间数据结构
指空间数据在计算机内的组织和编码形式；它是一种适合于计算机存储、管理和处理空间数据的逻辑结构，是实体的空间排列和相互关系的抽象描述。
2.3.10图文资料扫描数字化
通过扫描把以纸介质为载体的图文资料由模拟信息转变为数字信息，并按一定的质量要求对电子文件进行加工和制作，然后存储在磁带、磁盘或光盘等介质上的过程。
2.3.11源数据集
本系统所使用的数据来源之集合。
2.3.12基础（存档）数据集
指来自于源数据集的数据，经过格式转换、代码统一、重复排除和质量控制后形成的实测层数据集合（相对“标准数据集”而言）。值得一提的是：对于在标准层上发现的资料质量问题，必须到实测层存档数据集中寻找出错原因，再加以改正，然后重新计算标准层后入库。
2.3.13标准数据集
根据实测层数据计算出的准备入库之标准层数据集合。标准层定义见下表
2.3.1 4排
重
排除数据集中重复数据的过程和技术。
2.3.15质量控制
剔除数据集或数据库中随机错误和“人为虚构”测站资料与数据的过程及技术之总称。
2 . 4编码、属性表命名规则
2.4.1编码规则
本数据库中使用了包括网格编号、国家编码、资料源代码、资料类型、参数编码等在内的诸多编码，其编码规则均采用由美国国家海洋数据中心编制的世界海洋数据库（WO P编码规则。为了方便数据循环调用和统计，字段编码采用代码制，即根据数据参数的特点，事先制订字段参数-代码表，然后依据参数-代码表进行数据库设计
2.4.2数据库命名规则
数据库名称为9位编：如ODMS_4002
xx〈x , XX XX
------- 子系统编码
子系统版本
-------------------------- 系统名称
2.4.3数据表命名规则
X XXXX X XXXXX
--- 数据表参数2
----------------- 数据表参数 1
----------------------------- 数据表类型
数据表名称为12位编：如T_1312011111
2.4.4字段命名规则
为了方便数据循环调用和统计，字段编码采用代码制，即根据数据参数的特点，事先制
订字段参数-代码表，然后依据参数-代码表进行数据库设计
2 . 5元数据标准
采用的元数据标准为《WDCD海洋学资料元数据标准》（见附件1）。
2 . 6文档格式
本系统吸收国际各种数据格式的优点，自行研发和采用了“海洋资料共享格式（ODSF）”，并改进为0DSF1，作为输入、输出格式（见附录2）。
2 . 7数据库建设流程
温-盐-密-声库的建设流程如下图所示。在做好数据收集提取、格式转换、编码统一、质量控制和排重工作的基础上，根据需求分析的结果，并灵活运用建库理论，通过数据管理子系统，将经过校验的数据导入库内，建成数据库实体。
2 . 8数据质量控制
2.8. 1质量监控体系
质量监控体系包括数据入库前的质量控制流程和排重流程，以及数据入库后的库内分析诊断模块。
2. 8. 2数据质量监控
1、数据质量控制流程图
合并
第二次质控
OSD 类型资料为例）
2、排重工作流程图（以
解压、合并后的 OSD 资料总文件
次排 第一组参数分离出完全重复的资料
用经纬度和时间的 复
重 可能完全重复数据文件
人工 重复
是 合并
次排重
人工 是
生成*.comb2文件
使用经、纬度和时间组合的第三组参数
合 并
排 除 D 程
序 块 劣 审核 否
审核
否 拷
Y
程 重 拷贝对应重复站
至REP
人工审核 否
H 选程优
贝 重— 复 _
是
拷贝至重复站REP 生成*.comb1文件
可能重复数据文件
可能不重复数据文件
可能不重复数据文件
从两个或多个站中优选出一个站
从两个或多个站中优选出一个站
生成统一的重复数据文件 并入重复数据集
年 度 确 认
对程第 亠序 应
站
M
—至
程
"RE 序 块
调 用: 左 边 程 序择 模 斗块
部
分 L 造 O ■假 程 资 序 料 块
重
块
纬
L 度
A 合
确 Y -- 程
认
序
第三次
并
兀排重
使用经、纬度和时间组合的第二组参数
重复
可能重复文件
重复
从两个或多个站中优选出一个站 肯定不重复文件
生成*.comb3最终文件，供质控使用
REP ，供IOCAS 和OCL 检验
3、库内分析诊断模块
（1）极值定位
利用本系统“通过给定站位和站次ID，可以查阅、检索，并显示该站完整信息”的功
能，并“根据网格数据的统计结果，可进行极值（极大或极小值）定位”的功能模块，能
够确认从0.1 o*0.1 o到10o*10o任意方区内的极值是否合理，从而达到诊断资料真实性的的目的；因为“错情”通常是与观测参数特定空间范围和特殊时段的“极值”（极大/小值）紧密相关。
（2）同步观测资料类比
将数据类型、观测参数、航次/断面信息先以函数的形式存放在数据表中，然后在程序中通过函数进行转换，使相关参数“函数化”；这样只改列表，而不动程序，就可容易地达到预想的变更目的。有质量问题的资料（造假）入库后，通过相关参数“函数化”处理和系统强大的统计检索功能，可以把与该资料（造假）同属一个航次/断面的有关资料和其它航
次/断面的同步或准同步测量资料调度到同一平面上类比，从而确认该（造假）资料的真实性。实践证明，相当数量人为制造的资料与真实资料在同一时空环境下类比就会暴露“伪” 的原形。
（3）盐-密模定量分析
表征水团特性的温一盐曲线在特定海区具有定常的形态（Svordrup等1942）,因此使
用温-盐或盐-密双变量频率分布所形成的模式，可以检验现有观测资料的质量。美国国家海洋资料中心Douglas Hamilton 博士于1976年率先研制了5 x 5网格的盐-密模，并用于定性质控（Environmental Models for Quality Control, 1976, Douglas Hamilton ）。借鉴
美国的经验，使用了数据子系统的温、盐资料计算出条件密度，再用盐度和密度值及其它相关参数制成不同海区、季节/月份、以及不同层次上的盐-密模型；之后再用盐-密模型检验入库资料的质量，剔除可能会严重影响统计结果的非真实资料。
（4）航次/断面分析诊断
如果某一航次/断面中的“一个或多个”测站出现“有疑问”的资料，系统会根据具体需要和该航次综合信息绘制出航次/断面图，以确诊“疑问”之所在，并帮助纠正元数据，同时提供纠错办法与可能的“订正量”，即订正值的大小。
2 . 9数据库汇交（集成）（汇交至的方法和途径等）
（1）由研发单位向中科院科学数据库中心汇交本数据管理系统；
（2）所有的数据库建设成果及相关文档（工程设计书、总体方案、建库合同、协议等）均按科学数据库有关要求存档保管；
（3）汇交数据文件的存储介质为光盘；
（4）提交成果之前，应进行全面查、杀毒，以确保数据的安全。
附录1 WDCD海洋学资料元数据标准
数据集名称：中国近海和西北太平洋温盐声密数据库
数据集编码：待定
数据集内容关键词：海洋信息、格式、质控、排重、管理系统、标准
数据集内容：海洋学各分支学科的现场观测资料
数据集开始时间：1876年6月
数据集结束时间：2004年4月
数据空间范围（最低经度，最高经度）：100oE~140oE
数据空间范围（最低纬度，最高纬度）：10oS~50oN
数据空间范围（最低高度，最高高度）：海面~海底
数据质量说明：数据质量可靠，误码率小于万分之六
数据存储介质：CD-ROM、DVD、活动硬盘
数据存储格式：入库数据均以数据表的形式存储
数据量：12.6GB
数据来源：全球海洋科学团体
数据集使用的语种：中文、英文
系统、数据集、数据库等作者信息：
科学顾问：胡敦欣
系统总设计：许崇金、王凡、代亮、孙丰山、陈献辉、孙东丽、陈永利等管理子系统设计：
代亮、许崇金、王凡、孙丰山、孙东丽、陈永利、陈献辉温-盐数据库设计：王凡、许崇金、
代亮、孙丰山、孙东丽、陈永利、陈献辉数据集存放地点：中国科学院海洋研究所
数据集索取方式：函索/面商皆可。
数据更新周期：每半年至一年更新一次
附录2 “海洋资料共享格式（ODSF）”
本数据库吸收国际各种数据格式的优点，自行研发和采用了“海洋资料共享格式（ODSF）”，并改进为ODSF1，作为输入、输出格式。
格式例样1：
1 2 3 4 5 6
123456789012345678901234567890123456789012345678901234567890
CC cruise Latitde Lon gitde YYYY MM DD Time Station # 崛第一个记录：英文表头说明49 PR19 26.830 121.255 1990 11 15 12.26 IS-13 9 ------------------- 二个记录：英文对应的
信息
Nvar= 2 = 第三个记录；"2”参
数个数
1 2第四个记录：按顺序排列的参数代码( ParaCodes.txt )
0.0 23.732⑵0 33.649⑵0第五个记录以下为各层次之数据资料
5.0 23.741 (2) 0 33.649 (2) 0 9为观测层次数 -----
10.0 23.746 ⑵ 0 33.651 ⑵ 0
15.0 23.742 ⑵ 0 31.654 (2) 10
格式例样2:表头信息
格式例样3:实测层信息
20.0 25.0 30.0 50.0 63.4 23.731 ⑵ 0 33.661 ⑵ 0 23.637 ⑵ 0 33.696 ⑵ 0 23.569 ⑵ 0 33.722 ⑵ 0
33.560 23.571 ⑵ 0
（2） 20 33.723 ⑵ 0 33.728（2）0 资料： 美国 来源国原有质量码位（空位） 资
料中心质量代码位
2”和“1”
本数据库新加质量码位“
数据库安全规范
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、判定条件
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： 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模型的步骤如下所示:
平安金融科技数据库（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、设计主题数据库的实体联系模型，要求按规范画出实体联系模型（E-R 模型）图 3、根据转换规则由主题数据库的E-R模型转化为关系模型，并标出关系的主码和外码 4、设计数据库，每个关系的表结构、确定主键 三、实验步骤 1.主题数据库的需求分析：每个学校都有自己专门的教学管理系统，方便教学信息检索查询，最简单的就是班级的课表与老师的教学任务表了，本次实验主要完成的是简单教学管理系统的设计与实现，做到可以方便的查询每个班级（或每个学生）所对应的专业，课程与授课教师。本数据库的实体有：学生信息，班级信息，专业信息，课程信息，教师信息以及教学任务表，需要在每个实体中添加对应信息，明确所在班级的专业信息，学生的课程信息，老师的教学信息等等方面内容。 2. 教学管理系统数据库的实体间的联系：由生活常识与数据库联系要求可知： 学生信息———————班级信息1对多关系 班级信息———————专业信息1对多关系 学生信息———————专业信息1对多关系 课程信息———————教师信息多对多关系 课程信息———————班级信息多对多关系 教师信息———————班级信息多对多关系 注：课程，班级，教师由一张教学任务表互相联系 E-R模型图，如下：
3.教学管理系统数据库的关系模型： 关系模型如下： 学生信息（学号，姓名，性别，班号） 班级信息（班号，班级，专业号） 专业信息（专业号，专业） 课程信息（课程号，课程） 教师信息（教师号，教师名） 课程，班级，教师由一张教学任务表互相联系： 教学任务表（课程号，教师号，班号，学期，起始时间） 相应的关系结构模型如下： （1）学生信息与班级信息的关系结构模型
1命名原则 1.1约定 u是指对数据库、数据库对象如表、字段、索引、序列、存储过程等的命名约定； U命名使用富有意义的英文词汇，尽量避免使用缩写，多个单词组成的，中间以下划线分割 u避免使用Oracle的保留字如LEVEL、关键字如TYPE （见Oracle保留字和关键字）； u各表之间相关列名尽量同名； u除数据库名称长度为1 — 8个字符，其余为1 — 30个字符，Database link 名称也不要超过30个字符； u命名只能使用英文字母，数字和下划线； 1.2表名 规则如下： 命名规则为xxx_yyy_TableName 。xxx表示开发公司的名称，最多五个字母构成，尽量用简称；yyy 表示子系统中的子模块的名称（可以没有），最多五个字母构成，尽量用简称；TableName 为表含义，最多十个字母构成，尽量用简称 TableName 规则如下： u使用英文单词或词组作为表名，不得使用汉语拼音 u用名词和名词短语作表名 u不使用复数 正确的命名，例如： fiber_sys_user fiber_biz_order 1.3存储过程 规则如下： 命名规则为xxx_yyy_StoredProcedureName 。xxx表示开发公司的名称，最多五个字母构成，尽量用 简称；yyy表示子系统中的子模块的名称（可以没有），最多五个字母构成，尽量用简称；
StoredProcedureName 规则如下： u用动词或动词短语来命名，并带有宾语 u需要符合用Pascal命名规则。 u尽量谨慎地使用缩写 u尽量不要和关键字重合 u不要用任何名前缀（例如U , B） u StoredProcedureName 内不使用下划线 u当操作依赖条件时，一般结尾使用By+条件 存储过程正确的命名，例如： sys_lnsertUser sys_SearchUserByUserlD sys_DeleteUserByUserlD 1.4视图 规则如下： u视图的命名采用xxx_yyy_ ViewName_v 。xxx表示开发公司的名称，最多五个字母构成，尽量用简称；yyy表示子系统中的子模块的名称（可以没有），最多五个字母构成，尽量用简称；_v后缀表示视图, ViewName 部分表示视图的含义，最多十个字母构成，尽量用简称。 ViewName 规则如下： u用名词和名词短语， u不使用复数 u用Pascal命名规则 u尽量谨慎地使用缩写 u尽量不要和关键字重合 u不要用任何名前缀（例如U，B） u ViewName 中使用下划线 视图正确的命名，例如:
专题数据库建设推荐标准规范 （一）数据采集规范 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）建立科学合理的智慧城市公共基础数据库指标体系，力求全面反映地区经济和社会发展的总体情况： 2）有组织、有计划、持续地对政府统计部门、政府各部门以及国民经济行业管理部门负责统计的关系到地区经济与社会发展的信息资源进行收集、整合，
数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个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 目的 本规范的主要目的是希望规范数据库设计，尽量提前避免由于数据库设计不当而产生的麻烦；同时好的规范，在执行的时候可以培养出好的习惯，好的习惯是软件质量的很好的保证。 数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 2 适用范围 本规范的适用人员范围包括我司的所有应用开发人员以及在我司承接数据库应用开发的软件人员。 本规范的适用IT范围包括数据库对象的命名规范、设计原则、SQL语句的设计和使用、SQL语句的性能优化建议、其他与性能有关的设计原则以及设计工具的选择。 3 数据对象的命名规范 3.1 通用规范 3.1.1 使用英文：要用简单明了的英文单词，不要用拼音，特别是拼音缩写。主要目的很明确，让人容易明白这个对象是做什么用的； 3.1.2 一律大写，特别是表名：有些数据库，表的命名乃至其他数据对象的命名是大小写敏感的，为了避免不必要的麻烦，并且尊重通常的习惯，最好一律用大写； 3.2 数据库对象命名规范 3.2.1 表的命名 3.2.1.1 表名的前缀：前缀_表名_T。为表的名称增加一个或者多个前缀，前缀名不要太长，可以用缩写，最好用下划线与后面的单词分开；其目的有这样几个：3.2.1.1.1 为了不与其他项目或者其他系统、子系统的表重名； 3.2.1.1.2 表示某种从属关系，比如表明是属于某个子系统、某个模块或者某个项目等等。表示这种从属关系的一个主要目的是，从表名能够大概知道如何去找相关的人员。比如以子系统为前缀的，当看到这个表的时候，就知道有问题可以去找该子系统的开发和使用人员； 3.2.2 视图命名：相关表名_V（或者根据需要另取名字）； 3.2.3 程序包命名：程序包名_PKG（用英文表达程序包意义）； 3.2.4 存储过程命名：存储过程名_PRO（用英文表达存储过程意义）；
竭诚为您提供优质文档/双击可除人口基础数据库建设规范 篇一：全员人口数据库建设培训手册 入户调查———信息卡登记填写篇 以下几个率，我们各级检查中是要考核的，数据库的建设必须达到如下指标： 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. 前言 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。在第一范式中满足进一步要求的为第二范式，其余以此类推。一般而言，数据库的设计应至少满足第三范式。 关联 关联是不同表之间的数据彼此联系的方法。关联同时存在于形成不同实体的数据项之间和表实体本身之间，构成了数据库规范化的基本核心问题。它分为一对一、一对多、多对多三种关联形式。 关系模型 关系模型由关系数据结构、关系操作集合和关系完整性约束三部分组成。在 关系模型中，实体与实体间的联系都是用关系来表示的。 视图 视图是一个定制的虚拟表。可以是本地的、远程的或带参数的；其数据可以 来源于一个或多个表，或者其他视图；它是可更新的，可以引用远程表；它可以 更新数据源。视图是基于数据库的，因此，创建视图的前必须有数据库。 外键 外键是一个关系中的一组属性（一个或多个列），它同时也是某种（相同的 或其它的）关系中的主键。它是关系之间的逻辑链接。 约束
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. 数据源 数据源，顾名思义就是数据的来源，互联网公司的数据来源随着公司的规模扩张而呈递增趋势，同时自不同的业务源，比如埋点采集，客户上报等。 2. ODS层 数据仓库源头系统的数据表通常会原封不动地存储一份，这称为ODS（Operation Data Store）层, ODS层也经常会被称为准备区（Staging area）,它们是后续数据仓库层（即基于Kimball维度建模生成的事实表和维度表层，以及基于这些事实表和明细表加工的汇总层数据）加工数据的来源，同时ODS层也存储着历史的增量数据或全量数据。 3. DW层 据仓库明细层（Data Warehouse Detail ，DWD）和数据仓库汇总层（Data Warehouse Summary, DWS）是数据仓库的主题内容。DWD和DWS层的数据是ODS 层经过ETL清洗、转换、加载生成的，而且它们通常都是基于Kimball的维度建模理论来构建的，并通过一致性维度和数据总线来保证各个子主题的维度一致性。 4. DWS层 应用层汇总层主要是将DWD和DWS的明细数据在hadoop平台进行汇总，然后将产生的结果同步到DWS数据库，提供给各个应用。 二，数据采集
数据采集的任务就是把数据从各种数据源中采集和存储到数据存储上，期间有可能会做一些简单的清洗。 比较常见的就是用户行为数据的采集 先做sdk埋点，通过kafka实时采集到用户的访问数据，再用spark做简单的清洗，存入hdfs作为数据仓库的数据源之一。 三，数据存储 随着公司的规模不断扩张，产生的数据也越来越到，像一些大公司每天产生的数据量都在PB级别，传统的数据库已经不能满足存储要求，目前hdfs是大数据环境下数据仓库/数据平台最完美的数据存储解决方案。 在离线计算方面，也就是对实时性要求不高的部分，Hive还是首当其冲的选择，丰富的数据类型、内置函数；压缩比非常高的ORC/PARQUET文件存储格式；非常方便的SQL 支持，使得Hive在基于结构化数据上的统计分析远远比MapReduce要高效的多，一句SQL可以完成的需求，开发MR可能需要上百行代码；而在实时计算方面，flink是最优的选择，不过目前仅支持java跟scala开发。 四，数据同步 数据同步是指不同数据存储系统之间要进行数据迁移，比如在hdfs上，大多业务和应用因为效率的原因不可以直接从HDFS上获取数据，因此需要将hdfs上汇总后的数据同步至其他的存储系统，比如mysql；sqoop可以做到这一点，但是Sqoop太过繁重，而且不
18春《Oracle数据库开发》作业_1 一、单选题( 每题4分, 共10道小题, 总分值40分) 1.在Oracle中，关于PL/SQL下列描述正确的是（） A. PL/SQL代表Power Language/SQL B. PL/SQL不支持面向对象编程 C. PL/SQL块包括声明部分、可执行部分和异常处理部分 D. PL/SQL提供的四种内置数据类型是character,integer,float,boolean 答案：C 2.当需要删除表，且该表具有外键约束，需要删除表及其外键约束，可以使用如下（）类型的SQL语句。 A. DROP TABLE table1 B. DROP TABLE tablel with foreign key C. DROP TABLE tablel1 CASCADE CONSTRAINTS D. DROP TABLE table1 all 答案：C 3.为了启动Oracle数据库实例，Oracle必须读取一个（）文件，该文件保存了实例和数据库的配置参数列表。 A. 控制文件 B. 数据文件 C. 参数文件 D. 初始化文件 答案：C 4.（）实现了JDBC ResultSet中的所有方法，但与ResultSet不同的是，OracleCachedRowSet 中的数据在Connection关闭后仍然有效。 A. OracleCachedRowSet B. OracleRowSet C. OracleSet D. CachedRowSet 答案：A 5.假设需要给某个客户表Customer的Customer_name列添加注释信息：客户姓名，可以使用如下（）方式 A. COMMENT ON TABLE?CUSTOMER?IS?'客户姓名' B. COMMENT ON COLUMN CUSTOMER.CUSTOMER_NAME IS '客户姓名' C. COMMENT ON COLUMN CUSTOMER.CUSTOMER_NAME '客户姓名' D. COMMENT ON COLUMN CUSTOMER.CUSTOMER_NAME '客户姓名' 答案：B
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_"前缀 + "站点名_"前缀及其所服务的应用名称命名。
中草药主题数据库 随着现代人们返璞归真，越来越趋向于用天然药物防治疾病的影响，中医医药事业蓬勃发展，医学院校加大中医建设，民族药企也如雨后春笋一般涌现，面对这种情况，对中草药资源的合理开发和利用成为关键，只有全面了解中草药，才能有效利用这些宝贵的资源。《中草药主题数据库》逐渐成为中草药行业的标志性数据平台，已经成为中草药行业信息检索与资源分享的重要途径。本库不但能满足广大中草药学者、科研人员的需要，也是临床医务工作者、药品生产企业最需要的“中草药大全”。 《中草药主题数据库》内含上万条目，收载现代中草药近6000种，图像资料9000多张。本库按照多级目录分别描述，每种药物附有生长实地拍摄的彩色图片。 数据库可以做什么 数据库按照主治功效、药物类别、临床科目、性味分成条目，其
下再按草药形态、生长环境分布、入药部位、行为功效等分别描述，每种药物附有生长实地拍摄的彩色图片，内容丰富，图文并茂，是全面介绍中草药信息的参考工具型数据库。 目录层级： 一级目录：主治功效、药物类别、临床科目、性味 二级目录：草药形态、生长环境分布、入药部位、行为功效 数据库采用对条目元数据和正文的综合检索（即全部），检索方式采用拼音索引、笔画索引和拉丁索引，同时提供针对标题、关键字、
内容的细分检索，用户能快速的查到所需的条目。我们根据用户的搜索和浏览习惯统计数据，将热词链接罗列在主页面上，直观快捷。 不光“治病”，还能养生 中国药茶是祖国医学宝库中的一颗璀璨明珠，从“神农尝百草，日遇七十二毒，得茶而解之”的记载到唐朝“茶为万病之药”的高度评价可知，茶的药用价值是不可估量的。 所以中草药数据库还延伸出了茶药专题，收集了药茶方3000多首，所有茶方的来源均注明出处。茶药根据功能分为为保健茶、治疗茶、保健食品茶、药茶和代用茶5类，其中又各自根据养生补气、美容怡神、内外科治疗等功能各列出上百条茶方，详细叙述了茶方组成、用法、功能及其茶方来源。茶药不仅在中国受到欢迎，随着时代的变迁也被世界各国的人所熟知喜爱，整理药茶方剂，对弘扬祖国医学有着特别深远的意义。 药歌新编，易读易记