29、数据库业务规则与视图全解析

数据库业务规则与视图全解析

1. 业务规则基础

业务规则是对字段或关系施加的约束，它基于组织对数据的认知和使用方式，源于组织的运作模式。主要分为面向数据库和面向应用两类业务规则，这里着重探讨面向数据库的业务规则，但面向应用的业务规则的基本元素也可记录下来，供后续实施过程使用。

面向数据库的业务规则又可细分为两类：
- 字段特定业务规则 ：影响特定字段的字段规范元素。
- 关系特定业务规则 ：影响关系的特征。

2. 业务规则的定义与建立

定义和建立业务规则需要与用户和管理层合作，以确定组织所需的业务规则。一般来说，最好先建立字段特定业务规则，再建立关系特定业务规则。具体步骤如下：
1. 针对一个字段或关系开展工作。
2. 根据规则审查该字段或关系，判断是否需要施加约束。
3. 定义合适的业务规则。
4. 通过修改相应的字段规范元素或关系特征来确立规则。
5. 确定测试该规则的操作。
6. 填写业务规则规范表。

3. 业务规则规范表

业务规则规范表是记录和审查业务规则的标准方法，它包含以下元素：
|元素|说明|
| ---- | ---- |
|字段名称|涉及的字段|
|表名称|涉及的表|
|陈述|规则的具体描述|
|约束|规则的限制条件|
|测试操作|在插入、删除、更新时进行测试|
|类别|字段特定或关系特定|
|类型|面向数据库或面向应用|
|逻辑元素|如键结构、编辑规则等|
|物理元素|如长度、输入掩码等|

例如，对于 VENDORS 和 PRODUCTS 表的业务规则规范表如下：
|元素|详情|
| ---- | ---- |
|字段名称|VENDORS, PRODUCTS|
|表名称|VENDORS, PRODUCTS|
|陈述|PRODUCTS 的参与类型改为强制；PRODUCTS 的参与度改为 (1,N)；为 PRODUCTS 表定义了限制删除规则；VENDORS 表中的单条记录必须与 PRODUCTS 表中的至少一条记录关联；每个供应商必须至少供应一种产品|
|约束|/|
|测试操作|插入、删除（勾选）、更新|
|类别|关系特定|
|类型|面向数据库|
|逻辑元素|键结构、编辑规则、空值支持、唯一性等（部分勾选）|
|物理元素|长度、输入掩码、小数位数等（部分勾选）|

4. 验证表

可以创建和使用验证表来支持限制特定字段值范围的业务规则，有助于加强数据完整性。使用验证表时需要建立新的关系，这些关系与数据库中的其他关系具有相同的特征。

5. 视图概述

视图是由数据库中一个或多个表的字段组成的虚拟表，也可以包含其他视图的字段。组成视图的表和视图称为视图的基表。视图是“虚拟”的，因为它从基表中提取数据，而不是自行存储数据。数据库中仅存储视图的结构，每次以某种方式访问视图时，RDBMS 会重新构建并“重新填充”视图。许多主要的 RDBMS 程序支持视图，有些（如 Microsoft Access）将其称为保存的查询。

使用视图的原因有很多：
- 可以同时处理多个表的数据。
- 反映最新信息，因为每次访问视图时，RDBMS 都会重新构建和填充它。
- 可以根据个人或群体的特定需求进行定制。
- 有助于加强数据完整性。
- 可用于安全或保密目的。

6. 视图的类型

