2.1.3 联系中的角色（role）
• 两个实体集之间有多种联系
empid name as leader Salesman work for depid idno name
Department
gender
phone
2.1.4 联系中的属性 • 除了实体集可定义属性之外，联系也可定义 属性来扩展语义。
–把三元联系表示为一个实体集，称为连接实体集（一种 特殊的实体集，可等价表示一个联系。通常有属性）； –确定连接实体集的属性； –分别建立该实体集到三个原实体集的多对1的二元联系。
• 需要把联系转化为实体集的情况：
–多元联系；多对多联系；有属性的联系
2.2 E/R图设计原则
• 设计原则是指导我们分析需求，设计解决方 案的准则。 • 其目的是为了真实全面反应客观需求，以得 到良好的设计，且应避免常见问题。 • 原则：
2.2.3 简单性
• 简单性原则：
–避免引入多余的元素。 –若违背此原则，多余实体集必然导致多余的联系，空 间浪费；易出错等问题
• 要点：
– 对1对1联系的实体集要仔细研究是否多余。 –若两个实体集之间是1对1联系，且有相同的键，则应 考虑合并两个实体集。
• 避免冗余和简单性都是关于“独立性”。每个建 模元素所表示的含义都不可替代。
–真实性； –避免冗余； –简单性； – 选择合适的元素类型。
2.2.1 真实性
• 真实性原则：
–忠实反映需求规范：实体集、联系和属性应 反映客观的实际情况。 –最基本原则：保持一致性，不自相矛盾。 –若违背此原则，将会得到无效甚至有害的设 计。
2.2.2 避免冗余
• 避免冗余原则：
–对任何事物的任何性质的描述，都仅描述一次。 –若违背此原则，会造成一致性难以维护，空间浪 费等问题。
E
R
F
• 若E是一个弱实体集，则为E提供键属性的 某实体集F必然通过一个联系R与E关联，且 满足下面条件：
–从E到F是多对1的二元联系。 – F为E提供的键属性必然是F的键。 –若F本身是弱实体集，则F为E提供的属性可 能是通过另一个多对1联系与F关联的另一个 实体集的键。 –若从E到F存在多个多对1的联系，则每个联系 都可能把F的键提供给E构成其键。
2.5.3 弱实体集的表示法 • 弱实体集：双边矩形。 • 多对1的联系：双边菱形。 • 键属性：下划线。
小结
• 数据库建模的目的是什么？ • 如何对一个数据库进行建模？我们学过 哪种建模方法？ • 建模时应坚持哪些原则？ • 系统中可能有哪些重要约束？如何对约 束建模？ • 弱实体集是什么？如何对弱实体集建模？
2.1.2 多元联系
• 三元联系中的多重性是如何确定：
–实体集A和B先分别确定一个实体，判断联系 的C的实体是一个还是多个。
• 思考：
–图书馆中“读者”、“书籍”和“管理员”之 间的联系 –学校教务管理中“班级”、“教师”和“课程” 之间的联系
2.1.3 联系中的角色（role）
• 角色：
–在一种联系中，一个实体相对于被关联的其它实体的 职责。
2.4.2 单值约束
• 空值NULL表示什么含义？
– 空值表示“不明确”、或“现在不知道”或“不 存在”的含义。
• E/R模型如何表示单值约束？
– 实体集的每个属性隐含单值约束，且允许为空。 – 不 允 许 为 空 的 属 性 ， 必 须 明 确 标 注 。 ｛ NOT NULL｝ – 多对1联系是单值联系。
–实体集entity set：与类class相对应。描述名称。 矩形表示。 –属性attribute：描述实体某一个性质的值。只 描述名称，不描述类型。椭圆表示。 –联系relationship：两个或多个实体集之间的连 接关系。通常需要描述名称。菱形表示。
2.1 实体/联系图
title
year
Movies
address Studios
Crews
2.5.1 产生弱实体集的原因
• 连接实体集。
year title Signdate Salary Star-of name
Movies
Movie-of
Contracts
Studio-of
Stars
addr
Studios
name addr
2.5.2 对弱实体集的要求
• E/R模型中如何表示多重性：
– 有箭头所指的实体集为1；无箭头所连接的实体集为多。
• 多重性是最基本定量关系，有决定数据库基本结构 的意义。
2.1.2 多元联系
• 一个联系涉及两个以上的实体集，该联系就 是多元联系。通常是三元联系。
Movies
Contract s
Stars
Studios • Contracts是一个三元联系，表示一个制片公司和一个影 星签约以参演某一部电影。 • 一个联系可表示为一个三元组：(studio, star, movie)
Stars in
nam e
address
Stars
length
file type
Own s
Studios
nam e
address
2.1 实体/联系图
• 为仓库管理设计一个E/R模型。仓库主要管理 零件(Part)的入库、出库和采购等事项。仓库 根据需要 向外面厂家(Supplier)订购零件，而 许多工程项目(Project)需要仓库供应零件。 • 工程项目的属性：项目编号，项目名称，项目 开工日期。 • 零件的属性：零件编号，零件名称，规格，颜 色，重量。 • 供应厂家的属性：工厂编号，工程名称，工程 地址。
2.4.1 键（key）
• 选错键的后果：
–错误设计。返工；修复代价高昂。
• E/R图中键的表示：
–下划线表示键。
title year
Movies
length
file type
2.4.1 键（key）
• 每个实体集只有唯一的键吗？ –一个实体集可能有多个键。 – E/R模型中每个实体集通常只选择描述一个键， 即“主键”Primary Key。 –如果需要，可旁注说明多个键。 • 每个实体集的键属性肯定都是自己的属性吗？ –有一种特殊的实体集，称为“弱实体集”，其 键属性的一部分就不是自身属性。 • 每个实体集是否都有自然的属性作为键？ –不是，有些实体集需人工造键。
• 为何要对约束建模？
–除了实体集、联系和属性的名称之外，还有更多信息。 –这些信息不能独立存在，而是附加在已有元素上。 –附加信息以约束的方式作用于实体集、联系或属性。
2.4 对约束（constraint)建模
• 主要的约束：
– 键key：唯一标识 – 单值single-value：值的唯一性 – 参照完整性reference integrity：被参照的值必 须先存在。 – 域domain：值集或值的范围 – 一般约束
2.2.4 选择合适的元素类型
• “合适”原则：
–表示事物的某个性质时，可能面临多种建模元素的选择。 –相对的合理；更自然；更简单；更贴近需求。
• 是选择属性还是实体集：
–若某事物具有除名称之外的更多信息，则应建模为一个实 体集；否则应为属性。
• 是选择一个多元联系，还是一个等价的连接实体集：
–根据具体需求分析的要求决定。
第二章 数据库建模
• 当构建一个数据库应用时，如何以简单明确的方 式描述各种数据的结构特征？ • 从思想→E/R设计→关系模式→关系DBMS • 主要内容：
– – – – 实体/联系图: E/R图 设计原则 对约束建模 弱实体集
2.1 实体/联系图
• Entity/Relationship图，简称E/R图，一种传 统的图形化数据库建模语言。E/R模型。 • E/R图的主要建模元素 ：
2.1.1 E/R联系的多重性（multiplicity）
• 多重性是实体之间存在的定量的约束关系。 • 本质上区分为两种多重性：
– 1：关联零个或一个实体，“最多一个” –多：关联零个到多个实体，“能超过一个”
• 组合起来，考虑实体集A到B的联系：
– 1对1：A的一个实体对应B的零个或一个实体； 且B的一个实体对应A的零个或一个。 –1对多：A的一个实体对应B的零个到多个实体； 而B的一个实体对应A的零个或一个。（多对1是 1对多的逆联系） –多对多：A到B是1对多、且B到A也是1对多。
2.4.2 单值约束
• 值：
–一个实体在某方面的一个状态。 –一个实体在属性或联系上的值表示该实体的状态。
• 单值：
–一个实体在某个属性或联系上的值“只有一个”。 反之，如果多于一个值，则为“多值”。
• 区别单值约束的两种情况：
– “至多一个”：允许空值(NULL)，即零个或一个。 – “必须一个”。不允许空值，必存在一个非空值。
• 当两个不同实体集之间建立一种联系时，假定双 方实体集的名称作为各自角色。 • 当一个实体集自身存在某种联系时，就需要确定 联系的双方实体所扮演的不同角色。
Original Sequel-of Sequel Movies 考虑公司雇员之间 的管理关系 (superior—inferior) 应如何表示
2.4.1 键（key）
• 键：
–若一个实体集中的一个或几个属性的值可唯一标 识一个实体，则该属性集称为实体集的一个键。 –键中每个属性称为一个键属性。 –一个键的选择应尽可能使属性集合最小化。 –对象标识Object Identity (OID) – 其它
• 如何在属性集合中寻求键：
–唯一标识一个实体。
–一种特殊的实体集，其键属性的一部分或 全部属性属于其它实体集。
2.5.1 产生弱实体集的原因 • 实体集之间存在包含层次结构。
– 例 ： Studios 和 Crews 之 间 ； Company 和 Department之间；SalesOrder和SalesItem…