【系统架构设计（37）】数据库体系结构

一、数据库体系结构

数据库体系结构是数据库系统的核心框架，它通过分层抽象的方式，将复杂的数据库系统分解为三个清晰的层次，每个层次都有明确的职责和边界。这种设计理念的核心在于认识到复杂业务系统的本质是业务逻辑的复杂性，而非技术实现的复杂性。

1、 数据库模式

数据库模式是数据库系统对数据组织和存储方式的抽象描述，它通过三级模式和两级映射关系，实现了数据的逻辑独立性和物理独立性。

1.1、 三级模式

外模式（用户模式）

• 定义：用户与数据库系统的接口，是用户可见的数据视图，不同用户通过各自的外模式访问数据库，描述用户可见的数据结构
• 作用：实现数据的逻辑独立性，为用户提供个性化的数据访问接口，如普通员工只能看到自己权限内的工资、考勤等数据视图，经理能看到部门整体业务数据视图

概念模式（逻辑模式）

• 定义：数据库的整体逻辑结构，反映数据库的整体逻辑关系和语义，处于中间层，不涉及数据的物理存储细节，是数据库管理员（DBA）视图
• 作用：用于管理和维护数据库，是三级模式的核心，定义全局数据逻辑结构，协调数据一致性和完整性

内模式（物理模式）

• 定义：描述数据在存储介质上的组织和存储方式，涉及数据的存储结构、索引方式、块大小等物理细节，与操作系统紧密相关
• 作用：管理物理存储，决定存储效率和访问性能，实现数据的物理独立性，适应不同硬件环境

 

1.2、 两级映射

外模式-概念模式映射

• 作用：建立外模式与概念模式之间的对应关系，当概念模式变化时，可通过调整此映射，使外模式尽量不变，保证用户应用程序无需修改，实现数据的逻辑独立性
• 机制：通过映射表或映射规则实现两层之间的转换，如数据库新增字段，但不影响用户原有访问视图

概念模式-内模式映射

• 作用：建立概念模式与内模式之间的对应关系，当内模式发生变化时，调整该映射可使概念模式不变，进而保证外模式和应用程序不受影响，实现数据的物理独立性
• 机制：通过存储映射表实现逻辑结构与物理存储的转换，如存储设备更换、存储结构调整时，不影响应用程序

 

2、（关系型数据库）关系表类型

关系型数据库中的数据主要以关系表的形式组织，包括基本表（实际存储数据的表，是数据库的核心组成部分）、视图（由查询定义的虚拟表，不存储实际数据）和物化视图（存储查询结果的实体化视图，提高查询性能）。

 

2.1、数据库视图

数据库视图通过虚拟化技术实现了数据访问的抽象化，在提供便利性的同时也带来了性能权衡。

数据库视图本质上是一种虚拟表，它由查询语句定义而不存储实际数据，当用户访问时通过动态执行查询来生成结果。这种设计让视图成为了查询逻辑的封装层，为用户提供了数据访问的抽象接口，使得复杂的数据库操作变得简单直观。

视图的核心价值在于它解决了数据访问的复杂性问题。

通过将复杂的多表关联查询封装成视图，用户只需要像操作普通表一样使用视图，无需了解底层的查询逻辑。

然而，视图的虚拟化特性也带来了显著的性能挑战。

由于视图不存储实际数据，每次查询都需要重新执行底层的查询语句，这增加了系统的计算开销。当视图定义包含复杂的子查询、多表连接或聚合操作时，这种性能影响会更加明显。在MySQL等数据库中，如果视图使用了临时表算法（如包含ORDER BY、GROUP BY等操作），系统会先将所有数据加载到临时表中，然后再应用外部的WHERE条件，这种"先查询后过滤"的方式会严重影响查询效率。

因此，视图的使用需要在便利性和性能之间找到平衡点。

对于频繁查询且计算复杂的场景，物化视图可能是更好的选择，它通过预计算和存储结果来避免重复计算。而对于简单的查询或对实时性要求不高的场景，普通视图则能提供更好的灵活性和维护性。这种权衡体现了数据库设计中抽象与性能之间的永恒博弈。

 

2.2 物化视图

物化视图通过预计算和存储机制解决了普通视图的性能瓶颈，为复杂查询场景提供了高效的解决方案。

