实体关系(E/R)模型
串讲要点
- 需要会画
E/R模型基础
目的与概念
实体关系模型(Entity-Relationship Model)是一种数据库设计工具,它允许我们:
- 草绘数据库模式设计,包括约束但不包括操作
- 以图形化方式表达数据库结构,形成实体关系图
- 作为从需求分析到关系数据库设计的桥梁
在实际开发中,E/R模型是与"老板"(领域专家)沟通的重要工具,帮助确定数据库应该包含什么内容。
实体集(Entity Sets)
实体集是E/R模型的核心概念:
- 实体(Entity):现实世界中的一个"事物"或对象
- 实体集(Entity Set):类似实体的集合(类似于面向对象编程中的"类")
图形表示:实体集在E/R图中用矩形表示
示例:
Students
(所有学生的集合)Courses
(所有课程的集合)Beers
(所有啤酒的集合)
属性(Attributes)
属性描述实体集中实体的特征:
- 属性是简单值,如整数、字符串等
- 每个实体都有这些属性的特定值
图形表示:属性在E/R图中用椭圆表示,通过线条连接到所属的实体集
示例:
Beers
实体集可能有属性:name
、manf
(制造商)- 一个具体的Beer实体可能有值:(Bud, Anheuser-Busch)
关系(Relationships)
基本概念
关系描述不同实体集之间的联系:
- 关系连接两个或多个实体集
- 关系具有自己的语义含义(如"喜欢"、"销售"等)
图形表示:关系在E/R图中用菱形表示,通过线条连接相关的实体集
示例:
Likes
:连接Drinkers
和Beers
,表示饮酒者喜欢哪些啤酒Sells
:连接Bars
和Beers
,表示酒吧销售哪些啤酒Frequents
:连接Drinkers
和Bars
,表示饮酒者常去哪些酒吧
多向关系可以连接三个或更多实体集:
- 例如,
Serves
可以是连接Drinkers
、Bars
和Beers
的三向关系,表示"饮酒者在特定酒吧喝特定啤酒"
关系的多重性
关系的多重性定义了实体集之间关联的约束:
多对多关系(M:N)
- 第一个实体集中的一个实体可以关联到第二个实体集中的多个实体,反之亦然
- 图形表示:不带箭头的连接线
- 示例:
Bars
和Beers
之间的Sells
关系(一个酒吧销售多种啤酒,一种啤酒被多家酒吧销售)
多对一关系(M:1)
- 第一个实体集中的多个实体可以关联到第二个实体集中的同一个实体
- 图形表示:带箭头指向"一"的一侧
- 示例:
Beers
和Manfs
之间的ManufacturedBy
关系(多种啤酒由同一制造商生产)
一对一关系(1:1)
- 第一个实体集中的一个实体最多关联到第二个实体集中的一个实体,反之亦然
- 图形表示:双向箭头
- 示例:制造商和啤酒之间的
Best-seller
关系(假设每个制造商只有一个畅销产品)
圆角箭头表示"恰好一个",即强制要求必须有关联(非空)。
关系上的属性
关系本身也可以有属性:
- 这些属性属于关系本身,而不是任何参与的实体
- 通常用于描述关系的特征
示例:
Bars
和Beers
之间的Sells
关系可以有一个price
属性- 价格是酒吧和啤酒的函数,而不仅仅是其中一个的函数
角色(Roles)
当同一个实体集在一个关系中出现多次时,需要使用角色来区分:
- 角色名标记在实体集与关系之间的连接边上
- 角色名澄清了实体在关系中扮演的不同角色
示例:
Drinkers
实体集在Married
关系中出现两次,分别以husband
和wife
角色Drinkers
实体集在Buddies
关系中出现两次,分别以Buddy1
和Buddy2
角色
高级E/R概念
子类(ISA关系)
子类表示特殊情况的实体:
- 子类继承父类(超类)的所有属性
- 子类还可以有自己特有的属性
- 子类通常构成一个层次结构(树形结构)
图形表示:通过指向超类的三角形(标记为ISA)表示子类关系
示例:
Ales
是Beers
的子类- 所有
Ales
都是Beers
,但不是所有Beers
都是Ales
Ales
除了继承Beers
的所有属性外,还可能有特有的color
属性
键(Keys)
键是唯一标识实体集中实体的属性组:
- 键的所有属性一起使得实体集中的任何两个实体互不相同
- 每个实体集必须指定一个或多个键
表示方法:通常在E/R图中通过下划线标记键属性
示例:
Students
实体集中,SID
(学生ID)可能是键Beers
实体集中,name
和manf
(制造商)的组合可能是键
弱实体集
弱实体集是依赖于其他实体集来唯一标识的实体集:
- 弱实体集没有足够的属性自行形成键
- 需要跟随一个或多个多对一关系来唯一标识实体
图形表示:双重矩形表示弱实体集,双重菱形表示标识关系
示例:
- 足球运动员的
number
属性不足以作为键(两支不同球队的球员可能有相同号码) - 但
number
加上所属Team
(通过Plays-on
关系)可以唯一标识球员
实体关系图设计
设计技巧与原则
设计有效的E/R图应遵循以下原则:
避免冗余
- 不要用多种方式表达同一概念
- 冗余不仅浪费空间,更可能导致不一致性
有限使用弱实体集
- 仅在实体确实需要外部实体帮助标识时使用弱实体集
- 过度使用会增加模型复杂性
适当选择实体集vs属性
- 当属性足够描述信息时,避免创建不必要的实体集
- 但如果属性自身需要有属性,则应将其提升为实体集
从E/R图到关系模式
E/R图可以系统地转换为关系数据库模式:
实体集转换
- 每个实体集转换为一个关系表
- 实体集的属性成为表的列
关系转换
- 每个关系转换为一个表,包含:
- 参与实体集的键(作为外键)
- 关系本身的属性
- 每个关系转换为一个表,包含:
优化转换
- 多对一关系的表可以合并到"多"那一侧的实体表中
- 弱实体集的表必须包含其完整键(包括标识实体的键)
处理子类的策略
- 面向对象方式:每个子类一个表,包含所有属性
- 空值方式:一个总表包含所有属性,不适用的属性用NULL
- E/R方式:每个子类一个表,只包含键和特有属性