数据库设计的灵活性考虑 |
| 作者：王宏福1，马涛 文章来源：网络 点击数： 更新时间：2006-4-20 |
|
【摘 要】数据库技术是计算机科学中发展最快的领域之一，也是应用最广的技术之一，它已成为计算机信息系统与应用系统的核心技术和重要基础。文章提出数据库设计中所出现的各种问题，并归纳分析了解决这些问题的种种途径。
【关键词】数据库设计；数据冗余；数据库管理系统
一、引言
近年来，随着多媒体技术、空间数据库技术和计算机网络的飞速发展，数据库系统的发展十分迅速，应用领域愈来愈广，企事业单位、政府部门的行政管理、办公自动化；企业生产计划管理；军队物资管理；银行财务管理；铁路、民航飞机票预定系统；铁路车次调度系统；宾馆、酒店房间预定系统；图书馆管理；政府部门的计划和统计系统；人口普查；气象预报；地震，勘探等大量数据的贮存和统计分析；以及最近google推出的全球卫星定位系统、手机GPRS定位系统，其背后都是一个规模巨大的数据库。
如何合理高效地为政府管理人员或企业高层决策人员、设计数据库管理系统服务已成为当务之急。好的灵活的数据库设计，既能给前台应用程序的设计带来简便，又能给后台数据库的编码和扩充，和系统的维护带来极大的便利。现在关系型数据库已成为业界的主流，而我们讨论的也主要是基于关系型数据库的。
二、解决数据库设计中所出现的各种问题的途径
（一）需求分析采集
设计一个数据库，第一件的事情就是搞好用户需求分析，需求分析是对现实世界深入了解的过程，数据库能否正确地反映现实世界，主要决定于需求分析。而需求分析的采集主要是由设计人员和该单位有关工作人员合作进行的。需求分析的结果整理成需求说明。需求说明是数据库技术人员和应用单位的工作人员取得共识的基础，必须得到有关管理人员确认。需求说明经过评审后，才成为正式的需求文档，为下一步的数据库设计打好基础。在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
（二）考察现有系统
在需求分析采集的过程中，不仅要耐心地和用户讨论业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。
（三）分析各种可能的变化
在具体设计每一个字段时一定要从长远角度考虑它以后的扩充，给出一定的预留空间。这样你设计的数据库的伸缩性就非常好。以后在系统升级维护时就非常容易，不至于重构整个系统。这方面的一个典型例子就是：身份证的长度问题，以前是15位，现在是18位，如果你当时设计成15位的话，为那3位的扩充你将会付出多大代价啊。
（四）数据库逻辑性设计
键选择原则：
1.键设计原则为关联字段创建外键。
所有的键都必须唯一。
避免使用复合键。
外键总是关联唯一的键字段。
2.使用系统生成的主键。设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
（五）关系模式规范化的度
对数据库进行关系模式规范化不仅有助于消除数据库中的数据冗余、删除、插入等异常出错的可能性，而且，还使你的设计比较科学、规范，同时也使你的系统的伸缩性，以及后期维护特别容易。
3NF通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。其定义为：关系R中若不存在这样的码X、属性组Y及非主属性Z(Z包含于Y)使得X决定Y、Y不依赖于X、Y决定Z成立，则称R属于3NF。
此外，还有BCNF，4NF、5NF等更高层次的关系规范化，但是不是关系规范化的程序越高，就越实用呢，就越能满足我们的要求呢？我只能用不一定来回答，因为这要视情况而定。其实，在有些项目中是非常慎用关系模式的。因为如果规范化的程序越高，势必要将一个大表拆分成几个小表，在这些小表中用一些键值进行联接，在查询时就需要对多个表进行连接，而联接时最易产生迪卡尔积，这样查询结果集就成几何倍增，非常影响查询的效率。所以为了追求效率我们有时不对表进行关系规范化也是必要的，这样的例子很多。
（六）要为尽量减轻前台的编码而工作
不要养成对数据库的复杂操作都放到前台来管理的习惯，这样会使你的程序的可读性非常差，同时也造成数据的不一致，而且会对后期的维护带来很大隐患。这一块完全应该是DBA的工作。这方面的典型例子就是数据的更新和删除操作。如果我们把这两种操作都放在前台来管理的话，就需要对多个表进行操作，操作不当的话，就会造成数据不一致。而如果DBA在后台对这几个表搭建关系的话，你在前台只要对一个主表进行操作，那么其他的几个从表就会自动更新。由此可见DBA的工作的重要性。所以，请不要把数据的管理工作都放到前台来做，因为这不是体现你编程能力的时机。
（七）命名规范一定要统一
目前有两种编码风格：微软式和西班牙式。
典型例子如果：
微软式：StuInfo
西班牙式：Stu_Info
我们要视大家的编程习惯酌情选用。最坏的情况是大杂烩的编程风格，这样编码只会让后期的维护非常困难。所以在设计时，关于这一块的设计一定要统一，一定要作为制度来执行。
（八）字段的设计原则
1.每个表中都应该添加的3个有用的字段：
dRecordCreationDate，在VB下默认是Now()，而在SQL Server
下默认为GETDATE()
sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT
USER nRecordVersion，记录的版本标记；有助于准确说明记录中出现null数据或者丢失数据的原因。
2.使用角色实体定义属于某类别的列。例如：用STUDENT实体和STUDENT_TYPE实体来描述人员。比方说，当John Smith, Engineer提升为John Smith, Director乃至最后爬到John Smith, CIO的高位，而所有你要做的不过是改变两个表STUDENT 和STUDENT_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的STUDENT_TYPE表就包含了所有STUDENT的可能类型，比如Associate、Engineer、Director、CIO或者CEO等。
3.选择数字类型和文本类型尽量充足。在SQL中使用smallint和tinyint类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了32,767就不能进行计算操作了。
而ID类型的文本字段，比如客户ID或定单号等等都应该设置得比一般想象更大。假设客户ID为10位数长。那你应该把数据库表字段的长度设为12或者13个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
（九）合理使用数据类型
我们要合理使用一些常规的数据类型，这样不仅能减少数据冗余，而且也能使你的设计更加科学、明确，同时也能使你的数据更加准确。如SQL SERVER2000中有一个float类型，它并没有限定小数位，如果你输入时带小数位的话，它会将它精确得很长，虽然你在往数据库中存放时限定了小数位，但当你在前台进行输出时，就有可能出现小数位精度过度的情况。所以可用numeric来替代。但同时又有另一个问题发生了：例如我们用asp开发网站时用的vbscript就不支持该类型（它只认float）。所以我们应该综合考虑多种因素酌情设计。
（十）慎用触发器
一般在大型RDBMS中都有触发器这一数据元素，合理使用数据触发器会使你的后台管理非常容易，但是随之带来的问题就是，当我们在调试程序时触发器可能成为干扰。但如果说你确实要采用触发器，你最好集中对它文档化。
（十一）用视图隐藏细节
我们考虑这样的情况，当我们在进行数据库模式设计时需要将一张大表拆分为几张小表，而在进行查询时又需要将几张小表合并为一张大表。如果表比较多的话，我们就要编写复杂的SQL语句，有没有一种机制将这几张小表一次合并为一张虚表，然后对一张表查询，这样操作起来就会简单得多。答案是肯定的。在SQL SERVER中可以用视图解决。视图是在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由，同时也对数据的一些底层操作进行了隐藏。
（十二）包含版本机制
在程序中有版本控制的概念，在进行数据库设计时，我们也要考虑到。因为用户的需求是随着时间的增长而变化的，所以最终可能会导致要修改数据库结构，甚至重构，假如说我们因为某种原因要将数据库恢复到以前的某个版本（状态），如果这时你进行了版本控制的话，工作量可想而知。只要找到以前的那个版本，进行恢复即可。但如果说我们没有版本控制的话，我们的工作将会非常烦琐和复杂，因一个小小的操作而白白浪费半天或一天的时间。
三、结论
总之，我们在进行数据库设计时，一定要综合考虑多种因素，具体问题具体分析，既要考虑当前实现的可行性，又要考虑以后的升级维护；既要减轻前台编码的负担，又要让后台的管理简单易行；既要让前台的查询效率高，又要让后台的实现方便可行。数据库设计是一项综合性设计，决非一朝一夕之功，大家一定要在工作、学习中多思考、多动脑、多总结、灵活运用所学知识，综合考虑各种因素，平衡把握每个细节，这样数据库设计才会更加科学、合理。
【参考文献】
[1]王选．软件设计方法[M]．北京：清华大学出版社，2003．
[2]http://www.csdn.net (中国最大程序网站)．
[3]http://www.uml.org.cn/（UML软件工程组织）．
[4]何玉洁，等.数据库设计[M].北京：机械工业出版社，2001．
|
| 论文录入：华东论文网 责任编辑：华东论文网 |
|
上一篇论文： 几种WEB数据库访问方法浅谈
下一篇论文： 没有了 |
| 【字体：小 大】【发表评论】【告诉好友】【打印此文】【关闭窗口】 |
论文定制
发表论文
合作流程
付款方式
信用说明
刊物介绍
50403530