数据库建设的规则_第1页
数据库建设的规则_第2页
数据库建设的规则_第3页
数据库建设的规则_第4页
数据库建设的规则_第5页
已阅读5页,还剩8页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、I目录目录1. 范围范围 .12. 总体要求总体要求 .12.1 数据库设计总体要求.12.2 数据库对象命名的总体要求.12.3 数据库程序编码的总体要求.23. 数据库设计规范数据库设计规范 .23.1 数据库设计要求.23.2 数据库概念逻辑设计.23.2.1 需求调研.23.2.2 概念设计.33.2.3 局部设计.33.2.4 整体设汁.33.2.5 逻辑设计.33.3 数据库物理设计.34. ORACLE 数据库命名规则数据库命名规则 .44.1 ORACLE数据库对象命名规则.44.1.1 数据库名(Databases) .54.1.2 实例名(Instances).54.1.3

2、 表空间 (Tablespaces).54.1.4 数据文件(Data files).54.1.5 日志文件(Redo log files).54.1.6 参数文件(Parameter files和Stored Parameter files).64.1.7 控制文件(Control files).64.1.8 回滚段(Rollback segments).64.1.9 表(Tables).64.1.10 字段(Fields).64.1.11 索引(Indexes).74.1.12 约束(Constraints).74.1.13 视图(Views).74.1.14 同义词(Synonyms).

3、74.1.15 序列号(Sequences).84.1.16 存储过程(Stored Procedures).84.1.17 函数(Functions).84.1.18 程序包(Packages)和程序包体(Packages Bodies).84.1.19 触发器(Triggers).84.1.20 角色(Roles).84.1.21 用户(Users).84.2 SQL、PL/SQL 源代码编写约定.8II4.2.1 变量命名规则.84.2.2 代码排版规则.94.2.3 代码注释规则.94.2.4 其他要求.105. 数据字典文档编写格式数据字典文档编写格式 .105.1 数据库表汇总表格

4、式.105.2 数据库表详述表格式.105.3 编码数据表格式.1111. 范围范围本规范规定了南京市交通局数据库建设的规则,是检验评定软件开发者为南京市交通局开发的应用系统质量的标准尺度。本规范适用于各软件开发者和有关单位为南京市交通局开发的应用系统所使用的数据库,数据库的设计、数据库内的对象命名、数据字典文档的编写必须遵守本规范。2. 总体要求总体要求数据库建设规范主要包括数据库设计规范、数据库对象命名规则和数据库程序编码规则、数据字典文档编写格式等内容。2.1 数据库设计总体要求数据库设计总体要求 数据库是交通信息化建设的重要基础。数据库设计通常是作为应用系统开发的一部分进行的,但在应用

5、系统开发中数据库设计具有特殊的重要性和相对独立性,因此在本规范中专门进行规定。关于交通局应用系统的开发要求,请参见南京市交通局信息化软件开发实施指南 。 开发者在系统设计阶段,应采用合理的设计方法进行数据库设计,建立数据库的逻辑模型和物理模型,最终设计出高性能、易扩展、易维护、少冗余、高安全性、高可靠性、一致性和完整性好的数据库。 在数据库设计完成后,开发者应向交通局提交数据库设计报告 。在软件鉴定验收时,开发者应向交通局提交完整的数据库设计报告 、 数据字典和在开发过程中发生的变更记录。2.2 数据库对象命名的总体要求数据库对象命名的总体要求 数据库对象如表、存储过程等的名称一般根据对象的类

6、别、所在的系统代号和自定义代号来确定,但对各类对象的命名有其特定要求,具体的各种对象的命名要求请见本规范第四部分。 自定义代号根据中文名称来确定,采用中文名称首字的全拼,后接其它字的中文拼音首字母,如果有两个对象根据此方法命名出现重复则对两个对象都用中文拼音的完整拼音来表示。 数据库对象不得使用数据库的关键字作为名字。 在本规则的第四部分对 Oracle 数据库的对象命名要求和程序编码要求做了具体规定,如果需要使用具它数据库如 SQL Server 等,其命名规则参照 Oracle 数据库的命名规则来进行。本部分的要求具有强制性,开发者应严格遵守此要求。22.3 数据库程序编码的总体要求数据库

