数据库期末复习资料
第1章 数据库系统概述
1.数据库技术的产生与发展
1.1数据库系统发展的3个阶段
- 数据模型是数据库系统的核心和基础,各种DBMS软件都是基于某种数据模型的,所以通常按照数据模型的特点将传统数据库分为网状数据库、层次数据库和关系数据库三类。
- 出现时间:网状数据库→层次数据库→关系数据库
网状数据库和层次数据库已经很好解决了数据的集中和共享问题(第一代数据系统),但是在数据独立性和抽象级别上仍然有很大欠缺,关系数据库应运而生(第二代数据库系统)
20世纪80年代末90年代初,人们为了对图形、图像、声音等多媒体数据、时态数据、空间数据、知识信息及各种复杂对象等非常规数据进行有效处理,提出了第三代数据库系统,如多媒体数据库、时态数据库、空间数据库、面向对象数据库、分布式数据库、并行数据库系统、数据仓库、移动数据库、XML数据管理技术等。
1.2数据管理和数据处理
数据管理是指数据的收集、整理、分类、组织、存储、查询、检索、维护等操作,这部分操作是数据处理业务的基本环节,而且是任何数据处理业务中必不可少的共有部分。
数据处理是指从某些已知的数据出发,推导加工出一些新的数据,这些新的数据又表示了新的信息。
数据处理是与数据管理相联系的,数据管理技术的优劣将直接影响数据处理的效率。
1.3数据管理技术的3个阶段
- 人工管理阶段:这个阶段的特点是数据量较少,数据不会永久保存,没有专用的软件对数据进行管理,由单个应用程序管理一组数据,数据不能共享。在这个阶段,应用程序完全依赖于数据,数据与程序没有独立性,数据与数据组之间可能有大量重复的数据,造成数据冗余。
- 文件系统阶段:文件系统的主要特点是数据能以”文件”形式长期保存在外部存储器的磁盘上,数据的逻辑结构和物理结构有了区别,程序可以按名访问,不必关心数据的物理位置。数据不再属于某个特定的程序,可以重复使用,即数据面向应用。然而,文件系统也存在一些缺点,如数据冗余、数据不一致性、数据之间的联系比较弱等。
- 数据库系统阶段:这个阶段的特点是采用数据模型来表示复杂的数据结构。数据库系统不仅描述了数据本身的特性,还描述了数据之间的联系。在这个阶段,数据不再面向某个应用,而是面向整个应用系统。因此,数据冗余明显减少,实现了数据共享,有较高的数据独立性。同时提供数据库的并发控制、数据库的恢复、数据的完整性和数据安全性4个方面的数据控制功能,增加了系统的灵活性和安全性。
2.数据库系统基本概念
- 数据库(DB): 长期存储在计算机内、有组织的、统一管理的相关数据的集合,能够为各种用户共享,具有较小冗余度、数据间紧密联系而又有较高的数据独立性等特点。
- 数据库管理系统(DBMS): 位于用户和操作系统之间的一层数据管理软件,它为用户或应用程序提供访问数据库的方法,包括数据库的建立、查询、更新及各种数据控制。DBMS总是基于各种数据模型,可以分为层次性、网状型、关系型和面向对象型等。
DBMS的功能因产品而异,但现代DBMS一般必须具备以下基本功能:
(1)提供高级的用户接口、查询处理和优化、数据目录管理
(2)并发控制、恢复功能、完整性约束功能、访问控制
数据库系统(DBS): 数据库、数据库管理系统及相关软件、硬件系统、数据库管理员和用户组成的整体系统。
联系:DB是DBMS的基础,DBMS是DB的管理者,而DBS是包括DB和DBMS在内的整个系统。
区别:DB是数据的集合,DBMS是管理这些数据的软件,DBS是包括数据、管理软件和相关应用的整个系统。
3. 数据库系统的特点
实现数据的集中化控制
数据的冗余度小、易扩充(冗余是指相同数据重复出现)
采用一定的数据模型实现数据结构化
避免了数据的不一致性,要求数据在数据库中的表达是相互符合的,不会出现矛盾
实现数据共享,主要体现在多个用户、现在的和将来的、不同语言的和同时四个方面
提供数据库保护,保障数据的完整性和安全性。
数据独立性, 逻辑独立性和物理独立性,用户不受数据库逻辑结构和物理结构的改变影响。
4.其它简答
- 文件系统中的文件与数据库系统中的文件有何本质上的不同?
- 文件系统中的文件是面向应用的,一个文件基本上对应一个应用程序,文件之间不存在联系,数据冗余大,数据共享性差,数据独立性低
- 数据库系统中的文件不再面向特定的某个或多个应用,而是面向整个应用系统,文件之间是相互联系的,减少了数据冗余,实现了数据共享,数据独立性高
- 简述数据独立性、数据物理独立性与数据逻辑独立性
- 数据独立性是指数据库中的数据独立于应用程序,即数据的逻辑结构、存储结构与存取方式的改变不影响应用程序,数据独立性一般分为数据的逻辑独立性和物理独立性
- 数据逻辑独立性是指数据库总体逻辑结构的改变(如修改数据定义、增加新的数据类型、改变数据间的联系等)不需要修改应用程序
- 数据物理独立性是指数据的物理结构(存储结构、存取方式)的改变,如存储设备的更换、物理存储格式和存取方式的改变等不影响数据库的逻辑结构,因而不会引起应用程序的变化
第4章 关系数据库方法
关系与普通表格、文件有什么区别
关系是一种规范化了的二维表格,具有如下性质
属性值是原子的,不可分解
没有重复元组
没有行序
理论上没有列序,为方便,使用时有列序
关系模式的完整性规则
- 实体完整性规则:关系中元组的主键值不能为空
- 参照完整性规则:外键必须是另一个表的主键的有效值,或者是一个”空值”。
- 用户定义的完整性规则
为什么关系中的元组没有先后顺序
由于关系定义为元组的集合,而集合中的元素是没有顺序的,因此关系中的元组也就没有先后顺序(对用户而言)。这样既能减少逻辑排序,又便于在关系数据库中引进集合论的理论
为什么关系中不允许有重复元组
每个关系模式都有一个主键,在关系中主键值是不允许重复的,否则起不了唯一标识作用。如果关系中有重复元组,那么其主键值肯定相等,因此关系中不允许有重复元组
零碎知识点
- 在关系模型中,概念模式是关系模式的集合,外模式是关系子模式的集合,内模式是存储模式的集合
- 关系操作的特点是集合操作
- 关系代数运算中,基本的运算是选择、投影、笛卡儿积、并运算、差运算
- 组合运算有交运算、连接运算、除运算,其中交运算可以由基本运算中的差运算推导出,连接运算可以由基本运算中的笛卡儿积运算、选择运算推导出,自然连接和半连接运算在此基础上还要加上一个投影
- 关系代数中,从关系中取出所需属性组成新关系的操作称为投影
- 关系数据库中可命名的最小数据单位是属性名
- 关系数据库中基于数学的两类运算是关系代数和关系演算,关系演算分为域关系演算和元组关系演算
第5章 关系数据库的结构化查询语言
SQL数据库的体系结构
定义
- 基本表:又称数据表,是数据库中实际存在的关系
- 视图:由基本表或视图产生的虚表,不能存放数据,只存储数据的定义 (优点:数据安全性、数据独立性、操作简便性)
- 存储文件:每个基本表对应一个存储文件,一个基本表还可以带一个或几个索引,存储文件和索引一起构成了关系数据库的内模式
特征
一个SQL模式是表和约束的集合
一个表是行的集合,每行是列的序列,每列对应一个数据项
一个表可以是一个基本表,也可以是一个视图。基本表是实际存储在数据库中的表,视图是从基本表或其它视图中导出的表。视图是一个虚表,它存储在数据库中的只是其定义,而不存放视图的数据,视图中的数据仍存放在导出该视图的基本表中
一个基本表可以跨一个或多个存储文件,一个存储文件也可存储一个或多个基本表
- 用户可以用SQL语句对视图和基本表进行查询等操作
- SQL用户可以是应用程序,也可以是终端用户
三级结构
在SQL中,视图对应于关系模型的外模式,基本表对应于关系模型的模式,存储文件对应于关系模型的内模式
SQL的组成
SQL从功能上可以分为数据定义、数据操纵、数据查询和数据控制4个部分
数据定义语言(DDL):用于定义SQL模式、基本表、视图和索引
数据操纵语言(DML):用于数据的增加、删除、修改
数据查询语言(DQL):用于数据查询
数据控制语言(DCL):用于数据访问权限的控制
1 | --建表、主键、外键定义 |
零碎知识点
UNIQUE和DISTINCT在oracle中通用,一般来说UNIQUE用在表结构、定义中,DISTINCT 用在SELECT中
DISTINCT如果后面跟着两个属性,只有两个属性都不同时才去除重复
排序时NULL在sql server、mysql中记为最小,在oracle中记为最大
聚集函数使用时自动排除NULL,即不考虑NULL
--查询以MIS_开头,且倒数第二个汉字为“导”字的课程的情况 --方法一 ESCAPE中的字符后面的字符不看作通配符,更通用 SELECT CNAME FROM dbo.C WHERE CNAME LIKE 'MIS\_%导_' ESCAPE('\'); --方法二 []中的字符不看作通配符(对- !~ 等原先在[]中有意义的字符无效 ) WHERE CNAME LIKE 'MIS[_]%导_'
第6章 关系模式的规范化理论
6.1 关系模式设计中的问题
关系规范化理论解决了把现实世界表达成数据库模式的问题,是设计关系数据库的指南,也是关系数据库的理论基础。
满足条件较低的规范化:关系模式中的所有属性必须是不可再分的原子项(1NF)
1NF可能出现的问题(这里以S_C_G(SNO,SNAME,DNAME,AGE,CNO,CNAME,PRE_CNO,SCORE)为例)
- 冗余度大,学生每选一门课,有关他本人的信息和有关课程的信息都要存放一次,从而造成数据的极大冗余。
- 插入异常,这个关系模式的关键字由SNO和CNO组成,如果要往数据库中插入一门课程的信息,当该课程暂无学生选修,则不能把该课程的信息插入数据库。
- 删除异常,与上述情况相反,如果库中的刘强同学因某种原因退学,需要把他的信息从库中删除,但因为某课程只有他一个人选修,则在删除刘强本人信息的同时,也把该课程的信息删除了。
6.2 函数依赖
6.3 数据依赖的公理系统
6.3.1 重要概念: 逻辑蕴含
6.3.3 推理规则
6.3.4 函数依赖集闭包和属性集闭包
6.3.5 最小函数依赖集
最小依赖集定义
- F中每一个函数依赖的右部都是单个属性 (单个属性看起来比较简单,且任一函数依赖集F都可以被规范化右部为单个属性)
- F中不存在这样的函数依赖 X→A,使得F-{X→A}与F等价(去掉某一个依赖后F不变,即可以由其他依赖推出去掉的这个依赖,那么这个依赖就是多余的)去掉冗余依赖
- F中也不存在这样的 X→A,使得(F-{X→A}) U {Z→A}与F等价,其中Z C X。(去掉某一个左部为多属性键的依赖中左部的某个属性后F保持不变,即去掉的这个属性在这个依赖中是多余的,没有这个属性可以由这个依赖中的其它属性/属性集推出依赖右部) 用所含属性较少的依赖代替所含属性较多的依赖
求最小依赖集步骤
6.4 关系模式的分解及其问题
6.4.1 分解的原因、依据、优缺点
原因:由于数据之间存在着联系和约束,在关系模式的关系中可能会存在数据冗余和操作异常现象,因此需把关系模式进行分解,以消除冗余和异常现象
依据:分解的依据是数据的依赖和模式的标准(范式)
优点
消除冗余和异常
在分解了的关系中可存储悬挂元组(?)
缺点
- 查询时需要做更多的连接操作,增加了查询时间,降低效率
- 可能分解了的关系不存在泛关系(泛关系是指只存在一个关系模式,获取完全的存取路径独立性)
6.4.2 无损连接分解
定义:将一个关系模式分解成若干个关系模式后,通过自然联接和投影等运算仍能还原到原来的关系模式
分解为两个关系模式
由分解后的两个模式的公共属性(集)推出任意一个模式除公共属性(集)之外的属性(集) :两个依赖,这两个依赖至少有一个属于函数依赖集的闭包
对上一点进一步总结:如果两个关系模式间的公共属性集至少包含其中一个关系模式的关键字,则此分解必定具有无损连接性
分解为多个关系模式
6.4.3 保持函数依赖性
重要定义:投影
保持函数依赖性检验
- 充分条件:如果F上的每一个函数依赖都在其分解后的某一个关系上成立,则这个分解是保持依赖的。
若上述不成立,并不能断言分解不是保持依赖的,因为上面只是充分条件,还要使用下面的算法做进一步判断。
6.5 关系模式的规范化
实质是关系模式不断分解的过程,直至关系模式达到某一范式
6.5.1 求候选键
上述步骤将属性分为L(只出现在左部)、LR(既出现在左部,也出现在右部)、R(只出现在右部)三种类型
首先以L中所有属性作为候选键,求属性集闭包,若该闭包包括关系模式中所有属性,则可以作为候选键。若不包括,则L中所有属性不足以作为候选键(推不出所有属性)
接着从LR中取出1个属性和L中属性一起作为候选键继续1)中步骤 (LR中有n个属性,则应取n次,求n次闭包,若n个闭包均包括关系模式中所有属性,则有n个候选键),成功则终止
从LR中取出2个属性和L中属性一起作为候选键继续1)中步骤 (LR中有n个属性,应取$c_{n}^{2}$次),成功则终止
重复上述步骤,每次从LR中多取出一个属性和L中属性一起作为候选键继续1)中步骤,直至LR中属性被全部取出。
所有候选码中包含的所有属性的并集为主属性,未包含的属性为非主属性
6.5.2 范式判断
BCNF是在3NF的基础上,若3NF中每一个函数依赖左部均为候选键,则该范式为BCNF。
BCNF均为3NF,3NF不一定为BCNF
6.5.3 范式分解
第7章 数据库设计
基本过程
规划
主要任务是建立数据库的必要性及可行性分析,确定数据库系统在组织和信息系统中的地位,以及各个数据库之间的联系
规划工作完成后应写出详尽的可行性分析报告和数据库系统规划纲要
需求分析
- 目标:对系统的整个应用情况作全面的、详细的调查,确定企业组织的目标,收集支持系统总的设计目标的基础数据和对这些数据的要求,确定用户的需求,并把这些要求写成用户和数据库设计者都能够接受的文档
- 步骤:需求信息的收集、分析整理和评审
- 数据流图(Data Flow Diagram, DFD):带有名字的有向线表示数据流、一个圆角矩形代表一个处理进程,带有名称的长方形表示存储信息
- 数据字典(Data Dictionary,DD):包括数据项、数据结构、数据流、数据存储、处理进程,数据字典是在需求分析阶段建立的,并在数据库设计过程中不断改进、充实和完善
概念设计
- 必要性
将概念设计从设计过程中独立开来,至少有以下几个好处:
- 各阶段的任务相对单一化,设计复杂程度大大降低,便于组织管理。
- 不受特定的DBMS的限制,也独立于存储安排和效率方面的考虑,因而比逻辑模式更为稳定。
概念模式不含具体的DBMS所附加的技术细节,更容易为用户所理解及反映用户的信息需求。
数据库概念设计是整个数据库设计的关键,将在需求分析阶段所得到的应用需求先抽象到概念结构,以此作为各种数据模型的基础,从而能更好地、更准确地用DBMS实现这些需求
- 步骤
- 进行数据抽象,设计局部概念模式
- 将局部概念模式综合成全局概念模式
- 评审
- 局部ER图合并冲突
冲突:不同的应用通常被不同的设计人员设计成不同的局部ER模式,在合并时不可避免得存在不一致的地方
主要分为属性冲突、命名冲突和结构冲突三种类型
逻辑设计
主要任务是把概念结构设计阶段设计好的基本E-R图转换为与选用的具体DBMS所支持的数据模型相符合的逻辑模式,除了数据库的逻辑模式外,还得为各类用户或应用设计其各自的逻辑模式,即外模式
物理设计
根据逻辑模式、DBMS及计算机系统所提供的手段和施加的限制设计数据库的内模式,即文件结构、各种存取路径、存储空间的分配、记录的存储格式等
实现
- 建立实际数据库结构
- 装入试验数据,对应用程序进行调试
- 装入实际数据,进入试运行阶段
运行与维护
- 维护数据库的安全性与完整性
- 监测并改善数据库运行性能
- 及时改正运行中发现的系统错误
- 根据用户要求对数据库现有功能进行扩充
输入和输出
输入
设计方法
事物
定义:构成单一逻辑工作单元的操作序列的集合
ACID准则
- 原子性:一个事物对数据库的所有操作,是一个不可分割的工作单元。这些操作要么全部执行,要么什么也不做
- 一致性:一个事物独立执行的结果,应保持数据库的一致性,即数据不会因事物的执行而遭受破坏
- 隔离性:在多个事物并发执行时,与先后单独执行的结果一样
- 永久性:一个事物一旦完成全部操作,它对数据库的所有更新应永久地反映在数据库中
存取控制
自主存取控制(DAC)
- 特点:灵活
同一用户对于不同的数据对象有不同的存取权限
不同的用户对同一对象也有不同的权限
用户还可将其拥有的存取权限转授给其他用户
操作
GRANT语法进行权限的授予、收回等
强制存取控制(MAC)
- 特点:严格
每一个数据对象被标以一定的密级(绝密/机密/可信/公开)
每一个用户也被授予某一个级别的许可证
对于任意一个对象,只有具有合法许可证的用户才可以存取
- 规则
仅当主体的许可证级别大于或等于客体的密级时,该主体才能读取相应的客体;
仅当主体的许可证级别等于客体的密级时,该主体才能写相应的客体。
- 修正后
主体的许可证级别 <=客体的密级,主体能写客体
用户可为写入的数据对象赋予高于自己的许可证级别的密级
一旦数据被写入,该用户自己也不能再读该数据对象了
规则的共同点:禁止了拥有高许可证级别的主体更新低密级的数据对象
MAC与DAC
- DAC与MAC共同构成DBMS的安全机制
原因:较高安全性级别提供的安全保护要包含较低级别的所有保护
先进行DAC检查,通过DAC检查的数据对象再由系统进行MAC检查,只有通过MAC检查的数据对象方可存取。
优秀博文
主键、候选键、键的区别
首先说明 键字=码字,所以 主键=主码=主关键字,候选键=候选码=候选关键字…
所谓键/码,指的是一个表中的一个(或一组)属性,用来标识该表的每一行或与另一个表产生联系。
相信这个图已经画得很清晰了,下面逐一解释:
1、码=超键:能够唯一标识一条记录的属性或属性集。
标识性:一个数据表的所有记录都具有不同的超键
非空性:不能为空
有些时候也把码称作“键”
2、候选键=候选码:能够唯一标识一条记录的最小属性集
- 标识性:一个数据表的所有记录都具有不同的候选键
- 最小性:任一候选键的任何真子集都不能唯一标识一个记录(比如在成绩表中(学号,课程号)是一个候选键,单独的学号,课程号都不能决定一条记录)
- 非空性:不能为空
- 候选键是没有多余属性的超键(举例:学生ID是候选码,那么含有候选码的都是码)
- 少部分地方也有叫超级码的,但是见得不多
3、主键=主码:某个能够唯一标识一条记录的最小属性集(是从候选码里人为挑选的一条)
- 唯一性:一个数据表只能有一个主键
- 标识性:一个数据表的所有记录都具有不同的主键取值
- 非空性:不能为空人为的选取某个候选码为主码
4、主属性:包含在任一候选码中的属性。简单来说,主属性是候选码所有属性的并集
非主属性:不包含在候选码中的属性。 非主属性是相对于主属性来定义的。
5、外键(foreign key):子数据表中出现的父数据表的主键,称为子数据表的外键。
6、全码:当所有的属性共同构成一个候选码时,这时该候选码为全码。(教师,课程,学生)假如一个教师可以讲授多门课程,某门课程可以有多个教师讲授,学生可以听不同教师讲授的不同课程,那么,要区分关系中的每一个元组,这个关系模式R的候选码应为全部属性构成 (教师、课程、学生),即主码。
7、代理键:当不适合用任何一个候选键作为主键时(如数据太长等),添加一个没有实际意义的键作为主键,这个键就是代理键。(如常用的序号1、2、3)
8、自然键:自然生活中唯一能够标识一条记录的键(如身份证)
关系模式范式分解教程
引自关系模式范式分解教程 3NF与BCNF口诀!小白也能看懂-CSDN博客
基础知识
1NF是指表中的每一列都是不可分割的基本数据项,即实体中的某个属性不能有多个值或者不能有重复的属性。
2NF要求属性完全依赖于主键,不能存在仅依赖主关键字一部分的属性。
3NF要求每一个非主属性既不部分依赖于码也不传递依赖于码。
BCNF消除了主属性对候选码的部分和传递函数依赖。(函数依赖左部均为候选键)
3NF分解
分为保持依赖和无损连接
为了说明求解保持依赖,我们先要会求最小依赖集
(1)最小依赖集求法:
口诀:右侧先拆单,依赖依次删。 还原即可删,再拆左非单。
通过求下面的最小依赖集对口诀进行解释
(2)3NF分解:
口诀:
保函依赖分解题,先求最小依赖集。
依赖两侧未出现,分成子集放一边,剩余依赖变子集。
若要连接成无损,再添候选做子集。
下面通过几道例题讲解口诀:
例1.已知R(ABCDE), F={A→D,E→D,D→B,BC→D,DC→A}求保持函数依赖的3NF分解,和具有无损连接性及保持函数依赖的3NF分解
第一步:保函依赖分解题,先求最小依赖集。先求出R的最小依赖集,可得F={A ->D,E->D,D->B,BC->D,DC->A}
第二步:依赖两侧未出现,分成子集放一边。首先可以发现没有不出现在两侧的元素不用单独分出一个子集,剩余依赖变子集,然后我们将各依赖分别划分为子集得到:{AD} {ED} {DB} {BCD} {DCA},即为所求保持函数依赖的3NF分解
第三步:若要连接成无损,再添候选做子集
(1)候选码的求解:所谓候选码即能决定整个关系的,我们通过找未出现在依赖右边的和两侧均未出现的元素即可求得
(2)可以发现C E未出现在右边,因此候选码为{CE}。故所求具有无损连接性及保持函数依赖的3NF分解为{AD} {ED} {DB} {BCD} {DCA} {CE}
例2.关系模式R,有U={A,B,C,D,E,G},F={B→G,CE→B,C→A,CE→G,B→D,C→D},将关系模式分解为3NF且保持函数依赖
第一步:保函依赖分解题,先求最小依赖集。先求出R的最小依赖集,
假设B→G冗余,则(B)+=B D,没有G故不冗余。
假设CE→B冗余,则(CE)+=C E G D A,没有B故不冗余。
假设C→A冗余,则(C)+=CD,故不冗余。
一次可以得到最小函数依赖集Fm={B->G,CE->B,C->A,B->D,C->D}
第二步:依赖两侧未出现,分成子集放一边,剩余依赖变子集。首先可以发现没有不出现在两侧的元素,然后我们将各依赖分别划分为子集得{B G} {C E B} {C A} {B D} {C D},即为所求保持函数依赖的3NF分解
第三步:若要连接成无损,再添候选做子集。找到R的一个候选码为{CE}。故所求具有无损连接性及保持函数依赖的3NF分解为{B G} {C E B} {C A} {B D} {C D} {CE} (注:范式分解并不唯一,正确即可)
BCNF分解
将关系模式R分解为一个BCNF的基本步骤是
1)先求最小依赖集,候码非码成子集
3)余下左侧全候码,完成BCNF题
例.关系模式R,有U={A,B,C,D,E,G},F={B→G,CE→B,C→A,CE→G,B→D,C→D},将关系模式分解为3NF且保持函数依赖
第一步:先求最小依赖集。可以发现CE→G多余,因此最小依赖集为F={B→G,CE→B,C→A,B→D,C→D}。
第二步:候码非码成子集。由于候选码为(CE)因此将CE→B划分出子集(B C E),而B→G,B→D左侧均不含主属性(C、E)中的任何一个故划分出(B G),(B D)
第三步:此时剩余依赖F={C→A,C→D}剩余元素{A,C,D}检查发现函数依赖左侧都是候选码即完成BCNF分解,如果不满足则继续分解余下的。
于是BCNF分解的最后结果为{(B G),(B D),(A C D),(B C E)}。