多个事务并发执行时，不同事务相互隔离，一个事务的执行不能被其他事务干扰-优快云博客

图片内容描述了M集团为了有效管理旗下多个分公司的员工，决定构建一个信息平台的需求分析和关系模式设计。

需求分析

分公司关系模式：需要记录的信息包括分公司编号、名称、经理号、可联系地址和电话。每个分公司都有一名经理，负责公司的管理工作。每个分公司设立多个业务部，如研发部、财务部、采购部、交易部等。
业务部关系模式：需要记录的信息包括业务部编号、名称、地址、电话和分公司编号。每个业务部有一名主管负责管理工作，每个业务部有多名职员，每个职员只能来源于一个业务部。
职员关系模式：需要记录的信息包括职员号、姓名、所属业务部编号、岗位、电话、家庭成员姓名和成员关系。职员的岗位包括经理、主管、研究员、业务员等。

关系模式

分公司：包含分公司编号、名称、经理号、联系地址。
业务部：包含业务部门编号、名称、地址、电话。
职员：包含职员号、姓名、岗位、电话、家庭成员姓名、关系。

概念模型设计

这部分内容在图片中没有具体展开，但通常涉及如何将上述关系模式转化为数据库设计中的具体表结构和字段定义。

答案

(a) 经理号、电话
(b) 地址、分公司编号
© 所属业务部编号

解析

对于分公司关系模式：根据需求分析 1，分公司关系模式需记录公司编号、名称、经理号、可联系地址和电话，已知已有分公司编号、名称、联系地址，所以空缺处应补充经理号、电话。
对于业务部关系模式：依据需求分析 2，业务部关系模式要记录业务部的编号、名称、地址、电话和分公司编号，已知已有业务部门编号、名称、电话，所以空缺处应补充地址、分公司编号。
对于职员关系模式：按照需求分析 3，职员关系模式需记录职员号、姓名、所属业务部编号、岗位、电话、家庭成员姓名和成员关系，已知已有职员号、姓名、岗位、电话、家庭成员姓名、关系，所以空缺处应补充所属业务部编号。
分公司和职员之间的关联是通过业务部来实现的。具体来说，这种关联关系可以描述如下：

分公司包含多个业务部。
业务部包含多个职员。
每个职员属于一个特定的业务部，而每个业务部属于一个特定的分公司。

因此，职员与分公司之间的关联是间接的，通过业务部来连接。职员记录中会包含一个业务部编号，而业务部记录中会包含一个分公司编号。这样，通过业务部编号可以找到职员所属的业务部，再通过业务部的分公司编号可以找到该业务部所属的分公司。

在数据库设计中，这种关系通常通过外键来实现。例如：

职员表中会有一个外键字段（例如business_department_id），该字段引用业务部表的主键（business_department_id）。
业务部表中会有一个外键字段（例如company_id），该字段引用分公司表的主键（company_id）。

通过这种方式，可以确保数据的一致性和完整性，同时也方便进行数据查询和维护。
在构建M集团信息平台以确保数据一致性和完整性方面，可从以下几方面着手：

设计层面

合理的数据库模式设计：依据需求准确设计分公司、业务部、职员等关系模式，明确各属性及关联。如分公司与业务部通过分公司编号关联，业务部与职员通过业务部编号关联，避免数据冗余和不一致。利用规范化理论，消除数据依赖中不合适部分，减少插入、删除、更新异常。比如将数据规范到第三范式（3NF），确保每个非主属性既不部分依赖也不传递依赖于候选键。
设置主键和外键约束：为分公司、业务部、职员等关系模式设置合适主键，如分公司编号、业务部门编号、职员号等，确保每条记录唯一性。通过外键建立表间关联，如业务部表中外键分公司编号参照分公司表主键，职员表中外键所属业务部编号参照业务部表主键，保证关联数据一致性。

操作层面

事务管理：对涉及多个数据操作的业务，如职员从一个业务部调动到另一个业务部（涉及职员表和业务部相关数据更新），使用事务处理。事务具有原子性，要么全部操作成功提交，要么全部失败回滚，防止部分操作导致数据不一致。
数据验证：在数据录入环节，对输入数据进行有效性验证。比如分公司电话、职员电话需符合电话号码格式规范；业务部地址长度、格式要符合规定等。对输入的分公司编号、业务部编号等外键值，检查是否在对应主表中存在，避免无效关联。

监控和维护层面

