设计

1. 手工试凑法

2. 规范设计法(结构化方法)
1. 新奥尔良方法
2. 基于E-R模型的数据库设计方法
3. 3NF的设计方法
4. 面向对象的数据库设计方法
5. 统一建模语言(UML)方法

1. 需求分析: 综合各个用户的应用需求

2. 概念结构设计: 形成独立于机器特点，独立于各个数据库管理系统产品的概念模式（E-R图）

3. 逻辑结构设计: 首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式, 然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图（View），形成数据的外模式

4. 物理结构设计: 根据数据库管理系统特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

5. 数据库实施

6. 数据库运行和维护

需求分析

概念结构设计

设计方法

• 自顶向下, 首先定义全局概念结构框架, 再逐步细化.

• 逐步扩张, 首先定义核心概念结构, 然后向外滚雪球扩充.

• 混合策略: 自顶向下设计全局概念结构框架, 自底向上设计各局部概念结构

1. 能作为属性的尽量作为属性对待

2. 作为属性必须不可分, 不能再具有需要描述的性质, 不能包含其他属性

3. 属性不能和其他实体具有联系, 只能属于某一实体或联系

E-R图

• 矩形 → 实体型

• 菱形 → 联系

• 椭圆形 → 实体型或联系的属性

• 三角形 → 表示”is a”联系, 表示子类继承父类的所有属性

联系

继承

基数约束

Part-of联系

E-R图的集成

1. 合并: 解决分E-R图之间的冲突, 将分E-R图合并起来生成初步E-R图;
• 冲突:
• 属性冲突: 属性值的类型, 取值范围, 取值集合或取值单位不同
• 命名冲突: 同名异义, 异名同义, 可能发生在实体、联系一级也可能发生在属性一级
• 结构冲突: 同一对象在不同应用中具有不同的抽象(一个图中是实体, 另一个图中是属性, 需要统一)/同一实体在不同子系统中包含的属性个数和排列次序不同(取并集, 调整次序)/在不同E-R图中具有不同类型的联系(综合调整)

2. 修改和重构: 消除初步E-R图中不必要的冗余, 生成基本E-R图;
• 冗余的数据(可由基本数据导出的数据), 冗余的联系(可由其他联系导出的联系)
• 主要采用分析方法, 以数据字典和数据流图为依据, 根据数据字典中关于数据项之间逻辑关系的说明消除冗余
• 规范化理论消除冗余
💡
1. 确定E-R图实体之间的数据依赖
在E-R图中，实体之间的联系（Relationship）实际上体现了数据依赖。第一步是识别并列出所有实体之间的函数依赖.
将E-R图中所有实体属性之间的确定性关系都以函数依赖的形式表示出来，构成一个函数依赖集合FL。这个FL是后续步骤的基础。
2. 求FL的最小覆盖GL，差集为 D = FL - GL
这一步是规范化理论的核心应用。
• 最小覆盖（Minimal Cover） 是指一个函数依赖集合，它具有以下三个性质：
1. 右侧都是单个属性（如果不是，可以通过分解得到）。
2. 没有冗余的函数依赖（即移除任何一个FD都会改变闭包）。
3. 没有冗余的左侧属性（即在任何一个FD中，左侧的属性都不能被移除而不改变闭包）。
• 求FL的最小覆盖GL 的过程通常涉及以下步骤：
1. 分解右侧非单属性的FD：如果一个FD的右侧包含多个属性，将其分解为多个右侧为单属性的FD。例如，A -> BC 可以分解为 A -> B 和 A -> C。
2. 移除冗余的FD：对于FL中的每个FD，尝试移除它，然后检查剩余FD的闭包是否仍然能推导出被移除的FD。如果能，则该FD是冗余的，可以移除。
3. 移除左侧冗余属性：对于FL中的每个FD X -> A，检查X中的每个属性x，如果X - {x} -> A 仍然成立，则x是冗余的，可以从X中移除。
• 通过以上步骤，我们得到一个精简的函数依赖集合 GL，它与原始的FL具有相同的推导能力，但去除了内部的冗余。
• 差集 D = FL - GL：这个差集D包含了在FL中存在，但在GL中被移除的函数依赖。这些被移除的FD就是潜在的冗余联系。它们之所以被移除，是因为它们可以从GL中的其他函数依赖推导出来，因此在数据库设计中是多余的。
• 冗余的联系一定在D中, 但是D中的联系不一定是冗余的.
3. 逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉。
现在我们有了潜在的冗余函数依赖集合D。这一步是根据D中的每个函数依赖，回到E-R图中，判断其对应的联系是否真的是冗余的，并将其删除。
• 考察过程：对于D中的每一个函数依赖 X -> Y，你需要检查E-R图中是否存在一个直接对应于这个FD的联系。
• 如果存在这样的联系，并且该联系所表达的信息可以通过E-R图中现有的其他实体和联系（这些联系对应于GL中的函数依赖）间接推导出来，那么这个联系就是冗余的。
• 例如，如果FL中包含 (学生ID, 课程号) -> 教师ID（表示学生选修某门课程，由固定教师教授），而GL中已经有 课程号 -> 教师ID（表示一门课程只由一个教师教授）。那么，FL中的第一个FD就是冗余的，因为它可以通过第二个FD推导出来。此时，如果E-R图中有一个“学生-选课-教师”的三元联系，这个联系可能就是冗余的，因为教师信息可以直接通过“课程”实体获得。
• 删除冗余联系：一旦确定某个联系是冗余的，就可以将其从E-R图中移除。

