【软考架构】第2章 2.3.3 关系数据库

最新推荐文章于 2025-10-28 16:44:02 发布

小马哥编程

最新推荐文章于 2025-10-28 16:44:02 发布

阅读量861

点赞数 22

CC 4.0 BY-SA版权

文章标签：架构数据库

本文链接：https://blog.csdn.net/qq_41413652/article/details/153967551

数据模型是数据特征的抽象，它是对数据库组织方式的一种模型化表示，是数据库系统的核心与基础。它具有数据结构、数据操作和完整性约束条件三要素。关系可以理解为二维表。一个关系模型就是指用若干关系表示实体及其联系，用二维表的形式存储数据。例如，对某高校学生的选课(不同年级甚至同一年级学生所选课程可以不同)进行管理，可以用二维表表示，如图2-4所示。
在这里插入图片描述
用关系表示如下，其中带下画线的属性为主码，主码能唯一确定某个实体，如学号能唯一确定某个学生。
学生(学号，姓名，年龄，系别)
课程(课程号，课程名，学分)
选课(学号，课程号，分数)

1)关系数据库设计的特点及方法

数据库设计是指对于一个给定的应用环境构造最优的数据库，建立数据库及其应用系统，使之能有效地存储数据，满足各种用户的需求。数据库设计包括结构特性和行为特性的设计两方面的内容。
数据库设计的很多阶段都可以和软件工程的各阶段对应起来，数据库设计的特点有：从数据结构即数据模型开始，并以数据模型为核心展开，这是数据库设计的一个主要特点；静态结构设计与动态行为设计分离；试探性；反复性和多步性。
目前已有的数据库设计方法可分为4类，即直观设计法、规范设计法、计算机辅助设计法和自动化设计法。常用的有基于3NF的设计方法、基于实体联系(E-R)模型的数据库设计方法、基于视图概念的数据库设计方法、面向对象的关系数据库设计方法、计算机辅助数据库设计方法、敏捷数据库设计方法等。

2)关系数据库设计的基本步骤

数据库设计分为需求分析、概念结构设计、逻辑结构设计、物理结构设计、应用程序设计和运行维护6个阶段，如图2-5所示。
在这里插入图片描述

需求分析阶段的任务是对现实世界要处理的对象(组织、部门和企业等)进行详细调查，在了解现行系统的概况和确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。需求分析是在用户调查的基础上，通过分析逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。

数据库概念结构设计是在需求分析的基础上，依照需求分析中的信息需求，对用户信息加以分类、聚集和概括，建立信息模型，并依照选定的数据库管理系统软件，把它们转换为数据的逻辑结构，再依照软硬件环境，最终实现数据的合理存储。这一过程也称为数据建模。

设计数据库概念模型的最著名、最常用的方法是E-R方法。采用E-R方法的数据库概念结构设计可分为三步：设计局部E-R模型、设计全局E-R模型以及全局E-R模型的优化。

逻辑结构设计是在概念结构设计基础上进行的数据模型设计，可以是层次、网状模型和关系模型。逻辑结构设计阶段的主要任务是确定数据模型，将E-R图转换为指定的数据模型，确定完整性约束，确定用户视图。

这句话精辟地概括了逻辑结构设计阶段的核心工作。我们可以将它拆解为四个递进的步骤来深入理解：

flowchart TD
    A[“概念结构设计成果<br>E-R图”] --> B(第一步：确定数据模型)
    
    subgraph C [逻辑结构设计阶段]
        direction TB
        B --> D(第二步：模型转换<br>将E-R图转换为关系模型)
        D --> E(第三步：确定完整性约束<br>保障数据一致性与正确性)
        E --> F(第四步：确定用户视图<br>实现数据安全与简化)
    end

    C --> G[“最终成果<br>可供物理设计使用的具体模式”]

第一步：确定数据模型