7、程序编码的总体要求 通过对数据库程序编码制定规则,来提高程序的可读性。这其中主要包括变量命名规则、代码排版规则、代码注释规则等。 本部分相对要求较宽,但开发者应参照这部分的要求制定自己的编码规范,并严格遵守。本部分的代码注释规则是对开发者编写注释的基本要求,开发者自己可以提出对代码注释的更高要求,但不得低于本规则的要求。3. 数据库设计规范数据库设计规范3.1 数据库设计要求数据库设计要求为了保证数据库设计的质量,提高数据库的完整性、一致型、安全性、易扩展性、性能、减少数据的冗余,开发者应在需求分析阶段对已有业务系统、本期开发的业务系统和以后开发的业务系统的数据作全面的调研,在此基础上采用合理

8、的设计方法,分析业务系统所涉及的数据及数据之间的内在关系,利用如 Rational Rose、Together、ER-Win 等软件作为数据库辅助设计工具,进行反映数据库中对象联系和依赖的概念逻辑设计和物理设计。在进行数据库设计时,除了本规范以外,还应遵守南京市交通局信息化软件开发实施指南的要求。 在数据库逻辑设计完成后,开发者应向交通局提交数据库设计报告 ,在数据库设计报告中必须包括完整的实体关系图(E-R 图),在得到交通局的评审认可后方可进行数据库的物理设计。 在软件鉴定验收时,开发者应向交通局提交最终完稿的数据库设计报告及其变更记录,同时提交所交付软件完整的数据字典 。3.2 数据库概

9、念逻辑设计数据库概念逻辑设计 整个概念逻辑设计包括需求调研、概念设计和逻辑设计三个部分,需要与业务系统的调研、分析、设计和开发结合起来进行。3.2.1 需求调研 在应用系统开发的需求调研阶段,应对本期开发的业务系统的功能数据和以后开发的业务系统的数据进行调研。对于本期要求开发实现的应用系统,应调研系统功能和所要处理的数据,同时要对交通局所有已有相关应用系统进行调研,分析这些系统是否已有新系统所需要的数据,该数据能否满足新系统的所有需求,以决定是否可以直接访问已有应用系统的数据库中的数据,或采用复制等方法定期将已有系统的数据复制到本期开发的应用系统后台数据库,或直接用新系统来维护这些数据。33.

10、2.2 概念设计 概念设计应采用 E-R 模型进行,针对各个业务系统进行局部数据视图设计,然后进行局部数据视图集成,进行整体数据视图的设计。在整体设计中找到最大的共享数据集,同时对这些共享数据进行语义上的描述(数据产生的业务系统、数据使用的业务系统等)。面向信息服务的数据建模采用 E-R 模型描述,但所有的数据模式按照中心主题建立。E-R 图设计、画法不是唯一的,但在绘 E-R 图时应注意:结构要清晰、关联要简洁、实体个数要适中、属性分配要合理、没有低级冗余。3.2.3 局部设计根据各个业务系统的需求调研,设计出业务系统中的所有实体和关系,形成个局部的业务数据视图。3.2.4 整体设汁将交通局

11、的各个业务系统对应的局部业务视图进行两两集成,删除冗余的实体和关系,记录业务系统的共享数据模式,最终实现一个没有冗余、一致的全局视图模式。标记所有共享数据模式的相关业务系统,以及数据的来源和数据的使用状况。3.2.5 逻辑设计根据得到的全局概念模式进行关系逻辑设计,并作规范化分解,建立一系列的规范化分解,对于概念模式中的数据集进行数据表的设计。所有的公共共享数据集,业务数据要保证数据源唯一。同时对本期开发的业务系统中不能维护但需要使用的共享数据集,建立与老业务系统之间数据抽取的映射关系。面向信息服务的数据模式根据概念模式的来源和用途分别建立数据表或者跨数据库视图。能从业务数据平台中直接获取的数

12、据应设计跨数据库视图,需要从业务数据平台层捕获的历史数据应设计成数据表。在逻辑设计阶段,应考虑:为提高程序的执行效率适当进行逆规范化,减少连接运算合理的属性类型及长度创建视图 可以建立面向用户的外模式,提供一定的逻辑数据独立性。3.3 数据库物理设计数据库物理设计将设计好的关系逻辑模式按照数据产生的来源建立不同的业务数据集(库),然后建立一个公共共享数据集(库),在这个数据库中建立共享视图,同时为各个数据集(库)进行用户设置和权限分配。物理数据库的分布也存在多种模式:所有的物理数据库存在于一台数据库服务器上,而且都由一个 DBMS 实例管理;4所有的物理数据库存在于一台数据库服务器上,由多个

