数据库系统原理与实践 笔记 #7

数据库系统原理与实践 笔记 #7

数据库设计和E-R模型(续)

转换为关系模式

• 一个符合E-R模式的数据库可以表示为一些关系模式的集合：
  • 实体集和联系集都可以用表示数据库内容的统一的关系模式来表示
  • 每个实体集合联系集独有一个特有的关系模式与其对应，并分配相应的名字
  • 每个关系模式都有一些列，每个列多有唯一的名字

具有简单属性的实体集的表示

• 从强实体集转换而来的模式与强实体集具有相同属性、主码
• 从弱实体集转换的模式包含弱实体集的属性和表示强实体集的主码
• 该模式的主码由强实体集的主码与弱实体集的分辨符组合而成

复合属性

• 复合属性通过为每个子属性创建单独的属性
  • 实体集instructor有复合属性name：由first_name, middle_name和last_name构成
  • 转化成关系模式后，该实体集具有name_first_name，name_middle_name和name_last_name

多值属性

• 实体集E的多值属性M用一个独立的模式EM表示
• 模式EM包含对应于的E主码及多值属性M的属性
• 多值属性的每个值映射到关系模式EM的每一个独立元组
• 不需要建立一个对应于实体集的模式，只需创建一个对应于多值属性的关系即可

联系集的表示

• 联系集关系模式属性的选择
• 联系集主码选择：二元联系集主码选择、多元联系集主码选择
• 注意：需要为联系集的属性建立外码约束

模式的冗余—合并

• 多对一和一对多的联系集的模式，如果“多”方参与是全部的，那么可以将 “多”方实体集和联系集的模式合并成单个包含两个模式所有属性并集的关系模式
• 合并后模式加入原联系集的外码约束
• 如果“多”方参与是部分的，也可以通过使用空值来进行模式合并。转换为关系模式时，联系集中 “一”方的相关属性应注意不能设置为not null
• 在一对一联系的情况下，联系集的关系模式可以跟参与联系的任何一个实体集的模式进行合并
• 一般而言，连接弱实体集与其标识强实体集之间的标识性联系集转换出的模式是冗余的

实体-联系设计问题

设计问题

• 常见错误：用一个实体集的主码作为另一个实体集的属性、将相关实体集的主码属性作为联系集的属性
  

• 如果注册信息还与其他实体集相联系，那么上述E-R设计更有效

• 一般而言，通过创建一个实体集可以将非二元联系集转换为二元联系集

• 所有的费二元联系集都可以用多个二元联系集来表示，但有时n元的联系集能够更清楚的表示几个参与的实体集之间的联系

联系属性的布局

• 设计时将联系集的描述性属性作为联系集的属性还是实体集的属性这一选择应由映射基数约束决定

扩展的E-R特性

特化

• 自顶向下设计过程：从初始实体集到一系列不同层次的实体子集的细化（具体化）
• 在实体集内部进行分组的过程称为特化
• 子集中的实体在某些方面区别于实体集中的其他实体：这些子集成为了较低层的实体集，可能具有高层实体集不具有的属性、或者参与到高层实体集不参与的实体集中
• 特化通过从特化实体指向另一个实体的空心箭头来表示

概化

• 自底向上设计过程：多个实体集根据共同具有的特征综合称一个较高层的实体集
• 概化是高层实体集与一个或多个底层时提及间的包含关系
• 概化是特化的逆过程，可互换使用
• 它们在E-R图中的表示是相同的，区别在于不同的出发点和目标

属性继承

• 属性继承—底层实体集继承了与其相关联的高层实体集的所有属性，并且继承地参与到其高层实体所参与的联系集中

特化/概化的设计约束

• 成员资格判断约束：条件/属性定义的、用户定义的：用户将实体指派给某个实体集
• 实体是否可以属于同一概化中的多个低层实体集的约束：不相交、重叠
• 完全性约束：定义高层实体集中的一个实体是否必须属性该概化的至少一个低层实体集：全部：每个高层实体必须属于一个低层实体集、部分：允许一些高层实体不属于任何低层实体集
• 默认部分概化

聚集

• 考虑我们之前看到的三元联系proj_guide，假设我们要记录某个项目中导师对学生的评价
  

• 为不引入冗余，用聚集来表示E-R模型，如下图所示：一个学生在一个指定的项目中由一个指定导师辅导；学生、导师、项目的组合可能有相关联的评价信息

E-R图表示方法总结

E-R设计方案

• 用实体或者属性表示一个对象
• 由实体集或联系集更好地表达现实世界的概念
• 强/弱实体集的使用
• 概化/特化的使用—有助于模块化设计
• 聚类的使用—将聚集实体集作为单一单元，不必考虑其内部结构

UML

• UML(Unified Modeling Language): 统一建模语言
• UML包含了将整个软件系统图形化的很多组件
• UML类图与E-R图类似，仅有一些不同

E-R图与UML类图对比

关系数据库设计

好的关系设计的特点

设计选择1：更大的模式？

• 通过E-R图转换得出一组关系模式后

• 选择1：把一些关系模式合并为更大的关系，例如inst_dept(ID,name,salary,dept_name,building,budget)
  

• 如果通过E-R模型转换得出如下的两个关系模式：sec_class(sec_id, building, room_number) and section(course_id, sec_id, semester, year)

• 那么在逻辑设计中，我们可以将上述两个关系合并为如下关系：section(course_id, sec_id, semester, year, building, room_number)，这样的关系模式不会产生数据冗余