理解：这是在“概念模型”和“具体DBMS”之间架设桥梁。虽然今天绝大多数系统使用关系模型（即基于表的模型），但理论上还有其他模型（如网状、层次模型）。这一步明确了我们将用关系理论（表、行、列）来描述和构建数据库。

第二步：将E-R图转换为指定的数据模型

理解：这是该阶段最实质性的转换工作。它需要遵循明确的规则，将抽象的E-R图成分具体化为关系模型中的元素：
- 实体 → 表/关系：每个实体型转换为一张表。
- 实体属性 → 表的列/字段：实体的属性转换为表的列。
- 实体标识符 → 主键：实体的主标识符转换为该表的主键。
- 实体间联系 → 外键或新表：
  - 1:1 或 1:n 联系：通常通过在“多”方表中添加外键来表示。
  - m:n 联系：必须创建一个新的关联表，该表至少包含双方实体的主键作为复合外键。

第三步：确定完整性约束

理解：这是为数据注入业务规则和一致性保证，是数据库的“法律体系”。它主要包括：
- 实体完整性：每个表的主键不能为空（NOT NULL）且必须唯一。
- 参照完整性：定义外键与主键之间的引用关系，确保不会引用不存在的记录。
- 用户自定义完整性：根据业务需求定义的特定规则，如“年龄必须在0-150之间”、“性别只能是‘男’或‘女’”。

第四步：确定用户视图

理解：这是面向用户的最后一步，旨在实现数据的安全性、逻辑独立性和简洁性。
- 视图是一种虚拟表，其内容由查询定义。
- 作用：
  1. 安全性：只为不同角色的用户（如经理、普通员工）提供他们需要的数据列和行，隐藏敏感信息和不相关数据。
  2. 逻辑独立性：当底层基表的结构发生变化时，只要视图的查询结果不变，面向用户的应用程序就无需修改。
  3. 简化复杂性：将一个复杂的多表查询封装成一个视图，用户可以直接像查询单表一样操作。

总结而言：
这句话描述了一个从抽象到具体、从结构到规则、再从规则到用户界面的完整过程。它确保了概念模型能被准确无误地实现为一个结构优良、约束严谨、且便于不同用户安全高效访问的数据库逻辑蓝图。这个蓝图是后续物理结构设计（如何在磁盘上存储）和应用程序开发的直接依据。

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构。数据库的物理结构设计是对已确定的数据库逻辑结构，利用DBMS所提供的方法、技术，以较优的存储结构和数据存取路径、合理的数据存放位置以及存储分配，设计出一个高效的、可实现的数据库物理结构。

数据库应用系统开发是DBMS的二次开发，一方面是对用户信息的存储；另一方面就是对用户处理要求的实现。

数据库应用程序设计要做的工作有选择设计方法、制订开发计划、选择系统架构和设计安全性策略。在应用程序设计阶段，设计方法有结构化设计方法和面向对象设计方法两种。安全性策略主要是指硬件平台、操作系统、数据库系统、网络及应用系统的安全。

数据库的正常运行和优化也是数据库设计的内容之一。在数据库运行维护阶段要做的工作主要有数据库的转储和恢复，数据库的安全性和完整性控制，数据库性能的监督、分析和改造，数据库的重组和重构等。

根据图2-5和描述，我们可以对关系数据库设计的六个基本步骤进行深入解析。这六个阶段环环相扣，是一个从抽象需求到具体实现的系统工程。

下图清晰地展示了这一循序渐进的设计流程与核心任务：

以下是每个阶段的详细解析：

1. 需求分析

核心任务：全面收集、分析并确定整个系统所要处理的数据和业务规则。这是整个设计的基石，若此阶段出错，后续工作将偏离方向。
输入：与用户和业务专家的沟通。
输出：需求说明书，详细定义了“当前和未来应用的数据要求”和“数据处理要求”。

2. 概念结构设计