物化视图与普通虚拟视图的根本区别在于它实际存储查询结果，而不是仅仅保存查询语句。当原始表数据发生变化时，物化视图会相应地更新其存储的数据，确保数据的一致性和实时性。

物化视图的核心优势在于它通过空间换时间的策略显著提升了查询性能。

通过提前计算并存储复杂的查询结果，物化视图避免了每次查询时重复执行复杂的计算过程。这种机制特别适用于频繁查询且计算复杂的场景，比如大型电商平台需要定期统计的销售报表数据。当用户查询月度销售汇总时，系统可以直接从物化视图中读取预计算的结果，而不需要重新执行涉及数百万条订单记录的复杂聚合查询。

然而，物化视图的维护成本也是不可忽视的考虑因素。

由于物化视图需要存储实际数据，它会占用额外的存储空间，并且需要维护与原始数据的同步机制。当原始数据频繁更新时，物化视图的维护开销可能会抵消其带来的性能优势。因此，物化视图最适合那些原始数据变动不频繁、但查询需求频繁且计算复杂的场景，如数据仓库中的历史数据统计、定期报表生成等应用。

 

3、分布式数据库

3.1 特性

分布式数据库通过多层次的数据独立性设计，实现了从集中式到分布式的无缝过渡，为用户提供了透明化的分布式数据访问体验。

分布式数据库系统的数据独立性体现在三个递进的层次上。

1. 逻辑独立性，确保用户应用程序与数据库逻辑结构解耦，当数据库表结构发生变化时，用户程序无需修改；
2. 物理独立性，进一步隔离了应用程序与存储硬件的依赖关系，存储设备的更换不会影响应用运行。
3. 分布独立性，它让用户能够像操作集中式数据库一样使用分布式数据库，完全屏蔽了数据在多个节点间的分布复杂性，这种透明性设计大大提高了系统的易用性和可管理性。

分布式数据库的控制架构巧妙地平衡了自治与集中的矛盾需求。

1. 各局部数据库管理系统具备自治功能，能够独立处理本地数据请求，根据本地业务需求灵活制定管理策略，这种设计保证了系统的响应速度和灵活性。
2. 全局控制机制负责协调各局部DBMS的工作，处理跨节点的数据查询和事务处理，确保整个分布式系统的一致性和协调性。

这种"分而治之"的架构设计既保证了局部的高效性，又维护了全局的统一性。

数据冗余策略是分布式数据库可靠性和性能的重要保障。

1. 通过在多个节点存储数据副本，系统能够在某个节点故障时继续提供服务，保障了数据的可用性和完备性。
2. 合理的数据副本分布还能让用户就近获取数据，减少网络传输开销，显著提高系统性能。

这种冗余设计体现了分布式系统"以空间换时间"和"以空间换可靠性"的经典权衡策略。

全局一致性、可串行性和可恢复性构成了分布式数据库事务处理的三大支柱。

1. 一致性确保所有节点在任何时刻都保持数据同步
2. 可串行性保证并发事务的执行结果与串行执行相同
3. 可恢复性则提供了故障后的系统恢复能力

这三个特性共同构成了分布式数据库ACID特性的分布式实现，为复杂业务场景提供了可靠的数据处理保障。

 

3.2 分布式数据库系统的模式结构

分布式数据库的模式结构通过分层抽象和映射机制，实现了从全局逻辑到局部物理的完整数据管理架构。

分布式数据库的全局DBMS相关模式构成了系统的顶层架构。

1. 全局外模式：作为用户与系统交互的接口，为不同用户和应用程序提供个性化的数据视图，体现了用户可见的数据结构和操作权限。
2. 全局概念模式：则描述了整个分布式数据库的逻辑结构和语义关系，涵盖了系统的数据关系和约束，但巧妙地避开了物理分布的复杂性。
3. 分片模式：定义了数据分割策略，包括水平分片（按行分割）和垂直分片（按列分割）等方式，这是实现数据分布存储的基础。
4. 分布模式：则具体确定了数据分片在各个节点的物理分布情况，与网络拓扑和节点存储能力等因素密切相关。

 

局部DBMS相关模式为每个节点提供了独立而协调的数据管理能力。

