逐步设计你的数据库：如何提取业务规则

逐步设计你的数据库：不可低估的要求。在需求分析中，我们采用了多种方法来了解客户的需求并编写需求文档。在这篇文章中我们将回答三个问题。 1. 为什么业务规则很重要。 2.如何识别业务规则。 3、如何修改关系模型，隔离业务规则。 简介： 逐步设计您的数据库。在需求分析中，我们采用多种方法了解客户的需求并编写需求文档。在这篇文章中我们将回答三个问题。 1. 为什么业务规则很重要。 2.如何识别业务规则。 3、如何修改关系模型，隔离业务规则。 什么是业务规则 业务规则描述了业务流程中重要且值得记录的对象、关系和活动。这包括业务运营中的流程、规范和政策。业务规则确保企业满足其目标和义务。 生活中的一些商业规则可能是： 当顾客进入商店时，最近的员工必须向顾客打招呼并说：“欢迎光临×××”。 顾客兑换价值200元以上的彩票时，柜员必须要求看顾客身份证并复印。当兑换优惠券金额低于25元时，无需客户签名。 早上第一个进入办公室的人需要打开饮水机上的加热按钮。 在本系列中，我们重点关注与数据库相关的业务规则。一些示例如下： 仅当客户下第一笔订单时才会创建客户记录。 如果学生尚未参加任何课程，请将其状态字段设置为“非活动”。 如果销售人员一个月卖出10套沙发，他将获得500元的奖励。 联系人必须至少有 1 个电话号码和 1 个电子邮件地址。 订单不含税总金额超过1000元，可享受5%折扣。 如果订单不含税总金额超过500元，则免运费。 员工购买我们的产品可享受5%的折扣。 如果仓库中某种产品的库存低于上月销售总量，则需要采购。 从数据库的角度来看，业务规则是一种约束。简单的约束，例如： 所有订单都必须有联系电话。 像上面这样的简单规则可以轻松映射到关系数据库定义，以确定字段的数据类型或将字段设置为必填字段（不能为 NULL）。有些业务规则表达的约束会比较复杂，比如： 学生每天的上课时间加上项目时间必须在 1 到 14 小时之间。 我们可以通过检查约束或者外键约束来实现这样的业务规则。对于一些非常复杂的业务规则，例如： 教员每周工作时间不得少于30小时，分为办公时间、实验室时间和课堂时间。每1小时的课程需要0.5小时的办公时间来备课。每1小时的实验需要1小时的办公室准备。每周督导学生论文的时间不少于2小时。 像上面这样的业务规则需要从多个表中收集数据，因此最适合用程序代码来实现。 确定关键业务规则 记录所有的业务规则，并对这些规则进行分类，可以帮助我们更好的在系统中实现业务逻辑。 业务规则如何实现不仅关系到当前的业务逻辑，还关系到业务逻辑未来如何变化。当规则将来可能发生变化时，我们需要使用更复杂但更灵活的方式来构建规则。 例如，假设公司只能发货到有本地仓库的城市，包括：南京、长沙、西安、广州。业务规则要求订单中的发货城市字段必须为NJ、CS、XA、GZ之一。 我们可以简单地将此规则实现为检查约束。但未来，如果公司在上海有新的仓库，则必须从后端数据库修改检查约束。如果公司随后设立更多新仓库，或者业务规则发生变化，允许发货到没有仓库的城市，我们每次都需要修改这个约束。 考虑另一种实现此业务规则的方法 - 使用外键。我们创建一个ShippingCities表，其中存储值：NJ、CS、XA、GZ，并让订单表中的发货城市字段的外键引用ShippingCities表中的主键。这样订单的发货城市一栏就只能接受ShippingCities中存在的城市。当支持的发货城市增加或减少时，只需在ShippingCities中插入或删除记录即可。 两种方法实现难度没有太大区别，但前一种方法每次都需要修改数据库结构，而后一种方法只需要修改数据。修改数据不仅劳动强度较低，而且技术要求也较低。 上述作为检查约束实现的业务规则可以如下： ShippingCity = ‘NJ’ 或 ShippingCity = ‘CS’ 或 ShippingCity = ‘XA’ 或 ShippingCity = ‘GZ’ 上面的代码并不复杂，但是只有熟悉数据库的程序员才能从后台修改。 ShippingCitis表中的数据比较容易理解，我们可以提供一个接口让用户自己维护城市。 为了确定关键业务规则，我们可以问自己两个问题。 首先，改变规则有多困难。规则越复杂，修改起来就越困难，也就越容易出错。 其次，规则改变的可能性有多大？频繁变化的规则需要额外的设计，以更好地应对未来的变化。 需要特别关注的规则（关键业务规则）： 枚举值。例如：有效的发货城市、订单状态（待处理、已批准、已发货）等。 计算参数。例如：订单满500元免运费。未来这个数值可能会调整为300元或600元。 有效参数。例如：项目团队可以由2到5人组成。有些项目是否可以由1人完成或者更多人参与。 交叉记录和交叉表检查。例如：订单中可订购的商品数量不能超过该商品的当前库存。 普遍性限制。如果预见到将来需要应用一些类似的约束，我们可以考虑将这些约束抽象出来进行管理。例如：某保险公司最近促销A产品，每月销售20份A产品的销售人员将获得1000元奖金。不同的保险产品在不同的时间段可能有不同的促销奖励规则。我们可以将产品名称、序列号、销量、奖金金额、促销时间段提取到一个单独的表中，作为计算奖金的参数。 非常复杂的检查。有些检查规则非常复杂，用程序代码实现这些规则会更容易、更清晰。例如，学生选择理学院的谓词微积分课程的前提是通过了理学院的命题微积分课程或社科院的逻辑一、二课程，否则需要许可来自他们的导师。该规则在某些数据库产品中可以通过表级检查约束来实现，但在程序中更容易维护和理解。 一些可以直接在数据库中实现的业务规则： 固定枚举值。例如：性别（男、女）、惯用手（左撇子、右撇子）。 数据类型要求。每个字段都有特定的数据类型是关系数据库的重要特征之一。滥用常见数据类型（例如字符串）会损害性能和数据错误预防。 所需值。例如：会员必须有手机联系信息。 合理性检查。合理性检查确定的范围基本不会改变。例如：产品价格大于等于0。 作为软件从业者，不要拒绝或避免改变。世界上唯一不变的就是变化。在收集业务规则时，多了解规则的业务背景和历史变化，而不是强迫客户保证规则不会改变。尽可能发现所有业务规则并将其记录下来。根据变化的可能性和修改的难度对这些业务规则进行分类，对那些未来可能变化且难以修改的规则进行精心设计。 #p# 提取关键业务规则 在对业务规则进行识别和分类之后，我们需要在数据库内部或外部实现关键业务规则。我们可以参考以下方法： 1. 如果规则是测试一组有效值，则将规则转换为外键约束。上一个示例中的有效发货城市就是一个很好的例子。创建一个 ShippingCities 表并填写允许的运输城市。然后将 Orders 表的 ShippingCity 列设置为外键，引用 ShippingCities 表的主键。 2. 如果规则是一个计算公式，参数可能发生变化，则将这些参数提取到表格中。例如：销售人员一个月内销售总价超过100万元的汽车，即可获得500元奖金。将参数100万元和500元提取到一个表中。如有必要，您甚至可以提取一个月的时间段作为参数。 我还看到一些软件系统在数据库中有一个公共参数表。通用参数表存储了系统所需的各种参数，有些用于计算，有些用于测试，有些则决定系统的行为。每条记录都有两个字段：名称和值。例如，如果我们需要确定一个销售人员可以获得多少奖金，我们首先需要找到Name字段为BonusSales的记录，检查该销售人员的销售额是否达到了Value字段中的金额，如果是的话，然后搜索Name字段为BonusAward的记录。记录以确定奖金金额。这样设计的另一个好处是，在程序启动时就可以将通用参数表读入内存中的某个集合中，使用参数值时无需再次连接数据库。 3、如果逻辑或计算规则非常复杂，则提取到代码中实现。这里所说的代码可以是应用程序端代码，也可以是数据库端存储过程。将规则放入代码中的意义在于，业务规则与数据库表结构分离，规则的更改不会影响数据库表结构。通过结构化编程或面向对象编程来实现复杂的规则更容易维护。 举一个综合性的例子： 数据库设计书籍的版税为前 5,000 册的 5%，销售 5,000 至 10,000 册的 7%，销售超过 10,000 册的 10%。不同类型的图书的版税可能不同。 上述规则比较复杂，包含多个可能变化的参数，所以采用方法1和方法2。我们可以通过存储过程来实现这个规则，并将参数隔离到参数表中进行维护。创建的参数表为RoyaltyRates，通过BookId与Books关联（如图1）。这使得为​​不同的书籍创建新的版税规则变得非常容易。 ​ 图1 参数表RoyaltyRates与Books表的关系 多层应用程序的概念是每个人都熟悉的。三层应用程序是最常见的分层方法。复杂的业务逻辑一般在中间层（即业务层）实现。对于一些基础验证，如所需信息、有效数值区间等，需要在顶层用户界面和底层数据库进行双重验证。数据库端的约束是防止脏数据进入系统的最后一道防线，而用户界面的检查可以防止错误数据在被拒绝之前传输到系统后端，从而节省系统资源。 注意：有关多层应用程序的更多信息，请参阅最后的“摘要和参考”部分。 主要内容回顾 1. 业务规则决定业务如何运行，从简单直接的录入时钟到复杂的奖金计算公式。 2.对于数据库来说，业务规则会影响数据模型。业务规则决定了每个字段的域（值的类型和范围）、是否为必填字段以及该字段必须满足的其他条件。 3. 了解业务规则并识别那些需要特殊处理的关键规则至关重要。 4、有些规则简单，基本不变，利用数据库特性可以轻松实现。其他规则可能很复杂或者经常变化，我们可以从逻辑上或物理上将它们与数据库（到参数表、存储过程或业务层）隔离，以便于修改。 多层应用参考 1.谈谈对企业级系统架构的理解（http://www.sychzs.cn/liping13599168/archive/2011/05/11/2043127.html） 2. 多层架构(http://www.sychzs.cn/wiki/Multitier_architecture) 3. 软件架构、架构师和架构设计(http://www.sychzs.cn/) 原文链接：http://www.sychzs.cn/DBFocus/archive/2011/06/08/2075795.html 【编辑精选】 数据库设计，你了解多少 逐步设计您的数据库并分析不可低估的需求