设计选择2：更小的模式？

• 如果通过E-R模型转换得出inst_dept关系模式，那么在逻辑设计中，我们可以将其分解为两个关系模式：instructor(ID, name, salary, dept_name)，department(dept_name, building, budget)
• 这样可以避免(building, budget)的数据冗余
• 可以通过如下一条规则：dept_name确定(building,budget)数据，即保持函数依赖：dept_name$\to$building,budget
• 由于dept_name在inst_dept关系中不是主码，因此需要将其拆分为更小的关系模式
• 并不是所有的关系模式拆分都是有益的：
  • 例如，将employee(ID,name, street)分解为employee_attr1(ID, name)和employee_attr2(name, street, city, salary)
• name无法作为employee_attr2关系的主码，有可能会重名：无法通过分解出的employee_attr1和employee_attr2重建(自然连接)得出原始关系
• 我们称无法通过自然连接重建原始关系元组的分解为有损分解

有损分解

无损分解的例子

• 无损分解(lossless decomposition)

• $R=(A,B,C)$的分解：$R_1=(A,B),R_2=(B,C)$
  

• $r={\prod }_{A,B}(r)\bowtie {\prod }_{B,C}(r)$

• inst_dept分解为instructor和department关系是无损分解

函数依赖

• 假设$r(R)$是一个关系模式，$\alpha \subseteq R,\beta ⫅R$，模式R上的函数依赖：
  $$\alpha \to \beta$$
• 成立的条件是：如果对于任意关系实例r中任意两个元组$t_1$和$t_2$，如果两者的属性(集)$\alpha$ 的值相同，那么它们的属性(集)$\beta$ 取值也相同。也就是：
  $$t_1[\alpha ]=t_2[\alpha ]\Rightarrow t_1[\beta ]=t_2[\beta ]$$
• 称 $\alpha$函数确定$\beta$，$\beta$函数依赖于$\alpha$

函数依赖和码

• 超码：在某关系中，若一个或多个属性的集合 { A 1 , A 2 , . . . , A n } \{A_1, A_2,...,A_n\} {A1​,A2​,...,An​}，函数决定该关系中的其它全部属性，则称该关系的超码
• 候选码：若集合 { A 1 , A 2 , . . . , A n } \{A_1, A_2, ..., A_n\} {A1​,A2​,...,An​}的任何真子集均不能函数决定该关系中的其它属性，则此时 { A 1 , A 2 , . . . , A n } \{A_1, A_2, ..., A_n\} {A1​,A2​,...,An​}是最小的超码，即候选码
• 外码：若关系模式R中属性或属性组X是另一个关系模式的主码，则称X是R的外码

函数依赖是码的概化

• 函数依赖允许我们表达超码不能表达的约束，考虑下面的模式：inst_dept(ID, name, salary, dept_name, building, budget)

函数依赖的使用

• 函数依赖在关系实例和关系模式上的体现区别：
  • 如果关系实例r咋函数依赖集F上合法，则称r满足F
  • 如果模式R上的所有合法关系实例都满足函数依赖集F，我们说F在关系模式R上成立
• 注意：即使函数依赖并没有对关系模式$r(R)$的所有合法实例成立，这个关系模式的其中一个具体实例r可能满足函数依赖

函数依赖相关术语

• 有些函数依赖被称为平凡(trivial) 的因为它们在所有关系中都是满足的
• 例如：name$\to$name，ID,name$\to$ID
• 通常，如果$\beta \subseteq \alpha$，那么$\alpha \to \beta$是平凡的函数依赖
• $\alpha \to \beta$，但$\beta ⊈\alpha$，则称$\alpha \to \beta$是非平凡的函数依赖
• 若$\alpha \to \beta$，则称$\alpha$为决定因素
• 函数依赖$\alpha \to \beta$称为部分依赖的条件是：存在$\alpha$的真子集$\gamma$，使得$\gamma \to \beta$

函数依赖集的闭包

• 从给定函数依赖集f能够推导出的所有函数依赖的集合，我们称之为F集合的闭包
• 我们用$F^{+}$来表示函数依赖集F的闭包

函数依赖的路基蕴含

• 给定关系模式$r(R)$，如果$r(R)$的每个满足F的实例也满足某个函数依赖f，则R上的函数依赖f逻辑蕴含于r上的函数依赖集F
• 已知关系R上的函数依赖集T、F，如果对于该关系中满足F的每一个关系实例都满足T，则称函数依赖集F逻辑蕴涵函数依赖集F

函数依赖的推理规则

• Armstrong公理：
  • 如果$\beta \subseteq \alpha$，则有$\alpha \to \beta$(自反律)
  • 如果$\alpha \to \beta$，则有$\gamma \alpha \to \gamma \beta$（增补律）
  • 如果$\alpha \to \beta$及$\beta \to \gamma$，则有$\alpha \to \gamma$（传递律）
• 附加定理：

  • 如果$\alpha \to \beta$及$\alpha \to \gamma$，则有$\alpha \to \beta \gamma$(合并律)

  • 如果$\alpha \to \beta \gamma$，则有$\alpha \to \beta$及$\alpha \to \gamma$(分解律)

  • 如果$\alpha \to \beta$及$\gamma \beta \to \delta$，则有$\alpha \gamma \to \delta$（伪传递律）

属性闭包的应用

• 超码的判断
• 验证函数依赖
• 计算F的闭包