28、数据库业务规则与验证表的应用

数据库业务规则与验证表的应用解析

最新推荐文章于 2025-12-01 20:35:00 发布

c6d7e8f9g

最新推荐文章于 2025-12-01 20:35:00 发布

阅读量63

点赞数

CC 4.0 BY-SA版权

分类专栏：《凡人数据库设计》：从零构建高效数据库文章标签：数据库设计业务规则验证表

本文链接：https://blog.youkuaiyun.com/c6d7e8f9g/article/details/149580799

《凡人数据库设计》：从零构建高效数据库专栏收录该内容

37 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

数据库业务规则与验证表的应用

在数据库设计中，业务规则是确保数据完整性和一致性的关键要素。业务规则能够根据组织的运营方式和业务需求，对数据进行约束和规范，从而保证数据的有效性。而验证表则是实现这些业务规则的重要工具，下面我们将详细探讨验证表的相关内容。

验证表的基本概念

当定义特定字段的业务规则时，有时规则会对字段的值范围施加约束，定义出一组有效的值。这组值通常数量相对固定，且很少发生变化。但如果值的数量较多，在字段规范表中列举每个值会很困难，在关系型数据库管理系统（RDBMS）中实现整个值集也会比较复杂。这时，我们可以使用验证表来存储所有这些值，从而避免这些问题。

验证表（也称为查找表）用于存储专门用于实现数据完整性的数据。一旦用所需数据填充了该表，就很少会对表中的记录进行插入、更新或删除操作。验证表通常包含两个字段：第一个字段作为主键，用于帮助实施数据完整性；第二个字段是非键字段，用于存储数据库中其他字段所需的一组值。以下是两个验证表的示例：
| 类别 | 类别 ID |
| — | — |
| 建筑师 | 60002 |
| 总承包商 | 60003 |
| 律师 | 60004 |
| 计算机顾问 | 60001 |

州	州名
AL	阿拉巴马州
AK	阿拉斯加州
AR	阿肯色州
CA	加利福尼亚州

使用验证表支持业务规则

当业务规则限制了字段的值范围时，我们可以使用验证表来实施该约束，让该字段从验证表的相应字段中获取值。建立这种规则通常涉及两个步骤：
1. 定义关系 ：在受规则影响的字段的父表和验证表之间定义关系。
2. 修改字段规范 ：修改父表中受影响字段的字段规范中的“值范围”元素。

下面通过一个具体的例子来说明：假设我们有一个 SUPPLIERS 表，其中有一个 SUPPSTATE 字段。我们定义了这样一个业务规则：任何我们使用的供应商必须位于 11 个毗连的西部州、阿拉斯加州或夏威夷州。这个规则限制了 SUPPSTATE 字段的值范围，只能是 AK、AZ、CA、CO、HI、ID、MT、NM、NV、OR、UT、WA 和 WY。为了实施这个规则，我们可以创建一个名为 STATES 的验证表，将这些值存储在其中，然后将 STATES 表作为 SUPPSTATE 字段值范围的来源。

具体操作步骤如下：
1. 建立关系 ： STATES 表和 SUPPLIERS 表之间存在一对多的关系，即 STATES 表中的一条记录可以与 SUPPLIERS 表中的多条记录相关联，而 SUPPLIERS 表中的一条记录只能与 STATES 表中的一条记录相关联。我们将 STATES 表的主键复制到 SUPPLIERS 表中，使其成为外键。虽然 SUPPLIERS 表中已经有一个名为 SUPPSTATE 的字段，但我们将其替换为 STATES 验证表中的 STATE 字段。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(建立 STATES 表和 SUPPLIERS 表的关系):::process
    B --> C(将 STATES 表的主键复制到 SUPPLIERS 表成为外键):::process
    C --> D(用 STATES 表的 STATE 字段替换 SUPPLIERS 表的 SUPPSTATE 字段):::process
    D --> E(设置 STATE 字段的字段规范):::process
    E --> F(设置关系的特性):::process
    F --> G(修改 STATE 字段的值范围元素):::process
    G --> H([结束]):::startend

