数据库原理要点.docx

数据库原理要点.docx

《数据库原理要点.docx》由会员分享，可在线阅读，更多相关《数据库原理要点.docx（17页珍藏版）》请在冰点文库上搜索。

数据库原理要点

结合复习要点和教材、课件进行复习

第一章数据库系统概述（☆）

数据库相关术语：

数据库、数据库管理系统、数据库系统的概念以及之间的联系

简单了解数据库的发展阶段人工管理-文件系统-数据库系统

数据模型：

理解信息的三种世界以及其对应关系；数据模型组成要素、信息世界涉及的基本概念、概念模型的表示方法（结合具体案例复习E-R图）、

简单了解常用的结构数据模型-层次、网状、关系模型

关系模型中涉及的概念

数据库系统模式结构：

三级模式模式、外模式、内模式

两级映像：

模式/内模式映象保证数据的物理独立性；外模式/模式保证了数据和程序间逻辑独立性

第二章关系数据库基础（☆☆）

关系模型三个组成部分：

数据结构、关系操作、完整性约束

理解关系数据结构中的概念：

关系、域、笛卡尔积、关系的性质

理解完整性约束：

实体完整性、参照完整性、用户自定义完整性

关系代数（结合举例案例进行复习、要求会用关系代数描述具体要求）：

传统的集合运算并、交、差、广义笛卡尔积

专门的关系运算：

选择、投影、连接、除

第四章关系数据库标准语言（☆☆☆）

SQL基本功能：

数据查询SELECT、数据操作INSERT、UPDATE、DELETE、数据定义CREATE、ALTER、DROP和数据控制GRANT、REVOKE

SQL支持的关系数据库三级模式：

外模式对应于视图和部分表、模式对应表、内模式对应存储文件

数据定义语言CREATE、ALTER、DROP：

创建表、修改表、删除表、完整性约束、索引的作用、类型、建立原则、创建索引、删除索引、视图的概念、视图的作用、定义视图、修改视图、删除视图

数据查询语句SELECT简单查询、复杂查询、集合查询

数据更新INSERT、UPDATE、DELETE

数据控制GRANT、REVOKE

第六章关系数据库设计理论（☆☆☆）

理解关系可能出现的问题：

数据冗余大、插入异常、更新异常、删除异常关系模式基本要求

函数依赖：

函数依赖、完全函数依赖、部分函数依赖、平凡函数依赖、非平凡函数依赖、传递函数依赖（要求会分析具体案例中的函数依赖）

候选键、主属性、非主属性（结合具体案例）

范式：

第一范式、第二范式、第三范式、BC范式（结合具体实例理解）

低一级范式通过模式分解转换为若干个高一级范式的关系模式集合，分解基本原则：

‘一事一地’

理解关系模式规范化的步骤：

对1NF关系进行投影，消除原关系中非主属性对键的部分函数依赖转换为若干个2NF；对2NF关系进行投影，消除原关系中非主属性对键的传递函数依赖将转换为若干个3NF；对3NF进行投影，消除原关系中主属性对键的部分函数依赖和传递函数依赖，使决定因素都包含一个候选键，得到一组BCNF关系[要求会分析具体案例包含什么函数依赖、属于第几范式、如何划分为高一级范式结合ppt]

第七章数据库设计（☆☆）

数据库设计的基本步骤：

需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库实施、数据库运行和维护阶段（每个阶段的任务）

概念结构设计：

E-R图

逻辑结构设计：

E-R图向关系模式转换的基本原则实体型转换为一个关系模式、实体间的联系针对不同的情况进行转换（结合具体案例）

第九章数据库保护（☆）

数据库安全性以及安全性控制方法

完整性控制：

与sqlserver结合几种约束保证完整性

并发控制和封锁：

事务的概念、特征、数据库并发性含义、并发操作与数据不一致性（结合具体案例、会分析哪些情况是丢失更新、脏读、不可重复读）、并发控制实现的常见机制是封锁、封锁的概念、封锁类型、封锁协议、死锁、活锁

数据库恢复的概念、故障类型、恢复原理（利用冗余数据：

数据转储和登记日志文件）、对应不同故障类型的恢复策略、sqlserver备份恢复技术

历年数据库考试真题

简答题

1、WhatistheSQLandwhat’sthefunctionofSQL?

答案：

SQL是结构化查询语言（StructuredQueryLanguage）的缩写，是介于关系代数与关系演算之间的语言，是一种用来与关系数据库管理系统通信的标准计算机语言。

