数据库设计的技巧和规范Word下载.doc

数据库设计的技巧和规范Word下载.doc

《数据库设计的技巧和规范Word下载.doc》由会员分享，可在线阅读，更多相关《数据库设计的技巧和规范Word下载.doc（7页珍藏版）》请在冰豆网上搜索。

表内的列[字段]要针对键采用一整套设计规则。

比如，如果字段是数字类型，你可以用_n作为后缀；

如果是字符类型则可以采用_c后缀。

对列[字段]名应该采用标准的前缀和后缀。

再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个_m后缀。

还有，日期列[字段]最好以d_作为名字打头。

3、在物理实践之前进行逻辑设计

在深入物理设计之前要先进行逻辑设计。

随着大量的case工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。

4、理解客户需求

在你百分百地确定系统从客户角度满足其需求之前不要在你的ER（实体关系）模式中加入哪怕一个数据表。

了解你的用户的业务需求可以在以后的开发阶段节约大量的时间。

一旦你明确了业务需求，你就可以自己做出许多决策了。

一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。

采用客户的术语并且向他们解释你所想到的和你所听到的。

同时还应该用可能、将会和必须等词汇表达出系统的关系基数。

这样你就可以让你的客户纠正你自己的理解然后做好下一步的ER设计。

看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。

不要依赖用户写下来的需求，真正的需求在客户的脑袋里。

你要让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。

一个不变的真理是：

“只有我看见了我才知道我想要的是什么”必然会导致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。

而更糟的是你对他们需求的解释只属于你自己，而且可能是完全错误的。

5、创建数据字典和ER图

一定要花点时间创建ER图和数据字典。

其中至少应该包含每个字段的数据类型和在每个表内的主外键。

创建ER图和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。

越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的人都明确如何从数据库中获得数据。

有一份诸如ER图等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。

对以后设计SQL语句来说这是完全必要的。

6、创建模式

一张图表胜过千言万语：

开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。

模式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。

模式不必弄的很复杂；

甚至可以简单到手写在一张纸上就可以了。

只是要保证其上的逻辑关系今后能产生效益。

7、从输入输出下手

在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。

举个简单的例子：

假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码存放在地址字段里。

8、报表技巧

要了解用户通常是如何报告数据的：

批处理还是在线提交报表？

时间间隔是每天、每周、每月、每个季度还是每年？

如果需要的话还可以考虑创建总结表。

第2部分-设计表和字段

1、采用有意义的字段名

可使用缩写字段名，但请尽可能地把字段描述的清楚些。

当然，也别做过头了，比如customer_shipping_address_street_line_1，虽然很富有说明性，但没人愿意键入这么长的名字，具体尺度就在你的把握中。

2、标准化和数据驱动

数据的标准化不仅方便了自己而且也方便了其他人。

比方说，假如你的用户界面要访问外部数据源（文件、XML文档、其他数据库等），你不妨把相应的连接和路径信息存储在用户界面支持表内。

还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。

但标准化不能过头，3NF通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。

简单来说，3NF规定：

*表内的每一个值都只能被表达一次。

*表内的每一行都应该被唯一的标识（有唯一键），别忘了定义主、外键。

*表内不应该存储依赖于其他键的非键信息。

遵守3NF标准的数据库具有以下特点：

有一组表专门存放通过键连接起来的关联数据。

比方说，某个存放客户及其有关定单的3NF数据库就可能有两个表：

customer和order。

order表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向customer表里包含该客户信息的那一行。

更高层次的标准化也有，但更标准是否就一定更好呢？

答案是不一定。

事实上，对某些项目来说，甚至就连3NF都可能给数据库引入太高的复杂性。

3、给文本字段留足余量

比如客户CustID的文本类型字段等都应该设置得比一般想象更大，因为时间不长你多半就会因为要添加额外的字符而难堪不已。

比方说，假设你的客户CustID为10位数长。

那你应该把数据库表字段的长度设为12或者13个字符长。

这算浪费空间吗？

是有一点，但也没你想象的那么多：

一个字段加长3个字符在有1百万条记录，再加上一点索引的情况下才不过让整个数据库多占据3MB的空间。

但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

身份证的号码从15位变成18位就是最好和最惨痛的例子。

4、字段命名技巧

我们发现，假如你给每个表的列[字段]名都采用统一的前缀，那么在编写sql表达式的时候会得到大大的简化。

这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列[字段]名同某些数据库联系起来，不过就连这些工具有时不也连接错误嘛。

举个简单的例子，假设有两个表customer和order：

customer表的前缀是cu_，所以该表内的子段名如下：

cu_name、cu_id、cu_surname、cu_initials和cu_address等。

order表的前缀是or_，所以子段名是：

or_id、or_cust_id、or_quantity和or_description等。

这样从数据库中选出全部数据的sql语句可以写成如下所示：

select*fromcustomer,orderwherecu_surname="

myname"

;

andcu_id=or_cust_idandor_quantity=1

在没有这些前缀的情况下则写成这个样子（用别名来区分）：

select*fromcustomer,orderwherecustomer.surname="

andcustomer._id=order.cust_idandorder.quantity=1

第3部分-保证数据的完整性

1、用约束而非商务规则强制数据完整性

如果你按照商务规则来处理需求，那么你应当检查商务层次/用户界面：

如果商务规则以后发生变化，那么只需要进行更新即可。

假如需求源于维护数据完整性的需要，那么在数据库层面上需要施加限制条件。

如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。

除非你的字段命名很冗长，否则字段名本身还不够。

只要有可能，请采用数据库系统实现数据的完整性。

这不但包括通过标准化实现的完整性而且还包括数据的功能性。

在写数据的时候还可以增加触发器来保证数据的正确性。

不要依赖于商务层保证数据完整性；

它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。

2、定义完整性规则（实体完整性和参照完整性）

没有好办法能在无效数据进入数据库之后消除它，所以你应该在它进入数据库之前将其剔除。

激活数据库系统的完整性规则。

这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

3、关系

如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。

从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。

4、采用视图

为了在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的视图而不必非要应用程序直接访问数据表。

这样做还等于在处理数据库变更时给你提供了更多的自由。

4、给数据保有和恢复制定计划

考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程。

采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。

编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。

5、用存储过程让系统做重活

解决了许多麻烦来产生一个具有高度完整性的数据库解决方案之后，我决定封装一些关联表的功能组，提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。

数据库不只是一个存放数据的地方，它也是简化编码之地。