软考——软件设计师:第二章:数据库技术考点总结(完整篇)(上)

简介: 软考——软件设计师:第二章:数据库技术考点总结(完整篇)(上)

文章目录:


1.基本概念

1.1 几个专有名词 

1.2 DBMS的功能

1.3 DBMS的特征

2.三级模式——两级映像 

2.1 三级模式 

2.2 两级映像

3.数据库设计过程

4.E-R模型

5.关系代数

6.规范化理论

6.1 函数依赖 

6.2 求候选关键字

6.2.1 码的相关概念 

6.2.2 候选码的求解方法

6.3 价值与用途

6.4 范式

6.5 模式分解


1.基本概念


1.1 几个专有名词

数据(data):Data

数据库(DB):DataBase

数据库管理系统(DBMS):DataBase Management System

数据库系统(DBS):DataBase System,广义上讲:由数据库、硬件、软件和人员组成。

数据库管理员(DBA):DataBase Administrator


1.2 DBMS的功能

数据定义。数据库操作。数据库运行管理。数据的组织、存储和管理。数据库的建立和维护。等等......


1.3 DBMS的特征

数据结构化且统一管理。有较高的数据独立性。数据控制功能(数据库的安全性、完整性、并发控制、故障恢复)。 


2.三级模式——两级映像


2.1 三级模式


模式:也称概念模式,它是数据库中全体数据的逻辑结构和特征的描述。只涉及型的描述,不涉及具体的值。概念模式的一个具体值称为模式的一个实例,同一个模式可以有很多实例。描述模式的数据定义语言为:模式DDL

外模式:也称用户模式或子模式,是用户与数据库系统的接口,是用户看到的那部分数据的描述。 描述外模式的数据定义语言为:外模式DDL

内模式:也称存储模式,是数据物理结构和存储方式的描述,是数据在数据库内部的表示方法,定义所有的内部记录类型、索引和文件的组织方法,以及数据控制方面的细节。描述内模式的数据定义语言为:内模式DDL

(一个数据库系统中,外模式可以有多个,而模式和内模式只有有一个!!!)

外模式——模式——内模式分别对应:视图——基本表——文件


2.2 两级映像


首先,数据的独立性是由DBMS的两级映像功能来保证的。

模式/内模式映像:存在于概念级和内部级之间,实现了模式和内模式之间的相互转换。保证了数据的物理独立性。

外模式/模式映像:存在于外部级和概念级之间,实现了外模式和模式之间的相互转换。保证了数据的逻辑独立性。


3.数据库设计过程



4.E-R模型



E-R模型中,实体用矩形表示、属性用椭圆形表示、联系用菱形表示。

在上图中学生和课程都是实体,而学号、姓名、性别、年龄这四个是学生实体的属性,课程号、课程名、任何教师这三个是课程实体的属性,因为一个学生可以选修多门课程、一门课程也可以被多个学生选修,所以学生与课程之间是多对多联系,即选课联系用菱形表示,而成绩是选课联系中对应的属性。


E-R模型中,每个实体必须转换为一个关系模式,而联系分为(111nmn)三种,前两种可以转也可以不转,第三种则是必须转。所以上面这个例题,ABC三个实体为多对多对多联系,所以必须转换,即一共可转换为4个关系模式。具体的转换规则如以下三个表所示:👇👇👇 


E-R模型转关系模式的规则:11联系

联系类型

联系是否转换

属性

主键

外键

11联系

联系自身属性+

各实体关键字

每个实体的关键字

均可作为主键

每个实体的关键字

均可作为外键

不转

任意一端实体中添加

联系自身属性以及

另一端实体的关键字

仍为原关系模式的主键

另一端实体的关键字

E-R模型转关系模式的规则:1对多联系

联系类型

联系是否转换

属性

主键

外键

1n联系

联系自身属性+

各实体关键字

n端实体的关键字

各实体关键字

不转

n端实体添加

联系自身属性以及

1端实体的关键字

仍为原关系模式的主键

1端实体的关键字

 

E-R模型转关系模式的规则:多对多联系

联系类型

联系必须转换

属性

主键

外键

mn联系

各实体关键字+

联系自身属性

各实体关键字的组合

各实体的关键字


5.关系代数




集合运算符:并、交、差、笛卡儿积。专门的关系运算符:选择、投影、连接、除。

其中,并、差、笛卡儿积、选择、投影这五种运算是基本的运算。(对于属性列,笛卡儿积不去重,自然连接去重)

大家应该都学过数据库中的关系代数,我在这里只介绍了相应的考点,具体的大家可以自行学习!!!


6.规范化理论


6.1 函数依赖


假设:学号姓名,表示学号唯一确定一个学生的姓名,也就是说姓名是完全依赖于学号。

假设(学号,课程号)系名,而根据常识,显然根据一个学生的学号,就已经可以确认这个学生所在系,根本不需要课程号这个属性,所以这就是一个部分函数依赖。

假设:学号系名,系名系主任姓名,在这里我们可以直接得出:学号系主任姓名,所以这就是一个传递函数依赖。

这里还要介绍一下函数依赖的公理系统,设关系模式RUF):👇👇👇