功能包括数据查询、数据定义、数据操纵和数据控制。

2、已知学生关系模式S（Sno，Sname，SD，Sdname，Course，Grade）

其中：

Sno学号、Sname姓名、SD系名、Sdname系主任名、Course课程、Grade成绩。

写出关系模式S的基本函数依赖和主码。

答案：

Sno→Sname，SD→Sdname，Sno→SD，（Sno，Course）→Grade

关系模式S的码为：

（Sno，Course）

设计题

设学校数据库中有两个实体集：

学生表：

学号、姓名、班级、年龄、所在系

课程表：

课程号、课程名称、教师

某学校有若干学生，每个学生可以选修多门课程，学校有若干课程供学生选修，每门课程可以供多个学生选修，要建立该学校学生选修课程的数据库，请设计：

（1）试画出E-R图，要求在图上注明属性及联系的类型；

（2）将E-R图转换成关系模型，并注明主码；

设计题答案

1.

2.关系模式如下：

学生表（学号，姓名，班级，年龄，所在系）

选修（学号，课程号，成绩）

课程表（课程号，课程名称，教师）

数据库管理技术的发展

集合的理论模式的描述关系运算的种类

简答：

事务的描述并发操作函数的依赖（着重）

E/R图

实体的描述模式内模式的作用理解第三范式和

第二范式的区别锁协议

数据库设计有关数据库的安全范式的判断

数据库管理技术的发展

在数据管理技术的发展过程中，经历人工管理阶段、文件系统阶段和数据库系统阶段。

模式的描述：

一、概念模式（ConceptualSchema）--简称"模式"

　　定义：

也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。

　　　概念模式主要描述数据的概念记录类型及数据以及它们间的关系，它还包括一些数据间的语义约束，对它的描述可用DBMS中的DDL语言定义。

　　理解：

　　①一个数据库只有一个模式;

　　②是数据库数据在逻辑级上的视图;

　　③数据库模式以某一种数据模型为基础;

　　④定义模式时不仅要定义数据的逻辑结构（如数据记录由哪些数据项构成，数据项的名字、类型、取值范围等），而且要定义与数据有关的安全性、完整性要求，定义这些数据之间的联系。

　　它是数据库管理员看到的数据库。

　　二、外模式（ExternalSchema）

　　定义：

也称子模式（Subschema）或用户模式，是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用有关的数据的逻辑表示。

　　外模式也称子模式（Subschema）或称用户模式（User’sschema）它是用户的数据视图，亦即是用户所见到的模式的一个部分，它由概念模式推导而出，概念模式给出了系统全局的数据描述而外模式则给出每个用户的局部描述。

一个概念模式可以有若干个外模式，每个用户只关心与它有关的模式，这样可以屏蔽大量无关信息且有利于数据保护，因此对用户极为有利。

在一般的DBMS中都提供有相关的外模式描述语言（外模式DDL）。

　　理解：

　　①一个数据库可以有多个外模式;

　　②外模式就是用户视图;

　　③外模式是保证数据安全性的一个有力措施。

　　三、内模式（InternalSchema）

定义：

也称存储模式（StorageSchema），它是数据物理结构和存储方式的描述，是数据在数据库内部的表示方式。

　　内模式又称物理模式（PhysicalSchema），它给出了数据库物理存储结构与物理存取方法，如数据存储的文件结构、索引、集簇及hash等存取方式与存取路径，内模式的物理性主要体现在操作系统及文件级上，它还不深入到设备级上（如磁盘及磁盘操作），但近年来有向设备级发展的趋势（如原始磁盘、磁盘分块技术等），DBMS一般提供相关的内模式描述语言（内模式DDL）。

　　理解：

　　①一个数据库只有一个内模式;

　　②一个表可能由多个文件组成，如：

数据文件、索引文件。

　　它是数据库管理系统（DBMS）对数据库中数据进行有效组织和管理的方法

　　其目的有：

　　①为了减少数据冗余，实现数据共享;

　　②为了提高存取效率，改善性能。

数据库三级模式

　　数据模式给出了数据库的数据框架结构，而数据库中的数据才是真正的实体，但这些数据必须按框架所描述的结构组织，以概念模式为框架所组成的数据库叫概念数据库（ConceptualDatabase），以外模式为框架所组成的数据库叫用户数据库（user’sDatabase），以内模式为框架所组成的数据库叫物理数据库（PhysicalDatabase），这三种数据库中只有物理数据库是真实存在于计算机外存中，其它两种数据库并不真正存在于计算机中，而是通过两种映射由物理数据库映射而成。

