一、数据库系统 00:00

1. 历年考情 00:18

• 考试频率：数据库章节每年必考，选择题分值3-5分
• 案例分析：在案例分析题中每年固定考查一题，需重点关注
• 重要性说明：相比软件硬件操作系统章节，数据库考点在教材改版后保持完整

2. 教材改动 00:38

• 
• 章节分布：
  • 基础概念位于2.3.3节
  • 核心技术集中在第六章
• 主要改动：
  • 数据库设计：新增两个设计阶段并补充内容（需重点复习）
  • NoSQL技术：仅简单新增，主要在案例题考查（案例专题会详细讲解）
• 保留内容：
  • 三级模式两级映像
  • 数据模型（E-R模型/关系模型）
  • 关系代数与SQL语言
  • 规范化理论（函数依赖/键约束/范式分解）
  • 并发控制（三级封锁协议）
  • 数据库安全与分布式技术
  • 数据仓库与反规范化技术
• 学习建议：
  • 老学员只需重点复习数据库设计部分改动
  • NoSQL相关内容直接学习案例专题部分

3. 数据库系统内容 02:07

1）数据库系统 03:52

• 数据 04:02
  • 基本定义: 数据库中存储的基本对象，是描述事物的符号记录
  • 主要种类:
    • 文本、图形、图像、音频、视频
    • 学生档案记录、货物运输情况等具体应用实例
  • 本质归类: 计算机数据可归为三大类：文本、图形图像、音频视频，其他具体形式都是这三类的组合或应用
• 数据库 04:51
  • 
  • 英文缩写: DB(Database)
  • 核心定义: 长期存储在计算机内、有组织的、可共享的大量数据集合
  • 常见误解: 不能简单理解为"数据仓库"，二者有专业区别
  • 关系模型特点: 现代主流数据库(如MySQL、Oracle)都采用关系模型，表现为有行有列的表结构
• 数据库的基本特征 05:16
  • 组织方式: 按特定数据模型(如关系模型)组织、描述和存储
  • 共享性: 支持多用户共享访问
  • 冗余控制: 通过规范化手段减小数据冗余
  • 独立性: 数据具有较高独立性
  • 扩展性: 系统易于扩展
• 数据库系统 06:29
  • 
  • 英文缩写: DBS(Database System)
  • 系统定义: 采用数据库技术，有组织地动态存储大量相关数据，支持多用户访问的计算机系统
  • 四大组成部分:
    • 数据库：统一管理的相关数据集合
    • 硬件：计算机及存储设备
    • 软件：操作系统、DBMS及应用程序
    • 人员：设计人员、程序员、用户、DBA
  • 数据库管理系统 07:52
    • 英文缩写: DBMS(Database Management System)
    • 系统定位: 属于DBS中的软件组成部分
    • 核心功能: 对共享数据进行有效组织、管理和存取
    • 主要操作:
      • 数据定义
      • 数据库操作
      • 运行管理
      • 存储管理
      • 建立维护
    • 开发接口: 提供SQL语言供应用程序调用

2）三级模式两级映射 08:52

• 
• 模式层级:
  • 外模式(外部视图)：与用户直接交互的视图层
  • 模式(概念模式)：数据库中的基本表结构
  • 内模式：物理存储文件管理
• 映射关系:
  • 外模式/模式映射
  • 模式/内模式映射
• 核心价值: 保证数据修改不影响应用程序
  • 逻辑独立性：通过外模式/模式映射实现
  • 物理独立性：通过模式/内模式映射实现
• 模式详解
  • 内模式:
    • 管理物理存储文件
    • 直接与存储设备交互
    • 位于层级最底层
  • 模式(概念模式):
    • 对应关系数据库中的基本表
    • 表现为有行有列的结构
    • 现代主流为关系模型
  • 外模式:
    • 对应数据库视图(View)
    • 通过SELECT查询生成
    • 是表的逻辑子集
    • 修改视图不影响基表
• 视图与表的区别
  • 存储性质:
    • 表：实际存储数据的实体
    • 视图：查询生成的虚拟表
  • 修改影响:
    • 修改视图不影响基表数据
    • 修改基表数据会反映到视图
  • 应用场景:
    • 表：完整数据存储
    • 视图：按需提取部分数据列