在设计数据库的逻辑结构时，可以定义三种类型的视图：数据视图、聚合视图和验证视图。
- 数据视图 ：用于检查和操作来自单个基表或多个基表的数据。
- 单表数据视图 ：通常只使用基表的部分字段。例如，基于 EMPLOYEES 表创建的 EMPLOYEE PHONE LIST 视图，只包含 EMPLOYEE ID、EMPFIRST NAME、EMPLAST NAME 和 EMPPHONE NUMBER 字段。每次访问该视图时，RDBMS 会重新构建和填充它，反映 EMPLOYEES 表中数据的最新变化。可以修改单表数据视图中的数据，这些修改会反映到基表中，但修改操作受字段规范和业务规则的限制。
- 多表数据视图 ：使用两个或更多相关表定义数据视图，这些表之间必须存在关系，以确保视图呈现的信息有效且有意义。例如，为社区学院数据库创建的 CLASS ROSTER 视图，使用 CLASSES 表的 CLASS NAME 字段和 STUDENTS 表的 STUDFIRST NAME、STUDLAST NAME 字段，通过 STUDENT CLASSES 链接表关联。每次访问该视图时，RDBMS 会使用基表的最新数据重新构建和填充它。可以修改多表数据视图中的大部分数据，但不能修改从基表引入的主键值，修改操作同样受字段规范和业务规则的限制。多表数据视图中可能会出现冗余数据，但这是由于合并记录导致的，数据实际上存储在基表中，符合数据库设计规则。数据视图没有自己的主键，但可以根据需要引入基表的主键。
- 聚合视图 ：用于以特定方式聚合一组数据并显示结果。可以使用一个或多个基表定义聚合视图，包含一个或多个聚合数据的计算字段和一个或多个用于分组聚合数据的数据字段。常见的聚合函数有 Sum、Average、Minimum、Maximum 和 Count。例如，对于学校数据库，最初定义的 CLASS REGISTRATION 数据视图包含 CLASS NAME 和 STUDENT ID 字段，为了方便统计每个班级的注册学生数量，可将 STUDENT ID 字段替换为计算字段 TOTAL STUDENTS REGISTERED，使用 Count 函数统计每个班级的学生数量。聚合视图具有以下特点：
- TOTAL STUDENTS REGISTERED 字段为每个班级名称显示一个数字，表示该班级的注册学生总数。
- CLASS NAME 字段的冗余被消除，成为分组字段，其值不能被修改。
- 由于聚合视图完全由分组字段和计算字段组成，因此不能修改其数据。聚合视图最适合作为报表的基础或提供各种统计信息。
- 验证视图 ：类似于验证表，可帮助实现数据完整性。当业务规则限制特定字段的值范围时，可以使用验证视图来实施约束。验证视图与验证表的区别在于其构造方式，验证表存储自己的数据，而验证视图从基表中提取数据。通常使用单个基表定义验证视图，并只包含基表的两三个字段。例如，在为小型承包商设计的数据库中，SUBCONTRACTORS 表的 SUBCONTRACTOR ID 字段为 PROJECT SUBCONTRACTORS 表的 SUBCONTRACTOR ID 字段提供值范围。为了限制用户对 SUBCONTRACTORS 表某些字段的访问，可以定义一个验证视图 APPROVED SUBCONTRACTORS，仅包含 SUBCONTRACTOR ID、SCNAME、SCPHONE NUMBER 和 SCFAX NUMBER 字段。

7. 总结

业务规则和视图在数据库设计中都起着至关重要的作用。业务规则确保数据的准确性和一致性，而视图则提供了灵活的数据访问方式。通过合理定义和使用业务规则和视图，可以提高数据库的性能和可用性，满足不同用户的需求。

8. 总结流程图

graph LR
    A[业务规则] --> B[定义与建立]
    B --> C[填写规范表]
    A --> D[分类]
    D --> E[字段特定]
    D --> F[关系特定]
    G[视图] --> H[类型]
    H --> I[数据视图]
    H --> J[聚合视图]
    H --> K[验证视图]
    I --> L[单表数据视图]
    I --> M[多表数据视图]

数据库业务规则与视图全解析

9. 业务规则的实际应用与操作步骤

在实际应用中，定义和建立业务规则需要遵循一定的操作步骤，以确保规则的准确性和有效性。以下是详细的操作流程：
1. 与用户和管理层沟通 ：了解组织对数据的使用方式和业务需求，确定所需的业务规则。这一步骤需要与相关人员进行充分的交流，确保规则符合实际业务情况。
2. 确定规则类型 ：判断业务规则是字段特定还是关系特定。对于字段特定业务规则，关注特定字段的规范元素；对于关系特定业务规则，着重考虑关系的特征。
3. 审查字段或关系 ：根据确定的规则，审查相关的字段或关系，判断是否需要施加约束。例如，检查字段的取值范围、是否允许为空等。
4. 定义业务规则 ：明确规则的具体内容，包括规则的陈述、约束条件等。规则的陈述应该清晰明了，约束条件要准确无误。
5. 修改规范元素或关系特征 ：根据定义的业务规则，修改相应的字段规范元素或关系特征。例如，调整字段的长度、输入掩码等，或者修改关系的参与度和删除规则。
6. 确定测试操作 ：决定在哪些操作（插入、删除、更新）时测试业务规则。确保规则在关键操作中能够得到有效验证。
7. 填写业务规则规范表 ：将规则的相关信息记录在业务规则规范表中，包括字段名称、表名称、规则陈述、约束条件、测试操作、类别、类型等。规范表的填写要准确完整，以便后续的查询和维护。

10. 视图的操作与注意事项

使用视图时，需要注意以下操作和事项：
- 创建视图 ：根据实际需求，选择合适的基表和字段来创建视图。可以使用 RDBMS 提供的视图创建工具，按照语法要求编写视图定义语句。例如，在 SQL 中，可以使用 CREATE VIEW 语句来创建视图。
- 访问视图 ：每次访问视图时，RDBMS 会重新构建和填充视图，确保显示的是最新数据。访问视图的方式与访问普通表类似，可以使用查询语句进行数据检索。
- 修改视图数据 ：对于数据视图，可以修改其中的数据，但要注意修改操作受字段规范和业务规则的限制。不能修改聚合视图的数据，因为它完全由分组字段和计算字段组成。
- 注意视图的性能 ：视图的性能可能会受到基表数据量和查询复杂度的影响。在设计视图时，要尽量优化查询语句，避免不必要的复杂计算。
- 检查 RDBMS 文档 ：不同的 RDBMS 对视图的支持和约束可能有所不同。在使用视图之前，务必检查 RDBMS 的文档，了解其对视图的具体要求和限制。

