11.1.1 数据库应用系统的生命期
数据库应用系统的生命周期分为数据库规划、需求描述与分析、数据库与应用程序设计、数据库设计实现、测试、运行维护6个阶段。
1、数据库规划
数据库规划的任务是确定软件的开发目标及可行性。该阶段应该给出问题定义、可行性分析和项目开发计划。
2、需求描述与分析
需求描述与分析是以用户的角度，从系统中的数据和业务规则入手，收集和整理用户的信息，以特定的方式加以描述，是下一步工作的基础。
3、数据库与应用程序设计
数据库的设计是对用户数据的组织和存储设计；应用程序设计是在数据库设计基础上对数据操作及业务实现的设计，包括事务设计和用户界面设计。
4、数据库设计实现
数据库设计实现是依照设计，使用DBMS支持的数据定义语言实现数据库的建立，用高级语言编写应用程序
5、测试
测试是在数据库系统投入使用之前，通过精心制订的测试计划和测试数据来测试系统的性能是否满足设计要求，以便发现问题。
6、运行维护
数据库应用系统经过测试、试运行后即可正式投入运行。运行维护是系统投入使用后，必须不断地对其进行评价、调整和修改，直至系统消亡。
11.1.2 数据库设计的一般策略
数据库设计的一般策略有两种：自顶向下和自底向上。
11.1.3 数据库设计的基本步骤
一般将数据库设计分为如下6个阶段：（1）用户需求分析。（2）概念结构设计。（3）逻辑结构设计。（4）物理结构设计。（5）数据库实施阶段。（6）数据库运行和维护阶段。
11.2.1 需求分析的任务、方法和目标
需求分析阶段的任务：综合各个用户的应用需求，对现实世界要处理的对象（组织、部门和企业等）进行详细调查，在了解现行系统的概况，确定新系统功能的过程中，收集支持系统目标的基础
数据及处理方法。
（1）信息要求。用户需要在系统中保存哪些信息，由这些保存的信息要得到什么样的信息，这些信息以及信息间应当满足的完整性要求。
（2）处理要求。用户在系统中要实现什么样的操作功能，对保存信息的处理过程和方式，各种操作处理的频度、响应时间要求、处理方式等以及处理过程中的安全性要求和完整性要求。
（3）系统要求。包括安全性要求、使用方式要求和可扩充性要求。安全性要求：系统有几种用户使用，每一种用户的使用权限如何。使用方式要求：用户的使用环境是什么，平均有多少用户同时使用，最高峰有多少用户同时使用，有无查询相应的时间要求等。可扩充性要求：对未来功能、性能和应用访问的可扩充性的要求。
11.2.2 需求分析阶段的文档
需求分析阶段的成果是系统需求说明书，主要包括数据流图、数据字典、各种说明性表格、统
计输出表和系统功能结构图等。
数据字典（Data Dictionary,DD)是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。如用户将向数据库中输入什么信息，从数据库中要得到什么信息，各类信息的内容和结构，信息之间的联系等。
数据字典包括数据项、数据结构、数据流、数据存储和处理过程5个部分。
数据字典是数据流图的补充，以下是五个部分的总结：
数据项名称： 订单编号
别名： 订单号、OrderID
类型： 字符型
长度： 12位
取值范围： ORD20240100001 ~ ORD99999999999
含义说明： 格式：ORD+年份+月+5位序列号
示例：ORD20240100001表示2024年1月第1号订单
与其他项关系： 唯一标识一个订单，主键特征
原子性：不能再分解为更小的数据单位
独立性：具有独立的业务含义
基础性：构成数据结构的基本元素
数据结构：由多个数据项组成的数据单位，描述数据之间的关系。
数据结构名称： 客户信息
别名： 客户资料、CustomerInfo
组成： 客户编号
客户姓名
客户类型
联系电话
电子邮箱
注册日期
信用等级
数据结构类型： 客户基本信息
备注： 用于存储客户的核心信息
特征
组合性：由数据项或其他数据结构组成
层次性：可以嵌套定义
完整性：表达一个完整的业务对象
数据流：数据在系统内的流动，包括来源、去向、组成和流量等。
数据流名称： 支付请求
编号： DF-003
来源： 支付处理过程(P2)
去向： 银行支付网关
数据流组成： 订单编号
支付金额
支付方式代码
时间戳
商户ID
客户支付令牌（加密）
流量： 平均200次/小时，高峰1000次/小时
峰值流量： 双十一期间可达5000次/小时
备注： 采用RSA加密传输，JSON格式特征
方向性：有明确的源和目的地
瞬时性：在某个时间点传递
内容性：包含具体的数据内容
数据存储：系统中保存数据的地方，是数据结构的载体。
数据存储名称： 订单表
编号： DS-001
别名： 订单主表、Orders
输入数据流： 新增订单、修改订单状态
输出数据流： 订单查询结果、订单统计信息
组成： 订单编号 [PK]
客户编号 [FK]
下单时间
订单状态
总金额
收货地址ID
物流单号
支付状态
数据量： 约100万条记录
增长量： 每月约5万条
存取频率： 查询：1000次/分钟，更新：200次/分钟
存储方式： 数据库表（MySQL InnoDB）
索引： 主键：订单编号
索引：客户编号、下单时间、订单状态
分区策略： 按月份水平分区特征
持久性：数据长期保存
结构性：有明确的组织结构
访问性：通过特定接口访问
处理过程：对数据进行加工处理的具体操作，描述输入、处理和输出。
处理过程名称： 处理订单支付
编号： P2.1
输入： 支付信息（订单编号、金额、支付方式）
输出： 支付结果（成功/失败、交易号）
处理逻辑：
1. 验证订单状态是否为"待支付"
2. 检查支付金额与订单金额是否一致
3. 根据支付方式调用相应支付接口
- 支付宝：调用支付宝SDK
- 微信支付：调用微信支付API
- 银行卡：调用银联接口
4. 接收支付网关返回结果
5. 更新订单支付状态
IF 支付成功 THEN
更新订单状态为"已支付"
记录交易流水号
发送支付成功通知
ELSE
更新订单状态为"支付失败"
记录失败原因
通知客户重新支付
6. 返回处理结果
激发条件： 用户提交支付请求
执行频率： 平均500次/小时
性能要求： 响应时间<2秒，成功率>99.9%
异常处理： 网络超时重试3次，支付失败记录日志并告警
特征
功能性：完成特定的数据处理功能
转换性：将输入数据转换为输出数据
封装性 | 隐藏内部处理细节
数据字典各部分的关联关系
数据项
↓
数据结构 ←→ 数据存储
↓ ↓
数据流 → 处理过程
(流动的数据) (加工数据)关联示例：订单处理
数据项：订单编号、商品编号、数量、单价
数据结构：订单明细 = 商品编号 + 数量 + 单价
数据存储：订单表（存储订单数据结构）
数据流：新增订单（从界面流向订单处理过程）
处理过程：创建订单（接收数据流，操作数据存储）
数据流图是数据库设计的逻辑蓝图，它帮助设计者在编码和建表之前，清晰地理解数据从哪里来、经过什么处理、存储在哪里、最后到哪里去。为了从宏观到细节地描述系统，采用自顶向下的分层绘制方法：
上下文图：
层级：0层图。
内容：只有一个代表整个系统的“过程”，以及所有与之交互的“外部实体”和主要数据流。
目的：界定系统边界。
顶层图：
层级：1层图。
内容：将上下文图中的单一“过程”分解为几个主要的子“过程”（通常3-9个），并显示它们与外部实体、数据存储之间的数据流。
目的：展示系统的主要功能模块。
逐层分解：
层级：2层、3层图等。
内容：对顶层图中的某个复杂“过程”进一步分解，形成更详细的DFD。
原则：保持平衡，即子图的输入/输出数据流必须与父图中该过程的输入/输出一致
上下文图
┌─────────────────┐
│ 银行支付 │
│ 网关 │
└────────┬────────┘
│支付验证结果
│
┌─────────────┐ │ ┌─────────────┐
│ │ │ │ │
│ 顾客 │──────┼──────│ 物流公司 │
│ │ │ │ │
└─────────────┘ │ └─────────────┘
│ │ │
│提交订单 │发货状态更新 │配送信息
│订单查询 │ │
│ │ │
└─────────────┼─────────────┘
│
┌──────────▼──────────┐
│ │
│ 在线书店系统 │
│ │
└─────────────────────┘顶层图
┌─────────────┐ ┌─────────────┐
│ │ 提交订单 │ │
│ 顾客 ├────────────────► 处理订单 │
│ │ │ (P1) │
└─────────────┘ └──────┬──────┘
▲ │
│ 订单确认 │订单详情
│ │
│ ┌─────────▼──────────┐
│ │ │
│ │ 订单数据库 │
│ │ (D1) │
│ │ │
│ └─────────┬──────────┘
│ │
│ │订单信息
│ │
┌───────┴───────┐ ┌─────▼─────┐
│ │ 支付请求 │ │
│ 银行支付 │◄───────────────┤ 处理支付 │
│ 网关 │ │ (P2) │
│ ├───────────────►│ │
└───────────────┘ 支付结果 └─────┬─────┘
│
│支付状态
│
┌───────▼───────┐
│ │
│ 更新库存状态 │
│ (P3) │
└───────┬───────┘
│
│库存调整
│
┌──────────────▼──────────────┐
│ │
│ 库存数据库 │
│ (D2) │
│ │
└──────────────┬──────────────┘
│
│发货信息
│
┌─────────▼─────────┐
│ │
│ 处理发货 │
│ (P4) │
└─────────┬─────────┘
│
│发货指令
│
┌─────────▼─────────┐
│ │
│ 物流公司 │
│ │
└───────────────────┘
│
│配送状态
│
┌─────────▼─────────┐
│ │
│ 更新订单状态 │
│ (P5) │
└─────────┬─────────┘
│
│状态信息
│
┌─────────▼─────────┐
│ │
│ 订单数据库 │
│ (D1) │
└───────────────────┘概念结构设计是在需求分析的基础上，依照需求分析中的信息要求，对用户信息加以分类、聚集和概括，建立信息模型。
• 概念结构设计最著名最常用的方法是实体-联系方法，简称E-R方法。它将现实世界的信息结构统一用实体、属性以及实体之间的联系来描述。
• 概念结构设计工作步骤包括：选择局部应用、逐一设计分E-R图和E-R图合并。
1、选择局部应用
选择适当层次的数据流图，让这一层的每一部分对应一个局部应用，实现某一项功能，从这一层入手，就能很好地设计分E-R图。
2、逐一设计分E-R图
划分好各个局部应用之后，就要对每一个局部应用逐一设计分E-R图，又称为局部E-R图。
现实生活中许多事物，作为实体还是属性没有明确的界定，这需要根据具体情况而定，一般遵
循以下两条准则：
（1）属性不可再分，即属性不再具有需要描述的性质，不能有属性的属性。
（2）属性不能与其他实体发生联系，联系是实体与实体间的联系。
3、E-R图合并
根据局部应用设计好各局部E-R图之后，就可以对各分E-R图进行合并。合并的目的在于解决冲突，消除冗余。
分E-R图合并时，它们之间存在的冲突主要有以下三类：
（1）属性冲突：同一属性可能会存在于不同的分E-R图中，由于设计人员不同或是出发点不同，对属性的类型、取值范围、数据单位等可能会不一致。
（2）命名冲突：相同意义的属性，在不同的分E-R图上有着不同的命名，或是名称相同的属性在不同的分E-R图中代表着不同的意义，这些也需要进行统一。
（3）结构冲突：同一实体在不同的分E-R图中有不同的属性，同一对象在某一分E-R图中被抽象为实体而在另一分E-R图中又被抽象为属性。
分E-R图合并时，可能遇到以下冲突，处理原则如下：
1. 属性冲突
现象：同一属性在不同局部E-R图中的数据类型或取值范围不一致。
处理原则：协商统一该属性的数据类型和取值范围。
目的：确保数据定义的一致性。
2. 命名冲突
现象：不同含义的对象使用了相同名称，或相同含义的对象使用了不同名称。
处理原则：对同名异义对象改名区分，对异名同义对象统一命名。
目的：确保全局模型中的命名唯一且明确。
3. 结构冲突（对象抽象级别不同）
现象：同一对象在一个分E-R图中作为实体，在另一个分E-R图中作为属性。
处理原则：根据整体业务需求，将该对象统一作为实体或属性。
目的：确保对象抽象级别的一致性。
4. 结构冲突（联系类型不同）
现象：相同的两个实体之间的联系方式在不同分E-R图中类型不一致（如一个图中是1:1，另一个是1:N）。
处理原则：分析实际业务语义，确定正确的联系类型。
目的：确保联系类型的正确性。
5. 结构冲突（属性组成不同）
现象：同一实体在不同业务视图中属性不一致。
处理原则：取各分E-R图中该实体属性的并集。
目的：确保全局模型涵盖所有业务需求。逻辑结构设计就是在概念结构设计的基础上进行数据模型设计，可以是层次模型、
网状模型和关系模型。
• 逻辑结构设计阶段的主要工作步骤包括确定数据模型、将E-R图转换成指定的数据
模型、确定完整性约束和确定用户视图。
概念结构设计和应用程序模块设计都是系统设计的组成部分，它们相互影响、互为前提，都基于同一个需求分析，但不存在简单的单向依赖关系。
11.4.1 E-R图向关系模式的转换
1、实体向关系模式的转换
2、联系向关系模式的转换
重要，最后讲。
11.4.2 关系模式的规范化
由E-R图转换得来的初始关系模式并不能完全符合要求，还会有数据冗余、更新异常存在，这就需要经过进
一步的规范化处理。
（1）根据语义确定各关系模式的数据依赖。
（2）根据数据依赖确定关系模式的范式，判断关系模式是否达到了3NF或4NF。
（3）如果关系模式不符合要求，要进行分解，达到3NF、BCNF或4NF。
（4）关系模式的评价及修正。有时根据处理要求，可能还需要增加部分冗余以满足处理要求，这就需要做部分关系模式的处理，分解、合并或增加冗余属性，提高存储效率和处理效率。
11.4.3 确定完整性约束
11.4.4 用户视图的确定
（1）根据数据流图确定处理过程使用的视图。
（2）根据用户类别确定不同用户使用的视图。
数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系
统。为一个给定的逻辑数据模型设计一个最适合应用要求的物理结构的过程，就是数据库的物理设计。
11.5.1 数据库物理设计工作过程
11.5.2 数据库物理设计工作步骤
物理设计的主要工作步骤包括：确定数据分布、存储结构和访问方式。
1、确定数据分布
（1）根据不同应用分布数据。
（2）根据处理要求确定数据的分布。
（3）对数据的分布存储必然会导致数据的逻辑结构的变化，要对关系模式做新的调整，回到数据库逻辑设计阶段做必要的修改。
2、确定数据的存储结构
存储结构具体指数据文件中记录之间的物理结构。
为提高数据的访问速度，通常会采用索引技术。在物理设计阶段，要根据数据处理和修改要求，确定数据库文件的索引字段和索引类型。
3、确定数据的访问方式
（1）存储记录结构设计。
（2）存储记录布局。
（3）存取方法的设计。
1、数据库重组和重构
数据库重组是指在不改变数据库逻辑和物理结构的情况下，去除数据库存储文件中的废弃空间
以及碎片空间中的指针链，使数据库记录在物理上紧连。
数据库系统运行过程中，会因为一些原因而对数据库的结构做修改，称为数据库重构。重构包
括表结构的修改和视图的修改。
2、数据库系统的审计
审计是一种DBMS工具，它记录数据库资源和权限的使用情况。启用审计功能，可以产生审计跟
踪信息，包括哪些数据库对象受到了影响，谁在什么时候执行了这些操作。
审计是被动的，它只能跟踪对数据库的修改而不能防止，但作为一个安全性手段，起到对非法
入侵的威慑作用，可以据此追究非法入侵者的法律责任。
审计功能的开启会影响系统的性能。
3、数据库的存储管理
在数据库系统运行过程中，随着数据的不断变更，会影响到系统的响应效率。通过以下手段进行存储管理，
可有效地提高系统性能。
（1）索引文件和数据文件分开存储，事务日志文件存储在高速设备上。
（2）适时修改数据文件和索引文件的页面大小。
（3）定期对数据进行排序。
（4）增加必要的索引项。
4、数据安全性管理
（1）建立网络安全，主要是防火墙的设置。
（2）操作系统级安全，进行登录用户的管理。
（3）DBMS级安全，对访问数据库的用户进行密码验证。
（4）角色和用户的授权管理。
（5）建立视图和存储过程加强安全性。
（6）使用审计功能，为追究非法入侵者法律责任提供证据，发现安全漏洞。
5、SQL语句的编码检验
（1）尽可能地减少多表查询或建立物化视图。
（2）以不相关子查询替代相关子查询。
（3）只检索需要的列。
（4）用带IN的条件子句等价替换OR子句。
（5）经常提交COMMIT，以尽早释放锁。
6、表设计的评价
（1）如果频繁的访问是对两个相关的表进行连接操作，则考虑将其合并。
（2）如果频繁的访问只是在表中的某一部分字段上进行，则考虑分解表，将该部分单独作为一个表。
（3）对于更新很少的表，引入物化视图。
7、索引维护和改进
（1）如果查询是瓶颈，则在关系上建立适应的索引，通常在作为查询条件的属性上建立索引，可以提高查询效
率。
（2）如果更新是瓶颈，每次更新都会重建表上的索引，引起效率的降低，则考虑删除某些索引。
（3）选择适当的索引类型，如果是经常使用范围查询，则B树索引比散列索引更高效。
（4）将有利于大多数据查询和更新的索引设为聚簇索引。
ER图关系模式转换
1、实体向关系模式的转换：
ER图中的每一个实体单独转换成一个关系模式，实体名对应关系模式的名称，实体的属性转换为关系模式的属性，实体标识符就是关系的码。
班主任（工号，姓名，身份证号，住址）
班级（班级编号，名称，人数）
2、一对一联系的转换(1：1)：
通常一对一联系不需要将其转换为一个独立的关系模式，只需要将联系归并到关联的两个实体的任意一方，给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可，归并后的实体码保持不变。
班主任（工号，姓名，身份证号，住址，班级编号，任职时间）或： 班级（班级编号，名称，人数，班主任工号，任职时间）
3、一对多联系的转换(1：*)：
通常一对多联系也不需要将其转换为一个独立的关系模式，只需要将联系归并到关联的两个实体的多方，给待归并的多方实体属性集中增加一方实体的码和该联系的属性即可，归并后的多方实体码保持不变。
员工（工号，姓名，身份证号，公司编号，入职时间，离职时间）
4、多对多联系的转换(：)：
多对多联系只能转换成一个独立的关系模式，关系模式的名称取联系的名称，关系模式的属性
取该联系所关联的两个多方实体的码及联系的属性，关系的码是多方实体的码构成的属性组。
选修（学号，课程编号，成绩，出勤率）
5、多对多对多联系的转换(：：*)：
三方联系的多对多对多（：：*）也是一样，只能转换成一个独立的关系模式，关系模式的属
性取三方实体的码及联系的属性，关系模式的码为三方实体的码组成的属性组。如：一个供应商可
以给多个项目供应多种零件，一个项目可以使用多个供应商供应的多种零件。
供应（供应商编号，项目编号，零件编号，供应数量）
联系类型是“关系种类”，关系模式是“表格结构”
联系类型（ER模型层面）
所在位置：ER图中
表现形式：菱形 + 连线
关注点：
这是什么关系？（师生、订购、拥有）
谁和谁有关系？（学生和课程）
是一对一、一对多还是多对多？
有什么属性吗？（成绩是“选课”关系的属性）
例子：
学生和课程之间的“选课”联系
医生和病人之间的“诊疗”联系
关系模式（数据库层面）
所在位置：数据库中
表现形式：SQL建表语句
关注点：
表叫什么名字？
有哪些列（字段）？
每个列的数据类型是什么？
主键、外键是什么？
扩展E-R图（Enhanced ER或EER）包括一些高级概念，如子类/继承、聚合等。
联系可以看作实体，与另一实体产生联系，称为聚合"。聚合是一种抽象，其中一个联系被当作一个高层实体来对待，以便它可以参与其他联系。
联系的属性是指联系本身的属性。联系的属性不能是关联实体的标识符属性，因为标识符属性是实体的属性。
关于三元联系与多个二元联系的区别。在E-R模型中，三个实体之间的单个三元联系（ternary relationship）并不等价于它们之间的三个两两联系（三个二元联系）。三元联系表示三个实体同时参与一个联系，而两两联系不能表达同样的约束。例如，假设有实体：医生、病人、药物，一个三元联系"治疗"表示哪个医生给哪个病人开了哪种药。如果分解为三个二元联系：医生-病人、病人-药物、医生-药物，那么可能丢失信息，比如无法确保特定的医生-病人-药物组合。所以它们不等价。
在 E-R 模型（实体-关系模型） 中，不同类别的 属性（Attribute） 有不同的表示方法，以区分其性质和功能。
单值属性（Simple Attribute）
定义：不可再分的独立属性（如：姓名、年龄）。
E-R 图表示：椭圆（○）
多值属性（Multivalued Attribute）
定义：一个属性可以存储多个值（如：一个人有多个电话号码）。
E-R 图表示：双椭圆（◎）
复合属性（Composite Attribute）
定义：由多个子属性组成（如：地址 = 省 + 市 + 区）。
E-R 图表示：椭圆 + 连线子属性
派生属性（Derived Attribute）
定义：可通过其他属性计算得到（如：年龄 ← 出生日期）。
E-R 图表示：虚线椭圆（┆○┆）
主键（Primary Key）
定义：唯一标识实体的属性（如：学号、身份证号）。
E-R 图表示：
下划线（如 学号）或在属性后标注 (PK)
外键（FK） Foreign Key
表示：虚线下划线或标注 (FK)
评论