数据库系统原理与实践 笔记 #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 → \rightarrow building,budget
  • 由于dept_name在inst_dept关系中不是主码,因此需要将其拆分为更小的关系模式
  • 并不是所有的关系模式拆分都是有益的:
    • 例如,将employee(ID,name, street)分解为employee_attr1(ID, name)employee_attr2(name, street, city, salary)
  • name无法作为employee_attr2关系的主码,有可能会重名:无法通过分解出的employee_attr1employee_attr2重建(自然连接)得出原始关系
  • 我们称无法通过自然连接重建原始关系元组的分解为有损分解

有损分解

在这里插入图片描述

无损分解的例子

  • 无损分解(lossless decomposition)

  • R = ( A , B , C ) R=(A,B,C) R=(A,B,C)的分解: R 1 = ( A , B ) ,   R 2 = ( B , C ) R_1=(A,B),\ R_2=(B,C) R1=(A,B), R2=(B,C)
    在这里插入图片描述

  • r = ∏ A , B ( r ) ⋈ ∏ B , C ( r ) r = \prod_{A,B}(r)\bowtie \prod_{B,C}(r) r=A,B(r)B,C(r)

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

函数依赖

  • 假设 r ( R ) r(R) r(R)是一个关系模式, α ⊆ R , β ⫅ R \alpha \subseteq R,\beta \subseteqq R αR,βR,模式R上的函数依赖
    α → β \alpha\rightarrow\beta αβ
  • 成立的条件是:如果对于任意关系实例r中任意两个元组 t 1 t_1 t1 t 2 t_2 t2,如果两者的属性(集) α \alpha α 的值相同,那么它们的属性(集) β \beta β 取值也相同。也就是:
    t 1 [ α ] = t 2 [ α ] ⇒ t 1 [ β ] = t 2 [ β ] t_1[\alpha] =t_2[\alpha] \Rightarrow t_1[\beta]=t_2[\beta] t1[α]=t2[α]t1[β]=t2[β]
  • α \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(R) r(R)所有合法实例成立,这个关系模式的其中一个具体实例r可能满足函数依赖

函数依赖相关术语

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

函数依赖集的闭包

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

函数依赖的路基蕴含

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

函数依赖的推理规则

  • Armstrong公理
    • 如果 β ⊆ α \beta\subseteq\alpha βα,则有 α → β \alpha\rightarrow\beta αβ(自反律)
    • 如果 α → β \alpha\rightarrow\beta αβ,则有 γ α → γ β \gamma\alpha\rightarrow\gamma\beta γαγβ增补律
    • 如果 α → β \alpha\rightarrow\beta αβ β → γ \beta\rightarrow\gamma βγ,则有 α → γ \alpha\rightarrow\gamma αγ传递律
  • 附加定理:
    • 如果 α → β \alpha\rightarrow\beta αβ α → γ \alpha\rightarrow\gamma αγ,则有 α → β γ \alpha\rightarrow\beta\gamma αβγ(合并律)

    • 如果 α → β γ \alpha\rightarrow\beta\gamma αβγ,则有 α → β \alpha\rightarrow\beta αβ α → γ \alpha\rightarrow\gamma αγ(分解律)

    • 如果 α → β \alpha\rightarrow\beta αβ γ β → δ \gamma\beta\rightarrow\delta γβδ,则有 α γ → δ \alpha\gamma\rightarrow\delta αγδ伪传递律

属性闭包的应用

  • 超码的判断
  • 验证函数依赖
  • 计算F的闭包
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: 数据库系统工程师笔记csdn是一篇关于数据库系统工程师学习笔记的文章。在这篇文章中,作者通过分享自己的学习笔记,为想要从事数据库系统工程师工作的人提供了有用的参考和指导。 文章中首先介绍了数据库系统工程师的职责,包括设计、开发、测试、维护和优化数据库系统,同时需要具备扎实的数据库原理和编程能力。作者建议想要成为一名数据库系统工程师的人,应该首先学习数据库的基本概念和 SQL 命令,同时还要了解各种数据库管理系统的操作和配置。 接着,作者介绍了数据库设计的基本步骤和原则,包括需求分析、概念设计、逻辑设计和物理设计等方面。这些步骤都非常重要,应该在设计数据库系统之前认真考虑。 最后,作者分享了自己在学习数据库系统工程师方面的心得和体会,强调了学习的重要性和不断提高自己的必要性。他建议大家在学习过程中要注重实践和思考,通过参与实际项目来提高自己的技能和经验。 总之,数据库系统工程师笔记csdn是一篇有价值的学习笔记,为想要成为一名数据库系统工程师的人提供了很好的指导和建议。希望更多的人可以从中获得启发,不断提高自己的技能和水平。 ### 回答2: 数据库系统工程师是一个高端技术岗位,主要负责设计和维护复杂的数据库系统。作为一名数据库系统工程师,需要具备深厚的计算机理论知识和丰富的实践经验,掌握多种数据库系统的管理和操作技术,以及熟练应对各种异常情况和技术挑战的能力。 在这个领域里,csdn的笔记内容十分丰富,包括了基础知识、应用实践数据库系统架构设计、性能优化、数据安全等多个方面。这些笔记内容不仅包含了数据库的基础知识,还介绍了很多数据库系统性能调优和安全问题的解决方案,能够帮助数据库系统工程师更好地解决实际问题,提高工作效率。同时,笔记中有许多实用的案例,可以让数据库系统工程师更好地理解和掌握数据库系统的各种技术。 除了csdn的笔记外,数据库系统工程师还需要不断学习和探索新的数据库技术,通过阅读相关书籍和参加各种技术交流会议,拓展自己的视野和技能。只有不断学习和提高,才能在这个竞争激烈的领域里保持竞争力。 ### 回答3: 数据库系统工程师是负责设计、开发和维护数据库系统的专业技术人员。在现代信息化时代,全球各行各业都离不开数据库系统,这就需要数据库系统工程师掌握一定的技术,从而保证各种业务得以正常运行和发展。 CSND是一个专注于IT技术交流的平台,是大部分IT技术爱好者和从业人员的必备之地。在这个平台上,数据库系统工程师可以找到大量的学习资源和同行的交流,提高自己的技能水平。比如,他们可以了解数据库系统的基本概念、数据结构、SQL语言、数据库事务、索引优化和数据备份等技术,从而应对各种复杂的业务需求。 此外,数据库系统工程师还应该关注行业的大趋势,不断更新自己的知识储备。比如,随着大数据和云计算技术的快速发展,数据库系统工程师需要掌握分布式数据库、NoSQL等新技术,以适应业务的巨大变革。 总之,作为数据库系统工程师,不仅需要掌握实用技术,更要时刻关注技术的发展趋势和行业的变化,保持敏锐的洞察力和学习能力。而在CSND这个优秀的技术交流平台上,数据库系统工程师可以获得更多的机会,拓展自己的思路和视野,向自己的目标不断前进。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值