11. 业务规则与视图的关联与协同作用

业务规则和视图在数据库中相互关联，协同作用，共同提高数据库的性能和可用性。以下是它们之间的关联和协同方式：
|关联点|说明|
| ---- | ---- |
|数据完整性|业务规则确保数据的准确性和一致性，视图可以通过验证视图来加强数据完整性。例如，验证视图可以限制字段的取值范围，与业务规则中的约束条件相配合。|
|数据访问|视图提供了灵活的数据访问方式，用户可以根据自己的需求定制视图。业务规则可以控制用户对数据的访问权限，确保数据的安全性。例如，通过业务规则限制用户对某些字段的访问，再通过视图只展示允许访问的字段。|
|业务逻辑实现|业务规则体现了组织的业务逻辑，视图可以根据业务规则来展示符合特定条件的数据。例如，根据业务规则定义的关系特定规则，视图可以展示相关联的数据。|

12. 案例分析

以下通过一个具体案例来进一步说明业务规则和视图的应用。假设我们正在设计一个图书馆管理数据库，包含以下表：
- BOOKS 表 ：存储书籍的基本信息，如书籍 ID、书名、作者、出版日期等。
- BORROWERS 表 ：记录借阅者的信息，如借阅者 ID、姓名、联系方式等。
- BORROW_RECORDS 表 ：记录书籍的借阅记录，包括借阅 ID、书籍 ID、借阅者 ID、借阅日期、归还日期等。

业务规则设计 ：
- 字段特定业务规则 ：
- 书籍 ID 字段必须唯一，不允许为空。可以通过设置字段的唯一性和非空约束来实现。
- 借阅日期必须小于归还日期。可以在插入或更新记录时进行检查，确保满足该条件。
- 关系特定业务规则 ：
- 每本图书最多只能被一个借阅者借阅。可以通过设置关系的参与度和删除规则来保证。
- 借阅者必须至少借阅一本图书。可以通过修改关系的参与度来实现。

视图设计 ：
- 数据视图 ：创建一个 CURRENT_BORROWERS 视图，显示当前正在借阅书籍的借阅者信息。该视图可以基于 BORROWERS 表和 BORROW_RECORDS 表，只显示借阅日期小于当前日期且归还日期为空的记录。
- 聚合视图 ：创建一个 BOOK_BORROW_COUNT 视图，统计每本书的借阅次数。该视图可以使用 BORROW_RECORDS 表，通过 Count 函数统计每本书的借阅记录数量。
- 验证视图 ：创建一个 APPROVED_BOOKS 视图，限制用户只能访问某些特定类别的书籍。该视图可以基于 BOOKS 表，只显示符合特定类别条件的书籍。

13. 业务规则与视图的优化建议

为了提高数据库的性能和可用性，对业务规则和视图进行优化是很有必要的。以下是一些优化建议：
- 业务规则优化 ：
- 减少不必要的规则，避免过度约束导致数据操作的复杂性增加。
- 定期审查和更新业务规则，确保规则符合实际业务变化。
- 对规则进行分类管理，便于查询和维护。
- 视图优化 ：
- 避免在视图中使用复杂的计算和嵌套查询，以提高视图的性能。
- 对经常使用的视图进行索引，加快数据的检索速度。
- 合理选择基表和字段，避免视图包含过多不必要的信息。

14. 总结与展望

通过对业务规则和视图的深入了解和应用，我们可以看到它们在数据库设计和管理中发挥着重要的作用。业务规则确保了数据的准确性和一致性，视图提供了灵活的数据访问方式。在未来的数据库发展中，随着业务需求的不断变化和技术的不断进步，业务规则和视图的应用将会更加广泛和深入。我们需要不断学习和掌握相关知识，以更好地应对各种数据库挑战，提高数据库的性能和可用性，为组织的发展提供有力的支持。

15. 整体流程总结表

步骤	业务规则	视图
定义	与用户和管理层沟通确定规则	根据需求选择基表和字段
建立	审查、修改规范元素或关系特征	使用 RDBMS 工具创建视图
测试	确定测试操作	访问视图检查数据
优化	减少不必要规则，定期审查更新	避免复杂计算，合理选择基表字段

16. 综合流程图

graph LR
    A[数据库设计] --> B[业务规则]
    A --> C[视图]
    B --> D[确定规则类型]
    D --> E[字段特定规则]
    D --> F[关系特定规则]
    B --> G[审查与修改]
    G --> H[填写规范表]
    C --> I[确定视图类型]
    I --> J[数据视图]
    I --> K[聚合视图]
    I --> L[验证视图]
    C --> M[创建与访问]
    M --> N[测试与优化]
    B --> O[优化规则]
    C --> P[优化视图]
    O --> Q[减少规则,定期审查]
    P --> R[避免复杂计算,合理选表]