　　模式的三个级别层次反映了模式的三个不同环境以及它们的不同要求，其中内模式处于最低层，它反映了数据在计算机物理结构中的实际存储形式，概念模式处于中层，它反映了设计者的数据全局逻辑要求，而外模式处于最外层，它反映了用户对数据的要求。

　　数据库系统的三级模式是对数据的三个级别抽象，它把数据的具体物理实现留给物理模式，使用户与全局设计者能不必关心数据库的具体实现与物理背景，同时，它通过两级映射建立三级模式间的联系与转换，使得概念模式与外模式虽然并不具物理存在，但是也能通过映射而获得其存在的实体，同时两级映射也保证了数据库系统中数据的独立性，亦即数据的物理组织改变与逻辑概念级改变，并不影响用户外模式的改变，它只要调整映射方式而不必改变用户模式。

　　1.概念模式到内模式的映射

　　该映射给出了概念模式中数据的全局逻辑结构到数据的物理存储结构间的对应关系，此种映射一般由DBMS实现。

　　2.外模式到概念模式的映射

　　概念模式是一个全局模式而外模式则是用户的局部模式，一个概念模式中可以定义多个外模式，而每个外模式是概念模式的一个基本视图。

外模式到概念模式的映射给出了外模式与概念模式的对应关系，这种映射一般由DBMS实现。

关系运算的种类：

1、和（Union）运算、针对行针对两张具有相同属性的表，将两者表合并起来，在合并过程中遇到重复的行保留一项就行了。

2、差（difference）运算、针对行针对两张具有相同属性的表，第一张表减去第二张表中有的内容。

3、交（intersection）运算、针对行针对两张具有相同属性的表，求出两个表相同的行。

4、广义笛卡尔积（ExtendedCartesianProduct）运算、针对行

两张表行的组合，并且属性是两者之和。

5.选择（Selection）运算、针对行根据某种条件选择出指定的行。

就是查询操作，一般用where语句。

6.投影（Projection）运算、针对列选出一个表的某些属性。

7.连接（Join）运算、针对行从第一张表中取出几行，从第二张表中取出几行，两者的笛卡尔乘积构成最终的结果。

如果是自然连接还要取消相同属性的列。

事务的描述：

事务是DBMS的基本工作单位，它是用户定义的一组逻辑一致的程序序列它是一个不可分割的工作单位，其中包含的所有操作，要么都执行，要么都不执行

事务具有四个特性：

原子性（Atomicity）、一致性（consistency）、隔离性（Isolation）和持续性（Durability）这四个特性也简称为ACID特性

并发操作：

对于多用户系统，数据库操作的并发问题很常见，造成的错误如，数据丢失，读取错误数据等。

究其本质原因其实是数据不一致：

一个进程读入内存中的数据和数据库中的“同一批”数据在某一时刻已经不一样了（可能数据库中的数据被另外一个进程修改了），但程序并不知道，于是造成各种错误。

主要要解决的是离线并发问题，其他并发问题通常可以通过系统事务和简单逻辑解决。

离线并发通常都与业务逻辑有关，当不可避免时，我们期望的是业务事务能象系统事务一样工作。

但长的业务事务有时不能放在一个系统事务中（不灵活，降低了并发性），于是就要自己控制这种跨系统事务的业务事务的并发问题。

当业务逻辑比较复杂时，要在正确性和并发性之间权衡一下，这两方面有时是矛盾的，没法得到完美的解决。

比如，有的处理可能会使某种操作不正确，但它影响很小，不会带来损失，但能提高系统的并发性，这样的正确性可以牺牲。

既然本质原因是数据不一致，要解决问题一般要从两方面入手：

1.禁止出现数据不一致的情况。

也就是要使用锁，把数据库中相关数据锁起来，不允许其它进程修改，当业务事务完成后再释放锁。

把资源变成独占式的，能避免数据不一致。

系统事务也就是这个原理，其锁是数据库底层维护的。

这种方式会造成不灵活，降低并发性，因为当一个进程执行某个业务事务时，其他进程都不能做相关操作。

最简单的方法是把整个业务事务都放在一个系统事务内执行（这就不是离线并发问题了），带来的问题是，当一个进程执行业务事务时，其它进程做相关操作就会进入无响应的等待状态，如果业务事务持续一天，其它进程可能就会等待一天，还可能会造成死锁。

既然使用了锁，就要防止死锁。

想一想，死锁要具有两个必要条件：

