请使用支持现代 CSS 与 JavaScript 的浏览器播放课件
DBPA · 7.1

数据库设计总览与需求分析

从业务问题建立可追溯的设计输入

VER. 2608.2 Built with impress.js
DBPA | CH07 | 7.1

学习目标

数据库设计从业务目标、数据、处理和运行约束出发，逐步形成可验证的设计输入

  1. 01区分数据库设计的广义、狭义含义及三类设计目标
  2. 02说明六个设计阶段的输入、任务、产出和 DBMS 边界
  3. 03解释基础数据、管理规则和应用处理如何共同影响设计
  4. 04设计需求调查路径，使用六种方法收集证据，并用结构化分析整理
  5. 05填写五类数据字典条目并追踪到概念、逻辑和物理设计
  6. 06让用户确认需求规格说明书和数据字典，记录边界、版本和未决项
2/16
LEARNING OBJECTIVES
DBPA | CH07 | 7.1 | 7.1

导入 Excel 不等于完成数据库设计

设计要同时回答数据对象和业务处理

设计视角要回答的问题典型结果
信息管理应存储和管理哪些数据对象学生、课程、选课
数据操作需要查询、增加、删除、修改什么开课、选课、成绩登记
运行目标如何平衡存取效率、空间利用率和运行维护效率存储结构、存取方法和维护方案
Takeaway

表只是载体；业务语义、处理责任和运行目标仍需要设计

3/16
DESIGN SCOPE
DBPA | CH07 | 7.1 | 7.1

数据库设计同时处理技术结构和业务责任

基础数据、业务规则和事务活动共同决定模式能否长期使用

基础数据

设计以选课、成绩等业务事实为基础，并持续收集、整理、组织和更新这些数据

业务管理

教务规则和组织职责会塑造数据对象及其联系

结构与行为

选课、退课、成绩登记等事务会影响模式和物理结构

Takeaway

数据库设计必须与应用、业务流程和运行维护同步推进

4/16
DESIGN PRINCIPLES
DBPA | CH07 | 7.1 | 7.1

六个阶段让设计逐步收敛

每一阶段都留下可以复核的设计产出，后续证据也可能促使前面回退

需求、概念、逻辑、物理、实施与维护六阶段设计漏斗
阶段主要输入与任务主要产出
需求分析业务目标、现有记录；调查并确认需求需求规格、数据字典
概念结构需求规格、数据字典；抽取对象和联系E-R 图、概念模型
逻辑结构概念模型、依赖和约束；转换并规范化逻辑模式、外模式
物理结构逻辑模式、负载约束；选择存储和存取方法存储结构、索引、配置
实施模式、程序和数据；构建、装载和测试可运行系统、试运行结果
运行维护运行反馈、故障和变化；评价、调整和备份监控、重组或重构方案
Takeaway

需求与概念设计相对独立于 DBMS；逻辑与物理设计受目标 DBMS 影响，事务和应用设计与各阶段同步推进

5/16
SIX PHASES
DBPA | CH07 | 7.1 | 7.1

数据库设计需要共同承担责任

不同角色在不同阶段提供业务、结构、处理和运行证据

角色主要责任重点参与
系统分析员组织业务调查、梳理需求和边界需求分析
数据库设计员设计并维护概念、逻辑和物理结构结构设计全过程
应用开发人员把处理要求落实为事务和应用程序实施与试运行
数据库管理员管理运行环境、权限、备份和监控，并提出运行约束需求、物理设计与运行维护
用户代表持续提供业务语义、确认范围并反馈运行结果需求分析、验收与运行反馈
Takeaway

各角色在自己负责的阶段提供证据；系统分析员与数据库设计员贯穿全过程，并与其他角色协作

6/16
DESIGN ROLES
DBPA | CH07 | 7.1 | 7.2

需求分析的对象是数据和处理

需求分析把业务语言整理为信息、处理、安全性和完整性要求

需求类别高校选课示例它回答什么
信息学生、教学班、选课记录、成绩要保存和查询什么
处理选课、退课、成绩登记、统计要完成什么操作及其响应
安全性学生只能查看自己的成绩谁可以查看、修改或导出什么
完整性成绩必须对应合法选课记录哪些取值、联系和状态必须成立
Takeaway

需求还要说明未来扩充的可能性，以及新系统负责和不负责的边界

7/16
REQUIREMENTS
DBPA | CH07 | 7.1 | 7.2

需求调查要从组织和业务活动开始

需求调查先核对真实流程，再与用户确认系统边界和职责

  1. 01组织：调查部门职责、原有系统和记录，整理组织结构与信息流向
  2. 02业务：跟踪输入、加工、输出、频率和高峰期，记录实际业务流程
  3. 03共识：与用户确认信息、处理、安全性和完整性要求，整理待确认清单
  4. 04边界：区分系统、人工和外部系统负责的活动，记录职责边界