1. 局部概念模式：针对每个局部数据库，定义了该节点上数据的逻辑组织和关系，与全局概念模式保持相互关联，确保局部逻辑与全局逻辑的一致性。
2. 局部内模式：则深入到物理存储层面，描述局部数据库在存储介质上的具体存储结构，包括存储方式和索引结构等细节，与操作系统和存储设备紧密相关。这种设计让每个节点既能独立管理本地数据，又能与全局系统保持协调。

映像关系是连接全局与局部、逻辑与物理的关键桥梁。

1. 映像1：建立了全局外模式与全局概念模式之间的对应关系，保障了数据的逻辑独立性，当全局概念模式发生变化时，可以通过调整此映像使全局外模式不受影响。
2. 映像2：关联全局概念模式和分片模式，说明了全局数据逻辑结构如何被分割成各个分片。
3. 映像3：连接分片模式和分布模式，指明了数据分片的具体分布位置。
4. 映像4：则建立了全局概念模式与局部概念模式的映射，协调全局数据逻辑与局部数据逻辑的一致性。

这四个映像关系共同构成了分布式数据库的完整映射体系，实现了从用户视图到物理存储的全链路数据管理。

 

3.3 分布式数据库管理系统的组成和结构

分布式数据库管理系统通过四元组架构实现了全局协调与局部自治的完美结合，为大规模分布式数据管理提供了系统性的解决方案。

分布式数据库管理系统的组成体现了"分而治之"的设计哲学。

1. 局部数据库管理系统（LDBMS）：作为系统的基层组件，负责管理局部数据库的日常操作，包括数据存储、查询、更新和事务处理等，每个节点都具备一定的自治性，能够独立处理本地数据请求。
2. 全局数据库管理系统（GDBMS）：则扮演着"总指挥"的角色，从全局角度协调各局部数据库的工作，处理跨节点的全局事务，制定和调整数据分布策略，确保全局数据的一致性和完整性。
3. 全局数据字典：作为系统的"元数据中心"，存储着所有元数据信息，为GDBMS和LDBMS提供数据定义和管理的依据，是系统进行数据管理和查询优化的重要基础。
4. 通信管理（CM）：则负责节点间的通信协调，处理数据传输、消息传递和网络连接管理，确保整个分布式系统能够高效、可靠地通信。

分布式数据库管理系统的结构设计体现了在集中控制与分散自治之间的权衡艺术。

1. 全局控制集中的DDBMS将控制功能集中在一个或少数几个节点上，这种结构便于管理和协调全局事务，决策效率高，但存在单点故障风险，一旦控制节点出现问题，整个系统可能受到影响。
2. 全局控制分散的DDBMS将控制功能分散到多个节点上，各个节点都参与全局事务的决策和协调，具有较好的容错性和扩展性，但协调和管理的复杂度显著增加，可能导致决策效率降低。
3. 全局控制部分分散的DDBMS则试图在两者之间找到平衡点，将关键控制功能集中管理以保证效率，将其他控制功能分散到各个节点以提高可靠性，这种混合架构体现了分布式系统设计中的实用主义思想。

这种四元组架构和三种结构模式为不同规模和需求的分布式应用提供了灵活的选择空间。

无论是追求高可靠性的金融系统，还是需要高扩展性的互联网应用，都可以根据具体需求选择合适的架构模式。这种设计体现了分布式数据库系统在复杂性和实用性之间的精妙平衡，为现代大规模数据管理提供了坚实的理论基础和实践指导。

 

3.4 数据分片

分布式数据库的四种透明性设计构成了一个递进的抽象层次，从数据分片到系统异构，逐步屏蔽了分布式系统的复杂性，为用户提供了统一透明的数据访问体验。

分片透明性作为最高层次的透明性，完全屏蔽了数据分片的复杂性。

用户无需关心数据是按行分割还是按列分割，也无需了解数据被分布到哪些节点，系统会自动处理所有分片相关的事宜。例如，当系统需要重新分片以优化性能时，用户完全感知不到这种变化。

复制透明性进一步隐藏了数据冗余和副本管理的复杂性。

用户不需要了解数据在哪些节点有副本，也不需要关心副本数据的更新机制，系统会自动处理所有复制相关的事务。当某个节点出现故障时，其他节点的副本会无缝接管服务，用户完全感知不到这种切换过程。