核心任务：将需求分析的结果抽象为一个信息世界的模型，独立于任何具体的数据库管理系统（DBMS）。
方法与输出：通常使用E-R图 作为工具，创建“用户的数据模式”。这个模型只关心实体、属性、联系，而不涉及如何在计算机中实现。

3. 逻辑结构设计

核心任务：将概念模型转换为特定DBMS（如Oracle, MySQL）所支持的数据模型（关系模型）。这是“与DBMS相关”的第一步。
转换依据：
- 转换规则：指导如何将E-R图中的实体和联系转化为表、主键和外键。
- 规范化理论：用于审核和优化表结构，减少数据冗余，确保数据一致性。
- DBMS特性：考虑目标DBMS支持的数据类型、约束等。
输出：视图（为不同用户定制的数据外观）和概念模式（基本的表结构），以及应用处理说明书。

4. 物理结构设计

核心任务：为逻辑数据模型选择一个最合适的、在物理存储设备上的实现方案。它“与硬件和OS紧密相关”。
考虑因素：
- DBMS特性：利用DBMS提供的存取方法（如索引类型、聚簇存储）。
- 硬件与OS特性：考虑存储设备性能、操作系统文件管理方式等。
设计内容：确定文件的存储结构、存取路径（如索引的设计）、数据存放位置等，以追求最高的存取效率和存储空间利用率。

5. 应用程序设计与运行维护

应用程序设计：基于建立的数据模型，设计和编写前台应用程序（如Web、桌面、移动应用），实现具体的业务逻辑和数据处理功能。
运行维护：数据库投入运行后，需要持续进行性能监控、调整、备份、恢复、数据字典管理等工作。这是一个持续的迭代过程，根据运行情况和需求变化，可能需要对前述设计进行优化甚至重构。

总结：
这个设计流程体现了“自顶向下，逐步求精”的思想。它从用户需求出发，先构建一个独立于技术实现的抽象模型，再逐步考虑具体的DBMS、硬件和应用程序，最终形成一个高效、可靠、可维护的数据库系统。每个阶段的输出都是下一阶段的输入，确保了设计的连贯性和正确性。

2.分布式数据库

分布式数据库系统(Distributed DataBase System,DDBS)是针对地理上分散，而管理上又需要不同程度集中管理的需求而提出的一种数据管理信息系统。满足分布性、逻辑相关性、场地透明性和场地自治性的数据库系统被称为完全分布式数据库系统。

分布式数据库系统的特点是数据的集中控制性、数据独立性、数据冗余可控性、场地自治性和存取的有效性。

1)分布式数据库体系结构
我国在多年研究与开发分布式数据库及制定《分布式数据库系统标准》中，提出了把分布式数据库抽象为4层的结构模式，如图2-6所示。这种结构模式得到了国内外一定程度的支持和认同。

在这里插入图片描述
4层模式划分为全局外层、全局概念层、局部概念层和局部内层，在各层间还有相应的层间映射。这种4层模式适用于同构型分布式数据库系统，也适用于异构型分布式数据库系统。

2)分布式数据库的应用
分布式数据库的应用领域有分布式计算、Internet应用、数据仓库、数据复制以及全球联网查询等，Sybase公司的Replication Server即是一种典型的分布式数据库系统

图2-6非常经典，它展示了分布式数据库系统的参考体系结构。这种4层模式划分的核心思想是通过分层和映射，实现数据的分布透明性，即用户无需关心数据物理存储在哪里、如何分片、位于哪种数据库系统上，就能像操作一个单一的集中式数据库一样使用它。

下面我们对这个结构进行深入解析。

各层级的核心功能解析

整个体系结构可以看作是从用户的单一全局视角，到底层多个局部物理数据库之间的逐步映射和转换过程。

