数据库设计StepbyStep(6)提取业务规则

引言：数据库设计 Step by Step (5)中我们通过多种方法来理解客户的需求并撰写了需求文档。本文我们将回答三个问题。1. 为什么业务规则非常重要。2. 怎样识别业务规则。3. 如何修改关系模型并隔离出业务规则。 什么是业务规则 业务规则描述了业务过程中重要

引言：数据库设计 Step by Step (5)中我们通过多种方法来理解客户的需求并撰写了需求文档。本文我们将回答三个问题。1. 为什么业务规则非常重要。2. 怎样识别业务规则。3. 如何修改关系模型并隔离出业务规则。

什么是业务规则

业务规则描述了业务过程中重要的且值得记录的对象、关系和活动。其中包括业务操作中的流程、规范与策略。业务规则保证了业务能满足其目标和义务。

生活中的一些业务规则可能是：

本系列我们关注数据库相关的业务规则，一些例子如下：

从数据库的视角来看，业务规则是一种约束。简单的约束如：

所有订单必须有一个联系电话。

上述这类简单的规则可以很容易的映射到关系数据库定义中，为字段确定数据类型或设定某字段为必填（不能为NULL）。某些业务规则表达的约束会复杂些，如：

学生每天的上课时间加上项目时间必须在1至14小时之间。

我们可以通过check约束或外键约束来实现这类业务规则。对于一些非常复杂的业务规则，如：

一名教员每周不能少于30小时工作量，其中分为办公时间、实验时间和上课时间。每1小时的课需要0.5小时办公时间进行备课。每1小时实验需1小时办公准备。每周指导学生论文时间不少于2小时。

类似上述的业务规则需要从多个表中收集数据，故在程序代码中实现最为合适。

识别关键业务规则

记录所有的业务规则并对这些规则进行分类能帮助我们更好的在系统中实现业务逻辑。

如何实现业务规则不仅与当前的业务逻辑有关，而且与该业务逻辑将来如何变化有关。当一个规则在将来很可能变化时，我们需要使用更复杂但更灵活的方式构建该规则。

举例来说，假设公司只能向当地设有仓库的城市发货，这些城市包括：南京、长沙、西安、广州。业务规则要求订单中的发货城市字段必须为NJ、CS、XA、GZ之一。

我们可以把该规则简单的实现为check约束。但将来公司若在上海有了一个新仓库，就必须从后台数据库端修改该check约束。若公司随后设立更多新仓库或业务规则变化为可以向没有仓库的城市发货，每次我们都需要修改该约束。

考虑另一种实现该业务规则的方法——使用外键。我们创建一张ShippingCities表，其中存放值：NJ、CS、XA、GZ，并让订单表中的发货城市字段外键引用ShippingCities表中的主键。这样订单的发货城市列只能接受ShippingCities中存在的城市。当支持的发货城市增加或减少时，只需要在ShippingCities中插入或删除记录。

两种方式的实现难度差异不大，但前一种方式每次都需要修改数据库结构，后一种只需要修改数据。修改数据不仅更省力而且技术要求也更低。

上述业务规则实现为check约束可能如下：

ShippingCity = ‘NJ’ or ShippingCity = ‘CS’ or ShippingCity = ‘XA’ or ShippingCity = ‘GZ’

上述代码并不复杂，但只有熟悉数据库的程序员从后台才能修改。ShippingCitis表中的数据相对更易于理解，我们可以提供一个界面来让用户自己维护其中的城市。

要识别关键业务规则，我们可以问自己两个问题。

第一、修改规则会有多困难。越是复杂的规则，香港服务器租用，修改起来越困难且更容易出错。

第二、规则变化的可能性有多大。变化频繁的规则需要额外的设计来更好的应对将来的变化。

需要特别注意的规则（关键业务规则）：

一些直接可以在数据库中实现的业务规则：

作为软件从业人员不要拒绝或回避变化。世界上唯一不变的就是变化。在收集业务规则时多去了解该规则的业务背景与历史变化历程，而不是逼迫客户保证规则不会变化。尽可能发现所有的业务规则并记录下来。对这些业务规则按变化的可能性和修改难度进行分类，精心设计那些将来可能变化且修改困难的规则。

提取关键业务规则

识别并分类业务规则之后，我们需要在数据库中或数据库外来实现关键业务规则。我们可以参考如下方法：

1. 若规则为检验一组有效值时，香港虚拟主机，把该规则转化为外键约束。先前举例中的有效发货城市就是一个很好的例子。创建ShippingCities表，填入允许的发货城市。然后把Orders表的ShippingCity列设为外键，引用ShippingCities表的主键。

2. 若规则为参数可能变化的计算式时，把这些参数提取到一张表中。例如：一个月内卖出总价超过100万元汽车的销售员能获得500元奖金。把参数100万元和500元提取到一张表中，如果需要甚至可以把一个月的时间段也作为参数提取出来。

我还见过一些软件系统在数据库中有一张通用的参数表。该通用参数表中存放系统需要的各种参数，一些是用于计算、一些是作为检验、另一些决定系统的行为。每一条记录有两个字段：Name和Value。例如需要确定一名销售员能获得多少奖金，我们先要查找Name字段为BonusSales的记录，检查该销售员的销售额是否达到了Value字段的金额，若答案是肯定的再查找Name字段为BonusAward的记录来确定奖金数额。这种设计另有一好处，在程序启动时可以把通用参数表读入内存的某集合中，此后使用参数值时就无需再次连接数据库。

3. 若逻辑或计算规则很复杂时，则提取到代码中进行实现。这里说的代码可以是应用程序端代码，还可以是数据库端存储过程。把规则放到代码中实现的意义在于业务规则与数据库表结构分离了，规则的变化不会影响到数据库表结构。通过结构化编程或面向对象编程来实现复杂的规则更易于维护。

举一个综合性的例子：

一本关于数据库设计的书籍卖出前5000本的版税为5%，5000本至10000本之间的版税为7%，超过10000本后的版税为10%，不同类型书籍的版税可能不同。

上述规则比较复杂且包含多个可能变化的参数，故使用第1、2条方法。我们可以通过存储过程来实现该规则，并把参数隔离到一张参数表中进行维护。创建的参数表为RoyaltyRates，并通过BookId与Books关联（如图1所示）。这样为不同书籍创建新的版税规则就非常容易了。