位置透明性让数据迁移和系统扩展变得对用户完全透明。

用户不必知晓所操作数据的实际存储位置，系统会自动定位数据所在位置并完成操作。这种设计使得数据在不同节点间的迁移、系统扩容、故障修复等操作对用户完全透明，当数据库进行存储架构调整时，用户对数据的正常访问和操作不会受到任何影响。

局部映像透明性作为最低层次的透明性，解决了异构系统的兼容性问题。

在异构型和同构异质的分布式数据库系统中，不同的局部数据库可能采用不同的数据模型和数据操纵语言，局部映像透明性让用户能够以统一的方式访问这些异构的数据源。

 

3.5 两阶段提交协议（表决、执行）

两阶段提交协议通过"先表决后执行"的设计，确保了分布式事务的原子性和一致性，是分布式数据库事务管理的经典解决方案。

1. 两阶段提交协议的第一阶段——表决阶段，体现了分布式系统中"民主决策"的设计理念。

协调者向所有参与者发送"准备提交"请求，询问它们是否准备好提交事务，每个参与者需要检查自身的事务执行情况，如果能够成功提交则回复"同意"，如果遇到任何问题则回复"撤销"。这个过程实际上是在收集各参与者对事务提交的态度，为后续的决策提供依据，确保分布式事务在各节点的一致性。这种设计让系统能够在执行最终操作之前，先确认所有节点都处于可提交状态。

2. 执行阶段则体现了"全有或全无"的原子性原则。

如果表决阶段所有参与者都回复"同意"，协调者会向所有参与者发送"提交"指令，参与者执行事务提交操作，将事务结果持久化存储。然而，如果有任何一个参与者回复"撤销"，协调者会发送"撤销"指令，所有参与者都必须回滚事务，撤销已执行的操作。这种设计确保了分布式事务在所有节点上的最终状态完全一致，要么全部成功，要么全部失败，不存在部分成功的情况。

两阶段提交协议的核心价值在于它解决了分布式环境下的协调一致性问题。

通过将事务提交过程分解为表决和执行两个阶段，系统能够在复杂的分布式环境中保证事务的ACID特性。这种设计虽然增加了通信开销和延迟，但为分布式数据库提供了可靠的事务保障机制，是构建可靠分布式系统的重要基础。

 

两条全局提交规则

• 规则1：只要有一个参与者撤销事务，协调者就必须做出全局撤销决定，只要有一个节点因自身问题不能提交事务，为保证数据一致性，整个分布式事务都要撤销，避免部分节点提交成功、部分失败导致数据不一致
• 规则2：只有所有参与者都同意提交事务，协调者才能做出全局提交决定，只有当所有涉及事务的节点都确认可以提交事务，没有任何节点存在问题时，协调者才允许事务在所有节点提交，确保分布式事务在各节点都能正确执行

 

二、数据库设计过程

1、 设计流程

数据库设计流程体现了从需求到实现的完整转换过程，通过四个递进阶段将用户需求转化为可运行的数据库系统，体现了软件工程中"分而治之"的设计思想。

1. 需求分析作为起点，通过收集和分析用户对数据的需求，包括存储、查询、更新等操作需求，明确用户需要处理的数据类型、数据关系和处理逻辑。

这个过程通过与用户沟通和业务流程调研，产生数据流图、数据字典和需求说明书，为后续设计提供坚实的基础。数据流图描述数据在系统中的流动和处理过程，数据字典详细定义数据的各项属性，需求说明书则综合阐述用户需求，三者共同构成了需求分析的完整输出。

 

2. 概念结构设计将现实世界的需求抽象为与具体技术无关的概念模型。

这个阶段将需求分析的结果抽象为实体-关系（ER）模型，通过识别实体、属性和关系，构建出反映用户数据需求的概念结构。ER模型是对现实世界数据特征的抽象描述，不涉及具体的DBMS实现细节，这种抽象设计使得概念模型具有很好的通用性和可移植性。

例如，一个学生选课系统的概念模型可能包含学生、课程、选课等实体，以及它们之间的关系，这种抽象为后续的逻辑设计提供了清晰的指导。

 