8/16
USER SURVEY
DBPA | CH07 | 7.1 | 7.2

不同调查方法回答不同的证据问题

复杂业务通常需要组合使用多种调查方法

观察流程

通过跟班作业和查阅记录了解实际流程

澄清规则

通过调查会、专人介绍和询问澄清业务规则

收集反馈

通过问卷调查收集较大范围的反馈

Takeaway

六种调查方法按证据问题分组；调查完成后还要由用户确认需求规格

9/16
SURVEY METHODS
DBPA | CH07 | 7.1 | 7.2

结构化分析逐层组织调查证据

结构化分析自顶向下逐层分解，把组织问题落到可记录的数据和处理过程

  1. 01从组织目标和系统边界确定分析范围
  2. 02将部门职责分解为业务活动
  3. 03把活动拆为输入、加工、输出、频率与责任
  4. 04把结果交给数据字典与需求规格说明书
Takeaway

结构化分析整理调查证据，但不替代用户判断；组织层级和业务活动的实际分解会随系统变化

10/16
STRUCTURED ANALYSIS
DBPA | CH07 | 7.1 | 7.2

数据字典记录的是数据的含义和边界

它是需求分析的元数据成果，不是业务记录本身

条目描述重点后续用途
数据项不可再分；含义、别名、类型/长度、取值范围/含义、逻辑关系属性、域和完整性约束
数据结构数据项或子结构的业务组合，不是数组或链表概念对象、联系和消息输入
数据流数据结构的来源、去向、组成、平均与高峰流量处理边界与事务频率
数据存储手工文档或计算机存储；流入流出、数据量、频度和方式逻辑对象与物理存储估算
处理过程输入、输出、功能、频度和响应要求；描述做什么而非如何实现事务、响应性能与物理设计输入
Takeaway

数据项之间的逻辑关系是后续函数依赖、完整性约束和逻辑模式优化的语义来源

11/16
DATA DICTIONARY
DBPA | CH07 | 7.1 | 7.2

从“选课申请”提取五类数据字典条目

把同一业务事实拆开记录，为后续设计保留可追溯的来源

条目示例内容设计提示
数据项学号、教学班号、申请时间、状态；值域和有效性规则属性、域和完整性约束
数据结构申请 = 学号＋教学班号＋申请时间＋状态学生—教学班联系及其属性
数据流学生端 → 选课处理 → 记录与结果来源、去向和系统边界
数据存储选课记录；数据量、频度和方式待调查逻辑对象与物理存储估算
处理过程资格、容量、冲突校验；成功或拒绝输出事务、响应和异常分支
Takeaway

五类条目分别为概念对象与联系、逻辑键和约束、物理负载评估提供证据

12/16
DICTIONARY EXAMPLE
DBPA | CH07 | 7.1 | 7.2

用户需要确认需求规格说明书

用户确认的是语义、范围和优先级，而不是替设计员决定表名

  1. 01对照业务流程和数据字典，检查每项需求是否能追溯到调查证据
  2. 02标出本系统负责、暂不负责和未来可能扩充的功能
  3. 03由用户代表复核需求规格说明书及数据字典中的语义、范围、优先级和约束
  4. 04记录确认版本、未决事项、变更原因和下一次确认时间
Takeaway

经用户确认的当前版本，才成为设计团队共同使用的依据；未决事项和后续变更仍需记录

13/16
REQUIREMENTS CONFIRMATION
DBPA | CH07 | 7.1

用需求、字典和阶段追踪设计输入

数据库设计从业务目标出发，在运行反馈中持续修正

范围与阶段

区分广义与狭义设计，说明六个阶段和协作角色

调查与需求

使用六种方法和结构化分析整理四类需求

字典与确认

用五类条目记录语义，由用户确认并追踪到后续设计

Takeaway

确认后的需求和数据字典为实体、属性、联系和约束设计提供输入

14/16
RECAP
DBPA | CH07 | 7.1

本节知识地图

15/16
KNOWLEDGE MAP
DBPA | CH07 | 7.1

本节问题

  1. 01“把 Excel 导入数据库”属于哪种设计范围，还缺少哪些设计工作？
  2. 02为六个阶段各补一项输入和产出，并指出为什么可能回退？
  3. 03将“选课申请”中的陈述分别归入信息、处理、安全性和完整性要求？
  4. 04为一项业务问题选择调查方法，并描述结构化分析的逐层分解链？
  5. 05为“选课申请”补写五类数据字典条目，并说明各自的后续设计去向？
  6. 06将这条路径迁移到手机游戏赛季或电子商务退款，指出需要更换哪些调查证据？
16/16
CHECK YOUR UNDERSTANDING