13、DBMS 实例进行管理;所有的物理数据库分布在不同的数据库服务器上,但所有的 DBMS 采用一种类型;因选择的数据库不同,在具体的物理设计上也会有所不同,但要保证数据库的设计和管理符合规范,并保证制定的规范是可行的、可扩的,同时必须符合本规范的要求。在物理设计阶段,应根据数据的访问需求、频度、性能要求等设计索引和簇集,包括单属性索引、多属性索引、簇集索引等。4. Oracle 数据库命名规则数据库命名规则4.1 Oracle 数据库对象命名规则数据库对象命名规则为避免混乱,不得使用 Oracle 的关键字作为数据库对象的名字,Oracle 数据库的关键字参见下表。除非在定义对象名称时在该对象前

14、后加双引号,Oracle 各类对象都以大写的形式保存, 且在使用时不区分大小写。表 4-1 Oracle 数据库关键字表ACCESSAUDITCOMPRESSDESCADOBETWEENCONNECTDISTINCTALLBYCREATEDROPALTERCHARCURRENTELSEANDCHECKDATEEXLUSIVEANYCLUSTERDECIMALEXISTSASCOLUMNDEFAULTFILEASCCOMMENTDELETEFLOATFORLONGFCTFREESUCCESSFULFROMMAXEXTENTSPRIORSYNONYMGRANTMUNUSPRIVILEGESSYSD

15、ATEGROUPMODEPUBLICTABLEHAVINGMODIFYRAWTHENIDENTIFIEDNETWORKRENANETOIMMEDIATENOAUDITRESOURCETRIGGERINNOCOMPRESSREVOKEUIDINCREMENTNOTROWUNIONINDEXNOWALTROWIDUNIQUEINITIALNULLROWNUMUPDATEINSERTNUMBERROWSUSERINTEGEROFSELECTVALIDATEINTERSECTOFFLINESESSIONVALUESINTOONSETVARCHARISONLINESHAREVARCHAR2LEVELOP

16、TIONSIZEVIEWLIKEORSMALLINTWHENEVER5LOCKORDERSTARTWHEREWITH各类 Oracle 数据库对象的具体命名应遵守下面的规则。4.1.1 数据库名(Databases) 数据库名称由数据库系统的首字母拼音缩写加数据库编号组成,在只有一个数据库的情况下可不加数据库编号。数据库编号从 1 开始,并以增量 1 递增。4.1.2 实例名(Instances)如果一个数据库只有一个实例,则此实例与数据库名称相同,如使用 Oracle 和 Parallel Server 或 Oracle Real Application Clusters 产品,一个数据库可

17、能有多个实例,则采用数据库名加下划线加实例首字母拼音来命名。在数据库建设过程中,各单位应认真填写数据库、数据库实例名及对应用途关系表,并交数据库管理员妥善保存,此表格如此下。表 4-2 数据库实例表地点数据库数据库实例名用途备注实例 1数据库 1实例 2实例 1单位名数据库 2实例 24.1.3 表空间 (Tablespaces) 表空间分为两种,用来存储系统生成的临时数据的临时表空间(Temporary Tablespaces)和储存用户数据的永久表空间(Permanent Tablespace)。临时表空间命名为 TEMP_#,#表示编号(下同) ,如一个数据库只有一个临时表空间,则直接用

18、 TEMP 命名即可。永久表空间命名分为三段:TBS_SSSS_ZZZZ;TBS 表示这是一个表空间,SSSS 为系统代号,ZZZZ 为表空间类型,可以为 DATA 和 IDX,DATA 表示该表空间用来存储表对象,IDX 表示该表空间用来存储索引对象。系统代号应能反映该表空间中存储对象在系统中的总体功能,用功能名的首字母拼音表示。应用系统中的表和索引应该分别储存在两个表空间中,以达到提高性能的目的。4.1.4 数据文件(Data files)数据库文件的命名根据该文件所属表空间的名字进行,通过在表空间的名字后加下划线加编号实现,如_#.dbf 所示,数据库文件的名字用.dbf 作为后缀。64