一，当持有对某些资源的锁时又去请求新的资源；二，如果请求的资源已经被别人锁住，就进入等待状态。

这两个条件缺一个都不会出现死锁。

比较好的方式就是自己控制锁。

可以在应用服务器端的内存或数据库中开辟一个区域专门维护锁。

例如，在数据库中建一个锁表或给每条数据加一个锁字段，要锁住某条数据时，就标志一下，当其它进程要做相关操作时先检查数据是否已经被锁住，如果已经被锁住，就不再继续执行。

当然，还可以根据业务逻辑，给一组数据设定一个锁。

这与系统事务不同的是，当请求的资源被锁住时，不是进入等待状态，而是放弃继续执行，提高了灵活性（用户可以进行其它操作），还能有效降低死锁的可能性（使之不满足死锁的第二个条件）。

但这种控制方式是最麻烦的，开发者要弄清楚数据的业务逻辑，就是各个业务事务以及相互的关系，还要涉及锁管理和系统事务。

还会涉及维护会话的问题，因为用户可能会非正常结束业务的执行（死机，网络中断，停电，地球不转等），会留下没有释放的锁。

服务器必须做到，如果某个用户已经非正常停止了会话，就释放会话过程中的锁。

另外，要防止死锁，在开发过程中应该注意，当执行某个操作时，尽量开始时就一次性的锁住所有需要的资源，在执行过程中不再请求其它资源（使之不满足死锁的第一个条件），操作结束后释放锁。

如果要更谨慎一些，有时还可以给锁加上时间限制，当一个锁超过一定时间后就自动失效，在锁过程中所做的操作也都变得无效，这其实是使之不满足死锁的第二个条件。

2.允许数据不一致，但数据更新时要进行一致性检查。

从数据库中读出一批初始数据，依据这些数据做了一系列的操作，当把操作结果更新到数据库时，先检查数据库中那“同一批”初始数据是否已经发生了变化，如果发生了变化，根据业务需要，进行一定的处理。

这种方式并发性强，比较灵活，而且是不加锁的，这就避免了不少麻烦问题，实现起来要简单一些。

简单考虑，检查数据一致性时，可以检查数据库中数据和内存中数据的值是否相同。

但如果数据量较大，这种检查恐怕效率很低。

其实一致性检查要考虑粒度问题，根据实际情况选择合适的粒度。

检查具体数据的值是否变化，可以说是最细的粒度。

可以通过数据的版本控制来实现更粗粒度的检查。

以数据记录为单位进行版本管理，可以在数据表中加一个整型字段作为版本。

当insert一条数据时，设置一个初始版本值。

当update数据时，先检查数据库中的版本值是否发生了变化，如果没有变化才执行update，并将被更新的数据版本值加1。

根据业务逻辑，有时要把一组数据使用一个版本来管理（更粗的粒度），这可以使用一个专门存储版本的表来实现。

要注意的是，一致性检查和数据更新一定要在同一个系统事务中进行，才能保证一致性。

没有完美的世界，这种方式的缺点是，当提交更新时才会发现不一致，以至于提交之前的所有操作可能都变得无效。

例如，用户先从数据库中读出一些初始数据，然后做了大量的修改或录入工作，弄了两三个小时，最后提交时系统检查到数据不一致问题，结果提交失败，工作都白做了，于是用户就会很郁闷，于是就会开始不想使用这样的系统，这是我们不希望看到的。

一个缓解的办法是，除了在最后提交时检查一致性外，可以在业务事务进行过程中，时不时的就检查一下，越早发现不一致就可以越早的处理。

这也只是缓解，不能从根本上解决。

第一类方法被称为乐观并发控制方法，第二类方法被称为悲观并发控制方法（“大家们”都喜欢弄出一些有趣的名词来）。

总之，离线并发问题不止是技术问题，首先要深入分析系统的业务逻辑，弄清楚系统在何时何地可能会出现什么样的并发问题，再根据具体情况和实际需要，权衡利弊，选择合适的解决方法。

应该先考虑长系统事务，如果能接受把整个业务事务都放在一个系统事务中，就避免了离线并发问题。

如果不能接受，再考虑乐观控制方法，毕竟这个实现起来要相对简单一些，但只当并发冲突发生的频率较低，可能性较小时，才适合使用乐观方法（如果用户总是提交失败，就更加对这样的系统深恶痛绝了）。

然后再考虑悲观控制方法，虽然麻烦，但可用于并发冲突发生频率较高的情况，实际上是限制了系统的并发性。

