数据完整性的设计

数据完整性，从应用的 层次来看，主要在于三个层次的数据验证，即数据库层，应用界面层和业务逻辑层。

           数据库层级中的数据完整性验证，是最基本的数据验证。数据库通过主键的唯一性保证实体的唯一；通过外键，保证引用完整性；通过数据类型，保证数据值正确；通过非空约束，保证数据不含无意义值；通过附加的约束（如：check等），保证数据值在范围之内；同时，触发器还可以保证简单的表之间的完整性。应用界面处理的数据完整性，主要是用户输入上的数据验证；通过界面的验证，让后面的业务逻辑和数据库接收比较正确的数据。业务逻辑中处理的完整性，主要是验证数据在业务方面的正确性，体现在多表间复杂关系的验证，有些资料中称作是业务规则。

           数据完整性的验证设计，需要在三个层次方面同时考虑到，理论上在任何一个层级都可以实现数据完整性验证。数据库加上各种约束，只能保证数据严格依据定义，在这一级上，数据只是无意义的符号数据，而不是信息；使用数据库的触发器机制，可以验证简单的关系及业务规则，但是由于数据库的可移植性、安全性等因素，数据库上不适合放置大量的验证。界面上的数据验证，也可以验证数据的类型、范围等，能够让用户较快地得到错误报告，获得修改输入数据的机会。一些比较复杂的验证，则放在业务逻辑中比较合适，一是可能比较复杂，需要很多计算，同时还和其它业务处理紧密相关，另外也是由于变化较多，需要特别对待；业务逻辑的验证中，有一些不需要实时验证，可以设计成单独的用例（Use－Case）。

           VATA系统中，MAWB和ULD＋BSA计划表（BSAPlan）的关系问题，就牵扯到三方面的验证。ULD＋BSA的分配表（AssignBSA），是MAWB汇总表和BSAPlan的连接，当删除MAWB时，必须检查分配表AssignBSA是否完整，分配表AssignBSA中不能存在无头的MAWB；而分配表AssignBSA和计划表BSAPlan是一对多关系，BSAPlan是主表。在ULD数量方面，分配ULD＋BSA时，OPs可以指定MAWB为BSA或者Non-BSA，同时分配ULD数量，系统要检查是否超出计划量；而输入MAWB时，要先汇总MAWB，得到航班＋日期的BSA＋ULD使用情况，检查比较BSAPlan中的BSA计划量，分配量，如果余额不足就提示。
           设计实现时，AssignBSA和BSAPlan的关系是主从表，由数据库主外键来维护验证，同时在界面上要维护该主从关系，删除、增加时，需要注意主从表的顺序。MAWB和AssignBSA的关系，在MAWB（输入和导入）的界面上验证；而分配和输入MAWB时，数量关系则由业务逻辑来验证。

 

           数据完整性设计，还牵扯到另外一个问题，就是 一致性。数据验证可能居于三个层级上，设计时要保证从任何一个层级进入的数据保持一致，由于数据库层级的数据验证是自动生效的，所以重点是考虑业务逻辑和界面层。当数据中有一些特殊意义的编码存在时，保持数据的一致性，就是一个比较困难的决策。

           比如身份证的编码，编码中包含了出生地、生日、性别等信息，同时还存在一位校验位；编码长度是15或者18位，如果是15位，需要自动转换为18位；然后验证生日、性别等是否相符；计算17位编码的校验和，验证校验码。考虑这样一个系统，比如税务局的计税系统，完整的计税系统包含两部分软件，税务局本身系统和纳税公司报税客户端，身份证在税务局和公司客户端系统中都进行验证。可是由于验证的不一致，客户端中导出的报税数据，在税务局系统中就不能通过验证。税务局和纳税公司需要多次交流沟通，才能解决报税数据中存在的问题，原来客户端软件只验证了生日和校验位，而税务局系统还验证性别。

           应该怎样才能避免系统应用以后出现类似的情况呢？设计时，就把这类验证定义为单独的功能集，集中在一起便于修改、维护，保持一致性。实现时最简单的方案是，抽离出所有的数据验证逻辑，组合成一个数据验证的服务包（类），在界面和业务逻辑中，调用服务包的服务来验证数据的完整性。在分布式的系统中，还应该注意部署和升级的及时性。