• 映射机制原理
  • 修改传播路径:
    • 内模式修改 → 调整模式/内模式映射 → 模式保持不变
    • 模式修改 → 调整外模式/模式映射 → 外模式保持不变
  • 最终效果:
    • 物理存储改变不影响应用程序
    • 逻辑结构改变不影响应用程序
    • 实现"数据变而程序不变"的目标

3）数据库设计 17:42

• 
• 六个阶段：需求分析→概念结构设计→逻辑结构设计→物理设计→数据库实施→运行维护（新增后两个阶段）
• 核心考点：
  • 步骤顺序
  • 各阶段产出物
  • 各阶段具体内容
• 步骤 18:50
  • 需求分析：分析数据存储要求，获取用户对系统的信息要求、处理要求和系统要求
  • 概念结构设计：设计ER图（实体联系图），包含实体、联系和属性
  • 逻辑结构设计：将ER图转化为关系模式（表结构）
  • 物理设计：确定数据分布、存储结构和访问方式
  • 数据库实施：建立数据库、调试程序、数据入库、试运行
  • 运行维护：系统评价、调整与修改
• 产出物 21:40
  • 需求分析：数据流图、数据字典、需求说明书
  • 概念结构设计：ER模型/概念结构模型
  • 逻辑结构设计：关系模式（80%数据库采用）、视图、完整性约束
  • 物理设计：存储结构和访问方式说明
  • 数据库实施：具体数据库实例
  • 运行维护：无特定产出物
• 内容 23:02
  • 需求分析要点
    • 三类要求：
      • 信息要求：数据内容需求
      • 处理要求：数据操作需求
      • 系统要求：系统性能需求
  • 概念结构设计要点
    • 设计过程：自底向上，先局部后整体

1. 1. 1. 1. 1. 选择局部应用
            2. 设计分ER图
            3. 合并ER图

• • • 合并冲突：
      • 属性冲突：同一属性在不同ER图中定义不同
      • 命名冲突：相同含义属性在不同ER图中命名不同（如"学号"vs"学生ID"）
      • 结构冲突：同一实体在不同ER图中属性数量不同
  • 逻辑结构设计要点
    • 转换步骤：

1. 1. 1. 1. 1. 确定数据模型（通常为关系模式）
            2. ER图→关系模式
            3. 确定完整性约束和用户视图

• • 物理设计要点
    • 核心内容：数据分布策略、存储结构（哈希/顺序等）、访问方式

4）应用案例 27:59

例题#视图基本表存储文件结构对应关系

• • 题目解析：
    • 对应关系：
      • 视图→外模式（用户视图）
      • 基本表→模式（概念模式）
      • 存储文件→内模式（物理存储）
    • 独立性实现：
      • 物理独立性：模式-内模式映像
      • 逻辑独立性：外模式-模式映像
    • 易错点：不存在外模式直接与内模式的映像
    • 答案：第一空C，第二空A

例题#逻辑结构设计阶段需求

29:14

• • 题目解析：
    • 阶段依赖：逻辑设计需要前两个阶段（需求分析+概念设计）的产出
    • 产出物判断：
      • 概念设计产出ER图（选项未出现）
      • 需求分析产出：需求说明文档、数据字典、数据流图
    • 答案：第一空A，第二空C

5）数据模型 30:36

• 数据模型分类 30:46
  • 关系模型：二维表形式表示实体-联系，由开发人员设计转换而来（如学生信息表）
  • 概念模型：用户视角建模，现实世界的第一抽象（ER图），与关系模型本质相同但表现形式不同
  • 网状模型：实体间多向联系形成网状结构（如供应链网络）
  • 面向对象模型：采用OOP方法设计，含对象/类/继承特性（现代使用较少）
• 数据模型三要素 31:58
  • 
  • 数据结构：对象类型集合（如表结构设计）
  • 数据操作：允许执行的操作集合（增删改查）
  • 约束条件：完整性规则（如年龄字段限制<150岁）