flowchart TD
    subgraph A [全局外层 | 用户视图层]
        direction LR
        A1[“全局视图A”]
        A2[“全局视图B”]
        A3[“全局视图...”]
    end

    subgraph B [全局概念层 | 全局逻辑层]
        B1[“全局概念模式<br>（集成所有站点的数据模型）”]
        B2[“分片模式<br>（水平/垂直分片规则）”]
        B3[“分配模式<br>（分片副本的分布位置）”]
    end

    subgraph C [局部概念层 | 站点映射层]
        direction LR
        C1[“局部概念模式A”]
        C2[“局部概念模式B”]
        C3[“局部概念模式...”]
    end

    subgraph D [局部内层 | 物理存储层]
        direction LR
        D1[“局部内模式A”]
        D2[“局部内模式B”]
        D3[“局部内模式...”]
    end

    subgraph E [局部数据库]
        E1[“局部数据库<br>（站点1: Oracle）”]
        E2[“局部数据库<br>（站点2: SQL Server）”]
        E3[“局部数据库<br>（站点3: MySQL）”]
    end

    A -- “映射1<br>（逻辑独立性）” --> B
    B -- “映射2与3<br>（分布透明性）” --> C
    C -- “映射4<br>（物理独立性）” --> D
    D --> E

1. 全局外层（Global External Level）

功能：这是用户或应用程序的视角。它定义了多个独立的全局视图，每个视图为特定用户组提供所需数据的逻辑结构，并屏蔽掉无关的数据。
类比：它与集中式数据库中的外模式（视图层）完全对应。

2. 全局概念层（Global Conceptual Level）

功能**：这是分布式数据库的核心抽象层，它描述了整个分布式系统所有数据的全局逻辑结构，仿佛数据没有被分布和分片一样。它包含三个关键部分：
- 全局概念模式（Global Conceptual Schema）：定义了所有全局实体、属性及其关系，是一个集成的、统一的数据模型。
- 分片模式（Fragmentation Schema）：定义了如何将全局数据切割成更小的逻辑单元（分片）。分片可以是水平的（按行，如不同地区的用户记录）、垂直的（按列，如将用户基本信息和登录信息分开）或混合的。
- 分配模式（Allocation Schema）：定义了每个分片的物理存放位置（在哪个站点存储），并指定是只存一份还是存储多个副本（复本）以实现容错和负载均衡。

3. 局部概念层（Local Conceptual Level）

功能：这一层将全局概念层中的概念，映射到各个局部站点数据库管理系统（DBMS）所能理解的概念模型上。
在异构系统中的关键作用：在异构分布式数据库（如一个站点用Oracle，另一个用MySQL）中，这一层负责将全局概念模式转换为特定于站点的局部概念模式。例如，将全局的VARCHAR类型转换为Oracle的VARCHAR2或MySQL的TEXT。

4. 局部内层（Local Internal Level）

功能：这一层描述数据在每个局部站点上的物理存储细节，如文件的存储结构、索引类型等。
类比：它与集中式数据库中的内模式完全对应。

层间映射：实现透明性的关键

图中连接各层的箭头代表了映射，这是实现透明性的技术核心：

映射1：保证了逻辑数据独立性。全局视图的变化不影响全局概念模式。
映射2 & 3：这是实现分布透明性的关键。它使得：
- 分片透明性：用户查询不需要指定数据在哪个分片。
- 位置透明性：用户查询不需要指定数据在哪个物理站点。
- 局部映射透明性：用户查询不需要关心局部DBMS的类型。
映射4：保证了物理数据独立性。局部概念模式的变化不影响应用程序。

对同构与异构系统的适用性

同构系统：所有局部站点使用相同类型的DBMS。此时，局部概念层可能非常简化，甚至与全局概念层基本相同，映射工作很简单。
异构系统：各站点使用不同类型的DBMS。此时，局部概念层至关重要，它作为一个“翻译官”，将统一的全局数据模型“翻译”成各种局部DBMS（如Oracle, SQL Server, DB2）所能理解的模式，从而实现对现有异构数据库的集成。