A1自反律:若Y包含于X包含于U,则X→YF所蕴涵。

A2增广律:若X→YF所蕴涵,且Z包含于U,则XZ→YZF所蕴涵。

A3传递律:若X→YY→ZF所蕴涵,则X→ZF所蕴涵。

合并规则:若X→YX→Z,则X→YZF所蕴涵。

伪传递律:若X→YWY→Z,则XW→ZF所蕴涵。

分解规则:若X→YZ包含于Y,则X→ZF所蕴涵。


6.2 求候选关键字

6.2.1 码的相关概念

候选码:也称候选键,若关系模式中的某一属性或属性组能唯一的标识一个元组,则称该属性或属性组为候选码。例如:学号可以唯一确定学生性别、姓名等信息,所以学号就是学生关系模式的候选码。

主码:也称主键,若一个关系模式有多个候选码,则选定其中一个作为主码。例如:学号可以唯一确定学生姓名,身份证号也可以唯一确定学生姓名,那么学号和身份证号都是学生关系模式的候选码,我们选择候选码之一:学号作为主码。

超码:也称超键,对于学生关系模式,学号可以唯一确定学生性别,所以学号可以作为候选码,那么(学号,姓名)组合起来也可以唯一确定学生性别,那么这里的(学号,姓名)就称为学生关系模式的超码。

外码:也称外键,如果关系模式R中的属性或属性组不是该关系的码,但它是其他关系模式的码,那么该属性或属性组对关系模式R而言就是外码。

全码:如果在一个关系模式中,需要所有的属性才可以唯一标识其中的每一个元组,那么就称这个属性组为全码。

(非)主属性:包含在任何一个候选码中的所有属性称为主属性,不包含在任何候选码中的属性称为非主属性。


6.2.2 候选码的求解方法


在一个关系模式中,我们对函数依赖集中的所有的属性进行分类(LRLRN),L类表示该属性只出现在左边,R类表示该属性只出现在右边,LR类表示该属性在左右两边都出现过,N类表示该属性没有出现。

对关系模式中的所有属性进行分类之后,最终的结论是:候选码中一定包含L类属性和N类属性,一定不包含R类属性,可能包含LR类属性。此时我们只需要去求L类和N类属性集的闭包就可以了,如果该属性集的闭包等于全集,那么该属性集就是该关系模式的候选码。如果不是,就从LR类属性中依次添加单个属性,每添加一个,就求一次闭包,直到属性集的闭包等于全集,即可确定该关系模式的候选码。

对于例1:由关系模式R和函数依赖集F可知,L类属性:A1R类属性:A4LR类属性:A2A3,则候选码中一定包含A1,一定不包含A4,可能包含A2A3。而A1属性的闭包为:A1A2A3A4=全集U,所以关系R的候选码为A1


对于例2:由关系模式P和函数依赖集可知,L类属性:ABCDR类属性:EFHILR类属性:GJN类属性:无,所以候选码中一定包含ABCD,一定不包含EFHI,可能包含GJ。而属性集ABCD的闭包为:ABCDEFGHIJ=全集U,所以关系模式P的候选码为ABCD


对于例3:由关系R和函数依赖集F可知,L类属性:无,R类属性:CLR类属性:ABN类属性:无。所以候选码中一定不包含C,此时我们就依次添加LR类属性来求闭包,首先是属性A,它的闭包为:ABC=全集U,所以可以作为关系R的候选码,那么此时ABAC也可以唯一标识每一个元组,称ABAC为关系R的超码;其次看属性B,它的闭包为:ABC=全集U,也可以作为关系R的候选码,那么ABBC同样可以作为关系R的超码。即属性AB都可以作为关系R的候选码。


6.3 价值与用途

6.4 范式

1NF(第一范式):若关系模式R的每一个分量都是不可再分的数据项,则关系模式R1NF

2NF(第二范式):若关系模式R1NF,且每一个非主属性完全依赖于码,则关系模式R2NF。(换句话说,当1NF消除了非主属性对码的部分函数依赖,则称为2NF

3NF(第三范式):若关系模式RUF)中不存在这样的码X,属性组Y及非主属性ZZ不包含于Y)使得X→YY→Z成立,则关系模式R3NF。(换句话说,当2NF消除了非主属性对码的传递函数依赖,则称为3NF

BCNFBC范式):关系模式RUF1NF,若X→YY不包含于X时,X必含有码,则RBCNF。(换句话说,关系模式R中,若每一个决定因素都包含码,则称为BCNF

一个满足BCNF的关系模式有:所有非主属性对每一个码都是完全函数依赖。

                                                所有主属性对每一个不包含它的码也是完全函数依赖。

                                                没有任何属性完全函数依赖于非码的任何一组属性。

6.5 模式分解


对于保持函数依赖和模式分解,在这里只介绍一些简单的例子,具体的大家可以自行学习。

假设一个关系模式RABC),函数依赖集F={A→BB→C},我们将关系模式R分解为R1AB),R2BC)。那么在R1中,我们能够找出A→B;在R2中,我们能够找出B→C,这与原函数依赖集完全对应,所以就称这样的模式分解保持函数依赖。(换句话说,对于一个总关系模式分解成了若干个子关系模式,如果根据这些子关系模式中的属性能够推出与原函数依赖集相同的内容,则称保持函数依赖)