设置外键规范 ：确保 STATE 字段符合外键的要素，并以适当的方式设置其字段规范。
设置关系特性 ：
- 删除规则 ：为该关系定义“限制删除”规则，即不允许删除 STATES 表中被 SUPPLIERS 表记录引用的州。
- 参与类型 ：指定 SUPPLIERS 表为可选参与类型， STATES 表为强制参与类型。也就是说，在 STATES 表中插入新记录时， SUPPLIERS 表中不需要有记录；但在 SUPPLIERS 表中插入记录时， STATES 表中必须至少有一条记录。
- 参与度 ：为 STATES 表分配 (1,1) 的参与度，因为在 SUPPLIERS 表中插入记录之前， STATES 表中必须至少有一条记录；为 SUPPLIERS 表分配 (0,N) 的参与度，因为 SUPPLIERS 表中的任意数量的记录都可以与 STATES 表中的特定记录相关联。
修改值范围元素 ：将 SUPPLIERS 表中 STATE 字段的字段规范中的“值范围”元素修改为“ STATES 表中 STATE 字段的任何值”。
确定测试规则的操作 ：当使用验证表实施业务规则时，通常在用户尝试向字段插入新值或更新字段中的现有值时测试规则。如果用户尝试输入验证表中不存在的值，就会发生违规。
填写业务规则规范表 ：填写业务规则规范表，明确说明对字段和新关系所做的修改。

业务规则规范表的审查

在建立了认为合适的业务规则后，需要审查它们的规范表。仔细检查每个规范表，确保规则已正确建立，并在表上清晰标记所有适当的区域。如果发现错误，进行必要的修改并再次审查，重复这个过程，直到审查完所有业务规则。

业务规则是数据库的重要组成部分，它们有助于整体数据完整性，并施加特定于组织的完整性约束。这些规则不仅能确保数据的有效性和一致性，还会影响数据库在 RDBMS 中的实现方式以及为数据库设计和开发的最终用户应用程序。

需要注意的是，我们会经常重新审视这些规则。在审查最终结构时，可能会发现需要额外的业务规则；有些规则可能无法达到预期的效果，需要进行修改；甚至可能会发现某些规则不再必要，但在删除之前一定要仔细审查。随着组织的发展和变化，业务规则也需要相应地进行调整和修改，这是数据库设计过程中的一个持续任务。不要因为需要多次执行这个任务而气馁，从长远来看，这些努力将带来巨大的回报。

案例研究

下面通过一个实际案例来进一步说明如何使用验证表建立业务规则。假设我们要为 Mike 的数据库建立业务规则，我们与 Mike 及其员工开会，审查他们数据库中的表和关系。

定义字段特定的业务规则

我们首先从 PRODUCTS 表开始审查。当审查到 CATEGORY 字段时，我们发现之前对其值范围存在疑问。经过与 Mike 及其员工的讨论，我们最终确定了一份明确的类别列表。Mike 决定将 CATEGORY 字段的值限制在这个列表中，以确保员工不会随意创建新的类别。因此，我们定义了以下业务规则：不允许使用无效的产品类别。

由于可能的类别列表中有多个项目，我们决定使用验证表来建立这个规则。我们创建了一个名为 CATEGORIES 的新表，并在它和 PRODUCTS 表之间建立了关系。然后，我们绘制了关系图，并以适当的方式设置了关系的特性：
- 关系存在“限制删除”规则。
- CATEGORIES 表具有强制参与类型。
- PRODUCTS 表具有可选参与类型。
- CATEGORIES 表的参与度为 (1,1)。
- PRODUCTS 表的参与度为 (0,N)。

建立关系后，我们用新 CATEGORIES 表中的 CATEGORY ID 字段替换了 PRODUCTS 表中现有的 CATEGORY 字段。我们确保 PRODUCTS 表中的 CATEGORY ID 字段符合外键的要素，并对其字段规范进行了适当的修改。最后，将该字段的“值范围”元素设置为“ CATEGORIES 表中 CATEGORY ID 字段的任何值”。

我们通常在用户尝试向字段插入值或更新字段中的现有值时测试这个规则。最后，我们填写了一份业务规则规范表，反映了对 CATEGORY ID 字段的字段规范以及 CATEGORIES 表和 PRODUCTS 表之间关系特性所做的修改。

定义关系特定的业务规则

