关系型数据库应用程序设计

目录

设计的原则

在进行关系型数据库的设计过程中，要遵循以下几个原则，借此可以提高数据库的存储效率、数据完整性和可扩展性。

1. 实体的概念模型设计：在概念模型设计中，对于出现的实体、属性及相关表的结构要统一。例如在数据库设计中，首先要确定实体的属性、以及相关属性的类型、长度、取值范围等。这样就能保证在命名时不会出现同名异义或异名同义、属性特征及结构冲突等问题。

2. 数据的一致性和完整性：在关系型数据库中可以采用域完整性、实体完整性和参照完整性等约束条件来满足其数据的一致性和完整性，用 Primary key（主键）、Foreign key（外键）、Check、Default、NULL 等约束来实现。

3. 数据冗余：数据库中的数据应尽可能地减少冗余，这就意味着不同表之间不应该存在重复的属性字段。例如：若一个部门职员的电话存储在不同的表中，假设该职员的电话号码发生变化时，就要求对多个表进行更新操作，若某个表不幸被忽略了，就会造成数据不一致的情况。

4. 范式理论：在关系数据库设计时，需要根据实际情况来满足某一个范式。通常认为第三范式在性能、扩展性和数据完整性方面达到了最好的平衡。因此，通常要求数据库的设计满足第三范式，以消除数据依赖中不合理的部分。最终实现：一个关系仅描述一个实体或者实体间一种联系。

设计的步骤

关系型数据库设计的过程可大体分为四个时期七个阶段。

1. 用户需求分析时期：主要是了解和分析用户对数据的功能需求和应用需求，是整个设计过程的基础，事关整个数据库应用系统设计的成败。

2. 数据库设计时期：主要是将用户需求进行综合、归纳与抽象，形成一个独立于具体 DBMS 的 E-R 模型。

3. 数据库实现时期：根据 E-R 模型，以及选定的 RDBMS，通过 SQL 完成数据库结构创建，包括：创建数据库、创建表、创建索引、创建聚簇等。

4. 数据库运行与维护阶时期。

设计的范式

为了设计冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。

• 1NF：属性具有原子性约束。
• 2NF：属性具有惟一性约束。
• 3NF：属性具有冗余性约束。

第一范式：确保属性的原子性与唯一性

• 要求每一列都是不可分割的原子属性。
• 要求不存在重复的属性。

示例：

在上面的表中，“家庭信息” 和 “学校信息” 列均不满足原子性的要求，故不满足第一范式，调整如下：

第二范式：确保属性完全依赖于主码（消除部分函数依赖）

• 要求必须先满足第一范式。
• 要求每一个属性都完全依赖于主码，而不能只完全依赖于主键的某一部分（针对联合主键而言）。

示例：

上图所示，同一个订单中可能包含不同的产品，因此主键必须是 “订单号” 和 “产品号” 联合组成。但可以发现，产品数量、产品折扣、产品价格依赖于 “订单号” 和 “产品号”，但是订单金额和订单时间仅依赖于 “订单号” 相关，与 “产品号” 无关，这样就不满足第二范式的要求。那么订单金额和订单时间和 “订单号” 应该分离出来形成新的实体，调整如下：

• “订单号 + 产品号” 为主码
  

• 订单号为主码
  

第三范式：确保属性不依赖于其他非主属性（消除传递依赖）

• 要求必须先满足第二范式。
• 要求每个属性都和主码直接相关，而不能间接相关。

示例：

上表中，所有属性都完全依赖于学号，所以满足第二范式，但是 “班主任性别” 和 “班主任年龄” 直接依赖的是属于非主属性的 “班主任姓名”，而不是主键 “学号”，所以需做如下调整：

• 学号为主码
  

• 班主任姓名为主码
  

注：2NF 和 3NF 的概念很容易混淆，区分它们的关键点在于：

• 2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分（主要针对联合主键的表）；
• 3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。