19、.1.5 日志文件(Redo log files)采用_REDO_#.log 来命名数据库的日志文件。4.1.6 参数文件(Parameter files 和 Stored Parameter files)一个数据库对应一个参数文件,其命名用 init_.ora 表示。Oracle 9i 推出了存储参数文件的功能,如使用,其命名用 sp_.ora 表示。4.1.7 控制文件(Control files)采用_CRTL_#.ctl 来命名数据库的控制文件;为数据库名称,#为控制文件序号,控制文件以.ctl 作为后缀。4.1.8 回滚段(Rollback segments)回滚段用 RBS_#表示

20、,如一个数据库的回滚段为 RBS_01,RBS_02,在 Oracle 9i 版本数据库中推出了 Automatic Undo Management 功能,来实现对回滚信息的自动管理,此功能具有简化管理、提高效率的优点,因此如果使 Oracle 9i 以上版本数据库,则应使用此功能。4.1.9 表(Tables)表名为三段:Z_SSSS_XXXX,Z 为性质代号,SSSS 为系统代号(下同) 。XXXX 为自定义代号(下同) ,表的所有字母统一用大写表示。(1) 、性质代号包括 B、C、T、A,其含义如下:B 指原始数据表C 编码数据表T 工具数据表A 统计数据表、临时数据表或中间数据表(2)

21、 、系统代号应能反映该表所在系统的功能。开发者应该在系统设计阶段根据软件功能模块的划分来确定系统代号,系统代号用能表达模块功能的关键词的首字母来表示,应控制在 2 到 4 个字母之内,为便于理解和记忆,一个系统不宜有过多的系统代号。(3) 、自定义代号根据中文名称来确定,采用中文名称首字的全拼,后接其他字的中文拼音首字母,如果有两个表根据此方法命名出现重复则对两个表都用中文拼音的完整拼音来表示:自定义代号的长度应保持在 12 位以内。4.1.10 字段(Fields)字段名称字段名分为三段:F_ZZ_XXXX; F 表示这是一个字段,ZZ 表示字段的数据类7型代号,数据类型对应的数据类型代号如

22、下表:表 4-3 数据类型代号表代号数据类型CRCHAR,NCHARDTDATELGLONGRARAWLRLONG RAWNBNUMBERVCVARCHAR2,NVARCHAR2FLFLOATLBBLOG,CLOG,NCLOGBFBFILE另外,主表中的主键字段和附表中的外部键字段的类型和名称要完全相同。对于日期类型的数据,如果只保存日期数据,采用 yyyy/mm/dd 的格式,如果只保存时间数据,采用 hh24:mi:ss 的格式,如果同时保存日期和时间格式,采用 yyyy/mm/dd hh24:mi:ss 的格式。4.1.11 索引(Indexes)表主键(Primary Key)对应的索

23、引命名为 IDX_PK。如果表的唯一性索引(Unique Index)只有一个,则命名为 IDX_UK,如果表有多个唯一性索引,则在最后再加上一个编号,命名为 IDX_UK#,此处的#为一个数。如果一个表有多个其他的非唯一性索引,则按顺序为每一个索引加一个编号 IDX_#,此处的#为一个数。4.1.12 约束(Constraints)应对主键(Primary Key) 、唯一性约束(Unique)和引用约束(Referential Key)等约束进行命名,而不是使用系统自动生成的名字。主键约束命名为 PK_。如果一个表只有唯一性约束,则命名为 UK_。如果一个表有多个外键,则在名称的最后再加一

24、个编号,命名为 UK_#。如果一个表只有一个外键约束,则命名为 FK_。如果一个表有多个外键,则在名称的最后再加一个编号,命名为 FK_#。4.1.13 视图(Views)视图名分为三段:V_SSSS_XXXX。V 表示此对象为视图。84.1.14 同义词(Synonyms)同义词名分为三段:SYN_SSSS_XXXX。SYN 表示此对象为同义词。4.1.15 序列号(Sequences)序列号名分为三段:SQ_SSSS_XXXX。SQ 表示此对象为序列号。4.1.16 存储过程(Stored Procedures)存储过程名分为三段:PRO_SSSS_XXXX。PRO 表示此对象为存储过程。

