逻辑数据库设计
步骤1：创建并检查ER模型
在分析阶段。将确定一系列的用户视图。根据交迭的数量，为了便于管理可能需要合并一些视图。这个步骤地目的是为了每个这样的视图（可能是合并的）构建一个公司（或者是公司的一部分）的逻辑数据模型。
步骤1.1：标识实体
标识和文档化公司视图中的主要的实体。
步骤1.2：标识关系
标识已经确定的实体间存在的主要关系，确定关系的多样性约束。文档化关系，必要时使用ER模型。
步骤1.3：标识实体或关系的有关属性
将属性与合适的实体和关系联系起来，表示简单/复合的属性、单值/多值的属性和派生的属性，文档化属性。
步骤1.4：确定属性域
确定ER模型中的属性的域，文档化属性域。
步骤1.5：确定候选键、主键和备用键属性
为每个实体确定候选键，如果有多于一个的候选键，则选择其中的一个作为主键，其他的作为备用键。对每个实体的候选键、主键和备用键进行存档。
步骤1.6：特化/泛化实体（可选步骤）
如果合适的话，标识超类和子类实体。
步骤1.7：检查模型的数据冗余
检查ER模型确保没有冗余，特别要反复检查1:1关系并删除冗余关系。
步骤1.8：检查模型是否支持用户事务
确保ER模型支持用户所需的视图事务。
步骤1.9：与用户一起检查模型
步骤2：将ER模型映射为表
将ER模型映射为一组表，并检查表的结构。
步骤2.1：映射表
在这一步骤中，我们为步骤1创建的ER模型建立基本表来描绘实体、关系、属性和约束。表结构是从ER模型描述的信息中派生出来的。这些信息包括数据字典和其他描述模型的文档。同样，要为在给ER模型创建表的过程中产生的新的主键和候选键建立文档。
建立表的基本规则如下：
l 为每个实体建立一个包括这个实体的所有简单属性的表。
l 可用主键/外键机制来描述每个关系。为了确定外键，必须在关系中标识父实体和子实体。父实体把它的一个主键放置到子实体中，作为外键。下表给出了从ER模型创建表的规则。
如何将实体、关系和多值属性表达为表的总结
|
实体/关系/属性 |
表达为表 |
|
强实体或弱实体 |
创建包含所有简单属性的表 |
|
1:*二元关系 |
将“一”端实体的主键复制到表达“多”端实体的表中，关系中的任何属性也复制到“多”端的表中 |
|
1:*递归关系 |
“一”端的实体和“多”端 的实体是一样的，代表实体的表有主键的另一个拷贝，这个拷贝是被重命名的，并且有关系的其他属性 |
|
1:1二元关系： |
|
|
两端都是强制参与 |
将实体组合成一张表 |
|
一端是强制参与 |
将有可选参与的实体的主键复制到表达有强制参与的实体的表中，关系的任何属性也被复制到表达有强制参与的实体的表中 |
|
两端都是可选参与 |
没有更多的信息，将一个实体的主键拷贝到另一个实体中。但如果信息是可获得的，则将更具有强制参与的实体作为子实体 |
|
*:*二元关系/复杂关系 |
创建表达关系的表，此表中包含任何与关系有关的属性，将每个父实体中的主键复制到新表中作为外键 |
|
多值属性 |
创建一个表达多值属性的表，并将父实体的主键复制到新表中作为外键 |
l 对每个超类/子类关系，可以定义超类作为父实体而子类为子实体。关于如何最好地描述这样的关系为一个表或多个表，有各种不同的方法。对最合适方法的选择基于在超类/子类关系中的参与约束和无连接的约束，下表给出了如何从ER模型映射表的总结。
表示基于参与和无连接约束的超类/子类关系的可选的选项
|
参与约束 |
无连接约束 |
需要的表 |
|
强制 |
非无连接约束（And） |
一张表 |
|
可选 |
非无连接约束（And） |
两张表：一个表用于超类，另一张表用于所有的子类 |
|
强制 |
无连接约束（Or） |
多张表：每个表用于超类/子类的组合 |
|
可选 |
无连接约束（Or） |
多张表：一张表用于超类，其他的用于每个子类 |
步骤2.2：用规范化方法检查表结构
这个步骤的目的是检查在步骤2.1中建立的每个表的列的分组。可以用规范化的规则检查每个表的组成。每个表最少应该是第三范式（3NF）的。
步骤2.3：检查表是否支持用户事务
在这个步骤中，我们要确定表是否支持视图所需要的事务。视图需要的事务可以从用户需求说明书确定。
步骤2.4：检查业务规则
检查逻辑数据库设计中表达的所有业务规则。这些约束包括：指明需要的数据、属性域约束、实体完整性、多样性、参照完整性和其他业务规则。对所有的整体性约束进行存档。
步骤2.5：与用户讨论逻辑数据模型
确保逻辑数据模型是公司（或者是公司一部分）所需数据的真实的模型化描述。
步骤2.6：构建并检查全局逻辑数据模型
合并单个的局部逻辑数据模型为一个完整的全局逻辑数据模型，以描述公司（或是公司的一部分）的数据要求。
步骤
合并单个的局部逻辑数据模型为一个完整的全局逻辑数据模型。这个步骤的一些基本的任务如下：
l 回顾实体/表的名字和内容以及它们的主键。
l 回顾关系/外键的名字和内容。
l 从局部数据模型合并实体/表。
l 包含（不是合并）对每个局部数据模型唯一的实体/表。
l 从局部逻辑数据模型中合并关系。
l 包含（不是合并）在每个局部逻辑数据模型中唯一的关系。
l 从局部数据模型合并关系/外键。
l 包含（不是合并）对每个局部数据模型唯一关系/外键。
l 检查漏掉的实体/表和关系/外键。
l 检查外键。
l 检查业务规则。
l 画出全局ER/表图。
l 更新文档。
步骤
这个步骤的作用与步骤2.3和2.4相同，也是用规范化检查为全局数据模型建立的表的结构，然后检查这些表能否支持所有的用户事务。
步骤
确定在可预见的将来是否存在有意义的变化并估计全局数据模型是否能适应这些变化。
步骤
确保我们建立的全局数据模型是公司（或者是公司的一部分）需要的数据的真实描述。
物理数据库设计
步骤3：为目标数据库管理系统转换全局逻辑数据模型
从逻辑数据模型中产生一个基本表的工作集。
步骤3.1：设计基本表
决定如何在目标数据库管理系统中表述在逻辑数据模型中建立的基本表。为表的设计建立文档。
步骤3.2：设计派生数据的表示
考虑如何表达派生数据。需做出的选择是在每次需要时计算派生列还是引入冗余列来在表中存储派生数据。将派生数据的设计存档。
步骤3.3：设计其他业务规则
为目标DBMS设计其他的业务规则，将对其他业务规则的设计存档。
步骤4：选择文件组织方式和索引
决定要用来保存基本表的文件组织方式，也就是说，表和记录在辅存中的存取方式。考虑增加索引来提高性能。
步骤4.1：分析事务
理解在数据库中运行的事务的功能并分析重要的事务。
步骤4.2：选择文件组织方式
为每个基本表确定一个有效的文件组织方式。
步骤4.3：选择索引
确定增加索引是否会提高系统的整体性能。
步骤5：设计用户视图
设计在需求收集和分析阶段标识的用户视图。
步骤6：设计安全性机制
为数据库实现设计安全机制，这些安全性机制是在需要收集和分析阶段由用户指定的。将对安全性机制的设计存档。
步骤7：引入受控冗余的考虑
确定引入受控的冗余以降低规范化规则是否会提高系统的整体功能。考虑重复的列或者连接一些表可以获得提高性能的目的。尤其是考虑合并一对一（1:1）关系，在一对多（1:*）的关系中重复非键列来减少连接，在一对多（1:*）的关系中重复外键列来减少连接，在多对多（*:*）关系中用重复列来减少连接，可以引入重复的组，建立摘要表和分区表。
步骤8：监视和调用运行的系统
监控运行的系统并提高系统性能来改进不合适的设计决定或者反映变化的需求。