接下来，我们开始建立关系特定的业务规则。我们先审查了 EMPLOYEES 表和 INVOICES 表之间的关系，发现一切正常，然后转向 VENDORS 表和 PRODUCTS 表之间的关系。

在与 Mike 讨论是否对这个关系施加约束时，Mike 认为应该对 PRODUCTS 表施加约束。他希望确保 VENDORS 表中的每个供应商都至少与一种产品相关联，因为保留不提供任何产品的供应商的数据是没有必要的。因此，我们为这个约束定义了以下业务规则：每个供应商必须至少供应一种产品。

为了建立这个规则，我们修改了相应的关系特性：
- 指定 PRODUCTS 表具有强制参与类型，并分配 (1,N) 的参与度。
- 基于 PRODUCTS 表为关系定义“限制删除”规则，以防止意外删除与给定供应商关联的唯一产品。

通过这个案例，我们可以看到如何在实际场景中使用验证表和业务规则来确保数据库的数据完整性和一致性。在数据库设计过程中，合理运用业务规则和验证表是非常重要的，它们能够帮助我们构建更加健壮和可靠的数据库系统。

数据库业务规则与验证表的应用（续）

验证表与业务规则在不同场景的深入应用

在数据库设计中，验证表和业务规则的应用场景丰富多样，除了前面提到的案例，还有许多其他情况需要我们灵活运用这些概念。

多字段关联的验证表应用

有时候，业务规则可能涉及多个字段之间的关联。例如，在一个订单管理系统中，有 ORDERS 表和 PRODUCTS 表，同时还有一个 DISCOUNTS 验证表。业务规则规定，某些特定类别的产品在特定时间段内可以享受折扣。

为了实现这个规则，我们可以在 ORDERS 表中添加 PRODUCT_ID 和 ORDER_DATE 字段，在 PRODUCTS 表中记录产品的类别信息，在 DISCOUNTS 表中存储不同类别产品对应的折扣时间段和折扣率。具体操作步骤如下：
1. 建立关系 ：在 ORDERS 表、 PRODUCTS 表和 DISCOUNTS 表之间建立关系。 ORDERS 表通过 PRODUCT_ID 与 PRODUCTS 表关联，同时根据 ORDER_DATE 和产品类别与 DISCOUNTS 表关联。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(建立 ORDERS 表、PRODUCTS 表和 DISCOUNTS 表的关系):::process
    B --> C(ORDERS 表通过 PRODUCT_ID 与 PRODUCTS 表关联):::process
    C --> D(ORDERS 表根据 ORDER_DATE 和产品类别与 DISCOUNTS 表关联):::process
    D --> E(设置关联字段的字段规范):::process
    E --> F(设置关系的特性):::process
    F --> G(确定折扣计算规则):::process
    G --> H([结束]):::startend

设置字段规范 ：确保 PRODUCT_ID 、 ORDER_DATE 等字段符合相应的要素，并设置好字段规范。
设置关系特性 ：
- 删除规则 ：对于 ORDERS 表和 PRODUCTS 表的关系，定义“限制删除”规则，防止删除产品时影响相关订单；对于 ORDERS 表和 DISCOUNTS 表的关系，同样定义“限制删除”规则，避免删除折扣信息时影响已有的订单折扣计算。
- 参与类型 ： ORDERS 表与 PRODUCTS 表的关联为强制参与类型，因为每个订单必须关联一个产品； ORDERS 表与 DISCOUNTS 表的关联为可选参与类型，因为不是所有订单都能享受折扣。
- 参与度 ： ORDERS 表与 PRODUCTS 表的参与度为 (1,1)， ORDERS 表与 DISCOUNTS 表的参与度为 (0,1)。
确定折扣计算规则 ：在业务规则中明确根据 ORDER_DATE 和产品类别从 DISCOUNTS 表中获取折扣率，并计算订单的实际价格。
测试规则 ：在用户创建或修改订单时，测试规则是否正确执行。如果订单的产品和日期符合折扣条件，能够正确计算折扣价格；否则，按原价计算。
填写业务规则规范表 ：详细记录对字段和关系所做的修改以及折扣计算规则。

动态验证表的使用

在某些情况下，验证表中的数据可能需要动态更新。例如，在一个旅游预订系统中， DESTINATIONS 验证表存储了可供预订的旅游目的地信息。随着旅游市场的变化，可能会不断有新的目的地加入，或者某些目的地因为各种原因不再提供服务。

