7.4 逻辑结构设计

思维导图：

 

7.4 逻辑结构设计

• 概念结构与逻辑结构：

  • 概念结构：独立于任何数据模型的信息结构。
  • 逻辑结构设计任务：将概念结构（基本E-R图）转换为与数据库管理系统支持的数据模型相符合的逻辑结构。

• E-R图向关系模型的转换：

  • 基本转换原则：实体型、实体的属性和实体间联系转换为关系模式，包括属性和码的确定。
  • 实体型的转换：每个实体型转换为一个关系模式，属性和码保持不变。

• 实体间联系的转换：

  1. 1:1 联系：
     • 可转换为独立关系模式或合并至一端的关系模式。
     • 独立关系模式时，包括各实体的码和联系属性。
  2. 1:n 联系：
     • 可转换为独立关系模式或合并至n端的关系模式。
     • 关系模式的码为n端实体的码。
  3. m:n 联系：
     • 转换为一个关系模式，包括各实体的码和联系属性。
     • 实体的码组成关系的码或关系码的一部分。
  4. 多元联系：
     • 转换为一个关系模式，包括所有实体的码和联系属性。
     • 实体的码组成关系的码或关系码的一部分。
  5. 相同码的关系模式：
     • 可合并。

• 示例转换：

  • 部门：关系模式包含部门实体属性和“领导”联系属性。
  • 职工：关系模式包含职工实体属性和“属于”联系属性。
  • 产品、供应商、零件：各自对应的关系模式。
  • 参加、供应：联系“参加”和“供应”对应的关系模式。

总结

• 逻辑结构设计涉及将E-R图的实体型和实体间联系转换为适用于关系数据库管理系统的关系模型。
• 重要的是理解不同类型的实体间联系（如1:1, 1:n, m:n, 多元）如何转换为关系模式。

难度

• 理解转换原则：理解如何从E-R图到关系模型的转换原则可能需要一定的数据库设计知识。
• 应用转换原则：实际应用这些转换原则到具体的E-R图时可能需要细致的分析和理解。

易错点

1. 联系的错误转换：在将实体间的联系转换为关系模式时，可能会错误地选择转换方式，尤其是在处理复杂的多元联系时。
2. 属性和码的处理：在转换过程中可能会忽略或错误地处理实体的属性和码。
3. 合并关系模式：在合并具有相同码的关系模式时可能会忽略关键的属性或联系细节。

7.4.2 数据模型的优化

• 优化的必要性：

  • 数据库逻辑设计的结果不是唯一的，优化是为了提高数据库应用系统的性能。

• 优化步骤：

  1. 确定数据依赖：
     • 分析和表示数据项之间的联系。
     • 写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。
  2. 数据依赖的极小化处理：
     • 消除不必要的联系，如元余的联系。
  3. 分析关系模式的范式：
     • 检查关系模式是否存在部分函数依赖、传递函数依赖、多值依赖等。
     • 确定关系模式符合的范式级别。
  4. 根据应用需求调整模式：
     • 分析应用环境，确定是否需要对某些模式进行合并或分解。
  5. 关系模式分解：
     • 水平分解：将关系的元组分为子集合以提高效率。
     • 垂直分解：将关系模式的属性分为子集合，形成子关系模式。

• 规范化程度的考量：

  • 并非总是追求高规范化程度。
  • 需要权衡查询频率、连接运算的成本和规范化程度。
  • 非BCNF的关系模式在只读场景下可能可接受。

• 分解原则：

  • 保证分解后的关系具有无损连接性和保持函数依赖性。

总结

• 数据模型的优化是通过规范化理论和数据依赖分析来提升数据库应用系统的性能。
• 不同应用场景下，适当的规范化程度和关系模式的合并或分解策略是关键。

难度

• 理论与实践的结合：理解规范化理论和将其应用于具体的数据模型需要深入的理论知识和实际经验。
• 综合判断：在实际应用中，正确地进行数据模型优化需要综合考虑应用需求和理论指导。

易错点

1. 过度规范化：可能会过度追求高规范化程度，而忽略了应用环境的实际需求。
2. 错误的分解策略：在进行水平或垂直分解时，可能未能充分考虑无损连接性和保持函数依赖性，导致效率降低或数据完整性问题。
3. 忽视实际应用场景：可能会在不适当的场合应用规范化理论，如在频繁更新的场景中使用过于分散的数据结构。

7.4.3 设计用户子模式

• 用户外模式的设计目的：

  • 在全局逻辑模型的基础上，根据局部应用需求定制。
  • 结合关系数据库管理系统的特点，设计更符合局部用户需求的外模式。

• 利用视图概念：

  • 视图提供了一种方式来创建与用户习惯和权限相适应的外模式。
  • 通过视图，可以定义不同的用户界面和数据展示方式。

• 设计考虑因素：

  1. 别名使用：
     • 用视图定义符合用户习惯的属性别名，解决命名冲突，提高用户体验。
  2. 安全性和权限管理：
     • 定义不同级别用户的视图，限制数据访问，提高系统安全性。
     • 例如，为不同用户（如顾客、销售部门）定义不同属性的视图。
  3. 简化用户操作：
     • 将复杂查询预定义为视图，简化用户的查询操作。

• 示例应用：

  • 产品数据的不同视图：为不同用户群体（如顾客、销售部门）定义展示不同信息的产品视图。

总结

• 用户子模式的设计关键在于利用视图来定制适合不同用户群体的数据展示和访问方式，同时考虑安全性、易用性和用户习惯。

难度

• 视图概念的应用：理解和应用数据库视图概念，根据用户需求和权限设计合适的用户外模式。
• 平衡安全与便利：在保证数据安全性的同时，确保用户操作的便利性。

易错点

1. 忽视用户习惯：在设计用户外模式时，可能会忽视用户的习惯和易用性，导致用户体验不佳。
2. 安全性管理不当：可能在视图设计中未能妥善处理数据访问权限，导致安全性问题。
3. 过度复杂的视图：设计过于复杂的视图，反而增加用户操作的难度。

 总结：

重点

1. 数据模型设计：确定最合适的数据存储和组织方式，包括关系型数据库和非关系型数据库的选择。
2. 功能模块化：将系统分解为可管理和可维护的模块，确保高内聚和低耦合。
3. 接口设计：定义模块间的交互方式，确保数据和控制信息的正确流动。
4. 数据完整性和安全性：确保数据的准确性和保密性，设计恰当的权限控制和验证机制。

难点

1. 处理复杂性：在设计时需要处理系统的复杂性，找到平衡点以简化设计而不牺牲功能。
2. 性能优化：考虑系统的响应时间和资源利用率，优化数据存储和处理流程。
3. 可扩展性和灵活性：设计时要预见未来可能的变更，确保系统容易修改和扩展。
4. 用户需求理解：准确理解用户需求，并将其转化为有效的逻辑结构。

易错点

1. 过度设计：在追求完美的过程中可能导致过于复杂和昂贵的设计。
2. 忽视数据一致性：在设计数据库和数据交互时忽略数据一致性，可能导致数据错误和冲突。
3. 忽视安全性和权限管理：未充分考虑安全风险和适当的访问控制。
4. 模块划分不当：模块划分不合理可能导致高耦合和低内聚，影响系统的维护和扩展。