数据库设计经验谈重点文档格式.docx
- 文档编号:13743695
- 上传时间:2022-10-13
- 格式:DOCX
- 页数:12
- 大小:32.78KB
数据库设计经验谈重点文档格式.docx
《数据库设计经验谈重点文档格式.docx》由会员分享,可在线阅读,更多相关《数据库设计经验谈重点文档格式.docx(12页珍藏版)》请在冰豆网上搜索。
这里有10个技巧专门涉及系统生成的主键的正确用法,还有何时以及如何索引字段以获得最佳性能等。
第4部分-保证数据完整性
讨论如何保持数据库的清晰和健壮,如何把有害数据降低到最小程度。
第5部分-各种小技巧
不包括在以上4个部分中的其他技巧,五花八门,有了它们希望你的数据库开发工作会更轻松一些。
考察现有环境
在设计一个新数据库时,你不但应该仔细研究业务需求而且还要考察现有的系统。
大多数数据库项目都不是从头开始建立的;
通常,机构内总会存在用来满足特定需求的现有系统(可能没有实现自动计算。
显然,现有系统并不完美,否则你就不必再建立新系统了。
但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。
一般来说,考察现有系统对你绝对有好处。
定义标准的对象命名规范
一定要定义数据库对象的命名规范。
对数据库表来说,从项目一开始就要确定表名是采
用复数还是单数形式。
此外还要给表的别名定义简单规则(比方说,如果表名是一个单词,别名就取单词的前4个字母;
如果表名是两个单词,就各取两个单词的前两个字母组成4个字母长的别名;
如果表的名字由3个单词组成,你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母,结果还是组成4字母长的别名,其余依次类推对工作用表来说,表名可以加上前缀WORK_后面附上采用该表的应用程序的名字。
表内的列[字段]要针对键采用一整套设计规则。
比如,如果键是数字类型,你可以用_N作为后缀;
如果是字符类型则可以采用_C后缀。
对列[字段]名应该采用标准的前缀和后缀。
再如,假如你的表里有好多“money”字段,你不妨给每个列[字段]增加一个_M后缀。
还有,日期列[字段]最好以D_作为名字打头。
检查表名、报表名和查询名之间的命名规范。
你可能会很快就被这些不同的数据库要素的名称搞糊涂了。
假如你坚持统一地命名这些数据库的不同组成部分,至少你应该在这些对象名字的开头用Table、Query或者Report等前缀加以区别。
如果采用了MicrosoftAccess,你可以用qry、rpt、tbl和mod等符号来标识对象(比如tbl_Employees。
我在和SQLServer打交道的时候还用过tbl来索引表,但我用sp_company(现在用sp_feft_标识存储过程,因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。
我在实现SQLServer2000时用udf_(或者类似的标记标识我编写的函数。
工欲善其事,必先利其器
采用理想的数据库设计工具,比如:
SyBase公司的PowerDesign,她支持PB、VB、Delphe等语言,通过ODBC可以连接市面上流行的30多个数据库,包括dBase、FoxPro、VFP、SQLServer等,今后有机会我将着重介绍PowerDesign的使用。
获取数据模式资源手册
正在寻求示例模式的人可以阅读《数据模式资源手册》一书,该书由LenSilverston、W.H.Inmon和KentGraziano编写,是一本值得拥有的最佳数据建模图书。
该书包括的章节涵盖多种数据领域,比如人员、机构和工作效能等。
其他的你还可以参考:
[1]萨师煊王珊著数据库系统概论(第二版高等教育出版社1991、[2][美]StevenM.Bobrowski著Oracle7与客户/服务器计算技术从入门到精通刘建元等译电子工业出版社,1996、[3]周中元信息系统建模方法(下电子与信息化1999年第3期,1999
畅想未来,但不可忘了过去的教训
我发现询问用户如何看待未来需求变化非常有用。
这样做可以达到两个目的:
首先,你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈;
其次,你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。
一定要记住过去的经验教训!
我们开发人员还应该通过分享自己的体会和经验互相帮助。
即使用户认为他们再也不需要什么支持了,我们也应该对他们进行这方面的教育,我们
都曾经面临过这样的时刻“当初要是这么做了该多好..”。
在物理实践之前进行逻辑设计
在深入物理设计之前要先进行逻辑设计。
随着大量的CASE工具不断涌现出来,你的设计也可以达到相当高的逻辑水准,你通常可以从整体上更好地了解数据库设计所需要的方方面面。
了解你的业务
在你百分百地确定系统从客户角度满足其需求之前不要在你的ER(实体关系模式中加入哪怕一个数据表(怎么,你还没有模式?
那请你参看技巧9。
了解你的企业业务可以在以后的开发阶段节约大量的时间。
一旦你明确了业务需求,你就可以自己做出许多决策了。
一旦你认为你已经明确了业务内容,你最好同客户进行一次系统的交流。
采用客户的术语并且向他们解释你所想到的和你所听到的。
同时还应该用可能、将会和必须等词汇表达出系统的关系基数。
这样你就可以让你的客户纠正你自己的理解然后做好下一步的ER设计。
创建数据字典和ER图表
一定要花点时间创建ER图表和数据字典。
其中至少应该包含每个字段的数据类型和在每个表内的主外键。
创建ER图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。
越早创建越能有助于避免今后面临的可能混乱,从而可以让任何了解数据库的人都明确如何从数据库中获得数据。
有一份诸如ER图表等最新文档其重要性如何强调都不过分,这对表明表之间关系很有用,而数据字典则说明了每个字段的用途以及任何可能存在的别名。
对SQL表达式的文档化来说这是完全必要的。
创建模式
一张图表胜过千言万语:
开发人员不仅要阅读和实现它,而且还要用它来帮助自己和用户对话。
模式有助于提高协作效能,这样在先期的数据库设计中几乎不可能出现大的问题。
模式不必弄的很复杂;
甚至可以简单到手写在一张纸上就可以了。
只是要保证其上的逻辑关系今后能产生效益。
从输入输出下手
在定义数据库表和字段需求(输入时,首先应检查现有的或者已经设计出的报表、查询和视图(输出以决定为了支持这些输出哪些是必要的表和字段。
举个简单的例子:
假如客户需要一个报表按照邮政编码排序、分段和求和,你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
报表技巧
要了解用户通常是如何报告数据的:
批处理还是在线提交报表?
时间间隔是每天、每周、每月、每个季度还是每年?
如果需要的话还可以考虑创建总结表。
系统生成的主键在报表中
很难管理。
用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。
这样的检索性能比较低而且容易引起混乱。
理解客户需求
看起来这应该是显而易见的事,但需求就是来自客户(这里要从内部和外部客户的角度考虑。
不要依赖用户写下来的需求,真正的需求在客户的脑袋里。
你要让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中。
一个不变的真理是:
“只有我看见了我才知道我想要的是什么”必然会导致大量的返工,因为数据库没有达到客户从来没有写下来的需求标准。
而更糟的是你对他们需求的解释只属于你自己,而且可能是完全错误的。
第2部分-设计表和字段
检查各种变化
我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。
比方说,姓氏就是如此(注意是西方人的姓氏,比如女性结婚后从夫姓等。
所以,在建立系统存储客户信息时,我倾向于在单独的一个数据表里存储姓氏字段,而且还附加起始日和终止日等字段,这样就可以跟踪这一数据条目的变化。
采用有意义的字段名
有一回我参加开发过一个项目,其中有从其他程序员那里继承的程序,那个程序员喜欢用屏幕上显示数据指示用语命名字段,这也不赖,但不幸的是,她还喜欢用一些奇怪的命名法,其命名采用了匈牙利命名和控制序号的组合形式,比如cbo1、txt2、txt2_b等等。
除非你在使用只面向你的缩写字段名的系统,否则请尽可能地把字段描述的清楚些。
当然,也别做过头了,比如Customer_Shipping_Address_Street_Line_1,虽然很富有说明性,但没人愿意键入这么长的名字,具体尺度就在你的把握中。
采用前缀命名
如果多个表里有好多同一类型的字段(比如FirstName,你不妨用特定表的前缀(比如CusLastName来帮助你标识字段。
时效性数据应包括“最近更新日期/时间”字段。
时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。
标准化和数据驱动
数据的标准化不仅方便了自己而且也方便了其他人。
比方说,假如你的用户界面要访问外部数据源(文件、XML文档、其他数据库等,你不妨把相应的连接和路径信息存储在用户界面支持表里。
还有,如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修
改记录状态等,那么产生工作流的数据也可以存放在数据库里。
预先安排总需要付出努力,但如果这些过程采用数据驱动而非硬编码的方式,那么策略变更和维护都会方便得多。
事实上,如果过程是数据驱动的,你就可以把相当大的责任推给用户,由用户来维护自己的工作流过程。
标准化不能过头
对那些不熟悉标准化一词(normalization的人而言,标准化可以保证表内的字段都是最基础的要素,而这一措施有助于消除数据库中的数据冗余。
标准化有好几种形式,但ThirdNormalForm(3NF通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。
简单来说,3NF规定:
*表内的每一个值都只能被表达一次。
*表内的每一行都应该被唯一的标识(有唯一键。
*表内不应该存储依赖于其他键的非键信息。
遵守3NF标准的数据库具有以下特点:
有一组表专门存放通过键连接起来的关联数据。
比方说,某个存放客户及其有关定单的3NF数据库就可能有两个表:
Customer和Order。
Order表不包含定单关联客户的任何信息,但表内会存放一个键值,该键指向Customer表里包含该客户信息的那一行。
更高层次的标准化也有,但更标准是否就一定更好呢?
答案是不一定。
事实上,对某些项目来说,甚至就连3NF都可能给数据库引入太高的复杂性。
为了效率的缘故,对表不进行标准化有时也是必要的,这样的例子很多。
曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均40秒降低到了两秒左右。
虽然我不得不这么做,但我绝不把数据表的非标准化当作当然的设计理念。
而具体的操作不过是一种派生。
所以如果表出了问题重新产生非标准化的表是完全可能的。
MicrosoftVisualFoxPro报表技巧
如果你正在使用MicrosoftVisualFoxPro,你可以用对用户友好的字段名来代替编号的名称:
比如用CustomerName
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 设计 经验谈 重点