锁协议：

三级封锁协议

一级封锁协议:

事务T在修改数据R之前必须对其加X锁，直到事务结束才释放。

以及封锁协议可以防止修改丢失，并保证事务T是可恢复的。

在一级封锁协议中，如果仅仅是读数据不对其进行修改，是不需要加锁的，所以它不能保证可重复读和不读“脏”数据。

二级封锁协议是:

一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。

二级封锁协议除防止丢失修改，还可进一步防止读“脏”数据。

在二级封锁协议中，由于读完数据即可释放S锁，所以它不能保证可重复读。

三级封锁协议:

一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。

三级封锁协议可以防止丢失修改，读“脏"数据和不可重复读。

函数的依赖：

一、函数依赖（FunctionalDependency）的概念

数据依赖的一种，它反映属性或属性组之间相依存，互相制约的关系，即反映现实世界的约束关系。

二、定义

设R（U）是属性U上的一个关系模式，X和Y均为U={A1，A2，…，An}的子集，r为R的任一关系，如果对于r中的任意两个元组u，v，只要有u[X]=v[X]，就有u[Y]=v

[Y]，则称X函数决定Y，或称Y函数依赖于X，记为X→Y。

例：

（sno-学生ID，tno-教师ID，cno-课程ID，sname-学生姓名，tname-教师姓名，cname-课程名称，grade-成绩）

1、sno→sname,cno→cname,（sno,cno）→grade√

2、sname→sno,tno→cno,sno→tname×

三、函数依赖是语义范畴

1、语义：

数据所反映的现实世界事物本质联系

2、根据语义来确定函数依赖性的存在与否

3、函数依赖反映属性之间的一般规律，必须在关系模式下的任一个关系r中都满足约束条件。

四、属性间的联系决定函数依赖关系

设X、Y均是U的子集

1、X和Y间联系是1:

1，则X→Y,Y→X。

（相互依赖，可记作X←→Y）

2、X和Y间联系是M:

1（M），则X→Y。

3、X和Y间联系是M:

N（M,N），则X、Y间不存在函数依赖。

五、完全函数依赖和部分函数依赖

1、函数依赖分为完全函数依赖和部分函数依赖

2、定义：

在R（U）中，如果X→Y，并且对于X的任何真子集X'都有X'Y'，则称Y完全依赖于X，记作X→Y；否则，如果X→Y，且X中存在一个真子集X'，使得X'→Y成立，则称Y部分依赖于X。

例：

学生ID，学生姓名，所修课程ID，课程名称，成绩

（学生ID，所修课程ID）→成绩

成绩既不能单独依赖于学生ID，也不能单独依赖于所修课程ID，因此成绩完全函数依赖于关键字。

（学生ID，所修课程ID）→学生姓名

学生ID→学生姓名

学生姓名可以依赖于关键字的一个主属性——学生ID，因此学生姓名部分函数依赖于（学生ID，所修课程ID）。

（学生ID，所修课程ID）→学生姓名

实体的描述：

数据库实体就是数据库管理系统中的不同管理对象。

数据库管理系统中的各种用于数据管理方便而设定的各种数据管理对象，如：

数据库表、视图、存储过程等都是数据库实体。

广义上讲，这些对象中所存储的数据也是数据库实体。

因为它们也是确切存在着的实体

三大范式：

◆第一范式（1NF）：

强调的是列的原子性，即列不能够再分成其他几列。

考虑这样一个表：

【联系人】（姓名，性别，电话）

如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到1NF。

要符合1NF我们只需把列（电话）拆分，即：

【联系人】（姓名，性别，家庭电话，公司电话）。

1NF很好辨别，但是2NF和3NF就容易搞混淆。

◆第二范式（2NF）：

首先是1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

考虑一个订单明细表：

【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。

因为我们知道在一个订单中可以订购多种产品，所以单单一个OrderID是不足以成为主键的，主键应该是（OrderID，ProductID）。

显而易见Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而UnitPrice，ProductName只依赖于ProductID。

所以OrderDetail表不符合2NF。

不符合2NF的设计容易产生冗余数据。

可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。

◆第三范式（3NF）：

首先是2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。

即不能存在：

非主键列A依赖于非主键列B，非主键列B依赖于主键的情况。

考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。

其中OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity等非主键列都完全依赖于主键（OrderID），所以符合2NF。

不过问题是CustomerName，CustomerAddr，CustomerCity直接依赖的是CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合3NF。

通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到3NF。

第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关