对于模式分解,如果分解的子关系模式数量大于2,则需使用表格法进行还原(表格法在这里就不再详细讲解了);如果分解的子关系模式只有两个:R1R2,那么只需要求一下 R1∩R2(交集)、R1-R2(差运算)、R2-R1(差运算),如果此时 R1∩R2 能够推出 R1-R2R2-R1 其中之一,则称模式分解是无损的。



相关文章
|
6天前
|
机器学习/深度学习 存储 人工智能
新一代数据库技术:融合人工智能与分布式系统的未来前景
传统数据库技术在应对大规模数据处理和智能化需求方面逐渐显露出瓶颈。本文探讨了新一代数据库技术的发展趋势,重点关注了人工智能与分布式系统的融合,以及其在未来数据管理和分析中的潜在优势。通过深度学习和自动化技术,新型数据库系统能够实现更高效的数据处理和智能化决策,为企业带来更灵活、可靠的数据解决方案。
|
6天前
|
存储 人工智能 NoSQL
现代数据库技术演进与应用前景分析
本文探讨了现代数据库技术的演进历程及其在各领域的应用前景。首先介绍了传统数据库的局限性,随后分析了NoSQL、NewSQL以及分布式数据库等新兴技术的特点和优势。接着探讨了人工智能、物联网、大数据等领域对数据库技术提出的新要求,并展望了未来数据库技术的发展趋势与应用前景。
|
6天前
|
Cloud Native OLAP OLTP
云原生一体化数据库技术是一个具有潜力的领域
【5月更文挑战第13天】在业务处理分析一体化趋势下,开发者需权衡OLTP和OLAP数据库的选型。一体化数据库如阿里云瑶池通过Zero-ETL实现数据自动搬迁,简化流程,支持高并发事务和复杂分析。但也带来定制化开发、性能优化及管理维护的挑战。随着集中式与分布式数据库边界模糊,开发者需更深入理解各种架构特点,灵活选择以适应业务需求。云原生一体化数据库在处理大规模数据和高并发场景中展现优势,但选择时需综合考虑技术成熟度、成本和维护因素。总的来说,一体化数据库技术是未来发展的重要方向,但也需要谨慎评估和决策。
30 3
|
6天前
|
存储 机器学习/深度学习 人工智能
新一代数据库技术:融合AI的智能数据管理系统
传统数据库管理系统在数据存储和查询方面已经取得了巨大的成就,但随着数据量的不断增长和应用场景的多样化,传统数据库已经难以满足日益增长的需求。本文将介绍一种新一代数据库技术,即融合了人工智能技术的智能数据管理系统。通过结合AI的强大能力,这种系统能够实现更高效的数据管理、更智能的数据分析和更精准的数据预测,为用户带来全新的数据管理体验。
|
6天前
|
存储 NoSQL 搜索推荐
探索新一代数据库技术:基于图数据库的应用与优势
传统关系型数据库在处理复杂的关系数据时存在着诸多限制,而基于图数据库的新一代数据库技术则提供了更为灵活和高效的解决方案。本文将深入探讨图数据库的核心概念、应用场景以及与传统数据库相比的优势,带领读者一窥未来数据库技术的发展趋势。
|
6天前
|
存储 缓存 算法
ICDE2024 |VDTuner:向量数据库自动调优技术
在CodeFuse接入实际业务的过程中,大模型的推理成本以及生成内容的准确性是产品规模落地的两个核心考量因素。为了降低推理成本,我们研发了CodeFuse-ModelCache语义缓存加速功能,通过引入Cache机制,缓存已经计算的结果,当接收到类似请求后直接提取缓存结果返回给用户。另一方面,为了提升代码生成的准确度,我们引入了few shot机制,在输入大模型之前拼接一些类似的代码片段,帮助大模型更好的理解希望生成的目标代码。上述两个核心功能的实现都依赖于向量数据库(Vector Data Management Systems, VDMS)存储并检索相似的请求或者代码片段。
18 0
|
6天前
|
存储 关系型数据库 分布式数据库
数据库索引回表困难?揭秘PolarDB存储引擎优化技术
PolarDB分布式版存储引擎采用CSM方案均衡资源开销与可用性。
数据库索引回表困难?揭秘PolarDB存储引擎优化技术
|
4天前
|
关系型数据库 MySQL API
实时计算 Flink版产品使用合集之可以通过mysql-cdc动态监听MySQL数据库的数据变动吗
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
80 0
|
6天前
|
关系型数据库 MySQL 数据库
docker MySQL删除数据库时的错误(errno: 39)
docker MySQL删除数据库时的错误(errno: 39)
60 0
|
6天前
|
Java 关系型数据库 MySQL
【MySQL × SpringBoot 突发奇想】全面实现流程 · xlsx文件,Excel表格导入数据库的接口(下)
【MySQL × SpringBoot 突发奇想】全面实现流程 · xlsx文件,Excel表格导入数据库的接口
44 0