3. 迭代.

逻辑结构设计

1. 一个实体型 → 一个关系模式
• 实体的属性变成关系的属性, 实体的码变为关系的码

2. 一个1:1的二元联系 → 一个独立的关系模式 / 与任意一端对应的关系模式合并
• 转换为一个独立的关系模式: 与该联系相连的各实体的码以及联系本身的属性变成关系的属性, 每个实体的码均是该关系的候选码
• 与某一端实体对应的关系模式合并: 该端关系的码和联系本身的属性组成合并后关系的属性, 合并后关系的码保持不变

3. 一个1:n的二元联系 → 一个独立的关系模式 / 与n端对应的关系模式合并
• 转换为一个独立的关系模式: 与该联系相连的各实体的码以及联系本身的属性变成关系的属性, n端实体的码成为该关系的候选码
• 与n端实体对应的关系模式合并: 1端关系的码(成为外码)和联系本身的属性组成合并后关系的属性, 合并后关系的码保持不变(仍为n端关系的码). 可以减少系统中的关系个数.

4. 一个m:n的二元联系 → 一个独立的关系模式
• 与该联系相连的各实体的码以及联系本身的属性组成新关系的属性
• 各实体的码组合成新关系模式的码

5. 多元联系 → 一个独立的关系模式
• 与该多元联系相连的各实体的码以及该联系本身的属性组成新关系的属性
• 各实体码组合成新关系模式的码

6. 关系模式合并 → 从以上步骤派生出的具有相同码的关系模式可以合并
• 将其中一个关系模式的全部属性加入另一个关系模式中
• 去掉同义属性, 适当调整次序

模式分解

水平分解

• 对符合80/20原则的, 把20%经常被使用的数据水平分解出来形成一个子关系

• 水平分解为若干子关系, 使得每个事务存取的数据对应一个子关系(类似RAID 0, 提高并发)

垂直分解

设计用户子模式(外模式)

• 使用更符合用户习惯的别名

• 针对不同级别的用户定义不同的视图, 保证系统安全性

• 简化系统使用

物理结构设计

存取方法

B+树索引存取方法

• 对哪些属性列建立索引

• 对哪些属性列建立组合索引

• 将哪些索引设计为唯一索引

• 如果一个/组属性经常在查询条件中出现, 则考虑在这个/组属性上建立B+树索引/组合索引

• 如果一个属性经常作为最大值/最小值等聚集函数作用的对象, 则考虑在这个属性上建立B+树索引

• 如果一个/组属性经常在连接条件中出现, 则考虑在这个/组属性上建立B+树索引

Hash索引存取方法

1. 该关系的大小可预知而且不变

2. 该关系的大小动态改变, 但选用的数据库管理系统提供了动态hash存取方法

聚簇

1. 选择聚簇存储方法:
• 需要建立多少个聚簇, 每个聚簇中包含哪些关系
• 一个数据库可以建立多个聚簇, 但是一个关系只能加入一个聚簇

2. 设计候选聚簇:
• 经常在一起进行连接操作的关系可以建立组合聚簇
• 一个关系的一组属性经常出现在等值比较条件中, 则该单个关系可以建立聚簇
• 一个关系的一个/一组属性上的值重复率很高, 则该单个关系可以建立聚簇

3. 检查候选聚簇中的关系
• 从聚簇中删除经常进行全盘扫描的关系
• 从聚簇中删除更新操作远多于连接操作的关系
• 从聚簇中删除重复出现的关系(当一个发现关系重复加入多个候选聚簇时, 必须选择一个最优的)

存储结构

实施, 运行, 维护概念