数据库设计
设计方法（先逻辑数据库设计后物理数据库设计）
- 需求分析
- 概念结构设计
- 逻辑结构设计
- 物理设计（在关系型数据库系统中，数据的存取是透明的，故不考虑物理设计）
- 数据库实施（sql）
- 数据库运行和维护
需求分析：
重点调查、收集和分析用户在数据管理中的信息要求、处理要求、安全性和完整性要求
需求分析的方法；
自顶向下分析方法
- 首先调查组织机构情况
- 对于每个部门，请该部门负责人和有关专业人员介绍该部门的全部职能
- 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求
- 最后对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成
各种调查方法：
- 跟班作业，亲身参加业务工作来了解业务活动的情况
- 开调查会，通过与用户座谈来了解业务活动情况及用户需求
- 询问，对调查的某些问题可以找专人询问
- 设计调查表并请用户填写，如果调查表设计得很合理，这种方法很有效，也易被用户接受
- 查阅资料，即查阅与系统有关的数据资料
需求分析表示方法：
- 数据流图 data flow diagram，DFD
- 数字字典 data dictionary，DD（数据项、数据结构、数据流、处理过程）
概念结构设计（重点）
用于概念数据库设计的高级数据模型，实体-联系模型和扩展的实体-联系模型
实体-联系模型 E-R模型
实体、属性
实体型、键属性（简单键、复合键）、属性的值域
实体间的联系（实体对应的约束：1:1、1:N、M:N）:
特别：一门课程由多个教师讲授，一个教师可以讲授多门课程，因为教师与课程之间具有M:N关系（1:N和N:1的结合）
实体-联系图 E-R图
概念结构设计的方法
自顶向下、自底向上、混合策略
- 数据抽象
- 局部视图设计
- 局部视图集成
- 属性冲突解决
- 修改、重构消除冗余（①依据数据字典和数据流图；方法②依据规范化理论）
逻辑结构设计
全局逻辑结构（将概念模型转换为全局逻辑结构）
设计用户子模式（面向各个最终用户或用户集团的局部逻辑结构，提现各个用户对数据库的不同视角，一般采用视图功能 view）
关系数据库的逻辑设计
-
导出初始关系模式（从E-R图向关系模式的转换）
-
使关系模式规范化（数据依赖理论：每个关系模式内部属性之间的数据依赖关系）
-
反复评价和修正模式（从功能和性能两个方面评价数据库模式）
设计用户子模式（设计视图）
存储模式设计（索引定义、聚集定义、数据段定义）
系统编码设计
对对象都应强制执行编码规则，如只准使用编码列表中的值
应用软件设计
- 设计功能模块结构
- 对处于不同数据流程图但功能相同的模块进行合并
- 补充数据字典（在数据字典中增加一下信息的描述）
菜单设计
设计主菜单及下拉菜单结构
设计用户界面
设计交互界面的布局和风格
生成交叉指引表
-
对每个关系模式，列出引用它的功能模块名清单
-
对每个功能模块，列出它引用的关系模式名清单，它调用的功能模块名清单，调用它的功能模块名清单
E-R图向关系模式的转换（重点）
实质是将实体、实体的属性、实体之间的联系转换为关系模式
这种转换遵循如下原则：
- 一个实体转换为一个关系模式（实体的属性对应于一个关系模式的属性）
- 若实体间的联系是1:1，可以转换为一个独立的关系模式，与该联系相连的各实体的键以及联系本身的属性均转换为关系的属性，每个实体的键均是该关系的候选键 ②若与任意一端对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的键和联系本身的属性
- 若实体间的联系是1:N，则可以与N端对应的关系模式合并，并在N端实体型转换的关系模式中加入1端实体型转换成的关系模式的键和联系的属性。②若转换为一个独立的关系模式，则与该联系相连的各实体转换成的关系模式的键以及联系本身的属性均转换为关系的属性
- **若为M:N，则将该联系转换为一个独立的关系模式，**其属性位两端实体类型的键加上联系类型的属性，而关系的键为两端实体转换成的关系模式键的组合
数据库设计中关系规范化的实际应用
物理设计
为给定的基本数据模型选取一个最适合应用环境的物理结果的过程，选取适合的存储结构和存取方法
- 影响物理设计的因素
- 为关系模式选择存取方法（索引方法、HASH方法、聚集方法）
- 关系、索引等物理存储结构设计
数据库实施
- 建立实际数据库结构
- 装入试验数据，对应用程序调试
- 装入实际数据，进入试运行状态
数据库运行和维护
- 维护数据库的安全性与完整性
- 检测并改善数据库的性能
- 根据用户要求对数据库现有的功能进行调整和扩充
- 及时发现并改正运行中出现的系统错误和暴露出的不足
实例1
