第4 部分— 保证数据的完整性
1. 用约束而非商务规则强制数据完整性
如果你按照商务规则来处理需求，那么你应当检查商务层次/用户界面：如果商务规则以后发生变
化，那么只需要进行更新即可。
假如需求源于维护数据完整性的需要，那么在数据库层面上需要施加限制条件。
如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解
的语言通知用户界面。除非你的字段命名很冗长，否则字段名本身还不够。
只要有可能，请采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还
包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层
保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
2. 分布式数据系统
对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该
估计一下未来5 年或者10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段
中设置一些标记。在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下
你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地
拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。
3. 强制指示完整性
没有好办法能在有害数据进入数据库之后消除它，所以你应该在它进入数据库之前将其剔除。激
活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处
理错误条件。
4. 关系
如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置
成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。
5. 采用视图
为了在你的数据库和你的应用程序代码之间提供另一层抽象，你可以为你的应用程序建立专门的
视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的
自由。
6. 给数据保有和恢复制定计划
考虑数据保有策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发
人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供
以后万一数据丢失可以重新处理更新。
7. 用存储过程让系统做重活
解决了许多麻烦来产生一个具有高度完整性的数据库解决方案之后，我所在的团队决定封装一些
关联表的功能组，提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开
发。在此期间，我们发现3GL 编码器设置了所有可能的错误条件，比如以下所示：
SELECT Cnt = COUNT (*
)
FROM [<Table>
]
WHERE [<primary key column>] = <new value>
IF Cnt =
0
BEGIN
INSERT INTO [<Table>
]
( [< primary key column>]
)
VALUES ( <New value>
)
END
ELSE
BEGIN
<indicate duplication error>
END
而一个非3GL 编码器是这样做的：
INSERT INTO [<Table>
]
( [< primary key column>]
)
VALUES
( <New value>
)
IF @@ERROR = 2627 -- Literal error code for Primary Key Constraint
BEGIN
<indicate duplication error>
END
第2 个程序简单多了，而且事实上，利用了我们给数据库的功能。虽然我个人不喜欢使用嵌入文
字（2627）。但是那样可以很方便地用一点预先处理来代替。数据库不只是一个存放数据的地
方，它也是简化编码之地。
8. 使用查找
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值
列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适
合查找：国家代码、状态代码等。
第5 部分— 各种小技巧
1. 文档、文档、文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
— nickypendragon
采用给表、列、触发器等加注释的数据库工具。是的，这有点费事，但从长远来看，这样做对开
发、支持和跟踪修改非常有用。
取决于你使用的数据库系统，可能有一些软件会给你一些供你很快上手的文档。你可能希望先开
始在说，然后获得越来越多的细节。或者你可能希望周期性的预排，在输入新数据同时随着你的
进展对每一部分细节化。不管你选择哪种方式，总要对你的数据库文档化，或者在数据库自身的
内部或者单独建立文档。这样，当你过了一年多时间后再回过头来做第2 个版本，你犯错的机会
将大大减少。
2. 使用常用英语（或者其他任何语言）而不要使用编码
为什么我们经常采用编码（比如9935A 可能是墨水笔的供应代码，4XF788-Q 可能是帐目编
码）？理由很多。但是用户通常都用英语进行思考而不是编码。工作5 年的会计或许知道
4XF788-Q 是什么东西，但新来的可就不一定了。在创建下拉菜单、列表、报表时最好按照英语
名排序。假如你需要编码，那你可以在编码旁附上用户知道的英语。
3. 保存常用信息
让一个表专门存放一般数据库信息非常有用。我常在这个表里存放数据库当前版本、最近检查/修
复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据
库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境
特别有用。
4. 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测
试并且同用户一道保证你选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之
前完成。
5. 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，
针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。
6. Access设计技巧
对复杂的Microsoft Access 数据库应用程序而言，可以把所有的主表放在一个数据库文件里，然
后增加其他数据库文件和装载同原有数据库有关的特殊函数。根据需要用这些函数连接到主文件
中的主表。比如数据输入、数据QC、统计分析、向管理层或者政府部门提供报表以及各类只读
查询等。这一措施简化了用户和组权限的分配，而且有利于应用程序函数的分组和划分，从而在
程序必须修改的时候易于管理。