25、4.1.17 函数(Functions) 函数分为三段:FUN_SSSS_XXXX。FUN 表示此对象为函数。4.1.18 程序包(Packages)和程序包体(Packages Bodies)程序包和相应程序包体的名字相同,分为三段:PAK_SSSS_XXXX。PAK 表示此对象为函数。包内过程和函数的命名规则与独立的存储过程和函数的命名相同,具体过程参见4.1.16 和 4.1.17。4.1.19 触发器(Triggers)触发器分为三段:TR_A|BI|U|D_。TR 表示这是一个触发器,后面跟着表示触发器操作条件的英文字母,A|BI|U|D(A|B 表示 after|before,I|

26、U|D 表示insert|update|delete 无该项操作则去掉相应的字母) ,后面再跟使用它的表名或视图名。4.1.20 角色(Roles)数据库角色分为两段:ROL_XXXX。ROL 表示这是一个数据库角色。4.1.21 用户(Users)数据库用户分为两段:USR_XXXX。USR 表示这是一个数据库用户。94.2 SQL、PL/SQL 源代码编写约定源代码编写约定4.2.1 变量命名规则为了提高 PL/SQL 程序的可读性,需要对 PL/SQL 程序的变量制定适当的命名规则。变量应该用中文拼音首字母来表示,应防止变量名与 Oracle 表的字段重名,因为如果重名,Oracle 会

27、将此名字解释为字段名。为了能够快速区分变量的作用域和类型,应对变量加上统一的前缀和后缀。在基本类型局部变量名家前缀 v_在全局变量名前加前缀 g_在常量名前加前缀 c_在过程和函数的参数函数变量前加 p_,对 IN OUT 类型和 OUT 类型的参数变量要分别加后缀 io 和 o。缺省没有前缀的参数变量都为 IN 类型。在 record collection 类型变量前加前缀 r_在%rowtype 类型变量前加前缀 rt_在 PL/SQL 类型变量前加前缀 t_在 table type 类型变量前加前缀 tt_在游标 cursor 类型变量前加前缀 cur_在例外 exception 类型变

28、量前加前缀 e_4.2.2 代码排版规则制定代码排版规则的目的是使用户更方便地理解程序的逻辑结构。缩进缩进设置为 4 个空格,Tab 设置为 4 个空格。通过缩进要把程序的条件、循环的逻辑结构显示出来。使用大小写所有的 SQL 和 PL/SQL 关键字用大小写,而所有的数据库表、字段、变量用小写。4.2.3 代码注释规则在 PL/SQL 程序段中的注释需要能说明问题,应该比代码易读;注释的长度不能太长,60 字符以内为宜;当代码发生改变时,注释应该及时更新。每个数据对象包括表、存储过程、函数和字段都必须作相关的注释说明。如果数据对象是函数或存储过程,还必须说明作者、功能和创立时间(修改时间)等

29、信息。格式如下:注释位置对 Oracle 数据库对象的整体注释应置于对象定义语法的下一行,AS 关键字之后(置于头部时,经 Oracle 编译后会丢失,不能保存到数据库中) ;同理,其他注释也要置于代码内部。PL/SQL 程序文件头部注释文件头部注释用于表明该文件的信息及版权格式,其格式如下:10/Copyright/文件名:/功能描述:/改版履历:/ 姓名 时间 描述/过程、函数、包注释对过程、函数、包必须加注释描述其主要功能,注释长度不超过 60 字符为宜,超过则作换行处理。其他需要加注释的地方: 每一个分支出,如:if else 处; 曾经出现 Bug 的地方(加注 Bug 号) ;声明变量时; 定义常量时,解释常量的意义; 其他比较难以理解的地方。4.2.4 其他要求Oracle8i 以上版本是对象关系型数据库管理系统(RDBMS) ,和传统的关系型数据库相比,增加了面向对象的功能。但为了提高数据库的兼容性,在进行数据库设计时应避免使用这些面向对象的功能。能够使用 SQL 语句实现功能时,不使用 PL/SQL。删除所有无用的变量。如果要用变量来表示一个字段和多个字段,尽量使用%TYPE 和%ROWTYP

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论