数据库原理-设计技巧

ER 模型设计技巧总结

1. 概念建模：实体集 vs. 属性

• 原则：当一个概念需要存储多个值、具有结构化信息，或未来可能扩展时，应将其建模为独立的实体集，而非简单的属性。
• 示例：雇员地址。如果地址是单一、非结构化的（如字符串），可作为属性；但若需记录多个地址或结构化信息（如省、市、街道），则应抽象为“地址”实体集，便于查询和管理。
• 好处：支持灵活查询和扩展，避免属性复杂化。

2. 概念建模：实体集 vs. 联系

• 原则：当简单的二元联系无法表达复杂业务逻辑（如多次发生、特定上下文或冗余属性）时，应引入新实体或转换为更高阶联系。
• 案例一：雇员在部门多次任职。简单的多对多联系无法区分多次记录（SSN 和 DID 会重复）。解决方案：引入“WORKIN”实体，将二元联系转换为三元联系，并添加时间属性（如 from_date, to_date）作为标识符，实现唯一区分。
• 案例二：经理管理多个部门且财务权限一致。将财务信息作为联系属性会导致冗余。解决方案：引入“委派”或“审批权限”实体，将权限分组，降低冗余并简化修改。
• 案例三：学生选课成绩。成绩是单值、非多值，应建模为联系属性，而非独立实体。
• 好处：消除冗余，提高数据一致性和管理效率。

3. 联系类型选择：多个二元联系 vs. 一个 N 元联系

• 原则：三元联系的强约束可能过于严格，难以满足复杂业务需求。将三元联系拆分为多个二元联系，能更灵活地施加独立约束。
• 示例：雇员、保险、家属的三元联系。三元联系可能暗示家属是弱实体，且每份保险至少涉及一位家属，导致不恰当的副作用。
• 优化方案：拆分为二元联系，如雇员-保险（全参与，1
  ）、保险-家属（1
  ）、家属-雇员（可选）。这能清晰表达“一个保险只能由一个雇员购买”、“每位家属只对应一份保险”等约束。
• 好处：提高模型灵活性，避免强约束带来的设计难题，更好满足独立业务需求。

总体考量

• 灵活性优先：优先选择能满足复杂约束的方案，避免过度简化导致的数据冗余或约束过强。
• 业务驱动：设计应基于实际业务逻辑，确保模型能准确反映现实世界。
• 迭代优化：在设计过程中，不断评估和调整，以平衡简洁性和准确性。

这些技巧是 ER 模型设计的基础，有助于构建高效、可维护的数据库结构。