为了实现动态更新，我们可以在系统中设置专门的管理界面，允许管理员对 DESTINATIONS 表进行插入、更新和删除操作。同时，需要相应地调整业务规则和关系特性。具体步骤如下：
1. 设计管理界面 ：开发一个管理界面，管理员可以在该界面上添加新的目的地信息，包括目的地名称、地址、相关描述等；修改现有目的地的信息；删除不再提供服务的目的地。
2. 更新业务规则 ：确保业务规则能够适应验证表的动态变化。例如，在 BOOKINGS 表中，当用户预订旅游目的地时，系统会实时从 DESTINATIONS 表中获取可用的目的地列表。
3. 调整关系特性 ：
- 删除规则 ：当管理员删除 DESTINATIONS 表中的某个目的地时，需要检查是否有相关的预订记录。如果有，需要根据业务规则决定是禁止删除还是同时删除相关的预订记录。
- 参与类型和参与度 ：保持 BOOKINGS 表与 DESTINATIONS 表的关系特性不变，即 BOOKINGS 表可选参与， DESTINATIONS 表强制参与，参与度分别为 (0,N) 和 (1,1)。
4. 测试更新后的系统 ：在每次对 DESTINATIONS 表进行更新后，对系统进行全面测试，确保业务规则仍然能够正确执行，数据的完整性和一致性得到保证。

业务规则的维护与优化

随着数据库系统的运行和业务的发展，业务规则需要不断进行维护和优化。

定期审查业务规则

定期对业务规则进行审查是非常必要的。可以按照一定的时间周期（如每月、每季度）对业务规则规范表进行检查，查看是否有规则已经不再适用，或者是否需要根据新的业务需求添加新的规则。

审查过程中，需要关注以下几个方面：
1. 规则的有效性 ：检查业务规则是否仍然符合当前的业务流程和需求。例如，随着市场竞争的加剧，公司可能调整了产品的定价策略，那么相关的价格计算规则就需要进行更新。
2. 规则的性能 ：评估业务规则在数据库中的执行性能。如果某些规则的执行效率低下，导致数据库查询响应时间过长，需要考虑对规则进行优化。例如，通过优化查询语句、创建合适的索引等方式提高规则的执行速度。
3. 规则的一致性 ：确保不同业务规则之间没有冲突。例如，在一个库存管理系统中，不能同时存在“库存数量不能为负数”和“允许超量发货”这样相互矛盾的规则。

优化业务规则的执行

为了提高业务规则的执行效率，可以采取以下几种优化措施：
1. 索引优化 ：根据业务规则涉及的字段，在相关表上创建合适的索引。例如，如果业务规则经常根据产品的类别进行查询和筛选，那么在 PRODUCTS 表的 CATEGORY 字段上创建索引可以显著提高查询速度。
2. 缓存机制 ：对于一些频繁使用的验证表数据，可以采用缓存机制。例如，将 DISCOUNTS 表中的数据缓存到内存中，减少数据库的查询次数，提高系统的响应速度。
3. 规则合并与简化 ：如果发现有多个业务规则可以合并为一个更简洁的规则，或者某些规则的逻辑过于复杂，可以进行简化。例如，将多个条件相同的规则合并为一个规则，减少规则的数量和复杂度。

总结

在数据库设计和管理过程中，业务规则和验证表起着至关重要的作用。验证表能够帮助我们有效地管理字段的值范围，确保数据的有效性；业务规则则能够根据组织的业务需求对数据进行约束和规范，保证数据的完整性和一致性。

通过合理运用验证表和业务规则，我们可以构建出更加健壮、可靠和高效的数据库系统。在实际应用中，我们需要根据不同的业务场景灵活应用这些概念，同时注重业务规则的维护和优化，以适应不断变化的业务需求。随着数据库技术的不断发展，我们相信业务规则和验证表的应用将会更加广泛和深入，为企业的信息化建设提供更强大的支持。

总之，数据库业务规则与验证表的应用是一个需要不断学习、实践和创新的过程。只有不断提升我们的技术水平和业务理解能力，才能更好地应对各种复杂的数据库设计和管理挑战。