3. 逻辑结构设计将抽象的概念模型转换为具体的数据库实现方案。

这个阶段将ER模型转换为与DBMS相关的逻辑数据模型，如关系模式，运用规范化理论对关系模式进行优化，消除数据冗余和更新异常等问题。

同时确定视图、完整性约束和应用处理说明书，得到的关系模式定义了数据库中表的结构、字段属性以及表之间的关系。这个过程体现了从概念到实现的转换，为物理设计提供了具体的逻辑框架。

 
4. 物理设计关注数据库在实际环境中的部署和运行细节。

根据选定的DBMS和硬件、操作系统环境，设计数据的物理存储结构和访问方法，确定数据文件的存储位置、索引的建立方式、数据的存储格式等，以提高数据库的性能和存储效率。

这个阶段的输出为数据库在实际环境中的部署和运行提供了具体方案，体现了从逻辑设计到物理实现的最终转换。整个设计流程体现了从抽象到具体、从需求到实现的完整转换过程，为构建高质量的数据库系统提供了系统性的方法论。

 

2、 概念结构设计

E-R模型通过实体、属性和联系三个基本概念，能够准确反映现实世界的数据特征和关系。

E-R模型的基本概念构成了概念设计的核心要素。

1. 实体代表现实世界中可区别于其他对象的"事物"或"对象"，在数据库设计中用矩形框表示；
2. 属性是实体所具有的某一特性，用椭圆形框表示并与对应的实体相连；
3. 联系则是实体之间的关联关系，用菱形框表示，联系本身也可能具有属性。

这种图形化的表示方法使得复杂的数据关系变得直观易懂，为数据库设计者提供了有效的建模工具。

 

联系类型的设计体现了现实世界中实体间关系的多样性。

1. 一对一关系表示一个实体实例仅与另一个实体实例相关联，如班级与班长的关系；
2. 一对多关系表示一个实体实例与另一个实体实例的多个实例相关联，如班级与学生的关系；
3. 多对多关系表示两个实体实例的多个实例相互关联，如学生与课程的关系。

 

概念结构设计流程体现了从局部到全局的系统化设计方法。

1. 设计步骤从抽象数据开始，对现实世界的数据进行抽象，提取关键的数据特征和关系。
2. 针对不同的局部应用或业务场景，分别设计局部ER模型，每个局部模型描述对应范围内的数据结构和关系。
3. 将各个局部ER模型合并成全局ER模型，识别并消除冲突，包括属性冲突、命名冲突和结构冲突等。
4. 对合并后的全局ER模型进行重构和优化，去除冗余的数据和关系，使模型更加简洁合理。

 

集成方法的选择体现了在效率和控制之间的权衡。

多个局部E-R图一次集成的方法效率较高，但当局部ER图数量多、关系复杂时，处理冲突的难度较大；逐步集成采用累加的方式，每次只集成两个局部ER图，相对更易于控制和处理冲突，但集成过程可能较为繁琐。这种权衡体现了复杂系统设计中效率与可控性之间的经典矛盾。

 

3、 逻辑结构设计

关系模型的数据模型三要素构成了其理论基础。

1. 数据结构：描述了数据的组织形式和类型，在关系模型中体现为二维表形式，表中的列定义数据类型，行则是具体的数据记录。
2. 数据操作：指对数据进行的各种操作，如查询、插入、删除、更新等，关系模型支持基于SQL语言的各种数据操作。
3. 数据的约束条件：用于限定数据的取值范围和数据之间的关系，保证数据的完整性和一致性，如主键约束确保表中每行记录的唯一性，外键约束保证表与表之间关联数据的一致性。这三个要素共同构成了关系模型的完整理论框架。

 

不同数据模型的对比体现了关系模型的优势所在。

1. 层次模型以树状结构组织数据，有且仅有一个根节点，其他节点有且仅有一个父节点，通常按层级关系组织；
2. 网状模型允许节点有多个父节点，能更灵活地表示数据之间的复杂关系；
3. 面向对象模型将数据和操作封装成对象，对象之间通过继承、聚合等关系相互关联。

相比之下，关系模型通过二维表的形式化表示，如"学生（学号，姓名，年龄，班级编号）"，其中U是属性集合，F是函数依赖集合，这种表示方法简洁明了，易于理解和操作。

 