审计和日志记录：建立审计机制和日志系统，记录对数据的所有增、删、改操作。通过审计日志，可追溯数据变化历史，发现异常操作及时处理，保障数据完整性。例如若发现某个业务部被误删除，可依据日志恢复数据。
定期数据检查和修复：定期运行数据检查脚本，检测数据是否存在不一致情况，如是否存在孤立记录（如职员所属业务部在业务部表中不存在）。一旦发现问题，及时采取修复措施，如更新关联数据或删除无效数据。
职员要知道自己属于哪个分公司，可以通过以下步骤进行查询：

查看职员记录：职员的记录中会包含一个业务部编号，这是职员所属业务部的唯一标识。
查询业务部信息：使用职员记录中的业务部编号，查询业务部表，找到对应的业务部记录。
获取分公司编号：在业务部记录中，会有一个分公司编号，这是该业务部所属分公司的唯一标识。
查询分公司信息：使用业务部记录中的分公司编号，查询分公司表，找到对应的分公司记录。
获取分公司信息：在分公司记录中，可以找到分公司的名称、地址、电话等信息，这些信息表明了职员所属的分公司。

在数据库中，这种查询可以通过连接（JOIN）操作来实现，例如：

SELECT 职员.姓名, 分公司.名称 AS 分公司名称
FROM 职员
JOIN 业务部 ON 职员.业务部编号 = 业务部.编号
JOIN 分公司 ON 业务部.分公司编号 = 分公司.编号;

这个查询会返回职员的姓名和他们所属的分公司名称，从而让职员知道自己属于哪个分公司。通过这种方式，职员可以清楚地了解自己在公司组织结构中的位置。
事务管理主要通过以下特性来保证数据一致性和完整性：

原子性（Atomicity）

事务是一个不可分割的工作单位，事务中的操作要么全部执行，要么全部不执行。例如在银行转账中，从一个账户扣款并向另一个账户存款这两个操作构成一个事务。若扣款成功但存款因系统故障失败，事务会回滚，撤销扣款操作，避免一方账户资金减少而另一方未增加的不一致情况。在M集团信息平台里，若要调整职员所属业务部，涉及职员表和业务部相关数据更新操作，若其中一个更新失败，事务回滚，保证数据状态一致，不会出现职员归属错乱等问题。

一致性（Consistency）

事务执行前后，数据库的完整性约束没有被破坏。比如转账事务执行前，两个账户总金额是固定值，事务执行后，总金额应保持不变。在M集团中，若业务部调整预算（涉及多个财务相关数据更新），事务执行完后，相关财务数据应符合财务规则和业务逻辑，保证数据整体一致性和完整性。

隔离性（Isolation）

多个事务并发执行时，不同事务相互隔离，一个事务的执行不能被其他事务干扰。比如多个用户同时进行转账操作，各转账事务相互隔离，避免因并发导致数据错误。在M集团信息平台，若多个用户同时对职员信息进行修改操作，隔离性可防止操作相互干扰，保证数据修改正确，维护数据一致性。

持久性（Durability）

一个事务一旦提交，它对数据库中数据的改变就应该永久保存，接下来的其他操作或故障不应该对其执行结果有任何影响。如转账事务提交后，即便系统崩溃，转账结果依然存在。在M集团里，当职员信息修改事务提交后，后续不管出现什么状况，修改后的数据都能持久保存，确保数据完整性。
如果业务部编号错了，可能会导致职员被错误地关联到错误的业务部，进而影响到职员与分公司的关联关系。这种情况需要及时纠正，以确保数据的准确性和业务流程的正常运行。以下是处理业务部编号错误的一些步骤：

识别错误：首先需要发现业务部编号的错误。这可能通过数据审核、员工反馈或系统自动检测异常来实现。
数据备份：在进行任何更改之前，备份当前的数据是非常重要的。这样可以在必要时恢复原始数据。
更正错误：
- 直接修改：如果错误是个别情况，可以直接在数据库中更新错误的业务部编号为正确的编号。
- 批量更新：如果错误是普遍存在的，可能需要编写脚本或使用数据库管理工具来进行批量更新。
更新相关记录：如果职员表或其他相关表中使用了错误的业务部编号作为外键，也需要更新这些记录以反映正确的业务部编号。
验证更新：更新完成后，需要验证数据的一致性和准确性。这可以通过查询和报表来完成，确保所有相关记录都已正确更新。
通知相关人员：如果业务部编号的错误影响了员工的薪资、报告线或其他业务流程，需要通知相关人员，以便他们可以据此调整自己的工作。
防止未来错误：分析错误发生的原因，并采取措施防止未来再次发生类似的错误。这可能包括改进数据输入流程、增加数据验证步骤或提供员工培训。
记录和审计：记录错误发生的情况和采取的纠正措施，以便于未来的审计和分析。