• ER模型 32:38
  • ER图的基本构成 33:16
    • 
    • 图形符号：
      • 椭圆：属性（如商品价格）
      • 长方形：实体（如超市、员工）
      • 菱形：联系（动词如"管理"）
    • 联系标注：两端需标注联系类型（1:1/1:N/M:N）
  • 实体与属性的概念 34:01
    • 实体定义：客观存在可区别的事物（具体如汽车，抽象如账户）
    • 属性示例：
      • 简单属性：年龄（单个值）
      • 复合属性：家庭住址（省+市+街道）
  • 联系与联系类型 35:43
    • 类型判断方法：
      • 1:1：双向"一"（如经理-超市）
      • 1:N：单向"多"（部门1→N员工）
      • M:N：双向"多"（业务员M→N商品）
    • 记忆技巧：通过双向语句验证（“一个A对应？个B，一个B对应？个A”）
  • 弱实体与强实体 40:41
    • 
    • 识别特征：
      • 强实体：普通长方形（如员工）
      • 弱实体：双线长方形（如经理）
    • 依赖关系：弱实体必须依附强实体存在（无员工则无经理）
  • 属性分类与域、码的概念 41:52
    • 特殊属性：
      • 派生属性：通过计算获得（如年龄=当前年-出生年）
      • 多值属性：可取多个值（如电话号码）
    • 码(Key)：唯一标识实体的属性集（如学号）
  • 两个以上实体型的联系 43:45
    • 
    • 典型场景：
      • 1:N联系：教师1→N课程（使用参考书）
      • M:N联系：项目M→N零件
    • 分析方法：拆解为两两关系判断（教师-课程、课程-参考书分别分析）
• 关系模型
  • 
  • 逻辑结构：采用二维表形式，由行（元组）和列（属性）组成，用表格结构表达实体集，外键标识实体间联系
  • 行术语：称为元组/水平记录，表示具体实体实例（如学生王小明的一条完整记录）
  • 列术语：称为属性，描述实体特征（如学号、姓名、性别等字段）
  • 优点：
    • 数学基础严格
    • 结构简单清晰易理解
    • 存取路径透明带来数据独立性和安全性
  • 缺点：因存取路径透明导致查询效率低于非关系模型
• ER模型转关系模型
  • 
  • 基本原则：
    • 每个强实体必须转换为独立的关系模式
    • 弱实体不单独转换（如经理不单独转，用员工表的岗位属性表示）
  • 联系转换规则：
    • 1:1联系：
      • 可并入任意一端实体作为属性（需保证1:1关联）
      • 也可转为单独关系模式（一般不推荐）
      • 示例：超市与经理的"管理"联系可放入超市表或经理表
    • 1:N联系：
      • 常规做法：在N端加入1端的主键
      • 原理说明：避免在1端加入N端主键导致数据冗余（如部门表重复存储员工信息）
      • 典型案例：员工(学号,姓名,部门号)中的部门号即部门表主键
    • M:N联系：
      • 强制要求：必须转为单独关系模式
      • 主键规则：采用两端实体的联合主键
      • 记忆技巧：多对多联系就像"中间商"，必须独立存在
  • 符号规范：
    • 考试中统一使用题目给定的多值表示方式（★/M/N）
    • 禁止混用表示法（如M对★）
• 应用案例 57:48
  • 例题#实体联系判断
    • 
    • 题目解析：
      • 多对多判断：
        • 学生-课程：双向"多"关系（学生选多门课，课程被多人选）
        • 教师-课程：单向"多"关系（教师教多门课，但课程仅属一位教师）
      • 弱实体识别：
        • 家长必须依附学生存在（无学生则家长数据无意义）
        • 其他实体均可独立存在
      • 答案：C（学生-课程）、A（家长-学生）
  • 例题#部门员工项目关系模式 01:00:58
    • 
    • 题目解析：
      • 联系类型判断：
        • 员工-项目：ER图中双★标记即为多对多关系
      • 关系模式主键：
        • 必须包含两端主键（员工代码+项目编号）
        • 排除含非主键属性的选项（如项目名称、承担任务）
      • 答案：D（多对多）、B（项目编号+员工代码）

二、知识小结