关系模型的相关概念为数据组织提供了精确的定义体系。

1. 目或度指关系模式中属性的个数，
2. 候选码是能唯一标识关系中每一个元组且不包含冗余属性的属性或属性组合，
3. 主码是从候选码中任选一个用来唯一标识关系中的元组。
4. 主属性与非主属性的区分基于是否组成候选码，
5. 外码是关系中的某个属性或属性组，它不是当前关系的主码，但却是其他关系的主码，用于建立关系间的关联。
6. 全码则是当关系模式的所有属性组构成的集合能唯一标识元组且无冗余时的特殊情况。

 

完整性约束机制为数据质量提供了多层次的保障。

1. 实体完整性约束：规定主属性不能取空值，因为主属性用于唯一标识元组，若取空值就无法准确标识，会破坏数据的唯一性和完整性。
2. 参照完整性约束：用于维护关系与关系之间的引用关系，确保外键引用的有效性。
3. 用户自定义完整性约束：由具体的应用环境决定，根据用户业务需求制定约束条件，可以针对特定的属性取值范围、数据格式等进行限制。
4. 触发器：作为特殊的存储过程，能够在特定的数据库操作发生时自动执行，实现复杂的业务规则和数据完整性约束。

这四个层次的约束机制共同构成了关系数据库的完整性保障体系，为数据质量提供了全面的保护。

 

逻辑设计阶段的任务

主要任务

• E-R图向关系模式的转换：根据转换规则，将E-R图中的实体、属性和联系映射为关系模式
• 数据模型的优化：通过规范化理论，消除数据冗余，减少更新异常，提高数据存储效率和一致性
• 确定完整性约束：定义实体完整性、参照完整性以及用户自定义完整性
• 编写数据字典：详细描述每个关系模式、属性、域、约束等信息

 

设计原则

• 实体型转换规则：一个实体型必须转换为一个关系模式，这是因为实体是现实世界中可区别的对象，将其转换为关系模式，能以表的形式在数据库中存储和管理实体的属性信息
• 联系转换规则：
  • 一对一联系：可以创建独立的关系模式或归并到任意一端
  • 一对多联系：可以创建独立的关系模式或归并到多端
  • 多对多联系：只能创建独立的关系模式，主键是两端主键的组合键
• 联系类型尽可能少：要进行归并优化，减少关系模式的复杂度

 

三、关系代数

参考：【源码预备】Calcite基础知识与概念：关系代数概念、查询优化、sql关键字执行顺序以及calcite基础概念

关系代数为关系型数据库提供了数学化的查询理论基础，通过传统集合运算和专门关系运算，实现了对关系数据的精确操作和查询。

同构关系是关系代数运算的重要约束条件，确保了运算的数学严谨性。

同构要求参与某些运算的关系必须具有相同的属性结构，即属性列数相同且对应属性的域相同。这种约束主要应用于并、交、差等传统集合运算，确保了运算结果的数学意义和实际应用价值

1. 并运算（S1 ∪ S2）将两个同构关系的元组合并，去除重复项，体现了集合的并集概念；
2. 交运算（S1 ∩ S2）找出两个关系中完全相同的元组，体现了集合的交集概念；
3. 差运算（S1 - S2）取属于第一个关系但不属于第二个关系的元组，体现了集合的差集概念。这些运算都要求关系同构，确保了运算的数学严谨性。

 
笛卡尔积是关系代数中唯一不要求同构的运算，为连接操作提供了基础。

笛卡尔积将两个关系的所有可能组合进行拼接，结果元组的数量是两个关系元组数量的乘积。这种运算虽然不要求关系同构，但会产生大量的中间结果，在实际应用中通常与其他条件结合使用，如等值连接和自然连接。

 

专门关系运算提供了更贴近实际查询需求的操作方式。

1. 投影运算从列的角度选择属性，相当于SQL中的SELECT子句；
2. 选择运算从行的角度筛选元组，相当于SQL中的WHERE子句。
3. 自然连接则在等值连接的基础上自动去除重复属性列，其性能优于笛卡尔积，体现了查询优化的思想。

这些运算的组合使用能够表达复杂的查询需求，为关系型数据库的查询优化提供了理论基础。