扫码获取 VIP 码
添加管理员微信获取 VIP 码
数据库三级模式结构是数据库领域的核心架构理论，由美国国家标准协会下属的标准规划与需求委员会于1975年正式提出。ANSI/SPARC体系结构将数据库抽象为三个层次：外模式、概念模式和内模式。这一分层思想的精髓在于"隔离变化"——每一层只关注自己的职责，层与层之间通过标准化的映像机制进行转换，实现数据与程序的彻底分离。
在三级模式结构中，外模式最贴近用户，内模式最贴近物理存储，概念模式居于中间承担承上启下的枢纽角色。三个模式各自独立演化，通过两级映像——外模式与概念模式之间的映像、概念模式与内模式之间的映像——来维持一致性。正是这种分层解耦的架构策略，赋予了数据库数据独立性这一至关重要的能力。
理解三级模式结构可以从一个现实困境切入。某企业人事数据库中存储着全体员工档案，人力资源部门需要查询姓名、工号和岗位，财务部门需要查询姓名、银行账号和薪资级别，行政部门需要查询姓名、办公地点和工位编号。三个部门面对同一套物理数据，各自需要的数据范围截然不同。如果让每个部门直接面对底层物理表编写查询程序，当数据库管理员调整表结构、增加字段或改变存储格式时，所有部门的程序都面临修改。三级模式结构正是为了解决这一耦合困境而构建的。
外模式又称子模式或用户模式，是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述。它是概念模式的子集，一个概念模式可以派生出多个外模式，每个外模式面向一类特定用户或应用场景。
外模式的引入带来三个核心价值。其一是安全隔离：不同用户通过外模式只能访问被授权的数据子集，无法越权查看敏感信息。其二是接口简化：开发人员只需关心外模式定义的局部数据结构，无需理解整个数据库的庞大逻辑模型。其三是逻辑数据独立性：当概念模式发生改变时，数据库管理员只需调整外模式与概念模式之间的映像，外模式本身可以保持不变，依赖该外模式的应用程序代码因此无需修改。
外模式不是物理上的数据副本，而是逻辑层面的视角定义。在主流关系数据库中，外模式通常通过视图机制以及列级和行级的权限控制来实现。需要注意的是，视图只是外模式的一种实现手段，两者的概念层次并不完全等同——外模式是抽象架构概念，视图是具体实现工具。
概念模式又称逻辑模式，是数据库中全部数据的整体逻辑结构和特征的描述。它处于三级模式结构的中间层，是所有用户的公共数据视图，也是数据库管理员视角下的全局全景图。
概念模式定义了数据库中存储哪些实体、实体之间有什么联系、每个实体包含哪些属性以及属性的数据类型和约束条件。它以某种数据模型为基础——在关系数据库中即关系模型——用数据定义语言描述数据项、记录类型和数据之间的联系。概念模式只描述数据是什么以及数据之间怎么关联，不涉及物理存储细节，也不涉及具体用户如何查看数据。
一个数据库只有一个概念模式。这意味着无论数据库有多少个外模式、无论底层存储采用何种文件组织方式，概念模式始终是全局唯一的逻辑基准。在关系数据库中，概念模式对应于基本表的集合——包括表名、列名、列的数据类型、主键约束、外键约束、唯一性约束和检查约束等，但不包括索引、聚簇方式等物理存储相关内容。概念模式来源于设计阶段的概念设计产物即实体联系图，经过逻辑设计阶段转换为关系模式后最终形成。它是三层中最稳定的数据库组件：业务需求的变化通常只影响外模式的定义，存储结构的变化只影响内模式，概念模式的修改频率最低。
内模式又称存储模式或物理模式，是数据在数据库内部的表示方式和存储结构。它描述数据的物理存储策略和存取路径，是三级模式中最低层、离硬件最近的一层。
内模式关心的核心要素包括数据文件和索引文件的组织方式——堆文件、顺序文件、散列文件或B+树索引文件——以及记录的存储格式为定长或变长、记录的物理顺序与逻辑顺序之间的映射、数据压缩策略、加密方式以及存储空间分配参数。一个数据库同样只有一个内模式。
在关系数据库中，内模式的具体体现包括表空间的定义、数据文件的物理路径、索引的B+树结构、聚簇索引的页链组织、数据块的大小和填充因子等。当数据库管理员执行创建索引或重建聚簇等操作时，实际上是在修改内模式。由于模式与内模式之间的映像机制屏蔽了物理变化，上层的外模式和概念模式完全感知不到这些底层调整。
理解内模式的关键在于区分物理存储和物理设备两个层次。内模式描述的仍然是数据的逻辑存储结构而非纯粹的硬件细节。内模式规定某个关系以B+树索引组织，但并不规定B+树节点具体落在磁盘的哪个柱面和扇区——那是操作系统和文件系统层面的任务。
三级模式结构之所以能够实现数据独立性，核心机制在于两级映像。映像可以理解为一种翻译规则或转换函数：它定义了上一层模式中的每一个概念和操作如何映射到下一层模式中的对应实体。两级映像由数据库管理系统在内部自动维护，对用户和应用程序完全透明。
外模式与概念模式之间的映像定义了每一个外模式中的数据结构如何从概念模式中推导出来。当概念模式发生改变时——例如为员工表增加一个学历字段、将地址字段拆分为省份、城市和详细地址三个独立字段、或者将员工表垂直拆分为员工基本信息和薪资信息两张表——数据库管理员只需调整外模式与概念模式之间的映像定义即可。
调整映像后，外模式可以对外维持概念模式未变化的外观。原本查询员工表所有字段的程序，映像会自动将查询翻译为对拆分后两张表的联合查询；原本不需要学历字段的外模式，映像则会屏蔽新增列。对于依赖该外模式的程序，一切如常，代码无需修改。这就是逻辑数据独立性的本质。
软考中有一个经典考点需要特别注意：当概念模式发生变化时，是通过修改外模式与模式之间的映像来保持外模式不变的。考生容易犯的错误是将外模式与模式映像和模式与内模式映像的作用相互混淆——前者保障逻辑独立性，后者保障物理独立性，二者职责截然不同。
概念模式与内模式之间的映像定义了概念模式中的关系、元组和属性如何映射到内模式中的存储记录、数据块和字段。当内模式发生改变时——例如为频繁查询的某列创建B+树索引、将原本以堆文件组织的表改为聚簇索引组织、或者将数据文件从一个磁盘迁移到另一个磁盘——只需修改模式与内模式之间的映像即可。
映像的调整使得概念模式完全不受底层物理变化的影响。数据库管理员发现某张表的全表扫描开销过大，决定为其订单日期列创建B+树索引。创建索引实际上改变了内模式——新增了一个索引文件并在内模式中注册了存取路径。但由于模式与内模式映像会将对概念模式中订单表的范围查询自动路由到索引扫描路径上，上层的概念模式定义和外模式定义都无需任何修改。
物理数据独立性的价值不仅体现在性能调优的便利性，更体现在存储硬件演进时的平滑适应性上。从机械硬盘到固态硬盘、从单机存储到分布式存储集群，只要数据库产品在模式与内模式映像层做好适配，上层应用完全不感知底层硬件的代际更替。
物理数据独立性是指当数据库的存储结构即内模式发生改变时，应用程序和概念模式可以保持不变的能力，由模式与内模式之间的映像来保障。典型的物理变化场景包括创建或删除索引、修改数据文件的存储路径、变更数据压缩算法、增加新的存储设备并将数据分布其上、调整数据块大小和填充因子等，这些操作全部属于内模式层面的变更，概念模式和外模式完全不受波及。
逻辑数据独立性是指当数据库的概念模式发生改变时，应用程序和外模式可以保持不变的能力，由外模式与概念模式之间的映像来保障。典型的逻辑变化场景包括在已有关系中增加新的属性列、将一个大关系拆分为多个小关系、合并多个关系为一个关系、修改属性列的数据类型或约束
本篇完！