数据库设计规范标准.docx
- 文档编号:3712089
- 上传时间:2022-11-24
- 格式:DOCX
- 页数:14
- 大小:24.31KB
数据库设计规范标准.docx
《数据库设计规范标准.docx》由会员分享,可在线阅读,更多相关《数据库设计规范标准.docx(14页珍藏版)》请在冰豆网上搜索。
数据库设计规范标准
关系型数据库设计规
文档类别使用对象4
1.概述5
1.1简介5
1.2术语定义5
1.3参考资料5
1.4版本更新记录5
2.数据库设计的目标6
3.数据库的特征6
3.1完整性约束6
3.1.1notnull约束7
3.1.2缺省值7
3.1.3unique约束7
3.1.4primarykey约束7
3.1.5参照完整性约束8
3.1.6check约束8
3.2存储过程8
3.3触发器9
3.4事务处理9
3.4.3事务与一致性10
3.4.4事务和恢复10
3.5并发处理10
3.5.3死锁11
3.5.4读一致性11
3.6序号生成器11
3.7视图11
3.7.3安全性12
3.7.4逻辑数据独立性12
4.调整数据库设计以提高系统性能13
4.1建立有用的性能标准13
4.2数据库的规化13
4.3通过非规化设计提高数据库的效率13
4.3.3非规化的原因13
4.3.4非规化技术14
4.3.5进行非规化处理时的注意事项14
4.4表的大小15
4.4.3表是否过小15
4.4.4表是否过大15
4.4.5如何减小表的尺寸15
4.5记录的大小15
4.5.3列有最佳的位置吗15
4.5.4存在最佳的记录大小吗15
4.5.5记录是否过小15
4.5.6记录是否过大15
4.5.7如何减小记录16
4.5.8总结16
5.其它16
文档类别使用对象
文档类别
该文档是通用软件公司的关系型数据库的设计规,是技术文档。
使用对象
该文档使用人员包括:
Ø开发本部总经理
Ø各产品部、事业部的经理、项目经理、设计人员
Ø软件中心负责人、设计人员
Ø公司总经理
1.概述
1.1简介
本文档总结了公司进行多年来的SYBASE数据库设计经验,目的将公司进行数据库设计的经验积累下来,实现设计经验的复用,为项目评审与项目质量保证提供进行检查的依据。
本规从数据库设计的目的、数据库的各个特征、数据库的规化等各个方面进行论述,对进行SYBASE数据库的设计提供了很好的依据。
1.2术语定义
1.3参考资料
《Powerbuilder开发设计中的数据库设计》晓通数据库研究与发展中心公司
1.4版本更新记录
版本/修订版
日期
修改记录
备注
1.0
10/10/99
初始版本
2.数据库设计的目标
好的数据库物理设计应当充分考虑应用的需求和开发工具的特征,应当充分利用和挖掘数据库的功能。
一流的数据库设计会给整个应用系统带来以下的好处:
Ø维护容易。
当需求发生变化时,优良的数据库设计会使应用系统容易地适应这种变化。
Ø编程简单。
由于数据库设计充分挖掘了数据库的功能,所以应用程序的复杂度可以明显降低。
Ø加快开发速度。
因为数据库设计充分地考虑了需求和开发工具的特征,所以开发人员会感到左右逢源,得心应手,从而可以加快开发速度。
Ø系统具有良好的整体运行效率。
3.数据库的特征
Ø完整性约束。
完整性约束允许在表上定义某种约束条件,这些条件作为表定义的一部分存在,从而强制表中的数据满足一定的规则。
Ø存储过程。
存储过程是由流控制语句(if…else)和SQL语句书写的过程,这个过程经过编译和优化后存储在数据库服务器中,使用时只要调用即可。
Ø触发器。
触发器是一种特殊的存储过程,不同的是这种过程不是由程序调用来执行,而是通过数据库数据的更新自动地“触发”执行。
Ø事务处理:
事务是最小的逻辑工作单元,在这个单元中对数据库所有的更新要么全成功要么全失败。
Ø并发处理。
允许用户在没有冲突的情况下更新表中不同的行。
行级锁和页级锁对联机事务处理非常有用。
Ø序号生成器。
数据库可以自动生成连续的序号供应用程序使用。
Ø遵守工业标准的SQL。
Ø视图。
视图是原始数据库表的变换,可给应用程序带来安全性、简单性和独立性。
Ø分布处理。
数据可以分布在网络的多个点上,数据本身支持分布查询和分布修改。
Ø数据复制。
数据可以在网络的多个数据库点相互复制。
3.1完整性约束
完整性约束是数据库用于维护数据库完整性的一种机制。
这种约束是表定义的一部分,是部的。
与在应用程序中维护数据库的完整性不同,它的代价小而且性能高。
完整性约束有以下两点作用:
1.使企业的规则与数据库联系起来。
2.防止操作员或终端用户输入错误的数据,破坏数据库的完整性。
完整性约束有以下几种:
●notnull约束
缺省值
●unique约束
●primarykey约束
●foreignkey约束
●check约束
3.1.1notnull约束
notnull的含义是列中不能有空值。
notnull在创建表时定义。
notnull约束限定了列中必须有值,但不能限定列中可以有什么值,因此它常常与其它的约束配合使用。
3.1.2缺省值
缺省值是在数据录入时,若用户没有输入数据,数据库自动输入的值。
下面是定义缺省时应注意的一些事项:
要确保列宽对缺省值来说足够大。
要注意缺省值与规则间的冲突,确保缺省值为规则所允许,否则,缺省值会被规则忽略掉。
3.1.3unique约束
唯一列是这样的列,它的值不能在表中重复出现。
注意,唯一列与主键不同,主键可用来唯一地标识表中的一行(不能有空值),而唯一列仅仅表示该列的值不能在表中重复出现(可以有空值)。
可以在一个列上定义唯一列,也可以在表上定义唯一列,也可以在表上对多个列定义唯一列。
3.1.4primarykey约束
每个表中都应有主键,主键唯一标识表中的行。
选择主键应注意以下几点:
●选择数据是唯一的列。
●选择数据值不会改变的列。
主键的目的是唯一地标识一行,不含有用于其它目的的数据,选择一般不需要改变主键值的列。
●选择不含有空值的列。
根据定义,主键列不允许输入空值。
●选择短的和数值型的列。
●避免选择联合主键。
虽然允许联合主键,但很难满足以上四点要求。
3.1.5参照完整性约束
参照完整性约束用来约束两个表间的关系。
1.空值和外部键
对于缺省(无notnull或check语句)的情况,外部键约束为组合外部键实施“无匹配”规则。
通过使用check和notnull也可使用全部或部分规则:
●在组合外部键中实施全匹配规则,要求键的全部要么都为空要么都不为空。
●在一般情况下,不能使用参照完整性在组合键中实施部分匹配规则。
部分匹配规则要求键的非空部分出现在引用表的主键的对应部分上,这种情况一般要用触发器来处理。
2.父表和子表的关系
父表和子表的关系决定于在子表的外部键上定义的其它类型的完整性约束。
●在外部键上没有约束。
●在外部键上有非空约束。
●在外部键上有unique约束。
●在外部键上有unique和notnull约束。
3.1.6check约束
当需要根据逻辑表达式来限定列的值域时,可以用check完整性约束。
check约束的写法和where子句的写法一样,但它有如下的限制:
●条件必须是能够利用更新行中的值来求值的表达式。
●条件中不能有子查询或序号。
●条件中不能含有函数。
●条件中不能含有伪列。
3.2存储过程
存储过程是由流控制和SQL语句书写的过程,这个过程经编译和优化后存储在数据库服务器中,使用时只要调用即可。
使用存储过程有以下优点:
●存储过程的能力大大增强了SQL语言的功能和灵活性。
存储过程可以用流控制语句编写,有很强的灵活性,可以完成复杂的判断和较复杂的运算。
●可保证数据的安全性和完整性。
♦通过存储过程可以使没有权限的用户在控制之下间接地寸取数据库,从而保证数据的安全。
♦通过存储过程可以使相关的动作在一起发生,从而可以维护数据库的完整性。
●在运行存储过程前,数据库已对其进行了语法和句法分析,并给出了优化执行方案。
这种已经编译好的过程可极改善SQL语句的性能。
由于执行SQL语句的大部分工作已经完成,所以存储过程能以极快的速度执行。
●可以降低网络的通信量。
●使体现企业规则的运算程序放入数据库服务器中,以便:
♦集中控制。
♦当企业规则发生变化时在服务器中改变存储过程即可,无须修改任何应用程序。
3.3触发器
触发器是一种特殊的存储过程,它在插入、删除或修改特定表中的数据时触发执行,它比数据库本身标准的功能有更精细和更复杂的数据控制能力。
数据库触发器有以下的作用:
●安全性。
可以基于数据库的值使用户具有操作数据库的某种权利。
♦可以基于时间限制用户的操作。
♦可以基于数据库中的数据限制用户的操作。
●审计。
可以跟踪用户对数据库的操作。
♦审计用户操作数据库的语句。
♦把用户对数据库的更新写入审计表。
●实现复杂的数据完整性规则。
♦实现非标准的数据完整性检查和约束。
触发器可产生比规则更复杂的限制。
与规则不同,触发器可以引用列或数据库对象。
♦提供可变的缺省值。
●实现复杂的非标准的数据库相关完整性规则。
触发器可以对数据库中相关的表进行连环更新。
♦在修改或删除时级联修改或删除其它表中的与之匹配的行。
♦在修改或删除时把其它表中的与之匹配的行设成NULL值。
♦在修改或删除时把其它表中的与之匹配的行级联成缺省值。
♦触发器能够拒绝或“回退”那些破坏相关完整性的变化,取消试图进行数据更新的事物。
当插入一个与主键不匹配的外部键时,这种触发器会起作用。
●同步实时地复制表中的数据。
●自动计算数据值,如果数据的值达到了一定的要求,则进行特定的处理。
3.4事务处理
事务是这样一种机制,它确保多个SQL语句被当作单个工作单元来处理。
事务具有以下的作用:
●一致性:
同时进行的查询和更新彼此不会发生冲突,其他用户不会看到发生了变化但尚未提交的数据。
●可恢复性:
一旦系统故障,数据库会自动地完全恢复未完成的事务。
3.4.3事务与一致性
事务是完整性的单位,一个事务的执行是把数据库从一个一致的状态转换成另一个一致的状态。
因此,如果事务孤立执行时是正确的,但如果多个事务并发交错地执行,就可能相互干扰,造成数据库状态的不一致性。
在多用户环境中,数据库必须避免同时进行的查询和更新发生冲突。
这一点是很重要的,如果正在被处理的数据能够在该处理正在运行时被另一用户的修改所改变,那么该处理的结果会是不明确的。
不加控制的并发存取会产生以下的几种错误。
丢失修改(lostupdates)
当多个事务并发修改一个数据时,不加控制会得出错误的结果,一个修改会覆盖掉另一个修改。
这种丢失修改叫“写—写依赖”(Write—WriteDependency)。
读的不可重复性
当多个事务按某种时间顺序存取若干数据时,如果对并发存取不加控制,也会产生错误。
这叫做“读—写依赖”(Read—WriteDependency)。
脏读(dirtydata),读的不一致性
这种脏读或说读的不一致性叫“写—读依赖”(Write—ReadDependency)。
光标带来的当前值的混乱
事务在执行过程中它在某个表上的当前位置是由光标表示的。
光标指向当前正处理的记录。
当处理完该条记录后,则指向下一条记录。
在多个事务并发执行时,一个事务的修改可能产生副作用,使与这些光标有关的事务出错。
未释放修改造成连锁退出
一个事务在进行修改操作的过程中可能会发生故障,这时需要将已做的修改回退(Rollback)。
如果在已进行过或已发现错误尚未复原之前允许其它事务读已做过的修改(脏读),则会导致连锁退出。
一事务在对一表更新时,另外的事务却修改或删除此表的定义。
3.4.4事务和恢复
数据库本身肩负着管理事务的责任。
事务是最小的逻辑工作单元,在这个工作单元中,对数据库的所有更新工作,要么必须全部成功,要么必须全部失败(回退)。
只要应用程序指定了某段程序为一个事务并做了相应的处理,数据库系统会自动维护事务本身的特性。
3.5并发处理
数据库的特点就是数据的集中管理和共享。
在通常情况下总是有若干个事务并发地运行,这些并行的事务可能并发地存取相同的数据。
因此,数据库管理系统的一个重要任务就是要有一种机制去保证这种并发的存取和修改不破坏数据的完整性,确保这些事务能正确地运行并取得正确的结果。
事务并发执行时若不加控制的话将导致不正确的结果和数据库的不一致状态。
为保证数据库数据正确地反映所有事务的更新以及在一事务修改数据时其它事务不同时修改这个数据,数据库系统用锁来控制对数据的并发存取。
3.5.3死锁
当事务T1想要锁住的资源已被事务T2锁住,而T2想要锁住的资源也被T1锁住时,T1要等待T2释放资源,T2要等待T1释放资源。
这样,两个事务互相等待造成死锁。
当数据库检测到死锁时,检测到死锁的事务被告知出错,回退当前语句。
通常被告知出错的事务应显式地回退整个事务,但用户也可不管被锁住的资源直接提交或等会儿再重新做。
数据库会自动检测到死锁并恢复。
在应用中,为避免死锁,应在事务的开始加尽量强的锁。
在应用系统中,存取同一表的各种程序应使用相同的次序,这会避免死锁。
3.5.4读一致性
读一致性是数据库事务处理的重要特性,其含义为:
一事务对数据库的任何更新都在本事务见到,数据库的数据对本事务是一致的。
其它事务未提交的更新,在本事务见不到。
即其它事务的任何更新,只要还没提交,则对本事务而言,就好象不存在一样。
3.6序号生成器
在很多应用系统要用到序号。
由于序号是连续生成的,在大型系统中,会有多个用户同时申请下一个序号,序号生成便成了应用系统的瓶颈问题。
为了解决这个问题,大型数据库都增加了序号对象。
通过序号对象可以自动生成序号,多个用户可以并发读取,无须互相等待。
3.7视图
视图是原始数据库数据的一种变换,是查看表中数据的另外一种方式。
可以将视图看成一个移动的窗口,通过它可以看到感兴趣的数据。
视图是从一个或多个实际表中获得的,这些表的数据存放在数据库中。
那些用于产生视图的表叫做视图的基表。
一个视图也可从另一视图中产生。
视图的定义存在数据库中,与此定义相关的数据并没有再存一份于数据库中。
通过视图看到的数据存放在基表中。
视图看上去非常象数据库的物理表,对它的操作同任何其它的表一样。
当通过视图修改数据时,实际上是在改变基表中的数据;相反地,基表数据的改变也会自动反映在由基表产生的视图中。
由于逻辑上的原因,有些视图可以修改对应的基表,有些则不能(仅仅能查询)。
视图有以下的作用:
●简单性。
看到的就是需要的。
视图不仅可以简化用户对数据的理解,也可以简化他们的操作。
那些被经常使用的查询可以被定义为视图,从而使得用户不必为以后的操作每次指定全部的条件。
●安全性。
通过视图用户只能查询和修改他们所能见到的数据。
数据库中的其它数据则既看不见也取不到。
数据库授权命令可以使每个用户对数据库的检索限制到特定的数据库对象上,但不能授权到数据库的行和特定的列上。
通过视图,用户可被限制在数据的不同子集上:
♦基表的行的子集上。
♦基表的列的子集上。
♦基表的行和列的子集上。
♦多个基表的连接所限定的行上。
♦基表的数据的统计汇总上。
♦另一行视图的一个子集上,或是一些视图和基表合并后的子集上。
●逻辑数据独立性。
视图可帮助用户屏蔽真实表结构变化带来的影响。
3.7.3安全性
视图的安全性可以防止未授权的用户查看特定的行或列。
使用户只能看到表中特定行的方法如下:
1.在表中增加一个标志用户的列;
2.建立视图,使用户只能看到标有自己用户名的列;
3.把视图授权给其他用户。
3.7.4逻辑数据独立性
视图可以在以下几个方面使程序与数据独立:
1.如果应用建立在数据库表上,当数据库表发生变化时,可以在表上建立视图,通过视图屏蔽表的变化,从而应用程序可以不动。
2.如果应用建立在数据库表上,当应用发生变化时,可以在表上建立视图,通过视图屏蔽应用的变化,从而使数据库表不动。
3.如果应用建立在视图上,当数据库表发生变化时,可以在表上修改视图,通过视图屏蔽表的变化,从而应用程序可以不动。
4.如果应用建立在视图上,当应用发生变化时,可以在表上修改视图,通过视图屏蔽应用的变化,从而使数据库表不动。
4.调整数据库设计以提高系统性能
4.1建立有用的性能标准
需遵循下列标准:
●单条记录的更新应当在1秒钟之。
●多条记录的更新不超过10秒钟。
●对于少于4个表的、数据有一定限度的查询,响应时间应在5秒钟之。
●对于其它的数据有一定限度的多表查询应在10秒钟之。
●整个表的查询时间应在30秒钟之。
但是,不要盲目地接受性能标准,有些极端可除外。
4.2数据库的规化
从关系模型的角度来看,标准的表应当满足第三式(3NF)。
这样的表结构最容易维护,而且最具有可维护性。
对数据库进行规化处理具有以下的优点:
●因为表的列数减少了,所以搜索、排序、创建索引的速度可以加快。
●因为表减小了,所以按照索引查询的速度加快了。
●可以更好地使用段来控制数据的物理存储。
●每个表可以只有很少的索引,因此可以加快更新速度。
●可以减少空值和冗余,使数据库更紧凑。
●因为减少了冗余的数据,可以使触发器的执行速度更快。
●减少数据的不规则性。
●规化使数据库的维护和修改变得更容易。
数据库经过规化后,数据的查询虽然需要更多的连接操作,但对于具有索引的列,连接的速度是比较快的。
然而,全部采用规化的设计可能达不到最佳的性能。
因此,虽然推荐尽量采用第三式的设计,但是在性能得不到满足的情况下,需要非规化的方法提高性能。
4.3通过非规化设计提高数据库的效率
4.3.3非规化的原因
在进行数据库的设计时,出于对数据库执行效率的考虑,可以采用非规化的方法。
所谓非规化的方法,就是在数据库的设计中适当地降低数据库的式。
在下列情况下,通常要考虑进行非规化处理:
●大量频繁的查询过程所涉及的表都需要进行连接。
●主要的应用程序在执行时要将表连接起来进行查询。
●对数据库的计算需要临时表或进行复杂的查询。
4.3.4非规化技术
对数据库进行非规化的目的在于提高应用程序的效率,但非规化处理毕竟会增加数据冗余,会带来相应的数据完整性问题。
因此,在考虑非规化处理时,要慎重考虑下面的几个问题:
●哪些是比较紧急的事务,哪些事务对响应时间有要求。
●这些事务的执行频率有多高。
●这些紧急的事务要操作哪些表以及表中的哪些列,每次要访问多少行。
●哪种类型的事务执行频率最高:
查询、插入、删除还是更新。
●通常的排序顺序是什么。
●哪些工作会并发执行。
●经常访问的表有多大。
●哪些需要进行统计计算。
●数据的物理位置在哪里。
常用的非规化技术有以下几种:
●增加冗余列。
●增加派生列。
●合并表。
其它技术还有:
●重复表。
●分割表(水平分割和垂直分割)。
4.3.5进行非规化处理时的注意事项
非规化的优点:
●可以减少查询操作所需的连接。
●可以减少外部键的数量。
●减少了索引的数量,节省了存储空间。
●可以预先进行统计计算。
●减少了表的数量。
非规化的缺点:
●数据的更新速度会减慢。
●当应用程序改变时,可能要对规化程度重新进行考察。
●会增加表的大小。
●在某些情况下会使编码复杂化。
无论使用哪种规化方法,都必须保证数据的完整性。
为此:
●建立触发器,保证冗余、派生的以及重复的数据和基本的数据保持一致。
●通过应用程序中的事务逻辑来保证非规化数据在更新时保持一致。
●批命令,在适当的时间间隔运行批命令或存储过程来保证数据的完整性。
4.4表的大小
4.4.3表是否过小
表的大小无下限,但过小可能会产生空间浪费。
4.4.4表是否过大
事实上,表的大小无上限,但为了满足响应时间和重建索引的需要,最好限制表的大小。
4.4.5如何减小表的尺寸
通过垂直分割和水平分割来减小表的尺寸。
4.5记录的大小
4.5.3列有最佳的位置吗
没有。
但在定义表时,把主键列放在最前列,然后是常用的列,至少会使文档好些。
4.5.4存在最佳的记录大小吗
没有,但最好避免刚超过半页的记录。
4.5.5记录是否过小
记录的大小没有下限。
4.5.6记录是否过大
没有,但最好避免刚超过半页的记录。
4.5.7如何减小记录
1.分割记录。
2.静态分割与动态分割。
3.应用程序分割。
4.数据类型分割。
5.使用小数据类型。
4.5.8总结
●每页记录数为一个整数。
●记录的最大尺寸为1962字节。
●每页的记录大小没有下限,但上限是256(最新版本为1024)。
●固定长度的记录有4字节的额外开销。
●可变长度的记录有4字节固定的额外开销和每列2+1个字节的额外开销。
5.其它
●数据库设计的工具:
象PowerDesigner等。
●数据仓库技术的应用:
OLTP和OLAP的数据分开设计。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 设计规范 标准
![提示](https://static.bdocx.com/images/bang_tan.gif)